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]。
5. 【一問一答セルフテスト】
問1（○×問題）
JSON形式で記述される「IAMポリシー」の構成ルールにおいて、プロパティ内の「Action」には『どのAWSサービスに対して何のアクションを実行してよいか（例：s3:GetObject）』を記述し、「Resource」には『その操作の具体的な対象物（例：対象バケットのARNなど）』を指定する。
（○ か × か） [p.182]
問2（○×問題）
企業において「カスタマー管理ポリシー」を定義した。このポリシーの権限変更（Actionの追加など）を行った際、このポリシーがアタッチされているすべてのIAMグループ、ユーザー、およびロールに対して、ポリシーを個別にアタッチし直すことなく自動的かつ一元的に新しい権限設定が反映される。 （○ か × か） [p.182]
問3（4択問題）
EC2インスタンス上のJavaプログラムから、本番環境のDynamoDBテーブルに対してデータを書き込む必要があります。このとき、責任共有モデルおよびAWSのセキュリティベストプラクティスに基づき、認証情報の流出リスクを最も低く抑えつつ、アプリケーションに最小限の権限（書き込みのみ）を与えるための正しい設計構成はどれですか。 [p.183-184]
- A. ルートユーザーのアクセスキーをEC2インスタンスのユーザーデータに直接保存して起動する。
- B. DynamoDBへの書き込みポリシーをアタッチした「IAMロール」を作成し、そのロールをEC2インスタンスに割り当てる（アタッチする）。
- C. 新規にIAMユーザーを作成して「アクセスキー」をプログラムソースコードにハードコードしてコンパイルする。
- D. インスタンス内でセキュリティグループの設定を変更し、DynamoDBへの通信（ポート443）をインバウンドですべて「許可（Allow）」にする。
問4（4択問題）
IAMユーザーにおける認証資格情報の使い分けについて記述した次のうち、最も「正しい」説明はどれですか。 [p.183]
- A. 「ユーザーIDとパスワード」は、AWS CLI（コマンドライン）やAPIを経由してプログラムからAWSにアクセスする際の認証に使用する。
- B. 「アクセスキーIDとシークレットアクセスキー」は、Webブラウザ（マネジメントコンソール）へ手動でパスワードログインするために使用する。
- C. 「ユーザーIDとパスワード」はマネジメントコンソールへのログイン認証に使用し、「アクセスキーIDとシークレットアクセスキー」はCLIやAPIを経由した外部からのアクセス時（プログラム等）に使用する。
- D. セキュリティを最大化するため、マネジメントコンソールへのサインインにはパスワードではなく、必ずアクセスキーIDを代入しなければならない。
問5（○×問題）
「IAMグループ」は同一の権限を割り当てられたIAMユーザーをまとめた論理コンテナであり、グループそのものはログインパスワードやアクセスキーといった「独自の認証資格情報」を持たないため、グループ自体のアカウントでコンソールに直接サインインすることはできない。 （○ か × か） [p.183-184]
【解答と解説】
解答1：○
- 解説: 記述の通りです [p.182]。IAMポリシーはJSONで記述され、「Effect（許可/拒否）」「Action（実行コマンド、何をするか）」「Resource（操作されるAWSリソースの実体、ARNで指定）」などを定義することで、リソースへの具体的な動作の境界線を明確に決定します [p.182]。
解答2：○
- 解説: 記述の通りです [p.182]。インラインポリシーと異なり、管理ポリシー（カスタマー管理ポリシー含む） はポリシー単体として独立して管理されているため、ポリシー自体の定義を1箇所修正（アップデート）するだけで、それをアタッチしているすべてのIAMグループ、ユーザー、ロールの権限が一発で同期的に一括適用（変更）されます [p.182]。これにより運用管理のミスを防ぐことができます [p.182]。
解答3：B
- 解説: 正解は B です [p.184]。プログラムに永続的なアクセスキーを持たせる設計（A、C）は流出時のリスクが極めて高いため試験では完全に排除します [p.183-184]。IAMロールをEC2にアタッチすることで、プログラムは一切の固定キーを持たず、AWS側から自動発行される安全な「一時的セキュリティ資格情報」を利用してDynamoDBにアクセスできるようになります [p.184]。なお、Dは通信を制御するネットワーク機能（セキュリティグループ）であり、リソースに対するAPI操作権限（認可）とはレイヤーが異なるため不適合です [p.36, p.181]。
解答4：C
- 解説: 正解は C です [p.183]。人間がマネジメントコンソール（Web画面）から操作する場合は「ユーザーIDとパスワード」を入力し、システムやCLI、APIコードからAWSリソースを実行する場合は「アクセスキーIDとシークレットアクセスキー」を使用します [p.183]。これらを逆に入力して接続することは物理仕様上不可能です [p.183]。
解答5：○
- 解説: 記述の通りです [p.183-184]。IAMグループはあくまで管理をシンプルにするための「権限をまとめる箱」であり、グループ自体が認証資格情報を保持してサインインやAPI呼び出しのアクションを自ら実行することはありません。ログインやアクションの実行主体となるのは、常にグループに所属している個々の「IAMユーザー」です [p.183-184]。
🏁 これで第7章7-3（IAMの権限管理）のコア論点も完璧に網羅されました！
セキュリティ管理を盤石に整えたら、次はいよいよAWS上のシステム構築の第一歩となる 「Amazon VPC（第2章）」のサブネットやインターネットゲートウェイ、セキュリティグループの実装へとステップを進めましょうか？