プロダクトノート
個人情報の置き場所
この設計は、規制対応から生まれたものではありません。「ログインできない」の調査をしていて、見なくていいものを見てしまうという、運用の現場で毎回起きていた居心地の悪さが出発点です。
調査に入ると、否応なく見えてしまう
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 です。
なお、この設計は削除依頼への対応をやりやすくするものであって、 それ自体が法令順守を意味するわけではありません。 実際の適合性は、運用手順や契約を含めた組織側の判断になります。