AWS Security Agent で設計レビューをやってみた
こちらの記事は、TechBull Advent Calendar 2025の15日目の記事です。
はじめに
12月といえばアドベントカレンダー、そして AWS re:Invent の季節ですね！
今年も大量のアップデートがありましたが、個人的に気になったのが AWS Security Agent です。
今回は、このサービスを実際に触ってみたいと思います。
概要
まずはざっくり、このサービスが何者なのか整理しておきます。
AWS Security Agent は、re:Invent 2025 で Preview として発表された新しいセキュリティ機能です。
一言でいうと、
「アプリの『文脈』を理解して、設計からデプロイまで面倒を見てくれるAIエージェント」
です。
以下3つの機能を提供しています。
1. 設計セキュリティレビュー (Design Security Review)
コードを書く前の「設計段階」でリスクを見つけます。 アーキテクチャ図や仕様書を読み込み、「会社のセキュリティ要件（カスタムルール）」やAWSの推奨ルールに合っているか、AIが評価してくれます。
2. コードセキュリティレビュー (Code Security Review)
GitHub などのプルリクエストを監視します。 一般的な脆弱性（SQLインジェクションなど）のチェックはもちろん、「設計レビューで決めたルール」がコードでも守られているかを確認します。（例：「ログは90日保持」というルールをコードで破っていないか等）
3. オンデマンド侵入テスト (On-demand Penetration Testing)
「待ち時間なし」で実行できる自動ペネトレーションテストです。 設計書やコードから学んだ情報を元に、そのアプリ専用の攻撃プランをAIが作成。実際に攻撃を試行して、本当に危険な脆弱性がないかを検証します。
これまでの課題と Security Agent のアプローチ
これまでもセキュリティスキャンツールは様々あったかと思いますが、AWS 公式ブログでは従来のツール（SAST/DAST）を 「一次元的（One-dimensional）」 だと指摘しています。
従来のツールは「コードだけ」や「動作中のアプリだけ」を見て判断するため、「どういう意図で設計されたか」や「この会社特有のルールは何か」といった 「文脈（コンテキスト）」 を知りません。 そのため、一般的な脆弱性は見つけられても、顧客独自のコンプライアンス要件などはスルーされてしまい、結局は人間が時間をかけてチェックする必要がありました。
Security Agent は、そうした「コンテキスト」を認識し、アプリケーション全体を理解することで、単なる機械的なスキャンでは見つけられない、本当に必要なセキュリティチェックを実現してくれる点が特徴です。
今回検証すること
今回検証したいのは、この中の 「設計書のレビュー」 の機能です。
実際の案件ではAWSのベストプラクティスとは別に、会社や顧客ごとに定められた独自のセキュリティ要件が定められているケースが多くあります。
これに実装後やデプロイ直前で気づくと、手戻りが非常に大きくなります。
だからこそ、設計段階でセキュリティ要件を満たせているかのチェックができたら良いですね。
それでは、実際にやってみましょう。
セットアップ
マネジメントコンソールのSecurity Agentからセットアップを行なっていきます。
※ 現在は プレビュー版 のため、バージニア北部リージョンのみで利用できます。
※ プレビュー期間中は、AWS Security Agent は無料です。(料金については、AWS公式の最新の情報をご確認お願いします。)
セットアップとは言っても、エージェントの設定でエージェントスペース名を入れて、ユーザーアクセス設定を選択するのみです。
認証方式は、今回はIAM ユーザーを選択しました。
エージェントスペースが作成されました。
エージェントスペースを選択すると、設計レビュー、コードレビュー、ペネトレーションテストの項目があることがわかります。
AWS マネージドのセキュリティ要件
設計レビューのタブを見ると、あらかじめ以下の10つの AWS マネージドのセキュリティ要件 が設定されています。業界標準とベストプラクティスに基づいてAWSが作成・管理しているものです。
こちらは特に設定が不要で、デフォルトで有効化されているため、すぐに使い始めることができます。
| セキュリティ要件名 | 日本語 | 概要 |
|---|---|---|
| Audit Logging Best Practices | 監査ログのベストプラクティス | システム変更・アクセス試行・ユーザー操作を十分な詳細度で記録すること。記録漏れや詳細不足は違反。 |
| Authentication Best Practices | 認証のベストプラクティス | 明確で適切な認証メカニズムを定義すること。ハードコードされた認証情報や認証機能の欠如は違反。 |
| Authorization Best Practices | 認可・アクセス制御のベストプラクティス | 最小権限の原則に基づいたアクセス制御を行うこと。過剰な権限付与や区分の曖昧さは違反。 |
| Information Protection Best Practices | 情報保護のベストプラクティス | 機密データの保存・転送時に暗号化を行い、完全性を維持すること。 |
| Log Protection Best Practices | ログ保護のベストプラクティス | ログの改ざん防止、マスキング、適切な保持期間と安全な保管を行うこと。 |
| Privileged Access Best Practices | 特権アクセス管理のベストプラクティス | 管理者ロールを明確化し、特権操作を記録すること。過剰な特権は違反。 |
| Secret Protection Best Practices | シークレット保護のベストプラクティス | IAM ロールや専用サービスを活用し、コードへのハードコードを避けること。 |
| Secure by Default Best Practices | デフォルトセキュリティのベストプラクティス | 初期状態からパブリック禁止・暗号化有効など、最も安全な設定にすること。 |
| Tenant Isolation Best Practices | テナント分離のベストプラクティス | マルチテナント環境でのテナント間の境界を明確にすること。 |
| Trusted Cryptography Best Practices | 信頼された暗号化技術のベストプラクティス | 独自実装を避け、確立された暗号ライブラリと最新アルゴリズムを使用すること。 |
カスタムセキュリティ要件の作成
今回は一旦、マネージド要件を全て無効化し、カスタムセキュリティ要件を作成します。
よくある「顧客データは日本国内から出してはいけない」というケースを想定して、要件を入力していきます。
セキュリティ要件の詳細
コンソール上では英語で記載していますが、内容がわかりやすいようにこちらでは日本語で内容を書いています。
セキュリティ要件名
Japan Data Sovereignty Policy（日本データ主権ポリシー）
説明
法的なデータ主権要件に準拠するため、すべての機密顧客データが日本（東京）リージョン（ap-northeast-1）内にのみ存在することを保証します。国境を越えたデータ転送は禁止されています。
適用性
この要件は、Amazon S3、Amazon RDS、Amazon DynamoDB などのデータストレージサービスを含むすべてのアーキテクチャに適用されます。また、すべての環境（本番、ステージング、災害対策）に適用されます。
Compliance conditions（コンプライアンス条件）
非準拠 (Non-compliant):
- ap-northeast-1以外のリージョンにデータを保存するいかなる構成。
- 日本国外を宛先バケットとするS3 クロスリージョンレプリケーション(CRR)。
- 海外リージョンに配置されたデータベースのリードレプリカ。
準拠 (Compliant):
- データの保存場所がap-northeast-1に厳格に限定されている。
- レプリケーションは同一リージョン内 (Same-Region Replication)、または東京リージョン内でのマルチ AZ 配置のみで行われている。
上記の内容で作成させてみました。
有効なセキュリティ条件のタブから現在有効になっている要件のみを確認することができます。
設計レビューの実行
では、レビューを実施してみます。
ウェブアプリで開始をクリックします。
セキュリティエージェントのページに遷移して、Create design reviewsをクリックします。
ファイルは以下の形式をサポートしています。
今回はMDファイルの設計書と、PNGで保存した構成図のレビューを試してみます。
DOC, DOCX, JPEG, MD, PDF, PNG, TXT
設計書（テキスト）のレビュー
今回は AI で作成したMarkdown の簡易的な設計書を使用しました。
設計書には、以下のように DR 対策として us-east-1 へレプリケーションする 記述を含めています。
## 4. Disaster Recovery (DR) Strategy
To ensure business continuity in the event of a catastrophic failure in the Tokyo region (e.g., earthquake), we implement a robust DR strategy:
* **Cross-Region Replication (CRR):**
* We will enable S3 Cross-Region Replication.
* **Destination Region:** US East (N. Virginia) - `us-east-1`
* **Rationale:** N. Virginia is geographically distant from Tokyo, ensuring data safety even if the entire Japan region goes offline.
Start design reviewをクリックし、数分すると、Completeになりました。
結果を見るとしっかり非準拠と判定されています。
また、以下のように代替案も提案されました。
- 同一リージョン内バックアップ
- S3 バージョニング
- Multi-AZ
結果は、CSVでダウンロードが可能になっています。
構成図（画像）のレビュー
構成図（画像）でも同様に検証してみました。
ファイル名が日本語だとエラーになるようです。
英語名にすると問題なくレビューを行うことができました。
こちらも クロスリージョンレプリケーションが違反として検出されました。
まとめ
今回、テキストの設計書と画像の構成図の両方で検証しましたが、どちらも正しく解釈し、事前に設定したセキュリティ要件違反を検出してくれました。
特に印象的だったのは、「DR 対策のため」というもっともらしい理由が書かれていても
カスタムルールを優先して問題を指摘できた点です。単なる一般的なベストプラクティスではなく、与えられた要件の優先度や文脈を理解した上で判断していることが実感できました。
一方で、現状はセキュリティ要件をコンソール上でテキスト入力する必要があるため、ルールが多い組織では設定の手間や運用負荷が課題になりそうです。 既存の社内ガイドライン（PDF など）を直接読み込んで要件化できるようになれば、実用性が高まるかと感じました。
また、今回は比較的明確な表現で設計書を作成したため、より曖昧なニュアンスを含むドキュメントでも正しく判定できるのかは、今後試してみたいと思います。
設計段階での手戻りを防げるメリットは非常に大きいので、今後の機能拡充に期待しつつ、東京リージョンへの展開を待ちたいと思います！
Discussion