日志中的用户隐私安全

摘要：

对于敏捷团队，安全卡应该提到比业务卡更高的优先级，同样需要放在backlog里面进行track，需要kick off、deskcheck，需要一个正经的流程或者仪式感强化成员的意识：安全卡和业务卡、Bug卡都是项目交付中的一等公民。

与“中国人愿意用隐私交换便利性”的心态完全不同，欧美国家在个人隐私保护方面明显走得更早也更远一些。在2018年5月GDPR发布前后的一段时间里，保护个人隐私相关的需求被迅速提高了优先级，而像我这样一个开发涉及欧美产品的普通程序员，日常工作也因此受到影响，我们放下手中的业务需求卡（Story），转而去做GDPR相关的安全需求。

一般在医疗保健或金融行业中，限制访问客户的敏感数据有着非常严格的规定，尤其欧洲GDPR颁布之后，公司泄露个人数据的后果也非常严重。在个人隐私保护方面，国内目前在法律和意识方面处于滞后的状态，但是许多人或多或少都感受到个人信息泄露给自己带来的麻烦，比如骚扰电话的增多就是最明显的例证。比较乐观的是，随着网络安全法的发布健全、网民意识的觉醒，我们的个人信息保护正走在大路上。

对于一些面向欧美的项目，从公司最高层面，自上而下，我们采取了一系列相关动作，比如梳理我们基础设施架构图、数据流图、API数据字段分析等，其中包括保护日志中的个人信息。

安全问题的特殊性

个人隐私安全和其它安全问题一样，是一个永远做不完的需求。你不能说你的网站是绝对安全的，只能说“我检查了所有目前已发现的安全漏洞列表（Checklist），并且采取了相应的防御措施，做到尽量安全”，或者说我们采取了一些很好的安全实践，比如采取了动态密码、在nginx上安装了防攻击防SQL注入插件等等。

现在的Web系统一般都配备了日志系统用于记录访问请求、分析线上事故等，比如开源的有ELK，SaaS的有DataDog、Sumo Logic 等。

在日志记录过程记录下一些用户隐私信息往往是不可避免的。诚然，开发者的个人隐私保护意识是很重要的，但有时并不一定是开发者的主动想偷窥用户信息。比如这里举一个很常见的情况，有些程序异常如果没有合理捕获，往往会输出调用堆栈，这些调用堆栈里面某些方法的参数可能就包含有个人隐私信息。

虽说没有一种一劳永逸的方式来避免个人信息出现在日志中，但我们可以通过下面的实践来尽量规避，并将这些内建在自己平时的开发工作中。下面的实践，一些涉及到了代码层面的技术实践、团队流程的优化，还有的是测试、运维上的一些措施。

首先：确定什么是隐私数据

在我们深入讨论怎样避免个人隐私数据出现在日志之前，我们来界定什么是隐私数据：

• 个人可标识数据（PII）：如社会安全号码，数据组合（如名字+出生日期或姓氏+邮政编码）或用户生成的数据（如电子邮件或用户名，如bywang@thoughtworks.com），手机号。