Build Security In PII｜洞见

引子

很多年前，我沉迷在一款名叫《魔兽世界》的游戏中，不幸的是，我使用了Yahoo的邮箱来注册游戏账号。大约在2013年的某天，因为密码错误，我发现自己已无法登陆，同时，注册游戏账户的邮箱也被人修改了密码。不出所料，经过繁琐的手续找回密码后，发现自己已损失惨重，这直接导致我放弃了这款游戏。

不久就看到“Yahoo丢失了大量账户（一说500万账户被泄露，另一说则高达10亿）”的新闻，对于Yahoo来说，这只是业务江河日下的开始。不幸的是，在我们的生活中，只有危机发生后我们才开始重视，进行补救、修复、挽回、公关等工作，在安全领域预防危机是非常难的，而且也是经常被忽略的。我们常常会被一个简单的逻辑思路所误导：我们的系统看起来没有任何问题，为什么我需要安全保护呢？

作为一个用户，我们每天都在承受隐私被泄露的痛苦：

• 你的手机是否天天收到垃圾短信？是否被猎头各种骚扰？
• 你的QQ 、微信是否被广告、微商、奇怪的好友申请围绕？
• 在使用一个邮件去注册各种服务，该邮箱总会被垃圾广告填满？
• 只要联系过一次租房中介，每天都会被各种中介的电话亲切的问候？
• 在某搜索引擎上搜索了贷款，第二天被各种贷款、保险电话骚扰？

诚然，也许对于用户来说，保护自己的隐私或者尽早的适应隐私泄露的生活才是最重要的，但是矛盾之处在于，现代社会是建立在合作分工基础上的，你必须提供自己的身份信息来获取服务。对于服务的提供者（企业），保护个人隐私数据已经是一个社会责任，这会影响到用户的信任、企业的声望，特别是对于金融、审计、房产、航空、医疗等行业。

（我们可以为可能到来的无隐私时代做点什么？）

PII是什么？

PII是Personal Identifiable Information的全称，也被称为SPI（Sensitive Personal Information），从这个名字中我们可以读出三个关键点：

• 敏感的
• 标识的
• 个人相关

总结就是，PII可以用来识别出个体的信息。直接的PII信息有全名、地址、邮件地址、身份证、信用卡、电话号码等等，也有些信息是潜在的PII信息，比如经过简单的组合就可以识别出个体的信息，全名、省份、街道、年龄、性格、种族等。有这样一个著名的例子：1990年，87%的美国人可以被性别、邮政编码，以及出生年月所识别出。

在一个房地产应用中，使用服务的人分为两类：中介和客户，大量的用户都有强烈的买房欲望，用户群集中、多样性不高，如果泄露了这些优质用户的联系方式，有竞争关系的中介就会获得一个优质用户的联系列表，并且很可能直接骚扰用户，显而易见的后果是评价降低、带来公关危机、罚款以及用户流失。特别是在北美、欧洲、澳洲等发达地区，健全的法规对企业的约束与惩罚是非常严厉的，罚款往往是一个天文数字。

（email_address永远是存在最广泛的PII信息，可以思考一下，我们是否可以不需要该字段就完成我们的业务呢？）

危害

最近出现的一个新闻就是美国选举人信息泄露问题，由于数据库的错误配置，大约有2亿选民身份被泄露，大约有1.8T的数据量，泄露的身份占美国人口63%。泄露的数据包括姓名、出生日期、住址、电话号码以及选民注册细节信息，很难计算这样的数据泄露所造成的危害，但对于Deep Root Analytics这样的大数据分析的公司，声望的损失无法估量。

所以，当PII泄露后，最大的危害是大量的经济损失，包含有政府管理部门的罚款（往往伴随着法律问题）、对于用户的补偿、以及清理breach的各种成本。公关部门将会彻夜忙碌，开发部门天天加班，而管理人员则需要更新管理规范等，损失所产生的骨牌效应是无法预计的。2011年SONY PSN账户泄露造成了1.71亿美元的损失，SONY为每个用户的数据丢失付出了1.67$的代价。

在Ponemon Institute与IBM的报告《2017 Cost of Data Breach Study》中，每条丢失或被盗的记录的平均成本是$141。而且该报告中并不包括知识产权、商业秘密等高价值信息资产泄露的损失。数据永远是无价的。

即使像ThoughtWorks这样一个提供软件服务的公司，我们也需要为客户应用的安全提供更好的保护，并且如果暴露出隐私问题，很可能会带来法律责任。回到选举人泄露问题，这也说明了很多非专业的客户（政府、银行、保险、医疗等）并没有能力保护好自己的数据，对于一个专业的提供软件服务的公司，我们更需要替客户考虑周到，并且规避风险。

（一旦使用用户的信用卡数据， PCI标准便是一条红线，不能让信用卡在你的服务中裸奔）

Build Security In PII

我们在和一家审计行业的领先企业的长期合作中培养出了更高的隐私保护意识，资深的业务人员与安全技术人员会不断的分享关于隐私保护的知识，正如同其他的安全措施一样，所有的风险、漏洞都是存在在细节中的，只有意识上重视才能在工作中避免出现问题。

当意识一旦建立完毕后，开发人员、项目管理者等角色会主动引入PII信息保护到具体的业务设计、架构设计等，我们的工程师会主动确认、问询、double check PII。

对于一家审计行业的巨头，保护客户的隐私并且遵守法律的规定是极为重要的，他们也非常乐意与我们在合作中将隐私保护做到最好。同时，也很赞赏我们为隐私保护所作出的努力。我们要在和客户的长期合作中建立出对于PII的重视，在策略、法律、长期合作的基础上做到合理的保护PII。在顶层角度，我们输出两点：

建立意识：

保护PII是一个需要长期建立的意识，特别是对一些长期发展的项目中，需要每一位参与项目的人都要清楚的了解到PII是什么、为什么要保护它，要提高它的重要性，这个意识不应该随着人员流动而变的淡薄。目前在一个房地产信息项目中，如果需要新启动小项目，对项目中PII数据的识别、分析、提出保留策略等都会由组员所提出，并且提醒。在开发、测试等等环节中，参与的人员都需要按照之前讨论的策略对PII进行检查等。这些行为都是自发的，是由重视的意识所驱动的。

解决方案：

我所收集到的解决方案基本涵盖了PII数据的生命周期，有些解决方案关注于顶层策略，在战略层级制定PII的保护策略，有些则是需要开发新的系统、功能来维护数据安全，还有些是清理已有系统中的风险。同样，例如数据库加密，入侵检测等等这些基础设施上的保护功能也是可以帮助我们保护PII的。总体来说，在合适的层级、场景我们都需要有类似的解决方案。也可以把自己作为入侵者，来思考如何保护系统中PII的数据。

（BSI所提出的方法论）

制定Policy

一般来说，整体考虑PII的问题需要从制定顶层policy做起，首先必须明确一点：企业的雇员必须通过PII数据完成工作，如果雇员不需要用该数据进行工作的话，那么他就不应该接触到PII，进一步讲，就是不需要感知到PII的存在。销售人员需要给不同的客户发送促销通知，那么他就必须要知道用户的邮件地址。所以，将PII数据彻底的清除掉是不现实的。

在2017年6月1日施行的《中华人民共和国网络安全法》中，安全法规定了账号实名的法规，所以很多应用都需要更新以适应。不同的国家和地区对于个人隐私信息都是有明确法律法规的，所以也是必须要考虑的。

制定数据传输的规则和政策也是必要的，特别是在很多应用需要依赖于外部服务的情况下，我们需要考虑哪些数据是可以传输给外部服务的。很多应用都使用了log center来收集应用的日志，往往这些log center是三方所提供的服务，工程师们希望有详细的日志来帮助分析问题，所以很有可能将用户名、密码、邮箱地址等PII信息上传上去。这些PII数据就处于不可控的状态，提高了泄露风险。

我们也需要考虑数据聚合、备份等情况。某公司每天都会backup自己的数据库，但是所dump出的数据库备份，并没有做好权限保护，这也会造成泄露PII的风险（MySQL dump造成了大量的数据泄露，我们往往重视数据库的保护却忽略了备份）；Dropbox曾经犯过一个错误，由于错误的保存了用户数据的聚合（一个xlsx表格），某员工的账号被入侵，造成了6800万个账号信息泄露。特别是在扁平化的组织中，员工的账号都有很大的权限，这也为身份安全提出了新的挑战，当然这些挑战在安全领域都有很好的解决方案，很多安全领域的solution都可以帮助我们降低PII泄露的风险，即使该solution不是针对PII的。

一旦我们保留PII信息的策略发生变更，我们需要更新User Agreement以通知用户，简单的来说，如果用户不同意我们的策略，我们就不能提供服务。现代应用往往都有很多客户端，怎样将User Agreement推送给用户，并且保证用户阅读并同意是一个关键点。可以参考的是iOS更新，每次更新都会加入User Agreement的改动，并且只有将滚动条移动到最后才能进行升级操作。User Agreement不仅仅是对用户的声明，也可以保护企业规避部分法律风险。

总体来说，制定PII保护的Policy需要有四个步骤：

1. Find：找到系统中持有的PII数据，以及需要解除或者使用PII数据的角色。
2. Arrange：分析并整理数据，哪些是必要的，哪些是不必要的，哪些的权限需要更新，而哪些存放在三方服务中等等。
3. Create：根据整理到的数据建立policy，包含有action。例如：我们不希望在日志中保留用户的信息，应该修改日志记录的内容，同时处理掉已有的数据中的PII。
4. Educate：将制定的policy 通知给相关的人员，确保所有人都清楚我们的策略。

考虑PII数据的生命周期

之前我们是通过组织结构来规划我们的PII保护策略的，也可以使用另一种角度去达到目的，就是紧跟PII数据的生命周期。我们可以将数据生命周期表示为：存储、处理、传输，PII数据永远都是在这三个状态中进行转换，于是我们提出以下五个步骤来处理PII：

1. 考虑哪些数据是必要的，收集并持有必要的数据；
2. 根据我们的隐私策略，如何持有、处理这些PII数据（例如加密、权限设置、敏感字符替换等等）；
3. 根据新的风险调整策略，并且演进业务逻辑；
4. 合理的规划保护PII数据的每一个步骤（细化）；
5. 销毁不必要的数据，包括backup，log甚至audit report。

例如我们在开发一个提醒用户房产项目更新的服务时，在项目启动阶段，我们就会考虑到该系统会使用到哪些PII的数据，由于我们要给用户发送邮件和推送，用户的邮件地址与设备id就是PII，而信息中往往也含有用户的全名，我们必须要使用这些数据。所以问题就变成了我们如何持有、消费、销毁这些数据。

最少一个追踪邮件是否送达的数据表中，只需要知道邮件的标记就足够了。对于BA想看到的审计数据，也需要经过处理，例如展示收到邮件最多的地址时，我们可以使用wildcard来替换掉邮件地址中的部分字符。在开发过程中，需要注意的是不要在日志、监控这样的地方泄露PII，部署中也得考虑数据库加密、线上环境的权限配置等等工作。总而言之，在这个服务中，系统是需要知道邮件的目的地址的，而雇员、工程师、其他人则是不需要的，所以PII应该设计为对这些人不可见。

（dump file永远都是十分危险的，无数数据都是通过mysql dump泄露的）

总结

PII数据保护是一个范围很大、优先级很高的事情，最重要的意识是根据大量的教育、分享、实践所build出来的。同时，PII也是信息安全的重要组成部分，我们希望不论是在交付还是在咨询项目中，我们能够考虑到了PII信息，也给出了较好的解决方案，则会提高我们的声望。而PII泄露的事故正如很多信息安全故事一样，如果不出事故则不会被重视，但是一旦出现事故，结果往往则是无法挽回的。保护PII，不仅是保护客户的利益，也是保护我们自己。