最初は AWS アカウントが1つで、メンバーごとに IAM ユーザーを作れば足りていた。ところが本番・検証・開発とアカウントを分けたら、同じ人の IAM ユーザーをアカウントの数だけ作ることになった。パスワードも MFA もアカウントごと、辞めた人を消すときは全部のアカウントを回る。気づけば、誰かの PC に何年も前に作ったアクセスキーが残っている。IAM とポリシーの評価の仕組みは分かったのに、「人をどう入れるか」で詰まる段階です。この記事は、その答えとして AWS が勧めている AWS IAM Identity Center を、何を1か所にまとめるのか → 権限をどう配るのか → 社内の ID とどうつなぐのか → IAM ユーザーと何が違うのか、の順に整理します。
この記事の結論
- AWS IAM Identity Center は、人が複数の AWS アカウントや業務アプリにサインインする入口を1か所にまとめるサービスです（旧名は AWS Single Sign-On）。
- 許可セットは権限のひな形で、ユーザーやグループとアカウントの組に割り当てると、そのアカウントに IAM ロールとして作られます。
- ユーザーの置き場（ID ソース）は、Identity Center のディレクトリ・Active Directory・外部の IdP のどれか1つを選びます。
- 外部の IdP とつなぐときは、本人確認を SAML 2.0 が、ユーザーとグループの同期を SCIM が担います。
- IAM ユーザーと違い、サインインのたびに期限つきの一時的な認証情報が渡るので、人に長期のアクセスキーを配らずに済みます。
IAM Identity Center とは何か（何を1か所にまとめるか）
たとえるなら、Identity Center は会社の社員証の発行窓口です。社員証（1つの ID）を持っていれば、各フロア（AWS アカウント）の扉を通れる。どのフロアで何をしてよいかは、窓口がまとめて決めて扉に登録しておく。辞めた人の社員証を窓口で1枚止めれば、全部のフロアの扉が閉まる。これを正確な言葉に戻すと、次の3つを1か所にまとめるサービスです。
- 人の ID（ユーザーとグループ）: ID ソースに置く
- 入口: AWS アクセスポータルという1つのサインイン画面
- 権限の配り方: 許可セットを、ユーザーやグループとアカウントの組に割り当てる
サインインしてから作業を始めるまでの流れは次のとおりです。
ONE DOOR INサインインの流れ
入口は1つ。選んだアカウントのロールで作業する
-
利用者
いつもの ID で
サインイン -
ID ソース
本人かを確かめる
-
アクセスポータル
アカウントと
許可セットを選ぶ -
一時的な認証情報
期限つきで発行
-
AWS アカウント
ロールの権限で作業
ユーザーの置き場である ID ソースは、組織に1つだけ選びます。
| ID ソース | ユーザーをどこで管理するか | 合う場面 |
|---|---|---|
| Identity Center のディレクトリ | Identity Center の中で直接作る（最初に有効にしたときの既定） | 社内に別の ID の仕組みが無い小さなチーム |
| Active Directory | 社内の AD、または AWS Managed Microsoft AD | すでに AD で社員の ID を管理している |
| 外部の IdP | Okta・Microsoft Entra ID などの IdP | すでに業務アプリのサインインを IdP でまとめている |
Identity Center は AWS アカウントだけでなく、SAML に対応した業務アプリへのサインインもまとめられます。ただ、この記事では AWS アカウントへの入り方に絞ります。
許可セットとは（アカウントごとに何を配るか）
許可セットは、1つ以上の IAM ポリシーをまとめた「権限のひな形」です。AWS の管理ポリシー（ReadOnlyAccess など）を入れても、自分で書いたポリシーを入れてもかまいません。ひな形を作っただけでは、どのアカウントでも使われていません。
使えるようになるのは、「誰に（ユーザーかグループ）」「どのアカウントで」「どの許可セットを」の3つを組にして割り当てたときです。割り当てると、Identity Center はそのアカウントに AWSReservedSSO_ で始まる名前の IAM ロールを作り、許可セットのポリシーを付けます。利用者はサインインのたびにこのロールを引き受けて作業します。許可セットを直すと、割り当て済みのアカウントのロールも Identity Center が揃えて更新します。
| 部品 | 中身 | たとえ |
|---|---|---|
| ユーザー・グループ | 人の ID。ID ソースに置く | 社員と部署 |
| 許可セット | ポリシーをまとめた権限のひな形 | 「閲覧だけ」「開発者」のような役割の定義 |
| 割り当て | 誰に × どのアカウントで × どの許可セットを | 「開発部は検証フロアで開発者として入れる」という登録 |
| アカウントの中のロール | 割り当てから Identity Center が作る IAM ロール | 実際にフロアの扉に登録された鍵 |
権限はグループに割り当てるのが基本です。人が異動したら、グループの所属を変えるだけで入れるアカウントと権限がまとめて変わります。1人ずつアカウントを回って IAM ユーザーを直す必要がありません。
READ ALSO — 未経験向け・段1 入口
IAM ポリシーの評価の仕組み｜許可と拒否はどの順で決まるか
許可セットで付けた権限も、IAM ポリシーの評価の仕組みの中で判定されます。組織の SCP で拒否されている操作は、許可セットで許可しても実行できません（SCP は管理アカウントには効かない点は別に覚えておきます）。許可セットは「このアカウントで何をしてよいか」、SCP は「組織として何をさせないか」という役割の分担です。
なお、許可セットは AWS Organizations と組み合わせた組織のインスタンスの機能です。Organizations を使わないアカウントのインスタンスには許可セットが無く、AWS アカウントへのアクセスには使えません。
CHECK 1ここまでの確認
Identity Center でいう「許可セット」の説明として正しいのはどれ?
答えと解説
答え: 2. 権限のひな形で、アカウントに割り当てると、そのアカウントに IAM ロールとして作られる
許可セットはポリシーをまとめた「権限のひな形」です。ユーザーやグループとアカウントの組に割り当てると、Identity Center がそのアカウントにロールを作ります。上限を決めるのは SCP の役目です。「許可セットとは」の章を読み直してください。
外部の IdP とつなぐとは（社内の ID をそのまま使う）
多くの会社では、メールやチャットや業務アプリのサインインを、Okta や Microsoft Entra ID などの IdP（ID プロバイダー）でまとめています。Identity Center の ID ソースを外部の IdP にすると、社員はいつもの ID で AWS アクセスポータルに入れます。このとき、2つの別の仕組みが働きます。
| 仕組み | 何をするか | 止まるとどうなるか |
|---|---|---|
| SAML 2.0 | サインインのたびに「この人は本人か」を IdP が確かめ、結果を Identity Center に渡す（認証） | サインインできない |
| SCIM | IdP のユーザーとグループを Identity Center に自動で作り・直し・消す（プロビジョニング） | 入社・異動・退職が Identity Center に届かず、手で揃えることになる |
SAML だけでもサインインはできますが、ユーザーやグループが Identity Center 側に無いと、許可セットを割り当てる相手がいません。SCIM で同期しておけば、IdP で退職の処理をした時点で、AWS へのサインインもできなくなります。ID の入口と出口を1か所に寄せられるのが、外部 IdP と組み合わせる一番の利点です。
IdP の属性（部署やプロジェクトなど）を AWS のセッションに渡し、リソースのタグと照らし合わせて許可を決める使い方（属性ベースのアクセス制御）もあります。許可セットの数を増やさずに済む方法ですが、まずは「グループに許可セットを割り当てる」形を理解してからで十分です。
CHECK 2ここまでの確認
社内ですでに使っている IdP のアカウントで AWS に入れるようにするとき、ユーザーとグループを自動で揃える仕組みはどれ?
答えと解説
答え: 1. SCIM による自動プロビジョニング
認証（本人かどうか）は SAML 2.0、ユーザーとグループの同期は SCIM が担います。「外部の IdP とつなぐとは」の章を読み直してください。
IAM ユーザーとは何が違うのか（長期のアクセスキーを持たせない理由）
IAM ユーザーも Identity Center のユーザーも「人が AWS に入るための ID」ですが、置き場所と認証情報の性質が違います。
USER VS IDENTITY人の入り方の違い
人の ID は1か所に置き、期限つきの鍵で入る
IAM ユーザー
アカウントごとに作る
- アカウントの数だけ作る同じ人が何人分にもなる
- 長期のアクセスキー期限が無く、漏れたら止めるまで使える
- 退職者は全アカウントで削除消し忘れが残りやすい
Identity Center のユーザー
ID ソースに1回だけ
- 許可セットをアカウントに割り当てグループ単位で配る
- 一時的な認証情報サインインのたびに期限つきで発行
- 退職者は ID ソースで1回止める全アカウントの入口が閉じる
| IAM ユーザー | Identity Center のユーザー | |
|---|---|---|
| どこに作るか | アカウントごと | ID ソースに1回だけ |
| 権限の付け方 | ユーザーやグループにポリシーを付ける | 許可セットをアカウントごとに割り当てる |
| CLI で使う認証情報 | 長期のアクセスキー（期限なし） | サインインのたびに発行される一時的な認証情報 |
| 退職者の対応 | 全アカウントの IAM ユーザーを消す | ID ソースで1回止める |
| 向いている相手 | 人ではない仕組みで、どうしても長期の鍵が要る場合に限る | 人（従業員・委託先） |
長期のアクセスキーの何が問題か
長期のアクセスキーには期限がありません。PC の設定ファイル、スクリプト、うっかり公開したリポジトリに残れば、誰かが失効させるまで使い続けられます。定期的に作り直す運用を決めても、アカウントと人の数が増えるほど回らなくなります。
AWS の IAM のベストプラクティスは、人には ID プロバイダーとのフェデレーションを使い、一時的な認証情報で AWS に入らせることを求めています。Identity Center はその形をそのまま実現する仕組みで、AWS CLI（バージョン2）も Identity Center でサインインして一時的な認証情報を受け取れます。
人の入り方でやってはいけない3つ
- 同じ IAM ユーザーやアクセスキーを複数の人で使い回す（誰が操作したか追えない）
- アクセスキーをコードや設定ファイルに書いてリポジトリに入れる
- アカウントごとに IAM ユーザーを作り、退職者の削除を人の記憶に頼る
アプリケーションや EC2 の上のプログラムが AWS を呼ぶときは、人ではないので Identity Center ではなく IAM ロール（EC2 ならインスタンスプロファイル）を使います。「人は Identity Center、仕組みはロール」と分けておくと、長期のアクセスキーが要る場面はほとんど残りません。
CHECK 3ここまでの確認
人に長期のアクセスキーを配らない方がよい一番の理由はどれ?
答えと解説
答え: 2. 漏れたときに、失効させるまで誰でも使い続けられるから
長期のアクセスキーには期限が無く、漏れれば止めるまで使われます。Identity Center は、サインインのたびに期限つきの一時的な認証情報を渡します。「IAM ユーザーとは何が違うのか」の章を読み直してください。
まとめ
- IAM Identity Center は、人の ID・サインインの入口・権限の配り方を1か所にまとめ、複数のアカウントへのサインインを1つにします。
- 許可セットは権限のひな形で、「誰に × どのアカウントで × どの許可セットを」の割り当てから、各アカウントに IAM ロールが作られます。
- ID ソースは1つだけ選び、外部の IdP とつなぐなら認証を SAML 2.0、同期を SCIM に任せます。
- IAM ユーザーと違い、サインインのたびに期限つきの認証情報が渡るので、人に長期のアクセスキーを配らずに済みます。
- 次は、アカウントを境界として分け、Organizations と SCP でガードレールを引くマルチアカウント設計へ進んでください。
参照ソース
- What is IAM Identity Center?（AWS IAM Identity Center User Guide） — サービスの役割と、複数アカウント・アプリへのサインインをまとめることの根拠（2026-09 時点の記載）
- Manage AWS accounts with permission sets（AWS IAM Identity Center User Guide） — 許可セットの定義と、割り当てると各アカウントにロールが作られることの根拠（2026-09 時点の記載）
- IAM roles created by IAM Identity Center（AWS IAM Identity Center User Guide） — AWSReservedSSO_ で始まるロールの根拠（2026-09 時点の記載）
- Manage your identity source（AWS IAM Identity Center User Guide） — ID ソースの3種類と、組織に1つだけ選ぶことの根拠（2026-09 時点の記載）
- Organization and account instances of IAM Identity Center（AWS IAM Identity Center User Guide） — 組織のインスタンスとアカウントのインスタンスの違い、アカウントのインスタンスに許可セットが無いことの根拠（2026-09 時点の記載）
- External identity providers（AWS IAM Identity Center User Guide） — 外部 IdP との連携が SAML 2.0 で認証することの根拠（2026-09 時点の記載）
- Security best practices in IAM（AWS Identity and Access Management User Guide） — 人にはフェデレーションと一時的な認証情報を使わせるという推奨の根拠（2026-09 時点の記載）
- AWS IAM Identity Center FAQs — 追加料金なしで提供されていることの根拠（2026-09 時点の記載。この環境から直接は開けず、検索結果の抜粋で確認）
