产品笔记
个人信息放在哪里
调查登录故障时，却看到了不需要查看的个人信息。这项设计的起点，是日常运维中这种令人不安的经历。
排查问题时，身份信息也出现在眼前
运营身份平台时，经常会收到这样的反馈：“有个用户无法登录。”为了查明原因，工作人员需要进入客户环境，找到对应账户。
真正需要了解的事情很具体：账户是否被锁定？上次尝试在什么时间、哪个环节失败？用户走了哪条登录路径？通行密钥的注册是否仍然有效？
这些问题都不需要知道用户是谁。但打开账户后，姓名、邮箱、电话号码和关联账户会同时出现。原本只想查看运行状态，却连个人身份也一并看到了。
信息已经显示在页面上时，
“请不要看”并不能成为有效的保护措施。
这并不是谁违反了规定。客户提出请求，工作人员按流程操作，却依然看到了不需要的信息。问题来自系统本身的结构。
如果只靠规则和培训来解决，就会依赖每个人的记忆与自觉。Authrim将个人信息放入独立数据库，正是为了从结构上解决这个日常运维问题。
从一开始就分成两个数据库
可直接识别个人的信息存放在物理上独立的数据库中。这不是事后补上的隔离，而是在数据访问层就已经分开。
这样就能处理开头的问题。锁定状态、登录失败记录、设备信息，都可以在左侧查看。授予排查所需权限时，不必同时授予右侧权限，工作人员也不用刻意避开个人信息。
同样的结构也便于回答审计问题。姓名和邮箱存放在哪里、删除涉及哪些范围，都可以清楚说明。先解决运维问题，再获得清晰说明系统的能力。
这并不意味着只有PII DB包含个人数据
需要明确的是：这种分离不是法律意义上的个人数据与非个人数据的界线。
Core DB也包含IP地址、设备信息、会话历史、认证事件、凭据元数据和稳定的内部用户ID。根据具体情境，它们也可能属于个人数据。单独看未必能识别人，与其他信息结合后则可能做到。
Authrim实际区分的是可直接识别个人的数据和运维所需的身份数据。目标是让排查能够只访问后者，而不是说后者不需要保护。
因此，不能说“个人数据只存在于PII DB”。准确的说法是：姓名、邮箱等直接标识信息被隔离在PII DB中，可以在不访问该存储的情况下授予排查权限。
删除只是第一步
“请删除我的账户”本身容易执行。随后出现的两个要求更难处理。
一是证明已经删除，以后仍能查到何时、由谁、为何删除。二是在一定期限内阻止重新注册。
矛盾在于，这两个要求都需要识别一个已经删除的人。如果仍保留可直接识别其身份的信息，就与删除的目的相冲突。
实现中明确了这一取舍：只保留防止重复所需的指纹，期限过后自动删除，同时记录删除时间、执行者和原因。
“无法恢复”成立的前提
补充一点技术细节：邮箱地址的熵较低。如果只是普通哈希，字典攻击可能找回原始地址。“无法恢复”并非无条件成立。
Authrim使用带秘密密钥的HMAC-SHA256盲索引，并记录密钥代次以支持轮换。不掌握密钥，就无法通过重新计算指纹来验证候选地址。
因此，密钥隔离是这种保护的前提。如果密钥与指纹放在一起，这项保证就不再成立。
让排查只看到需要的信息
回到“无法登录”的反馈。工作人员需要找出认证停在哪个环节，通常并不需要打开姓名或电话号码。
Authrim将直接标识信息分开存放，让排查权限不必包含这部分存储。如果调查确实需要个人信息，则由具备相应额外权限的人员处理。
加密与访问控制保护数据，审计日志记录使用过程。同时，工作人员应当能够在不打开无关个人信息的情况下完成日常排查。分离存储，就是为了让这种状态成为日常运维的起点。
实现状态：已完成存储与访问边界的分离。
验证：通过代码仓库中的自动化测试持续确认。
运维成熟度：仍在加强中。Authrim目前处于pre-1.0阶段。
这种设计让删除流程更容易执行，但本身不等于符合法律要求。实际合规性还取决于组织的流程与合同。