データマスキングと匿名化

分析やに使うデータには、氏名、メールアドレス、カード番号などの個人を特定できる情報 () が混ざります。法令や社内規程は「必要な人以外に見せない」「目的に必要な範囲だけ使う」ことを求めます。 DEA では、マスキング・・ハッシュ化・・匿名化の違いを理解し、要件に合わせてパイプラインのどこで、どの AWS の機能を使って保護するかを判断します。

Point

PII = Personally Identifiable Information (個人を特定できる情報) の略です。
Masking は「覆い隠す」ことで、値の一部や全部を別の文字に置き換えます。
Tokenization は、値を意味のない代替値 (トークン) に置き換え、元の値との対応表を別に安全に保管する方式です。
Pseudonymization (仮名化) は、追加の情報がないと個人を特定できない形にすることです。追加の情報があれば戻せます。
Anonymization (匿名化) は、どんな手段でも個人を特定できない形にすることです。
和訳
- Anonymize: 匿名にする
- Weblio英和辞書「anonymize」

概要

保護の方式は「元に戻せるか」「同じ値が同じ結果になるか (結合や集計に使えるか)」で選びます。

見るポイント	代表的な判断
一部の利用者だけ元の値を見る必要があるか	元データは残し、や列の権限で見せ分けます。
元の値を分析環境に置くこと自体を避けたいか	取り込み時に静的にマスキング・ハッシュ化した列だけを書き込みます。
同じ顧客の行を結合・集計したいか	決定的な方式 (ハッシュ化、、決定的暗号化) を使います。
統計的な分析だけでよいか	削除・一般化・集約で匿名化します。

主要技術

①保護の方式の違い ⚠️ 頻出

方式	例	元に戻せるか	結合・集計のキー	主な用途
伏せ字 (マスキング、リダクション)	`**--**-1234`	戻せない	使えない	画面やレポートでの表示、問い合わせ対応
削除 (ヌル化)	列ごと消す	戻せない	使えない	分析に不要な列
ハッシュ化 (ソルト付き)	SHA-256 の値	戻せない	使える	同じ顧客を識別した集計
	`tok_8f3a...` と対応表	対応表で戻せる	使える	決済、権限者だけが元の値を必要とする処理
決定的暗号化	同じ値は同じ暗号文	キーで戻せる	使える	結合が必要で、権限者は復号する
確率的暗号化	毎回違う暗号文	キーで戻せる	使えない	保管時の保護
一般化	年齢 → 年代、住所 → 都道府県	戻せない	粗い単位で使える	統計、外部への提供
置換・	本物らしい別の値、他の行の値と入れ替え	戻せない	使えない	テスト用データの作成

ハッシュ化は、電話番号のように取りうる値が少ないと、総当たりで元の値を推測されます。秘密のソルト (付け足す値) を加えるか、HMAC のようにキー付きのハッシュを使います。

したデータ (トークン化、ハッシュ化) は、対応表や追加の情報と組み合わせれば個人を特定できる可能性が残ります。規制の上では引き続き個人データとして扱われる場合があるため、「匿名化したので規制の対象外」と判断するには、組み合わせによる再識別の可能性まで考える必要があります。

②静的マスキングと動的マスキング

方式	仕組み	長所	短所
静的マスキング	でマスクした値を書き込みます。	保存先に元の値がないため、漏えいの影響が小さいです。	元の値が必要な利用者のために、別に元データを保管する必要があります。
動的マスキング	保存値はそのままで、クエリの結果を利用者ごとに変えます。	1つのテーブルで利用者ごとに見せ方を変えられます。	保存先には元の値があるため、保存先の権限管理が前提です。

では、元の値を持つ raw ゾーンへのアクセスを最小限に絞り、多くの利用者には静的にマスクした curated ゾーンを使わせる構成が一般的です。

③AWS Glue の機密データ検出 ⚠️ 頻出

Studio の「Detect Sensitive Data ( の検出)」変換は、の途中で PII を見つけて処理します。

設定	選択肢
走査の方法	すべての行のセルを調べる (網羅的)、または一部の行を標本として調べ、PII を含む列を特定する (費用と時間を抑える)
検出する対象	AWS が定義したエンティティ (メール、クレジットカード番号、各国の識別番号など) をカテゴリや個別に選びます。正規表現と文脈の単語で独自のパターンも作れます。
検出時の処理	検出結果を列として追加する、伏せ字にする、一部を伏せ字にする、SHA-256 のハッシュに置き換える
細かい上書き	列ごとに検出の対象外にしたり、別の処理を指定したりできます。

取り込みのジョブにこの変換を入れると、raw から curated へ書き込む時点で PII を伏せ字やハッシュに変えられます。

④そのほかの AWS の機能

機能	役割	方式
の	クエリの結果を利用者・ロールごとに伏せ字やハッシュにします (「Redshift のアクセス制御とデータ共有」の章)。	動的
の列・セルのフィルター	利用者ごとにの列を見せません (「AWS Lake Formation」の章)。	動的 (列ごと隠す)
のレシピ	置換、、決定的・確率的暗号化、ヌル化、伏せ字、ハッシュ化の変換をコードなしで適用し、プロファイルで PII を検出します。	静的
	のどこに PII があるかを見つけます。マスキングはしません (「Amazon Macie」の章)。	検出のみ
+	独自のや暗号化を行い、対応表をなどに暗号化して保管します。	静的

⑤コンプライアンスの要件との対応

要件の例	対応の考え方
目的に必要な最小限のデータだけを使う	分析に不要なの列は取り込み時に削除します。
権限者以外に個人を特定させない	列の権限、動的マスキング、静的マスキングを組み合わせます。
決済カード番号の表示を制限する	表示は末尾の数桁などに限り、元の値はや暗号化で保護します。
研究や外部への提供	一般化や集約で匿名化し、少人数の集団から個人が推測されないかを確かめます。
削除要求 (忘れられる権利)	トークンの対応表を消すと、トークン化したデータから個人を特定できなくなります。
監査	どの列をどう保護したかを Data Catalog のタグやで記録します。

試験対策

マスキングの問題では、「元の値に戻す必要があるか」「結合のキーとして使うか」「保存先に元の値を置いてよいか」の3つで方式を絞ります。次に、パイプラインのどこ (取り込み時のか、クエリ時か) で保護するかで AWS の機能を選びます。

①判断マトリクス

問題文のキーワード	選ぶもの	理由
の途中でを検出して伏せ字にしたい	の機密データ検出の変換	検出と伏せ字・ハッシュ化を同時に行えます。
個人を識別せずに同じ顧客の購買を集計したい	ソルト付きのハッシュ化	同じ値は同じハッシュになり、元に戻せません。
権限のある処理だけが元のカード番号を使う	(対応表を厳重に保管)	対応表で元に戻せます。
1つのテーブルで、チームにより見え方を変えたい	の	保存値を変えずに結果だけ変えます。
で PII の列を一部の利用者から隠す	の列のフィルター	などの結果から列を除きます。
分析環境に元の PII を置きたくない	取り込み時の静的マスキング	保存先に元の値が残りません。
コードを書かずに分析者が PII を変換したい	の PII のレシピ	画面の操作で変換します。
どのに PII があるか分からない	で検出してから保護	検出と保護を分けて考えます。
テスト環境に本番に似たデータを用意したい	置換・	本物らしいが個人ではない値にします。

②よくある誤答

ハッシュ化を、元に戻せる暗号化と混同すること。ハッシュは戻せません。
がデータをマスキングすると考えること。Macie は検出だけです。
動的マスキングをすれば保存先の権限管理が不要と考えること。保存先には元の値があります。
ソルトなしのハッシュで十分と考えること。値の種類が少ないと推測されます。
したデータを、常に個人データではないと考えること。