权限设计要从岗位职责出发
权限混乱是多数内部系统的通病。常见做法是给每个人开尽可能多的权限，以免影响工作，结果是敏感数据被大范围可见，出现问题时也无法定位。
比较有效的起点是按岗位梳理数据范围：这个岗位在工作中必须看到哪些数据、可以修改哪些字段、能否导出。三个问题答完，权限模型基本就成型了。
导出权限需要单独控制。浏览和导出带来的风险完全不同，一份客户名单在系统里查看与变成一份表格文件流出，后果差异很大，因此导出通常应当纳入更严格的审批。
账号本身也要有生命周期管理。人员入职、调岗、离职时权限是否及时调整，是安全事故中最常见的诱因，这项管理动作需要明确责任人。
操作留痕与责任可追溯
留痕的目的不是监控员工，而是在数据出现异常时能够还原过程。缺少记录时，问题只能靠回忆与推测，既影响处理效率，也容易造成内部矛盾。
需要记录的内容包括操作人、时间、操作对象、变更前后的值。其中变更前后的值最容易被省略，却是排查问题时最有用的一项。
登录与关键操作也应当记录来源信息，配合异常登录提醒，可以在账号被盗用时及时发现。对于涉及资金或重要审批的功能，还应当增加二次确认环节。
备份要验证过恢复才算数
备份策略需要回答三个问题：多久备份一次、保留多长时间、存放在哪里。三个问题都与业务对数据丢失的容忍度有关，而不是按习惯设置。
备份存放在同一台服务器或者同一个机房，只能应对误删除，无法应对硬件故障或者更严重的情况。至少应当有一份异地或者异环境的副本。
最关键的一步是定期做恢复演练。备份文件是否完整、恢复流程是否可用、恢复需要多长时间，只有实际做过才知道。没有验证过的备份只是心理安慰。
合规要求与合同条款的衔接
涉及个人信息处理的系统，需要在收集环节说明用途与范围，并尽量遵循最小必要原则。收集了用不到的信息，既是风险也是负担。
如果系统由外部团队开发或托管，应当在合同中约定数据的所有权、访问范围、保密义务以及合作终止后的数据交付与删除方式。这些条款需要在合作开始时就谈，事后追加会很被动。
最后，安全措施要与业务规模匹配。一个内部使用的排班系统与一个面向大量用户的交易系统，防护重点完全不同，把资源投在最可能出问题的地方，比照搬一套通用方案更实际。
还有一点常被忽略：权限需要定期复核。组织架构调整或者岗位职责变化之后，原有权限往往不会自动收回，累积一段时间就形成了大范围的隐性可见。建议至少每年做一次权限对照检查，把离岗人员的账号停用、把超出职责范围的数据访问收回，这项工作耗时不多，效果却很直接。
