Amazon Web Services ブログ
CIRT インサイト: AWS Organizations からの不正なアカウント離脱を防ぐには
本ブログは 2026 年 5 月 19 日に公開された AWS Blog、”CIRT insights: How to help prevent unauthorized account removals from AWS Organizations” を翻訳したものです。
AWS Customer Incident Response Team (CIRT) は、お客様がアクティブなセキュリティインシデントから復旧するためのご支援を行っています。この活動の中で、特定のお客様の構成や設計を悪用する、新しいまたは流行している攻撃手口を発見することがしばしばあります。
これらの手口を理解することは、アーキテクチャ上の意思決定への反映、対応計画の改善、そして実際にこのような状況が発生した場合の検出に役立ちます。
本投稿では、攻撃者がお客様アカウントの制御を奪取した後に取る新しいアプローチを取り上げます。具体的には、お客様の AWS Organizations 実装から該当アカウントを離脱させ、その構造が提供するポリシーや保護を回避する手口です。
本記事で説明する手口は、AWS サービスの脆弱性を利用するものではありません。代わりに、特定の構成や設計によって生じた予期しない機会を悪用し、AWS アカウント内のリソースを不正に使用するものです。
何が起きているのか
このアプローチは、攻撃者が organizations:LeaveOrganization 権限の付与を持つクレデンシャルを使用するところから始まります。この権限は LeaveOrganization API コールへのアクセスを提供し、メンバーアカウントから呼び出されると、そのアカウントを Organization から離脱させようとします。
重要な点として、このアプローチでは侵害されたルートクレデンシャルが使われる場合もありますが、攻撃者は他の手段でアクセス権を昇格させ、必要な権限を取得したり、その権限を持つロールを引き受ける能力を獲得したり、現在のクレデンシャルにこの権限を付与する能力を獲得したりすることもできます。これが、認可に対して最小権限のアプローチを取ることが、お客様の環境を保護する上で極めて重要である理由です。詳細については、AWS Identity and Access Management (IAM) ドキュメントと、組織単位 (OU) 設計および サービスコントロールポリシー (SCP) 実装に関する AWS Organizations のガイダンスをご覧ください。
お客様の環境への影響
アカウントが Organization から離脱させられると、その Organization の一部として継承されていた制限 (破壊的なアクションを防止していた SCP、利用可能な AWS リージョンを制限していたもの、特定の API コールをブロックしていたもの等) が適用されなくなります。また、当該アカウントは一括請求 (Consolidated Billing) の対象外となるため、Organization の請求アラートやコスト異常検知も該当アカウントの活動をカバーしなくなります。AWS CloudTrail の組織トレイルは離脱したアカウントからのイベント取得を停止し、委任管理者を介して管理されていた Amazon GuardDuty の検出結果も中央のセキュリティアカウントへ流れなくなります。
その結果しばしば発生するのは、Organization が当該アカウントへの可視性を失う一方で、そのアカウント内には引き続き Organization のリソースが残るという状況です。関連する Threat Technique Catalog のエントリを以下に示します。
- T1078.A002: Account Root User: 侵害されたルートクレデンシャルを利用した初期アクセス
- T1078.004: Cloud Accounts: 侵害された IAM クレデンシャルを利用した初期アクセス
- T1098: Account Manipulation: 制御を維持するための権限昇格とアカウント設定の変更
- T1666.A002: Leave AWS Organization: SCP やガバナンスコントロールを回避するため、メンバーアカウントを Organization から離脱させる
- T1562.008: Disable Cloud Logs: Organization からの離脱後、中央集約型ロギングの可視性が失われる
この手口の検知
アカウントが Organization からの離脱を試みると、CloudTrail には少なくとも 2 つの API コールが記録されます。organizations:AcceptHandshake と organizations:LeaveOrganization です。中央集約型のロギングを構成している場合、これらのイベントが侵害アカウントから観測される最後のイベントとなる可能性があります。Organization からの離脱後、デフォルトではアカウント内のイベントは自身の CloudTrail ログに記録されることになります。アカウントが Organization に参加または離脱する際に関連する CloudTrail イベントを以下に示します。これらのイベントは、AWS Organizations を管理するためにチームが利用する承認済みの運用ワークフローの一部でない限り、調査が必要です。
| CloudTrail イベント | 意味 |
LeaveOrganization |
メンバーアカウントが Organization から離脱しようとしている |
AcceptHandshake |
アカウントが別の Organization への参加招待を承諾している |
InviteAccountToOrganization |
Organization がアカウントを招待している |
RemoveAccountFromOrganization |
管理アカウントがメンバーアカウントを削除している (メンバー自らが離脱する場合とは異なる) |
この手口を防ぐための推奨ステップ
organizations:LeaveOrganization アクションを拒否する SCP を実装してください。AWS Organizations はこの制御の実装に関する詳細なガイダンスを提供しており、具体的な SCP ポリシー JSON や、本番環境および開発環境のアカウントには保護を維持しつつ正当なアカウント移行を許容できる OU 構造の設計に関するアドバイスが含まれています。
SCP は、メンバーアカウント内で IAM ポリシーが許可できる範囲を制限するガードレールとして機能します。AWS Organizations をご利用のすべてのお客様には、この SCP が現在配置されているかを確認し、配置されていない場合には実装に向けた手順を踏むことを強く推奨いたします。この SCP は迅速にデプロイでき、運用上の影響も最小限です。メンバーアカウントを Organization から分離することを慎重に管理・検討するためのプロセスを提供します。
このアクションは、ルートだけでなく organizations:LeaveOrganization 権限を持つあらゆる侵害された IAM プリンシパルから発生し得るため、IAM 権限の最小権限原則は重要な補完的な制御となります。ユーザーやロールがポリシーの追加・削除・変更を行ったり、別のロールを引き受けたり、自身の権限を変更したりできる範囲を制限することで、不正な権限変更が行われる経路を減らすことができます。IAM ポリシーを定期的にレビューし、過度に広範な権限 (特に iam:AttachRolePolicy、iam:AttachUserPolicy、iam:PutRolePolicy、および広範な信頼ポリシーを伴う sts:AssumeRole) を確認することは、侵害されたプリンシパルが実行できる範囲を制限するのに役立ちます。
ルートアカウントのセキュリティは引き続き重要です。ルートの侵害がこのパターンの一般的な侵入経路となるためです。すべてのルートユーザーに対して多要素認証 (MFA) を有効化し、ルートアクセスキーを削除し、メンバーアカウントからルートクレデンシャルを完全に取り除くルートアクセスの一元管理を採用することで、リスクの軽減につながります。
今後について
本手口は、私たちが様々なエンゲージメントを通じて目にしている、より広範なテーマを浮き彫りにしています。攻撃者は AWS のガバナンスコントロールがどのように機能するかをますます認識しており、Organization が提供する制御からアカウントを切り離すための意図的な手段を取っています。AWS CloudTrail を無効化する、Amazon GuardDuty ディテクターを削除する、Organization からアカウントを離脱させるといった行為は、いずれも同じ戦略の派生形にあたります。すなわち、本来であれば攻撃者の活動を制約し、お客様による対応を支援するはずのガードレールと可視性から、お客様のアカウントを切り離すというものです。
これを防ぐための制御は本日時点で利用可能であり、実装も簡単です。AWS Organizations サービスチームのガイダンスから始め、DenyLeaveOrganizationSCP を実装することをお勧めします。本手口に対して、最も効果が大きく、かつ最も労力の少ない制御です。それ以外にも、OU 構造全体での SCP のカバレッジを見直すこと、すべてのメンバーアカウントでルートクレデンシャルと IAM 権限が適切に保護されていることを確認すること、検知・対応プロセスが本手口を考慮に入れていることを確かめることが、より強固なセキュリティ態勢に貢献します。Threat Technique Catalog for AWS には、根底にある手口の検知ガイダンスが含まれています。
関連リソース
- Threat Technique Catalog for AWS – Matrix
- T1078.A002: Account Root User
- T1078.004: Cloud Accounts
- T1098: Account Manipulation
- T1666.A002: Leave AWS Organization
- AWS Organizations における不正なアカウント離脱を防止するための重要なセキュリティコントロール
- メンバーアカウントのルートアクセスを一元管理する
- AWS Organizations サービスコントロールポリシー
- Amazon GuardDuty
- AWS CloudTrail ユーザーガイド
本投稿に関するフィードバックがありましたら、下のコメントセクションにご投稿ください。
著者について
翻訳は Security Solutions Architect の 松崎 博昭 が担当しました。