Skip to content

個人情報を含むデータ修正依頼対応ポリシー

1. 概要

事業側からのデータ修正依頼に個人情報が含まれる可能性がある場合の運用方針と作業手順を定義します。 本ポリシーは、個人情報保護法およびGDPRなどの関連法令の遵守を目的としています。

2. 適用範囲

対象となるデータ修正依頼

  • 顧客の個人情報(氏名、メールアドレス、電話番号等)を含む可能性がある修正
  • 医療情報や健康データの修正
  • 決済情報や金融データの修正
  • その他の機密性の高いデータの修正

対象システム

  • 本番環境(production)
  • ステージング環境(staging)
  • 開発環境(develop)における本番データのコピー

3. 運用方針

3.1 基本原則

  1. 最小権限の原則: 作業に必要な最小限のアクセス権限のみを付与
  2. ログ記録の徹底: すべての作業をログに記録し、監査可能な状態を維持
  3. 二重確認: 重要なデータ修正は複数名による確認を必須とする
  4. 暗号化: 個人情報は必ず暗号化して取り扱う
  5. 保持期間の遵守: 作業用データは必要最小限の期間のみ保持

3.2 リスクレベル分類

高リスク(レベル3)

  • 大量の個人情報を含む修正(100件以上)
  • 医療情報や機密性の高いデータの修正
  • 本番環境への直接的な修正
  • GitHub Actionsを使用した自動修正(手動承認なし)

中リスク(レベル2)

  • 少量の個人情報を含む修正(10-99件)
  • ステージング環境での修正
  • 間接的な個人情報への影響がある修正
  • GitHub Actionsを使用した修正(手動承認あり)

低リスク(レベル1)

  • 最小限の個人情報を含む修正(1-9件)
  • 開発環境での修正
  • 匿名化されたデータの修正

4. 作業手順

4.1 事前準備

4.1.1 依頼内容の確認

  1. 個人情報の有無確認

    • 修正対象データに個人情報が含まれるかを事業側に確認
    • リスクレベルの判定
  2. 法的要件の確認

    • 個人情報保護法、GDPR等の適用の有無
    • データ保護責任者(DPO)への報告要否
  3. 承認プロセス

    依頼者 → チームリーダー → セキュリティ責任者 → 作業実行

4.1.2 技術的準備

  1. アクセス権限の設定

    bash
    # IAMロールの一時的な権限付与
    aws sts assume-role --role-arn arn:aws:iam::ACCOUNT:role/DataModificationRole
  2. 作業環境の準備

    • 専用のVPCまたはセキュアな環境の準備
    • CloudTrailログの有効化確認
    • バックアップの作成
  3. 暗号化設定の確認

    terraform
    # KMS暗号化の設定例
    resource "aws_kms_key" "data_modification" {
      description = "Key for data modification operations"
      policy = jsonencode({
        Version = "2012-10-17"
        Statement = [
          {
            Effect = "Allow"
            Principal = {
              AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root"
            }
            Action = "kms:*"
            Resource = "*"
          }
        ]
      })
    }

4.2 作業実施

4.2.1 データの抽出・準備

  1. セキュアな抽出

    bash
    # 暗号化されたS3バケットからのデータ抽出
    aws s3 cp s3://secure-bucket/data.csv ./encrypted-data.csv \
      --sse aws:kms \
      --sse-kms-key-id alias/data-modification-key
  2. データの匿名化(必要に応じて)

    bash
    # 個人情報の仮名化スクリプト実行
    python3 anonymize_data.py --input encrypted-data.csv --output processed-data.csv

4.2.2 修正作業

  1. バックアップの作成

    sql
    -- データベースの場合
    CREATE TABLE users_backup_YYYYMMDD AS SELECT * FROM users WHERE id IN (1,2,3);
  2. 修正の実行

    sql
    -- トランザクション内での修正
    BEGIN;
    UPDATE users SET email = 'new-email@example.com' WHERE id = 123;
    -- 修正内容の確認
    SELECT * FROM users WHERE id = 123;
    COMMIT;
  3. 変更ログの記録

    json
    {
      "timestamp": "2024-01-15T10:30:00Z",
      "operation": "UPDATE",
      "table": "users",
      "affected_rows": 1,
      "operator": "user@example.com",
      "approval_id": "REQ-2024-001",
      "before": {"email": "old-email@example.com"},
      "after": {"email": "new-email@example.com"}
    }

4.3 事後処理

4.3.1 検証とテスト

  1. データ整合性の確認

    bash
    # データ検証スクリプトの実行
    python3 validate_data.py --table users --check-constraints
  2. アプリケーションテスト

    • 修正が他機能に影響していないことを確認
    • 関連APIの動作確認

4.3.2 クリーンアップ

  1. 一時ファイルの削除

    bash
    # セキュアな削除
    shred -u temporary-data.csv
    rm -rf /tmp/data-modification-*
  2. アクセス権限の取り消し

    bash
    # 一時的に付与した権限の削除
    aws iam detach-role-policy --role-name DataModificationRole --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

5. セキュリティ要件

5.1 暗号化要件

  • 保存時: AES-256暗号化(AWS KMS使用)
  • 転送時: TLS 1.3以上を使用
  • メモリ: 可能な限り暗号化された状態で処理

5.2 GitHub Actions特有のセキュリティ要件

5.2.1 高リスク軽減策(レベル3対応)

  • 手動承認なしの自動実行は禁止
  • 本番環境へのアクセスは管理者承認必須
  • シークレット使用時は最小スコープに限定

5.2.2 GitHub Actions使用時の必須セキュリティ対策

シークレット管理

yaml
# 環境別のシークレット分離
production:
  secrets:
    AWS_ROLE_ARN: ${{ secrets.PROD_AWS_ROLE_ARN }}
    DB_PASSWORD: ${{ secrets.PROD_DB_PASSWORD_ENCRYPTED }}

staging:
  secrets:
    AWS_ROLE_ARN: ${{ secrets.STG_AWS_ROLE_ARN }}
    DB_PASSWORD: ${{ secrets.STG_DB_PASSWORD_ENCRYPTED }}

ログ保護設定

yaml
steps:
  - name: データ修正実行
    run: |
      # 個人情報をマスクして実行
      echo "::add-mask::${{ secrets.DB_PASSWORD }}"
      echo "::add-mask::${{ secrets.ENCRYPTION_KEY }}"
      # 修正処理実行(詳細はログに出力しない)
      ./data-modification-script.sh > /dev/null 2>&1
    env:
      SENSITIVE_DATA: ${{ secrets.ENCRYPTED_DATA }}

承認フロー設定

yaml
production:
  environment: production
  needs: [staging-approval]
  if: github.event_name == 'workflow_dispatch' && github.actor == 'authorized-user'

OIDC設定例

yaml
permissions:
  id-token: write
  contents: read

- name: AWS認証
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::${{ secrets.AWS_ACCOUNT_ID }}:role/GitHubActionsDataModificationRole
    role-session-name: DataModificationSession
    aws-region: ap-northeast-1

5.3 アクセス制御

terraform
# IAMポリシーの例
resource "aws_iam_policy" "data_modification_policy" {
  name = "DataModificationPolicy"
  
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "rds:DescribeDBInstances",
          "rds:ModifyDBInstance"
        ]
        Resource = "arn:aws:rds:*:*:db:production-*"
        Condition = {
          StringEquals = {
            "aws:RequestedRegion" = "ap-northeast-1"
          }
          DateGreaterThan = {
            "aws:CurrentTime" = "2024-01-01T00:00:00Z"
          }
          DateLessThan = {
            "aws:CurrentTime" = "2024-12-31T23:59:59Z"
          }
        }
      }
    ]
  })
}

5.4 監査ログ

terraform
# CloudTrail設定
resource "aws_cloudtrail" "data_modification_trail" {
  name           = "data-modification-trail"
  s3_bucket_name = aws_s3_bucket.cloudtrail_bucket.bucket
  
  enable_logging = true
  include_global_service_events = true
  is_multi_region_trail = true
  
  kms_key_id = aws_kms_key.cloudtrail_key.arn
  
  event_selector {
    read_write_type                 = "All"
    include_management_events       = true
    
    data_resource {
      type   = "AWS::RDS::DBInstance"
      values = ["arn:aws:rds:*:*:db:production-*"]
    }
  }
}

6. GitHub Actions使用時の追加考慮事項

6.1 推奨される運用方針

  1. 本番環境での個人情報修正はGitHub Actions使用を避ける
  2. GitHub Actionsを使用する場合は必ず手動承認を組み込む
  3. ワークフローの実行ログは定期的にレビューし、機密情報の漏洩がないか確認する
  4. Personal Access Tokenではなく、GitHub Apps またはOIDCを使用する

6.2 GitHub Actions固有のリスク対策

6.2.1 フォークからのPull Requestリスク

yaml
# pull_request_targetは使用禁止(機密情報にアクセス可能なため)
on:
  workflow_dispatch:  # 手動実行のみ許可
    inputs:
      environment:
        description: '実行環境'
        required: true
        type: choice
        options:
        - staging
        - production

6.2.2 ログ保護の徹底

yaml
steps:
  - name: 機密データの処理
    run: |
      # すべての機密情報をマスク
      echo "::add-mask::$(echo $ENCRYPTED_DB_PASSWORD | base64 -d)"
      echo "::add-mask::$USER_EMAIL"
      echo "::add-mask::$USER_PHONE"
      
      # 処理結果をログに出力しない
      result=$(./modify-user-data.sh "$USER_ID" 2>&1)
      if [ $? -eq 0 ]; then
        echo "データ修正が完了しました(詳細は出力されません)"
      else
        echo "データ修正に失敗しました"
        exit 1
      fi

6.2.3 環境保護設定

yaml
environments:
  production:
    protection_rules:
      - type: required_reviewers
        required_reviewers:
          - security-team
          - sre-team
      - type: wait_timer
        minutes: 30
    deployment_branch_policy:
      protected_branches: true
      custom_branch_policies: false

7. インシデント対応

7.1 インシデント分類

  1. レベル1: 軽微な個人情報の誤表示・誤送信
  2. レベル2: 中程度の個人情報漏洩
  3. レベル3: 大規模な個人情報漏洩
  4. レベル4: GitHub Actions経由での個人情報漏洩(ログ・シークレット経由)

7.2 対応手順

  1. 即座の対応

    • システムの一時停止
    • 影響範囲の特定
    • 関係者への報告
  2. 調査

    • ログ分析
    • 影響を受けたデータの特定
    • 原因分析
  3. 報告

    • 法的報告要件の確認
    • 監督当局への報告(必要に応じて)
    • 顧客への通知
  4. GitHub Actions固有の対応(レベル4の場合)

    • ワークフローの即座停止
    • 実行ログのアクセス制限
    • シークレットのローテーション
    • GitHubサポートへの連絡

8. 定期的な見直し

8.1 ポリシーの更新

  • 四半期ごとのポリシー見直し
  • 法改正に伴う更新
  • インシデント後の改善

8.2 トレーニング

  • 年2回の個人情報保護研修
  • 新しい技術・手法の共有
  • ロールプレイング演習

9. 関連ドキュメント

10. 承認・改訂履歴

版数改訂日改訂者改訂内容
1.02025-08-20SRE Team初版作成

注意: このドキュメントは機密情報を含みます。関係者以外への配布は禁止されています。