AWS認定の「ソリューションアーキテクト - アソシエイト（SAA-C03）」では、企業が複数のAWSアカウントを運用する「マルチアカウント環境」におけるセキュリティ設計が頻出テーマとなっています。
その中で特によく問われるのが、「外部のパートナー企業やベンダーに対して、自社のアカウント群へ安全に、かつ最小限の権限で一時的にアクセスさせるにはどうすればよいか」という設計課題です。
この記事では、実際の模擬試験レベルの設計課題をもとに、マルチアカウント環境でのアクセス制御の主役である「クロスアカウントIAMロール」と、組織全体のガードレールとなる「SCP（サービスコントロールポリシー）」の組み合わせについて、初心者向けに優しく解説します！
💻 よくある設計課題（シナリオ）
課題： 日本国内に複数の教育関連子会社を持つ大手グループ企業では、AWS Organizationsを使ってそれぞれの子会社アカウントを一元管理しています。
各子会社では、外部の教育ベンダーが一時的にアクセスし、コンテンツ管理や分析支援を行う必要があります。 同時に、親会社のセキュリティガイドラインでは「最小権限の原則」と「一時的なアクセス権限の付与」が義務付けられています。
これらの条件を満たし、効率的かつ安全にベンダーへのアクセスを許可する方法として最適なのはどれですか？
🔑 押さえておくべき2つの重要概念
この課題を解くための鍵は、「クロスアカウントIAMロール」と「SCP（サービスコントロールポリシー）」の2つの仕組みを理解することです。
💡 詳細な図解と仕組みの基礎を学びたい方へ クロスアカウントIAMロールのシーケンス図や、SCPがガードレールとして機能する詳細なイメージ図を用いた解説は、以下の関連記事で詳しく紹介しています。基礎から学びたい方はぜひ合わせて参考にしてください。
【AWS SAA対策】安全なマルチアカウント運用の基本！クロスアカウントIAMロールとSCP（AWS Organizations）の連携を徹底解説AWS Organizationsで複数アカウントを運用する際、外部ベンダーへ一時的なアクセス権限を安全に付与する手法について解説。SAA試験で頻出の「クロスアカウントIAMロール」と「SCP（サービスコントロールポリシー）」を組み合わせたセキュリティ設計のポイントを、図解入りで分かりやすく紹介します。
1. クロスアカウントIAMロールとは？（一時アクセス）
通常、別のアカウントにあるAWSリソースにアクセスさせたい場合、アクセス先のアカウントに「IAMユーザー」を作成してアクセスキーを渡すという方法を思い浮かべるかもしれません。しかし、これはセキュリティ上非常に危険です（アクセスキーの漏洩や管理の形骸化につながるため）。
そこで使用するのが「クロスアカウントIAMロール」です。
- 仕組み: アクセスされる側のアカウント（子会社アカウント）に、特定の信頼されたアカウント（ベンダーのアカウント）からのみ「スイッチロール（ロールの引き受け）」ができるIAMロールを作成します。
- メリット:
- ベンダーは自社のアカウントの認証情報を使ってログインし、そこから子会社アカウントのロールを引き受けます（
sts:AssumeRoleという仕組み）。 - 認証情報（パスワードやアクセスキー）を子会社側で管理・発行する必要がありません。
- ロールを引き受けると、一時的なセキュリティ資格情報（有効期限付きの鍵）が発行されるため、「一時的なアクセス権限の付与」という要件を完璧に満たします。
- ベンダーは自社のアカウントの認証情報を使ってログインし、そこから子会社アカウントのロールを引き受けます（
2. SCP（サービスコントロールポリシー）とは？（組織のガードレール）
AWS Organizations環境において、組織全体、または特定のグループ（OU: 組織単位）、特定のアカウントに対して「絶対にやってはいけないこと」や「許可する最大の権限」を制限するポリシーです。
- 仕組み: SCPは、そのアカウント内のすべてのユーザーやロール（ルートユーザーを含む）に影響を与えます。
- メリット:
- 例えば、子会社アカウントで誤って「AdministratorAccess（全権限）」を持つIAMロールを作成してベンダーに渡してしまったとします。しかし、親会社がAWS Organizations側で「ベンダーが触るリソース以外へのアクセスを禁止するSCP」を設定していれば、ベンダーはその制限を超えた操作は一切できません。
- 「IAMポリシーで許可されていても、SCPで拒否されていれば実行できない」という強力なガードレールとして機能します。
🎯 課題の要件をどう満たすか？
今回はシナリオで提示された要件と、なぜ「クロスアカウントIAMロール ＋ SCP」の組み合わせがベストプラクティスなのかを見ていきましょう。
- 要件①：最小権限の原則 ＆ 一時的なアクセス権限の付与
- ➡️ クロスアカウントIAMロール を使用することで、ベンダーに恒久的なIAMユーザーを作ることなく、必要な時間だけ一時的なアクセス（最小権限）を許可できます。
- 要件②：効率的かつ安全にベンダーへのアクセスを許可（統制）
- ➡️ SCP（サービスコントロールポリシー） を Organizations 全体に適用しておくことで、子会社アカウント側でどのようなIAM設計が行われても、親会社が定めたセキュリティ境界線（ガードレール）を強制することができます。
この2つを組み合わせることで、「現場（子会社）での柔軟な運用」と「全社的なセキュリティ統制」を両立させることができます。
🚫 なぜ他の選択肢は適していないのか？
試験対策として、他のアプローチが不適切な理由もしっかり理解しておきましょう。
a. 各ベンダー用に IAM ユーザーを作成し、アクセス後は手動で削除する
- 間違いの理由: 「手動で削除する」という運用は、削除漏れ（放置ユーザー）が発生するリスクが非常に高く、セキュリティガイドラインの「一時的なアクセス」をシステム的に強制できません。また、アクセスキーの発行・管理の手間も発生するため、非推奨とされています。
b. ベンダーに AWS Client VPN を配布し、アクセスを VPN 経由に限定する
- 間違いの理由: Client VPNは、ネットワークの接続経路を限定するだけであり、AWSリソース（S3やDynamoDBなど）に対する「誰がどの操作を行ってよいか」というIAMベースのきめ細かなアクセス制御（最小権限の原則）はできません。
d. 各アカウントにベンダー用の IAM Identity Center インスタンスを個別に構築する
- 間違いの理由: IAM Identity Center（旧AWS SSO）は、組織内のシングルサインオンを一元管理するための素晴らしいサービスですが、各アカウントごとに個別に構築するものではありません。Organizationsの管理アカウント（または委任された管理者アカウント）で一元的に設定するべきものです。個別に構築すると運用の手間が爆発し、管理が崩壊します。
💡 まとめ：試験対策のチートシート
AWS認定試験で「マルチアカウント」「外部ベンダーへの安全なアクセス」が出題されたら、以下のキーワードをセットで思い出しましょう！
- 🔑 「外部ベンダーに一時アクセスさせたい（鍵を渡したくない）」
- ➡️ クロスアカウントIAMロール（スイッチロール）
- 🔑 「組織全体・複数アカウントに一元的なガードレールを敷きたい」
- ➡️ AWS Organizations + SCP（サービスコントロールポリシー）
- 🔑 「ユーザーのサインオンを一元化したい（個別にアカウントを作るのはNG）」
- ➡️ IAM Identity Center（Organizationsで一括管理）
これらを理解しておくことで、マルチアカウント設計の問題は確実に得点源にできます！
🎯 AWS SAA 合格に向けたおすすめの教材
AWS SAA（ソリューションアーキテクト – アソシエイト）のセキュリティやアカウント管理分野は、実際の画面操作や図解と合わせて学ぶのが最も効率的です。
1. 【書籍】AWS教科書 AWS認定ソリューションアーキテクトアソシエイト テキスト＆問題集 第2版
試験範囲の網羅率が非常に高く、OrganizationsやIAM、SCPの仕組みが詳細な図解付きで体系的に学べる一冊です。
2. 【Udemy】【SAA-C03版】これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座
ベストセラーとなっている動画教材です。ハンズオン（実際にAWS画面を操作するパート）が豊富で、クロスアカウントロールの設定やSCPの適用方法などをビジュアルで体感できるため、本で学ぶよりも圧倒的にネットワークや権限の仕組みが腹落ちします。