概要
AWS Security Agentは、開発ライフサイクル全体を通じてアプリケーションのセキュリティを強化するためのサービスです。設計書やアーキテクチャドキュメントをレビューしてセキュリティリスクを特定するデザインセキュリティレビュー、リポジトリやS3上のソースコードを分析して脆弱性やポリシー違反を検出するコードセキュリティレビュー、稼働中のWebアプリケーションやAPIに対して多段階の攻撃シナリオで脆弱性を検出・検証するオンデマンドペネトレーションテストの3つの機能を備えています。
今回はこのうち、ペネトレーションテストとデザインレビューについて実際に試してみました。
セットアップ
まず、DevOpsエージェントと同様にエージェントスペースを作成します。AWSマネジメントコンソール側で初期設定を行い、その後はWebアプリケーションで操作していく流れとなります。
ペネトレーションテスト
コンソールでの設定
設定完了後、ペネトレーションテストを有効化します。この中でターゲットドメインを設定していきます。
- ターゲットドメインの追加 — テスト対象のドメインを入力します
- ドメイン所有権の検証 — 検証方法としてDNS TXTレコードを選択しました。Route 53を使用している場合は「ワンクリック検証」をクリックするだけで、ドメイン内にTXTレコードが自動作成され、所有権の確認が完了します
- VPCの設定 — セキュリティグループとサブネットの設定を行います（プライベートなアプリケーションをテストする場合に必要）
- サービスアクセスの設定 — エージェントがAWSリソースにアクセスするためのIAMサービスロールを選択します
これでペネトレーションテストが準備完了となりました。
Webアプリでの操作
ここからはWebアプリ側での操作になります。
- 「ペネトレーションテストを作成」をクリックします
- テスト名、ターゲットURL、IAMロール、VPCなどを設定していきます
- 必要に応じて認証情報を追加します
- ペネトレーションテストが作成されます
- 「実行を開始する」をクリックします
実行結果
ペネトレーションテストが実行されました。今回はタイムアウトとなり、実行結果は参考にできるものではありませんでしたが、「レポートを生成」をクリックするとレポートがダウンロードできます。
デザインレビュー
レビューの実施
こちらもWebアプリから操作していきます。
- Webアプリの「デザインレビュー」セクションを開きます
- 意図的にセキュリティ上の問題を多数含んだ設計書をMDファイルで作成し、アップロードします
# システム設計書: 社内ファイル共有Webアプリケーション
## 1. 概要
社内ユーザーがファイルをアップロード・ダウンロードできるWebアプリケーションを構築する。
顧客情報や財務データを含むファイルも取り扱う。
## 2. アーキテクチャ構成
### 2.1 ネットワーク構成
- VPC: 10.0.0.0/16
- パブリックサブネットのみ使用（プライベートサブネットは使用しない）
- すべてのリソースはパブリックサブネットに配置
- インターネットゲートウェイ経由で外部通信
### 2.2 コンピューティング
- EC2インスタンス (t2.micro) 1台構成（冗長化なし）
- OS: Amazon Linux 2
- Webサーバー: Apache (ポート80, HTTP)
- アプリケーション: Python Flask
- EC2にIAMロールを付与: AdministratorAccess ポリシーをアタッチ
- SSH接続用にポート22を0.0.0.0/0で開放
### 2.3 データベース
- RDS MySQL (db.t3.micro)
- パブリックサブネットに配置
- パブリックアクセス: 有効
- 暗号化: 無効
- Multi-AZ: 無効
- 自動バックアップ: 無効
- データベースのパスワード: admin123（ソースコードにハードコード）
### 2.4 ストレージ
- S3バケット: company-files-upload
- バケットポリシー: パブリックアクセス許可（全員がRead/Write可能）
- サーバーサイド暗号化: 無効
- バージョニング: 無効
- アクセスログ: 無効
- ライフサイクルポリシー: 未設定
### 2.5 認証・認可
- ユーザー認証: アプリケーション独自実装（Basic認証、HTTP通信）
- パスワードはMD5ハッシュでデータベースに保存
- セッション管理: Cookieに平文でユーザーIDを格納
- MFA: 未実装
- パスワードポリシー: なし（最小文字数制限なし）
## 3. セキュリティグループ設定
### EC2用セキュリティグループ
| タイプ | ポート | ソース | 説明 |
|--------|--------|--------|------|
| SSH | 22 | 0.0.0.0/0 | SSH接続用 |
| HTTP | 80 | 0.0.0.0/0 | Web公開用 |
| All Traffic | ALL | 0.0.0.0/0 | デバッグ用（本番でも残す） |
### RDS用セキュリティグループ
| タイプ | ポート | ソース | 説明 |
|--------|--------|--------|------|
| MySQL | 3306 | 0.0.0.0/0 | DB接続用 |
## 4. ログ・監視
- CloudTrail: 無効
- VPC Flow Logs: 無効
- CloudWatch: デフォルト設定のみ（カスタムメトリクスなし）
- アプリケーションログ: EC2ローカルディスクに保存（ローテーションなし）
- GuardDuty: 無効
- AWS Config: 無効
## 5. データ保護
- 通信の暗号化: なし（HTTPのみ、TLS/SSL未使用）
- 保存データの暗号化: なし
- KMSキー: 未使用
- 個人情報・機密データのマスキング: 未実装
## 6. デプロイ・運用
- デプロイ: 開発者がSSHでEC2に直接ログインし手動デプロイ
- IAMユーザー: 全開発者に共通のIAMユーザー（アクセスキー共有）
- アクセスキーのローテーション: 未実施
- ルートアカウント: 日常運用にも使用、MFA未設定
- セキュリティパッチ適用: 不定期（自動更新なし）
## 7. 災害対策
- バックアップ: なし
- DR戦略: 未定義
- シングルAZ構成
- Auto Scaling: 未設定
## 8. コスト管理
- 予算アラート: 未設定
- リソースのタグ付け: なし
- 未使用リソースの棚卸し: 未実施
レビュー結果
レビューが開始され、想定どおり非準拠の項目が多数検出されました。組織で有効化しているセキュリティ要件に基づいて分析が行われるため、カスタムのセキュリティポリシーを定義しておくことで、より実践的なレビューが可能になります。
