[安全] GDPR 知识梳理及自动化合规
![[安全] GDPR 知识梳理及自动化合规](../christian-lue-7dEyTJ7-8os-unsplash.jpg)
GDPR 背景
2018年5月25日，GDPR将正式生效，并取代当前的数据保护指令（DPD）。该规范比指令更有力，因为它不需要由每个成员国单独采用。相反，自生效之日起，所有成员国的法规将立即适用于法律。此外，GDPR新规是在28个欧盟成员国统一实施生效的，这将使28个欧盟及欧洲经济共同体成员国的隐私保护法更具有一致性和现代性。但是，GDPR的合规要求是相当高的，需要大多数企业投入大量的人力、财力才能得以实现。
欧盟议会于2016年4月通过了GDPR新规，用于取代1995年发布的过时的数据保护指令（DPD）。新的指令完全更新了欧盟成员国以及任何与欧盟各国进行交易或持有公民（欧洲经济区公民）数据的公司必须存储安全和管理个人数据的方式。2018年5月25日，GDPR将正式生效，并取代当前的数据保护指令（DPD）。该规范比指令更有力，因为它不需要由每个成员国单独采用。相反，自生效之日起，所有成员国的法规将立即适用于法律。
GDPR 的适用范围
GDPR新规是在28个欧盟成员国统一实施生效的，这将使**28个欧盟及欧洲经济共同体成员国的隐私保护法更具有一致性和现代性。但是，GDPR的合规要求是相当高的，需要大多数企业投入大量的人力、财力才能得以实现。**事实上，无论公司总部在哪儿，无论数据存储和处理地点在哪儿，只要与身处欧盟的人做生意，或者监视欧盟公民的行为，就必须遵从GDPR。
判别的标准是什么
什么样的组织或者系统需要满足 GDPR？一般来讲，只要满足如下条件的都需要满足 GDPR 的标准。
1.为了向欧盟境内可识别的自然人提供商品和服务而收集、处理他们的信息。 2.为了监控欧盟境内可识别的自然人的活动而收集、处理他们的信息。 3.即使是在欧盟境内没有分支机构的中国公司，只要处理了欧盟境内的数据主体的 个人信息或者监控其行为，也将受到GDPR的管辖。
GDPR 规定数据控制者义务
GDPR 条款中规定**数据控制者的义务：**数据控制者必须全面付诸实际行动并采取适当的管理措施保护数据主体的信息安全；在指定数据处理者时，数据控制者必须确保持有适当的书面数据处理协议；一旦数据控制者发现数据泄露，必须在72小时内通知数据保护机构数据泄露的消息；数据控制者有义务及时回应来自数据主体的要求，不得有任何不当延误且最晚在收到要求后一个月内回复。按照GDPR最佳实践，需要在以下4个方面落实相应的技术和组织措施。
- 对个人数据进行加密和脱敏
- 确保处理系统和服务加密，确保完整性和弹性
- 如果发生了相关的故障，需要及时的回复个人数据，确保高可用性。
- 持续的测试和评估技术和组织措施框架
GDPR 要求处理个人数据的原则
GDPR第五条要求个人数据的处理必须遵循以下原则：
- 个人数据数据必须合法、公正、透明地处理
- 个人数据仅依据明确、合法目的取得，不得违反原有的目的。
- 依据数据最小量原则，仅仅采集恰当的数据。而不是收集尽量多的数据。
- 数据的准确性其实是包括数据正确性与即时更新，如果数据有变化，那么就应该毫不拖延地消除或纠正
- 责任性：组织应透过信息技术或者组织管理机制，确保适当的安全性、完整性与机密性，防止数据泄漏。
- 数据存储方面不超过允许期限
风险评估
风险评估贯穿于企业 GDPR 合规制度的建立、实施以及更新完善的每一步， 也是企业判断 GDPR 合规制度是否必要以及如何建设的首要步骤。合规初期， 企业进行 GDPR 风险评估的重点主要为:(1)GDPR 是否适用;(2)GDPR 所 涉及的业务领域及其数据的收集、使用、处理、保存和跨境传输的状态。
数据收集
数据收集是企业进行数据处理活动的起始环节。企业在对特定领域业务中涉 及到数据收集的环节进行风险梳理时，可以重点比照 GDPR 中的下列要求，确定企业在特定目标业务领域中的数据收集环节是否存在较大的风险:
数据收集前是否进行充分告知
GDPR中规定数据控制者或处理者在向数据主体进行数据收集前，需以清晰 明确、易于理解的方式向数据主体告知有关数据收集和处理的相关信息，具体包括:
- 数据控制者、数据处理者以及二者的数据保护官(DPO，如有)的身份 和联系方式，如电话、电子邮箱、邮寄地址等;
- 数据收集的目的、种类、数量、范围;
- 数据收集后可能进行的数据处理活动;
- 数据的存储期限;
- 数据接收方或接收方的种类;
- 数据主体所享有的主张数据获取、修改、删除、限制处理、反对处理、可 携带等权利
- 除此之外，企业最好还能向数据主体披露:
- 数据跨境传输的相关情况;
- 所采取的安全保障措施的细节;
- 向监管机构投诉的权利、个人数据的来源;
- 撤回同意的方式等
数据收集前是否已获得同意
根据 GDPR 的相关规定，数据控制者或处理者向数据主体进行数据收集前， 需在对数据主体进行上述告知的基础上，取得数据主体对数据收集的明示且自愿 的同意，并告知数据主体其有权随时撤回同意。
数据收集是否具有其他合法事由
除前述数据主体的同意外，GDPR 还规定了其他五种数据收集和处理的合法 事由，包括出于合同履行、履行法定义务、保护个人重要利益、维护公共利益以 及追求正当利益的必要。企业可以参考这些合法事由的具体规定对自身的数据收 集行为进行审查，保证其满足数据收集和处理的合法性要求。
数据的使用和处理
企业可以重点比照 GDPR 中的下述要求，对目标业务领域相关数据使用和
处理环节所涉及到的合规风险进行判断:
确保数据处理符合数据初始收集时的目的
GDPR 规定数据控制者或处理者所进行的数据处理应当符合初始收集时的 目的。因此，建议企业在对目标业务领域的数据使用和处理环节进行核查时，注 意比较其数据使用和处理的目的、范围、主体等内容相对于数据初始收集时是否 发生变化;如发生变化，是否在使用和处理数据前对数据主体重新进行告知并取 得数据主体合法有效的同意。
确保数据处理遵循准确、必要、及时的原则，并以相关、必要为限度
GDPR 规定数据控制者或处理者所进行的数据处理应当遵循准确、必要、及 时的原则，并以相关、必要为限度。因此，建议企业在对目标业务领域的数据使 用和处理环节进行核查时，注意判断其所进行的数据处理与数据收集的目的是否 具有一定的相关性，是否在数据收集后的一定时间内发生以及是否为实现数据收 集时的目的所必要。
确保数据主体能够限制数据处理
GDPR明确数据主体有权限制数据控制者或处理者对其数据的处理活动。因 此，建议企业注意核查其是否已经建立特定的机制或为数据主体提供特定的途径， 以确保数据主体在特定情形(如当数据主体质疑数据准确性时，或数据处理系非 法且数据主体反对删除数据时等)下可以限制数据控制者对自身数据进行处理的 权利。
确保数据主体能够反对特定的数据处理
GDPR明确数据主体有权反对数据控制者或处理者的特定数据处理活动。因 此，建议企业注意核查其是否已经建立特定的机制或为数据主体提供特定的途径， 以确保数据主体在特定情形下有权反对对其进行的特定的数据处理活动，包括以 直接营销为目的的数据处理、数据画像等。
数据的存储
GDPR 规定数据控制者和处理者对于能够识别数据主体个人数据的保存时 限不得超过数据处理目的的必要。因此，建议企业注意核查其是否已经建立特定 的机制或为数据主体提供特定的途径，以确保企业能够识别由于数据处理目的已 经满足而存储到期的数据，并及时对到期数据进行删除。
数据的传输
GDPR 规定数据控制者或处理者对数据主体数据的传输应当在采取特定的 保护措施保障数据安全的情况下方可进行。此外，在技术可行的情况下，GDPR 规定数据主体有权要求将其个人数据从企业转移到另一个控制者手里且企业不 应加以阻挠。因此，建议企业注意核查其是否已经建立特定的机制或为数据主体 提供特定的途径，以确保数据主体能够进行上述数据传输。
第三方数据处理
GDPR规定数据控制者在选择数据处理的合作第三方时，应当选用具有充分保证的、采取合适技术与组织措施的、处理方式符合本条例要求并且能够保障数据主体权利的处理者。数据控制者应当在与第三方处理者的合同文本中纳入关于 数据处理者 GDPR 合规义务的约定，这类合同和约定应当包括处理者相对于控 制者的责任、主体事项、处理期限、处理性质与目的、个人数据的类型、数据主 体的类型及控制者责任与权利等。因此，建议企业注意对已经开展合作以及所要 进行合作的数据处理者及双方之间所订立或将要订立的文本进行仔细筛查，判断 其是否符合前述要求。
在上述梳理工作完成之后，企业应当根据具体的识别结果形成企业内部的 GDPR 风险识别清单。企业可以该清单作为指导，结合 GDPR 的各项具体要求开 展后续的具体合规工作。
如何应对 GDPR
落实响应的技术和组织措施 TOMS
按照GDPR最佳实践，需要在以下4个方面落实相应的技术和组织措施。 1.对个人数据进行加密和脱敏 2.确保处理系统和服务加密，确保完整性和弹性 3.如果发生了相关的故障，需要及时的回复个人数据，确保高可用性。 4.持续的测试和评估技术和组织措施框架
安全应对策略
GDPR许多要求的重心都是确保有效控制和保护个人数据。AWS服务提供的功能可让您以自己所需的方式实施安全措施及各类具体措施，助您实现GDPR合规性，部分措施示例如下：
日志与审计
GDPR 许多要求的重心都是确保有效控制和保护个人数据。首先需要根据GDPR及组织内部对于安全要求确定哪些人和系统能够根据数据访问控制确定能访问哪些数据条目之后，同时需要记录对数据的这些访问。建议在日志记录方面采取措施，将不必要的个人数据从日志事件中移除掉。按照GDPR 的规则，设备识别符、IP 地址、姓名，Cookie 等数据等都可以视为个人数据，因为根据这些数据都能识别出每个个体。
数据访问控制
组织需要遵循治理规则，这些规则规定了组织如何访问个人可识别数据、数据如何存储、存储多长时间，甚至用于什么目的。更重要的是，这些标准突出了数据访问和数据安全的交集。如果数据访问不是基于安全标准，那么它是没有意义的。
静态数据加密
数据加密的主要目的是保护组织的数字数据机密性。使用不安全的Internet或其他可能不安全的计算机网络传输存储在服务器和计算机系统上的数据。存储未加密的数据可能会危害数据的机密性。
数据传输加密
数据传输加密保证在电子传送、传输或存储个人数据到数据存储媒介的过程中，未授权人员不得对其进行读取、复制、更改或删除，且确保通过传输系统的个人数据传输可以被查证。加密在数据保护中起着至关重要的作用，用于保护传输(正在传输)和静止(存储以备后用)数据。
数据库加密
GDPR第32条和第83条建议将加密作为数据保护技术之一。实施数据时组织面临的挑战。加密不仅可以确保对数据库表中的个人数据进行加密，还可以确保数据备份也被加密。
数据脱敏
数据匿名化是一种数据转换技术，通过对数据进行有效的处理，从而使人们无法将数据与个人身份、目标或机构联系起来。匿名化可减少意外泄露数据的风险，并且，如果确实发生数据泄露，则被窃取的信息将对攻击者毫无用处。
数据完整性
数据完整性（Data integrity）是信息安全的三个基本要点之一，指在传输、存储信息或数据的过程中，确保信息或数据不被未授权的篡改或在篡改后能够被迅速发现。通常使用数字签名、散列函数等手段保证数据完整性。所以需要对数据的存储进行完整性校验。
如何确保数据安全
个人数据规范
我们对所有应用程序的个人数据收集处理进行了彻底的审查并记录各种数据来源。符合GDPR规范的自动化措施也正式实施。
提供可见性和透明度
我们的职责是为客户及其最终用户提供个人数据的有效管理和保护。我们已经开发了自动化措施，可以为客户提供透明化数据。
增强数据完整性和安全性
我们维护技术和组织安全惯例和措施，以保护客户数据的机密性、安全性、可用性和完整性。
数据的可移植性和可传输性
每个最终用户都有权接收、清除或传输其所有个人数据。考虑到这一点，我们已经实现了新功能，并将继续致力于在产品改善中优化这些功能。
隐私保护屏障
已通过欧盟– 美国隐私保护盾(EU – U.S. Privacy Shield)和瑞士–美国隐私保护屏障(Swiss-U.S.Privacy Shield)架构的自我认证，并由第三方独立公司TrustArc, Inc进行认证。遵守此自愿性框架反映了我们对客户数据保持最高隐私和数据安全性标准的承诺。
数据处理协议
过去我们使用了强大的数据处理协议，我们已经进行了修订，以使这些协议和未来的协议都符合GDPR要求。
组织通常通过以下方式围绕数据库具有多层安全性：防火墙，入侵检测系统和适当的网络分段，希望攻击者将无法直接访问数据库。但是，作为传统网络边界变得越来越模糊，人数（管理员，测试者以及可以直接访问数据库的合作伙伴）正在增长；它是直接保护数据库变得非常重要。为了减少攻击可以减少攻击者访问数据库的方式，这是对确保安全性尽可能接近数据极为重要。
在评估风险性质时，面临的挑战之一就是要确定评估，因为数据库应用程序通常包含来自网络，操作系统，数据库以及应用程序本身。恶意入侵者可以利用任何这些切入点的弱点。此外，入侵者还可以定位负责使用，管理，测试和维护系统。组织还需要考虑他们的系统如何部署，包括将其部署在云中，使用可能不会使用的旧版应用程序有其源代码，并依赖第三方测试和开发团队。
多年来，MySQL企业版发布了许多功能来帮助组织应对来自不同威胁媒介的攻击。细粒度之类的东西审核，透明数据加密，用户身份验证，高级加密和数据库防火墙。 MySQL企业版安全功能可帮助组织加速GDPR通过自动化，透明和高性能的技术和产品套件。本节说明MySQL企业安全控制可以帮助综合GDPR的安全要求评估，预防和检测。
评估安全风险
第35条要求对某些类型的数据进行数据保护影响评估处理。评估风险性质时的挑战之一是确定
要评估什么，因为数据库应用程序通常包含多个入口点，并将个人数据散布在多个定义不严格的列和表中访问控制。
MySQL Enterprise具有通过提供以下工具来帮助应对这一挑战的功能：
评估应用程序数据的多个方面：
- 查找包含“个人数据”的表和列
- 配置数据库以确定整体安全配置文件
- 分析数据库角色和特权，以确定控制器，处理器，第三方，数据主体和收件人可以访问个人数据
具体使用工具
使用MySQL Workbench工具评估敏感的数据格局在当今各种复杂的应用程序中，查找个人数据是一项艰巨的任务识别信息可以嵌入到多个应用程序的多个表中模式。MySQL Workbench数据建模，模式检查器和表检查器工具自动发现包含“个人数据”和相应数据的列
数据库中定义的父子关系。使用MySQL Workbench工具的用户可以发现存储信用卡号和国家标识符等数据的表采样数据并识别敏感列。识别个人数据后，这样就可以应用相关控制措施，无论是预防措施还是侦探措施。
通过执行特权分析来评估最小特权访问
一旦识别出个人数据，识别用户就变得很重要（数据主题，第三方，监管机构和收件人），包括特权用户和管理员（控制器，处理器），他们不仅可以访问而且可以处理个人数据。在应用程序设计和维护过程中，可能会无意中向用户授予其他特权。MySQL工作台用户管理工具以及MySQL Enterprise Monitor有助于提高安全性。
通过标识运行时使用的实际特权来确定应用程序的数量。
确定的特权
由于可以评估未使用的设备是否有可能被吊销，从而有助于实现最低特权模型。
**使用 **** MySQL Enterprise Monitor ** 评估数据库配置
所有数据库都带有许多可调的配置参数，以适应广泛的需求安全要求。重要的是要确保配置仍然安全，具有不会随着时间的流逝而变化，并会实施当前的最佳做法。组织需要扫描数据库以查找许多与安全性相关的设置，包括检查默认设置帐户密码和帐户状态。可以使用MySQL Enterprise Monitor运行对MySQL数据库进行策略检查，确定趋势并监控与正确的“黄金”配置。
使用透明数据加密来加密静态数据
GDPR第32条和第83条建议将加密作为数据之一保护技术。实施数据时组织面临的挑战之一
加密不仅可以确保对表中的个人数据进行加密，还可以确保
备份。查找和加密来自所有这些来源的数据可能是一种资源-
繁重的任务。MySQL透明数据加密（TDE）通过以下方式解决了这一挑战
加密innodb表空间，重做和撤消日志以及MySQL中的数据
企业审核日志直接在源（数据库层）中记录。TDE加密数据
写入存储（包括备份）时自动显示。加密的数据是
从存储中读取时相应地自动解密。这个自动
数据库层的加密解密功能使解决方案对
数据库应用程序。在数据库和应用程序上强制执行的访问控制
层保持有效。SQL查询永远不会改变，因此没有应用程序代码或
需要进行配置更改。MySQL企业版已预装
TDE并且可以轻松启用。
加密数据时的另一个问题是对数据库和数据库的性能影响。
应用程序操作。像TDE一样，加密和解密过程非常快
利用MySQL数据库缓存优化，并利用基于CPU的硬件
各种芯片组上均可使用加速功能。
数据库匿名化
MySQL Enterprise Masking和De-Identification通过以下方式解决了这些挑战
提供匿名和掩蔽格式，函数和字典的库
转换和数据黑名单。个人资料和其他敏感信息，
例如信用卡号，身份证号和其他个人身份信息
信息（PII）可以通过现成的屏蔽库轻松地屏蔽，
随机，字典和黑名单功能。
陈述26还指出，数据保护原则不适用于匿名
当以以下方式匿名提供个人数据时的信息：
数据主体不再可识别。在非生产环境中屏蔽数据可以
帮助将开发，测试和其他环境排除在GDPR范围之外
并非真正需要个人数据。
Privacy by Desgin
设计原则
- 最小化
- Apple pay业务中使用可重 置的设备卡号替代原始银行 卡号等敏感信息，因此用户 的银行卡号不会存储到苹果 设备或苹果服务器上，也不 会共享给商家。
- 隐藏化
- Google将用户人脸和车牌虚 拟化处理功能嵌入到街景图 像中，对图像中可识别出的 人脸和车牌进行模糊处理， 保护用户隐私.
- 聚集化
- 美国明尼苏达州公共卫生部网站上 发布儿童出生缺陷研究报告中，通 过隐私保护技术(如K-匿名技术和 差分隐私)对个人信息进行处理， 保证研究结果的价值和意义的同时 保护了个人隐私
- 通知
- 在用户使用摄像头调用用户敏感 信息时，Amazon的APP内会首 先弹出功能的详细说明和需要用 户授权的信息内容，用户同意后 才会弹出苹果手机系统的授权窗 口
- 控制
- WhatsApp对用户的聊天记 录和通话进行了端对端的加 密，包括WhatsApp在内的 第三方均无法获取上述信息。
- 强化
- Google同时以文字和视频 的方式向用户展示隐私保护 相关内容，包括:隐私政策、 服务条款、隐私技术等，并 在产品界面上为用户提供隐 私管理功能。
具体措施
要求： GDPR中合规要求( GDPR Article 25 )、并结合“欧盟网络和信息安全局(ENISA)报告，端对端安全性:全生命周期的保护”中隐私保护“设计策略 (Design Strategies )”、“设计模式(Design patterns )”“隐私增强技术(Privacy-enhancing technologies)”三大设计核心，以便在系统/产品的设 计过程和实际操作融入隐私保护理念，PBD实策略和施流程如下:
-
系统需求
-
是否考虑所搜集到的个 人资料与该功能关联(若 不搜集则功能无法运作)
-
系统是否有去识别化(如 需要)或masking功能
-
系统是否设计可提供隐 私声明并可选择同意/不 同意
-
系统是否可以支持当事 人行使权利
-
-
系统开发
-
系统账号应依照各自的权限分配
-
系统应设置保留日志审计记录
-
个人资料应脱敏展示或加密存储
-
-
系统测试
-
系统安全测试
-
业务部门应具备相关隐私保护的功能
-
-
系统上线
- 建立用户投诉和权利行使 渠道
- 应依与用户约定的保存期 限删除相关数据
脆弱性评估
脆弱性评估通过分析企业资产面临威胁的情况和程度，评估内部和外部的安全控制的安全性。这种技术上的信息系统评估，不仅要揭露现有防范措施里存在的风险，而且要提出多重备选的补救策略，并将这些策略进行比较。内部的脆弱性评估可保证内部系统的安全性，而外部的脆弱性评估则用于验证边界防护（perimeterdefenses）的有效性。无论进行内部脆弱性评估还是进行外部脆弱性评估，评估人员都会采用各种攻击模式严格测试网络资产的安全性，从而验证信息系统处理安全威胁的能力，进而确定应对措施的有效性。不同类型的脆弱性评估需要的测试流程、测试工具和自动化测试技术也不相同。这可以通过一体化的安全弱点管控（vulnerabilitymanagement）平台来实现。现在的安全弱点管控平台带有可自动更新的漏洞数据库，能够测试不同类型的网络设备，而且不会影响配置管理和变更管理的完整性。
安全测试方案论
为满足安全评估的相应需求，人们已经总结出了多种开源方法论。无论被评估目标的规模有多大，复杂性有多高，只要应用这些安全评估的方法论，就可以策略性地完成各种时间要求苛刻、富有挑战性的安全评估任务。某些方法论专注于安全测试的技术方面，有些则关注管理领域。只有极少数的方法论能够同时兼顾技术因素和管理因素。在评估工作中实践这些方法论，基本上都是按部就班地执行各种测试，以精确地判断被测试系统的安全状况。本书再次向您推荐几种著名的安全评估方法论。本章将重点突出这些方法论的关键特征和优势，希望它们能够帮助您拓宽网络安全和应用安全评估的视野。
- 开源安全测试方法论
- 信息系统安全评估框架
- 开放式Web应用安全项目
- Web应用安全联合威胁分类
- 渗透测试执行标准
上述这些测试框架和方法论，都能够指导安全人士针对客户需求制定最得当的策略。其中，前两个方法论所提供的通用原则和方法，几乎可以指导面向任何类型资产的安全测试。由OWASP（OpenWebApplicationSecurityProject）推出的测试框架主要面向应用安全的安全评估。
PTES（PenetrationTestingExecutionStandard）能够指导所有类型的渗透测试工作。然而需要注意的是，安全状态本身是一个持续变化的过程，而渗透测试只能够获取目标系统在被测试的那一时刻的安全状态。在测试的过程中，哪怕被测的信息系统发生了细微的变化，都可能影响安全测试的全局工作，从而导致最终的测试结果不正确。此外，单一的测试方法论并不一定能够涵盖风险评估工作的所有方面。而拟定适合目标网络和应用环境的最佳测试策略，确实是安全审计人员的职责。
安全测试的方法论有很多。要选取最佳的指导理论，就需要综合考虑成本和效果的因素。所以，评估策略的筛选工作受到多种因素的制约。这些因素包括与目标系统有关的技术细节和各种资源、渗透人员的知识结构、业务目标以及法规问题。以业务的角度看，效果和成本控制至关重要。本文介绍的这几种方法论，在官方网站上都有非常正规的详细说明文件。在此，我们对它们进行简要总结。如需了解详细的工作流程，您需要亲自访问相关网站，仔细研究各种文件和实施细则。
DPIA 与风险管理作业流程
评估是否执行 DPIA
- 在新业务流程、系统、产品上线或原有业务流程、系统、 产品产生重大变更时，通知业务流程接口人
- Owner:业务流程负责人
开展 DPIA
- 判断及指导业务流程負責人开展DPIA，与确认评估结果
- 协调业务流程負責人针对高和极高风险事项提出风险改善方案并提交网络安全和隐私保护委员会审阅
- Owner:业务流程接口人
分析评估风险结果
- 决策是否接受风险或增加风险改善的资源投入
- 向隐私保护总召集人汇报决策内容
指向风险整改
- 协调相关团队执行高风险、极高风险事项改善措施
- 业务流程接口人汇报改善措施的执行进度情况
AWS具体检查项映射表
根据安全应对应对策略，需要对 AWS 的哪些资源进行检查？
建议从如下7 大类，76 项进行检查。
另外，按照对应的 AWS 服务角度以及检查结果的重要程度划分，分布如下。
