2026-08-05（水）AWS基礎＋IAM（権限管理）

1. 【この範囲の全体像】

本範囲（第7章7-3）は、AWS上の各種リソースへのアクセスを「誰が（認証：Authentication）」「何に対してどのような操作をできるか（認可：Authorization）」安全にコントロールする、セキュリティの要（かなめ）である「IAM」の仕組みを学びます [p.181]。

「IAMポリシー」「IAMユーザー」「IAMグループ」「IAMロール」という4大構成要素の論理的な関係性を深く理解すること [p.181]、および、アクセスキー漏洩のリスクを極小化するために永続的なキーを持たない「IAMロール」の一時的なセキュリティ資格情報をリソースに委譲するベストプラクティス（最小権限の原則）をマッピングする能力が試験で厳しく問われます [p.183-184]。

2. 【重要キーワード・サービス一覧】

キーワード	説明
IAMポリシー (IAM Policy)	「どのような操作（Action）を、どのリソース（Resource）に対して、許可または拒否（Effect）するか」をJSON形式で定義した権限のマスター仕様書 [p.182]。
管理ポリシー (Managed Policy)	複数のユーザー、グループ、ロールに対して繰り返し再利用・アタッチが可能な独立したポリシー [p.182-183]。AWS側が作成・アップデートを行う「AWS管理ポリシー」と、ユーザーが独自に定義する「カスタマー管理ポリシー」がある [p.182]。
インラインポリシー (Inline Policy)	特定のユーザー、グループ、またはロールに1対1で直接埋め込まれ、そのオブジェクトと運命を共にする、他へ再利用不可能なポリシー [p.182-183]。
IAMユーザー (IAM User)	人間（個々のオペレーターや開発者）や特定の個別プログラムに1対1で作成される「個別のID」 [p.183]。
IAMグループ (IAM Group)	同じ権限ポリシーを共有するIAMユーザーを論理的にまとめる「コンテナ」 [p.183-184]。グループの配下に別のグループを所属させる「階層化（ネスト）」は行えない [p.184]。
IAMロール (IAM Role)	永続的なアクセスキー（パスワードやアクセスキーペア）を持たない、リソースや別アカウントのユーザーに「一時的なアクセス権限」を安全に貸し出す（委譲する）ための仕組み [p.184]。
一時的セキュリティ資格情報	IAMロールを引き受ける（AssumeRoleする）ことでAWSセキュリティトークンサービス（STS）から動的に発行される、有効期限付きのセキュアな認証トークン [p.184]。

3. 【試験で問われる比較ポイント】

① 権限定義：管理ポリシー vs インラインポリシー [p.182-183]

「ガバナンス・効率的な共通管理」か「1対1の厳密な個別例外管理」かで切り分けます [p.182]。

比較項目	管理ポリシー (Managed Policy) [p.182]	インラインポリシー (Inline Policy) [p.182]
再利用性（流用性）	高い（1つのポリシーを、複数のIAMユーザー/グループ/ロールへアタッチ可能） [p.182]。	なし（作成した特定のオブジェクトに直接埋め込まれ、他へは適用できない） [p.182]。
主な用途	開発チーム共通の「S3閲覧権限」や、管理者用「AdministratorAccess」などの標準権限 [p.182-183]。	「特定の1名（または1リソース）に対してのみ、例外的にこのバケットだけ限定的に操作を許可したい」場合 [p.182]。
管理のメリット	ポリシー自体の修正（バージョン管理）を行えば、アタッチされているすべてのリソースに一括で更新が反映される [p.182]。	ポリシーとオブジェクトの関係が1対1で固定されるため、ポリシーが不用意に他のリソースへアタッチされる事故を防げる [p.182]。

② 権限の宛先：IAMユーザー vs IAMロール [p.183-184]

「永続的なログインキーが必要な人間」か、「認証キーの流出を防ぎたいAWSリソースやプログラム」かで切り分けます [p.183-184]。

比較項目	IAMユーザー [p.183]	IAMロール [p.184]
認証キーの有無	あり（ログイン用の「ユーザーID/PW」、または「アクセスキーペア」を永続的に保持） [p.183]。	なし（ログイン用パスワードや永続キーは持たない。AssumeRole時に一時的な資格情報を発行） [p.184]。
主な適用対象	コンソールにサインインして直接操作する「人間（開発者、運用者）」 [p.183]。	「 EC2、LambdaなどのAWSリソース（プログラム）」、または「外部システム/他アカウントのユーザー」 [p.184]。
キー管理の手間	アクセスキーの定期的なローテーション（更新）や流出防止のための厳格な管理がユーザー側に要求される [p.183]。	AWS側がバックグラウンドで一時的なセキュリティ資格情報を自動生成・ローテーションするため、キー管理が不要（運用負荷ゼロ） [p.184]。

4. 【ひっかけ注意ポイント】

ひっかけ①：EC2インスタンス上で稼働するアプリケーションからAmazon S3やDynamoDBへデータを保存させるため、あらかじめ作成したIAMユーザーの「アクセスキー（Access Key ID / Secret Access Key）」をプログラムのコードや設定ファイルに記述してEC2内に保存する。
- 真実: アクセスキーのプログラム内へのハードコードは、ソースコード管理ツール（GitHubなど）への誤公開や、サーバーハッキングによってキーが露出した際、即座にアカウント全体の乗っ取り（重大なセキュリティ事故）に直結する絶対的な禁止パターン（アンチパターン） です [p.20, p.183-184]。
- 解決理由: プログラムに対してAWSリソースへのアクセスを許可する要件では、一切の物理的なアクセスキーを持たない 「IAMロール」を定義してEC2インスタンスにアタッチします [p.184]。これにより、AWS側が「一時的なセキュリティ資格情報（セッショントークン）」を安全にEC2内部に自動供給するため、キーをコード内に一切書くことなく安全なプログラム接続が可能となります [p.184]。
ひっかけ②：社内組織のネスト構造（開発本部 ➡ 第一開発部 ➡ インフラチーム）をそのままシステム権限に投影するため、IAMグループの配下にさらに別のIAMサブグループを階層構造として作成し、上位グループのポリシー権限を順次自動継承させる。
- 真実: AWS IAMの物理仕様上、「IAMグループの中に別のグループを所属させる（ネストする）」ことはできません [p.184]。グループは常にフラットな1階層（単一階層）で管理されます [p.184]。
- 解決理由: グループはネストせずフラットに並列配置します [p.184]。その代わり、共通の権限セットを「カスタマー管理ポリシー」として個別に定義し、それを必要とする複数のフラットなグループにそれぞれ個別にアタッチすることで、権限のポリシーベースでの共通統制とガバナンスを確保します [p.182-184]。