LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@hiyuuma(kamsaki)

AWS IAM超入門：知っておきたいセキュリティ設計と運用のベストプラクティス

Posted at

AWS IAM超入門：知っておきたいセキュリティ設計と運用のベストプラクティス

1. IAMとは？

AWS Identity and Access Management (IAM) は、AWSリソースへのアクセスを安全に管理するためのサービスです。IAMを使うと、「誰が」「どのAWSリソースに」「どのような操作を行えるか」を細かく制御できます (IAM とは - AWS Identity and Access Management)。つまり、IAMはユーザーの認証（Authentication）と権限の認可（Authorization）を統合的に扱い、AWS環境へのアクセス管理の基盤を提供します。

IAMの利用により、AWSアカウント内で複数のユーザーや役割を作成し、それぞれに必要最低限の権限を割り当てることができます。たとえば、新しくAWSアカウントを作成すると最初にルートユーザー（アカウント作成時のメールアドレスでログインするユーザー）だけが存在します。このルートユーザーはアカウント内の全リソースに対する完全な権限を持ちますが、セキュリティ上の観点から日常業務ではルートユーザーの使用は避けることが強く推奨されています (IAM とは - AWS Identity and Access Management)。代わりにIAMを用いて管理者や開発者などのユーザーを作成し、それぞれに適切な権限を付与して運用します。

要点をまとめると、IAMはAWSにおけるユーザー管理とアクセス制御の中心となるサービスです。これを正しく理解し設定することで、クラウド上のリソースを安全に利用できるようになります。

2. IAMユーザー・グループ・ロールの違いと使い分け

IAMではアクセス管理の主体となるエンティティとして「ユーザー」「ユーザーグループ」「ロール」の3種類が存在します。それぞれ役割が異なるため、違いと使い分けを把握しておきましょう。

  • IAMユーザー: IAMユーザーは、1人の人間（またはアプリケーション）に紐づくAWSアカウント内のアイデンティティです (IAM アイデンティティ - AWS Identity and Access Management)。一般的に社員や開発者など、人がAWSマネジメントコンソールにログインしたりAPIキーを使ってAWSサービスを操作する際に、このIAMユーザーを利用します。IAMユーザーにはログイン用の認証情報（パスワードやアクセスキー）が割り当てられ、作成直後は権限を持たないため必要なポリシーをアタッチして権限を与えます。

  • IAMユーザーグループ: IAMユーザーグループは、その名の通りIAMユーザーの集合を表します (IAM アイデンティティ - AWS Identity and Access Management)。グループ自体にポリシー（権限）を割り当てることで、グループに所属するすべてのユーザーに一括して同じ権限を付与できます。例えば、「開発チーム」グループや「管理者」グループを作成し、それぞれに適切なアクセス権限を付与すると、ユーザー個別ではなくグループ単位で統一的に権限管理が可能になります。組織やプロジェクト単位でユーザー権限をまとめたい場合に便利です。

  • IAMロール: IAMロールは特定の権限を持つAWSアカウント内のアイデンティティで、特定のユーザーに紐づかない点がIAMユーザーと異なります (IAM アイデンティティ - AWS Identity and Access Management)。ロールは主にAWSのサービスや外部ユーザーに一時的な権限を付与するために使われます。例えば、EC2上で動くアプリケーションがS3にアクセスする必要がある場合、IAMロールを作成して必要なS3アクセス権限をロールに付与し、そのロールをEC2インスタンスにアタッチします。これにより、そのEC2上のアプリケーションはロール経由で一時的な認証情報を取得し、必要なS3操作のみ実行できるようになります (〖AWS IAMとは？〗初心者にもわかりやすく解説｜WafCharm｜WAF自動運用サービス)。また、IAMロールはAWSアカウント間のリソース共有にも活用できます。他のアカウントに自分のリソース（例えばS3バケット）へのアクセスを許可したい場合、自アカウントに相手アカウント用のロールを作成し権限を付与することで、相手側はスイッチロール機能を使って一時的に自アカウントのリソースにアクセスできるようになります (〖AWS IAMとは？〗初心者にもわかりやすく解説｜WafCharm｜WAF自動運用サービス)。

図無しの解説にはなりますが、まとめると以下のような使い分けになります: 「人」がAWSを操作する場合はIAMユーザー（と必要に応じてグループ）、AWSサービスや外部からのアクセスにはIAMロールを使用する。適切に使い分けることで、安全かつ柔軟なアクセス権管理が可能です。

3. 最小権限の原則とは？

**最小権限の原則（Principle of Least Privilege）**とは、ユーザーやロールに対して業務遂行に必要最低限の権限だけを付与し、不要な権限は与えないようにするセキュリティ設計の基本原則です (IAM でのセキュリティのベストプラクティス - AWS Identity and Access Management)。簡単に言えば「やり過ぎない権限設定」のことで、例えば閲覧だけで良いユーザーに編集や削除の権限を与えない、といった具合にアクセスを絞ります。

この原則が重要視される理由はセキュリティと運用上のリスク軽減にあります。権限が必要以上に与えられたアカウントが万一不正利用された場合、攻撃者に広範囲な操作を許してしまい被害が大きくなります。また、ユーザー本人が誤って重要なリソースを変更・削除してしまうリスクも増えます。最小権限に留めておけば、万一その認証情報が漏洩した場合でも被害範囲を最小限に食い止めることができます (SEC03-BP02 Grant least privilege access - AWS Well-Architected Framework)。AWS Well-Architectedフレームワークでも「権限を最小限に抑えることは、誤ったアクセスを制限し『誰が何にアクセスできるか』の追跡を容易にする」と説明されています (SEC03-BP02 Grant least privilege access - AWS Well-Architected Framework)。

実務においても最小権限の考え方は常に意識すべきです。権限を付与する際は「本当にこの操作は必要か？」を検討し、必要無いなら許可しないようにします。例えば、開発者に日常業務でIAMユーザーやポリシーを削除・変更する権限は通常不要ですし、閲覧担当者にリソース作成権限は必要ありません。初めは広い権限で検証し、動作に必要な権限が判明したら余分な権限を削る、という手順でポリシーを段階的に絞り込むのも有効です (IAM でのセキュリティのベストプラクティス - AWS Identity and Access Management) (IAM でのセキュリティのベストプラクティス - AWS Identity and Access Management)。このようにしてAWS環境の権限を常に適正に保つことで、セキュリティ事故の発生リスクを大幅に低減できます。

4. 具体的な運用例

それでは、IAMの概念を実際のユースケースでどのように適用するか考えてみましょう。ここでは架空の企業「Example Corp」における運用例を参考に、IAMユーザーグループとポリシー設計の具体例を紹介します (IAM のビジネスユースケース - AWS Identity and Access Management)。

シナリオ: Example Corpでは、社内の役割に応じて以下の3つのIAMユーザーグループを作成し、それぞれに異なる権限を与えてAWSリソースへのアクセスを管理しています。

  • システム管理者グループ (SysAdmins) – インフラ全般の管理を担当するユーザー向け。Amazon EC2のインスタンスやボリューム、セキュリティグループの作成・削除などあらゆる操作が必要になるため、このグループにはAWS管理ポリシーのAdministratorAccessもしくはEC2に関するフルアクセス権限を持つAmazonEC2FullAccessポリシーをアタッチしています (IAM のビジネスユースケース - AWS Identity and Access Management)。これにより、SysAdminsグループのメンバーはEC2に関する全てのAPI操作が可能です。

  • 開発者グループ (Developers) – 自社アプリケーションの開発・デプロイを担当するユーザー向け。開発者にはEC2インスタンスの起動・停止など基本的な操作権限は必要ですが、インフラ全体の管理権限までは不要です。そのため、Example Corpでは開発者が必要とする特定のAPI操作（例：DescribeInstances、RunInstances、StopInstances、StartInstances、TerminateInstances）のみに絞ったカスタムポリシーを作成し、Developersグループにアタッチしています (IAM のビジネスユースケース - AWS Identity and Access Management)。このポリシーにより、開発者はインスタンスの起動・停止や情報参照はできますが、不要なリソース作成や削除は行えません。まさに最小権限の原則を体現した設定と言えます。

  • サポートグループ (Support) – システムの監視や問い合わせ対応を担当するユーザー向け。基本的にリソースの状態を閲覧できれば十分なので、SupportグループにはEC2の情報取得系操作（DescribeInstancesなど）のみに限定した読み取り専用ポリシーをアタッチしています (IAM のビジネスユースケース - AWS Identity and Access Management)。Supportグループのメンバーは現在稼働中のリソース一覧を確認できますが、起動・停止を含めリソースを変更する操作は一切できません。

上記のようなグループ分けとポリシー適用により、各ユーザーは自分の職務に見合った範囲のAWS操作しか行えないようになります。さらに、ユーザーの異動や役割変更が発生した場合もグループの所属を変更するだけで権限を調整できます。例えば、Example Corpではある開発者をサポート担当に異動させる際、彼をDevelopersグループからSupportグループへ移動させました (IAM のビジネスユースケース - AWS Identity and Access Management)。これにより、そのユーザーは開発者権限（インスタンス操作権限）を失い、代わりにサポート権限（閲覧のみ）に自動で置き換わります (IAM のビジネスユースケース - AWS Identity and Access Management)。個別にポリシーを編集することなく、グループ管理によってスムーズに最小権限の原則を維持できた好例です。

他にもIAMロールの活用例として、EC2からS3へのアクセスにはIAMロールを使う、複数アカウント運用時に共通の管理者ロールを用意してスイッチロールで切り替える、といったユースケースが挙げられます。自社のシステム構成や運用体制に合わせてIAMユーザー/グループ/ロールを適切に設計することが、セキュアで効率的なAWS運用の鍵となります。

5. IAM設定の実践（CLI操作・ポリシーJSON）

IAMの基本設定はAWSマネジメントコンソールからGUIベースで行えますが、ここではAWS CLIやポリシーのJSON例を使った設定方法を紹介します。コードや設定ファイルでIAMを扱えるようになると、より正確かつ再現性のある権限管理が可能になります。

IAMユーザーとグループの作成（AWS CLI）

AWS CLIを使用すると、ターミナルから直接IAMの操作が可能です。例えば、新規IAMユーザーを作成するには以下のコマンドを実行します。

# IAMユーザー「Bob」を作成
aws iam create-user --user-name Bob

上記を実行すると、ユーザー「Bob」が現在のAWSアカウントに作成されます (create-user — AWS CLI 1.37.15 Command Reference)。作成直後のIAMユーザーには権限が無いため、続いてポリシーをアタッチします。一般的な方法はマネージドポリシーをアタッチすることです。AWSが用意した代表的なポリシー（AWS管理ポリシー）を利用すれば、JSONを書くことなく基本的な権限セットを割り当てられます。例えば、先ほど作成したユーザー「Bob」に管理者権限を与えるには次のようにします。

# ユーザー「Bob」にAdministratorAccessポリシーをアタッチ
aws iam attach-user-policy \
    --user-name Bob \
    --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

このコマンドは、AWS管理ポリシーのAdministratorAccessをユーザーBobに関連付けています (attach-user-policy — AWS CLI 1.37.15 Command Reference)。実行しても出力はありませんが、aws iam list-attached-user-policies --user-name Bob などとすれば、ポリシーがアタッチされたことを確認できます。

もちろん、現実の運用でいきなりAdministratorAccessを付与するのは最小権限の原則に反します。上記は例示として管理者相当の権限を付けましたが、実際には必要な権限だけを付与するポリシーを選ぶか作成します。複数ユーザーに共通の権限を与える場合は、個々のユーザーに直接ポリシーをアタッチするのではなくIAMユーザーグループを作成してポリシーを付与し、ユーザーをそのグループに参加させる方法が推奨されます。例えば「Developersグループ」に開発者向けポリシーをアタッチし、全ての開発者ユーザーをそのグループに所属させる、といった形です。これによりポリシー管理がシンプルになり、ユーザーの追加・削除時にも権限の付け外し漏れを防止できます (SEC03-BP02 Grant least privilege access - AWS Well-Architected Framework)。

IAMポリシーJSONの記述例

IAMポリシーはJSONドキュメントで定義されます。マネージドポリシーにない細かな権限要件がある場合、自分でJSONを記述してカスタマー管理ポリシーを作成できます (〖AWS IAMとは？〗初心者にもわかりやすく解説｜WafCharm｜WAF自動運用サービス)。JSONの書式はIAMポリシー共通で、基本構造は以下の通りです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow or Deny",
      "Action": "許可または禁止するAWSアクション(またはその配列)",
      "Resource": "対象となるAWSリソース(ARNで指定, 配列可)",
      "Condition": { "条件オプション": "（必要に応じて）" }
    }
  ]
}

Statementには複数の権限文を含めることができ、それぞれにEffect（許可/拒否）、Action（操作）、Resource（リソース）を指定します。Conditionは必要に応じて付加でき、例えばアクセス元IPアドレスや日付、リクエスト時の他の条件で更にアクセスを絞り込むことが可能です。

例: 特定のS3バケットに対する読み書きのみ許可するポリシー
以下に、バケットmy-example-bucket上のオブジェクトに対して読み書き（GetObject/PutObject）権限だけを許可するポリシーJSONの例を示します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-example-bucket/*"
    }
  ]
}

このポリシーでは、my-example-bucketバケット内の全オブジェクト（/*で指定）に対し、S3のGetObject（取得）とPutObject（アップロード）の2つのアクションだけを許可しています。それ以外の操作（例えばバケット削除や他のバケットへのアクセス等）は明示的に許可していないため、デフォルト拒否の原則により実行できません。まさに必要最小限の操作権限だけを与えたポリシーになっています。

作成したJSONポリシーは、AWS CLIを使ってAWSアカウントに登録（ポリシーの作成）できます。例えば上記JSONをpolicy.jsonというファイルに保存し、以下のコマンドを実行するとカスタマー管理ポリシーを作成可能です。

# policy.jsonの内容でカスタムポリシーを作成
aws iam create-policy \
    --policy-name MyS3ReadWritePolicy \
    --policy-document file://policy.json

これでMyS3ReadWritePolicyという名前のカスタムポリシーがAWSアカウントに作成されます。あとはこのポリシーを必要とするユーザーやグループ、ロールにアタッチすれば、該当ユーザーらは指定バケットへの読み書きのみ行えるようになります。

なお、AWS公式ドキュメントには用途別のポリシーサンプルが多数掲載されています。ポリシー記述に迷ったときは「AWS 管理ポリシー」の定義を参照したり、ドキュメント中のユースケース別ポリシー例を参考にすると良いでしょう (IAM のビジネスユースケース - AWS Identity and Access Management)。

6. ベストプラクティスと注意点

最後に、IAMを運用する上で押さえておくべきベストプラクティスと注意点をまとめます。セキュリティ事故を未然に防ぎ、安全なクラウド運用を行うためにも以下のポイントを意識してください。

  • ルートユーザーの利用最小化と保護: ルートユーザーは強力な権限を持つため、日常的な利用は避け、どうしても必要な場合だけ使用します (IAM とは - AWS Identity and Access Management)。AWSアカウント作成直後にまずIAMで管理者用のユーザーを作成し、以降の操作はその管理者ユーザーで行うようにしましょう。またルートユーザーには必ずMFA（多要素認証）を有効に設定し、不正ログイン対策を施してください (IAM でのセキュリティのベストプラクティス - AWS Identity and Access Management)。ルートの認証情報（メールアドレス・パスワードやアクセスキー）は他人に共有せず、厳重に保管します。

  • 多要素認証（MFA）の活用: IAMユーザーやロールを用いたアクセスでも、特に権限の高いアカウントにはMFAを必須としましょう。MFAを有効化すると、通常のパスワード認証に加えてワンタイムコードの入力が必要になり、認証情報漏洩時の不正アクセスリスクを大きく下げることができます (IAM でのセキュリティのベストプラクティス - AWS Identity and Access Management)。AWSでは仮想MFAデバイス（スマホアプリ）やハードウェアキーなどさまざまなMFA手段をサポートしています。すべてのIAMユーザーにMFAを設定するのが理想ですが、特に管理者権限を持つユーザーやコンソールログインを行うユーザーには優先的に適用してください。

  • 最小権限アクセスの徹底: 前述の通り、必要な権限だけを付与し不要な権限は付けない運用を徹底します (IAM でのセキュリティのベストプラクティス - AWS Identity and Access Management)。権限を付ける際は原則として「Deny (拒否)」より「Allow (許可)」を列挙する形式でポリシーを作成し（ホワイトリスト方式）、デフォルト拒否の利点を活かします。既存のポリシーやユーザー権限も定期的に見直し、「このユーザーにこの権限は過剰ではないか？」とチェックしましょう。AWS IAM Access Analyzer等のツールを使うと、実際に使用していない権限を洗い出し不要な許可を削減するのに役立ちます (Security best practices in IAM - AWS Identity and Access Management)。権限の過剰付与（Permissions Creep）を防ぐことがセキュリティ維持の重要ポイントです。

  • IAMロールと一時的クレデンシャルの利用: EC2やLambda、その他AWSサービスがAWSリソースにアクセスする必要がある場合、IAMロールを使って一時的な認証情報を取得させるようにします。アプリケーションに長期的なアクセスキーをハードコーディングしたり手動で配布したりするのは避け、ロール経由で必要時に一時クレデンシャルを払い出す仕組みを利用しましょう (IAM でのセキュリティのベストプラクティス - AWS Identity and Access Management)。これにより、定期的なキーのローテーション管理が不要になるほか、万一そのリソースが侵害されても長期キー漏洩による被害を防げます。人間のユーザーについても、可能であればAWS SSO（IAM Identity Center）などを活用し、一時的な認証情報でアクセスするのが望ましいとされています (IAM でのセキュリティのベストプラクティス - AWS Identity and Access Management)。

  • アクセスキーやパスワードの適切な管理: IAMユーザーのアクセスキー（APIキー）やパスワードを扱う場合は、その管理・運用にも注意が必要です。アクセスキーは原則として必要最小限のユーザーにのみ発行し、定期的にローテーション（再生成と更新）を行います (IAM でのセキュリティのベストプラクティス - AWS Identity and Access Management)。古いアクセスキーが不要になったらすぐに無効化・削除し、利用状況をCloudTrailログなどで監視すると安心です。コンソール用パスワードについてはアカウントポリシーで強力なパスワード要件を設定し、一定期間でのパスワード更新を促す運用も検討してください。

  • 不要なIAMリソースのクリーンアップ: 定期的にIAMユーザー、ロール、ポリシー、アクセスキーなどを棚卸しし、不要になったものは削除しましょう (Security best practices in IAM - AWS Identity and Access Management)。たとえば退職者のIAMユーザーや使われなくなったロール・ポリシーが放置されていると、それらが予期せぬ形で悪用されるリスクがあります。IAMコンソールでは各種リソースの「最終利用日時」を確認できますので、長期間使われていない資格情報は無効化や削除を検討してください (Security best practices in IAM - AWS Identity and Access Management)。

  • その他のセキュリティ策: 上記以外にも、IAMポリシーに条件文を入れて特定のIPアドレスからのみアクセス許可する、Organizationsサービスとサービスコントロールポリシー(SCP)を使ってアカウント全体のガードレールを設定する、といった高度な管理も可能です。 (IAM でのセキュリティのベストプラクティス - AWS Identity and Access Management)で示されているように、条件付きでアクセスを絞り込むことや、組織単位での統制を利かせることも検討しましょう。また、重要な操作（例えばポリシーの変更や権限の付与）についてはCloudTrailを有効化して監査ログを取得し、必要に応じてアラート設定を行うのが望ましいです。

以上のベストプラクティスを踏まえてIAMを適切に運用すれば、AWS環境のセキュリティレベルを高く維持できます。IAMは強力な反面、設定ミスがあると重大なインシデントにつながる可能性もあるため、慎重かつ定期的な見直しが欠かせません。常に「最小権限」を意識し、安全なアクセス管理を心がけましょう。

7. 参考資料

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?