数据安全与隐私保护的统一

这是一篇关于数据安全与隐私保护的统一的思维导图，主要内容包括：数据安全架构与治理总结，数据安全治理能力成熟度模型（DSGMM），统一的数据安全生命周期管理，以数据为中心的统一治理。

数据安全与隐私保护的统一

• 以数据为中心的统一治理
  • 个人数据安全相对于传统的安全治理实践，更加关注以数据为中心，强调合规性证明的问题（即向监管机构证明自身的合规性）。为了达成这个目的，我们需要借助数据目录、数据流图等工具，展示个人数据管理的现状，以及数据流转的合规过程记录（比如数据传输协议的签署等）。通用的数据安全，也可以采取此做法，熟悉自己的家底，做到心中有数，在向上汇报工作时，可以用数字来描述合规现状（比如达标的百分比）。
  • 统一的数据安全治理
    • 以数据为中心，可以把数据安全与隐私保护治理统一起来，包括战略、组织、政策的统一设置，如图所示。
    • 战略上，将“从源头开始保障个人数据全生命周期的安全”、“防止个人数据泄露”明确写入企业的安全战略。
    • 组织上，数据安全的相关组织，同时将隐私保护的相关职责承接起来。负责数据安全治理的组织，通常由第二道防线中的合规与风险管理团队以及相应的指导委员会承担，治理层面的交付（战略、组织、政策等），在高级别的风险管理委员会决策后作为治理的依据。
    • 政策总纲上，纳入对个人数据的合规原则，可以选定某个业界最佳实践框架作为内部治理的参考，比如PCI-DSS、GAPP等。
    • 在合规与风险管理方面，可对各种类型的数据统一分级分类，将隐私相关的法律法规通过前面介绍的方法，转化为内部政策要求，在文件体系层面进行整合，如图所示。
  • 统一数据目录与数据流图
    • 数据目录（Data Inventory, DI），即数据集的清单，是将各数据集的元数据（Meta Data）统一管理起来，可用于数据流转决策、合规性证明等用途。元数据，就是描述数据的数据。如数据的管理责任人（或数据Owner）、数据的存储位置、对每个字段的描述、每个字段的数据分级分类标识等。图是数据目录的示例。
    • 数据流图，即数据流转关系图，表示数据的消费流向，可用于追踪数据的扩散范围。图是网上商城购物场景下的数据流图。
  • 统一数据服务
    • 使用API网关，将数据IO统一管理起来，统一执行身份认证、访问控制措施，统一管理数据消费。在这种情况下，可以做到以数据为中心，数据即服务，将数据作为生产力或生产资料，更好地服务于各业务的需要。
    • 按照本书第三部分所述，在API网关，可以统一实施身份认证、授权、访问控制、脱敏等安全机制。在API网关统一配置脱敏消费规则，让流出的敏感数据自动按照设定的规则脱敏后提供给消费方，防止敏感数据泄露，如图所示。
• 统一的数据安全生命周期管理
  • 数据面临的各种安全风险，究其根本原因，来自内部的各种不安全因素所占的比例越来越高，成为数据泄露的首要威胁。一些典型的场景包括：
    • ■ 数据共享给其他业务，结果其他业务疏于采取安全措施，导致数据泄露。
    • ■ 敏感数据展示时没有采取脱敏措施。
  • 数据安全生命周期管理，是从数据的安全收集或生成开始，覆盖数据的安全使用、安全传输、安全存储、安全披露、安全流转与跟踪，直到安全销毁为止的全过程安全保障机制。参考法律合规的要求，我们把隐私生命周期划分为如下几个阶段：
    • ■ 告知数据主体（隐私声明或通知）。
    • ■ 数据主体选择和同意。
    • ■ 数据收集或生成。
    • ■ 数据传输。
    • ■ 数据存储与留存期管理。
    • ■ 数据使用。
    • ■ 数据流转与出境。
    • ■ 数据披露。
    • ■ 数据销毁。
  • 此外，还包括全生命周期的数据主体权利保障，如图所示。
  • 数据安全生命周期
    • 1．告知数据主体
      • 应从数据收集开始，就明确所收集数据的用途、使用的业务和产品范围、保护措施等，避免收集不必要的用户数据。为了保障数据主体的知情权，以及符合法律法规的透明性要求，需要将我们的隐私政策告知数据主体。
      • 以最常见的网站在线服务为例，数据直接从数据主体处收集，通常需要在网站的每个页面的固定位置（比如最下方）放置一个名为“隐私声明”、“隐私政策”的超链接。
      • 也许你会说，我们的网站不在欧洲，也不收集欧洲用户的个人数据，难道也会受影响？
      • 答案是：会有影响。互联网是开放的，谁都可以公开访问，自然也能够被欧洲用户访问到。隐私法律法规，也不是只有GDPR，世界上很多国家都制定了隐私相关的法律，或在行业立法中包含了隐私保护的条款。
      • 而且，就算网站不需要登录，也不能保障“没有收集欧洲用户的个人数据”，事实上，以下几个常见的信息已经属于GDPR认定的个人数据了：
        • ■ Cookie。
        • ■ IP地址（没错，IP地址也是GDPR认定的个人数据，因为他们认为IP可用于定位到具体的自然人）。
      • 也就是说，只要你的网站使用到Cookie，或者记录用户的IP地址，就已经是在处理个人数据了。可见，在不需要用户登录的情况下，只有不使用任何Cookie、不记录用户IP地址的情况下，才可以不受GDPR的影响。
      • 难道要把欧洲排除掉？这不是一个好办法。如果你提供的网站不面向欧洲用户（如何理解“面向”，可参考17.2.1节），比如语言不是欧洲的语言文字（如使用韩文、日文、中文等），那可以视为目标受众不包括欧洲用户，不受GDPR影响。但是越来越多的国家和地区制定了跟GDPR类似的法律，因此，按照业界的最佳实践或合规的方式处理，才是正确的方式。
      • 针对只使用Cookie的网站，典型的做法是在用户首次访问网站时，提醒用户该网站使用了Cookie。
      • 如果收集用户的个人数据（含IP地址），那么就需要提供隐私声明了，并且隐私声明里面需要包括必要的信息。
    • 2．数据主体选择和同意
      • 前面提到，处理个人数据，至少需要具备六个法律依据中的一个。这六个依据是用户同意、合同义务、法定义务、数据主体或他人的核心利益、公共利益、数据控制者及第三方的合法利益。
      • 这六个法律依据中：
        • ■ 合同义务、法定义务、数据主体或他人的核心利益、公共利益这四个依据使用的场景非常有限，不具有普适性。
        • ■ 合法利益争议最大、投诉最多，需要尽量避开。
      • 因此，实践中最常用、最重要的一个法律依据是用户同意。
      • 在可能对数据主体造成较大影响时，尤其需要征得数据主体的有效同意（或明示同意）。所谓有效同意，就是默认不能替用户勾选同意，需要用户主动勾选同意选项。
    • 3．数据的安全收集或生成
      • 用户同意后，应按照隐私声明告知的范围，最小化收集。
      • 对接收的数据，应确定其数据分级和分类。数据分级和分类决定了应该采取什么样的措施来保护它。
      • 为防止个人信息泄露，数据在收集后应采取适当的预处理，或降低隐私敏感性的措施，再上传到服务器，而没有必要传输原始的敏感信息。下面是一些典型的场景：
        • ■ 口令，可以先在用户侧执行慢速加盐散列操作，然后再上传。
        • ■ 生物特征，能在用户侧完成比对的，不上传特征值（生物识别图像是肯定不能上传的）。
        • ■ 浏览、输入记录等，可在抽样的基础上执行差分隐私处理，即添加噪声后再传输。
        • ■ 身高数字为例，应在用户侧采取差分隐私算法处理，添加噪声后再上传。
    • 4．数据的安全传输
      • 传输信息应使用HTTPS或其他加密通道。在外网传输，毫无疑问，应该启用加密传输机制，首选HTTPS加密传输机制。推荐采用统一的接入网关，统一管理证书私钥，统一启用HTTPS。在内网，可考虑RPC加密传输、HTTPS等机制，加密传输敏感数据。
    • 5．数据的安全存储与留存期管理
      • 前面提到，针对以下这几类数据应当采取加密存储措施：
        • ■ 口令、密钥，包括数据库、配置文件中的口令和密钥。
        • ■ 敏感的个人隐私数据。
        • ■ 敏感的UGC数据。
      • 至于业务数据，则需要权衡，特别是涉及检索、排序、求和计算等场景。
      • 在客户端场景，比如移动APP，一些敏感的数据，如个人信息、UGC数据等，有的APP过于信赖移动设备所提供的沙盒机制，直接明文存储在本地，但是这种沙盒机制所能提供的保障是有限的，一般设备被越狱（让用户获取root权限），这些数据可能就泄露了。
      • 在留存期方面，主要涉及两类数据。其中，数据主体的身份类数据通常是收集一次后，如无更正需求，则存储较长的时间，直至产品下线或用户销户，删除相应的数据。还有一类数据，是在注册后的活动过程中生成的，比如支付/消费记录、运动记录等，这些记录也是个人数据，相应记录的生成日期可用于留存期管理，作为计算留存期的起始日期。
    • 6．数据的安全使用
      • 在数据使用、留存、存储的过程中，需要采取必要的安全控制措施，来保障个人数据的安全，这个部分，通常被称为“在设计过程中构建安全与隐私保护能力”（Privacy by Design，简写为PbD），内容可包括安全架构的5个要素：
        • ■ 身份认证，确认敏感数据接口具备身份认证机制，防止“任何人都可以访问和遍历查询”的情况。
        • ■ 授权，比如除了用户自己，授权其好友查看其朋友圈信息。
        • ■ 访问控制，比如防止“数据库直接对外开放或存在弱口令”。
        • ■ 可审计。
        • ■ 资产安全，比如存储加密、数据脱敏以防止敏感数据泄露。
      • 在留存期管理上，对于支付/消费记录、运动记录等数据，应按设定的留存期，到期自动删除或删除对应的加密密钥。对于身份相关的数据，在产品下线或用户注销后，如无法律要求，应立即删除。
      • 为了满足法律合规要求（典型场景如财务审计），设定的留存期不能小于适用法律规定的留存时长。设定的留存期到期之后，应予以删除。
      • 按照“基于身份的信任原则”，访问数据需要基于身份执行授权、访问控制、审计机制。
      • 此外，数据在展示或对外披露时，需要防止个人隐私泄露。
        • 1）数据的展示。
          • 有的数据是不能展示的，比如口令、用于身份识别的生物特征等；就算需要展示指纹认证效果，也只能用一个事先数字化生成的、跟任何真实个人无关的指纹。
          • 有的数据是需要脱敏后才能展示，如姓名、手机号码、地址、银行卡号等，如将银行卡号展示为：**** **** **** 1234。
          • 需要展示敏感个人信息的业务场景，则要增加操作或频率限制、总量限制，如一次只能查询一条记录，且需要记录日志。
        • 2）数据对外披露。
          • 很多公司每年都会发布一些基于大数据的各种分析报告，如互联网用户分析报告、医疗/疾控报告、安全报告等，或者将数据处理后提供给其他单位进行研究。
          • 这些数据对外披露前，应当采取严格的脱敏、去标识化措施，例如K -匿名（参见第18章）、提供统计查询接口时采用差分隐私保护措施（参见第18章），防止定位到任何真实的自然人，或怀疑为某个自然人的数据。
          • 数据披露给数据处理者（通常是执法数据处理的供应商）之前，应进行尽职调查及签署DPA（数据处理协议），确保数据处理者能够提供充分的数据安全保证。
    • 7．数据流转与出境
      • 一些典型的风险场景：
        • ■ 数据共享给其他业务，结果其他业务疏于采取安全措施，导致数据泄露。
        • ■ 数据出境，未履行必要的义务，导致法律合规冲突。
      • 为了强化对数据的管理，需要为数据设置数据安全责任人，由业务的管理层担任，称之为数据Owner（即数据所有者），负责数据流转的审批、权限授予与权限回收决策等事宜。如果数据需要在一个企业内部不同的业务间流转，不涉及出境的话，除了需要在隐私声明里面包含新的用途之外，还需要经过数据Owner的审批。
      • 通常来说，某业务收集的数据并不是完全仅限于在该业务范围内使用，往往还有其他业务需要使用的场景，比如客户服务人员在提供服务的时候，需要核实用户身份，需要访问业务系统中用户的资料用于确认用户身份。有的场景虽然是在业务范围内流转，但查询或使用数据的人员太多，容易失控，比如快递员在送货的时候，需要知道收件人的手机号码、地址等信息。
      • 关于批量数据出境，很多国家都有限制数据出境的法律法规。以GDPR为例，数据可以在欧洲经济区内自由流动，但流出欧洲经济区，需要具备如下条件之一：
        • ■ 目的地国家是被欧盟认可的具有充分保护水平的国家，如瑞士（不在欧洲经济区）、阿根廷、加拿大（商业组织）、以色列、日本、新西兰、乌拉圭，以及美国（仅限于已加入隐私盾协议框架的企业）等。
        • ■ 跨国企业申请加入BCR框架（Binding Corporate Rules，约束性企业规则）, BCR是由欧盟委员会制定，适用于跨国企业在组织内部对个人数据进行跨境转移，但需要经过申请和严格的审批程序（所需时间较长）。
        • ■ 在数据发送方和接收方签署欧盟认可的标准数据传输协议（DTA），并遵守标准协议中的条款。
      • 如果是国内收集或生成的数据，默认应在境内存储。如果要向境外转移，需要经过严格的评估，并咨询企业法务部门的意见。
      • 如果是手机APP等直接涉及个人数据出境的场景，至少应征得用户的明示同意。明示同意包括在隐私声明中主动明确地告知、用户主动勾选同意。
    • 8．数据销毁
      • 当业务下线但系统存在敏感数据时，就需要考虑数据销毁措施了；此外，法律法规也授予用户拥有删除自己个人资料、账号的权利。
      • 为了确保数据真正做到安全意义上的销毁或不可用，难度还是相当高的，因为数据不仅仅出现在生产环境数据库中，也可能存在于过去的归档记录或备份磁带上，而找出磁带，删除对应的用户记录是基本上不可实现的。
      • 为了能够实现这一点，前面的标准也提到，应当加密存储用户敏感的个人信息/隐私、敏感的UGC内容等，当用户提出删除请求时，可通过删除对应记录的密钥的方式，让备份中的原始加密数据不再可用。
      • 针对退役下来的硬盘，一般需要通过低格（低级格式化）、消磁、物理折弯销毁等手段，而普通的删除只是标记为删除，文件内容并未被擦除掉，普通的格式化也达不到安全意义上销毁的目的，因为它只是创建了新的索引，将所有扇区标记为未使用的状态，如果使用数据恢复工具，还是可以恢复大部分数据的。
  • 全生命周期的数据主体权利保障
    • 前面提到，为了保障数据主体（用户、雇员、前雇员、求职者、商业联系人等）的权利，我们需要建立数据主体请求响应流程系统。简单的数据主体响应流程如图所示。
    • 在收到数据主体的请求之后，为其创建一个流程单，用于跟进。请求的类型跟数据主体的权利有关。前面已介绍过数据主体的权利包括：知情权、访问权、更正权、删除权、限制处理权、可移植权、反对权。其中知情权主要通过隐私声明告知用户，而其他几项权利，就需要通过数据主体请求来解决了。
    • 接下来，就是验证数据主体的身份。如果已经为数据主体建立了自助式的个人后台管理系统，那么用户登录个人后台的时候已经通过了身份认证。如果尚未建立自助后台，而是通过简单的表单来收集数据主体请求，身份的确认就相当重要，应防止恶意的数据主体请求，如代替他人提出销户请求，如果不加区分地一律响应，就有可能误删。
    • 在身份确认之后，需要评估其请求是否有效。数据主体虽然有权提出请求，但并不是每一个请求都是合理的。一个典型的场景是，为了满足法定义务而采取的数据处理，比如实名制登记，如果用户希望在保持账号正常使用的条件下删除实名制信息，那么这个请求就跟法定义务冲突了，不能被满足，除非是用户提出了销户的请求。
    • 如果请求合理合法，就需要根据用户的请求采取处置措施，这一动作在初期可以采取人工方法，但随着请求数量的增多，人工成本会越来越高，就需要考虑建设自动化接口，自动完成相应的操作。
    • 为了考核数据主体请求响应团队的绩效，可设定SLA（服务水平协议）指标，从及时完成率、用户满意度等维度，为团队进行打分。
    • 数据主体请求处置完成，无论是正常响应还是请求不合理被驳回，都需要通知到数据主体。在通知环节，需要设置标准化的回复模板，避免将个人化的、情绪化的词语带入回复中，维护公司形象。
  • 典型案例
    • 案例1：隐私声明包含的内容
      • 不提供个人信息可能导致的问题或后果
      • 收集的个人信息种类
      • 使用个人信息的目的
      • 向第三方披露的情况
      • 自动决策的存在性说明
      • 如何访问个人信息的副本，以及修改、删除个人数据
      • 儿童个人数据
      • 告知用户投诉的权利及渠道
      • 注意
        • 如果数据不是直接从数据主体处获取，例如是通过采购的方式获取的，则需要对数据供应商执行尽职调查，确保供应商在收集数据前已履行通知义务，数据主体是知情并同意的。如果供应商无法保障这一点，则需要通知到每一位数据主体（如电子邮件），直接使用可能涉嫌违法，可招致投诉或法律诉讼。
    • 案例2：招聘
      • 假设某国内企业最近拓展海外业务，需要招聘一些国际化的员工，但面试官都在国内。这时需要注意什么呢？
      • 最典型的渠道，就是通过企业自己的对外招聘系统发布招聘信息。如果这个系统之前没有用于海外招聘，则需要审视招聘系统的隐私政策了。因为涉及处理欧洲公司的个人数据，则必须要提供隐私声明，保障数据主体的知情权。隐私声明中应包括：
        • ■ 数据控制者及法定代表人、数据保护官（DPO）的身份、联系方式。
        • ■ 收集数据的用途、必要性、合法性说明（该场景中仅用于面试）。
        • ■ 数据是否向第三者或第三国转移、接收者是谁（在这个场景中，涉及简历向国内转移，因此需要事先声明并需要获得求职者的明确同意）。
        • ■ 存储期限或标准（如果未能入职，则多长时间后会彻底删除其简历等个人数据）。
        • ■ 保护措施（比如简历只在IT系统中存储，不下载到个人电脑）。
        • ■ 声明数据主体有权访问、更正、删除个人数据，以及限制、拒绝、撤销同意、向监管机构投诉等权利。
        • 有求职者投递简历之后，公司将成为数据控制者，需要履行数据控制者的义务，对数据泄露承担责任。
      • 当未采用IT化系统而是面试官自行留存简历时，就很可能会出现跟隐私声明不一致的情况，比如留存期超过承诺的时间、感染木马导致数据泄露等。如果面试官的笔记本电脑丢失，且存有欧洲公民的简历文件时，按照GDPR的规定，需要在发现丢失后的72小时内向监管机构报告；如果数据可能会给候选人带来高风险（如资金损失），还需要通知到候选人本人。
    • 案例3:Cookie合规
      • 我们经常发现，刚刚才在某购物网站浏览过某件商品（手机、笔记本电脑、化妆品等等），很快就在浏览其他网页的时候，看到了同款产品的广告，甚至就连具体的型号、款式都是一模一样的！是谁监视了我们的浏览记录？
      • 其中发挥关键作用的，就是平常看起来非常不起眼的Cookie。如同它的英文含义“饼干”, Cookie是在浏览器里缓存的一小块“饼干”（数据），用于在浏览器和服务器之间记住一些小秘密，例如身份、会话与登录状态、个性化设置等。
      • 在互联网时代，发展出很多基于Cookie跟踪分析的业务模式，最为典型的就是网站分析、广告营销等场景。以某厂商的Analytics（分析）插件为例，当用户浏览了嵌入该Analytics插件的网页，用户的浏览器会自动向Analytics厂商发送一个请求，这个请求包含用户访问的页面等信息，同时，Analytics使用了Cookie，为用户生成唯一ID，浏览器在向Analytics厂商发送请求时会自动带上这个ID，这样Analytics厂商就知道你访问了哪个页面。通过这种方式厂商就可以根据用户的历史访问记录，推送相应的广告。
      • 作为用户，如果你对上述收集数据的行为比较反感的话，可考虑使用浏览器插件拦截各种追踪分析，比如Google Analytics Opt-out Add-on（只适用于Google Analytics）、Ghostery（可拦截各种追踪器、分析器、广告）等。
      • 作为企业，如果对网站所使用的相关Cookie处理不当，可能面临来自欧洲用户的投诉或监管层面的处罚。那么，企业应该如何处理Cookie才算合规呢？让我们先来看看欧盟相关的法律要求。
      • 电子隐私条例（ePrivacy Regulation，简记为ePR）是欧盟正在立法过程中的一项旨在保护欧洲公民电子通信信息的隐私法案（当前最新草案为欧洲理事会2019年3月13日批准），但尚未确定最终生效日期。电子隐私条例的前身为2002年发布的电子隐私指令（ePrivacy Directive 2002/58/EC）并在2009年做了修订。所以，当前有效的版本为2009年版本。ePrivacy Regulation将来正式生效后，再以ePrivacy Regulation为准。
      • 按照ePrivacy指令的要求，以及WP29（第二十九条工作组，是由欧盟各成员国数据保护机构的代表所组成的顾问机构，现为欧洲数据保护委员会，European Data Protection Board，简写为EDPB）的指导建议，以下7类Cookie可以豁免，不需要获得用户的同意：
        • ■ 用于跟踪用户输入的相关Cookie，比如购物车里面的物品清单。
        • ■ 用于身份认证的Cookie，比如记住登录状态。
        • ■ 登录安全有关的Cookie，比如登录尝试次数。
        • ■ 多媒体播放器的会话Cookie，比如记住上次播放位置。
        • ■ 负载均衡会话Cookie，用于在一组连续会话中访问同一个负载均衡节点，防止IP变化等因素导致用户会话失效。
        • ■ 自定义UI有关的Cookie，比如界面语言、每页展示的记录条数等。
        • ■ 用于社交网络插件内容分享的Cookie。
      • 而对于其他功能的Cookie，则需要征得用户的同意，并提供退出选项，或者默认不勾选，提供用户主动选择的选项。
      • 如下三个典型的场景通常不被豁免，需要征得用户的同意：
        • ■ 社交插件的跟踪Cookie。
        • ■ 第三方广告Cookie。
        • ■ 第一方分析Cookie
      • 这里涉及两个概念，第一方（First Party）Cookie和第三方（Third Party）Cookie。网上有很多误解，认为凡是涉及第三方网站在浏览器中设置Cookie的，就属于第三方Cookie。其实不然，以A网站嵌入Google Analytics分析为例，用户在浏览A网站的时候，浏览器会向Google Analytics服务器发送请求，并被Google Analytics设置Cookie，实际上，这个Cookie只能被Google Analytics使用，而A网站并不使用，不涉及跨域的问题，也不在数据控制者之间共享，Google是该Cookie数据的唯一控制者，因此应当被视为第一方Cookie。在Google Analytics的网站上，也明确表明Google Analytics使用的Cookie属于第一方Cookie。第三方Cookie是在线广告常使用的方式，通常涉及跨域Cookie操作，以DoubleClick广告为例，实际请求的域名跟写入Cookie的域名不同，用于跨站跟踪。
      • 你需要在用户首次访问时显示Cookie横幅，实施Cookie政策并允许用户提供同意。在同意之前，不能安装任何Cookie，上述豁免的Cookie除外。可以采用类似图的做法，在网页的上方或下方展示Cooke通知框（横幅），如果用户点击“接受”则关闭该通知框。
      • 如果用户想了解完整的Cookie策略，可以通过点击“更多信息”，跳转到隐私政策或单独的Cookie政策页面。如果用户打算修改设置，可点击“Cookie首选项”，进入下一菜单，如图所示。
      • 此时可以提供非基本Cookie的退出选项，或者将二者整合在一起，如图所示。
      • 注意 对于非基本功能的Cookie，到底是应该默认同意（即默认是勾选的，用户可退出），还是应该默认不同意（即默认是不勾选的），业界存在分歧。如果要求选择后同意，那么网站统计分析类的业务模式基本上没法持续了。鉴于ePrivacy Regulation尚未正式发布，有关Cookie的法律要求还存在一定的变数，需关注该条例的发布动态，在发布后审视并适当调整Cookie的处理方式。对于统计类插件，建议默认只开启最基本的统计功能，而不要开启增强功能，因为个性化营销/广告是需要用户明示同意的。
• 数据安全治理能力成熟度模型（DSGMM）
  • 数据安全治理经过一段时间的运作之后，我们往往很想知道，当前公司整体的数据安全治理水平如何，做得好不好，或者说如何评价当前的数据安全治理水平，怎样才算做得比较好？
  • 一方面，我们可以借助外部的DSMM（阿里牵头拟制的国家标准《信息安全技术 数据安全能力成熟度模型》, Data Security Maturity Model），来对公司的现状进行评估，看看处在哪一级。另一方面，本书也打算用自己的理解，概述一下理想中的数据安全治理能力成熟度（DSGMM, Data Security Governance Maturity Model）应当是怎样的。
  • 在评价维度上，我们选取了两个维度：
    • ■ 第一个维度包括安全治理的三个核心要素（战略、组织、政策）。在实际的治理工作中，战略主要通过项目建设交付的基础设施、流程系统、工具和技术等技术因素来支撑；组织主要通过权责划分、管理问责、绩效运营等跟组织和人员有关的运营管理来支撑；政策主要通过合规与风险管理来支撑。
    • ■ 第二个维度是数据的全生命周期，体现以数据为中心的理念。
  • 在数据安全治理能力成熟度上，主要以三个支撑要素为评价基础。这三个支撑要素为技术支撑（项目管理的交付成果）、绩效运营（运营管理）、合规与风险管理，分别支撑数据安全治理的战略、组织、政策。在成熟度中应同时考虑它们在数据全生命周期中发挥的作用，如图所示。
  • 一级为不可重复的初始状态，即使存在好的实践做法，也是单例。
  • 可持续、可重复的过程，可视为成熟度二级，不过这还没有达到及格线。
    • 怎么理解可持续、可重复的过程呢？ 以漏洞扫描为例，员工A昨天使用的是破解版的某X厂商的扫描工具，员工B没有使用扫描工具，而是凭借自己的经验，人工渗透测试了一番，那么漏洞扫描这个活动，在公司就是不可持续、不可重复的一个过程。不同的人来执行，结果大不一样，更别提风险量化了。这漏洞扫描这个活动上，就需要大家使用相同的工具（无论是自研工具还是外购产品），执行同样的扫描项目。 再说安全配置，如果每个人实施的结果都不一样，那么这个安全配置其实执行了跟没有执行区别也不大。不仅仅是需要配置规范，还需要相应的工具来支撑，比如提供配置工具，或者将安全配置做进镜像。 入侵防范方面，如果各业务、各产品自行其是，解决方案不一，那也不是可持续可重复的。因为大家的能力参差不齐，少量团队能力很强，但更多团队欠缺安全防护能力。所以也应该具备安全防御的基础设施，并在各业务中统一实施落地。 还有事件响应，如果出了安全事件之后，分工协作上一片混乱，各个具体的环节没有明确的责任人，这也是不可重复的。需要有明确的应急响应流程及预案，通过文件固定下来并在演练中不断完善，出了事件就能有条不紊地处理。
  • 在可重复的基础上，逐步构建起充分的文档化定义、相对完善的基础设施、基本的流程控制，以及满足合规的门槛要求，这些构成了数据安全治理能力的及格线（第三级）。
    • 什么叫充分的定义呢，看起来很拗口，但其实也很简单，主要是指相对完善的文档体系，也就是充分的文档化。政策总纲、管理政策、标准、规范、流程/指南等，都通过文档化确定下来，做到“有法可依”。 需要定义的内容包括： ■ 战略目标、范围、原则。 ■ 组织和职责的定义，谁负责什么内容，以及问责的标准和定义，用于确定出了事之后如何问责及处罚。 ■ 政策总纲，或供引用的最佳实践框架。 ■ 内部合规标准的定义，包括内部标准、规范、流程遵从等。其中，应包括各种术语的定义，比如数据Owner、项目阶段、数据生命周期各阶段等；风险、漏洞、事件的分级和定义，用于在内部达成共识，减少分歧（避免有人对同一风险、漏洞、事件，产生不同的定级预期）；过程或活动（Action）的定义，应当采取什么活动或流程来消减风险，比如同行评审、漏洞扫描、安全配置、入侵防范、事件响应等。 ■ 风险处置标准的定义，什么样的风险不可接受，需要降低到什么标准，什么样的风险可以接受以及谁来决策接受等。 在合规方面，满足合规的门槛要求，也就是满足法律法规的要求、满足监管层面的要求、满足合同义务的要求。上述问题如果基本都能解决，那么可以认为企业在数据安全领域，已经达到及格线了。
  • 如果要达到更好的四级成熟度水平，还需要具备一些增强的能力，那就是：
    • ■ 各种控制措施接近最佳实践，包括在设计中构建数据安全能力且可以通过自检等方式实现产品设计安全上的度量（Security & Privacy by Design）。
    • ■ 具备直接可验证的合规最佳实践，如数据目录、数据流图、数据主体请求的自助管理后台，保障数据主体的各项权利等。
    • ■ 具备职责分离（SoD, Separation of Duty）机制、对各业务团队的绩效的度量（如打分或排名）、安全培训/考试的度量。
    • ■ 具备风险量化与闭环跟进机制。重点是风险量化，也就是度量，用具体的数字来量化风险现状和改进趋势。数据主体请求也要可以度量，比如SLA。
  • 要做到优秀（90分以上，五级成熟度水平），就需要在度量的基础上，通过持续的改进和优化，让数据安全治理各方面（战略、组织、政策）均达到业界最佳实践，成为业界学习参考的对象，并坚持长期持续地改进。 怎么才能证明这一点呢？在组织上，通过监督、汇报或报告、绩效度量等机制，发现未履行职责或履行职责不到位的团队，执行管理问责，尽早发现落后的团队加以辅导、培训。要达到五级，则需要真正地执行管理问责，或基于上述度量反馈，实施组织架构的调整或优化。 对于安全战略和政策，则需要定期、例行的内部或外部的审核机制，如内部蓝军、内部审计、外部认证/测评、外部审计等，以及良好的反馈机制，包括各种内部反馈、外部反馈渠道等。 审核发现的问题/风险或通过各种渠道接收到的问题/风险均执行了风险控制，并得到了良好的闭环处理。其中审核记录、反馈记录均需要留存下来，保存一段时间，作为持续改进的活动记录。
  • 数据安全与隐私保护治理目前在国内还属于起步阶段，以上所介绍的方法也仅仅是个起步参考。综合运用PDCA方法论，以及GRC风险治理框架，可以让我们从传统的安全领域切入数据安全与隐私合规这一领域，并逐步建立起数据安全与隐私保护的第一道防线（业务自身的隐私合规）和第二道防线（企业整体的数据安全与隐私风险管理体系）。不过，能够拿来介绍的方法，都是别人家的方法，如果不能用于工作实践，去亲自感受它，就无法真正地理解它们。大家在了解这些方法之后，还需要深入业务实际，让自己“脸上有汗、脚上沾泥”，在实践中去验证，不断加深理解和提高，并最终形成自己的经验总结或方法论，这是从任何书本中都无法学来的。
• 数据安全架构与治理总结