AWS Organizations における不正なアカウント離脱を防止するための重要なセキュリティコントロール

本ブログは 2026 年 3 月 17 日に公開された AWS Blog、”Essential security controls to prevent unauthorized account removal in AWS Organizations” を翻訳したものです。

AWS メンバーアカウントが侵害された場合、攻撃者はアカウントを組織から離脱させ、すべてのガバナンスコントロールを無効化する可能性があります。本記事では、サービスコントロールポリシー (SCP)、安全なアカウント移行、一元化されたルートアクセス管理などの多層的なセキュリティコントロールを使用して、AWS 環境をアカウント侵害から保護する方法を解説します。

AWS はクラウドを実行するインフラストラクチャのセキュリティを担い、お客様はクラウド内のワークロードとデータのセキュリティを担います。そのために、AWS Organizations には不正なアカウント離脱を防止し、アカウント全体のガバナンスを維持するセキュリティコントロールが含まれています。

本記事では、4 つのコントロールについて説明します。サービスコントロールポリシー (SCP) による不正なアカウント離脱の防止、正当な移行のためのブレークグラス手順の確立、組織間でのアカウントの直接移行、およびメンバーアカウントのルートアクセスの無効化です。

前提条件
本記事では、AWS Organizations とマルチアカウント戦略の概念に精通している必要があります。以下の権限を持つ AWS Organizations 管理アカウントへのアクセスが必要です。

サービスコントロールポリシーの作成とアタッチ — organizations:CreatePolicy、organizations:AttachPolicy
組織単位の管理 — organizations:CreateOrganizationalUnit、organizations:MoveAccount
一元化されたルートアクセス管理の有効化 — iam:EnableOrganizationsRootCredentialsManagement

セキュリティと柔軟性を両立する組織単位 (OU) 構造の設計
マネージドサービスプロバイダー、リセラー、アカウントの入れ替わりが多い組織など、メンバーアカウントが定期的に組織を離脱することを許可する必要があるビジネスモデルの場合、最初からこのワークフローを考慮して OU 構造を設計する必要があります。

アカウントのライフサイクルステージ (オンボーディング、アクティブ、オフボーディング) ごとに専用の OU を作成し、長期的なガバナンス下に置くべきアカウントを含む OU にのみ DenyLeaveOrganization SCP を適用することを検討してください。このアプローチにより、コアインフラストラクチャを保護しつつ、短期間のアカウントの移行を簡素化できます。

セキュリティコントロールと運用の柔軟性のバランスを取る階層的な OU 構造を作成してください。本番環境と開発環境の OU に DenyLeaveOrganization SCP を適用して重要なワークロードを保護し、制御されたアカウント移行のためにこの制限のない別の移行用 OU を維持します。

推奨される OU アーキテクチャ

本番 OU: DenyLeaveOrganization SCP を適用して、本番ワークロードを実行するアカウントが組織を離脱することを防止します
開発 OU: 同じ SCP を適用して、開発およびテスト環境のガバナンスを維持します
移行 OU: DenyLeaveOrganization SCP を適用せず、組織を離脱する準備をしているアカウントの制御されたステージングエリアとして機能させます

正当なビジネス上の理由でアカウントが組織を離脱する必要がある場合、管理アカウントはそのアカウントを移行 OU に移動でき、メンバーアカウントの離脱操作が可能になります。これにより、明確な承認ワークフローが作成され、移行プロセス全体の可視性が維持されます。

管理アカウントは組織からメンバーアカウントを離脱させることができるため、メンバーアカウントが自ら離脱する正当な必要性がない場合は、離脱アカウント用の移行 OU アプローチを実装する必要はありません。

OU 構造の整理と管理に関する詳細なガイダンスについては、AWS Organizations での組織単位の管理に関する AWS ベストプラクティスを参照してください。

組織離脱アクションを拒否するサービスコントロールポリシーの実装
メンバーアカウントが組織を離脱することを防止するには、メンバーアカウントに対して organizations:LeaveOrganization アクションを拒否する SCP を実装します。この予防的コントロールにより、アカウントがガバナンスフレームワーク内に留まり、セキュリティコントロールと組織ポリシーが維持されます。

AWS マネジメントコンソールを使用した SCP の作成

管理アカウントで AWS Organizations コンソールにサインインします。
ナビゲーションペインで ポリシー を選択します。
サービスコントロールポリシーを有効化します。
ポリシーの作成 を選択します。
ポリシー名を入力します (例: “DenyLeaveOrganization”)。
ポリシーエディタに以下の JSON を入力します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

ポリシーの作成 をクリックします。

AWS CLI を使用した SCP の作成

以下のコマンドを実行してポリシーを作成します。

aws organizations create-policy \
--name DenyLeaveOrganization \
--type SERVICE_CONTROL_POLICY \
--description "Prevents member accounts from leaving the organization" \
--content '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"organizations:LeaveOrganization","Resource":"*"}]}'

次のステップで使用するため、出力からポリシー ID を記録してください。

ポリシーを作成したら、移行 OU を制限なしのまま維持しつつ、本番 OU と開発 OU に DenyLeaveOrganization SCP を適用します。

AWS マネジメントコンソールを使用した OU への SCP のアタッチ

AWS Organizations に移動します。
対象の OU (本番または開発) を選択します。
ポリシー タブを選択します。
アタッチ を選択し、「DenyLeaveOrganization」ポリシーを選択します。
ポリシーが必要な各 OU に対して繰り返します。

AWS CLI を使用した OU への SCP のアタッチ

作成ステップで取得したポリシー ID を使用して、対象の OU にポリシーをアタッチします。aws organizations attach-policy --policy-id p-xxxxxxxx --target-id r-xxxx
ポリシーのアタッチを確認します。aws organizations list-targets-for-policy --policy-id p-xxxxxxxx
ポリシーが必要な各 OU に対して繰り返します。

このコントロールは、コンソール、CLI、SDK を通じた API レベルでの離脱の試みをブロックします。管理アカウントの保護に関するベストプラクティスについては、ドキュメントを参照してください。

SCP は管理アカウントには適用されず、組織内のメンバーアカウントにのみ影響することに注意してください。そのため、管理アカウントを MFA、アクセス制限、一時的な認証情報のみの使用、包括的なモニタリングなど、可能な限り強力なセキュリティコントロールで保護することが不可欠です。

ブレークグラス手順の文書化

アカウントの移行、合併、買収、事業売却の際に特定のアカウントが組織を離脱することを許可する必要がある場合は、文書化された承認ワークフローと技術的メカニズムを備えた正式なプロセスを確立してください。

シナリオに適したブレークグラスメカニズムを選択してください。アカウントが組織を離脱する必要がある場合、標準的な変更管理プロセスを通じて、現在の OU から移行 OU に移動します。移行 OU に移動すると、DenyLeaveOrganization SCP の制限なしに離脱操作を実行できます。このアプローチにより、組織ルート全体から SCP を一時的に削除することなく、すべてのアクティブなアカウントのセキュリティコントロールが維持されます。

メンバーアカウント離脱の文書化された例外プロセスの確立

安全な招待ベースの移行プロセスの外で、メンバーアカウントが独自に組織を離脱する場合は、正式な承認を必要とする例外として扱う必要があります。各例外リクエストには、標準的な組織間移行プロセスを使用できない理由を説明する明確なビジネス上の正当性と、セキュリティおよびガバナンスポリシー要件との整合性を検証するためのセキュリティおよび IT 管理チームによるレビューと承認が含まれている必要があります。

この例外をセキュリティベースラインに文書化し、移行 OU は標準的な招待ベースの移行を使用できない承認済みの移行中の一時的なアカウントステージングのためにのみ存在することを明示的に記載してください。この文書化により、説明責任が確立され、コンプライアンスレビューのための監査証跡が作成され、セキュリティコントロールの例外が意図的で、正当化され、期限付きであることが保証されます。

合併・買収時のアカウントの安全な移行

合併、買収、または組織統合の際、AWS Organizations は組織間の安全な直接アカウント移行をサポートし、アカウントがスタンドアロンになることを防止します。移行先の組織の管理アカウントが移行するアカウントに招待を送信します。承認されると、アカウントは組織のガバナンスの外で運用されることなく、移行元から移行先の組織にシームレスに移行します。サービスコントロールポリシー (SCP)、ログ記録、モニタリングは移行中も継続的に適用され、セキュリティ体制が維持され、AWS CloudTrail を通じた完全な監査証跡が作成されます。

この招待ベースのアプローチは、アカウントが独立して運用される際に発生するセキュリティギャップを防止しながら、ほとんどの正当な移行ユースケースに対応します。管理アカウントがメンバーアカウントを手動で離脱させる必要はなく、招待プロセスが移行を自動的に処理します。移行後は、適切なポリシーが適用されていることを確認し、正しい組織 ID で IAM ポリシーを更新し、請求設定、税金設定、リザーブドインスタンスの移行を確認してください。詳細なガイダンスについては、AWS Organizations ユーザーガイドのアカウント移行を参照してください。

メンバーアカウントのルートアクセスの脆弱性の排除

メンバーアカウントのルートユーザー認証情報は、AWS 環境における最高レベルの特権アクセスであり、AWS Identity and Access Management (IAM) ポリシーやサービスコントロールポリシーをバイパスできます。2025 年の AWS 一元化されたルートアクセス管理の開始以降、新しく作成されたメンバーアカウントにはデフォルトでルートユーザー認証情報がなくなりました。これは、組織内のすべての新しいアカウントの標準的な動作です。新しく作成されたメンバーアカウントはルートユーザー認証情報なしで自動的にプロビジョニングされるため、多要素認証の設定などのプロビジョニング後のセキュリティ対策が不要になります。

このデフォルトが有効になる前に作成された既存のアカウントについては、長期間有効なルートユーザー認証情報の削除は迅速かつ簡単です。AWS 一元化されたルートアクセス管理を使用すると、パスワード、アクセスキー、署名証明書、MFA デバイスなどのルートユーザー認証情報を、管理アカウントから組織全体にわたって直接削除できます。各メンバーアカウントに個別にサインインする必要はありません。

この一元化されたアプローチにより、メンバーアカウント全体で一貫したセキュリティが維持されます。また、アカウント作成とセキュリティ設定の間の脆弱性ギャップを排除することで、運用オーバーヘッドが削減されます。一元化されたルートアクセス管理の実装に関する詳細なガイダンスについては、メンバーアカウントのルートアクセスの一元管理を参照してください。

AWS マネジメントコンソールを使用したルートユーザー認証情報の削除

管理アカウントを使用して IAM コンソールを開きます。
ナビゲーションペインの アクセス管理 で、ルートアクセス管理 を選択します。
一元化されたルートアクセス管理がまだ有効になっていない場合、ページの上部にバナーまたはプロンプトが表示されます。
有効化 を選択してアクティブにします。プロンプトが表示されない場合、この機能は組織で既に有効になっています。有効化すると、ページにメンバーアカウントを含む組織構造が表示されます。
アカウントを選択し、右側のルートユーザー認証情報パネルを確認します。アクティブなルートユーザー認証情報がまだあるアカウントについては、ルートユーザー認証情報の削除 を選択して削除します。

ルートアクセス管理

図 1: ルートアクセス管理

AWS CLI を使用した一元化されたルートアクセス管理の有効化

以下のコマンドを実行して、一元化されたルートアクセス管理を有効化します (既に有効な場合でも安全に実行でき、現在の機能の状態が返されます)。aws iam enable-organizations-root-credentials-management
有効化された機能を確認して設定を検証します。aws iam list-organizations-features
出力を確認して、有効化が成功したことを確認します。機能が有効化されている場合、以下のように表示されます。

{
  "OrganizationId": "o-xxxxxxxxxxxx",
  "EnabledFeatures": [
    "RootSessions",
    "RootCredentialsManagement"
  ]
}

機能がまだ有効化されていない場合、aws iam list-organizations-features は以下のように空の EnabledFeatures 配列を返します。

{
  "OrganizationId": "o-xxxxxxxxxxxx",
  "EnabledFeatures": []
}

まとめ
AWS Organizations をアカウント侵害から保護するには、保護と運用の柔軟性のバランスを取る多層的なセキュリティコントロールが必要です。DenyLeaveOrganization サービスコントロールポリシーは、不正なアカウント離脱をブロックし、継続的なガバナンスの監視を維持します。組織間の招待ベースのアカウント移行機能は、セキュリティギャップを作ることなく、合併、買収、統合などの正当なビジネスニーズをサポートします。AWS 一元化されたルートアクセス管理によるルートアクセスの排除は、セキュリティコントロールをバイパスできる最高特権の経路を削除します。

これらのコントロールにより、侵害された認証情報を使ったアカウントの組織からの離脱を防止し、移行中もサービスコントロールポリシーとログ記録をアクティブに保ち、セキュリティインシデントをガバナンスフレームワーク内に封じ込めることで、問題の検出、対応、修復をより迅速に行えるようになります。

まず OU 構造を設計し、ブレークグラス手順を文書化してから、DenyLeaveOrganization SCP を適用し、AWS 一元化されたルートアクセス管理を有効化してください。OU 構造を定期的にレビューし、例外リクエストを監査し、AWS CloudTrail を通じて不正アクセスの試みを監視してください。アカウントガバナンスを重要なセキュリティコントロールとして扱い、AWS 環境を安全でコンプライアンスに準拠し、ビジネス目標に沿った状態に保ちましょう。サービスコントロールポリシーの例とテンプレートについては、AWS SCP Examples GitHub リポジトリをご覧ください。

著者について

翻訳は Security Solutions Architect の松崎博昭が担当しました。

Amazon Web Services ブログ