[Chalk talk] Architecting Security at Scale with AWS Cloud Governance に参加しました #COP312 #AWSreInvent

こんにちは、クラウド事業本部 コンサルティング部のいたくらです。
AWS re:invent 2025 は現地参加しています。

「Architecting Security at Scale with AWS Cloud Governance」に参加したのでレポートします。
Chalk talk セッションはスピーカーと参加者がインタラクティブにやりとりするため、聞き取れなかった部分もありますがご了承ください。

3 行まとめ

• NIST CSF などのフレームワークにアラインすることで、セキュリティの測定可能性と組織内での共通言語が得られる
• AWS Organizations と Control Tower を基盤として、委任管理者アカウントを活用することで大規模環境でもセキュリティサービスを一元管理できる
• ランサムウェア対策には AWS Backup によるイミュータブルバックアップと、ワークロードアカウントとは分離した専用アカウントでの保存が有効

セッション概要

• セッション ID: COP312
• タイトル: Architecting Security at Scale with AWS Cloud Governance
• スピーカー
  • Luis Pastor, Senior Security Solutions Architect, Amazon
  • Simone Pomata, Principal Solutions Architect, Amazon Web Services
• レベル: 300 - Advanced

Implementing consistent cloud governance and security capabilities across a growing AWS estate challenges many organizations, often leading to fragmented controls and security gaps. Learn how to develop and implement a comprehensive governance strategy that scales with your business needs as well as your security requirements. Using ransomware protection as a practical example, we'll explore how to architect a multi-account environment that balances security with operational flexibility. Discover how AWS Control Tower, IAM Identity Center, AWS Organizations, AWS Config, Amazon GuardDuty and AWS Backup work together to implement security controls at scale. Walk away with actionable insights on designing and deploying a secure foundation that not only protects against modern threats but maintains the agility your business demands.

（機械翻訳）
拡大する AWS 環境全体で一貫したクラウドガバナンスとセキュリティ機能を実装することは、多くの組織にとって課題であり、断片的な統制やセキュリティギャップにつながることがよくあります。ビジネスニーズとセキュリティ要件の両方に対応できる包括的なガバナンス戦略の策定と実装方法を学びます。ランサムウェア対策を実践的な例として、セキュリティと運用の柔軟性のバランスを取るマルチアカウント環境のアーキテクチャを探ります。AWS Control Tower、IAM Identity Center、AWS Organizations、AWS Config、Amazon GuardDuty、AWS Backup がどのように連携してセキュリティコントロールを大規模に実装するかを学びます。最新の脅威から保護しつつ、ビジネスが求めるアジリティを維持するセキュアな基盤の設計とデプロイに関する実践的な知見を持ち帰ることができます。

セッション内容

大規模環境でのセキュリティの課題

セッションの冒頭で、参加者への質問がありました。50 以上の AWS アカウントを管理している人、100 以上のアカウントを管理している人など、挙手で確認が行われ、多くの参加者がマルチアカウント環境を運用していることが分かりました。

大規模環境でセキュリティを実装する際の課題として、すべてのアカウントで一貫したコントロールをどう確保するかという点が挙げられました。また、手作業を避けながらポリシーを適用する方法や、何百ものアカウントにわたってリソースの状況をどう把握するかも議論されました。

これらの課題に対して、ランサムウェア対策を具体的なユースケースとして取り上げながら、解決策を探っていく構成でセッションは進みました。

セキュリティフレームワークへのアライン

スピーカーから、セキュリティ要件を実装する前にフレームワークにアラインすることの重要性が強調されました。フレームワークを使用するメリットとして、現在地と目標を測定できる「測定可能性」と、組織内でのコミュニケーションを促進する「共通言語」の 2 点が挙げられました。

セッションでは NIST Cybersecurity Framework 2.0 を例として使用し、その 6 つの機能（Govern、Identify、Protect、Detect、Respond、Recover）に沿って AWS サービスをマッピングしていきました。自組織のセキュリティツールがフレームワークのどこに位置づけられるかを理解することで、どの機能がカバーされていて、どこにギャップがあるかを把握できます。

4 つのコントロールタイプ

AWS で使用できるコントロールには、4 つのタイプがあります。

コントロールタイプ	説明	例
Preventive	非準拠な設定を事前にブロック	SCP
Proactive	IaC ツールと連携し、非準拠なデプロイをブロック	CloudFormation Hooks
Detective	非準拠なリソースを検出して通知	AWS Config ルール
Responsive	検出された問題を自動的に修復	Systems Manager Automation

これらのコントロールは連携して動作し、大規模なコンプライアンスの達成を支援します。

典型的な問題のある環境

セッションでは、ガバナンスが整備されていない環境の例が示されました。複数のアカウントがそれぞれ独立して存在し、セキュリティサービスの有効化状況もバラバラ、レガシーなアカウントには作成者がすでに退職しているものもある、という状態です。

参加者からは、この環境の問題点として、中央集権的なアクセス制御や可視性がないこと、監査ログがないこと、請求が分散していてボリュームディスカウントが受けられないことなどが挙げられました。

Organizations と Control Towerによる 基盤構築

これらの問題に対処する最初のステップとして、AWS Organizations と Control Tower の導入が提案されました。

Organizations を使用することで、管理アカウントからすべてのアカウントを統制し、セキュリティアカウントとログアーカイブアカウントを用意し、組織単位（OU）を使用してアカウントをグループ化できます。この構成により、セキュリティチームが1つのアカウントからすべてのダッシュボードを確認でき、ログが一元化されて監査が容易になり、請求の統合によるボリュームディスカウントも得られます。

セキュリティサービスの導入

基盤が整った後、NIST CSF の各機能に対応するセキュリティサービスを導入します。

サービス	機能（NIST CSF）	役割
IAM Identity Center	Govern	一元化されたアイデンティティ管理と最小権限の実現
AWS Config	Identify	リソースのインベントリ管理と設定のコンプライアンス確認
Security Hub	Respond	セキュリティ所見の集約と対応
Amazon GuardDuty	Detect	脅威検知と不審な行動の監視
AWS KMS	Protect	暗号化キーの管理とデータ保護

これらのサービスの一部（IAM Identity Center、AWS Config、CloudTrail）はControl Tower を有効化すると自動的にセットアップされます。GuardDuty や Security Hub は別途有効化が必要ですが、Control Tower のコントロールとして設定することで組織全体に展開できます。

委任管理者アカウントの活用

大規模環境でセキュリティサービスを管理するためのベストプラクティスとして、委任管理者（Delegated Administrator）アカウントの活用が紹介されました。

たとえば GuardDuty の場合、セキュリティアカウントを委任管理者として設定することで、1 つのアカウントからすべてのアカウントの GuardDuty を有効化・管理できます。新しいアカウントが追加されると自動的にGuardDuty が有効化され、個別アカウントのユーザーが GuardDuty を無効化することも防止できます。これは攻撃者による検知回避を防ぐ上で重要なポイントです。

ランサムウェア対策としての AWS Backup

ランサムウェア対策として、AWS Backup が紹介されていました。単にバックアップを取るだけでなく、攻撃者がバックアップを削除・暗号化できないようにするイミュータブル（変更不可）バックアップと、バックアップからの復旧が実際に機能することを確認する復旧テストが重要とのことです。

AWS Backup を Control Tower と統合する場合、2 つの専用アカウントを使用します。Backup Administrator Account は AWS Backup の委任管理者として監視データやレポートを集約し、Central Backup Accountはバックアップボールトとバックアップデータを保存します。バックアップを専用アカウントに保存することで、ワークロードアカウントが侵害されてもバックアップは安全に保たれます。

追加のセキュリティ対策

セッションの最後に、さらなるセキュリティ強化のために検討すべきサービスとして、セキュリティグループや WAF、Shield Advanced などを一元管理する AWS Firewall Manager、OS レベルの脆弱性検出を行うAmazon Inspector、アカウント間のデータ転送ルールを設定するネットワークの分離などが挙げられていました。

さいごに

大規模な AWS 環境でセキュリティを実装・維持することは簡単ではありませんが、NIST CSF のようなフレームワークを軸に、AWS Organizations と Control Tower を基盤として各種セキュリティサービスを組み合わせることで、スケーラブルなガバナンス体制を構築できることが分かりました。

特に印象的だったのは、ランサムウェア対策として AWS Backup を専用アカウントに分離し、イミュータブルバックアップを活用するというアプローチです。ワークロードアカウントが侵害されてもバックアップは安全という設計思想は、実際のインシデント対応を見据えた現実的な対策だと感じたので取り入れたいと思いました。

この記事がどなたかのお役に立てれば幸いです。
以上、クラウド事業本部 コンサルティング部のいたくら（＠itkr2305）でした！