implementing-compliance

コンプライアンスフレームワーク

統合されたコントロールマッピング、ポリシー・アズ・コードの適用、自動化された証跡収集により、主要な規制フレームワークへの継続的なコンプライアンスを実現します。

目的

現代のコンプライアンスは、セキュリティコントロールの技術的な実装を必要とする継続的なエンジニアリングの取り組みです。このスキルでは、Infrastructure as Code、ポリシーの自動化、証跡収集を活用し、SOC 2 Type II、HIPAA、PCI-DSS 4.0、GDPRに準拠するためのパターンを提供します。複数のフレームワークを同時に満たす統合コントロールに注力し、実装作業を60～80％削減します。

使用する場面

次の場合に呼び出します：

• エンタープライズ向け販売のためにSOC 2 Type IIが必要なSaaS製品を構築する場合
• HIPAAへの準拠が必要な医療データ（PHI）を取り扱う場合
• PCI-DSSの検証が必要な決済カードを処理する場合
• EU居住者にサービスを提供し、GDPRに基づいて個人データを処理する場合
• 複数のコンプライアンスフレームワークを満たすセキュリティコントロールを実装する場合
• コンプライアンス証跡の収集と監査準備を自動化する場合
• CI/CDパイプラインでコンプライアンスポリシーを適用する場合

フレームワークの選定

Tier 1：信頼性とセキュリティの認証

SOC 2 Type II

• 対象：SaaSベンダー、クラウドサービスプロバイダー
• 必要となる場面：エンタープライズ向けB2B販売、顧客データの取り扱い
• 期間：6～12か月の観察期間
• 2025年の更新：月次のコントロールテスト、AIガバナンス、72時間以内の侵害開示

ISO 27001

• 対象：グローバル企業
• 必要となる場面：国際ビジネス、政府契約
• 期間：認証まで3～6か月、年次のサーベイランス

Tier 2：業界固有の規制

HIPAA（医療）

• 対象：医療提供者、PHIを取り扱うヘルステック企業
• 必要となる場面：保護対象保健情報の処理
• 2025年の重点分野：ゼロトラストアーキテクチャ、EDR/XDR、AI評価

PCI-DSS 4.0（ペイメントカード業界）

• 対象：加盟店、決済処理事業者
• 必要となる場面：カード会員データの処理、保存、送信
• 発効日：2025年4月1日（遵守必須）
• 主な変更点：クライアント側セキュリティ、12文字のパスワード、強化されたMFA

Tier 3：プライバシー規制

GDPR（EUのプライバシー）

• 対象：EU居住者のデータを処理する組織
• 必要となる場面：EUの顧客・ユーザー（域外適用）
• 2025年の更新：48時間以内の侵害報告、収益の6％に相当する罰金、AIの透明性

CCPA/CPRA（カリフォルニア州のプライバシー）

• 対象：カリフォルニア州居住者にサービスを提供する企業
• 必要となる場面：収益が2,500万ドル超、またはカリフォルニア州居住者が10万人以上、またはデータ販売による収益が50％以上

各フレームワークの詳細な要件については、references/soc2-controls.md、references/hipaa-safeguards.md、references/pci-dss-requirements.md、references/gdpr-articles.mdを参照してください。

共通コントロールの実装

統合コントロール戦略

コントロールを一度実装し、複数のフレームワークにマッピングします。作業を60～80％削減できます。

実装の優先順位：

1. 暗号化（ENC-001、ENC-002）：保存時はAES-256、転送時はTLS 1.3
2. アクセス制御（MFA-001、RBAC-001）：MFA、RBAC、最小権限
3. 監査ログ（LOG-001）：一元管理、改ざん不可能、7年間の保持
4. 監視（MON-001）：SIEM、侵入検知、アラート
5. インシデント対応（IR-001）：検知、エスカレーション、侵害通知

管理カテゴリ

ID とアクセス：

• 特権アクセスには多要素認証を適用
• 最小権限に基づくロールベースのアクセス制御
• 四半期ごとのアクセスレビュー
• パスワードポリシー：12 文字以上、複雑性要件

データ保護：

• 暗号化：AES-256（保存時）、TLS 1.3（転送時）
• データの分類とタグ付け
• 規制に準拠した保持ポリシー
• データの最小化

ログ記録と監視：

• 監査ログの一元管理（すべての認証とデータアクセス）
• 7 年間の保持（すべてのフレームワークの要件を満たします）
• イミュータブルストレージ（S3 Object Lock）
• リアルタイムのアラート

ネットワークセキュリティ：

• ネットワークのセグメント化と VPC の分離
• デフォルトで拒否するファイアウォール
• 侵入検知／防止
• 定期的な脆弱性スキャン

インシデント対応：

• 文書化されたインシデント対応計画
• 自動検知とアラート
• 漏えい通知：HIPAA は 60d、GDPR は 48h、SOC 2 は 72h、PCI-DSS は即時

事業継続性：

• RPO／RTO を定義した自動バックアップ
• マルチリージョンの災害復旧
• 定期的なフェイルオーバーテスト

管理策の完全な実装については、references/control-mapping-matrix.md を参照してください。

コードとしてのコンプライアンス

OPA によるポリシーの適用

インフラストラクチャをデプロイする前に、CI/CD でコンプライアンスポリシーを適用します。

アーキテクチャ：

Git Push → Terraform Plan → JSON → OPA Evaluation
                                    ├─► Pass → Deploy
                                    └─► Fail → Block

例：暗号化ポリシー

暗号化要件（SOC 2 CC6.1、HIPAA §164.312(a)(2)(iv)、PCI-DSS Req 3.4）を適用します。

完全な実装については、examples/opa-policies/encryption.rego を参照してください。

CI/CD との統合：

terraform plan -out=tfplan.binary
terraform show -json tfplan.binary > tfplan.json
opa eval --data policies/ --input tfplan.json 'data.compliance.main.deny'

CI/CD パターンの全容については、references/cicd-integration.md を参照してください。

Checkov による静的解析

組み込みのコンプライアンスフレームワーク対応機能を使用して IaC をスキャンします。

checkov -d ./terraform \
  --check SOC2 --check HIPAA --check PCI --check GDPR \
  --output cli --output json

組織固有の要件に合わせたカスタムポリシーを作成できます。例については、examples/checkov-policies/ を参照してください。

自動テスト

コンプライアンス検証をテストスイートに統合します。

def test_s3_encrypted(terraform_plan):
    """SOC2:CC6.1, HIPAA:164.312(a)(2)(iv)"""
    buckets = get_resources(terraform_plan, "aws_s3_bucket")
    encrypted = get_encryption_configs(terraform_plan)
    assert all_buckets_encrypted(buckets, encrypted)

def test_opa_policies():
    result = subprocess.run(["opa", "eval", "--data", "policies/",
        "--input", "tfplan.json", "data.compliance.main.deny"])
    assert not json.loads(result.stdout)

テストパターンの全容については、references/compliance-testing.md を参照してください。

技術的な管理策の実装

保存時の暗号化

標準： AES-256、マネージド KMS、自動ローテーション

AWS の例：

resource "aws_kms_key" "data" {
  enable_key_rotation = true
  tags = { Compliance = "ENC-001" }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "data" {
  bucket = aws_s3_bucket.data.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.data.arn
    }
  }
}

resource "aws_db_instance" "main" {
  storage_encrypted = true
  kms_key_id       = aws_kms_key.data.arn
}

Azure および GCP を含む暗号化実装の全容については、references/encryption-implementations.md を参照してください。

転送時の暗号化

標準： TLS 1.3（TLS 1.2 以上）、強固な暗号スイート、HSTS

ALB の例：

resource "aws_lb_listener" "https" {
  port       = 443
  protocol   = "HTTPS"
  ssl_policy = "ELBSecurityPolicy-TLS13-1-2-2021-06"
}

多要素認証

標準： TOTP、ハードウェアトークン、特権アクセスに対する生体認証

AWS IAM による適用：

resource "aws_iam_policy" "require_mfa" {
  policy = jsonencode({
    Statement = [{
      Effect = "Deny"
      NotAction = ["iam:CreateVirtualMFADevice", "iam:EnableMFADevice"]
      Resource = "*"
      Condition = {
        BoolIfExists = { "aws:MultiFactorAuthPresent" = "false" }
      }
    }]
  })
}

アプリケーションレベルの MFA（TOTP）については、examples/mfa-implementation.py を参照してください。

ロールベースのアクセス制御

標準： 最小権限、職務に基づくロール、四半期ごとのレビュー

Kubernetes の例：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
  namespace: development
rules:
- apiGroups: ["", "apps"]
  resources: ["pods", "deployments", "services"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]  # Read-only

AWS IAM と OPA ポリシーを含む RBAC パターンの全容については、references/access-control-patterns.md を参照してください。

監査ログ

標準： 構造化 JSON、7 年間の保持、イミュータブルストレージ

必須イベント： 認証、認可、データアクセス、管理操作、セキュリティイベント

Python の例：

class AuditLogger:
    def log_event(self, event_type, user_id, resource_type,
                  resource_id, action, result, ip_address):
        audit_event = {
            "timestamp": datetime.utcnow().isoformat() + "Z",
            "event_type": event_type.value,
            "user_id": user_id,
            "action": action,
            "result": result,
            "resource": {"type": resource_type, "id": resource_id},
            "source": {"ip": ip_address}
        }
        self.logger.info(json.dumps(audit_event))

ログの保持：

resource "aws_cloudwatch_log_group" "audit" {
  retention_in_days = 2555  # 7 years
  kms_key_id        = aws_kms_key.logs.arn
}

resource "aws_s3_bucket_object_lock_configuration" "audit" {
  bucket = aws_s3_bucket.audit_logs.id
  rule {
    default_retention { mode = "COMPLIANCE"; years = 7 }
  }
}

HIPAA の PHI アクセスログを含む監査ログパターンの全容については、references/audit-logging-patterns.md を参照してください。

証跡収集の自動化

継続的な監視

継続的なコンプライアンス検証のために、証跡収集を自動化します。

アーキテクチャ：

AWS Config → EventBridge → Lambda → S3 (Evidence)
                                   → DynamoDB (Status)

証跡の収集：

class EvidenceCollector:
    def collect_encryption_evidence(self):
        evidence = {
            "control_id": "ENC-001",
            "frameworks": ["SOC2-CC6.1", "HIPAA-164.312(a)(2)(iv)"],
            "timestamp": datetime.utcnow().isoformat(),
            "status": "PASS",
            "findings": []
        }
        # Check S3, RDS, EBS encryption status
        # Document findings
        return evidence

証跡収集ツールの全容については、examples/evidence-collection/evidence_collector.py を参照してください。

監査レポートの生成

コンプライアンスレポートを自動生成します。

class AuditReportGenerator:
    def generate_soc2_report(self, start_date, end_date):
        controls = self.get_control_status("SOC2")
        return {
            "framework": "SOC 2 Type II",
            "compliance_score": self.calculate_score(controls),
            "trust_services_criteria": {...},
            "controls": self.format_controls(controls)
        }

レポート生成ツールの全容については、examples/evidence-collection/report_generator.py を参照してください。

コントロール対応マトリックス

各フレームワークに共通するコントロールの対応関係：

コントロール	SOC 2	HIPAA	PCI-DSS	GDPR	ISO 27001
MFA	CC6.1	§164.312(d)	Req 8.3	Art 32	A.9.4.2
保存データの暗号化	CC6.1	§164.312(a)(2)(iv)	Req 3.4	Art 32	A.10.1.1
転送中データの暗号化	CC6.1	§164.312(e)(1)	Req 4.1	Art 32	A.13.1.1
監査ログ	CC7.2	§164.312(b)	Req 10.2	Art 30	A.12.4.1
アクセスレビュー	CC6.1	§164.308(a)(3)(ii)(C)	Req 8.2.4	Art 32	A.9.2.5
脆弱性スキャン	CC7.1	§164.308(a)(8)	Req 11.2	Art 32	A.12.6.1
インシデント対応	CC7.3	§164.308(a)(6)	Req 12.10	Art 33	A.16.1.1

戦略： 適切なタグ付けを行って一度実装し、該当するすべてのフレームワークに対応付けます。

45 以上のコントロールを網羅した完全な対応表については、references/control-mapping-matrix.md を参照してください。

データ侵害の通知要件

フレームワークごとの期限：

• HIPAA：HHS および影響を受けた個人に 60 日以内に通知
• GDPR：監督機関に 48 時間以内に通知（2025 年更新）
• SOC 2：影響を受けた顧客に 72 時間以内に通知
• PCI-DSS：カードブランドに直ちに通知

必須項目：

• インシデントおよび関係するデータの説明
• 影響を受けた個人の推定人数
• 被害を軽減するために講じた措置
• 問い合わせ先
• 是正措置とそのスケジュール

インシデント対応テンプレートについては、references/incident-response-templates.md を参照してください。

ベンダー管理

業務提携契約（HIPAA）：

• PHI を取り扱うすべてのベンダーに必要です
• 許可される使用と開示を明記します
• 適切な保護措置を求めます
• 年次レビューと更新を行います

データ処理契約（GDPR）：

• 個人データを処理するすべてのベンダーに必要です
• 管理者の指示に従ってのみ処理します
• 適切な技術的措置を実施します
• サブプロセッサーの承認が必要です

評価プロセス：

1. データアクセスレベルに基づくリスク分類
2. セキュリティ質問票の評価
3. BAA/DPA の締結
4. SOC 2 レポートの収集（発行から 90 日以内）
5. 年次再評価

ベンダー管理テンプレートについては、references/vendor-management.md を参照してください。

ツールとライブラリ

ポリシー・アズ・コード：

• Open Policy Agent (OPA)：汎用ポリシーエンジン
• Checkov：コンプライアンスフレームワークに対応した IaC セキュリティスキャン
• tfsec：Terraform セキュリティスキャナー
• Trivy：コンテナおよび IaC スキャナー

コンプライアンス自動化：

• AWS Config：AWS リソースのコンプライアンス監視
• Cloud Custodian：マルチクラウドのコンプライアンス自動化
• Drata/Vanta/Secureframe：継続的コンプライアンスプラットフォーム

ツール選定の指針については、references/tool-recommendations.md を参照してください。

他のスキルとの連携

関連スキル：

• security-hardening：技術的なセキュリティコントロールの実装
• secret-management：HIPAA/PCI-DSS に準拠したシークレットの取り扱い
• infrastructure-as-code：コンプライアンスコントロールを実装する IaC
• kubernetes-operations：K8s RBAC、ネットワークポリシー
• building-ci-pipelines：CI/CD でのポリシー適用
• siem-logging：監査ログと監視
• incident-management：インシデント対応手順

クイックリファレンス

実装チェックリスト：

• 該当するフレームワークを特定する
• 暗号化を実装する（AES-256、TLS 1.3）
• 特権アクセスに MFA を設定する
• 最小権限の原則に基づいて RBAC を実装する
• 監査ログを設定する（7 年間保持）
• セキュリティ監視とアラートを設定する
• インシデント対応計画を作成する
• ベンダー契約（BAA、DPA）を締結する
• ポリシー・アズ・コード（OPA、Checkov）を実装する
• 証跡収集を自動化する
• 四半期ごとにアクセスレビューを実施する
• 年次リスク評価を実施する

よくある間違い：

• コンプライアンスを継続的なプロセスではなく、一度限りのプロジェクトとして扱う
• 統一されたコントロールではなく、フレームワークごとに個別のコントロールを実装する
• 証跡収集を自動化せず、手作業で行う
• ログの保持期間が不十分（7 年未満）
• MFA の適用漏れ
• バックアップやログを暗号化しない
• ベンダーのデューデリジェンスが不十分

参考資料

フレームワークの詳細：

• references/soc2-controls.md - SOC 2 TSC 管理策カタログ
• references/hipaa-safeguards.md - HIPAA セーフガード
• references/pci-dss-requirements.md - PCI-DSS 4.0 要件
• references/gdpr-articles.md - GDPR の主要条項

実装パターン：

• references/control-mapping-matrix.md - 統合管理策マッピング
• references/encryption-implementations.md - 暗号化パターン
• references/access-control-patterns.md - MFA、RBAC の実装
• references/audit-logging-patterns.md - ログ要件
• references/incident-response-templates.md - IR 手順

自動化：

• references/cicd-integration.md - OPA/Checkov の CI/CD 統合
• references/compliance-testing.md - 自動テストのパターン
• references/vendor-management.md - ベンダー評価テンプレート
• references/tool-recommendations.md - ツール選定ガイド

コード例：

• examples/opa-policies/ - OPA ポリシーの例
• examples/terraform/ - Terraform による管理策の実装
• examples/evidence-collection/ - 証跡の自動収集
• examples/mfa-implementation.py - TOTP MFA の実装

法的解釈や監査準備については、資格を有する法律顧問および監査人に相談してください。