AWSのマルチアカウント環境におけるセキュリティサービスの構成をまとめてみた
こんにちは！クラウド事業本部の吉田です。
AWSのマルチアカウント環境でセキュリティサービスを設計しようとすると、全体像の把握が難しいと感じることがあります。
各セキュリティサービスのマルチアカウント環境における設計について解説した記事は存在しますが、それをひとまとめした記事というのはあまりない印象です。
そこで今回は、AWS Control Towerを利用したマルチアカウント環境を前提に、組織展開の観点で各セキュリティサービスの構成を整理してみました。
前提事項
対象者
本記事は、Control TowerとAWS Organizations、各セキュリティサービスの基礎を理解している読者を対象としています。
Control Tower
Control Towerの利用を前提とします。
また、ランディングゾーンのバージョンは4.0とします。
対象セキュリティサービス
本記事で扱うセキュリティサービスは以下の7つです。
- CloudTrail
- Config
- Security Hub
- GuardDuty
- IAM Access Analyzer
- Detective
- Inspector
当記事では、セキュリティサービスの組織展開を中心にまとめるので、各サービスの詳細なカスタマイズ設定に関しては触れません。
全体構成
マルチアカウント環境でセキュリティサービスを構成する際の基本方針は、以下の通りです。
- Control Tower統合、Organization統合により組織展開
- CloudTrail、Configは、Control Tower統合
- 上記以外のセキュリティサービスは、Organization統合
- Control Towerのリージョン拒否コントロールを設定した上で、管理リージョンのみセキュリティサービスを有効化
- ただし、管理アカウントは全リージョン有効化
- Auditアカウントをセキュリティサービスの委任管理アカウントとする
- Security Hubのリージョン集約機能で、検知結果を東京リージョンに集約する
- 最終的には全てのアカウントの検知結果がAuditアカウントの東京リージョンに集約される
Auditアカウントへの委任
委任管理者が設定できるAWSサービスについては、委任管理アカウントを設定することがベストプラクティスです。
新規にセキュリティサービスの委任管理アカウントを作成する形でも問題ありませんが、
Control Towerを利用している場合はAuditアカウントを委任管理アカウントを設定することがスタンダードです。
リージョン拒否について
Control Towerでは、管理リージョン以外でのAPIアクションを拒否する「リージョン拒否コントロール」を設定できます。
リージョン拒否コントロールには2種類あります。※1
| 種類 | 適用範囲 | 特徴 |
|---|---|---|
| ランディングゾーンリージョン拒否コントロール | Control Tower管理アカウント | シンプルだが例外設定ができない |
| OUリージョン拒否コントロール | OU単位 | 例外APIや例外IAMプリンシパルを設定可能 |
どちらのリージョン拒否コントロールを採用するかですが、基本的にはOUリージョン拒否コントロールの利用をおすすめします。
例えばBedrockでクロスリージョン推論を利用する場合、普段利用しないリージョンにもルーティングし、Control Towerのリージョン拒否コントロールとバッティングすることがあります。
(こちらの件は、後日執筆予定です。)
このようなケースに対応できるようにするため、例外条件や拒否リージョンをOU単位で設定できるOUリージョン拒否コントロールの利用を推奨します。
管理アカウントとメンバーアカウントの違い
管理アカウントにはSCPを適用できません。※2
Control Towerのリージョン拒否設定が反映されず、拒否リージョンでもAPIアクションが実行できます。
また、委任管理アカウント（Auditアカウント）上で、管理アカウントをメンバーとして統合すると、問題が発生します。
Security Hubのクロスリージョン集約設定において管理アカウントの拒否リージョンをリンクすることができず、管理アカウントの拒否リージョンのセキュリティ状況を監視することができません。
こちらの件は、下記の記事がわかりやすくまとまっております。
管理アカウントの監視対象リージョンをどのようにするか(拒否リージョンも監視対象に含めるか)検討する必要があります。
当記事では、管理アカウントは以下の方針で整理します。
- 委任管理アカウント（Auditアカウント）で、管理アカウントをメンバーとして統合しない
- 全リージョンでセキュリティサービスをスタンドアロンで有効化
- IAM Access AnalyzerとDetectiveは例外対応
- Inspectorに関しては、有効化自体任意
- Security Hub CSPMのリージョン集約機能で、検知結果を東京リージョンに集約
- 集約した検知結果を、クロスアカウントでEventBridgeに転送
ここからは、各サービスの設定について解説していきます。
各サービスの設定
CloudTrail
Control Tower統合により、組織の証跡を作成します。
作成される証跡は、組織の証跡、かつ、マルチリージョン証跡となるため、メンバーアカウントの管理リージョン、管理アカウントの全リージョンをカバーできます。
その他のセキュリティサービスのように管理アカウントで別途設定が必要となることはありません。
Config
メンバーアカウントと管理アカウントで設定内容が異なります。
| 項目 | メンバーアカウント | 管理アカウント |
|---|---|---|
| 有効化リージョン | 管理リージョンのみ | 全リージョン |
| Control Towerによる自動作成 | あり | なし |
| 設定変更 | 不可 | 可能 |
メンバーアカウントでは、Control Tower統合により管理リージョンのみでConfigレコーダーが作成されます。
Control Tower管理のリソースとなるため、記録対象リソースや記録頻度は基本的には変更できません。
管理アカウントでは、Control Tower管理のConfigレコーダーは作成されません。よって、別途レコーダーを作成する必要があります。
Control TowerがConfigに対して対応する設定と対応しない設定については、下記の記事がわかりやすくまとまっております。
管理アカウント上で、全リージョンでレコーダーを作成する方法についても紹介されておりますので、ぜひお読みください。
サービスリンクConfigアグリゲーターがAuditアカウントにControl Towerにより自動作成され、組織内の全アカウント（管理アカウント含む）のConfigレコーダーを集約します。
Security Hub
Security Hubは、CSPMとAdvancedという2つの機能を持っています。
両方を利用する場合は個別に設定が必要です。
画像引用：新しいAWS Security Hub（Advanced）と従来のAWS Security Hub（CSPM）をAWS Organizationsと絡めて整理してみた | DevelopersIO
Security Hub CSPMは、従来のSecurity HubのCSPM機能から独立して切り出された機能です。
組織展開には「中央設定」を使用し、Security Hub CSPM設定ポリシーでセキュリティ基準やコントロールの有効・無効、ポリシー適用リージョン・アカウントを統一管理できます。※4
Security Hub Advancedは、統合セキュリティソリューションとしてリブランドされたSecurity Hubとなります。
組織展開にはAWS Organizationsのマネージメントポリシー（Security Hub policies）を使用し、どのリージョンでAdvancedを有効化するかを設定できます。※5
CSPMとAdvancedは委任管理者を共有します。
一方のサービスで委任管理者を指定すると、もう一方でも同じアカウントが委任管理者になります。
ただし、有効化状態は独立しており、各機能は個別に有効化が必要です。
AWS Organizationの観点でCSPMとAdvancedをわかりやすく整理しているブログがありますので、ぜひお読みください。
ここからは、Security Hub CSPMの組織展開の方を中心にまとめます。
| 対象 | 展開方法 | 集約元リージョン | 集約先 |
|---|---|---|---|
| メンバーアカウント | Auditアカウント上の中央設定 | Control Tower管理リージョン | 東京リージョン |
| 管理アカウント | スタンドアロンで有効化 | 全リージョン | 東京リージョン |
Auditアカウント上でSecurity Hub CSPMの中央設定を設定し、メンバーアカウントに組織展開します。
ただし、「管理アカウントとメンバーアカウントの違い」セクションで記載した通り、
Security Hubのクロスリージョン集約設定において管理アカウントの拒否リージョンをリンクすることができません。
Security Hub CSPM設定ポリシーの適用対象アカウントから管理アカウントを除外し、管理アカウントはスタンドアロンでSecurity Hub CSPMを有効化します。
管理アカウントの全リージョンで有効化した後に、管理アカウント上リージョン集約設定を設定する形となります。
中央設定で管理されているメンバーアカウント上の検出結果に関しては、Organization統合により、Auditアカウントの東京リージョンのSecurity Hub CSPMに集約されます。
また、各アカウントのSecurity Hub CSPMに、Securty Hub CSPM以外のセキュリティサービスの検出結果が集約されるため、最終的に全アカウントのセキュリティサービスの検出結果がAuditアカウントに集約される形となります。
管理アカウントはスタンドアロンで管理しているため、AuditアカウントのSeucrity Hub CSPMにEventBridge経由で検出結果を転送する必要があります。
GuardDuty
Auditアカウント上で、管理アカウントを対象外とする組織レベルの自動有効化設定を設定します。※6
新規・既存のメンバーアカウントでGuardDutyが自動的に有効化され、Auditアカウントに検出結果が集約されます。
こちらの組織レベルの自動有効化設定は、各リージョンごとに設定が必要となります。
管理アカウントはSecurity Hubがスタンドアロンで管理しているため、それに合わせる形でGuardDutyもスタンドアロンで全リージョンに有効化します。
検出結果はSecurity Hubに統合され、リージョン集約機能により東京リージョンに集約されます。
IAM Access Analyzer
IAM Access Analyzerには3種類のアナライザーがあります。
- 外部アクセス検出: 組織外からアクセス可能なリソースを検出
- 内部アクセス検出: 組織内の他アカウントからアクセス可能なリソースを検出
- 未使用アクセス検出: 使用されていないIAMロールや権限を検出
内部アクセス・未使用アクセス検出のアナライザーは、分析対象リソースごとの課金となるため高額になりやすいです。IAMロールの棚卸しなど、必要なタイミングのみ有効化することをおすすめします。
当記事では外部アクセス検出のアナライザーを中心にまとめます。
Auditアカウントに組織レベルの外部アクセス検出のアナライザーを作成します。
信頼ゾーンを「組織」に設定することで、組織外からのアクセスのみを検出対象とします。
この構成の場合、メンバーアカウント上にアナライザー・アーカイブルールを作成する必要がありません。
ただし、組織内だとしても別アカウントからアクセスを検出したい場合は、各アカウントごとに信頼ゾーンが「アカウント」のアナライザーを作成する必要があります。
それぞれの構成のメリット、デメリットは、下記のブログでまとまっております。
要件がない限り、Auditアカウント上に信頼ゾーンを「組織」のアナライザーを作成する構成を推奨します。
信頼ゾーンを「組織」とした場合、管理アカウントも含め組織内すべてのアカウントが対象となります。
したがって、管理アカウントについては、管理リージョンと拒否リージョンで構成が異なります。
| リージョン | 構成 |
|---|---|
| 管理リージョン | Auditアカウントのアナライザー(信頼ゾーンが「組織」)で分析 |
| 拒否リージョン | 信頼ゾーンが「アカウント」のアナライザーを作成 |
管理リージョンにもアナライザーを作成すると、検出結果がAuditアカウントのアナライザーと重複します。
拒否リージョンのみ、管理アカウント上でアナライザーを作成する形となります。
Detective
Auditアカウント上で、組織レベルの自動有効化設定を設定します。※7
各リージョンごとに設定が必要です。
組織レベルの設定において管理アカウントをメンバーアカウントから外しても、管理アカウント上でDetectiveを有効化することはできません。
そのため、管理アカウントは以下の構成とします。
| リージョン | 構成 |
|---|---|
| 管理リージョン | Auditアカウント上で管理アカウントをメンバーとして追加 |
| 拒否リージョン | スタンドアロンで有効化 |
Inspector
Auditアカウント上で、AWS OrganizationsのマネージメントポリシーであるInspectorポリシーを作成し組織展開します。
こちらのInspectorポリシーは、Inspectorのどのスキャンタイプを有効化するか、そしてそのスキャンタイプをどのリージョンで有効化するかなど柔軟な設定ができます。
また、このポリシーはOU単位・アカウント単位でアタッチできるため、各アカウントで有効化するスキャンタイプを調整することが可能です。
画像引用：[アップデート]AWS OrganizationsにAmazon Inspectorのスキャン設定が柔軟に管理できる「Inspectorポリシー」が登場しました | DevelopersIO
管理アカウント上でもInspectorを有効化する場合は、管理アカウント用のInspectorポリシーを作成し、管理アカウントにアタッチする形となります。
ただし、AWSのベストプラクティスに従い管理アカウントにワークロードを構築していない場合は、Inspectorのスキャン対象（EC2、Lambda、ECR、コードリポジトリ）が存在しないため、有効化する必要性は低いです。
検出結果の通知基盤
AuditアカウントのSecurity Hub CSPMに集約された検出結果は、EventBridgeとSNSを通じて通知できます。
通知対象は以下の通りです。
- Security Hub CSPM: コントロール違反
- GuardDuty: 脅威検知
- IAM Access Analyzer: 外部アクセス検出
- Inspector: 脆弱性検知
ただEventBridgeとSNSだけだと、件名のカスタマイズや各メンバーアカウントへの通知振り分けなどができません。
SNSの前にStep Functionsを挟むことで上記の処理を実装することができます。
マルチアカウント環境のセキュリティサービスの通知基盤については、別記事で解説予定です。
さいごに
マルチアカウント環境におけるセキュリティサービス構成についてまとめてみました。
特に管理アカウントの扱いは、悩ましいところがあります。
あくまで私が思うベストな構成のため、要件に応じて適時変更していただくようお願いします。
この記事が、どなたかのお役に立てれば幸いです。
以上、クラウド事業本部の吉田でした！
参考資料
- ※1 Control Towerで設定可能な2種類のリージョン拒否コントロール（ランディングゾーン単位 or OU単位）
- ※2 【AWS Organizations】 管理アカウントにはSCPが適用されません | DevelopersIO
- Security Hub をリージョン集約・Organizations 統合する場合の管理アカウントについて考える | DevelopersIO
- AWS Security Hub を中央設定する場合の管理アカウントについて考える | DevelopersIO
- ※3 3. 作成されるAWSリソース | Members Service Specifications
- Control Tower 管理 CloudTrail をオプトアウトして CloudWatch Logs コストを削減 | DevelopersIO
- 【AWS Control Tower】ランディングゾーン v3.x へ更新する際のCloudTrailコスト周りの注意点 | DevelopersIO
- AWS Organization全体のCloudTrailの多重証跡を管理アカウントから一括チェック | DevelopersIO
- 【AWS Config】AWS Control Towerがやってくれる設定とやってくれない設定についてまとめました - サーバーワークスエンジニアブログ
- ※4 [アップデート]AWS Security Hubの組織への展開がセキュリティ標準やコントロールなどをカスタマイズして設定できるようになりました！ #AWSreInvent | DevelopersIO
- ※5 Security Hub policies - AWS Organizations
- 新しいAWS Security Hub（Advanced）と従来のAWS Security Hub（CSPM）をAWS Organizationsと絡めて整理してみた | DevelopersIO
- ※6 [アップデート] AWS Organizations でメンバーアカウントの GuardDuty 自動有効設定の方法が変わりました | DevelopersIO
- ※6 [アップデート] Amazon GuardDuty で Organizations の複数アカウントを管理する際に使える保護プランごとの自動有効化オプションが拡張されました | DevelopersIO
- Organizations統合とSecurity Hub統合 両方行っている場合の動作を確認してみた | DevelopersIO
- マルチアカウント環境におけるAWS IAM Access Analyzerの構成、通知方法、運用について考えてみた | DevelopersIO
- ※7 Amazon Detectiveの信頼されたアクセスを有効化してみる | DevelopersIO
- ※8 Organizations環境下のDetectiveをメンバーアカウントから見る方法 | DevelopersIO
- [アップデート]AWS OrganizationsにAmazon Inspectorのスキャン設定が柔軟に管理できる「Inspectorポリシー」が登場しました | DevelopersIO
