AWS Security AgentのDesign Review(設計レビュー)を触ってみた

はじめに

re:Invent 2025で発表された新サービス AWS Security Agentの Design Review を触ってみたところ、非常に感動したのでシェアさせていただきます。

AWS Security Agent とは

AWS Security Agent は、設計からデプロイまでアプリケーションのセキュリティを継続的に検証できるサービスです。

具体的に以下のような検証を実施できます。

• Design Review 設計レビュー

セキュリティ要件とベストプラクティスに照らしてシステム設計を評価します。

• Code Review コードレビュー

プルリクエストのセキュリティ脆弱性や組織のセキュリティ要件への準拠を自動的に確認します。

• Penetration Test ペネトレーションテスト

オンデマンドのペネトレーションテストを通じて、セキュリティの脆弱性を自動的に発見、検証、修復します。

執筆時点ではバージニア北部でパブリックプレビューとして提供されています。

AWS Security Agent - AWS

Design Review(設計レビュー) Deep Dive

Security Agent Web アプリケーションからシステム設計書をアップロードすると、セキュリティ要件へのコンプライアンスが評価されます。

アップロード可能なファイル形式は次の通りです。
DOC、DOCX、JPEG、MD、PDF、PNG、TXT

レビュー結果には評価結果と併せて改善ガイダンスが記載されています。

AWSマネージドのセキュリティに加えて、組織の要件をカスタムのセキュリティ要件として追加することが可能です。

AWSマネージドのセキュリティ

セキュリティ要件名	説明
AuditLoggingBestPractices 監査ログのベストプラクティス	Ensurethesystemsupportsecuritymonitoring. システムがセキュリティ監視を行えるようにすること。
AuthenticationBestPractices 認証のベストプラクティス	Ensureonlylegitimateuserscanaccessthesystem. 正当なユーザーのみがシステムにアクセスできるようにすること。
AuthorizationBestPractices 認可のベストプラクティス	Ensuresystemsfollowauthorizationbestpractices. システムが適切な認可のベストプラクティスに従うことを保証すること。
InformationProtectionBestPractices 情報保護のベストプラクティス	Ensuresensitivedataremainsconfidentialandunaltered. 機密データが機密性を保ち、改ざんされないことを保証すること。
LogProtectionBestPractices ログ保護のベストプラクティス	Protecttheintegrityandconfidentialityofsystemlogs. システムログの完全性および機密性を保護すること。
PrivilegedAccessBestPractices 特権アクセスのベストプラクティス	Ensurethereareadequateguardrailsforprivilegedfunctions. 特権機能に対して十分なガードレール（統制）があることを保証すること。
SecretProtectionBestPractices シークレット保護のベストプラクティス	Ensurethatsecretslikecredentialsremainconfidential. 認証情報などのシークレットが機密性を保つことを保証すること。
SecurebyDefaultBestPractices デフォルトセキュアのベストプラクティス	Ensurethesystem'sdefaultconfigurationissecure. システムのデフォルト設定が安全であることを保証すること。
TenantIsolationBestPractices テナント分離のベストプラクティス	Ensureappropriateseparationbetweensystemtenants. システム内のテナント間が適切に分離されていることを保証すること。
TrustedCryptographyBestPractices 信頼できる暗号のベストプラクティス	Ensureonlytrustworthycryptographicimplementationsareused. 信頼できる暗号実装のみが使用されることを保証すること。

Design Review(設計レビュー)を触ってみる

次の要件をカスタムのセキュリティ要件に追加した上で、Security Agent Web アプリケーションからシステム設計書をアップロードして、セキュリティ要件へのコンプライアンスを評価します。

• 個人情報を取り扱うシステムではデータの転送中並びにデータの保管中は暗号化すること。なおデータの保管中はカスタマーマネージドキーで暗号化すること。

  • システム設計書では明示的にカスタマーマネージドキーを使用すると明記しないようにして、指摘されるかを確認します。

• VPCにパブリックサブネットを作成しないこと。

  • システム設計書ではCloudFront-ALB間はALBのセキュリティグループでCloudFrontマネージドプレフィックスリストを用いたアクセス制御でオリジン保護をするように記載して、改善ガイダンスでVPCオリジンが提案されるかを確認する。

検証準備(エージェントスペース作成 - カスタム要件追加)

• エージェントスペースを作成します。

ユーザアクセス設定はIAMアイデンティティセンターによるシングルサインオン(SSO)もしくはIAMユーザーから選べます。
IAMアイデンティティセンターによるシングルサインオン(SSO)はIAMアイデンティティセンターのアカウントインスタンスがエージェントスペースと同リージョン(=バージニア北部)にないとダメらしく...私は東京リージョンにIAMアイデンティティセンターのアカウントインスタンスを作成しているので、本検証ではIAMユーザを選びました。

• 左ペインからセキュリティ要件を押下します。

• カスタムセキュリティ要件を押下して、カスタムセキュリティ要件を作成を押下します。

個人情報を取り扱うシステムではデータの転送中並びにデータの保管中は暗号化すること。なおデータの保管中はカスタマーマネージドキーで暗号化すること。

項目名	パラメーター
セキュリティ要件名	Encryption of Personal Data (In Transit & At Rest with CMK)
説明	Systems that handle personal information must encrypt data both in transit and at rest. Encryption of data at rest must use customer-managed keys (CMK) rather than provider-managed default keys.
適用性	Systems that handle personal information
コンプライアンス条件	1. All data in transit must be protected using TLS 1.2 or higher. 2. All data at rest (including databases, object storage, backups, and logs) must be encrypted. 3. Encryption at rest must use customer-managed keys (CMK). 4. Key access control and key rotation must be defined and enforced.
是正ガイダンス - オプション	- In transit: Enforce HTTPS/TLS and block unencrypted connections. - At rest: Enable encryption and explicitly configure CMK in the encryption settings. - Key management: Restrict CMK access using least privilege and enable regular key rotation. - Existing data: Re-encrypt existing storage and databases using CMK.

VPCにパブリックサブネットを作成しないこと。

項目名	パラメーター
Security Requirement Name	Do Not Create Public Subnets in the VPC
Description	In VPCs hosting systems that process personal or confidential information, public subnets that route directly to an Internet Gateway must not be created. All subnets must be configured as private. If external network access is required, traffic must be routed through a dedicated boundary network or controlled transit environment.
Applicability	VPCs hosting systems that process personal or confidential information
Compliance Conditions	1. No subnet exists whose route table sends 0.0.0.0/0 to an Internet Gateway. 2. Subnets do not have automatic public IP assignment enabled. 3. Instances are not directly reachable from the internet. 4. External communications, if required, are routed through a dedicated boundary network or controlled transit path.
Remediation Guidance	- Convert any existing public subnets to private and remove routes to the Internet Gateway. - Reroute outbound traffic through a dedicated boundary network or controlled transit environment. - Enforce standard VPC templates that prohibit the creation of public subnets.

日本語と英語の同じカスタムのセキュリティ要件を作って比較してみたいと思います。

検証(設計書レビュー)

• エージェントスペースに戻り、ウェブアプリで開始を押下して AWS Security Agent にアクセスします。

• Create design review を押下します。

• システム設計書をアップロードして、Start design reviewを押下します。

本検証ではマークダウン形式のシステム設計書をアップロードしました。

• 左ペインからDesign reviewsを押下してレビュー結果を確認します。

レビュー完了までは1分もかかりませんでした。

Dowload reportからCSV形式のレポートをダウンロードできます。

• レビュー結果は次のステータスに分類されます。

ステータス	説明
Compliant 準拠	Your design meets the security requirement based on the analysis 分析に基づいて設計がセキュリティ要件を満たしている
Non-compliant 非準拠	Your design violates or inadequately addresses the security requirement 設計がセキュリティ要件に違反しているか、不十分に対応しています
Insufficient data データが不十分	The uploaded files lack enough information to determine compliance アップロードされたファイルにはコンプライアンスを判断するのに十分な情報が不足しています
Not applicable 該当なし	The security requirement doesn’t apply to your system design セキュリティ要件はシステム設計には適用されません

Review findings from a design review - AWS Security Agent

• ステータスがCompliant

• ステータスがNon-compliant

コメント

• 結果は「NON_COMPLIANT」です。システムは個人情報（会員管理/ユーザーデータ）を扱い、AWS KMSを使用した保存時暗号化を指定していますが、顧客管理キー（CMK）を明示的に設定していません。セクション8.4ではAWS KMSとSSE-KMSを使用したTDEを示していますが、これらは通常、CMKが明示的に指定されない限りAWS管理キーがデフォルトとなります。

改善ガイダンス

• 準拠を達成するには、セクション8.4のRDS TDEおよびS3 SSE-KMS暗号化において、AWS管理キーではなく顧客管理CMKを明示的に指定してください。さらに、キー管理設計においてCMKアクセス制御ポリシーを定義し、自動キーローテーションを有効化してください。

期待通り、カスタマーマネージドキーを指定するよう指摘されました。

日本語のカスタムのセキュリティ要件でもコメントと改善ガイダンスは英語で出力されます。
日本語と英語の同じカスタムのセキュリティ要件を作ってみましたが、英語の方が詳細な説明となっているように見受けられます。

比較

項目名	日本語	英語
コメント	The result is NON_COMPLIANT because the design explicitly creates public subnets (10.0.1.0/24 and 10.0.2.0/24) in a VPC that handles personal information (member data and payment information for an e-commerce site). The ALB is placed in these public subnets with direct internet routing via CloudFront, violating the requirement that all subnets must be private when handling sensitive data. 結果はNON_COMPLIANTです。設計上、個人情報（ECサイトの会員データおよび決済情報）を扱うVPC内に明示的にパブリックサブネット（10.0.1.0/24および10.0.2.0/24）が作成されているためです。ALBはこれらのパブリックサブネットに配置され、CloudFront経由でインターネットへの直接ルーティングが可能となっており、機密データを扱う際の「すべてのサブネットはプライベートであること」という要件に違反しています。	The result is NON_COMPLIANT because the design explicitly creates public subnets (10.0.1.0/24 and 10.0.2.0/24) that host the ALB with direct internet connectivity through CloudFront, while the system processes personal information (member data, payment information) as an e-commerce site. The network topology diagram shows ALB in public subnets with direct internet routing, violating the requirement that all subnets must be private when processing confidential data. 結果がNON_COMPLIANTとなる理由は、設計において明示的にパブリックサブネット（10.0.1.0/24および10.0.2.0/24）が作成され、CloudFront経由でインターネットに直接接続されたALBをホストしている一方で、システムがeコマースサイトとして個人情報（会員データ、決済情報）を処理しているためです。ネットワークトポロジ図では、ALBがパブリックサブネット内に配置され、インターネットへの直接ルーティングが設定されている。これは機密データを処理する際、すべてのサブネットをプライベートに保つという要件に違反している。
改善ガイダンス	To achieve compliance, you can redesign the architecture to place the ALB in private subnets and route external traffic through a dedicated boundary network or transit infrastructure (such as AWS Transit Gateway with inspection VPC, or a separate perimeter VPC with proxy/gateway services). コンプライアンスを達成するには、ALBをプライベートサブネットに配置し、外部トラフィックを専用の境界ネットワークまたはトランジットインフラストラクチャ（検査機能付きVPCを備えたAWS Transit Gateway、またはプロキシ/ゲートウェイサービスを備えた独立した境界VPCなど）経由でルーティングするようにアーキテクチャを再設計できます。	To achieve compliance, you can redesign the network to place all subnets as private and route external traffic through a dedicated boundary network such as AWS Transit Gateway or a separate boundary VPC with strict controls. Alternatively, if the data sensitivity assessment determines personal information is sufficiently protected at other layers, document this risk acceptance with appropriate compensating controls. コンプライアンスを達成するには、ネットワークを再設計し、すべてのサブネットをプライベートとして配置し、外部トラフィックをAWS Transit Gatewayなどの専用境界ネットワーク、または厳格な制御を備えた独立した境界VPC経由でルーティングします。あるいは、データ機密性評価により個人情報が他のレイヤーで十分に保護されていると判断された場合は、適切な補償的統制によりこのリスク受容を文書化します。

期待に反し、VPCオリジンは提案されませんでした。

是正ガイダンスにVPCオリジンに関する記載を追加してみたところ、改善ガイダンスでVPCオリジンが提案されました。

• ステータスがInsufficient data

• ステータスがNot applicable

最後に

自然言語でカスタムのセキュリティ要件を作成でき、かつシステム設計書をアップロードするだけで的確なレビューが返ってくる AWS Security Agent の Design Review には脱帽です。
ただ組織の要件を効率よくインポートできる機能があると使い勝手が良くなるかなーと感じたので今後のアップデートに期待してます。