プロダクトノート
個人情報の置き場所
この設計は、規制対応から生まれたものではありません。「ログインできない」の調査をしていて、見なくていいものを見てしまうという、運用の現場で毎回起きていた居心地の悪さが出発点です。
調査に入ると、否応なく見えてしまう
IDの基盤を提供していると、「特定のユーザーがログインできない」という連絡が来ます。 原因を調べるには、お客様の環境に入り、該当するアカウントを探すことになります。
知りたいのは、アカウントがロックされているか、最後の認証がいつ、どこで失敗したか。 どの経路でログインしようとしたか。パスキーの登録はまだ使えるか。
どれも、その人が誰であるかとは無関係です。 それなのに、アカウントを開いた瞬間に氏名が出ます。メールアドレスが出ます。 電話番号も、連携先のアカウント名も、同じ画面に並んでいます。 調査に必要なのは状態だけなのに、人格が一緒についてきます。
「見ないでください」という運用ルールは、
画面に表示されている限り機能しません。
担当者に落ち度があるわけではありません。お客様に頼まれ、正規の手続きで入り、必要な調査をしている。 それでも個人情報が見えてしまう。そういう構造だからです。
規則や研修だけに頼ると、担当者の記憶力と良心に任せることになります。 それだけでは、いつか事故として表面化します。 Authrimが個人情報を別のデータベースに置くのは、まずこの問題を設計で解けないかと考えたからです。
普通は、全部ひとつのDBに入る
IDの仕組みを作ると、扱うデータは自然に混ざります。 氏名やメールアドレス、アプリを使う権限、ログイン中の端末、パスキーの登録情報、外部IDとの連携先。
どれも「ユーザーに関するデータ」です。素直に作れば、ひとつのデータベースに入ります。 それでも動きます。困るのは、あとで説明を求められたときです。
「個人情報の所在を図示してください」「漏洩した場合の影響範囲は」「削除依頼への対応手順は」。 全部が同じ場所にあると、答えは毎回「ユーザーテーブル一式」です。 どこまで影響するのか、範囲を絞って説明できません。
Authrim は最初から二つに分けている
Authrimは、個人を特定できる情報だけを物理的に別のデータベースに置きます。 あとから分けたのではありません。リポジトリ層から別の系統にしています。
保存先を分けると、冒頭の調査では左側の情報だけを見れば済みます。 ロック状態も、認証の失敗記録も、端末の情報もそこにあります。 右側に触れない権限で調査できるので、担当者が「見ないように気をつける」必要はありません。
同じ構造なら、審査や監査の質問にも答えやすくなります。 氏名やメールアドレスの置き場所をすぐに示せて、削除の手順も範囲を区切って説明できます。 先に運用上の問題を解こうとした結果、たまたま説明もしやすくなりました。
PII DB だけが個人データ、という意味ではありません
ここを取り違えると危険です。 この分離は「個人データ／非個人データ」の法的な線引きではありません。
Core DBにも、IPアドレス、端末情報、セッション履歴、認証イベント、資格情報のメタデータ、 内部で使う安定したユーザーIDなどが入ります。これらも、状況によっては個人データに該当します。 単独では個人を特定しなくても、他の情報と組み合わせれば特定に至ることがあるためです。
Authrimが分けているのは、個人を直接識別できるデータと、運用上のアイデンティティデータです。 前者を開かず、後者だけで障害調査ができるようにしています。 だからといって、後者を保護しなくてよいわけではありません。
「個人データはPII DBにしかない」という説明は正しくありません。 氏名やメールアドレスなど、直接識別できるデータをPII DBに隔離する。 障害調査の権限は、そこに触れずに渡せる。そういう設計です。
削除依頼で本当に難しいのは、消すことではない
「アカウントを削除してください」と依頼されたとき、消すこと自体は簡単です。 そのあとに、難しい要求が二つ残ります。
ひとつは消したことの証明。いつ、誰が、なぜ消したのかを後から示せる必要があります。 もうひとつは消した人が再登録してこないこと。 退会直後の再登録を一定期間止めたい、という業務要件はよくあります。
どちらも、消したはずの人をあとから識別するよう求めています。 けれど識別できる情報を残していたら、そもそも消したことになりません。
実装のコメントにも、この設計判断が書かれています。 個人情報は保存しない。重複防止のための指紋だけを持つ。保持期限を過ぎたら自動的に消える。 誰が・いつ・なぜ削除したかは記録する。
「復元できない」が成り立つ条件
ただし、メールアドレスはエントロピーが低い情報です。 単純なハッシュで指紋にしただけでは、辞書攻撃で元の値を突き止められます。 「復元できない」と無条件には言えません。
Authrimでは、秘密鍵を使うHMAC-SHA256のブラインドインデックスを採用しています。 鍵世代の番号を持たせ、鍵の更新にも対応しています。 鍵を知らなければ、指紋の総当たりはできません。
だからこそ、鍵を指紋から隔離することが、この保証の前提です。 同じ場所に置けば、保証は失われます。
調査に必要なものだけを、見られるようにする
最初の「ログインできない」という問い合わせに戻ります。担当者が知りたいのは、認証がどこで止まったかです。氏名や電話番号まで開く必要はありません。
Authrimでは、直接識別できる情報の保存先を分けています。担当者には、その保存先を開かずに調査できる権限を渡せます。個人情報が必要な調査は、別途その権限を持つ担当者が扱います。
暗号化とアクセス制御で守り、監査ログで扱った事実を確かめます。そのうえで、普段の調査は必要のない個人情報を開かずに終えられる。それを日々の運用の出発点にしたくて、保存先を分けています。
実装 完了（保存とアクセス境界の分離が動作）
検証 自動テストで継続的に確認
運用成熟度 本番向けの追い込み中。Authrim 全体が pre-1.0 です。
この設計は削除依頼への対応をしやすくしますが、それだけで法令順守になるわけではありません。 実際に適合するかは、運用手順や契約も含めて組織が判断します。