GDPR 巨额罚款震撼全球，聊聊隐私安全建设思路与实践

本文整理自字 OPPO 安全专家沈海涛在QCon 2022 广州站的演讲分享，主题为“OPPO 互联网业务隐私安全建设实践”。

分享主要从四个部分展开：首先是风险概述，其次是应对风险的整体思路，然后是在一些业务中的具体实践，最后是总结与展望。

隐私安全面临的风险

从法律上讲，2018 年 GDPR 的出台是隐私安全的一个里程碑。从 2018 年开始，各企业和国家更加重视隐私相关的保护，我本人也是从 2018 年开始真正做隐私安全，我之前在做传统安全，比如黑客的攻防对抗，排查业务是不是存在安全风险等。

由于 2018 年 GDPR 的出台，以及 OPPO 开始扩展一些海外业务，迫使我们更多的投入到隐私安全的工作中来，它已经成为与传统安全并列齐驱的一块工作内容，欧盟 GDPR 出台之后，全球各地都开始推出各种各样的法律法规。 

接下来大家看一组数据，看题目大家已经能够大概猜到，这是一个监管的处罚情况。我们统计了截止到今年 7 月份欧盟 GDPR 执法的一些情况，1087 是处罚的案件总数，十六亿三千万是整体的处罚金额。七亿四千六百万是 GDPR 有史以来单个案件处罚最多的一个案例，涉及的是某个全球性的跨境电商。我们再看另一组数据，大家看到最后这个人民币的符号，已经猜到是我们国内的情况，国内这三个数字截止到 2022 年的 6 月份，从工信部发布的数据来看，我国对上架的 322 万款 APP 进行了检测，对其中 3000 多款应用进行了通报，甚至下架的处罚。那么最后这个 80 亿，大家应该很清楚，是最近我们国内某公司因为隐私安全的问题，受到的处罚金额。

从这个数字来看，某种程度上国内的处罚力度比欧盟的 GDPR 还要大一些，国内的上限是全球营业额的 5%，GDPR 是全球营业额的 4%。

分享完监管和国家法律法规的一些要求，再从消费者的角度聊一下这个事情。随着移动互联网的蓬勃发展，各种各样的 APP 在方便大家的同时也收集了大量个人信息，那么消费者怎么看待这件事情呢？

这是 Veritas 的一份全球消费者数据隐私洞察报告，这里面有几个数字，全球 62% 的人、中国 55.7% 的人认为如果一家企业不能妥善保护用户的个人隐私数据，那他们将停止购买这家公司的产品。全球 48% 的人、国内 63.8% 的人甚至会转而购买竞争对手的产品。比较好的情况是有 59% 的全球消费者，愿意加大消费购买对个人隐私数据保护更加完善的企业类产品，甚至有 27% 的人愿意增加 25% 的消费投入。

所以说无论是从监管的角度，还是从消费者的角度，隐私安全都是公司产品的一项核心竞争力，如果隐私安全做不好，可能导致销售也做不好，如果隐私安全做的好，这可能会成为整个产品的一个卖点。

应对风险的思路总览

接下来讲一下我们整体应对风险的思路大概是什么样的。我们一直在说隐私安全，但是隐私安全到底是什么？现在也没有看到一个特别完善的定义，我尝试从我的理解定义一下到底什么是隐私安全。

首先什么是隐私？有一个比较简单的定义，即不愿意公开的信息叫做隐私，那有了隐私之后，作为人就有隐私权，隐私权是什么？这是我从维基百科上查到的比较专业的定义，即个人或者群体隔离自己，或与自己有关信息的权利。

隐私安全就是负责任地使用用户的数据，并且根据用户的要求，避免数据落入坏人之手，这样的一个动作。我们通过制度、技术、产品等各种方式达成保护用户隐私安全的目的，叫做隐私保护。隐私安全面临很多风险，刚才我们提到了监管，监管是底线的要求，如果做不到，那企业可能将承受巨大的处罚压力。

接下来还有黑客攻击。黑客也会觊觎用户的一些数据，因为这些数据能带来很大的价值。大家有没有遇到过这样的现象，当你在网上买了一个东西后，突然有人打电话给你说要退货，还要你再寄点钱给他，然后会返还你一些好处，这就是一种诈骗。那么黑客是怎么得到这些数据的呢？有很大的概率是通过攻击拿到了一些订单数据和消费者的信息，如果说某家公司对用户的隐私完全不注意，那消费者对它的产品肯定是没有信心的，对这家公司的价值也会存在置疑。

隐私安全有很多的建设阶段，这边大概说一下，后面我们会详细展开。比如最基础的是满足法律法规的要求和技术的合规。接下来会去做比如认证和相关体系的建设，自证合规向消费者传达做安全隐私的意愿和能力，最后是能够让用户感知到你有很多产品或功能来保护用户的隐私，比如说 OPPO 的密码本，你可以放心的将你各个网站的密码保存到里面，并且这个密码只能由你自己解开，OPPO 的云端是没办法解开的。

我们再谈一下怎么做，整体的思路不复杂。比如最早可能有很多外部标准的要求，包括法律、行业、实践的，需要把这些转化成我们内部的准则。我们的研发人员或者产品经理很难对法律条款非常熟悉，所以需要我们安全人员把它转换成产品经理和研发人员能够理解的东西，这就形成了内部的准则、要求及规范。那么这些东西怎么落地呢？光知道是不行的，如何通过流程、工具、审计来确保我们相关的标准要求落实到产品里面，是我们接下来要做的事情。

因为隐私相关的法律法规更多的是规范一些比较粗粒度的要求，可能导致每个人对同一个法律条款，或者同一个要求的理解是不一样的，这个时候我们应该尽量修正我们的理解，和监管部门的理解保持一致，需要通过一些外部验证去检验我们的这个事情是不是真的做对了。比如可以主动跟一些实验室合作，国外会比较多，比如像欧盟，可能会有很多独立的安全实验室，会给你做一些相关的认证，去切合当地一些法律法规的要求，并提出一些针对性的意见。同时你也可以主动去做一些送检。另外就是事件了，无论是外部爆出来的事件，还是我们自己被监管通告的事件，都可以作为我们验证自己的标准是否已经符合监管要求的标尺，它是一个循环的东西。

讲了宏观上的一些事情，再讲一下具体的细分，我们从 2018 年到现在大概是怎么做的，首先我们要明确一个原则，就是我们到底应该怎么处理用户的数据，怎么保护用户的隐私，这个原则是要我们安全跟产品都达成一致的，大家要形成共识的。我们这个原则是在做很多内部标准落地的时候，能提供指引性的。

接下来就是把我们的原则形成内部的一些技术规范，这个时候它可能就更细化了，比如说数据的分级分类是什么样的？安全的开发规范是什么样的？加解密的标准是什么样的？数据的整个生命周期是怎么做的？数据脱敏应该怎么去做？这些就会相对细化，同时这个地方离不开基础防御系统的建设，因为刚才我们也说到了，隐私面临着三部分问题，一个是监管，一个是黑客攻击，还有一个是消费者。当黑客攻击我们时，需要有基础的通用的安全防护能力，比如说防火墙、WAF、主机入侵防御检测系统等。

有了标准和技术之后，我们可能已经解决了 10% 到 20% 的问题，把它真正落实到我们的产品里面去，才是最重要的一环。比如，我们会在数据的生命保护周期内的每一环都落地相应的检测标准，然后同时把我们的要求，我们的工具去落实到整个研发的生命周期里面来，在需求、设计、开发、测试，发布等阶段都有相应的安全要求。

在一个企业里面，技术可能能够解决 30% 的问题，制度可能能够解决 70% 的问题，我指的制度就是组织要去支撑你做这件事，如果大家都不认可，没有人投入，那这个事情就很难落地，我们是建立了从上到下的三道防线组织，融合了安全部门和业务部门，最终我们希望达到的目的是整个公司都形成一种理念，即发自内心的尊重用户的隐私安全，而不仅仅是因为法律的约束，当然这是我们正在进行中的事情。

OPPO 隐私安全建设实践

接下来步入正题，讲一下我们到底是怎么做的。我先抛出一个问题：你认为建设隐私安全最重要的事情是什么？或者决定我们关键成败的事情是什么？从技术角度上讲，答案是标准的引入，为什么呢？如果标准没有解释的很清晰，研发人员就不知道该怎么落地，如果你的标准跟国家的要求产生了非常大的偏差，我们做完的产品也会有很大的偏差。所以说标准的引入是非常重要的一环。

那我们大概怎么去做呢？整体思路是首先投入人力把外部标准转化成内部语言，也就是内部的产品经理和研发人员能够理解的内部标准，标准细化之后还要有一个检测的标准，就是我们要去验证我们的产品到底是不是满足了这个标准。外部标准有这么几个来源，第一个是法律法规，法律法规规定的比较粗线条；第二个是行业标准，这个就非常重要了，很多技术机构会发布很多行标，行标里面会有非常细粒度的一些技术规范，所以说这对转化成内部的可执行的标准是非常重要的一点。

接下来就会有一些合作方的要求，还有一些业界的实践、通报案例等。内部的标准我们已经讲了很多了，包括数据方面的和权限方面的，还有研发人员可以自己去评估的一些准则，最后是一些检验标准，可能会包含比如设计规范、开发规范以及最后测试的检测项目，这就是 OPPO 现在主要参考的一些外部标准的来源，比如国内会有个人信息保护法，欧盟会有 GDPR，各个不同的业务开展的国家也会有具体的相应的法律法规。

行业标准是要花很大精力去解读的，它也是从法律到技术转化的中间态，这些大家也可以去关注。另外还会有很多合作方的要求，比如我们可能是基于谷歌系统、谷歌生态的，会有谷歌的一些 MBA 的要求，我们也会有 iOS 的 APP 上架，也要遵循 Apple 的一些要求，甚至跟运营商的合作也会有相应的要求。最终通报案例是大家学习中非常重要的一环，我们这边大概列出来国内处罚的套路，以及欧盟 GDPR 处罚的套路，这些就是监管重点关注的，我们需要重点去解读和转化的。

简单给大家举一个小例子，讲一下我们从外部转到内部到底要转化成什么样子，才是我们觉得做到位的标准。比如我拿到了一个工信部 164 号文件一条要求，它的要求标题是 APP 强制频繁过度索取权限，这个就很宽泛，它会有一些简单的描述，比如重点整治软件安装运行使用的过程中，在用户没有明确拒绝之后频繁弹窗等行为的要求。但这样直接给开发人员看，他还是不理解，因为没有站在他的场景里去做更多细节的描述，这时候就需要转化成研发内部能理解的语言，也就是场景化。比如我们会在启动阶段打开注册登录运行，然后用户明确拒绝之后，每一点都要做到什么？怎么去做？要描述的非常非常详细。

还有就是我们说到的检测标准，像刚才那样转化成内部开发人员能够理解的东西之后，就真的能够落地了吗？或者说研发人员能理解吗？还是说只有产品经理能理解？可能更多的是产品经理能够理解，但研发人员还不知道他自己要做什么。那我们就需要再做一个内部标准，更加细化的转化成一个研发人员能理解的语言，我这边拿一条我们内部的标准条款举例，即 APP 向用户明示收集个人信息的频次，超出其实现产品或者服务的业务功能所必须的最低频次，这个开发能理解吗？什么叫个人信息？最低频次怎么定义？怎么去计数频次？这些可能都是我们需要去细化的东西，比如个人信息，我们就要非常明确的表达，如 IMEI、设备的 MAC 地址、用户的定位信息等，这样描述开发人员就理解了。

接下来怎么去定义频繁？比如是用户非主动触发的，软件自动触发了，这就叫频繁，周期性读取的情况下，导航超过每秒一次，这个叫频繁，非常清晰地定义给开发看就行了。还有一个问题就是如何计数，比如说超过一次，这个一次怎么算？尤其是对于地理位置来说，有经度和纬度，经度获取一次算一次，还是说经纬度同时获取一次算一次？这些非常细化的场景都是需要我们投入人力去解读的，解读完之后还要转化成研发人员能理解的语言。

比如获取定位信息研发，某个研发人员可能只知道某一个 API，另外一个研发人员可能用其它的 API，那我们如何保证整个的全面性？这个是需要更多的技术专家参与进来的。大家以为这样就完了吗？这里面还会有很多坑，我这边随便讲一个，就是系统的差异。

我们在上图里已经给出获取 Wi-Fi 的 API 了。我们这段是获取 Wi-Fi 的代码，我们突然在某一天发现了一件事情，这个行为被某些系统认定为获取地理位置信息，我们完全不知道为什么，检测报告出来之后我们也不清楚，上面只是说超范围获取了用户的信息，具体什么信息我们不知道，我们认为是获取了 Wi-Fi，但 Wi-Fi 不是敏感信息，但最终交流之后才发现这是一个地理位置的信息。

这就需要我们有非常强大的技术团队去做分析了，它是一个系统的特性，从安卓 10 开始 APP 必须要有获取位置的权限才能使用 Wi-Fi Manager 里面的一些的类，才能获取 Wi-Fi 名称， Google 自己也意识到这不是一个非常好的解决办法，所以在安卓 13 的时候做了改进，单独把权限做了拆分。所以说标准解读可能没有我们想象的那么容易，从外部标准转换到内部标准，从内部标准再转换到研发标准，这甚至不是一个团队能够解决的，需要法务同事、数据安全的同事和安全攻防专家一起紧密配合，才能把整体的标准分析的比较清楚。

有了标准之后，我们要把这些标准落实到整个研发流程里面，那么从研发最开头的阶段说起，就是需求，如果在需求阶段没有让开发人员很好的注意到标准的变化以及标准要求，开发完成之后再返工的成本是非常大的，所以我们在需求阶段就很早的去介入了安全隐私的一些事情。

这个是我们做的一个安全隐私合规的评审的系统，是人工加半自动化的，它基于 STRIDEP 做场景化的位阶建模，然后能够实现半自动化的安全隐私需求评审，当然这是最终的结果，是我们现在运用的结果，它并不是一开始就是这样一个系统。

我们为什么会形成这样一个系统呢？有两方面的考虑，最早我们的隐私评审阶段都是人工介入的，人工介入有好处也有坏处，首先好处是可以把场景分析的非常清楚，坏处是会助长业务的依赖性，业务会认为这个需求评审是安全团队的事情，业务只要提出需求，具体的解决方案安全团队可以提供。另外一个是效率问题。基于这两点考虑，我们慢慢演化出这样一个系统，针对业务我们会有一个场景库，对于一些简单的场景，我们会通过专家把这个场景面临的安全的风险都列出来，如果业务方命中了这个场景，只需要按照我们的相关要求去做相应的动作就可以了。这样做的好处是业务方会有更强的参与感，会知道这个要求是什么样，下次自己去设计的时候自然就带上了。另外就是效率的提升。我们已经覆盖了大量的场景，业务方完全可以自助式的搞定这个事情。

在最早期的建设阶段，我们认为检测也是非常重要的，因为测试有很多工作都是依赖于人的，系统可能也是半自动化的，不能够保证百分之百，那怎样去检测业务方真实的做了相应的需求评审和开发呢，这就需要通过检测去做一些验证。刚才举了一个例子，比如频繁调用以及个人数据，那什么样的检测系统能检测出这样的问题呢？首先看你申请了什么权限，用了什么数据，通过代码扫描很简单就能看出你有没有用这个 API，所以我们首先建立了一个静态扫描系统，集合了隐私合规、安全漏洞扫描、安全编码规范以及 SDK 检测这几个功能。

回到频繁调用的问题，我们知道代码里有能力这样去调用，但是代码不能输出频次，我们又针对这个问题做了一套动态扫描系统，它运行在一个沙箱里，每一次调用了什么东西，大概什么时间调用的，一段时间内的调用频次都可以统计出来。我们这个系统集合了动态行为检测、个人信息分析，甚至云真机的功能，业务方只需要自己去操作，做一遍功能测试，一些隐私的检测项就自动出结果了，同时我们也可以做一些自动化的点击触发，结合整个静态和动态的扫描系统，然后再加上一些人工检测，就能覆盖我们隐私合规的大部分检测项。

这个是我们更全面的一些融入研发流程的建设，我们在培训、需求、架构设计、编码、测试、发布、上线，每个阶段都建立了比较多的能力，我们刚才讲的是我们建设能力的大概过程，我们先建设了隐私的评审和测试的检测能力，然后接下来才是其它的一些扩充，比如我们除了安卓系统的检测之外，还做了 iOS 的动态和静态的检测，以及快应用的检测。

有了这些东西之后，只能说明你具备这样的能力，但是想要让业务方完全遵守这样的规则，我们需要建立一套安全的上线流程。

流程大概是这样的：在产品需求阶段，是一定要做安全隐私合规的评审的。产品研发阶段我们会有相应的一些隐私扫描，同时我们会有一些安全的 SDK 提供给业务方使用，比如数据脱敏，业务方可能不知道数据脱敏怎么做，或者说很多业务方都要做自己的数据脱敏，这可能是一个重复的建设，现在安全方提供了这样一些能力，业务方只要直接接入使用就能保证数据是没有太多敏感的问题的。

在功能测试阶段，我们会有一些动态的隐私扫描和安全隐私的扫描，在上线之前，也就是功能测试完成之后，会根据业务的情况开展一些人工检测，以及制品的自动化扫描，在这个阶段一定要保证之前的需求评审通过了，整个业务上线之前要做门禁的检查，就是之前的这些安全环节有没有做？有没有达标？只有达标了之后才能发布到线上，发布到线上之后还需要做一些持续的监控分析。我们做了一些监控分析相关的系统，比如安全做了态势感知，实时扫描一些在线业务，然后也会通过一些情报去看业务有没有遭到攻击，数据隐私这块儿我们建立了一个数据治理平台，能够看到数据的使用和数据的流动情况，一旦发现不合规的问题就会及时整改。

所有流程制定完成之后，怎么样有力的执行？这就在于组织的建设。在 OPPO 把安全提到一个比较高的位置上来，所以我们建立了一个自上而下的安全组织，首先由系统高管担任我们的隐私安全委员会主任，这个委员会是系统公司级的。

接下来就到了每个部门，每个部门的部长要对自己部门的安全隐私负最终责任，当然他可以指定相应的人员去开展具体的工作，我们叫安全隐私合规代表，他会去拉通整个业务部门内部的研发安全落地流程。

对于安全团队，我们针对每个业务，会有相应的一个安全隐私接口人，这个接口人会拉通整个安全能力，比如我们安全团队后面有评审团队、测试团队、产品研发团队、智能风控团队和应急团队，安全隐私代表和安全隐私接口人会紧密合作，当然这个事情是需要持续运营，我们也会通过定期审计去确保一些关键策略是落地的。

我们之前讲的更多的是怎样应对监管，黑客攻击也是非常重要的一环，为了应对黑客攻击我们做了云安全的整个防御体系。首先我们从用户的请求出发，在端侧做了移动安全的一些加固和移动安全的 SDK，确保我们的端侧破解保护是有一定强度的。

接下来就到了网络层，网络层我们有动态防火墙，能够限定网络区域的访问划分，我们有 OPPO 的鹰眼系统，能够监测到整个网络流量的情况，以及里面是不是有敏感信息，是不是有黑客攻击的一些蛛丝马迹。

接下来到了接入层，接入层是 OPPO 整个后端业务整体的接入点，在这里我们会做一些攻击防御，比如像传统的 Web 攻击，SQL 注入、命令执行等，我们通过 OPPO 的云盾，也就是一个 WAF 去做整体的防御，然后通过 CC 防御去做 DOS 防御。

在业务层，我们也提供一些能力给业务方，比如鉴权能力，确保只有正确的人才能够访问正确的数据。我们针对黑产有一些风控防御系统，我们叫做 OPPO 天御系统，它会实时检测是不是有黑产的攻击，会不会有薅羊毛的风险，同时对它去做相应的调整和处罚。

在主机层我们有 OPPO 谛听这样的一些防御系统，对系统上线的容器、镜像等进行扫描，确保如果有入侵行为发生，我们能够及时发现。

在数据层我们提供了安全密钥和数据脱敏这样的服务，一些产品支撑了公司的线上业务，比如像一些端到端的加密的技术，只有用户自已才能解密相关的数据，连 OPPO 都无法在云端解密这些数据。

除了自建的体系之外，我们还想通过业界的一些能力补齐短板，我们建立了 OPPO 安全应急响应中心，利用白帽子的力量来增强安全隐私的能力，OSRC 除了接收传统的安全漏洞之外，还新增了一些隐私漏洞的接收范围。从现在的效果来看还是不错的，能够帮助我们补齐很多短板，优化了我们对标准的理解。

当然所有的这些成长，离不开我们自己能力的持续提升，我们要有能力保证满足业务的安全需求，我们会通过几个方向持续提升能力。首先我们会跟业界，比如安全公司成立联合实验室，跟一些产学研的高校共同探索新兴的安全隐私的领域和保护技术，同时我们自己也会持续投入到一些安全攻防技术的研究里来，并且把我们的心得和想法通过公开演讲的方式同业界交流，此前我们在 Black Hat Europe 和 Black Hat Asia 上面做了公开演讲。我们在学术领域也会发一些 Paper，比如在 DMV 上发布安卓安全的文章。

我们到底做的好不好？业界的一些认证可能是我们的一些试金石，为了验证我们自己的能力，我们在全球各地引入了一些主要的认证机构去做相应的评估，比如说在欧盟我们做了 TrustArc 和 ePrivacy，在 ISO 我们做了 27701 等等，当然这只是为了检验我们的工作效果。

总结与展望

我给隐私安全建设做了能力的分级，大概分为五个阶段：

• 第一阶段是满足法律约束，这是底线性的东西，任何一家公司开展业务都要满足这一级；

• 第二阶段是主动合规，此时公司会组建专业安全团队，主动满足监管的要求；

• 第三阶段是自证合规，此阶段安全团队会跟业界一些实验室和标准认证机构合作，取得安全隐私认证，检验建设效果；

• 第四个阶段我称作安全感知，除了做好产品安全性这件事以外，还要通过安全隐私特性（安全产品或功能）让消费者有更强的感知，让消费者认可你的产品是安全的，是能保护用户隐私的，这点非常重要，我们认为这是安全隐私工作做到比较好的一个高级阶段；

• 最后就是保证持续处于业界第一梯队，做业界的标杆，这是非常难的，也是我们所追求的终极目标。

这就是我今天分享的所有内容，谢谢大家。

相关阅读:

关于 GDPR 体系文件介绍，介绍 GDPR 体系文件的内容和意义

“史上最严”数据保护法 GDPR 是如何失败的？

面向软件开发者的“GDPR 指南”

所有 AWS 服务 GDPR 已准备就绪