AWS IAM Identity Center で実現するシングルサインオン - マルチアカウントアクセス管理

IAM Identity Center の概要

IAM Identity Center (旧 AWS SSO) はマルチアカウント環境のシングルサインオンとアクセス管理を一元化するサービスです。ユーザーは AWS アクセスポータルにログインし、割り当てられた AWS アカウントとアプリケーションにワンクリックでアクセスします。アカウントごとに IAM ユーザーを作成する必要がなくなり、認証情報の散在によるセキュリティリスクを根本的に排除します。Organizations の管理アカウントで有効化し (インスタンスは常に管理アカウントに置かれ、委任管理者アカウントは有効化後の管理作業を担う)、組織内の全アカウントに対してアクセス制御を一括で適用できます。サードパーティアプリケーションとの連携プロトコルは SAML 2.0 のみで、Salesforce、Slack、GitHub などの SAML 対応アプリへフェデレーションアクセスを提供します。OIDC だけに対応するアプリケーションは Identity Center のアプリ連携先にはできません。OIDC が使われるのは、AWS CLI v2 や SDK がアクセスポータル経由で一時的な認証情報を取得するデバイス認証フローの側であり、アプリ連携の選択肢とは役割が異なります。AWS マネジメントコンソール、CLI v2、SDK へのアクセスはいずれもアクセスポータルからの認証で統一されます。

ID ソースの選択と外部 IdP 連携

IAM Identity Center は 3 つの ID ソースをサポートします。1 つ目は Identity Center ディレクトリ (組み込み) で、小規模な組織や検証環境に適しています。2 つ目は Active Directory (AWS Managed Microsoft AD または AD Connector 経由) で、オンプレミスの AD をそのまま利用できます。3 つ目は外部 IdP で、SAML 2.0 で認証を委任し、SCIM 2.0 でユーザーとグループの自動プロビジョニングを実行します。Okta、Microsoft Entra ID (旧 Azure AD)、Google Workspace、OneLogin、Ping Identity が SCIM による自動同期に対応しており、IdP 側でユーザーの追加・削除・グループ変更を行うと、その内容が IAM Identity Center へ自動的に反映されます。ただし反映は即時ではなく、IdP 側のプロビジョニング周期に依存するため、設定によっては数十分の遅延が生じます。IdP 側でユーザーを無効化すれば同期後に AWS へのアクセスも遮断されるため、退職者のアカウント削除漏れによるセキュリティリスクを構造的に減らせます。即時に遮断したい場合は IdP 側で手動同期を実行します。

権限セットとアクセス割り当て

権限セットは IAM ポリシーのコレクションで、AdministratorAccess、ReadOnlyAccess などの AWS マネージドポリシー、カスタムポリシー (JSON 形式で直接記述)、およびカスタマーマネージドポリシーの参照を含めます。1 つの権限セットには最大 10 個のマネージドポリシーと 1 つのインラインポリシーを設定可能です。権限セットをユーザー/グループとアカウントの組み合わせに割り当てると、そのユーザーがアカウントにアクセスした際に対応する IAM ロールが自動作成されます。パーミッションバウンダリも設定でき、権限セットの上限を IAM ポリシーで制約することで最小権限原則を強制します。アクセス割り当ては権限セット × AWS アカウント × ユーザーまたはグループの 3 要素で定義し、グループベースの割り当てによりメンバーの追加・削除時にグループへの所属変更だけで権限が自動反映されます。

ABAC とセッション管理

IAM Identity Center は属性ベースのアクセス制御 (ABAC) をサポートし、ユーザー属性 (部門、役職、プロジェクト、コストセンター) に基づいてアクセス権限を動的に付与します。IdP から渡される SAML 属性を IAM セッションタグにマッピングし、リソースタグとの一致でアクセスを制御します。たとえば department=engineering のユーザーは department=engineering タグを持つ S3 バケットにのみアクセスできる、という制御をアカウント横断で適用可能です。セッション時間は権限セットごとに 1〜12 時間で設定でき、高セキュリティ環境では短いセッション (1 時間) を、開発環境では長いセッション (12 時間) を設定します。AWS アクセスポータルからワンクリックでマネジメントコンソールや CLI にアクセスでき、アカウントの切り替えが容易です。

# AWS CLI v2 での SSO プロファイル設定例 (~/.aws/config)
[profile dev-admin]
sso_session = my-sso
sso_account_id = 123456789012
sso_role_name = AdministratorAccess
region = ap-northeast-1
[sso-session my-sso]
sso_start_url = https://my-org.awsapps.com/start
sso_region = ap-northeast-1
sso_registration_scopes = sso:account:access
# SSO ログイン実行
aws sso login --profile dev-admin

CLI v2 の sso login コマンドでブラウザベースの認証フローが起動し、認証完了後は一時的な認証情報が自動的にキャッシュされます。長期アクセスキーの管理が不要になり、セキュリティが向上します。

設計のベストプラクティスと落とし穴

権限セットの設計では「職務ごとに 1 権限セット」の原則を守り、1 人のユーザーに複数の権限セットを割り当てて職務分離を実現します。たとえば開発者には DevOps 権限セット (デプロイ用) と ReadOnly 権限セット (監査用) を用意し、本番環境と開発環境で異なる権限セットを割り当てるパターンが効果的です。よくある落とし穴として、SCIM 同期の遅延があります。IdP 側のグループ変更が Identity Center に反映されるまでのラグ (IdP のプロビジョニング周期に依存し、設定によっては数十分) の間、古い権限でのアクセスが残る可能性があるため、権限昇格を伴う変更では手動同期を実行すべきです。もう 1 つの注意点は委任管理者の設定です。管理アカウント以外から Identity Center を運用する場合は委任管理者アカウントを指定しますが、委任管理者にできない操作は「管理アカウントに対する操作」を中心に定められています。具体的には (1) Identity Center 設定そのものの削除 (2) 別アカウントへの再委任 (3) 管理アカウントに対するユーザー・グループのアクセス割り当て管理 (4) 管理アカウントにプロビジョニング済みの権限セットの変更、の 4 点です。委任管理者アカウント自身への権限セット割り当てが禁じられているわけではないので、制約の対象を取り違えないことが重要です。組織との対応関係では、1 つの Organizations に対して有効化できる組織インスタンスは 1 つだけです。これとは別枠で、単一アカウント内で使うアカウントインスタンスを作成できますが、こちらは権限セットに対応しないため、マルチアカウントのアクセス管理には組織インスタンスを使います。リージョンについては、かつては 1 リージョンに固定される仕様でしたが、現在はプライマリリージョンから追加リージョンへのレプリケーションに対応しています (2026 年 8 月時点の公式ドキュメント記載値で、プライマリを含め合計 6 リージョンまで・引き上げ申請可)。追加リージョンにもアクセスポータルのエンドポイントが作られるため、地理的に分散した組織でのレイテンシと可用性を改善できます。ただしユーザー・グループ・権限セット・外部 IdP 設定の変更はプライマリリージョンで行い、追加リージョンへは非同期でレプリケートされる片方向の構成です。プライマリリージョンの昇格・降格や単独削除はできず、有効化にはマルチリージョン対応のカスタマー管理 KMS キー (追加リージョンごとのレプリカキー) が前提になるため、プライマリリージョンをどこに置くかは依然として重要な設計判断です。

Cognito との使い分けと他の認証方式

IAM Identity Center と Cognito はどちらも認証サービスですが、対象ユーザーが異なります。IAM Identity Center は従業員・開発者が AWS マネジメントコンソールや CLI にアクセスするための認証基盤であり、Cognito は Web/モバイルアプリケーションのエンドユーザー (顧客) 向けの認証・認可サービスです。Cognito はサインアップ、ソーシャルログイン、トークン管理を提供し、IAM Identity Center は AWS アカウントへのフェデレーションアクセスに特化しています。他のマルチアカウント管理手段としては、アカウントごとに IAM ユーザーを作成する方式 (認証情報が散在し運用負荷が高い)、IAM ロールのクロスアカウント AssumeRole (数十アカウント規模で管理が困難)、サードパーティ SSO 製品 (アカウント追加ごとに IdP 設定変更が必要) がありますが、IAM Identity Center は Organizations との深い連携でこれらの課題を統合的に解決します。CloudTrail との統合により、誰がいつどのアカウントにアクセスしたかの監査ログも自動記録されます。

IAM Identity Center の料金

IAM Identity Center は無料で利用できます。ユーザー数、グループ数、SSO セッション数に対する追加料金は発生しません。外部 IdP (Okta、Microsoft Entra ID、Google Workspace) との SAML/SCIM 統合も無料です。コストは Identity Center が管理する AWS アカウントやアプリケーションの利用料金に依存します。Identity Center 自体のサービスクォータは、2026 年 8 月時点の公式ドキュメント記載値でリージョンあたりのユーザー数が 200,000、グループ数が 100,000、権限セット数が 3,500、1 つの AWS アカウントにプロビジョニングできる権限セット数が 500 です。いずれも Service Quotas から引き上げを申請できる調整可能クォータで、設定できる AWS アカウント数とアプリケーション数もそれぞれ既定 7,000 と十分な余裕があります。一方、1 つの権限セットに対して 1 アカウントあたり割り当てられるグループ数の上限 100 は調整不可なので、大規模組織ではグループ設計の段階でこの上限を意識します。Organizations の全アカウントで IAM Identity Center を有効化し、IAM ユーザーの直接作成を廃止することで、セキュリティと運用効率を同時に向上させます。

まとめ

IAM Identity Center はマルチアカウント環境の SSO とアクセス管理を無料で一元化するサービスです。3 つの ID ソース (組み込みディレクトリ、Active Directory、外部 IdP) から環境に適した方式を選択し、権限セットで AWS マネージドポリシーとカスタムポリシーを組み合わせたアクセス権限を定義します。ABAC でユーザー属性に基づく動的な権限付与を行い、CLI v2 の SSO プロファイルでターミナルからもシームレスに認証します。権限セットは職務単位で設計し、委任管理者が管理アカウントに対して行えない操作の範囲と、プライマリリージョンと追加リージョンの役割分担を事前に把握した上で導入を進めることが重要です。