【ITニュース解説】Generating realistic fake PII that still passes checksum validation

システムエンジニアとして仕事を進める上で、個人を特定できる情報、通称PII（Personally Identifiable Information）を扱う機会は非常に多くある。顧客の氏名、住所、電話番号、クレジットカード番号、社会保障番号などがこれに該当する。これらのデータは、製品のデモ環境構築、AIモデルの学習、あるいは外部の協力会社との連携など、さまざまな状況で必要となることがある。しかし、本物の個人情報を安易に外部に出すことは、プライバシー侵害のリスクや法規制への違反に繋がりかねないため、厳重な管理が求められる。

こうした状況で重要なのが、「データのマスキング」という手法だ。マスキングとは、個人情報としての価値を失わせつつ、データの構造や形式、そして何よりもその有用性を保つ形で、偽のデータに置き換える技術のことである。単に個人情報の含まれる列を削除してしまうと、そのデータは本来の目的、例えば顧客管理システムのテストや売上分析などに使えなくなり、データの有用性が損なわれてしまう。また、無意味なランダムな値で置き換えるだけでは、下流のシステムや分析ツールが予期せぬエラーを起こし、かえって問題を引き起こすことになる。

そこで、マスキングされたデータが満たすべき三つの重要な特性が挙げられる。

第一に、「形式を維持する」ことだ。例えば、11桁の電話番号はマスキング後も11桁のままであるべきだし、18桁のIDは18桁のまま、そしてその中に含まれる誕生日も現実的な日付であるべきだ。もし出力されるデータの形式が元のデータと異なってしまうと、そのデータを受け取る側のシステム、例えばデータを解析するプログラムなどが正しく動作しなくなり、エラーが発生してしまう。すると、エラーを解決するために結局本物のデータが使われてしまい、マスキングの目的が果たされなくなるという事態に陥りかねない。

第二に、「チェックサムが有効である」ことだ。多くの重要な識別番号、例えばクレジットカード番号や一部の国の身分証明書番号などには、入力ミスを防ぐための「チェックサム」という仕組みが組み込まれている。クレジットカードの番号にはLuhnアルゴリズムが、中国のID番号にはISO 7064 MOD 11-2チェックデジットと呼ばれる検証方法が用いられている。マスキングされたデータがこのチェックサム検証を通過できなければ、フォーム入力の検証、データインポートツール、テストスイートなどがそのデータを不正なものとして拒否してしまう。結果として、マスキングされたデータがテスト用途にすら使えなくなるため、チェックサムの有効性は極めて重要なのである。

第三に、「一貫性があり、元に戻せる」ことだ。これは、同じ実際のデータ値（例えば特定の顧客ID）からは、常に同じ偽のデータ値が生成される必要があるという意味だ。もし同じ顧客が異なるファイルや異なる実行で毎回違う偽のIDを与えられてしまうと、複数のデータセット間で顧客IDを使ってデータを結合（JOIN）しようとした際に、正しい結合ができなくなり、結果としてデータセットは分析の目的には全く使えなくなる。さらに、必要に応じて、特定のキーを使えばマスキングされたデータから元のデータに戻せる「可逆性」も、データの管理上は非常に有用な特性となる。

では、なぜ単純にランダムな数字を生成するだけではいけないのだろうか。例えば、Pythonのrandomモジュールを使って18桁の数字をランダムに生成するような場合を考えてみよう。このようなランダムな文字列には、主に三つの欠陥がある。まず、チェックサム検証に失敗するため、それを入力しようとするシステムに拒否される。次に、もしこの数字がID番号として、例えば「92月」のようなありえない誕生日を中に含んでいた場合、それが偽のデータであることが一目で分かってしまう。一度偽物だと分かると、そのファイル内の他のデータも信用されなくなり、ファイル全体の信頼性が損なわれてしまう。そして最後に、ランダムであるため、同じ人物が次に生成されるファイルで異なるIDを受け取ってしまう可能性があり、データ同士の結合ができなくなり、有用な分析が不可能になる。

この問題を解決するために提案されるのが、「キー付き決定論的マッピング」という手法だ。これは、HMAC（Hash-based Message Authentication Code）と呼ばれる技術を用いる。HMACは、秘密のキーと元のデータ値を組み合わせて、常に同じ結果を生成する暗号学的ハッシュ関数である。つまり、同じ秘密のキーと元のデータ値からは、何度実行しても常に同じ偽のデータ値が生成されるため、「一貫性」が保証される。また、秘密のキーを知らない限り、偽のデータから元の個人情報を復元することは極めて困難であるため、セキュリティも保たれる。

HMACは通常、固定長のハッシュ値を出力するが、マスキングしたいデータの長さがそれより長い場合もある。この場合は、「カウンターモード」という方法が有効だ。これは、元のデータ値と秘密のキーに加えて、カウント用の数字を組み合わせてHMACを複数回実行し、それらの出力を連結することで、必要な長さの決定論的な数字列を生成する。カウント用の数字を増やすことで、異なるHMAC出力を得つつ、そのプロセス全体は決定論的であるため、一貫性は保たれる。

偽のデータを生成したら、次にチェックデジットを修復する必要がある。例えば、中国のID番号のチェックデジットは、最初の17桁の数字に特定の重み付けをして合計を計算し、その結果から導き出される。クレジットカードなどに使われるLuhnアルゴリズムでは、右端から数えて偶数番目の数字を2倍し（その結果が10以上なら9を引く）、全ての桁の合計が10の倍数になるようにチェックデジットを決定する。このように、特定のアルゴリズムに従って、生成された偽のデータが正規の形式として認識されるよう、チェックデジットを計算して付与するのだ。

具体的な例として、中国の18桁のID番号をマスキングするプロセスを考えてみよう。まず、HMACとカウンターモードを使って、元のID番号から17桁の決定論的な数字列を生成する。この17桁の数字列には、生年月日が埋め込まれている部分があるため、これを現実的な日付（例えば1950年から2009年の間、1月から12月、1日から28日までの日）になるように調整する。日を28に固定する理由は、2月の日数や30日と31日の月の違いといった複雑な日付計算の問題を避け、常に有効な日付を生成するためだ。この調整された17桁の数字列に、最後にID番号のチェックデジットを計算して付加すれば、形式的にもチェックサム的にも有効な、現実感のある偽のID番号が完成する。

しかし、マスキング作業で最も困難な課題の一つは、「誤検知」の問題である。例えば、単に「18桁の数字は中国のID番号だ」と判断して全てをマスキングしてしまうと、実際には注文番号やミリ秒単位のタイムスタンプ、あるいは他の情報が連結されたフィールドなど、個人情報ではない18桁の数字も破壊してしまう可能性がある。このような誤検知が頻発すると、データを受け取った同僚は「このツールは使えない」と判断し、結局は本物のデータを使ってしまうという最悪の結果を招きかねない。

この問題を避けるためには、マスキングを行う前に、対象となるデータが本当に個人情報であるかどうかを厳格に「検証」することが不可欠だ。例えば、中国のID番号であれば、単に18桁であるだけでなく、チェックサムが有効であること、埋め込まれた誕生日が現実的な日付であること、そして地域の省コードが存在することを確認するといった具合だ。銀行カード番号であれば、Luhnチェックが通り、桁数が13〜19桁の範囲内であり、BIN（銀行識別番号）プレフィックスが妥当な範囲であることを検証する。電話番号であれば、単に11桁の数字であるだけでなく、割り当てられた携帯電話の範囲のプレフィックスを持っているかを確認する。このような厳格な検証を行うことで、誤検知の数を大幅に減らし、ツールへの信頼性を維持できる。実際の混合データを含むスプレッドシートでは、この検証によってマスキング対象が大幅に絞り込まれ、人々が継続して利用するツールとなるかどうかの大きな違いを生む。

最後に、マスキングされたカラムが自動的に安全になるわけではないという点も重要だ。個人情報をマスキングしても、まだ他の方法で身元が漏洩する可能性がある。例えば、「彼に携帯で電話して、アカウントは妻の名義だと彼が言っていた」といったフリーテキストのメモには、個人を特定できる情報が含まれることがあるが、正規表現などでは見つけにくい。また、郵便番号、役職、生年といった複数の比較的匿名性の高い情報が組み合わさることで、特定の個人が容易に特定されてしまう「稀な組み合わせ」による情報漏洩のリスクもある。データセットが小さい場合、このようなリスクを避けるためには、マスキングではなく該当するカラム自体を削除する方が安全な場合もある。さらに、Excelファイルのようなドキュメント形式では、セルの内容を書き換えても、ファイルに埋め込まれた作成者名、会社名、元のファイルパスなどの「ファイルメタデータ」が残ってしまうことがあるため、これらも注意深く処理する必要がある。

まとめると、個人情報を安全かつ有用な形でマスキングするレシピは、まずデータを厳格に検証し、それが本当に個人情報であるかを確認することから始まる。次に、HMACをカウンターモードで利用し、決定論的に偽のデータを生成する。その後、生成されたデータが元のデータの形式を保ち、チェックデジット検証を通過するように修復する。そして、必要に応じて、秘密のキーを持つ人が元のデータに戻せるように、マッピングファイルを生成することも考慮に入れるべきだ。この一連のプロセスを適切に実施することで、データのプライバシー保護と有用性の両立を実現し、システムエンジニアとして信頼性の高いシステム構築に貢献できるのである。