系统里存着大量人员信息、联系方式、身份信息、业务记录，这些数据哪些能看、谁能看、能不能导出，是建设单位要负责的。做系统的时候如果只考虑功能，不考虑这些，后面要补的工作量很大。
分级和脱敏不用做得很复杂，但基本框架要有，否则没法回答数据是怎么管起来的。
一、先把数据分几档
常见的分法是三到四档。公开的，可以对外发布，比如政策通知、公开的统计数字。内部的，单位内部人员都能看，比如部门通讯录、工作安排。敏感的，需要限定岗位才能看，比如人员身份信息、联系方式、业务明细。核心的，极少数人可见，比如涉及资金、考核结果、案件信息。
分档之后，每一档对应的规则不一样。公开的可以随意导出，内部的限制导出范围，敏感的导出要审批并且留痕，核心的通常不允许批量导出。
分档工作建议由业务部门主导，技术方只提供方法。哪些字段算什么级别，只有业务方清楚，技术方按字段名猜往往会错。
二、几类常见字段怎么处理
姓名保留姓氏，名字用星号替换。这在不影响辨认的前提下，减少了完整姓名的暴露面。列表页面用这种处理，详情页面按权限决定是否显示全名。
手机号保留前三后四，中间打码。需要回拨的场景，可以提供一键拨号功能，不显示完整号码。
身份证号除了后四位全部打码。需要校验的时候用系统内部校验，不把完整号码显示给人看。
地址细化到街道或者村即可，不需要精确到门牌号，除非业务确实需要。很多系统的地址字段是自由录入的，历史数据里混着各种格式，处理起来比较麻烦，新系统建议改成结构化录入。
三、开发测试阶段最容易出事
最容易被忽略的环节是把生产数据直接拿到测试环境用。开发人员为了调试方便，导了一份真实数据到测试库，这些数据在测试环境里没有脱敏，也没有访问控制，风险很高。
合理做法是准备一套专门的测试数据，用工具生成，保证格式正确但人不真实。如果确实需要真实数据来复现问题，要经过审批，用完之后及时清理，并且记录谁用了、用了哪些。
还有几个容易漏的地方。日志里打出了完整的敏感信息，数据库备份文件没有加密，导出功能没有限制，测试账号权限过大。这几处都要在验收清单里列出来检查。
四、脱敏不是越狠越好
有个常见误区，把脱敏做过头，导致业务没法开展。比如客服需要看到完整手机号才能处理投诉，全部打码之后工作就做不了。
正确的做法是按角色和场景区分。同一份数据，在同一个系统里，不同岗位看到的内容可以不一样。客服岗能看到自己负责的客户的完整联系方式，其他岗位只能看到打码后的。管理员能看到完整信息，但每次查看都记日志。
这套做法在技术上并不复杂，难点在于要跟每个业务岗位确认他们实际需要看到什么。这项工作在需求阶段做完，比上线后再调整要省事。