security-assessment

セキュリティ評価

ステップ 1：コンテキストの収集

ユーザーに次の質問をしてください。

セキュリティ評価の対象となるワークロードまたは AWS 環境を教えてください。次の情報を共有してください。

• ワークロード名と、分析対象のコードパッケージ／ディレクトリ
• コンプライアンス要件（SOC2、HIPAA、PCI-DSS、FedRAMP、GDPR など）
• 既知の懸念事項（任意）

すでにコンテキストが提供されている場合、または IaC を含むコードベースを確認している場合は、そのまま進めてください。

ステップ 2：ID とアクセス管理の調査

コードベース内のすべての IAM 設定を分析してください。

必ず次の項目を調査してください。

• IAM ロールの定義（信頼ポリシーと権限ポリシー）
• IAM ポリシードキュメント（管理ポリシーとインラインポリシー）
• サービスリンクロールと権限境界
• リソースベースのポリシー（S3 バケットポリシー、KMS キーポリシー、SQS ポリシー）
• Cognito／Identity Center の設定
• API Gateway のオーソライザー
• Lambda の実行ロール

IAM リソースごとに、次の項目を記録してください。

• ファイルパスと行番号
• 許可されるアクション（ワイルドカードにフラグを付ける）
• 対象となるリソース（ワイルドカードにフラグを付ける）
• 信頼関係（誰が引き受けられるか）
• 最小権限の原則に従っているか

必ず次の項目を HIGH RISK としてフラグを付けてください。

• 変更を伴うアクションでの "Action": "*" または "Action": "service:*"
• 書き込み／削除操作を許可するポリシーでの "Resource": "*"
• 条件が過度に広範なクロスアカウントの信頼関係
• 機密性の高い操作に対する Condition ブロックの欠落
• * プリンシパルにアタッチされた IAM ポリシー
• 長期間有効な認証情報（コードまたは設定内のアクセスキー）

ステップ 3：暗号化とデータ保護の調査

すべてのリソースにわたる暗号化設定を分析してください。

必ず次の項目を調査してください。

• KMS キーの定義とキーポリシー
• すべてのストレージ（S3、EBS、RDS、DynamoDB、EFS、Secrets Manager）の保管時の暗号化設定
• 転送中の暗号化設定（TLS 設定、リスナールール、セキュリティポリシー）
• 証明書の管理（ACM、自己署名）
• シークレットの管理（Secrets Manager、Parameter Store SecureString、環境変数）
• データ分類タグ

必ず次の項目を HIGH RISK としてフラグを付けてください。

• 保管時の暗号化が有効になっていないストレージリソース
• いずれかのリスナーまたはエンドポイントでの TLS 1.2 未満のバージョン
• 弱い暗号スイート（RC4、DES、3DES、MD5 ベースの MAC）を許可するセキュリティポリシー
• 本番環境の設定で使用されている自己署名または期限切れの証明書
• Secrets Manager／Parameter Store ではなく、環境変数、ハードコードされた文字列、または設定ファイルに保存されたシークレット
• ローテーションが有効になっていない KMS キー
• デフォルトの暗号化が設定されていない S3 バケット

ステップ 4：ネットワーク保護の調査

すべてのネットワークセキュリティ設定を分析してください。

必ず次の項目を調査してください。

• VPC の定義（サブネット、ルートテーブル、インターネットゲートウェイ）
• セキュリティグループのルール（インバウンドとアウトバウンド）
• ネットワーク ACL
• WAF ルールと Web ACL
• VPC エンドポイント（インターフェイス型とゲートウェイ型）
• NAT Gateway とその配置
• ロードバランサーのセキュリティ（リスナー、ターゲットグループ、セキュリティポリシー）
• API Gateway のエンドポイントタイプとスロットリング

必ず次の項目を HIGH RISK としてフラグを付けてください。

• 443／80 以外のポートでのセキュリティグループの 0.0.0.0/0 インバウンド
• SSH（22）または RDP（3389）でのセキュリティグループの 0.0.0.0/0 インバウンド
• データベースまたは内部サービスをホストするパブリックサブネット
• S3／DynamoDB 用 VPC エンドポイントの欠落（NAT／インターネット経由のトラフィック）
• インターネットに公開されたエンドポイントに WAF がない
• 過度に許可的なアウトバウンドルール（すべての宛先へのすべてのトラフィック）

---STOP--- チェックポイント：調査が完了しました。評価の前に、発見事項を提示してください。

セキュリティ態勢について、次の点を確認しました。

• IAM：確認されたロール、ポリシー、アクセスパターンの概要
• 暗号化：保管時および転送中の暗号化状況の概要
• ネットワーク：VPC、セキュリティグループ、WAF 設定の概要

セキュリティの完全な評価に進みますか。それとも、対象範囲を調整しますか？

ユーザーが明示的に確認するまで、この時点より先に進まないでください。

ステップ 5：検知と対応の調査

セキュリティ監視とインシデント対応の設定を分析します。

以下を必ず確認してください。

• CloudTrail の設定
• GuardDuty の有効化
• Security Hub の設定
• Config ルール
• VPC フローログの設定
• セキュリティイベント（ルートログイン、未承認の API 呼び出し）に関する CloudWatch アラーム
• 自動対応の設定（Lambda による修復、Step Functions）
• S3 アクセスログ記録

ステップ 6：コンピューティング保護の調査

コンピューティングのセキュリティ設定を分析します。

以下を必ず確認してください。

• Lambda 関数の設定（ランタイム、レイヤー、VPC 接続、予約済み同時実行数）
• ECS/EKS タスク定義（特権モード、ユーザー、機能、シークレットの注入）
• EC2 起動テンプレート（IMDSv2、ユーザーデータ、セキュリティグループ）
• コンテナイメージのソースとスキャン設定
• SSM セッションマネージャーの設定（SSH アクセスとの比較）

以下を高リスクとして指摘してください。

• 正当な理由なく、特権モードで実行されているコンテナ
• IMDSv1 が有効な EC2 インスタンス（IMDSv2 が必須ではなく、ホップ制限が 1 より大きい）
• VPC アクセスの範囲が広すぎる Lambda 関数
• コンテナイメージのスキャンが設定されていない
• SSM セッションマネージャーで代替できる場合に SSH アクセスが有効になっている

ステップ 7：WA フレームワークの質問に照らして評価する

質問ごとに、ステータス、証拠（ファイル:行）、不足事項、リスクを示してください。

SEC 1 — ワークロードを安全に運用するにはどうすればよいですか？

• 確認事項：セキュリティベースライン、アカウントの分離、脅威検出、自動対応
• 証拠：Config ルール、GuardDuty の設定、セキュリティ自動化

SEC 2 — 人とマシンのアイデンティティをどのように管理しますか？

• 確認事項：一元化されたアイデンティティ、ロールの分離、認証情報のライフサイクル、MFA の設定
• 証拠：Identity Center の設定、IAM ロールの信頼ポリシー、Cognito の設定

SEC 3 — 人とマシンのアクセス許可をどのように管理しますか？

• 確認事項：最小権限、アクセス許可の境界、アクセス分析、定期的なレビュー手順
• 証拠：IAM ポリシー、アクセス許可の境界 ARN、Access Analyzer の設定

SEC 4 — セキュリティイベントをどのように検出し、調査しますか？

• 確認事項：CloudTrail、GuardDuty、Security Hub、VPC フローログ、DNS ログ記録
• 証拠：トレイルの設定、検出器の設定、ロググループの定義、アラームルール

SEC 5 — ネットワークリソースをどのように保護しますか？

• 確認事項：VPC のセグメンテーション、セキュリティグループ、WAF、プライベートサブネット、VPC エンドポイント
• 証拠：VPC 構成要素、SG ルール、WAF ACL、エンドポイントの定義

SEC 6 — コンピューティングリソースをどのように保護しますか？

• 確認事項：パッチ適用、コンテナスキャン、ランタイム保護、最小限の権限
• 証拠：起動テンプレート、タスク定義、Lambda の設定、スキャン設定

SEC 7 — データをどのように分類しますか？

• 確認事項：データ分類タグ、機密性ラベル、データカタログの設定
• 証拠：リソースタグ、Macie の設定、Glue カタログの設定

SEC 8 — 保存データをどのように保護しますか？

• 確認事項：すべてのストアでの暗号化、KMS ポリシー、キーのローテーション
• 証拠：IaC 内のすべてのストレージリソースにおける暗号化プロパティ

SEC 9 — 転送中のデータをどのように保護しますか？

• 確認事項：TLS 1.2 以降の強制、証明書管理、HTTPS のみの使用
• 証拠：リスナーの設定、セキュリティポリシー、リダイレクトルール

SEC 10 — インシデントをどのように予測し、対応し、復旧しますか？

• 確認事項：対応の自動化、フォレンジック機能、封じ込め手順
• 証拠：修復用 Lambda、隔離手順、バックアップ設定

ステップ 8：リスク評価

各所見について、影響度 × 発生可能性で評価します。

影響度：軽微（データの限定的な露出、コンプライアンス違反なし） | 中程度（一部データの露出、軽微なコンプライアンス上の不備） | 重大（データの全面的な侵害、規制違反、権限昇格）

発生可能性：低（複数のエクスプロイトを組み合わせる必要がある、強力な補完的制御がある） | 中（中程度の労力で悪用可能、部分的な制御がある） | 高（容易に悪用可能、補完的な制御がない）

影響度	発生可能性	リスクレベル
重大	高	クリティカル
重大	中	高
重大	低	高
中程度	高	高
中程度	中	中
中程度	低	中
軽微	高	中
軽微	中	低
軽微	低	低

---STOP--- チェックポイント：評価が完了しました。レポートを生成する前に、所見を確認してください。

評価の概要：

• クリティカルな所見：{count}
• 高リスクの所見：{count}
• 中／低リスクの所見：{count}

セキュリティレポート全体を作成しますか？それとも、まず特定の所見について話し合いますか？

ユーザーが明示的に確認するまで、この時点より先に進まないでください。

ステップ 9：所見を作成する

# Security Assessment: {Workload Name}

## Executive Summary
- **Date**: {date}
- **Compliance Scope**: {frameworks}
- **Packages Analyzed**: {list}
- **Findings**: {X} Critical, {Y} High, {Z} Medium, {W} Low
- **Overall Security Posture**: {1-5} — {one-line justification}

## Security Scorecard
| Domain | Score (1-5) | Key Strength | Key Gap |
|--------|-------------|--------------|---------|
| Identity & Access | {score} | {strength} | {gap} |
| Data Protection (at rest) | {score} | {strength} | {gap} |
| Data Protection (in transit) | {score} | {strength} | {gap} |
| Network Protection | {score} | {strength} | {gap} |
| Compute Protection | {score} | {strength} | {gap} |
| Detection & Response | {score} | {strength} | {gap} |

## Critical and High Risk Findings
{For each: ID, domain, title, description, evidence (file:line), impact assessment, recommendation, effort, AWS services}

## Medium Risk Findings
{Same format, condensed}

## Low Risk Findings
{Summary table: ID | Domain | Title | Recommendation}

## Compliance Mapping
{If compliance requirements specified, map findings to relevant framework controls}
| Finding ID | SOC2 CC | HIPAA | PCI-DSS | Notes |
|------------|---------|-------|---------|-------|

## Prioritized Remediation Plan

### Quick Wins (< 1 week)
| Finding | Action | Impact | Effort |
|---------|--------|--------|--------|
{Enable encryption, tighten SG rules, rotate keys, fix TLS versions}

### Foundation (1-4 weeks)
| Finding | Action | Impact | Effort | Dependencies |
|---------|--------|--------|--------|--------------|
{Implement least privilege, add WAF, enable GuardDuty, add VPC endpoints}

### Strategic (1-3 months)
| Finding | Action | Impact | Effort | Dependencies |
|---------|--------|--------|--------|--------------|
{Zero-trust network, automated response, forensic capabilities, compliance program}

## Next Steps
{Top 5 concrete security actions the team should take this week}

ステップ 10：フォローアップを提案する

評価を提示した後、次の内容を提案します。

次の対応をご希望ですか？

• 特定のロール向けに最小権限の IAM ポリシーを設計する
• セキュリティ制御（GuardDuty、Security Hub、Config ルール）の IaC を生成する
• 特定の脅威に対するインシデント対応プレイブックを作成する
• 所見を特定のコンプライアンスフレームワークに詳細に対応付ける
• ネットワークセグメンテーションアーキテクチャを設計する
• 影響を最小限に抑えながら、特定のセキュリティグループルールを厳格化する

評価基準に関するガイダンス

• あらゆる箇所で暗号化を適用し、最小権限の IAM、VPC セグメンテーション、GuardDuty、Security Hub を備えたワークロードは成熟しています。強化、検知の精度、対応の自動化に注力してください
• すべての所見にはコード上の証拠が必須です。すでに有効かどうかを確認せずに「暗号化を有効にしてください」と指摘してはいけません
• プロトコルレベルのリスクを明示してください。TLS < 1.2 は常にクリティカルであり、脆弱な暗号スイートは常に高リスクです
• コンプライアンス要件が指定されている場合、クリティカル／高リスクのすべての所見を、関連するコンプライアンス管理策に対応付けてください
• 静的解析だけでは不十分な場合（例：実際の IAM 使用パターンの把握に Access Analyzer のデータが必要な場合）、「判定できません」は妥当です
• 不備を列挙する前に、優れたセキュリティ対策を明確に評価してください