【ブースレポート】 クラウドガバナンスブースで SRA Verify による準拠度の可視化デモを見てきました
クラウド事業本部 コンサルティング部のいたくらです。
はじめに
AWS Summit Japan 2026 に参加してきました。本記事では、AWS Village 内のブース「守りと攻めを両立するクラウドガバナンス」（ブース番号: A122）を訪問した際のレポートをお届けします。
普段の業務で AWS Control Tower や Organizations といったガバナンス系サービスを扱っている身として、このブースはぜひ訪れたいと思っていました。実際にブースの方とお話しさせていただき、非常に学びの多い時間になりました。
三行まとめ
- ガバナンスは「開発の足かせ」ではなく「安心して開発を進めるための地盤」という考え方が印象的だった
- SRA Verify による SRA 準拠度のスコア化と可視化のデモが非常に分かりやすかった
- Kiro を活用して SRA Verify の結果からクイックウィン（即日実施可能な改善アクション）を導出するデモが実践的だった
ブースの概要
ブースは AWS Village 内の A122 に位置しており、2 台のモニターで資料とデモが表示されていました。
ブースのテーマは「守りと攻めを両立するクラウドガバナンス - AWS で実現するガバナンスとアジリティの共存」です。以下の内容が紹介されていました。
- AWS Control Tower で統制の基礎を整える
- Security Reference Architecture（SRA） で発展的なガバナンスのガイドラインを示す
- SRA Verify で SRA への準拠度をスコア化する
- BLEA（Baseline Environment on AWS） によるマルチアカウント構成の実装例
資料ではこれらが網羅的に紹介されていましたが、ブースでの説明は主に SRA Verify と Kiro を使ったデモが中心でした。
展示内容: マルチアカウント管理のベストプラクティス
資料では、まず Landing Zone の考え方とその実装方法が整理されていました。
Landing Zone とは、スケーラブルでセキュアなマルチアカウント環境のことで、AWS Control Tower はその実装方法の一つです。Landing Zone が持つべき機能として、以下の 6 つが挙げられていました。
- マルチアカウントの構成（AWS Organizations）
- アカウントの払い出し
- セキュリティベースライン
- ログイン情報の管理（認証と認可）
- ログ集約
- コスト管理
資料の中で印象的だったのは「Landing Zone で実現すべき機能や実装方法はここ数年大きく変化していない」という点です。ぜひ Control Tower を使ってください、とのことでした。一方で、新機能はより高いガバナンスを実現するためのもので必須ではない、という位置づけとされていました。
セキュリティベースラインと SRA
セキュリティベースラインについては、「マルチアカウント管理のセキュリティでやるべきことの全部は何か? と言われれば Security Reference Architecture（SRA）を参照するとよい」という説明がありました。
ただし、SRA に含まれるすべてを実装する必要はなく、通常はスタート地点として「基本的なセキュリティ」を実現すれば十分とのことです。ポイントとして、予防的・プロアクティブ・発見的（検出的）・レスポンシブの 4 つの統制をバランスよく構成することが推奨されていました。
また、Control Tower は基本的なセキュリティの中でも一部を実現しているにすぎないため、追加のサービスを利用してセキュリティベースラインを構成する必要があります。資料では、そのリファレンスとして BLEA（Baseline Environment on AWS）のベースラインが紹介されていました。
デモ: SRA Verify による準拠度の可視化
このブースで最も目を引いたのが、SRA Verify のデモンストレーションです。
SRA Verify は、Organizations 全体で各アカウントに対して SRA のチェック項目が満たせているかどうかを一覧化してくれるツールです。
ダッシュボードの概要
ダッシュボードの Overview では、チェック結果が一目で把握できるようになっていました。デモ環境では以下のような結果が表示されていました。
マインドマップによる組織全体の可視化
興味深かったのが、マインドマップ形式での可視化です。Organizations 全体のアカウント構成がツリー状に表示され、各アカウント、各リージョン、各サービスごとに SRA の準拠状況が色分けで示されていました。
- 緑: All Checks Pass
- 黄: Some Checks Fail（<50%）
- 赤: Most Checks Fail（>=50%）
組織管理者が SRA の準拠具合を見える化できるのは非常に便利だと感じました。
修正アクションの提示
チェックに失敗した項目に対しては「Key actions required」として、具体的な修正アクションが AWS CLI コマンド付きで提示されます。例えば、CloudTrail の CloudWatch Logs 連携の設定コマンドや、Macie の委任管理者設定のコマンドなどが表示されていました。
さらに、右上には「Copy generative AI prompt」というボタンがあり、検出結果を生成 AI に連携して対応の優先度付けなどに活用できるようになっていました。
個別チェック結果の詳細
Detailed findings のページでは、個別のチェック結果を確認できます。Status、Severity、Check ID、サービス名、リージョン、アカウント、Description、Actual Value が一覧で表示されており、フィルタリングも可能でした。
デモ: Kiro を活用したクイックウィンの導出
もう一つのデモとして、Kiro を使って SRA Verify の結果を分析し、即日実施可能なクイックウィンを導出するデモが行われていました。
画面上では、SRA Verify の結果を Kiro に食わせて、以下のようなクイックウィン（即日実施可能）の一覧が出力されていました。
実行コマンド例まで出力されており、例えば S3 Block Public Access については、対象アカウント ID を指定して aws s3control put-public-access-block を実行するスクリプトが示されていました。
SRA Verify でチェックして、その結果を Kiro に渡して修正アクションまで導出する、という一連の流れはとても実践的で、すぐにでも試してみたいと思いました。
ブースの方とお話しして印象に残ったこと
ブースの AWS の方と直接お話しする機会をいただき、いくつか印象に残った点がありました。
Control Tower のコントロールと Security Hub の使い分け
Control Tower のコントロールとSecurity Hub のコントロールは重複もある中で、どう使い分けるかという質問をさせていただきました。
基本的には、Control Tower のコントロールで満足できるのであれば Control Tower に全部寄せておく方がよいとのこと。一方で、Control Tower を管理する人と Security Hub を管理する人が異なるケースもあり、その場合はセキュリティを本格的に管理するチームが Security Hub 側で運用し、アカウント管理チームは Control Tower の必要最低限のコントロールだけを使う、という使い分けもあるそうです。
Control Tower と AWS Backup の統合
金融系のお客様を中心に、ランサムウェア対策としてバックアップの統制が重要なテーマになっているとのこと。Control Tower は AWS Backup と統合されており、3-2-1-1-0 バックアップルールに必要なバックアップアカウントやボールトの構成をある程度作り上げることができるそうです。Backup 統合はまだ試せていなかったので実際に触ってみようと思いました。
参考ドキュメント
- AWS Security Reference Architecture（AWS SRA）
- awslabs/sra-verify（GitHub）
- Baseline Environment on AWS（BLEA）
さいごに
普段の業務で Control Tower や Security Hub を触っているので、このブースの内容は非常に勉強になりました。
特に SRA Verify は、「SRA をやりましょう」と言われても「じゃあどうやって?」となりがちなところを、具体的にスコア化・可視化してくれるツールとして非常に有用だと感じました。さらに Kiro との組み合わせで修正アクションまで導出できるのは、実務でも活用しがいがあるなと思いました。
会場に足を運ばれる際は、ぜひ「守りと攻めを両立するクラウドガバナンス」（ブース番号: A122）にも立ち寄ってみてください！
この記事がどなたかのお役に立てれば幸いです。
以上、クラウド事業本部 コンサルティング部のいたくら（@itkr2305）でした！
