マスキングしたあとも、その事案を追えるか
一言でいうと
ログや持ち出しファイルから個人情報を消すことは、「見えなくすること」ではなく、調査に必要なつながりは残しつつ、人が誰か分からないようにすることです。その境界を決めるのがマスキングルールと決定的な仮名値であり、それが正しくできたかどうかは、機械でもう一度測って証明します。
なぜ必要なのか
障害調査をしていると、アプリケーションログをまるごと受け取って見ることになります。ところが、送金APIのログには自由記述の文が混ざっていて、その文の中に口座番号やカード番号、電話番号やメールアドレスがそのまま書かれていることがよくあります。開発者が悪意で書いたのではなく、障害を早く見つけようと「リクエストの電文をまるごと」出力した1行が、何年も残っているのです。
このログを分析担当や供給元に渡すには、個人情報を取り除かなければなりません。個人情報保護法は、目的を達成した個人情報を遅滞なく破棄するよう定めており(第21条)、調査に必要なのは人の身元ではなく、「同じ口座で何回失敗したか」のようなつながりです。ところが、口座番号をすべてアスタリスクで覆ってしまうと、そのつながりまで消えます。同じ人が3回失敗したのか、3人が1回ずつ失敗したのかが区別できなくなります。隠さなければならないが、つなげて見ることはできなければなりません。この2つの要求を同時に満たすことが、このテーマのすべてです。
どう動くのか
スクラビングは3つの段階に分かれます。探す、分ける、置き換える。
探すことは、正規表現です。reモジュールで、口座番号の形、16桁の数字、携帯電話の形、メールアドレスの形を走査します。問題は、正規表現が「形」しか見ないことです。銀行のログには、16桁の数字がカード番号以外にもいくらでもあります。清算の連番、電文の追跡番号、バッチジョブの識別子が、すべて16桁です。これらまでアスタリスクで覆うと、調査に必要な識別子が消えます。
分けることが、ここで登場します。カード番号にはチェックディジットが付いています。右端から2桁目から1桁おきに2倍にし、2倍が10以上なら桁の数字を足し(または9を引き)ます。すべて足した値が10の倍数なら合格です。一般にLuhnアルゴリズムと呼ばれ、カード番号体系の標準であるISO/IEC 7812-1がこのチェックディジットの方式を規定しています(標準の原文は有料なので、この文ではリンクしません)。ランダムな16桁の数字が偶然このチェックを通過する確率は10分の1なので、チェックディジットを使うと誤検知が10分の1に減ります。完全にはなくならないという意味でもあります。
置き換えることは、2つを一緒に行います。1つは、人が目で確認できるように下4桁だけを残すマスキングで、もう1つは、機械がつなげて見られるようにする仮名トークンです。トークンはhmacモジュールで作ります。値そのものをハッシュしてはいけません。口座番号は取りうる値が少ないので、単純なSHA-256は辞書攻撃で元に戻されます。秘密鍵を使うHMACであって初めて、鍵を知らない側が元に戻せなくなります。鍵はsecretsモジュールやopenssl randで作り、ログと同じ場所には置きません。
トークンのメッセージには、用途も一緒に入れます。acct|91231457820とcard|91231457820が互いに異なる値になるようにするのです。こうしておけば、どちらか一方のトークン表が漏れても、もう一方と突き合わせられません。
원본 "계좌 912-31-457820 카드 9012345678901234 일련번호 9900112233445566"
│ │ │
│ │ └ 검사숫자 실패 → 카드 아님 → 그대로 둔다
│ └ 검사숫자 통과 → ************1234
└ ***-**-**7820 + tokens.acct = ["acct_1f3c…"] (같은 계좌면 언제나 같은 값)
このコードブロックの韓国語コメントは、元の文字列に口座・カード・連番が含まれること、連番はチェックディジットが失敗するのでカードではなくそのまま残すこと、カードはチェックディジットを通過するので下4桁以外を隠すこと、口座は下4桁以外を隠したうえで、同じ口座なら常に同じ値のトークンを付けることを述べています。
現場での姿
第一に、2回回すと変わるスクラバーです。パイプラインはリトライをします。すでに隠された行をもう一度スクラビングしたとき、***-**-**7820のアスタリスクをさらに数えたり、トークンを再計算して別の値が出たりすると、突合が壊れます。処理済みの印を残し、ルールが自分の出力に再びかからないようにします。
第二に、隠すことと削除することの混同です。下4桁を残すマスキングは元に戻せませんが、すでに口座番号の一覧を持っている人には、候補を絞り込む手がかりになります。少数の口座だけを扱うファイルでは、下4桁だけで1人が特定されることもあります。そのため、持ち出しファイルでは、マスキングした値そのものを調査キーに使わず、トークンを使います。
第三に、鍵管理のない仮名化です。鍵をログと同じディレクトリに置いたり、コードに埋め込んだり、誰も鍵が変わった時点を知らなかったりすると、仮名値の意味が毎回変わります。レポートに鍵の識別子(鍵のハッシュの先頭部分)を書いておけば、「このトークンはどの鍵で作ったものか」をあとで言えます。
実務で本当に大切なこと
- 正規表現は候補しか出しません。チェックディジットや形式のルールでもう一度ふるいにかけないと、調査に必要な識別子を殺してしまいます。
- 同じ値は同じトークン、異なる用途は異なるトークンです。調査可能性と分離可能性を同時に得る唯一の方法です。
- 冪等性は機能です。2回回してバイトが同じかどうかを、テストで固定しておきます。
- 検査結果に元の値を書かないでください。漏えいレポートに流出した値をそのまま書くと、レポートがもう1つの流出物になります。
- ポリシーをファイルに置きます。何を持ち出さないか、何桁残すか、どれだけ保管するかを、人ではなくファイルに覚えさせます。
次のラボですること
合成した送金ログ640行を自分で作り、候補を探し、チェックディジットでカードと連番を分けたあと、マスキングと仮名トークンを付けた持ち出し版を作ります。そのうえで、元の口座番号を一度も使わずに、事故に遭った顧客の事案をトークンだけで追跡し、2回回して同じかどうかと、残った漏えいが0かどうかを確認して、ポリシーとレポートで締めくくります。採点ツールは、作成した鍵でトークンを再計算し、作成したプログラムを自分で作った番号で直接実行してみます。