AWSセキュリティ設計ハンドブック

周辺資料: 学習インデックス · AWSサービス一覧（2026） · インシデントレスポンス設計 · IAM最小権限設計

AWSセキュリティ設計の7つの柱と実装パターン。

1. セキュリティ設計の7本柱

1. ID・アクセス管理 (IAM)
   誰が・何に・どのようにアクセスできるかを最小権限で制御

2. 検知 (Detection)
   GuardDuty / Security Hub / Config で異常・逸脱を検知

3. インフラ保護 (Infrastructure Protection)
   VPC / SG / NACL / WAF / Shield で境界を保護

4. データ保護 (Data Protection)
   KMS / Macie / S3 Object Lock でデータを保護

5. インシデント対応 (Incident Response)
   検知 → トリアージ → 封じ込め → 根絶 → 復旧を自動化

6. 脆弱性管理 (Vulnerability Management)
   Inspector / ECR Scan / Patch Manager で継続的に管理

7. アプリケーションセキュリティ (Application Security)
   WAF / Cognito / API Gateway 認証・認可設計

2. ID・アクセス管理（IAM）

設計原則

[最小権限の原則]
  × Action: "*" の使用禁止（緊急用 BreakGlass ロールを除く）
  ◯ 必要なアクション・リソース・条件を明示

[ロールベースアクセス制御]
  × IAM ユーザーにポリシーを直接アタッチ
  ◯ IAM グループ → ポリシー
  ◯ IAM ロール（人間は IAM Identity Center 経由）

[一時的な認証情報]
  × IAM ユーザーのアクセスキーを長期使用
  ◯ ロールの AssumeRole + 一時的トークン
  ◯ Lambda / ECS / EC2 には IAM ロールを直接アタッチ

よく使うポリシーパターン

// リソースベース条件付きアクセス（特定 VPC からのみ S3 許可）
{
  "Effect": "Deny",
  "Action": "s3:*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:SourceVpc": "vpc-xxxxxxxxx"
    }
  }
}

// IAM PassRole の最小化（特定ロールのみ Pass 可能）
{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::123456789:role/MySpecificRole"
}

Permission Boundary（権限境界）

用途: 開発者に IAM 操作を委任しつつ、付与できる最大権限を制限する

設定例:
  管理者がPermission Boundaryポリシーを作成（"最大これまで"）
  開発者がIAMロールを作成する際、このBoundaryを指定必須に
  → 開発者が Admin ポリシーをアタッチしても Boundary 内の権限のみ有効

3. 暗号化設計

KMS エンベロープ暗号化

[仕組み]
  1. KMS が CMK（Customer Managed Key）を管理
  2. データ暗号化キー（DEK）を CMK で暗号化して保存
  3. 実際のデータは DEK で暗号化（CMK で直接暗号化しない）

[利点]
  - CMK はオフプレミスのハードウェア（CloudHSM）に保管可能
  - キーローテーション時も過去データを復号可能
  - アクセスポリシーで誰が暗号化/復号できるかを制御

キーの種類と使い分け

S3 暗号化オプション

• SSE-S3 (AES-256): AWS管理キー。最もシンプル
• SSE-KMS: CMK使用。監査証跡（CloudTrail）・アクセス制御が必要な場合
• SSE-C: お客様がキーを管理・提供。AWSにキーを渡したくない場合
• DSSE-KMS: 2重暗号化。CNSSI/NSA Suite B 準拠が必要な場合

4. ネットワーク保護

多層防御アーキテクチャ

インターネット
    │
  Route 53（DNS Firewall で悪意ドメイン遮断）
    │
  CloudFront + WAF（L7: SQLi/XSS/レートリミット/地理制限）
    │
  Shield Advanced（L3/L4 DDoS 軽減）
    │
  ALB / NLB
    │
  Security Group（インスタンスレベルのステートフルフィルタ）
    │
  NACL（サブネットレベルのステートレスフィルタ）
    │
  EC2 / ECS / Lambda（アプリ）
    │
  RDS / DynamoDB（プライベートサブネット）

WAF ルール設計

[推奨ルールセット（優先度順）]
  1. AWS マネージドルール（OWASP Top 10 対応）
  2. レートベースルール（例: 同一IP から5分間に2000リクエスト超でブロック）
  3. 地理的ブロック（アクセス元国を制限）
  4. カスタムルール（特定URI パターン / ヘッダーでの制御）

[モード]
  まず Count モードで影響を確認 → Block モードに切替
  過検知が多い場合は Scope-Down Statement でスコープ絞り込み

VPC セキュリティ設計

パブリックサブネット:
  ✓ ALB / NLB
  ✓ NAT Gateway
  × EC2 インスタンス（原則配置しない）
  × データベース

プライベートサブネット:
  ✓ ECS Fargate / Lambda
  ✓ EC2 アプリサーバー
  ✓ ElastiCache

分離サブネット（インターネット/NATへの経路なし）:
  ✓ RDS / Aurora
  ✓ 機密データを扱うサービス

5. 脅威検知と自動対応

検知サービスの役割分担

GuardDuty 検出結果への自動対応

[自動対応フロー]
  GuardDuty 検出 → EventBridge → Lambda（自動対応）
                                    │
                     Severity >= 7（HIGH/CRITICAL）
                                    │
                     ┌──────────────────────────────┐
                     EC2 隔離      IAMキー無効化     S3 ブロック
                     SG 変更で     AccessKey         Public Access
                     インバウンド  Deactivate        Block 有効化
                     遮断          + SNS 通知        + SNS 通知
                     + スナップ
                     ショット
                     └──────────────────────────────┘
                                    │
                               SNS → PagerDuty / Slack
                               Systems Manager OpsCenter 起票

6. ゼロトラストアーキテクチャ

従来境界防御 vs ゼロトラスト

[従来の境界防御]
  「VPC 内は安全」という前提
  外部: 厳しく制限 / 内部: 緩い制御
  リスク: 内部不正・横移動攻撃に弱い

[ゼロトラスト]
  「すべてのアクセスは潜在的に悪意あり」
  ユーザー / デバイス / リソースを常に検証
  最小権限 + 継続的モニタリング

AWS Verified Access の設計

[従来のリモートアクセス]
  ユーザー → VPN（社内ネットワーク全体へのアクセス）

[Verified Access]
  ユーザー → Verified Access（IdP + デバイス姿勢評価）
               → アクセスポリシーで個別アプリへのみ許可
               → VPN 不要、最小権限で内部アプリに接続

[Cedar ポリシー例]
permit(
  principal in Group::"engineering",
  action == Action::"access",
  resource == Application::"internal-tools"
) when {
  context.device.compliance == "Compliant"
  && context.network.type == "corporate"
};

7. マルチアカウントのセキュリティ統制

Security OU 構成

Organizations
  └── Security OU
        ├── Security Tooling Account（委任管理者）
        │     GuardDuty（全アカウントの検出結果集約）
        │     Security Hub（全アカウントの検出結果集約）
        │     Macie（S3スキャン結果集約）
        │     Detective（調査ハブ）
        │     IAM Access Analyzer（外部公開リソース検出）
        │
        └── Log Archive Account（ログ保管専用）
              CloudTrail Organization Trail → S3（変更不可）
              Config Organization Recorder → S3
              VPC Flow Logs → S3
              S3 Object Lock（削除・変更を防止）

SCP セキュリティガードレール例

{
  "Effect": "Deny",
  "Action": [
    "guardduty:DeleteDetector",
    "guardduty:DisassociateFromMasterAccount",
    "cloudtrail:DeleteTrail",
    "cloudtrail:StopLogging",
    "config:DeleteConfigurationRecorder",
    "securityhub:DisableSecurityHub"
  ],
  "Resource": "*"
}

8. コンプライアンス・監査対応

主要コンプライアンスと対応サービス

AWS Audit Manager の活用

[用途]
  PCI DSS / SOC 2 等のフレームワークへの証拠を自動収集・評価

[手順]
  1. Audit Manager でフレームワークを選択
  2. コントロールに対応するAWSサービスを設定
  3. Config ルール・CloudTrail 等から証拠を自動収集
  4. 評価レポートを監査人に提出

9. セキュリティ設計クイックチェックリスト

[必須（本番稼働前）]
□ ルートアカウント MFA 有効化
□ IAM ユーザーへの直接ポリシーアタッチ禁止
□ CloudTrail 全リージョン有効化
□ GuardDuty 有効化
□ S3 パブリックアクセスブロック（全バケット）
□ 保存データ KMS 暗号化（S3/RDS/EBS/DynamoDB）
□ 転送データ TLS 1.2+
□ Secrets Manager または SSM でシークレット管理
□ セキュリティグループ 0.0.0.0/0 の最小化
□ AWS Budgets でコスト監視

[推奨（運用安定後）]
□ Security Hub + CIS ベンチマーク有効化
□ Macie で S3 PII スキャン
□ Inspector で EC2/ECR 脆弱性スキャン自動化
□ Config ルール + 自動修復設定
□ IAM Access Analyzer で定期棚卸し
□ AWS Organizations + SCP でガードレール適用
□ Detective で GuardDuty 検出結果の調査体制
□ Security Lake（OCSF）でログ統合分析