此文总结了笔者在工作中涉及到敏感数据时候的一些心得体会，如有不对的地方欢迎大家交流、分享。
敏感数据有很多范畴，不同情况下任何数据都有可能成为敏感数据。
用户数据
在互联网人口红利的背景下，针对C端产品，数据变得越来越值钱，其中最常见的莫过于用户数据。任何产品都离不开用户。拿到了用户数据，就意味着有了流量入口，有了流量继而可以寻求多种变现方式。
而在B端产品中，更多的是企业一群人在一起协作，每一个人在工作流中都扮演着重要的角色。而这类产品的用户数据一旦泄漏，将意味着整个业务流的中断，甚至发生其他核心业务数据的泄漏等更严重的后果。
财务数据
……
联系方式，想必都有过接到各种各样推销的电话、短信等垃圾信息，给生活造成了不小的困扰。
联系方式+自身需求，这种更加可怕，个人深有体会，以房产为例：
看房子的时候如果留了电话，会有各种各样的售楼信息轰炸你，房子买了之后还会接到骚扰；房子买了之后会有各种各样的装修公司给你打电话，在你装修过后仍然会接到骚扰电话，在住进去2年后还会接到电话：您好我们是XXX装修公司的，请问您有装修的需求吗？
另外一些个人身份信息、财务信息更为重要，万一遭到不法分子窃取，并且用于牟取非法利益，个人会蒙受财务损失、承担法律风险。
对于企业/组织而言，如果这些敏感数据一旦发生丢失、失窃，将会面临严重的财务、法律或问责风险，更重要的是将会失去用户的信任，最终导致企业破产。
在不同的场景下，需要对敏感数据实施具体的处理方法，常见的方法如下：
权限隔离：一般业务系统是一个组织的人在用，而非个体。一些敏感数据有的时候只需要少部分人才能看到，如有这种需求就需要在产品设计阶段梳理清楚，通过引入系统权限模型，进行权限隔离。这里不展开，后续还会有介绍；
加密：密码123456经过MD5加密后的结果为：md5(123456,16) = 49ba59abbe56e057。业务系统用户密码在数据库中一般都是通过Hash算法处理后加密储存的。MD5加密过后的密码还可再次进行加盐处理，甚至可以加入随机盐，进一步保证数据安全性。安全程度取决于采用哪种加密算法，一般根据实际情况而定；
部分掩码: 123456 -> 1****6，保留了部分信息，并且保证了信息的长度不变性，对信息持有者更易辨别， 如用户名、手机号、邮箱、身份证号等；
完全掩码：比较常见，如在输入登录密码、银行密码等场景下，输入控件都会将真实密码遮掩显示；
替换：如统一将女性用户名替换为F，对内部人员可以完全保持信息完整性，但易破解；
截断：13811001111截断为138，舍弃必要信息来保证数据的模糊性；
日期偏移取整：20130520 12:30:45 -> 20130520 12:00:00，舍弃精度来保证原始数据的安全性，一般此种方法可以保护数据的时间分布密度。
笔者倒是没有涉及过5、6、7的处理方法，看到前人总结的经验也在此贴出来分享一下。
另外还有一点，如果数据需要在前端页面脱敏展示的话，需要保证后段接口返回的是已经脱敏后的数据。不过这种常识研发人员肯定都清楚。
一些交付类的项目，在生产环境正式上线之前，系统需要准备上线运营所必要的基础数据，这时如何将客户的基础数据交付到生产系统中，也需要考虑：
（1）非敏感数据只需要开发数据导入的单元测试，导入非生产环境（例如预发布环境），确认数据准确性后，再将数据迁移至生产环境即可。
如果在需求中就包含敏感数据的导入功能，大可不必担心敏感数据触碰问题，在生产环境上线后，可由甲方人员自行将数据导入。需要做的就是进行严格测试，保证功能可行性，做好容错机制。（例如：导入数据一旦有误，抛出异常信息，打印、记录日志。如有需要可以将本次导入的数据全部回滚，根据报错信息调整源数据，避免清洗脏数据的重复性工作）
当然也有部分情况下，这部分敏感数据没有开发可视化的导入功能，只是在环境正式上线前需要处理一次。例如：甲方员工的人员信息，可以开发数据导入的单元测试，用测试数据验证工具可行性。在应用正式上线前，在客户现场将数据导入生产环境，随后即将数据删除，免责。
如果以上条件都不具备，亦可通过类似三权分立的管理类机制，进行权限划分，保障敏感数据安全性，同时也将我方人员通过这种机制尽量保护起来：
研发工程师：提供已测试通过的数据导入的单元测试；
运维工程师：执行单元测试，导入敏感数据（不限定执行人，如甲方人员可操作那更好）。
如有必要可以与甲方当面进行敏感数据处理，实施完成后当即删除源文件。
以上只是列举了几种交付中数据处理情况，实际过程中需要根据实际业务针对特殊的敏感数据设计不同的实施方案。但是保证一个原则：尽量不要触碰业务方的敏感数据。
业务系统核心本质是解决多人协作的问题。不能每个人所做的工作是一样的，所以每个人有自己的职责范围，这时需要划分权限，常见的几种权限设计模型：
自主访问控制（DAC：Discretionary Access Control）
强制访问控制（MAC：Mandatory Access Control）
基于角色的访问控制（RBAC：Role-Based Access Control）
产品设计中目前最常用的RBAC模型，主要包含三个基本要素：用户、角色、权限。
而每个基本要素均可以根据实际业务按需进行拓展：
（1）用户
组织（企业、部门……）
用户
（2）角色（权限集合）
角色组
角色
（3） 权限
查看（可以根据实际业务，设计不同维度可查看的数据范围）
新增
修改
删除
……
备注说明：
简而言之：用户关联角色，角色关联权限；
原子权限的控制本质上是对接口调用权限的控制；
复杂的业务场景中可根据组织、用户、角色组、角色要素设计具有继承性、限制性的权限模型。
在梳理权限的时候可以通过excel表格，梳理清楚角色权限的关系，具体可参考下表：
笔者一直从事B端产品建设，其中也不乏一些企业级应用。期望在企业级应用之中总结一些心得体会，最终沉淀出一些方法论。有机会多多和大家分享交流。
