新機能である AWS Security Agent の Design security review（設計セキュリティレビュー）に関する検証を実施しました。定義されているセキュリティ要件に沿って設計書のセキュリティレビューを実施する機能で、ドキュメントや構成図の画像ファイルもレビューを実施できます。なお、検証したのは 2025年12月6～7日時点ですので、その時点での動作が前提です。
1. AWS Security Agent とは
AWS Security Agent は 2025年12月に開催された「AWS re:Invent 2025」の中で発表された新しい機能です。開発ライフサイクル全体にわたる包括的なセキュリティ機能を提供してくれます。
AWS公式ブログ：New AWS Security Agent secures applications proactively from design to deployment (preview)
具体的には以下の3つの機能が提供されます。
| 機能 | 説明 |
|---|---|
| Design security review 設計セキュリティレビュー |
・設計およびアーキテクチャドキュメントをレビューし、セキュリティリスクを特定します。 ・ウェブアプリケーションからドキュメントをアップロードすると、サービスが組織のセキュリティ要件に照らして分析します。 ・AWS Security Agent は、承認済みの認可ライブラリ、ログ記録標準、データアクセスポリシーなど、お客様が定義したセキュリティ要件への準拠を評価します。これにより、開発プロセスの早い段階で安全でない設計やポリシー違反を検出できます。 |
| Code security review コードセキュリティレビュー |
・コードリポジトリ内のコードを分析することで、言語、フレームワーク、アーキテクチャをまたいでセキュリティ上の脆弱性や組織のセキュリティ要件違反を特定します。 ・AWS Security Agent をリポジトリに接続すると、定義したセキュリティ要件に照らしてプルリクエストを自動的にレビューし、コードリポジトリプラットフォーム内で直接、具体的な改善ガイダンスを提供できるようになります。これにより、すべての開発チームでセキュリティポリシーを一貫して適用できるようになります。 |
| Penetration testing ペネトレーションテスト |
・カスタマイズされたマルチステップ攻撃シナリオを通じて、稼働中のウェブアプリケーションと API のセキュリティ脆弱性を検出、検証、報告、修正します。 ・テスト範囲、認証の詳細、リソースを指定して、ウェブアプリケーションを介した侵入テストを作成するようにサービスを設定します。 ・AWS Security Agent は、提供されたソースコードとドキュメントからアプリケーションコンテキストを作成し、高度な攻撃チェーンを実行することで、静的分析や従来のツールでは検出されない、悪用可能な脆弱性を特定します。また、すぐに実装できるコード修正を提供し、コードリポジトリに直接プルリクエストを作成することで、脆弱性をより迅速に解決できます。 |
この機能の中で気になったのが「Design security review」です。作成した設計書がセキュリティ要件に合致しているかレビューしてくれる機能です。
そのため、この記事では「Design security review」について検証します。
なお、機能の詳細な説明は「AWS Security Agent のユーザーガイド」をご確認ください。
2. Design security review （設計セキュリティレビュー）
「Design security review」は作成した設計ドキュメントの設計セキュリティレビューを実施してくれる機能です。操作方法について説明します。
2.1. 前提条件
まずは利用するにあたっての前提条件です。
現状、以下の条件があります。
| # | 前提条件 |
|---|---|
| 1 | Public preview です。正式リリース時には仕様が変更になる可能性があります。 |
| 2 | Public preview 期間中は無料で利用可能です（FAQ）。 |
| 3 | 利用できるリージョンは「米国(バージニア北部)(us-east-1)」のみです。 |
| 4 | 対応言語は明記されておらず英語と思われますが、日本語のドキュメントでも英語ドキュメントと同様にレビューができているので、日本語ドキュメントにも対応できているように見えます。ただし、本記事での検証は英語ドキュメントで実施しています。 |
| 5 | 同時にレビューできるファイルは最大5個です。 |
| 6 | アップロードできるファイル形式は DOC、DOCX、JPEG、MD、PDF、PNG、TXT です。 |
| 7 | 各ファイルは2MB以下で、全ファイルの合計は6MB以下である必要があります。 |
| 8 | モデルのトレーニングに顧客データを使用することはなく、顧客データをサードパーティと共有することもありません。 |
2.2. 初期設定方法
最初にエージェントスペースを作成する必要があります。
リージョン「米国(バージニア北部)(us-east-1)」で「AWS Security Agent」を選択します。
初期画面で「AWSセキュリティエージェントをセットアップ」を選択します。
エージェントスペース名を入力します。
ユーザーアクセス設定では IAMユーザーを選択します。
「AWSセキュリティエージェントをセットアップ」を選択します。
エージェントが作成されます。
エージェント名を選択します。
「ウェブアプリで開始」を選択します。
AWS Security Agent の Web画面が開きます。
2.3. 設計レビュー実施方法
Web画面で「Design reviews」を選択します。
「Create design review」を選択します。
Design review name を入力します。
レビュー対象のファイルをアップロードします。複数ファイルのアップロードも可能です。
「Start design review」を選択します。
レビューが実行されます。
レビューが完了すると Review status が「Completed」となり、レビュー結果が表示されます。
結果は画面上で確認でき、「Download report」を選択して CSV形式で出力できます。なお、レビュー結果は英語ですが、本記事では理解しやすいよう日本語に翻訳しています。また、「コメント」や「改善ガイダンス」は一部日本語表現がおかしい部分もありますが、原文のままで記載しています。
2.4. セキュリティ要件（マネージド）
レビューする際にチェックされるセキュリティ要件は AWS側で定義されています。AWS Security Agent 画面のナビゲーションバーで「セキュリティ要件」を選択すると、定義されているセキュリティ要件の一覧が表示されます。
初期では 業界標準に基づいてAWS側が準備したセキュリティ要件について10個表示されています。ここで有効化済みのセキュリティ要件がレビュー時に実行されます。それぞれのセキュリティ要件の内容は以下の通りです。
| セキュリティ要件 | 適用性 | 説明 | コンプライアンス条件 |
|---|---|---|---|
| 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 秘密保護のベストプラクティス |
シークレット、資格情報、API キー、トークン、またはその他の機密認証マテリアルを使用するシステムに適用されます。 | 資格情報などの秘密が機密に保たれていることを確認します。 | コンプライアンスに準拠したシステムは、既存の認証メカニズム（IAMロールやサービスアカウントなど）を活用することでシークレットの使用を最小限に抑え、必要なシークレットを専用の管理サービスに保存し、ローテーションポリシーを定義し、認証情報の失効手順を維持する必要があります。コンプライアンス評価を支援するために、システムが使用するシークレットの種類、それらの保存方法とローテーション方法、そして既存の認証メカニズムの代わりに新しいシークレットが必要な理由を文書で説明する必要があります。既存の認証メカニズムで十分な場合に不要な新しいシークレットを作成したり、シークレットを安全でない方法（コードや設定ファイルなど）で保存したり、ローテーションポリシーが欠如していたり、侵害された認証情報を処理するプロセスが存在しないシステムは、明らかにコンプライアンスに準拠していません。 |
| Secure by Default Best Practices デフォルトで安全なベストプラクティス |
構成可能なセキュリティ設定、リソース共有オプション、またはアクセス制御を備えたシステムに適用されます。 | システムのデフォルト構成が安全であることを確認します。 | 準拠したシステムは、制限的なセキュリティ設定から開始し、安全性の低い設定については明示的なオプトインを要求し、強力なセキュリティ機能（暗号化など）をデフォルトで有効にする必要があります。リソースはデフォルトで非公開にする必要があります。準拠性を評価するために、デフォルトのセキュリティ設定、自動的に有効になるセキュリティ機能、そしてセキュリティレベルを下げるためにユーザーが実行する必要がある明示的な手順をドキュメントに記載する必要があります。公開共有が有効になっている状態で開始したり、基本的なセキュリティ機能の利用にユーザーのオプトインを要求したり、デフォルトで許容的なアクセス制御を設定したりする場合、そのシステムは明らかに非準拠です。 |
| Tenant Isolation Best Practices テナント分離のベストプラクティス |
複数のテナントが共有インフラストラクチャまたはアプリケーション インスタンスを使用できるようにするシステムに適用されます。 | システム テナント間の適切な分離を確保します。 | コンプライアンスに準拠したシステムには、テナント間の明確な分離境界と、意図しないテナント間アクセスを防ぐための専用のセキュリティ制御が備わっている必要があります。コンプライアンス評価を支援するために、テナントデータとリソースがどのように分離されているか、テナント間のリソースアクセスを阻止するものは何なのか、そして共有インフラストラクチャがどのように不正使用から保護されているのかを文書で説明する必要があります。テナントが意図しない方法で他のテナントのデータにアクセスできるようにしている場合、または共有コンポーネントにバグを防ぐための分離制御が欠けている場合、システムは明らかにコンプライアンスに準拠していません。 |
| Trusted Cryptography Best Practices 信頼できる暗号化のベストプラクティス |
暗号化、復号化、ハッシュ、署名、キー管理などの暗号化操作を実装するシステムに適用されます。 | 信頼できる暗号化実装のみが使用されていることを確認します。 | 準拠システムは、確立された暗号ライブラリを使用し、カスタム実装を避け、適切な鍵管理を備えた強力な最新アルゴリズムを採用する必要があります。準拠性を評価するために、使用する暗号ライブラリまたはサービスと暗号鍵の管理方法を文書で規定する必要があります。カスタム暗号アルゴリズムを実装している、非推奨または脆弱なアルゴリズムを使用している、あるいは暗号鍵を安全でない方法で扱っているシステムは、明らかに非準拠です。 |
これは標準的なセキュリティ要件ですが、ユーザーごとに個別のセキュリティ要件が必要な場合もあります。それに対応するためにカスタムセキュリティ要件も準備されています。これは自分自身でセキュリティ要件を作成することができるもので、後ほど検証内容を記載します。
2.5. コンプライアンスステータス
レビュー結果画面ではセキュリティ要件ごとにコンプライアンスステータスが表示されます。ステータスは以下の４ステータスです。ドキュメントをレビューして「Compliant」「Not applicable」のみの結果を得ることが望ましいです。「Non-compliant 」があれば是正する必要がありますし、「Insufficient data」については判断に必要な情報が不足しているため、記載を追記する必要があります。
| 状態 | 説明 |
|---|---|
| 準拠 Compliant |
分析に基づいて設計がセキュリティ要件を満たしています。 |
| 非準拠 Non-compliant |
設計がセキュリティ要件に違反しており、対応が不十分です。 |
| データが不十分 Insufficient data |
アップロードされたファイルにはコンプライアンスを判断するための十分な情報が不足しています。 |
| 該当なし Not applicable |
セキュリティ要件はシステム設計には適用されません。 |
3. 設計書（ドキュメントデータ）のレビュー結果
それでは、実際に設計書（ドキュメントデータ）に対してレビューを実施してみます。
今回準備したサンプルの設計書は mdファイル形式です。記載した内容としては、パブリックサブネットに EC2 を設置してインターネットゲートウェイ経由でオンプレから RDP接続する前提としています。AWS Security Agent から指摘を受けるために、設計書にはあえて細かい記載をしていません。また、設計書は日本語ではなく英語記載の設計書を利用しています。
3.1. 当初レビュー結果
当初レビューの結果は以下の通りです。3つの 「Non-compliant 」 が指摘され、4つの項目が「Insufficient data」の状態でした。「Compliant」に至っては0件の状況です。
それぞれのセキュリティ要件の指摘内容は以下の通りです。
| セキュリティ要件 | 状態 | コメント | 改善ガイダンス |
|---|---|---|---|
| Audit Logging Best Practices 監査ログのベストプラクティス |
Non-compliant | システムはユーザー トラフィックを処理してアクションを実行する EC2 Web サーバーを提供しますが、監査ログ メカニズム (CloudTrail、VPC フロー ログ、アプリケーション ログ、または CloudWatch) が文書化されていないため、結果は NON_COMPLIANT になります。 | コンプライアンスを実現するには、API アクティビティのログ記録に AWS CloudTrail、ネットワーク トラフィックのモニタリングに VPC フロー ログを有効にし、EC2 インスタンスおよびアプリケーション レベルの監査ログに CloudWatch Logs を設定できます。 |
| Authentication Best Practices 認証のベストプラクティス |
Insufficient data | 結果はINSUFFICIENT_DATAです。ドキュメントにはユーザーにサービスを提供するEC2ウェブサーバーが記載されていますが、それらのユーザーの認証メカニズムが指定されていません。セキュリティグループはALBからのHTTPトラフィックと特定のソースからのSSHを許可していますが、エンドユーザーがウェブアプリケーションにどのように認証するか、または管理アクセスがどのように制御されるかについての情報が含まれていません。 | 明確にするために、Web アプリケーション ユーザーの認証メカニズム (OAuth、SAML、MFA を使用したユーザー名/パスワードなど) を文書化し、EC2 インスタンスへの管理アクセスがどのように認証および承認されるかを指定します。 |
| Authorization Best Practices 承認のベストプラクティス |
Insufficient data | 結果はINSUFFICIENT_DATAです。ドキュメントにはインフラストラクチャコンポーネントの説明が記載されていますが、ユーザーまたはクライアントがEC2インスタンスまたはウェブサーバーにアクセスするための認証方法や認可方法が明記されていません。セキュリティグループには、ALBからポート80が開かれていること、および特定のソースからのSSHが示されているものの、アプリケーションレベルの認可、IAMロール、またはアクセス制御メカニズムに関する記述がありません。 | 明確にするために、EC2 インスタンスの IAM ロール、ユーザーが Web アプリケーションに対して認証する方法、アプリケーション層に存在する承認制御などの承認モデルを文書化できます。 |
| Information Protection Best Practices 情報保護のベストプラクティス |
Insufficient data | 結果は INSUFFICIENT_DATA です。ドキュメントには、ユーザー データを処理する可能性のある Web サーバーが記載されていますが、保存/送信されるデータ、その機密性分類、保存時または転送中の暗号化などの保護メカニズムに関する情報が提供されていないためです。 | 具体的には、Web サーバーが処理するデータを文書化し、その機密性を分類し、暗号化方法 (転送には TLS、保存には EBS 暗号化など) とデータを保護するためのアクセス制御を指定できます。 |
| Log Protection Best Practices ログ保護のベストプラクティス |
Not applicable | 結果はNOT_APPLICABLEです。このドキュメントでは、基本的なAWSインフラストラクチャ（VPC、EC2、セキュリティグループ）について説明されていますが、システムがログの編集を必要とする機密情報を処理するかどうかについては言及されていません。このドキュメントでは、ログ記録については全く触れられておらず、アプリケーションのデータ処理特性についても説明されていません。 | |
| Privileged Access Best Practices 特権アクセスのベストプラクティス |
Non-compliant | 結果は NON_COMPLIANT です。セキュリティ グループが要塞ホストまたは特定の IP からの SSH アクセス (ポート 22) を許可していますが、それらが何であるかは定義されておらず、MFA、セッション ログ、EC2 インスタンスへの管理アクセスに対する最小権限の原則などの特権アクセス制御については言及されていないためです。 | コンプライアンスを実現するには、MFA 要件を含む要塞ホスト構成を指定し、直接 SSH の代わりに AWS Systems Manager Session Managerを実装し、セッションログやジャストインタイムアクセス制御などの特権アクセスポリシーを文書化します。 |
| Secret Protection Best Practices 秘密保護のベストプラクティス |
Insufficient data | 結果はINSUFFICIENT_DATAです。ドキュメントには、Webサーバーとして機能するEC2インスタンスについて記述されており、通常、認証にシークレットが必要ですが、シークレットの管理、保管、保護方法については何も記載されていないためです。セキュリティグループの設定には、要塞ホストまたは特定のIPからのSSHアクセスについて言及されており、認証情報ベースのアクセスが示唆されていますが、シークレットの取り扱いに関する詳細は記載されていません。 | 明確にするために、AWS Secrets Manager、AWS Systems Manager Parameter Store、またはサービス認証用の IAM ロールを使用するなど、シークレット (SSH キー、アプリケーション認証情報、API キー) がどのように保存および管理されるかを文書化できます。 |
| Secure by Default Best Practices デフォルトで安全なベストプラクティス |
Non-compliant | 結果はNON_COMPLIANTです。セキュリティグループsg-ec2は、要塞ホストまたは「特定のIP」からのSSHアクセス（ポート22）を許可していますが、そのIPアドレスが何であるかは定義されていません。また、0.0.0.0/0へのすべてのアウトバウンドトラフィックを許可しているため、アクセスが過度に緩和されています。このドキュメントでは、パブリックサブネット内のEC2インスタンスがインターネットに直接アクセスできることを示していますが、IMDSv2、暗号化されたEBSボリューム、SSHの代わりにAWS Systems Manager を使用するといったセキュアなデフォルト設定は指定されていません。 | コンプライアンスを実現するには、SSH アクセスの特定の IP 範囲を定義し、送信トラフィックを必要な宛先のみに制限し、EC2 インスタンスで IMDSv2 を有効にし、EBS 暗号化をデフォルトで有効にして、直接 SSH アクセスの代わりに AWS Systems Manager Session Manager の使用を検討します。 |
| Tenant Isolation Best Practices テナント分離のベストプラクティス |
Not applicable | このドキュメントでは、マルチテナントアーキテクチャや異なるテナント間の共有インフラストラクチャの証拠が示されていない、EC2 Web サーバーを備えた単純な AWS インフラストラクチャについて説明しているため、結果は NOT_APPLICABLE です。 | |
| Trusted Cryptography Best Practices 信頼できる暗号化のベストプラクティス |
Not applicable | このドキュメントでは、暗号化操作、暗号化、ハッシュ、署名、またはキー管理の実装については一切触れずに、基本的な AWS インフラストラクチャ (VPC、サブネット、EC2 インスタンス) について説明しているため、結果は NOT_APPLICABLE です。 |
監査ログやアクセス権については当初の設計書には記載がなく、そこを的確に指摘してくれています。そして、コメントとして指摘するだけでなく、改善ガイダンスも提供してくれるので、これに沿って設計書を修正・追記することができます。
3.2. 最終レビュー結果
その後、改善ガイダンスに沿って修正を繰り返し、最終的にすべての状態が**Compliant**にできた結果が以下の通りです。
それぞれのセキュリティ要件の指摘内容は以下の通りです。
| セキュリティ要件 | 状態 | コメント | 改善ガイダンス |
|---|---|---|---|
| Audit Logging Best Practices 監査ログのベストプラクティス |
Compliant | システムは包括的な監査ログを実装しており、ログファイルの整合性検証機能を備えたCloudTrail、7年間の保存期間と暗号化機能を備えたCloudWatch Logs、VPCフローログ、セッションマネージャーのセッションログ、そして重要なセキュリティイベントを検知するCloudWatchアラームなどが含まれています。すべてのログはIAMポリシーによってアクセス制御され、リソースにはテナントIDがタグ付けされているため、監査証跡は分離されています。 | |
| Authentication Best Practices 認証のベストプラクティス |
Compliant | システムは複数のユーザータイプにわたって認証のベストプラクティスを実装しているため、結果は準拠となります。IAMユーザーにはMFAの適用が必須（セクション3）、エンドユーザーはAmazon CognitoなどのOAuth/SAML準拠のアイデンティティプロバイダーを介して認証（セクション10）、プログラムによるアクセスにはAWS STS経由の一時認証情報を使用したIAMロールが使用されます（セクション8.1）。また、システムは特権アクセスにセッションマネージャーを適用し、要塞ホストにはIPベースの制限を適用します。 | |
| Authorization Best Practices 承認のベストプラクティス |
Compliant | 結果はコンプライアンスに準拠しています。なぜなら、ドキュメントのセクション8.1では、RBACの原則、ログに記録され監査可能な認可決定、重要な操作における職務分離、セッション管理におけるOWASP Top 10コンプライアンスなど、認可のベストプラクティスが明確に定義されているからです。システムは、これらのベストプラクティスを、一時的な認証情報のためのSTSを使用したIAMロール、マルチテナント分離のためのテナントID検証、そして7年間保持される包括的なCloudTrail/CloudWatchログを通じて実装しています。 | |
| Information Protection Best Practices 情報保護のベストプラクティス |
Compliant | システムは、保存時の暗号化 (EBS、KMS を使用した CloudWatch Logs)、転送中の暗号化 (強力な暗号スイートを使用した TLS 1.2/1.3)、FIPS 140-2/3 検証済み暗号化モジュール、AWS Secrets Manager によるシークレット管理と強制ローテーション、ログ内のデータ マスキング/編集、IAM および RBAC による厳格なアクセス制御を通じて、PII を含む機密データに対する包括的な保護を実装しているため、結果は準拠しています。 | |
| Log Protection Best Practices ログ保護のベストプラクティス |
Compliant | システムは、CloudWatch Logs に公開する前に機密データをマスキング/編集することでログの機密性に明示的に対処し (セクション 9.2)、CloudTrail ログ ファイルの整合性検証とバージョン管理および MFA 削除による不変のストレージを通じてログの整合性に明示的に対処しているため (セクション 8.2)、結果は準拠です。 | |
| Privileged Access Best Practices 特権アクセスのベストプラクティス |
Compliant | システムは包括的な特権アクセス制御を実装しており、これにはすべての特権IAMユーザーに対するMFAの適用、IPベースのアクセス制限、最小権限IAMポリシー、AWS Systems Manager Session Manager（SSHキー管理の排除）、職務分離を伴うロールベースのアクセス制御、すべての特権アクションの包括的なログ記録/監査が含まれます。これらの制御は、Infrastructure as Codeを通じて適用され、手動によるオーバーライドを防止します。 | |
| Secret Protection Best Practices 秘密保護のベストプラクティス |
Compliant | システムはAWS Secrets Managerによる包括的なシークレット保護と強制的な自動ローテーションを実装し、IAMロールを長期認証情報よりも優先することでシークレットの最小化を強制し、プレーンテキストやコードの埋め込みといった安全でない保存方法を明示的に禁止しているため、結果はコンプライアンスに準拠しています。設計には、侵害された認証情報の処理手順と安全なプロビジョニングメカニズムが含まれています。 | |
| Secure by Default Best Practices デフォルトで安全なベストプラクティス |
Compliant | 結果は準拠です。システムが Infrastructure as Code を通じて安全なデフォルト設定を明示的に義務付けており、セクション 8.4 では、MFA の適用、EBS 暗号化、KMS キーのローテーション、CloudTrail の有効化、セッション マネージャーなどのセキュリティ設定は「必須のデフォルト」であり、「IaC テンプレートを明示的に変更しない限り、手動で上書きまたは無効にすることはできません」と規定されています。このドキュメントでは、暗号化 (EBS 暗号化がデフォルトで有効化)、アクセス制御 (MFA の適用、最小権限)、ログ記録 (整合性検証付きの CloudTrail)、シークレット管理 (自動ローテーションが必須) など、複数のドメインにわたってデフォルトで安全であることが実証されています。 | |
| Tenant Isolation Best Practices テナント分離のベストプラクティス |
Compliant | 結果は準拠となります。この文書は、セクション8.3において、テナントIDの検証、タグ付けによる論理的な分離、セキュリティグループとNACLによるネットワーク分離、監査証跡の分離といった包括的な制御によって、マルチテナント分離について明示的に規定しています。このアーキテクチャは、アプリケーションレベルの制御、テナント識別のためのリソースタグ付け、そしてテナント間の厳格なネットワーク分離によって、多層防御を実現しています。 | |
| Trusted Cryptography Best Practices 信頼できる暗号化のベストプラクティス" |
Compliant | システムはすべての暗号化操作にFIPS 140-2/3検証済み暗号モジュールを必須とし、EBSおよびCloudWatch Logsの暗号化にはAWS KMS（FIPS 140-2検証済み）を指定し、アプリケーションレベルの暗号化にはFIPS検証済みプロバイダーを使用したAWS暗号化SDKまたは強制FIPSモードのOpenSSL FIPSモジュールのいずれかを必須としているため、結果は「準拠」となります。このドキュメントでは、検証されていない暗号ライブラリの使用を明示的に禁止し、業界標準のTLS暗号スイートを強制しています。 |
この結果を見ると、それぞれのセキュリティ要件を元に設計書をどうチェックして「Compliant」と判断したかが明確に理解できます。また、設計書の中のどのセクションに記載されていたかなどもレポートしてくれるので、該当箇所も認識しやすくなっています。
4. 設計図（画像データ）のレビュー結果
次は画像ファイルです。
レビューは Jpeg の画像ファイルに対しても実施することができます。
複数ファイル添付ができるので、本来はドキュメント＋画像データで登録することになりますが、いったん画像ファイルに対してどれくらいの読み取りができているか確認するため、次の構成図の Jpeg ファイルのみ読み込んでレビューを実施しました。
その結果は以下の通り、「Insufficient data」が 8件、「Not applicable」が2件となっています。
それぞれのセキュリティ要件の指摘内容は以下の通りです。
| セキュリティ要件 | 状態 | コメント | 改善ガイダンス |
|---|---|---|---|
| Audit Logging Best Practices 監査ログのベストプラクティス |
Insufficient data | 結果はINSUFFICIENT_DATAです。アーキテクチャ図にはRDP経由でアクセス可能なWindowsサーバーが示されていますが、監査ログ機能や設定に関する情報は提供されていません。システムは結果的なアクション（リモートサーバーアクセス）を処理しているように見えるため、要件は適用可能ですが、ドキュメントにはログ記録の実施方法に関する詳細な情報が記載されていません。 | 明確にするために、ログに記録されるイベント（認証試行、RDP セッション、管理アクション）、ログの保存場所、保持期間、ログの改ざん防止方法を文書化します。 |
| Authentication Best Practices 認証のベストプラクティス |
Insufficient data | 結果は INSUFFICIENT_DATA になります。図には、インターネットから RDP 経由でアクセス可能な Windows Server インスタンスが示されていますが、認証メカニズム、パスワード ポリシー、MFA 要件、またはアクセス制御に関する情報は提供されていないためです。 | 明確にするために、RDP アクセスの認証方法 (Active Directory、ローカル アカウントなど)、MFA が適用されているかどうか、パスワードの複雑さの要件、要塞ホストや VPN 要件などの追加のアクセス制御を文書化します。 |
| Authorization Best Practices 承認のベストプラクティス |
Insufficient data | 結果は INSUFFICIENT_DATA になります。アーキテクチャ図にはマルチユーザー システム (EC2 インスタンスに接続する RDP クライアント) が示されていますが、認証制御、アクセス ポリシー、またはユーザー権限の管理方法に関する情報が提供されていないためです。 | 明確にするために、ユーザーアクセスの制御方法、存在する権限レベル、RDP アクセスと AWS リソース権限に対して最小権限の原則が適用されているかどうかなど、承認モデルを文書化します。 |
| Information Protection Best Practices 情報保護のベストプラクティス |
Insufficient data | 結果は INSUFFICIENT_DATA になります。図には、インターネットから RDP 経由でアクセス可能な Windows サーバーが示されていますが、保存時の暗号化、転送中の暗号化、アクセス制御、データ処理方法などのデータ保護制御に関する情報は提供されていないためです。 | 明確にするために、どのような機密データが保存または送信されるか、保存中および転送中のデータはどのような暗号化メカニズムによって保護されるか、また、どのようなアクセス制御によって不正なデータアクセスや改ざんが防止されるかを文書化します。 |
| Log Protection Best Practices ログ保護のベストプラクティス |
Not applicable | このドキュメントは、ログ記録、機密データの処理、またはログ保護のメカニズムについての説明がなく、ネットワーク アーキテクチャを示すインフラストラクチャ図であるため、結果は NOT_APPLICABLE です。 | |
| Privileged Access Best Practices 特権アクセスのベストプラクティス |
Insufficient data | 結果は INSUFFICIENT_DATA になります。図には、特権アクセスを構成する RDP 経由でアクセス可能なパブリック IP を持つ Windows Server インスタンスが示されていますが、ガードレールやアクセス制御が文書化されていないためです。 | 明確にするために、MFA 要件、要塞ホスト、IP 許可リスト、セッション管理ポリシーなど、これらの Windows サーバーへの管理アクセスがどのように制御されるかを文書化します。 |
| Secret Protection Best Practices 秘密保護のベストプラクティス |
Insufficient data | 結果は INSUFFICIENT_DATA になります。アーキテクチャ図には、RDP 認証情報を必要とする可能性のある Windows サーバーと、API キーまたは IAM 認証情報を必要とする AWS リソースが示されていますが、ドキュメントにはこれらのシークレットの管理、保存、または保護方法に関する情報が記載されていないためです。 | 明確にするために、RDP アクセスと AWS API 認証の認証情報がどのように保存され (AWS Secrets Manager、パラメータストアなど)、ローテーションされ、アプリケーションと管理者によってアクセスされるかを文書化します。 |
| Secure by Default Best Practices デフォルトで安全なベストプラクティス |
Insufficient data | 結果は INSUFFICIENT_DATA になります。図には、インターネットに公開されているパブリック IP を持つパブリック サブネット内の Windows サーバーが示されていますが、デフォルトが安全かどうかを判断するセキュリティ グループ ルール、Windows ファイアウォール構成、または RDP アクセス制御が指定されていないためです。 | 明確にするために、デフォルトのセキュリティ グループ ルール、RDP が特定の IP に制限されているかどうか、および Windows サーバーに安全なベースライン構成が適用されているかどうかを文書化します。 |
| Tenant Isolation Best Practices テナント分離のベストプラクティス |
Not applicable | 結果は NOT_APPLICABLE です。ドキュメントでは 2 つの Windows Server EC2 インスタンスを含む単純な AWS インフラストラクチャについて説明しており、複数のテナントがインフラストラクチャまたはアプリケーション インスタンスを共有するマルチテナント システムを示していないためです。 | |
| Trusted Cryptography Best Practices 信頼できる暗号化のベストプラクティス |
Insufficient data | 結果はINSUFFICIENT_DATAです。これは、図にはRDP経由でアクセス可能なWindowsサーバーが示されていますが、暗号化操作で信頼された実装が使用されているかどうかが明記されていないためです。RDP接続では通常TLS/暗号化が使用されますが、このドキュメントでは、使用されている暗号化ライブラリ、アルゴリズム、またはキー管理方法の詳細は提供されていません。 | 明確にするために、使用されている暗号化ライブラリ (AWS 提供、OS ネイティブ、サードパーティ製など) を文書化し、RDP 接続の TLS バージョンと暗号スイートを指定し、キー管理のプラクティスについて説明します。 |
コメント欄を見ると、画像情報の内容については正確に理解できていることが分かります。画像だけで判断できている内容と、不足している内容を明確に指摘しています。本来は構成図だけですべてを記載することができないので、設計書（ドキュメント）＋構成図（画像データ）でレビューを実施することで、セキュリティ要件を満たすか確認する流れとなります。
5. カスタムセキュリティ要件の確認
5.1. カスタムセキュリティ要件の作成
AWS Security Agent が設計レビューする際に、組織の標準に合わせてカスタマイズしたり、カスタム要件をゼロから作成することが可能です。
今回の例では、「test-example Company」という会社の社内コンプライアンス要件として、AWS環境を構築する場合は東京リージョンに実施する必要があり、バックアップリージョンとして大阪リージョンを設定する必要があったとします。そのような組織に依存する個別の要件に関しては、カスタム要件として以下のように追加することが可能です。
AWS Security Agent のセキュリティ要件画面で「カスタムセキュリティ要件」を選択し、「カスタムセキュリティ要件を作成」を選択します。
カスタムセキュリティ要件を入力して、「セキュリティ要件の作成と有効化」を選択します。
なお、今回の入力内容は以下の通りです。
| 設定項目 | 内容 |
|---|---|
| セキュリティ要件名 | Custom Compliance for test-example Company |
| 説明 | Custom Compliance for test-example Company |
| 適用性 | It must be applied to the system for test-example Company. |
| コンプライアンス条件 | A compliant system must be built in a specified region.To that end, it must be designed with the Tokyo region as the main region and the Osaka region as the backup region.If any other region is used, the system is clearly not compliant. |
| 是正ガイダンス - オプション | Modify your design so that the main region is the Tokyo region and the backup region is the Osaka region. |
カスタムセキュリティ要件が作成されます。ここでセキュリティ要件のステータスが「有効化済み」になっている要件は、次回以降のレビュー時に対象となります。
5.2. 設計書（ドキュメントデータ）のレビュー結果
設計書（ドキュメントデータ）に関してカスタムセキュリティ要件のチェックについて確認します。確認する設計書は、先ほどすべてのセキュリティ要件が「Compliant」になった mdファイル形式の設計書です。
実施すると、追加したセキュリティ要件に対して以下の結果となります。
| セキュリティ要件 | 状態 | コメント | 改善ガイダンス |
|---|---|---|---|
| Custom Compliance for test-example Company test-example 社のカスタムコンプライアンス |
Not applicable | 結果はNOT_APPLICABLEです。なぜなら、このシステムがtest-example社向けであることは文書に記載されていないからです。プロジェクト名は「test-project」ですが、test-example社が顧客または利害関係者であることは記載されていません。 |
カスタムセキュリティ要件の設定画面にあった適用性で「test-example Companyのシステムに適用する必要があります。」と条件を設定しているため、その会社名が入っていない設計書なので状態が「Insufficient data」となっています。これは例えば別の会社名が記載されていた場合も、会社名が異なりますということで「Insufficient data」となります。
では、次は設計書（ドキュメントデータ）に会社名「test-example Company」を入れた上で再度レビューを実施します。
実施すると、以下の結果となります。
| セキュリティ要件 | 状態 | コメント | 改善ガイダンス |
|---|---|---|---|
| Custom Compliance for test-example Company test-example 社のカスタムコンプライアンス |
Non-compliant | 結果はNON_COMPLIANTです。ドキュメントでは東京（ap-northeast-1）をメインリージョンとして指定していますが、大阪をバックアップリージョンとして実装していないためです。要件では、test-example社において東京をメインリージョン、大阪をバックアップリージョンとして明示的に指定しています。 | コンプライアンスを実現するには、データのリージョン間レプリケーションやフェイルオーバー メカニズムなどの適切なマルチリージョン アーキテクチャ コンポーネントを使用して、大阪リージョン (ap-northeast-3) をバックアップ/DR リージョンとして追加できます。 |
会社名が合致しているためにレビューが実施され、バックアップリージョンとして大阪リージョンが設定されていないため、「Non-compliant」となっています。
では、最後に、バックアップリージョンとして大阪リージョンを追加した設計書（ドキュメントデータ）で再度レビューを実施します。
実施すると、以下の結果となります。
| セキュリティ要件 | 状態 | コメント | 改善ガイダンス |
|---|---|---|---|
| Custom Compliance for test-example Company test-example 社のカスタムコンプライアンス |
Compliant | ドキュメントのセクション 11 で、メイン環境として AWS 東京リージョン (ap-northeast-1)、バックアップ レプリケーションの環境として大阪リージョンが明示的に指定されているため、結果は準拠となります。会社はセクション 1 に記載されているように test-example 社であるため、この要件は適用可能であり、満たされています。 |
設計書（ドキュメントデータ）に追記した内容を読み取って、「Compliant」と回答がありました。
条件を満たしていることを回答してくれています。
5.3. 構成図（画像データ）のレビュー結果
構成図（画像データ）に関してもカスタムセキュリティ要件のチェックについて確認します。
まずは、先ほども確認した以下の構成図（画像データ）からです。
実施すると、以下の結果となります。
| セキュリティ要件 | 状態 | コメント | 改善ガイダンス |
|---|---|---|---|
| Custom Compliance for test-example Company test-example 社のカスタムコンプライアンス |
Insufficient data | 結果はINSUFFICIENT_DATAです。これは、ドキュメントにこのシステムがどの会社向けなのかが明記されていないためです。そのため、東京をメインリージョン、大阪をバックアップリージョンとして必要とするtest-example社のシステムなのか判断できません。図では東京リージョン（ap-northeast-1）が使用されているように見えますが、バックアップリージョンと会社情報は示されていません。 | 明確にするために、このシステムがどの会社にサービスを提供しているかを示すドキュメントを追加し、test-example社向けであればメインリージョン (東京) とバックアップリージョン (大阪) の両方を指定できます。 |
適用性で「test-example Companyのシステムに適用する必要があります。」と条件を設定しているため、その会社名が入っていない画像なので状態が「Insufficient data」となっています。
では、次は会社名「test-example Company」を入れた以下の構成図（画像データ）で再度レビューを実施します。
こちらを実施すると、以下の結果となります。
| セキュリティ要件 | 状態 | コメント | 改善ガイダンス |
|---|---|---|---|
| Custom Compliance for test-example Company test-example 社のカスタムコンプライアンス |
Non-compliant | ドキュメントには、メインリージョンとして東京リージョン (ap-northeast-1) にシステムがデプロイされていると記載されていますが、要求されているように大阪にバックアップ リージョンが設定されていないため、結果は NON_COMPLIANT になります。 | コンプライアンスを実現するには、適切な災害復旧または高可用性構成を使用して、大阪リージョン (ap-northeast-3) にバックアップ リージョンの展開を追加できます。 |
会社名が合致しているためにレビューが実施され、バックアップリージョンとして大阪リージョンが設定されていないため、「Non-compliant」となっています。
では、最後に、バックアップリージョンとして大阪リージョンを追加した以下の構成図（画像データ）で再度レビューを実施します。
こちらを実施すると、以下の結果となります。
| セキュリティ要件 | 状態 | コメント | 改善ガイダンス |
|---|---|---|---|
| Custom Compliance for test-example Company test-example 社のカスタムコンプライアンス |
Compliant | アーキテクチャ図では、東京リージョン (ap-northeast-1) がメインリージョン、大阪リージョン (ap-northeast-3) がバックアップリージョンとして示され、それらの間でレプリケーションが実行されているため、結果は準拠です。 |
構成図（画像データ）の読み取り、「Compliant」と回答がありました。
条件を満たしていることを回答してくれています。
このように、ユーザに合わせたセキュリティ要件の運用が可能です。
6. 日本語ドキュメントの対応について
AWS Security Agent の資料を見る限り、明確に日本語のドキュメントに対応していると記載されていません。ただ、同じ内容の英語と日本語の設計書をレビューさせた結果が以下の通りです。
※設計書（英語版）のレビュー結果
※設計書（日本語版）のレビュー結果
日本語のドキュメントの場合でも英語のドキュメントと同じ結果となり、記載されているコメントも日本語設計書の内容を理解して回答した内容になっていました。その為、日本語のドキュメントでも対応ができそうです。
7. まとめ
AWS Security Agent は 2025年12月に新しく発表された機能です。Design security review （設計セキュリティレビュー）はこれまでに無かった機能であり、設計書の精度を向上させるために活用できそうです。
今回は無料期間ということで色々と触りましたが、ドキュメントの内容をある程度理解してコメントや改善ガイダンスを返信してくれるところや、画像データの内容も理解してレビュー結果に反映してくれるところなどが確認できました。
また、カスタマイズセキュリティ要件を追加して、ユーザ個別の要件を設定できるところは非常によかったです。ユーザごとに求める内容が異なる場合もあり、それに対応したチェックを設定することで、ユーザ個別のレビュー環境を準備することができます。
現状は「public preview」の段階ですが、GAされるのが楽しみな機能です。