正解：B
この問題の鍵は、以下の2つの要件を同時に満たすことです。
-
非識別化（De-identify）： メールフィールドを個人を特定できない形に変換すること。
-
結合可能性（Joinability）： 非識別化された後のメールフィールド（トークン）を使用して、予約データとユーザープロファイルデータという異なるデータセットを結合できること。
🔑 選択肢の評価
-
A. Cloud DLP + マスキング:
-
マスキングは、データを「X」などの定数やランダムな値に置き換える非識別化手法です。
-
欠点： データが非識別化されますが、元のメールアドレスが異なっていても同じマスク値になってしまうため、異なるデータセット間で結合することが不可能になります。
-
-
B. Cloud DLP + FFX 形式保持暗号化 (FPE):
-
FFX は、形式保持暗号化の一種です。これは、元の値（メールアドレス）を、元の形式（メールアドレスの形式や文字数）を保持したまま、一意で一貫性のあるトークンに変換します。
-
利点：
-
非識別化： トークンは元の PII に戻すことが難しいため、PII が保護されます。
-
結合可能性： **同じ元のメールアドレスは、常に同じ一意のトークンに変換されます。**これにより、予約テーブルのトークン化されたメールと、ユーザープロファイルテーブルのトークン化されたメールを、元の情報（メールアドレス）を公開せずに結合することが可能になります。
-
-
これが要件を完全に満たす最良のソリューションです。
-
-
C & D. BigQuery 動的データマスキング:
-
動的データマスキングは、データ自体を物理的に変更するのではなく、クエリ実行時にユーザーの権限に基づいてデータにマスクをかける手法です。元の PII データは BigQuery テーブルにそのまま残っています。
-
欠点：
-
物理的な非識別化ではない： この要件は BigQuery にロードする前に非識別化することを求めているため、データマスキングはデータを取り込む際の解決策としては不適切です。
-
結合への影響： マスキングされたデータ（例：
xxxxx@xxxx.com）は、結合には使用できますが、アナリストがテーブルを結合できるのは、同じユーザーが同じマスキングルールを持っている場合のみであり、マスキングされた値自体は結合キーとして使用するには不確かです。また、問題の核心は「PII をアクセス不可にすること」であり、動的マスキングは元のデータが残るため、厳格なセキュリティ要件に適合しない可能性があります。また、特に「マスクされたメールアドレス」が結合キーとして機能する保証はありません（例: マスキングの種類によっては異なる値になってしまう）。FFX-FPEの方が、恒久的なトークンを生成するため、結合キーとして適しています。
-
-
FFX 形式保持暗号化は、データが永続的に非識別化され、かつ結合可能であるという、すべての要件を満たすため、正解は B となります。
コメント