Sensitive Data Protection を使用した大規模なデータセットの PII の匿名化と再識別

Last reviewed 2022-08-11 UTC

このドキュメントでは、Sensitive Data Protection を使用して自動化されたデータ変換パイプラインを作成し、個人情報（PII）などの機密データを匿名化する方法について説明します。トークン化（仮名化）などの匿名化手法により、データの有用性を失わずに結合や分析を行う一方で、元の機密データを難読化することでデータの取り扱いリスクを軽減できます。大量の機密データを処理するリスクを最小限に抑えるには、自動データ変換パイプラインを使用し、匿名化されたレプリカを作成します。機密データの保護では、削除、マスキング、トークン化、バケット化、他の匿名化の方法などの変換を行うことができます。データセットの特性が評価されていない場合、Sensitive Data Protection は 100 を超える組み込みの分類子を使用して機密情報のデータを検査することもできます。

このドキュメントは、データ セキュリティ、データ処理、データ分析を担当する技術者を対象としています。また、データ処理とデータ プライバシーに精通していることを前提としています。

リファレンス アーキテクチャ

次の図に、Google Cloud プロダクトを使用してセンシティブなデータセットにセキュリティ層を追加するリファレンス アーキテクチャを示します。

匿名化パイプライン、構成管理、再識別パイプラインのアーキテクチャ。

このアーキテクチャは次の要素で構成されています。

  • データ匿名化ストリーミング パイプライン: Dataflow を使用してテキスト内のセンシティブ データを匿名化します。このパイプラインは、複数の変換やユースケースで再利用できます。

  • 構成（Sensitive Data Protection のテンプレートと鍵）の管理: 匿名化方法と暗号鍵を公開しないように、少数のユーザー グループ（セキュリティ管理者など）のみがアクセスできるマネージドの匿名化構成。

  • データ検証と再識別のパイプライン: 匿名化されたデータのコピーを検証し、Dataflow パイプラインを使用して大規模なデータの再識別を行います。

センシティブ データの保護

企業の重要なタスクの 1 つは、ユーザーと従業員のデータのセキュリティを確保することです。Google Cloud には、保存データの暗号化や転送中のデータの暗号化など、データ セキュリティを強化するセキュリティ対策が用意されています。

保存データの暗号化: Cloud Storage

どの組織においてもデータ セキュリティの維持は重要な作業です。機密性が非常に高いものでなくても、不正アクセスでセンシティブ データの漏洩が発生すれば、お客様からの信頼や信用を失う結果になりかねません。Google では、保存されているデータをデフォルトで暗号化します。デフォルトでは、Cloud Storage バケットにアップロードされたオブジェクトは Google が管理する暗号鍵で暗号化されます。データセットがすでに暗号化され、アップロードの前にデフォルト以外のオプションが必要な場合は、Cloud Storage で別の暗号化オプションを使用することもできます。詳細については、データ暗号化オプションをご覧ください。

転送中の暗号化: Dataflow

転送中のデータの暗号化方法は保存時と異なります。転送中データは、転送時の暗号化という安全なネットワーク プロトコルによって保護されます。デフォルトの設定では、Dataflow は Google が管理する暗号鍵を使用します。このドキュメントに関連するチュートリアルで説明する自動化パイプラインでは、Google が管理するデフォルトの暗号鍵を使用します。

Sensitive Data Protection のデータ変換

Sensitive Data Protection によって実行される変換には、主に 2 つのタイプがあります。

recordTransformations メソッドと infoTypeTransformations メソッドは、データ内の機密情報を匿名化して暗号化します。たとえば、US_SOCIAL_SECURITY_NUMBER 列の値を変換して識別不能にします。また、トークン化により参照整合性を維持しながら難読化します。

infoTypeTransformations メソッドは機密データを検査して、その結果を変換します。たとえば、infoTypeTransformations メソッドを使用して非構造化データやフリーテキスト データを処理すると、文章内の SSN が暗号化され、残りのテキストはそのまま残ります。カスタム infoTypes メソッドを定義することもできます。

構造化データまたは表形式データの場合、recordTransformations メソッドを使用すると、フィールドごとに変換構成を適用できます。recordTransformations メソッドを使用すると、そのフィールドのすべての値に同じ変換を適用できます。たとえば、フィールド名またはヘッダー名に SSN が含まれている列のすべての値をハッシュ化またはトークン化できます。

recordTransformations メソッドは、指定したフィールドの値にのみ適用される infoTypeTransformations メソッドと一緒に使用できます。たとえば、comments というフィールドで、recordTransformations メソッド内に infoTypeTransformations メソッドを使用すると、フィールド内のテキスト内で見つかった US_SOCIAL_SECURITY_NUMBER の結果を削除できます。

匿名化プロセスを複雑な順に示すと、次のようになります。

  • 削除: 機密性の高いコンテンツを置換せずに削除します。
  • マスキング: 機密性の高いコンテンツを特定の文字で置き換えます。
  • 暗号化: 機密性の高いコンテンツを暗号化された文字列で置き換えます。

区切りデータの操作

多くの場合、CSV ファイルのように、データは特定の文字で区切られたレコードで構成され、各列のデータのタイプが一定になっています。この種類のデータの場合、データを検査せずに匿名化変換（recordTransformations）を直接適用できます。たとえば、SSN というラベルの列には SSN データのみが含まれます。infoType 検出器が US_SOCIAL_SECURITY_NUMBER であることを確認するために、データを検査する必要はありません。ただし、Additional Details というラベルの自由形式の列にも機密情報が含まれている可能性があります。この場合、infoType クラスを事前に特定することはできません。自由形式の列の場合、匿名化変換を適用する前に infoTypes 検出器（infoTypeTransformations）を検査する必要があります。Sensitive Data Protection を使用すると、これらの両方の変換タイプを単一の匿名化テンプレートに共存させることができます。Sensitive Data Protection には 100 を超える組み込み infoTypes 検出機能が含まれています。組織の固有の機密データを検出する場合は、組み込みの infoTypes 検出器を変更するだけでなく、カスタムタイプを作成することもできます。

変換タイプの決定

recordTransformations メソッドまたは infoTypeTransformations メソッドを使用するタイミングは、ユースケースによって異なります。infoTypeTransformations メソッドの場合、より多くのリソースが必要になるため、データタイプが不明な場合にのみ使用することをおすすめします。Google Cloud 料金計算ツールを使用して、Sensitive Data Protection を実行する費用を評価できます。

変換の例として、このドキュメントでは次の表に示すように、固定列を含む CSV ファイルを含むデータセットを参照します。

列名 検査 infoType（カスタムまたは組み込み） Sensitive Data Protection の変換タイプ
Card Number 該当なし 確定的暗号化（DE）
Card Holder's Name 該当なし 確定的暗号化（DE）
Card PIN 該当なし 暗号ハッシュ
SSN (Social Security Number) 該当なし マスキング
Age 該当なし バケット化
Job Title 該当なし バケット化
Additional Details 組み込み:
IBAN_CODE、EMAIL_ADDRESS、PHONE_NUMBER
カスタム:
ONLINE_USER_ID 		置換

この表には、列名とその列に必要な変換の種類が示されています。たとえば、Card Number 列には暗号化が必要なクレジットカード番号が含まれていますが、データ型（infoType）はわかっているため、検査を行う必要はありません。

検査変換が必要な列は Additional Details 列だけです。この列は自由形式で、PII が含まれている可能性があります。この例の目的上、この情報は検出して匿名化する必要があります。

この表の例では、5 種類の匿名化変換が示されています。

  • 双方向トークン化: 元のデータを確定的なトークンに置き換え、参照整合性を維持します。トークンを使用してデータの結合や集計分析を行うことができます。データの復号またはトークン化の解除は、トークンの作成に使用した鍵で行います。双方向トークン化には 2 つの方法があります。

    • 確定的暗号化（DE）: 元のデータを base64 エンコードの暗号化された値に置き換え、元の文字セットや長さを保持しません。
    • FFX によるフォーマット保持暗号化（FPE-FFX）: FFX モードのフォーマット保持暗号化を使用して生成されたトークンで元のデータを置き換えます。設計上、FPE-FFX は入力テキストの長さと文字セットを保持します。認証と初期化ベクトルがないため、出力トークンが長くなる可能性があります。従来のデータシステムとの下位互換性など、長さや文字セットの保持が必ずしも必要でない場合には、DE など、より強力なセキュリティを提供する方法をおすすめします。

  • 暗号ハッシュを使用した一方向のトークン化: 元の値をハッシュ値で置き換え、参照整合性を維持します。ただし、双方向トークン化とは異なり、この方法ではデータを元に戻すことはできません。ハッシュ値は、入力値に SHA-256 ベースのメッセージ認証コード（HMAC-SHA-256）を使用して生成されます。

  • マスキング: 指定した文字で元のデータを部分的または完全に置換します。

  • バケット化: 識別しやすい値を識別しにくい値で置き換えます。

  • 置換: 元のデータをトークンまたは infoType の名前（検出された場合）で置き換えます。

方法の選択

最適な匿名化方法はユースケースによって異なります。たとえば、従来のアプリで匿名化されたレコードを処理している場合は、形式の保持が重要になります。厳密にフォーマットされた 10 桁の数値を扱う場合、FPE を使用すると、入力の長さ（10 桁）と文字セット（数値）を保持できます。

ただし、Card Holder's Name 列の値のように、従来のフォーマットを厳密に維持する必要ない場合は、より強力な認証方法である DE をおすすめします。FPE と DE は、トークンの復元またはトークン化の解除を行うことができます。トークン化の解除が必要ない場合は、暗号ハッシュを使用すると整合性が維持されます。ただし、トークンを元に戻すことはできません。

完全な整合性を維持する必要のない値に対しては、マスキング、バケット化、日付シフト、置換などの方法が適しています。たとえば、年齢の値（例: 27）を年齢層（20〜30）にバケット化しても、個人の特定につながる可能性があります。

トークン暗号鍵

暗号化による匿名化変換では、暗号鍵（トークン暗号鍵ともいいます）が必要です。匿名化の暗号化に使用されるトークン暗号鍵は、元の値の再識別にも使用されます。このドキュメントでは、トークン暗号鍵を安全に作成し、管理する方法について説明しませんが、注意すべき重要な原則がいくつかあります（これらについては、関連するチュートリアルで説明します）。

  • テンプレートで平文の鍵を使用しない。代わりに、Cloud KMS を使用してラップされた鍵を作成します。
  • 鍵が不正に利用されるリスクを軽減するため、データ要素ごとに個別のトークン暗号鍵を使用する。
  • トークン暗号鍵をローテーションする。ラップされた鍵はローテーションできますが、トークン暗号鍵をローテーションすると、トークン化の整合性が失われます。鍵がローテーションされたら、データセット全体を再度トークン化する必要があります。

Sensitive Data Protection のテンプレート

大規模なデプロイでは、機密データ保護のテンプレートを使用して次のことを行います。

  • Identity and Access Management（IAM）でセキュリティ管理を有効にします。
  • 構成情報とその情報の匿名化方法をリクエストの実装から分離します。
  • 一連の変換を再利用します。匿名化テンプレートと再識別テンプレートは複数のデータセットで使用できます。

BigQuery

リファレンス アーキテクチャの最後の部分は、匿名化されたデータを BigQuery で表示して操作することです。BigQuery は、サーバーレス インフラストラクチャと BigQuery ML を備えた Google のデータ ウェアハウス ツールで、Sensitive Data Protection をネイティブツールとして実行できます。以下の参照アーキテクチャ例では、BigQuery は匿名化されたデータのデータ ウェアハウスとして使用されています。また、Pub/Sub を介してデータを共有する再識別の自動化データ パイプラインのバックエンドとして機能しています。

次のステップ