エンタープライズの認証統合設計 IAM Identity Center とフェデレーションで入口を一本化する

マルチアカウント環境で最初につまずくのが「誰がどのアカウントに、どの権限で入るのか」です。SAP-C02 では、既存の社内IDを活かしながらIAMユーザーを増やさずにアクセスを統制する設計が繰り返し問われます。この記事では、要件文のどの言葉がどの構成を指しているのかを読み解けるようにします。

覚え方は「集約・委任・一時」の3つの観点

認証統合の設計は次の3点に分解すると迷いません。集約＝IDの持ち主を1か所にする、委任＝アカウントごとの権限はロールで渡す、一時＝long-lived なアクセスキーを作らず一時認証情報にする。要件文に「既存のActive Directoryを使いたい」「アクセスキーの棚卸しが大変」とあれば、この3点のどれかが崩れているサインです。

IAM Identity Center を中心に据える

IAM Identity Center は、外部IdP（Microsoft Entra ID、Okta など）や AWS Managed Microsoft AD を ID ソースにでき、許可セット（Permission Set）を「どのアカウントのどのグループに割り当てるか」という形で一元管理します。200アカウントで部門ごとに権限を配りたい、退職時に1か所の削除で全アカウントの権限を止めたい、という要件ならこれが第一候補です。CLI 用の一時認証情報も発行されるため、アクセスキーの長期発行をやめられます。

SAML フェデレーションと Roles Anywhere の使いどころ

Identity Center を導入できない事情（既存のSAMLアサーション属性をそのまま使いたい等）がある場合は、IAM の SAML 2.0 IDプロバイダーを登録し、AssumeRoleWithSAML でロールを引き受ける従来型のフェデレーションを使います。一方、データセンターのサーバーやCI実行機など、AWS外のワークロードに一時認証情報を渡したい場合は IAM Roles Anywhere が適します。X.509証明書を信頼アンカーとして登録し、証明書ベースで一時クレデンシャルを取得させる仕組みです。

チェックリスト

• IAM Identity Center の許可セットとグループ割り当ての流れを説明できる
• 外部IdP連携で AssumeRoleWithSAML が使われる場面を説明できる
• 従業員向け（Identity Center）と一般利用者向け（Cognito）を区別できる
• クロスアカウントロールの信頼ポリシーで外部IDを使う理由を説明できる
• AWS外ワークロードに Roles Anywhere を選ぶ判断ができる

まとめ

認証統合は「集約・委任・一時」で整理し、従業員向けと利用者向けを取り違えないことが得点源です。 理解度の確認にはクイズが便利です。試験範囲や申し込みの最新情報はAWS認定 公式ページもあわせて確認してください。