概要

AWS Security Agent は、設計〜コード〜デプロイまでの開発ライフサイクル全体でアプリケーションをプロアクティブに保護するためのエージェント型サービスです。 ①設計書レビュー、②コード解析、③ペネトレーションテストを統合し、脆弱性発見から修正提案までを自動化します。

主な特徴・メリット

• 設計段階でのセキュリティレビュー（ドキュメント解析）。
• プルリクエスト内での自動コード解析と修正提案。
• オンデマンドのペネトレーションテスト。
• プレビュー期間中なので無償利用可（期間未定）。

軽く触ってみる

ステップ 1 — AWS Security Agent のセットアップ

1. コンソールから AWS Security Agent を開く。

   仕組みの説明を見ると、ペネトレーションテストアプリケーションの項目だけが「オンデマンド」と記載されています。ペネトレーションテストは利用者が必要なタイミングで手動実行する形式っぽいですね。

   

2. AWS セキュリティエージェントをセットアップを押下。
   この画面では、エージェントスペース名の入力やアクセス方法の選択を行います。なお、アクセス方法で IAM ユーザーを選んだ場合、後から IAM Identity Center（SSO）方式へ切り替えることはできないため注意が必要です。
   

3. エージェントスペースが作成されたことを確認できました。
   
   今回、WEBアプリへのアクセスに使用する自分の IIC ユーザーを追加しておきました。
   

ステップ 2 — 設計レビューを試してみる

1. セキュリティ要件の確認
   マネージドセキュリティ要件として予め10個の要件が用意されているようです。
   
   カスタムセキュリティ要件では、1から要件を作成することも出来ますが、オプションの部分でマネージドセキュリティ要件を選択するとテンプレートを使用して作成することも可能です。
   

2. 実際にレビューしてもらう

   WEBアプリにアクセスして、テスト用の適当な設計書をアップロードしました。
   
   設計書の内容は以下です。

   WEBアプリケーション設計書
   
   目次
   1. システム概要
   2. アーキテクチャ構成
   3. セキュリティ要件に対する考慮点
   4. 想定される脅威と対策
   5. 今後の拡張
   
   1. システム概要
   本システムは、ユーザリクエストを API Gateway で受け付け、Lambda で処理を実行し、
   結果を DynamoDB に保存するサーバーレスアプリケーションである。高可用性・
   スケーラビリティを重視し、インフラ管理コストの最小化を目的とする。
   
   2. アーキテクチャ構成
   API Gateway：REST API エンドポイントを提供。HTTPS のみを許可。
   AWS Lambda：アプリケーションロジックを実行。
   Amazon DynamoDB：アプリケーションデータを保存。SSE-KMS による暗号化を利用。
   AWS Secrets Manager：API キーや資格情報を安全に管理。
   AWS CloudWatch：各種ログ・メトリクスを集約し監視を行う。
   AWS CloudTrail：すべての API アクティビティを記録する監査ログ機能。
   
   3. セキュリティ要件に対する考慮点
   3.1 IAM・アクセス管理
   IAM ユーザは使用せず、すべて IIC（IAM Identity Center）ベースの認証を利用。
   Lambda と DynamoDB のアクセスは IAM ロールによる最小権限を適用。
   KMS キーの利用権限は特定ロールのみに限定し、不必要な権限を排除。
   
   3.2 データ保護
   DynamoDB は SSE-KMS（AES-256）で暗号化。
   すべての通信経路は TLS 1.2 以上を使用。
   Secrets Manager で機密データを管理し、Lambda 環境変数には保持しない。
   
   3.3 ロギングと監査
   API Gateway、Lambda のログを CloudWatch Logs に集約。
   CloudTrail を全リージョン・全サービスで有効化。
   監査ログ保存用 S3 バケットはバージョニング・MFA Delete を有効化し、アクセスを厳格に制御。
   
   3.4 ネットワークセキュリティ
   内部通信は VPC 内（Lambda + VPC エンドポイント）で完結するよう構成。
   外部ネットワーク経由のアクセスを制限し、DynamoDB/S3 は VPC エンドポイント経由のみ利用。
   
   3.5 CI/CD セキュリティ
   GitHub での push 時に静的解析（SAST）と IaC（Terraform）スキャンを実施。
   資格情報のハードコードを防ぐスキャンルールを有効化。
   デプロイは AWS CodePipeline を利用し、署名付きアーティファクトを使う。
   
   4. 想定される脅威と対策
   不正アクセス：最小権限 IAM ロール + IIC 認証で対策。
   盗聴・改ざん：HTTPS/TLS1.2+ により保護。
   データ漏洩：SSE-KMS と Secrets Manager で暗号化。
   設定ミス：CI/CD による自動スキャンで未然に検知。
   ロギング不足：CloudWatch + CloudTrail による完全な監査証跡。
   
   5. 今後の拡張
   WAF の導入による L7 防御強化。
   セキュリティ要件の継続的レビューおよび Security Agent による定期診断の実施。
   Lambda のコード署名対応。

    

   レビュー後の画面はこんな感じです。
   レビュー自体は1,2分で終わりました。
   

   Insufficient dataとなったものを確認してみると具体的な改善策も記載されていました。
   

ステップ 3 — コードレビューを試してみる

1. GitHub連携
   
   次にコードレビューを試してみます。
   まずはコンソールからGithubの連携を行います。
   
   接続が完了しました。
   接続するだけだとコードレビューは有効にはならないみたいです。以下の画面から有効化してあげます。
   

2. 実際にコードレビューしてもらう
   
   それでは実際にコードレビューが動くか確かめていきます。
   プルリクエストを作成すると、すぐに以下のようなコメントが入りました。
   
   ここから4~5分待ってみると、指摘コメントが複数返ってきました。かなり丁寧にコメントしてくれてます。
   GitHub連携をしておけば、プルリクエストを作成するたびにSecurity Agentがコメントをしてくれる仕組みのようです。
   

ステップ 4 — ペネトレーションテストを試してみる

1. ドメインの検証

   まずはターゲットドメインの検証を行います。
   今回はサンプル用のWEBアプリを用意してペネトレーションテストを検証します。
   （ステップ3で使用したコードとは無関係です。）

   検証方法はHTTPルートと、DNSテキストレコードがあります。今回はDNSテキストレコードを選択しました。
   

2. WEBアプリからペンテスト設定

   次にWEBアプリを開き、Create a penetration testを押下し、設定を進めていきます。

   リスクタイプも柔軟に選択できるようです。
   

3. 実際にペネトレーションテストを実行してみる
   Start runを押下して実行します。
   
   Preflight → Static analysis → Pentest → Finalizing の順に進んでいきます。
   
   2時間くらい待つと全てCompletedになっていました。
   調査結果もかなり詳しく記載されています。
   

欲を言えば、レビューした設計書の内容とソースコードの内容に矛盾がないかのチェックもしてくれるといいな～と思いました。

ペネトレーションテストに関しては今までAWSネイティブのサービスで実施できなかった気がするので、これから有効活用していきたいです。