產品筆記
個人資料放在哪裡
調查登入問題時，卻看到了不需要查看的個人資料。這項設計的起點，是日常維運中這種令人不安的經驗。
排查問題時，身分資訊也出現在眼前
營運身分平台時，經常會收到這樣的回報：“有個使用者無法登入。”為了查明原因，工作人員需要進入客戶環境，找到對應帳戶。
真正需要瞭解的事情很具體：帳戶是否被鎖定？上次嘗試在什麼時間、哪個環節失敗？使用者走了哪條登入路徑？通行金鑰的註冊是否仍然有效？
這些問題都不需要知道使用者是誰。但打開帳戶後，姓名、電子郵件、電話號碼和關聯帳戶會同時出現。原本只想查看運作狀態，卻連個人身分也一並看到了。
資訊已經顯示在頁面上時，
“請不要看”並不能成為有效的保護措施。
這並不是誰違反了規定。客戶提出請求，工作人員按流程操作，卻依然看到了不需要的資訊。問題來自系統本身的結構。
如果只靠規則和培訓來解決，就會依賴每個人的記憶與自覺。Authrim將個人資料放入獨立資料庫，正是為了從結構上解決這個日常維運問題。
從一開始就分成兩個資料庫
可直接識別個人的資訊存放在物理上獨立的資料庫中。這不是事後補上的隔離，而是在資料存取層就已經分開。
這樣就能處理開頭的問題。鎖定狀態、登入失敗記錄、裝置資訊，都可以在左側查看。授予排查所需權限時，不必同時授予右側權限，工作人員也不用刻意避開個人資料。
同樣的結構也便於回答稽核問題。姓名和電子郵件存放在哪裡、刪除涉及哪些範圍，都可以清楚說明。先解決維運問題，再獲得清晰說明系統的能力。
這並不意味著只有PII DB包含個人資料
需要明確的是：這種分離不是法律意義上的個人資料與非個人資料的界線。
Core DB也包含IP地址、裝置資訊、工作階段歷史、認證事件、憑證中繼資料和穩定的內部使用者ID。根據具體情境，它們也可能屬於個人資料。單獨看未必能識別人，與其他資訊結合後則可能做到。
Authrim實際區分的是可直接識別個人的資料和維運所需的身分資料。目標是讓排查能夠只存取後者，而不是說後者不需要保護。
因此，不能說“個人資料只存在於PII DB”。準確的說法是：姓名、電子郵件等直接標識資訊被隔離在PII DB中，可以在不存取該儲存的情況下授予排查權限。
刪除只是第一步
“請刪除我的帳戶”本身容易執行。隨後出現的兩個要求更難處理。
一是證明已經刪除，以後仍能查到何時、由誰、為何刪除。二是在一定期限內阻止重新註冊。
矛盾在於，這兩個要求都需要識別一個已經刪除的人。如果仍保留可直接識別其身分的資訊，就與刪除的目的相衝突。
實作中明確了這一取捨：只保留防止重複所需的指紋，期限過後自動刪除，同時記錄刪除時間、執行者和原因。
“無法恢復”成立的前提
補充一點技術細節：電子郵件地址的熵較低。如果只是普通雜湊，字典攻擊可能找回原始地址。“無法恢復”並非無條件成立。
Authrim使用帶秘密金鑰的HMAC-SHA256盲索引，並記錄金鑰代次以支援輪換。不掌握金鑰，就無法透過重新計算指紋來驗證候選地址。
因此，金鑰隔離是這種保護的前提。如果金鑰與指紋放在一起，這項保證就不再成立。
讓排查只看到需要的資訊
回到“無法登入”的回報。工作人員需要找出認證停在哪個環節，通常並不需要打開姓名或電話號碼。
Authrim將直接標識資訊分開存放，讓排查權限不必包含這部分儲存。如果調查確實需要個人資料，則由具備相應額外權限的人員處理。
加密與存取控制保護資料，稽核日誌記錄使用過程。同時，工作人員應當能夠在不打開無關個人資料的情況下完成日常排查。分離儲存，就是為了讓這種狀態成為日常維運的起點。
實作狀態：已完成儲存與存取邊界的分離。
驗證：透過原始碼儲存庫中的自動化測試持續確認。
維運成熟度：仍在加強中。Authrim目前處於pre-1.0階段。
這種設計讓刪除流程更容易執行，但本身不等於符合法律要求。實際法規遵循性還取決於組織的流程與合同。