AWS セキュリティ深掘り — Security Hub・GuardDuty・Well-Architected

前提知識: AWSの主要サービス。本教材では継続的な監視とWell-Architectedレビューを扱います。

1. セキュリティの階層（Defence in Depth）

インターネット
    ↓
[AWS WAF + Shield]   ← DDoS・SQLi・XSS のブロック
    ↓
[CloudFront]         ← エッジでのキャッシュ・フィルタリング
    ↓
[ALB + Security Group] ← L4/L7 のフィルタリング
    ↓
[EC2/ECS/Lambda]     ← アプリケーション層
    ↓
[RDS/DynamoDB]       ← データ層（暗号化・VPC 内）

監視:
  [CloudTrail] ← 全 API 呼び出しのログ（誰が・何を・いつ）
  [GuardDuty]  ← 脅威検知（機械学習ベース）
  [Security Hub] ← 複数サービスの結果を集約
  [Config]     ← リソース設定の継続的な監査

2. IAM ベストプラクティス（再掲・深掘り）

// ❌ 広すぎる権限（本番では絶対NG）
{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

// ✅ 最小権限（必要な S3 バケット・操作のみ）
{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::myapp-uploads/*",
  "Condition": {
    "StringEquals": {"aws:RequestedRegion": "ap-northeast-1"},
    "IpAddress": {"aws:SourceIp": "10.0.0.0/8"}
  }
}

# IAM Access Analyzer — 外部からアクセス可能なリソースを検出
aws accessanalyzer list-findings \
  --analyzer-name production-analyzer \
  --filter '{"status": {"eq": ["ACTIVE"]}}'

# 未使用の権限を特定（IAM Access Analyzer の推奨事項）
aws accessanalyzer list-access-preview-findings \
  --access-preview-id xxx

# SCPs（Service Control Policies）— 組織全体のガードレール
# 特定リージョン以外での操作を禁止
{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["ap-northeast-1", "us-east-1"]
    },
    "ArnNotLike": {
      "aws:PrincipalARN": "arn:aws:iam::*:role/NetworkAdmin"
    }
  }
}

3. GuardDuty — 脅威検知の仕組み

GuardDuty が監視するデータソース:
  - CloudTrail（API 呼び出しの異常）
  - VPC Flow Logs（ネットワークトラフィックの異常）
  - DNS ログ（悪意のあるドメインへのアクセス）
  - EKS Audit Logs（K8s の異常動作）
  - S3 データイベント（機密データへの不審アクセス）

主要な検知結果（Findings）の例:
  UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B（普段と異なる地域からのログイン）
  Behavior:IAMUser/InstanceCredentialExfiltration（EC2 のクレデンシャルを外部から使用）
  CryptoCurrency:EC2/BitcoinTool.B（マイニングツールの検出）
  Backdoor:EC2/C&CActivity.B（C2 サーバーへの通信）

# GuardDuty の検知結果を EventBridge → Lambda → Slack に通知
import boto3
import json
import os
import urllib.request

def handler(event, context):
    detail = event["detail"]
    finding_type = detail["type"]
    severity = detail["severity"]
    
    # 重要度 HIGH 以上のみ通知
    if severity < 7.0:
        return
    
    message = {
        "blocks": [{
            "type": "section",
            "text": {
                "type": "mrkdwn",
                "text": f"🚨 *GuardDuty Alert*\n*Type:* {finding_type}\n*Severity:* {severity}\n*Account:* {detail['accountId']}\n*Region:* {detail['region']}"
            }
        }]
    }
    
    req = urllib.request.Request(
        os.environ["SLACK_WEBHOOK"],
        data=json.dumps(message).encode(),
        headers={"Content-Type": "application/json"}
    )
    urllib.request.urlopen(req)

4. Security Hub — 統合ダッシュボード

Security Hub が集約する情報:
  - GuardDuty の検知結果
  - AWS Config ルールの違反
  - Inspector（脆弱性スキャン）
  - IAM Access Analyzer の結果
  - 独自のカスタムルール

準拠フレームワーク:
  - AWS Foundational Security Best Practices
  - CIS AWS Foundations Benchmark
  - PCI DSS（クレジットカード業界標準）

# Security Hub の有効化
aws securityhub enable-security-hub \
  --enable-default-standards

# 検知結果の一覧（HIGH/CRITICAL のみ）
aws securityhub get-findings \
  --filters '{
    "SeverityLabel": [{"Value": "CRITICAL", "Comparison": "EQUALS"},
                      {"Value": "HIGH", "Comparison": "EQUALS"}],
    "RecordState": [{"Value": "ACTIVE", "Comparison": "EQUALS"}]
  }' \
  --query 'Findings[].{Title: Title, Severity: Severity.Label, Resource: Resources[0].Id}'

5. AWS Config — 設定の継続的な監査

# 有効化されていないマネージドルールの例
aws configservice describe-compliance-by-config-rule \
  --config-rule-names \
    s3-bucket-public-read-prohibited \
    ec2-security-group-attached-to-eni \
    iam-password-policy \
    mfa-enabled-for-iam-console-access \
  --compliance-types NON_COMPLIANT

# カスタムルール（Lambda で自前チェック）
# 例: EBS ボリュームが全て暗号化されているか確認
def evaluate_compliance(event):
    ec2 = boto3.client("ec2")
    volumes = ec2.describe_volumes()["Volumes"]
    
    results = []
    for vol in volumes:
        results.append({
            "ComplianceResourceId": vol["VolumeId"],
            "ComplianceResourceType": "AWS::EC2::Volume",
            "ComplianceType": "COMPLIANT" if vol.get("Encrypted") else "NON_COMPLIANT"
        })
    return results

6. Well-Architected セキュリティの柱

AWS Well-Architected Framework — セキュリティの柱（6設計原則）:

1. 強力なアイデンティティ基盤の実装
   → ルートアカウント不使用・MFA 必須・IAM ロールで最小権限

2. トレーサビリティの実現
   → CloudTrail・VPC Flow Logs・CloudWatch Logs を全て有効化

3. 全レイヤーでのセキュリティ適用
   → Defence in Depth（多層防御）

4. セキュリティのベストプラクティスを自動化
   → Config ルール・Lambda による自動修正・Security Hub

5. 転送中および保管中のデータを保護
   → TLS 1.2 以上の強制・KMS による暗号化

6. データに人を近づけない
   → AWS Systems Manager Session Manager（SSH の廃止）
   → Secrets Manager でのシークレット管理（環境変数に書かない）

7. インシデント対応フロー

1. 検知: GuardDuty → EventBridge → Slack/PagerDuty
2. 初動:
   - 影響を受けた IAM ユーザー/ロールを即時無効化
     aws iam put-user-policy --user-name xxx --policy-name deny-all --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"*","Resource":"*"}]}'
   - 問題の EC2 インスタンスを隔離（Security Group で通信遮断）
3. 調査:
   - CloudTrail で直近の API 操作を確認
   - GuardDuty の Finding の詳細を確認
4. 復旧・再発防止:
   - 原因となった設定を修正
   - Config ルールに追加して継続監視

🔗 次のステップ

• 01_セキュリティ実践.md — STRIDE・暗号化・応用情報頻出
• AWS設計・運用 — Well-Architected 全体像