ある大手保険会社が AWS Organizations で管理するマルチアカウント環境に、新たにパートナー企業のアカウントをゲストとして参加させる必要があります。パートナーは特定の共有サービス（S3 バケット、API Gateway）にのみアクセス可能とし、他のリソースへのアクセスは一切禁止する必要があります。また、パートナーアカウントを完全に制御下に置くことなく、最小権限を確保したいと考えています。最も適切なアーキテクチャはどれですか？
- A. パートナーアカウントを Organizations に招待せず、クロスアカウント IAM ロールを作成して特定の S3 バケットと API Gateway のみへのアクセスを許可する。リソースベースポリシーでパートナーのアカウント ID を明示的に許可する
- B. パートナー企業を Organizations のメンバーアカウントとして招待し、SCP で許可するサービスを制限する
- C. パートナー企業の担当者に IAM ユーザーを自社アカウントに作成し、必要なリソースへの IAM ポリシーを付与する
- D. AWS PrivateLink を使用して S3 バケットと API Gateway のエンドポイントをパートナーの VPC に公開し、ネットワークレベルでアクセスを制限する
解答と解説を見る
正解: A
パートナー企業を Organizations のメンバーとして招待することなく、クロスアカウント IAM ロールとリソースベースポリシーを使う方法が最も適切です。これにより Organizations のガバナンス構造を変更せずに最小権限アクセスを提供でき、パートナーアカウントへの制御権も不要です。 B: パートナーを Organizations のメンバーとして招待すると、SCP の管理対象となり、自社の組織ポリシーがパートナーアカウント全体に適用されます。これはパートナーの独立性を侵害し、双方のガバナンスに問題が生じます。 C: 自社アカウントに IAM ユーザーを作成することはセキュリティリスクが高く、パートナーの認証情報管理の責任が自社に生じます。AWS のベストプラクティスはクロスアカウントロールの利用を推奨しています。 D: PrivateLink はネットワーク接続の提供には有効ですが、IAM 認証・認可の代替にはなりません。アクセス制御はリソースポリシーと IAM で行う必要があります。
📚 関連サービスの解説: AWS Organizations ・ AWS IAM