Sensitive Data Protection (Cloud DLP)

解決する課題

組織のデータには、本人が意図しないところにクレジットカード番号やマイナンバー、メールアドレスといった機密情報が紛れ込みます。どこに何があるか分からないままでは、漏えい時の影響範囲も、保護すべき対象も特定できません。Sensitive Data Protection（旧 Cloud DLP）は、こうした機密データの検出・分類・無害化をマネージドに引き受けます。

• 大量のデータ（DB、ストレージ、ログ）のどこに個人情報があるか分からない
• 分析や開発に使うデータから、**個人情報だけを安全に取り除いて（仮名化して）**使いたい
• 機密データの所在と種類を組織横断で棚卸しし、保護状況を把握したい
• フォーム入力やチャットなど、処理する前のデータに機密情報が混ざるのを防ぎたい

主要概念と用語

• infoType（情報タイプ）: 検出対象のカテゴリ。メールアドレス、クレジットカード番号、電話番号など多数の組み込み型に加え、正規表現や辞書によるカスタム infoType も定義できる
• 検査（Inspection）: テキストや構造化データ、画像をスキャンし、どの infoType がどこに何件あるかを**検出結果（finding）**として返す中核機能
• likelihood（確度）: 各検出が本当に機密かを示す確からしさの段階。誤検知の調整に使う
• 匿名化（De-identification）: 検出した値を変換して機密性を下げる処理。マスキング、置換、日付シフト、トークン化などの**変換（transformation）**を組み合わせる
• トークン化 / 仮名化（Pseudonymization）: 元の値を可逆または不可逆なトークンへ置き換える方式。フォーマット保持暗号化や暗号ハッシュにより、参照整合性を保ったまま実値を隠せる
• 再識別化（Re-identification）: 可逆トークン化したデータを、適切な鍵を持つ者だけが元の値へ戻す処理
• 検査ジョブ / ディスカバリ: Cloud Storage や BigQuery 等を対象に実行するスキャン。ディスカバリは継続的に資産を走査し、データプロファイルとして機密度を可視化する
• リスク分析: k-匿名性、l-多様性、k-マップなどの指標で、データセットの再識別リスクを定量評価する機能

仕様・制限・クォータ

• 対象データ: テキスト・構造化テーブル・画像のインスペクトに加え、ストレージ系では Cloud Storage、BigQuery、Datastore/Firestore などをスキャン対象にできる
• 組み込み infoType: 国・地域別の識別子（各国の納税者番号や電話番号など）を含む多数の型を提供。組織固有の値はカスタム infoType（正規表現・辞書・保存済み辞書）で補う
• コンテンツAPIの上限: 1リクエストで送れるペイロードのサイズや、テーブルの行・列数には上限がある。大きなデータはジョブ（ストレージスキャン）側で扱う
• クォータ: API のリクエスト数やジョブの同時実行数にレート上限があり、必要に応じて引き上げ申請が可能。具体的な上限値は変動するため公式を参照
• ロケーション: 処理リージョンを指定でき、データの所在地要件に合わせて選択する
• 料金や数値は変動するため、対応 infoType の一覧・上限・単価は常に公式ドキュメントで確認する

内部の仕組み

Sensitive Data Protection は、検出（インスペクト）と変換（匿名化）を分離したパイプラインとして動きます。入力に対して各 infoType の検出器を走らせ、見つかった箇所を「位置・型・確度」を持つ検出結果として返し、必要なら同じ箇所に変換を適用して無害化します。

• 検出は組み込み検出器（パターン・チェックサム・文脈語による補強）と、利用者定義の正規表現・辞書を組み合わせて行う。確度（likelihood）で誤検知のしきい値を調整できる
• 匿名化はコンテンツに対するインライン処理。マスキング（文字置換）、置換、日付シフト、暗号ベースのトークン化など、infoType ごとに異なる変換ルールを指定できる
• トークン化では決定的暗号やフォーマット保持暗号を使い、同じ入力が同じトークンになるよう参照整合性を保てる。鍵を Cloud KMS で管理すれば、再識別化を鍵保有者に限定できる
• ストレージ系のディスカバリは、対象を継続的に走査して機密度の高い資産をデータプロファイルとして整理し、検出結果は Security Command Center や Pub/Sub、BigQuery へ連携できる

設計パターン / ベストプラクティス

• 機密データの棚卸しは、まずディスカバリでデータプロファイルを作り、機密度の高い資産から対策する
• 分析・開発・テスト用データは、本番からコピーする時点で匿名化を通し、実値を環境外へ出さない
• 参照整合性が必要な分析には、ランダムマスキングではなく決定的トークン化を使い、結合可能性を保つ
• 再識別が必要な業務（不正調査など）では可逆トークン化＋KMS 鍵で、戻せる権限を厳格に分離する
• 誤検知/検知漏れは likelihood のしきい値とカスタム infoType・除外ルールで継続的にチューニングする
• リアルタイム入力（フォーム・チャット）は、保存前にコンテンツ API で検査・匿名化してから永続化する

運用・監視

• API 呼び出しやジョブ実行は Cloud Audit Logs に記録し、誰がいつ検査・再識別化したかを監査する
• ストレージスキャンの結果は Security Command Center に集約し、機密データの所在をセキュリティ運用に組み込む
• 検出結果を Pub/Sub や BigQuery に出力し、件数の推移やヒットの多い資産をダッシュボードで監視する
• 誤検知が多い場合は、infoType の絞り込み・likelihood の引き上げ・除外辞書（ハッシュ済みのテスト値など）で調整する
• レート上限に当たる場合は、対象を分割しジョブ化する、または不要な infoType を外してスキャン量を減らす

コスト

課金は「検査したデータ量（バイト）」と「匿名化・再識別化などの処理量」が基本で、ストレージのディスカバリ（プロファイリング）は別軸で課金されます。具体的な単価は変動するため公式を確認してください。

セキュリティ

• API とジョブは IAM で最小権限に。検査だけ許す権限と、再識別化（元値に戻す）権限は明確に分離する
• 可逆トークン化の暗号鍵は Cloud KMS で管理し、再識別化できる主体を鍵アクセス権で厳格に制限する
• 匿名化したデータでも、組み合わせ次第で個人が特定され得るため、**リスク分析（k-匿名性等）**で再識別リスクを評価する
• 検査・変換の処理ロケーションをデータ所在地要件に合わせ、機密値が不要に別リージョンへ移らないようにする

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

# テキストを検査し、メールアドレスとクレジットカード番号を検出する
gcloud dlp text inspect \
  --content "連絡先は taro@example.com、カードは 4111 1111 1111 1111 です" \
  --info-types EMAIL_ADDRESS,CREDIT_CARD_NUMBER

# 検査用の設定をファイルにし、Cloud Storage バケットをスキャンするジョブを作成
cat > inspect-job.json <<'JSON'
{
  "inspectJob": {
    "storageConfig": {
      "cloudStorageOptions": {
        "fileSet": { "url": "gs://my-bucket/data/**" }
      }
    },
    "inspectConfig": {
      "infoTypes": [
        { "name": "EMAIL_ADDRESS" },
        { "name": "PHONE_NUMBER" }
      ],
      "minLikelihood": "LIKELY"
    }
  }
}
JSON

# REST API でストレージ検査ジョブを発行（プロジェクトとロケーションを指定）
curl -s -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  "https://dlp.googleapis.com/v2/projects/PROJECT_ID/locations/asia-northeast1/dlpJobs" \
  -d @inspect-job.json