実践：AWS Security Hub & Amazon GuardDuty ~私有マルチアカウント環境の統制を最適化する~

Transcript

1. 実践：AWS Security Hub & Amazon GuardDuty ~私有マルチアカウント環境の統制を最適化する~
2. 実現したいこと • マルチアカウント環境にAWS Security HubとAmazon GuardDutyを適用する際、 できる限りコストを抑え、全アカウント・リージョンを監視 • シンプルな構成＆リソース数を最小限に • 脆弱性・脅威を検出した際は管理者にメール通知
3. 事前準備：Control Towerでランディングゾーンを設定 • 管理対象リージョン ◦ 米国東部 (オハイオ) ◦ 米国東部 (バージニア北部) ◦ アジアパシフィック (東京) ◦ 米国西部 (オレゴン)
5. ポイント①：メンバーアカウントをSecurity Hubで監視 • メンバーアカウントの全管理対象 リージョンで有効化 • 管理アカウントでは無効化 • Auditアカウントに委任
6. ポイント②：管理アカウントをGuardDutyで監視 • 管理アカウントの全リージョンで有 効化 • Auditアカウントに委任 →Security HubとGuardDutyが有効化さ れるリージョンを最低限にすることで、 Configルール数、ログ量を抑える
7. ポイント③ • 全リージョンに検出結果の生成を検 知するRule①を作成 • ホームリージョンに検出結果の集約 ＆通知用のRule②を作成 • 重要度>=0の場合に通知 →通知の仕組みを導入＆全リージョンの検 出結果をホームリージョンに集約し、リソー ス数を最小に
8. ポイント③(補足) EventBridgeとSNSはCloudFormation StackSetsでデプロイ • サービスマネージドアクセス許可 ◦ OUに属するアカウントの特定のリージョンにスタックをデプロイ (必ずOU IDの指定が必要) ◦ 事前準備不要 • セルフサービスのアクセス許可 ◦ 特定のアカウントの特定のリージョンにスタックをデプロイ ◦ cfn StackSets, cfnのサービスロールを事前に作成 →管理アカウントはOUに属さない(組織直下)ため後者
9. 困りごと 拒否リージョンではAWS Configが有効化されないため、コントロール[Config.1 AWS Config should be enabled and use the service-linked role for resource]の検出結果 においてコンプライアンスステータスがFAILEDになる。 • アカウントを作成するたびに手動でワークフローステータスを「抑制済み (SUPPRESSED)」にするのが面倒
10. 解決策：オートメーションルール 評価が実施されるタイミングで条件に合致した検出結果のステータスや重要度の変更、 メモの追加を自動で行う機能
11. オートメーションルールの動作確認 Account Factoryでメンバーアカウントを作成し、通知が来ないこと、コントロールステー タスが「成功」であることを確認 ※新規に生成される検出結果が評価対象であるため、既存の検出結果は手動で抑制 済みにする
12. 実現したいこと(振り返り) • ✅マルチアカウント環境にAWS Security HubとAmazon GuardDutyを適用する 際、できる限りコストを抑え、全アカウント・リージョンを監視 • ✅シンプルな構成＆リソース数を最小限に • ✅脆弱性・脅威を検出した際は管理者にメール通知 ※べスプラに則っていない箇所もあります
13. 今後 • Security Hubは生まれ変わったらしい ◦ AWS Security Hub Cloud Security Posture Management (CSPM) ◦ 「アタックパスの可視化」が注目機能？？ • Security Hubのセキュリティ標準とそのコントロールの内容を深堀 ◦ 今回はAWS Foundational Security Best Practicesのみ採用 • マルチアカウント環境のコストに配慮しつつべスプラの実践 ◦ IAM Access Analyzerが気になる
14. さいごに • Zenn https://zenn.dev/kubo_gene • X https://x.com/kubo_gene
15. End.