yagibrary
← 記事一覧に戻る
公開日: 2026-06-09

【AWS SAA対策】安全なマルチアカウント運用の基本！クロスアカウントIAMロールとSCP（AWS Organizations）の連携を徹底解説

AWS SAA セキュリティ IAM Organizations

AWS Organizationsで複数アカウントを運用する際、外部ベンダーへ一時的なアクセス権限を安全に付与する手法について解説。SAA試験で頻出の「クロスアカウントIAMロール」と「SCP（サービスコントロールポリシー）」を組み合わせたセキュリティ設計のポイントを、図解入りで分かりやすく紹介します。

【AWS SAA対策】安全なマルチアカウント運用の基本！クロスアカウントIAMロールとSCP（AWS Organizations）の連携を徹底解説

AWS認定ソリューションアーキテクト – アソシエイト（SAA-C03）の試験では、セキュリティとマルチアカウント運用の設計に関する問題が頻出します。

特に実務でもよくある、「複数のAWSアカウントを一元管理している環境において、外部のパートナー企業やベンダーに一時的なアクセス権限を安全に付与するにはどうすればよいか？」というシナリオは、セキュリティ設計の王道パターンです。

この記事では、具体的な試験対策問題をベースに、「クロスアカウントIAMロール」と「SCP（サービスコントロールポリシー）」を組み合わせた安全なアクセス制御の仕組みを、図解を交えて徹底的に解説します！

💻 よくある設計課題（シナリオ）

あなたはあるグループ企業で、AWS Organizations を使って複数ある子会社のアカウントを一元管理しています。

ある日、外部のパートナー企業（ベンダー）が子会社のアカウントに入ってコンテンツ管理や分析の支援を行うことになりました。

ここで、セキュリティ担当者から以下の要件が提示されます。

  1. 「最小権限の原則」を徹底し、ベンダーに必要以上の操作権限を与えない。
  2. セキュリティ事故を防ぐため、「一時的なアクセス権限の付与」とし、不要になったら自動的にアクセスできなくなる仕組みにする。

これらの条件を満たし、効率的かつ最も安全に外部ベンダーへのアクセスを許可するには、どのような設計にするべきでしょうか？

💡 具体的な試験問題と選択肢の解説はこちら このシナリオに基づいた具体的な模擬試験問題（選択肢の吟味や不正解の解説）については、以下の関連記事で紹介しています。

【AWS SAA対策】マルチアカウント環境でのクロスアカウントアクセスとSCP（サービスコントロールポリシー）による安全なベンダーアクセス設計
AWS認定 ソリューションアーキテクト（SAA）で頻出のマルチアカウント設計！AWS Organizations環境において、外部ベンダーなどに対して「最小権限の原則」と「一時的なアクセス権限の付与」をどのように安全かつ効率的に実装するか、クロスアカウントIAMロールとSCPの違いや組み合わせを初心者向けに分かりやすく解説します。
2026-06-16
#AWS#SAA#Organizations

🔑 目指すべき解決策

この課題に対するベストプラクティスは、「クロスアカウント IAM ロール」と「SCP（サービスコントロールポリシー）」を組み合わせた構成です。

なぜこの2つを連携させることで、強固で柔軟なマルチアカウント運用ができるのか、技術的な仕組みを見ていきましょう。

正解の技術解説

1. クロスアカウントIAMロールとは？

クロスアカウントIAMロールとは、「異なるAWSアカウント間で安全に権限を受け渡すための仕組み」です。

💡 そもそも「IAM」や「IAMロール」の基本をおさらいしたい方へ 「IAMロールとIAMユーザーの違いがまだ曖昧かもしれない…」という方は、まずこちらの記事

AWSセキュリティの要！「AWS IAM」とは？初心者向けに概念から設定方法まで図解でわかりやすく解説
AWSを利用する上で避けて通れない最重要サービス「AWS IAM」を初心者向けに解説。認証・認可の違いから、ユーザー、グループ、ロール、ポリシーの4大要素、JSONによるポリシーの書き方、安全運用のためのベストプラクティスまで、図解を交えて分かりやすく紹介します。安全なAWS運用の第一歩に最適です。
2026-06-08
#AWS#IAM#セキュリティ

を合わせてお読みいただくことを強くおすすめします。この記事で紹介している「ポリシーの適用ルール」や「一時的な認証情報の仕組み」を理解しておくと、今回のクロスアカウントの設計もより深く、スムーズに腑に落ちるようになります！

今回のケースでは、アクセスされる側（子会社アカウントA）が、アクセスする側（ベンダーのAWSアカウントB）を信頼する設定をした「IAMロール」をあらかじめ作成しておきます。

sequenceDiagram
    autonumber
    actor Vendor as ベンダー (アカウントB)
    participant STS as AWS STS (セキュリティトークン)
    participant Child as 子会社 (アカウントA)
    participant Res as AWSリソース (S3/EC2等)

    Note over Child: アカウントBを信頼するロールを設定
    Vendor->>STS: ① AssumeRole (ロール引き受け) をリクエスト
    STS->>Vendor: ② 一時的セキュリティ認証情報を発行 (アクセスキー等)
    Vendor->>Child: ③ 一時的な認証情報を使ってリソースを操作
    Child->>Res: ④ 許可された範囲で操作を実行

なぜ安全なのか？

  • 長期的な認証情報が不要： IDやパスワード、恒久的なアクセスキー（長期認証情報）をベンダーに渡す必要がありません。
  • 一時的な認証情報（Temporary Credentials）を利用： ベンダーは AWS STS (Security Token Service) を通じて、一時的に有効な認証情報を取得してアクセスします。この認証情報は数時間で自動的に失効するため、万が一漏洩しても被害を最小限に抑えられます。
  • アカウント間の切り替えがスムーズ： ベンダー側は自社のアカウントからスイッチロール（ロールの切り替え）するだけで、他のアカウントへ容易にアクセスできます。

2. SCP (Service Control Policy) とは？

AWS Organizations を使用してマルチアカウントを管理する場合、個別のアカウント（子会社）ごとにポリシーを設定するだけでは、グループ全体のガバナンスを保つのが困難になります。

そこで利用するのが SCP (サービスコントロールポリシー) です。

graph TD
    Root["AWS Organizations ルート組織"] -->|SCP: 強力なガードレールポリシー| Org["子会社アカウント群"]
    Org -->|IAMポリシー: 実際の操作権限| User["ベンダー用ロール"]
  • 組織レベルでのアクセス制限： SCPは、親アカウントから子会社アカウント（または組織単位：OU）に対して適用される「ガードレール」のようなポリシーです。
  • 上限の決定： 例えば、SCPで「特定のサービス（例: AWS Billingやセキュリティ設定の変更）へのアクセスを禁止する」と設定すると、子会社アカウント内のIAMロールにどんなに強い権限が与えられていても、その操作は絶対に実行できなくなります。
  • クロスアカウントの制御： ベンダーのクロスアカウントアクセスに対しても、SCPによって組織が定めた範囲を超えるような操作が行われないように強力に防御できます。

他の選択肢が不適切な理由

a. IAMユーザーを作成し、手動で削除する運用

  • 不適切である理由： 「手動で削除する」という人的なプロセスに依存する運用は、削除漏れや放置リスクが非常に高く、セキュリティ侵害の原因になります。また、一時的ではない長期的な認証情報（アクセスキーなど）が発行されるため、親会社の「一時的なアクセス権限の付与」というセキュリティガイドラインに違反します。

b. AWS Client VPN を配布し、アクセスを限定する

  • 不適切である理由： VPN（Virtual Private Network）は、特定のネットワーク経路を通じた通信を暗号化・保護するための「ネットワークレイヤー」の技術です。 VPNを導入しても、「AWSリソースを操作するためのIAM権限（どのAPIを実行できるか）」を制限することはできません。ネットワーク制限と権限制限は別物であり、最小特権の原則を達成するためにはIAMでの制御が必須となります。

d. 各アカウントに個別に IAM Identity Center インスタンスを構築する

  • 不適切である理由： AWS IAM Identity Center（旧 AWS Single Sign-On）は、組織内のユーザーアクセスを一元管理するための優れたサービスです。 しかし、Identity Centerは「組織全体（AWS Organizations）で一元管理されるべき」ものであり、各子会社のアカウントごとに個別に構築する（分散運用する）と管理が非常に煩雑になります。また、Identity Centerは主に人間（グループ企業の従業員など）に対するシングルサインオン用のサービスであり、外部の特定ベンダーに一時的なシステム権限を渡す場合は、通常のクロスアカウントIAMロールが適しています。

まとめ：AWSセキュリティ設計の黄金律

AWS Organizations 環境で外部ベンダーに安全にアクセスしてもらう際の構成は、以下がベストプラクティスです。

  1. クロスアカウントIAMロール（AssumeRole） を使用し、ベンダーに長期的なアクセスキーを渡さず、一時的な認証情報でアクセスさせる。
  2. AWS Organizations の SCP（サービスコントロールポリシー） を使って、各子会社アカウントに対して強力なセキュリティガードレールを設定し、ベンダーの誤操作や権限逸脱を防ぐ。

この2つを正解として覚えることで、AWS SAA試験のセキュリティ問題だけでなく、実際のマルチアカウント設計でも安全なインフラを構築できるようになります。

しっかりと理解して、試験合格と安全なAWS運用を目指しましょう！

この記事をシェアする