AWS IAM アイデンティティ：パーミッションバウンダリ、フェデレーション、STS、アクセスツール

SysOps / CloudOps の試験で繰り返し出る アイデンティティとアクセス：有効な権限 が SCP、パーミッションバウンダリ、ID ベースポリシーでどう組み合わさるか；クレデンシャル衛生と最小権限のための IAM 運用ツール；IAM Access Analyzer による外部アクセス検出；AWS STS による一時認証情報；エンタープライズと公開アプリのフェデレーション；本番変更前のポリシーシミュレーション。

同コレクションの関連記事：AWS Security, Compliance, Encryption, and Secrets for CloudOps（KMS、Secrets Manager、Security Hub など）。

IAM パーミッションバウンダリ

• IAM ユーザーとロールのみ対象 — IAM グループは対象外。
• パーミッションバウンダリはマネージドポリシーで、エンティティが受け取れる権限の上限を設定する。それ自体ではアクセスを付与しない。
• プリンシパルの有効な権限は次の積（および該当するリソースポリシー・SCP）：
  • ID ベースポリシーが許可するもの
  • パーミッションバウンダリが許可するもの（どちらかに明示 deny があれば除外）

コースのモデル： バウンダリが s3:*、cloudwatch:*、ec2:* だけに許可し、ID ポリシーが iam:CreateUser を許可しても、CreateUser はバウンダリ外なので効かない。

Organizations SCP との関係

可能性を狭める三層：

1. サービスコントロールポリシー（SCP） — 組織／OU／アカウントのガードレール（単体ではプリンシパルに権限を与えない）。
2. パーミッションバウンダリ — そのユーザー／ロールがいつまでも持てる上限。
3. ID ベースポリシー — 実際に意図した許可。

実効アクセスは、適用される制約がすべて重なるところ。パーミッションバウンダリはSCPに近い考え方：外側の上限；ID ポリシーがその内側の実際の allow。

代表的な用途

• 非管理者に IAM 管理（ユーザー作成やポリシーアタッチ）を委譲しつつフル管理者への昇格を防ぐ — バウンダリが禁止サービス／アクションをブロック。
• 開発者が自分で一部ポリシーを付与しつつ、バウンダリを超えた権限昇格を防ぐ。
• アカウント全体の SCP を変えず特定のユーザー／ロールだけを締める。
• 組織ポリシーを広げる前に、テストプリンシパルにSCP 風の上限をバウンダリで試す。

IAM クレデンシャルレポート（アカウント範囲）

• アカウント単位のレポート：IAM → Credential report → ダウンロード（CSV）。
• アカウント内の全 IAM ユーザー（コースではルートも含む場合）とクレデンシャルメタデータ：
  • ユーザー作成時刻
  • パスワードの有効／最終利用／最終変更；ローテーション設定時の期待
  • MFA の状態
  • アクセスキー：有無、ローテーションと最終利用
  • 署名証明書など（コースの CSV の列）

セキュリティレビューに利用：古いパスワード、MFA 未設定、古いアクセスキー、フォローアップが必要なアカウント。

IAM Access Advisor（ユーザー／ロール／グループ範囲）

• コンソールでプリンシパルごと：ユーザー（またはロール／グループの同等エントリ）を開く → Access Advisor／Last accessed。
• プリンシパルが使える AWS サービスと、各サービスの最終アクセス時刻（レポート期間内の API またはコンソール活動）。
• 最小権限の支援：未使用のサービス権限を特定しポリシーを縮小。
• ドリルダウン： サービス（例：EC2）ごとに、どのポリシー（例：AdministratorAccess）がそのサービスへのアクセスを与えたか表示され、ポリシーが多いときに有用。

IAM Access Analyzer

• 目的： 定義した信頼ゾーンの外のプリンシパルと共有されているリソースを見つける（意図しない外部やクロスアカウント露出）。
• コースで挙がるリソースタイプ：S3 バケット、IAM ロール、KMS キー、Lambda 関数とレイヤー、SQS キュー、Secrets Manager シークレット（最新の対応は AWS ドキュメントで確認）。
• 信頼ゾーン（例：この AWS アカウントまたはOrganization 全体）を定義し、アクセスがそのゾーンを超えるとfinding（別アカウント、匿名／パブリックプリンシパルなど）。
• アナライザーを有効化するとサービスリンクロールが作成される。コースでは有効化は無料の説明 — 継続料金は要確認。
• Finding のライフサイクル：
  • Active — ポリシーがまだ一致
  • Resolved — ポリシーを修正（例：SQS で Principal: * を削除）；再スキャンで確認
  • Archived — リスクを受容（例：S3 を意図的に公開）

AWS Security Token Service（STS）

• STS は短命の認証情報（access key ID、secret、session token）を発行する。
• 有効期間： 設定可能（コースは約 1 時間やそれ以上など — 最大セッション時間はフローとロール設定で確認）。
• よく使う API：
  • AssumeRole — 同一または別アカウントのIAM ロール用；クロスアカウント、セッション昇格、AssumeRole を包むフェデレーション。
  • AssumeRoleWithSAML — エンタープライズ IdP の SAML アサーションと一時認証情報を交換（信頼と SAML プロバイダ設定後）。
  • AssumeRoleWithWebIdentity — OIDC／web identity トークンと交換；新規アプリは多くの場合 Cognito 利用が推奨。
  • GetSessionToken — MFA 検証後の一時認証情報（IAM ユーザーまたはルート — コースの枠組み）。
• クロスアカウント（試験で定番）：
  1. アカウント B（例：本番）でリソース（例：S3）への権限と、アカウント A（例：開発）に sts:AssumeRole を許可する信頼ポリシーを持つIAM ロールを作成。
  2. アカウント A で、そのロール ARN への sts:AssumeRole をプリンシパルに付与。
  3. A のユーザーが AssumeRole を呼ぶ → 一時認証情報を取得 → B のロールとして API を呼ぶ。

B の信頼と A の** assume 許可の両方**がなければ AssumeRole は失敗。

アイデンティティフェデレーション（概要）

フェデレーションでは、ユーザーは AWS に長寿命 IAM ユーザーを持たず、外部で認証してから一時の AWS 認証情報を得る（多くの場合 STS とロール）。

SAML 2.0（エンタープライズ）

• ADFS、Azure AD など SAML 2.0 IdP が一般的。
• ユーザーが IdP で認証 → SAML アサーション → AssumeRoleWithSAML（CLI/SDK）またはコンソール連携エンドポイント。
• メリット： 従業員ごとの長期 IAM ユーザー不要；ロールベースで一時アクセス。

カスタムアイデンティティブローカー（非 SAML）

• SAML 2.0 がない場合、カスタムブローカーアプリが：
  • 社内アイデンティティストアでユーザーを認証し、
  • 特権を持つブローカー認証情報で STS を呼び、ユーザーごとに調整したポリシーの一時認証情報を発行。
• SAML ネイティブより手間だが、同じ流れ：外部 ID → ブローカー → STS → 一時 AWS アクセス。

Amazon Cognito（Web／モバイル）

• Web／モバイルユーザー（例：S3 へのアップロード、Facebook／Google／Cognito User Pools／SAML／OIDC）：
  • アプリが IdP で認証 → トークン取得 → Cognito Identity Pool がトークンを検証し STS を呼び → Identity Pool でマッピングした IAM ロールでスコープされた一時認証情報をアプリが受け取る。
• 新規アプリでは Cognito なしの素の Web Identity フェデレーションは推奨されにくい — 公開アプリのフェデレーションは試験では Cognito が答えになりやすい。

IAM ポリシーシミュレータ

• 目的： 本番を広く変えずに、あるプリンシパルが特定リソースに対して許可／拒否されるかをテスト・トラブルシュート。
• IAM コンソールから（URLはドキュメントの「IAM Policy Simulator」を参照）。
• 取り込めるもの：
  • ユーザー／グループ／ロールの ID ベースポリシー
  • リソースベースポリシー（例：S3 バケットポリシー）
  • パーミッションバウンダリ
  • Organization に入っているアカウントでは SCP（コースのデモではシミュレータが SCP を反映）
• サービスとアクションを選びシミュレーションし、allow／暗黙の deny と一致したステートメント（またはなし）を確認。

要点

• パーミッションバウンダリはユーザーとロールのみ；上限を設定；ID ポリシーと SCP と交差する制約として扱う。
• Credentials Report = アカウント全体の CSV クレデンシャル一覧；Access Advisor = プリンシパルごとのサービス最終アクセス（最小権限用）。
• Access Analyzer = 信頼ゾーン対外部アクセスの finding；ポリシー修正で解決、受容ならアーカイブ。
• STS = 一時認証情報；AssumeRole（ロール・クロスアカウント）；AssumeRoleWithSAML（エンタープライズ SAML）；GetSessionToken（MFA）；web identity は Cognito 中心に。
• フェデレーション = 外部 IdP → トークン／アサーション → STS（直接または Cognito）→ 一時 AWS アクセス；SAML 以外はカスタムブローカー。
• ポリシーシミュレータ = ID／リソース／バウンダリ／SCP をまたぐ安全な what-if。

---

🌐 Claudeによる翻訳