AWS IAM

このページで押さえる論点

• ユーザー・グループ・ロールの使い分けと、ルートユーザーの保護（MFA）
• ポリシーの種類（アイデンティティベース・リソースベース・SCP・アクセス許可の境界）
• ポリシーの評価ルール（明示的な拒否・許可・暗黙の拒否）
• アクセス許可の境界による権限管理の委任
• IAM ロールと AWS STS（AssumeRole・一時的な認証情報・EC2 のロール）
• クロスアカウントアクセス（ロールの引き受けとリソースベースポリシー。両側での許可が必要）
• Condition による制限（aws:SourceIp・MFA・組織 ID）
• フェデレーションと IAM Identity Center（複数アカウントへのサインイン）
• IAM Access Analyzer（外部公開・未使用の権限の検出、ポリシーの検証）

ユーザー・グループ・ロールの使い分け

IAM の登場人物は、人や仕組みを表す IAM ユーザー・IAM グループ（ユーザーのまとまり）・IAM ロール（一時的に引き受ける権限のセット）と、権限を書いた ポリシー（JSON 形式の文書）です。ポリシーには「Effect（Allow = 許可 / Deny = 拒否）」「Action（操作。例: s3:GetObject = S3 のファイル読み取り）」「Resource（対象）」を書き、必要なら「Condition（条件）」を加えます。

AWS アカウントを作ったときのルートユーザーはすべての権限を持つので、日常の作業には使わず、MFA（多要素認証。パスワードに加えてワンタイムパスワードなどを求める）を設定し、アクセスキーは作りません。IAM ユーザーや管理者権限を持つ人にも MFA を必須にします。権限は最小権限の原則（必要な操作・リソースだけを許可する）で付けます。

ポリシーの種類

試験で区別が必要なのは次の 4 つです。権限を与えるものと、上限を決めるだけのものがある点が重要です。

ポリシーの評価ルール

リクエストが来ると、AWS は関係するポリシーを全部集めて判定します。順番は「① どこかに明示的な Deny があれば拒否 → ② SCP の上限の外なら拒否 → ③ Allow があれば許可 → ④ どれにも当てはまらなければ暗黙の拒否」です。優先度でいうと 明示的な拒否 > 許可 > 暗黙の拒否 になります。何も書かれていなければ拒否（暗黙の拒否）なので、使わせたい操作は必ずどこかで Allow する必要があります。

図では省いたものも、同じ考え方で判定に加わります。

• リソースベースポリシー: 同じアカウント内なら、アイデンティティベースポリシーとリソースベースポリシーのどちらか一方で Allow されていれば許可されます。別アカウントからのアクセスでは両方の Allow が必要です（クロスアカウントアクセスを参照）。
• アクセス許可の境界: SCP と同じく「上限」です。境界の外の操作は、アイデンティティベースポリシーで Allow していても拒否されます。
• Condition: 条件に合わないリクエストには、その Allow や Deny が当てはまりません（Condition による制限を参照）。

アクセス許可の境界

アクセス許可の境界（Permissions Boundary）は、IAM ユーザーやロールに付ける管理ポリシーで、そのユーザー・ロールが持てる権限の最大値を決めます。実際に使える権限は、アイデンティティベースポリシーと境界の両方で許可された操作だけ（2 つの重なった部分）です。境界だけを付けても、権限は何も増えません。

典型的な使い方は、権限管理の委任です。たとえば開発者に「IAM ロールを作ってよい」権限を渡したいが、開発者が自分より強い権限のロールを作ってしまうのは困る、という場合に、「作るロールには必ずこの境界を付けること」を条件に作成を許可します。こうすると、開発者が作ったロールは境界の範囲を超えられません。

SCP との違いは範囲です。SCP は Organizations でアカウント全体に上限をかけ、境界は個々のユーザー・ロールに上限をかけます。

IAM ロールと AWS STS

AWS STS（Security Token Service）は、一時的な認証情報を発行するサービスです。ロールを引き受ける（AssumeRole）と、STS から「アクセスキー ID・シークレットアクセスキー・セッショントークン」の 3 つがセットになった一時的な認証情報が返ります。有効期間は 15 分から最大 12 時間（ロールに設定した最大セッション時間の範囲内）で、指定しなければ 1 時間です。ロールから別のロールを引き受けるロールの連鎖では、最大 1 時間に制限されます。

ロールには 2 種類のポリシーを付けます。「ロールで何ができるか」を書くアクセス許可ポリシーと、「誰がこのロールを引き受けてよいか」を書く信頼ポリシーです。

EC2 上のアプリから S3 を使うとき、アクセスキー（長期間使える ID とパスワードの組）をサーバーに保存すると、漏えいしたときに悪用され続ける危険があります。代わりに EC2 に IAM ロールを付けると、有効期限つきの一時的な認証情報が自動で発行・更新されます。Lambda などほかのサービスも同じ考え方で、ワークロードには IAM ロールの一時的な認証情報を使うのが推奨です。

クロスアカウントアクセス

別の AWS アカウントの人やアプリにリソースを使わせる方法は 2 つあります。どちらの場合も、リクエストする側のアカウントと、リソースを持つ側のアカウントの両方で Allow が必要です。片方だけでは拒否されます。

ロールを引き受けている間は、元のユーザーの権限ではなくロールの権限だけで動きます。元の権限に戻るのはロールを終了したときです。自分のアカウントのリソースと相手のリソースを同時に扱いたい処理（例: 自分のバケットから相手のバケットへコピー）では、ロールではなくリソースベースポリシーが向いています。アクセスキーやパスワードを相手に渡す方法は使いません。

Condition による制限

ポリシーの Condition（条件）に AWS 全体で使える条件キーを書くと、「どこから」「どうやって」のリクエストかでアクセスを絞れます。

フェデレーションと IAM Identity Center

フェデレーションとは、社内の ID（Active Directory などで管理しているアカウント）で認証した人に、AWS 側のロールの一時的な認証情報を渡す仕組みです。社員ごとに IAM ユーザーを作らずに済み、退職者の管理も社内の ID 側だけで済みます。

AWS IAM Identity Center は、社員（ワークフォースユーザー）が複数の AWS アカウントや AWS のアプリケーションに 1 か所からサインインできるようにするサービスです。Microsoft Entra ID・Okta・Active Directory などの既存の ID プロバイダーをつないでユーザーとグループを同期するか、Identity Center の中で直接ユーザーを作ります。職務ごとの権限はアクセス許可セットとして一元管理し、どのユーザー・グループにどのアカウントで割り当てるかを決めます。Organizations と組み合わせて使うのが推奨です。

なお、自社の Web アプリやモバイルアプリのエンドユーザー（お客様）のサインインには、IAM ではなく Amazon Cognito を使います。IAM・Identity Center は AWS を操作する社員や仕組みのためのものです。

IAM Access Analyzer

IAM Access Analyzer は、権限の付けすぎや意図しない公開を見つけるための機能です。

• 外部アクセスの検出: S3 バケット・IAM ロール・KMS キー・Lambda 関数・SQS キューなどのリソースベースポリシーを分析し、信頼する範囲（自分のアカウントや組織）の外から使える状態のもの（パブリック公開・他アカウントへの共有）を検出します。
• 未使用のアクセスの検出: 使われていないロール、アクセスキー、パスワード、権限（サービス・操作）を見つけます。
• ポリシーの検証: ポリシーの文法やベストプラクティスに照らしてチェックし、警告や改善案を出します。
• ポリシーの生成: CloudTrail のログから実際に使った操作を調べ、それに合わせたポリシーを作ります。最小権限に絞り込むときに使います。

問題文のキーワード → 選ぶべき答え

引っかけポイント

• 「SCP で許可すれば、IAM ユーザーはその操作ができる」→ ✕。SCP は上限だけで権限を与えない。IAM 側でも Allow が必要
• 「アクセス許可の境界を付けると、その範囲の権限が与えられる」→ ✕。境界も上限だけ。アイデンティティベースポリシーとの重なった部分しか使えない
• 「別アカウントからのアクセスは、バケットポリシーで許可すれば足りる」→ ✕。リクエストする側のアカウントでも Allow が必要（両側での許可）
• 「ユーザーに直接付けた Allow は、グループに付けた Deny より優先される」→ ✕。どこに付けても明示的な Deny が最優先
• 「バケットポリシーの Principal に IAM グループを指定する」→ ✕。グループは Principal に指定できない。ユーザー・ロール・アカウントを指定する
• 「アクセスキーを EC2 の設定ファイルや AMI に入れておく」→ ✕。IAM ロールで一時的な認証情報を使う

まとめ: SAA 試験で押さえるポイント

• 評価の基本: 何も書かれていなければ拒否（暗黙の拒否）。Allow があれば許可。ただし明示的な拒否（Deny）は、どの Allow よりも優先される
• SCP とアクセス許可の境界は「上限」を決めるだけで、権限を与えない。上限の中で、ユーザーやロール側で Allow した操作だけが使える
• EC2・Lambda などから AWS を操作するときは、アクセスキーを置かずに IAM ロールを使う。一時的な認証情報が自動で更新される
• 別アカウントの人に権限を渡す → そのアカウントから引き受けられるロール（クロスアカウントロール）を作る。アクセスキーを共有しない。クロスアカウントでは両側での許可が必要
• 最小権限の原則: 必要な操作・リソースだけを許可する。ルートユーザーは日常の作業に使わず、MFA（多要素認証）を設定する
• S3 のバケットポリシーのように、リソース側に付けるリソースベースポリシーもある（同じアカウントなら、どちらか一方の Allow で許可される）
• 社員の複数アカウントへのサインインは IAM Identity Center、公開・共有や未使用の権限の洗い出しは IAM Access Analyzer