グローバル製造業企業が競合他社を買収しました。買収先企業は独自の AWS 環境（40 アカウント）を保有しており、両社ともに Azure Active Directory (Azure AD) を既存のオンプレミス ID プロバイダーとして使用しています。統合後の AWS 環境に関して以下の要件が定められました。 ・全 AWS アカウント（将来的に 100 アカウント超が見込まれる）への Single Sign-On を Azure AD の既存ユーザーアカウントおよびグループで実現すること ・AWS へのすべての人的アクセスは一時的な認証情報を使用すること（長期 IAM ユーザー認証情報の使用を禁止） ・職務別（開発者・インフラ運用担当者・読み取り専用監査担当者）に異なるアクセス権限を全 AWS アカウントに適用すること ・IAM ロールの権限昇格を組織全体で防止すること ・EC2 インスタンスや ECS タスクなどのアプリケーションに、サービスアカウントのパスワードや長期的な認証情報をコード内に埋め込んではならないこと ・すべての人的アクセスおよびアプリケーション API 操作を中央集権的な監査ログに記録すること 最小限の運用オーバーヘッドで上記すべての要件を満たすソリューションはどれか。
AWS IAM Identity Center（旧 AWS SSO）は、AWS Organizations 全体への中央集権的なシングルサインオンとアクセス管理を提供します。Azure AD との統合では SAML 2.0 で認証し、SCIM（System for Cross-domain Identity Management）プロビジョニングにより Azure AD のユーザーとグループを IAM Identity Center に自動同期することで、新規アカウント追加時のオンボーディング作業を最小化できます。 許可セット（Permission Sets）は複数アカウントに同一の権限定義を一括適用する仕組みです。Permission Boundary を許可セットに設定することで、フェデレーションユーザーが新規 IAM ロールを作成しても境界を超えた権限昇格を防止できます。EC2 インスタンスプロファイルと ECS タスクロールにより一時的な認証情報が自動提供され、Secrets Manager で外部認証情報を動的取得することでコードへのハードコードを排除します。Organizations レベルの CloudTrail トレイルは全メンバーアカウントを自動カバーするため、アカウント追加後も監査設定の変更が不要です。 選択肢Bの各アカウント個別 SAML IdP 設定は、40 アカウントへの個別設定が必要で将来のアカウント追加のたびに繰り返しの手動作業が発生し、IAM Identity Center の一元管理の恩恵を受けられないため運用オーバーヘッドの最小化要件を満たさない。 選択肢Cのクロスアカウント IAM ロール手動プロビジョニングは、アカウント数増加に伴い管理コストが増大し、Permission Boundary の手動アタッチは適用漏れのリスクが高い。IAM Identity Center を経由しないため職務別アクセス権限の一元管理が実現できない。 選択肢Dの許可セット内 SCP 設定は技術的に誤りである。SCP（Service Control Policies）は AWS Organizations のポリシーであり、OU またはアカウントレベルで適用するものであって、IAM Identity Center の許可セット（Permission Sets）に直接組み込む機能は存在しない。