前几天威尔发的关于“最后一道防线-内核级HIDS”的文章反响热烈，关注公号的小伙伴一下子就好几百，十分了不起。这件事让威尔开心了好几天，但是因为公号才开不久，没办法留言互动，这就让人有了冲关的冲动。然后威尔就开始催促噶师傅写稿子，噶师傅最近忙于和公园大妈抢地盘斗萨克斯，以及为小伙伴着火的主板灭火，一直顾不上，所以我就弱弱的举手，打算写一篇凑数。
一直很想写写GDPR这个话题，原因是大概几个月前，换工作的时候，电话面试了一下蚂蚁金服，人家就随便问了几个实操中的问题，比如一个实际的项目要从哪里入手，推动的困难会有哪些，这些问题我没答上来。只能尴尬的说说自己认识谁谁谁，是哪家公司负责隐私和数据安全之类的，尴尬的要死...现在新公司四个多月了，GDPR的项目推进到了一个里程碑的阶段，感觉可以稍微总结一下，算是对当时的自己的一个交代吧。
GDPR项目解构
GDPR是一套要求、规则，大概分了三拨参与者，用户、服务商、监管。从企业角度来说，主要是需要了解作为服务商该干点啥，就能满足要求了。我读了读GDPR的原文和翻译稿，感觉就是...很催眠。法律文书的感觉就是这样，专业名词一大堆，定语一大串，经常使用多重否定，每个字都认识，但是你就是不知道他说了点啥，这就叫专业...
其实这种项目，最重要的就是解构，把看不懂的东西，解构成一个个目标，每个目标都达成，所有的要求也就符合了。这件事很像搞晚会，十几年前读书的时候，参加过水源BBS站庆的晚会筹备，本来感觉很复杂的事情，结果发现无非就是每个版块出个节目，然后彩排的时候音响、灯光配合一下，然后主持人中间出来串场就好了。
GDPR项目其实也一样，我们把GDPR项目解构成了五大部分：
1. 现状调研与差异分析 - 妥妥的咨询套路
2. 隐私协议 - 对外
3. 隐私和数据保护管理流程 - 内部
4. 数据保护技术方案落地
5. 其他
好了，如果你看到这里就恍然大悟的话，那基本上后面就不用看了，哈哈哈…在这五个大部分里面，如果把1、2、3都做了，感觉能得75分，4也做了，就能到90分。
这里面最核心的其实是三个东西：
一是隐私协议，这是一张皮，但是这张皮提纲挈领，非常重要，它是指导我们如何开展现状调研、差异分析的指引，也是指引我们进行流程建设的方向。
二是隐私和数据保护流程，其实这个就是“言必信，行必果”，隐私协议里面承诺了那么多，就需要能够说到做到，比如信息访问更正权、被遗忘权、可携权啥啥的...
三是数据保护的技术方案，这也是承诺的落实了，上面是流程上支持，这里是技术上支持和落地，比如加密、脱敏、遮蔽之类的...
总结一下，GDPR项目，解构出来就是几个目标，差异分析报告、隐私协议、管理流程、数据保护的落地方案、其他... GDPR项目推进过程 其实这个推进过程没什么好写的，就是PMP里面列的那些事儿，明确目标，定出来计划，做WBS分解，识别干系人，开启动会，定期跟进、汇报项目的进度，出了问题做风险处置和项目变更，然后跟老板约个时间总结汇报吹吹牛逼之类的。不过，我觉得 有一点在这里面非常重要，就是项目负责人的角色，虽然有点自吹自擂，但是我打心底里觉得项目负责人是项目成功的关键。
GDPR的项目往往会多方参与，比如我们这次项目就前后牵扯到了技术团队、法务团队、安全团队、客服团队超过30个干系人， 越多的参与团队意味着越高的沟通成本。项目负责人之所以关键，是因为他需要弥合不同团队人员背景知识的差异所导致的对问题认知的差异， 在必要的时候进行即使不完美的决策以推动项目整体的进展。
项目推动过程中，还需要充分调动各个参与方的专业所长，比如隐私协议制定过程中，技术团队对于信息的收集方式、内容、使用方式、保护方式等都非常清楚，而法务的同事则在公司法律主体信息、法规要求解读等方面非常专业，客服团队则对用户行为习惯、服务支持流程及工具非常熟悉，当大家充分参与到项目的建设中时，形成的合力可以使信息快速补全，使流程设计快速完善。再次不得不夸赞一下我们项目组的伙伴们，都是长得好看还做事漂亮的好战友！
其实我开始的时候，对这个项目的推动还挺担心的，因为大家都是第一次一起合作，可能需要很多必要的磨合。不过这一路走过来，都成了可以信任的伙伴，这让我回想起了李亚鹏之前在接受采访时候说过的一句话， “既不要低估公众对慈善的热情，也不要高估公众对慈善的参与度”。 其实就是要努力的降低门槛和难度，让项目组的伙伴们尽可能在能力范围之内做出贡献，他们给予的支持会超乎想象。
项目中的几个问题
问题一：是不是所有的用户权利都要支持
在准备隐私协议的时候，对比几家大厂的隐私协议的版本，我们发现用户权利真是挺多的，查看、修改、更正、可携、数据删除、撤回授权、免受自动化推荐等等。本来我们的想法是，有啥都一股脑的写上去就得了，但是仔细想想，这样是不对不负责任的。我们认真研究了每一项权利的含义，然后再确认隐私协议里面该怎么写。比如说免受自动化推荐这个事，虽然我们做了很多BI方面的工作，但实际上目前并没有千人千面、自动化推荐这样的模式存在，最终决定说明情况，然后NA掉。可携权也是如此，我们认为可携权是在数据有其他用途或进行服务迁移时才需要支持，比如银行流水、购物记录、通信记录等等，这些都可以用来贷款啊征信啊什么的，但是我们平台上的数据看起来并没有这样的必要性，所以也就NA掉了。
问题二：客户如何证明自己受到GDPR保护而有权要求我们删除数据
这是个困扰了我们一阵子的问题，因为GDPR也是有范围的，欧盟相关才管得到，那比如我一个非洲兄弟过来要求删账号，我是不是可以不支持？对于这个问题，我们最开始的时候是一视同仁，全球兄弟都一样，有要求我们就满足，但是这样的做法并不能满足我们对这个问题的探索。所以我们在圈子里面咨询了行业专家，小伙伴们给了很多精彩的建议，我简单的列一列。
1. GDPR是对公司的要求，只要你这个公司为欧盟提供服务，那么你就要遵守。意思是说，如果这个公司只为非洲兄弟服务，那我不管你，但是如果你为欧洲兄弟服务，那么你得遵守这个规定，得支持权利的伸张。
2. 如何界定你是不是为欧洲兄弟服务呢？答案：看你是不是用欧盟语言或者货币。现在的服务都是互联网，你公司开在哪都有可能，但是这服务全球都能用。所以这就给界定是否为欧盟服务带来了困扰。从业者给出的这个答案，我觉得挺好。
3. 欧洲用户并没有实名，我如何判定你是不是欧盟的人。其实，上面两个问题回答了之后，这个问题就不重要了，因为只要你的用户里面有欧盟用户，那么理论上来说，所有用户都应当受到同等的权利保障。不过最开始的时候，小伙伴们给出了一些答案，比如注册地IP、访问IP等，比如要求对方提供身份证明材料...想来想去都觉得提供证明材料实在是不太好，所以就索性都支持了吧...
问题三：DPO如何设立
当时我们有一些困扰，是不是一定要有DPO，DPO是不是必须要欧盟的人，DPO是不是背锅侠。我来说说我们目前得到的答案和我们的做法。
首先，DPO不是一定要有，只有三种场景下才一定要设立DPO（具体哪三种，随便搜搜就有）。其次，如果设置DPO，只需要能力强就行，不需要任何资质也没有国籍限制，这是企业内部的事情。第三，DPO只要证明自己履责了，风险评估做了、汇报做了、建议做了、要求整改了，就可以免责，责任就是企业运营方了，也就是老板，所以不存在背锅蹲大牢的风险。我们自己这边呢，项目团队的核心成员自然的组成了一个工作小组，虚拟履行DPO职责，我觉得也差不多够了，反正该干的活儿都干了。
这是我最近的一些心得，也算是对GDPR这个项目的一个阶段性的回顾，我觉得最有价值的就是项目解构，知道目标，知道做点啥，整个事情也就没那么多神秘感了。当然，我也知道自己对GDPR的理解十分粗浅，甚至有些地方是谬误的，真心地欢迎指正、探讨，不过现在公号还不能评论，不过你可以关注公号，然后留言。经常看到后台有人在留言调戏噶师傅，欢迎大家来调戏，哈哈~
2019.8.22
声明：本文来自灾难控制 局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
