導入
アカウントが数十になると、「各アカウントに個別のIAMユーザーを作る」というやり方は破綻します。人が入退社するたびに数十アカウント分のユーザーを作成・削除するのは非現実的です。組織全体で1回サインインすれば、必要なアカウントに必要な権限だけでアクセスできる仕組みが必要です。
説明
AWS IAM Identity Center（旧称 AWS SSO）は、AWS Organizations配下の全アカウントへの 一元的なシングルサインオン（SSO） を提供するサービスです。
社員のID管理は、多くの企業ではすでに Active Directory（AD） や Okta / Azure AD などの外部IdP（IDプロバイダー） で行われています。IAM Identity Centerは、これらの既存のIDソースと SAML 2.0 で連携し、「新しくIDを作り直す」のではなく「既存のIDをそのまま使う」ことができます。
flowchart LR
U["社員"] -- サインイン --> IDP["社内AD / Okta等<br/>（外部IdP）"]
IDP -- SAML --> IC["IAM Identity Center"]
IC -- "権限セットを適用" --> A1["アカウントA"]
IC -- "権限セットを適用" --> A2["アカウントB"]
IC -- "権限セットを適用" --> A3["アカウントC"]
権限の割り当てには 権限セット（Permission Set） という単位を使います。権限セットはIAMポリシーの集合をテンプレート化したもので、「どのユーザー／グループに」「どのアカウントで」「どの権限セットを」割り当てるかをマトリクスで管理します。実体としては、割り当てられたアカウントに自動的にIAMロールが作成される仕組みです。
| 概念 | 役割 |
|---|---|
| IDソース | 誰がユーザーか（AD/Okta/Identity Center自体のディレクトリ） |
| 権限セット | どんな権限を持つか（テンプレート化されたIAMポリシー） |
| 割り当て | どのユーザー/グループが、どのアカウントで、どの権限セットを持つか |
具体例
40個のAWSアカウントを持つ企業で、社員の入退社が起きるたびの運用を比べます。
IAMユーザーを各アカウントに作る場合：新入社員1人につき、必要な40アカウント分のIAMユーザーを作成。退職時には40個を確実に削除しないと、消し忘れたユーザーが不正アクセスの穴になる。人事異動のたびにこれを繰り返す——破綻します。
IAM Identity Center＋既存ADの場合：
- 社員は普段の社内ID（Active Directory）でサインインするだけ。新しいIDは作らない
- 入社時はAD側でグループに追加すれば、対応する権限セットが割り当たったアカウントに自動でアクセスできる
- 退職時はAD側で1回無効化すれば、全アカウントのアクセスが一括で止まる（消し忘れの穴が生じない）
- 「誰が・どのアカウントで・どの権限セットを持つか」をマトリクスで一元管理
「多数アカウントへの社員アクセスを一元管理」「既存ADを活かす」と来たら、ほぼIAM Identity Centerが正解。「アカウントごとにIAMユーザーを作る」選択肢は、大規模では運用破綻するので誤りと判断できます。
読んでみよう
「多数のAWSアカウントに対する社員のアクセスを一元管理したい」「既存のActive Directoryを活かしたい」という要件は、ほぼ確実にIAM Identity Centerが正解です。「アカウントごとにIAMユーザーを作る」という選択肢が出てきたら、大規模組織では運用が破綻するため誤りだと判断してよいでしょう。