ストーリー

主要なセキュリティフレームワークと規制

フレームワーク一覧

SOC 2のTrust Services Criteria

SOC 2 の 5 つのカテゴリ:

CC: Common Criteria（共通基準）
├── CC1: 統制環境
├── CC2: コミュニケーションと情報
├── CC3: リスクアセスメント
├── CC4: モニタリング活動
├── CC5: 統制活動
├── CC6: 論理的・物理的アクセス制御
├── CC7: システム運用
├── CC8: 変更管理
└── CC9: リスク軽減

A: Availability（可用性）
P: Processing Integrity（処理の完全性）
C: Confidentiality（機密性）
PI: Privacy（プライバシー）

セキュリティ要件からコンプライアンスへのマッピング

マッピング表の例

マッピングの効果

コンプライアンスマッピングなし:
  監査時に「PCI-DSS 8.3を満たしていますか？」
  → セキュリティチームが慌てて証拠を収集
  → 数週間のドキュメント作業
  → 「多分満たしていると思います」

コンプライアンスマッピングあり:
  監査時に「PCI-DSS 8.3を満たしていますか？」
  → SEC-AUTH-001, SEC-AUTH-002 が対応
  → 自動テストの実行結果を提示
  → 「はい、この自動テストで継続的に検証しています」

Compliance as Codeの実践

Open Policy Agent（OPA）によるポリシー定義

# ポリシー例: TLS 1.2以上を強制する（Rego言語）
package compliance.tls

default allow = false

allow {
    input.tls_version >= 1.2
}

deny[msg] {
    input.tls_version < 1.2
    msg := sprintf(
        "TLS version %v is below minimum 1.2 (SEC-DATA-001, PCI-DSS 4.1)",
        [input.tls_version]
    )
}

Terraformでのコンプライアンスチェック

# tfsec / checkov によるIaCスキャンの例
# S3バケットの暗号化チェック（SEC-DATA-002, PCI-DSS 3.4）

resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
  bucket = aws_s3_bucket.example.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"      # AES-256相当
      kms_master_key_id = aws_kms_key.example.arn
    }
    bucket_key_enabled = true
  }
}

# checkov チェック:
# CKV_AWS_19: "Ensure all data stored in the S3 bucket is securely encrypted"
# → PASSED: SEC-DATA-002, PCI-DSS 3.4 に準拠

CI/CDパイプラインでの自動チェック

# GitHub Actions でのコンプライアンスチェック例
name: Compliance Check

on: [pull_request]

jobs:
  compliance:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: IaC Security Scan (SEC-DATA-*, PCI-DSS 3/4)
        uses: bridgecrewio/checkov-action@v12
        with:
          directory: ./terraform
          framework: terraform

      - name: Container Security (CIS Benchmark)
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'config'
          scan-ref: './docker'

      - name: Policy Check (OPA/Rego)
        run: |
          opa eval --data policies/ --input config.json \
            "data.compliance.allow"

コンプライアンスの継続的モニタリング

コンプライアンスダッシュボードの設計

「コンプライアンスは年1回の監査のためにあるのではない。毎日のダッシュボードで確認できる状態にしておくことが、真のComplianceだ」 — 田中VPoE

まとめ

チェックリスト

• SOC 2、PCI-DSS、ISO 27001の概要を説明できる
• セキュリティ要件をコンプライアンス基準にマッピングできる
• Compliance as Codeの概念とツールを理解した
• コンプライアンスの継続的モニタリングの設計方針を理解した

次のステップへ

次は演習です。実際の組織シナリオをもとに、セキュリティ要件定義書を作成しましょう。

推定読了時間: 30分