1。背景1.1数据安全风险近年来，与数据泄露相关的新闻事件频发，不断引发公众的讨论和关注。所有企业都或多或少地承担着相关的数据安全风险，这可能给企业的经营带来额外的风险，包括来自公众的质疑和来自政府的处罚。超过5亿Facebook用户的个人数据被泄露；ElectorSoftware投票应用程序泄露了超过650万以色列选民的个人数据；T-Mobile数据被盗，1亿多用户个人信息被泄露和出售；亚马逊因违反GDPR欧元被罚款7.46亿……从现有的事件统计来看，数据库配置不当和黑客攻击是相对主要原因；在个人信息保护形势严峻的背景下，各国都在加强和完善相关法律法规。调控机制。1.2完善数据安全法律及合规性1.2.1现行法律及合规性国内：个人信息保护法、数据安全法、网络安全法国外：GDPR（欧盟，通用数据保护条例）、PDPB（印度，个人数据保护）Act),DBNL(US,DataLeakageNotificationAct)1.2.2工业和信息化部关于互联网行业市场秩序的专项整治行动。在工信部2021年7月组织的专项整治行动中，数据安全面临的威胁主要体现在：用户数据采集用户数据传输用户数据存储未建立数据安全管理制度，未采取必要的安全技术措施依法依规采取的措施将受到曝光、约谈、退市、暂停上网、行政处罚等处罚。1.3敏感数据治理现状及难点针对工信部的整改要求，我们梳理了现状及可能存在的风险：整改时间紧迫，留给内部处置的时间仅剩两和半个月，整改本身涉及的范围和难度都很大；涉及的项目模块包括互联网团队各部门，相关应用模块300多个；法规本身可能会发生变化，法规或整改要求可能会根据实际情况发生变化和更新，因此需要及时响应变化的要求转换、同步。问题其实就是关注这几个部分，什么是敏感数据，如何发现和脱敏，整体如何适配。基于这些困难，我们的最终目标是要以此次整改为契机，建立起长效的数据安全管理体系和体系。2.敏感数据字段发现2.1定义首先，需要定义或确定哪些数据可以被认为是敏感数据：用户的个人信息。在近年来发生的数据泄露事件中，公众更加关注此类信息的侵权程度；对于制造商、设备和设备相关数据，如操作记录、imei等唯一标识符，也存在敏感风险。此外，源自上述数据，例如：内容平台发布或存储的数据；从用户行为和特征中得出的用户画像；财务会计数据。这些场景将引起公众的极大关注。2.2数据分级规范针对复杂的敏感数据情况，vivo针对《个人信息保护法》和《数据安全法》中赋予企业的合规责任和义务，制定了具体的分级规范；简而言之，会根据影响的强度和范围来划分数据字段，而这个评级具体到字段级别：对企业运营的影响；对用户个人隐私和权益的影响。其中，风险等级以上的数据可能造成负面影响，侵犯用户权益和隐私，需要不同程度的脱敏处理。我们希望通过针对不同安全级别采取不同的运营策略，确保数据安全风险可控。2.3现状及改进措施有了标准规范层级后，我们需要对现有数据和新增数据进行分类，但目前存在以下问题：新领域没有明确的层级，经常需要使用分级前分类；数据字段识别引擎有待优化，主要支持用户类型识别，对非用户数据支持较差；股票数据依赖人工判断，工作量大；缺乏衡量评价指标，质量不可控。针对目前存在的这些问题，在各个环节进行了优化和改进，形成了完整的敏感数据字段自动发现解决方案：2.4系统自动分类纠错通过敏感数据识别引擎，结构化数据整体扫描，自动识别敏感字段。数据，支持数据分类和数据治理，根据结果对敏感数据进行进一步的安全保护和后续细粒度管理。在具体环节，我们通过系统定期对业务集群的库、表、集合、字段进行扫描，对其中的字段进行分类打分，并根据已有数据进行打分（准确率），进而修正打分系统通过人工校正。进行反馈调整以实现长期的积极改进循环。我们定义了两个指标来支持评分机制的改进：Coverage：分类分级的数据量/所有数据；accuracy：正确分类分级的用户数据量*0.1/（采样用户数据*0.1+非用户类别用户类别采样数据量*0.9）。计算公式中的1:9关系是通过计算我们现有数据分类中用户数据和非用户数据的比例得到的。它实际上是用来平衡实际用户分类和分类准确率的计算。可以减少将用户数据误判为非用户数据。2.5小结最后，基于能力现状，我们实现了：MySQL/TIDB/ElasticSearch/MongoDB四种数据库的敏感字段识别；支持全自动实时敏感数据字段识别，包括创建新表和集合进行业务扫描；支持用户或非用户数据分类共计100多个类别，最终实用分类准确率不低于85%；基于这种方式内置的能力，我们可以实现敏感数据分类分类，以及针对此类场景的即席查询保护敏感数据的能力。那么我们解决了敏感字段如何发现的问题之后，我们就需要对这些敏感数据进行处理，这也是本次专项治理的核心环节。3.数据加解密3.1方案选择对于具体的处置环节，需要考虑的要求相对较多，而且在不同层次上，相关方的关注点可能不一致，需要在两者之间做出权衡这几点。对于开发和运维，希望接入简单，一次整改解决所有问题。对于安全性，它关注满足合规性要求并避免可能的风险。这里主要介绍MySQL的工作。我们内部团队从多个方向出发，给出了相应的解决方案：基于MyBatis插件的实现形式，业务可以使用自定义的加解密方式，在应用内部实现加解密；基于shardingsphere实现的应用层加解密，业务通过改变接入层使用特殊配置的数据源；基于MySQL架构中用于实现通用数据加解密的代理，对应用层是完全透明的，同时限制访问解密数据的权限必须通过代理。3.2方案对比需要SDK加解密（定制MyBatis插件）ShardingSphere中间件（vivo-JDBC）数据库透明加解密（Proxy）接入成本高，需要修改应用高，需要修改应用低，不需要修改代码，只需配置脱敏规则维护成本业务自维护代码中间件团队维护数据库团队维护推广成本高，只支持java语言high，只支持java语言low，属于MySQL架构高可用应用服务本身决定应用服务本身决定MySQL高可用不支持托管客户端软件解密，不支持下游使用，不支持。它需要连接到代理。从一些常规的角度来看，我们通过对实际实施和业务反馈的研究，对比了三种方案的效果，在成本和上下游兼容性方面，Proxy具有相当大的优势。一般情况下，我们内部推荐使用Proxy进行加解密。当然，其他解决方案也是可行的。它们本质上是相同的加密和解密算法。在程序之间无缝切换。一般来说，在这些方案中，加解密发生的环节都位于发起服务器和数据库层之间；为了提高效率，中间执行具体转发请求的服务器或proxy代理会缓存相应的密文密钥，所有密文密钥都托管在KMS服务平台上，在找不到或无法启动时再发起请求。原则上不能中途修改密钥，否则会导致历史数据被破坏。3.3代理加解密3.3.1原理加解密的核心是拦截数据传输，并据此改写SQL和结果集；该操作是基于预设的脱敏规则：逻辑字段：用户识别中的字段名称明文字段：存储原始数据的字段密文字段：存储加密密文数据的字段从设计上来说，明文字段密文字段在一定时间内会共存，支持任意明文和密文切换。保证线上运行的稳定性和回滚能力；业务查询或写入依赖于逻辑字段，在传输过程中会改写相应的规则，包括将明文/密文字段改写为逻辑字段和反向操作，分别对应读包和写sql两个阶段；这里是一个比较常规的数据写入模型，包括明文字段和密文字段password和password_cipher。脱敏规则中包含了password和password_cipher字段，那么Proxy在读取SQL的时候，会重写对应的字段和数据列，包括名称重映射和数据加密处理重写。3.3.2优缺点Proxy本身是基于MySQL协议实现的代理层。与直接使用SDK或shardingsphere等语言偏向方案相比，具有以下优势：是MySQL架构的一部分，可以实现加解密操作仅限于“数据库架构”范围，对数据透明外部系统；兼容所有使用MySQL协议的数据库，更容易在相关场景应用，没有访问障碍；它支持各种语言，没有限制。但它本质上还是依赖于加密列的实现，因为原有语义的破坏和算法的局限性，无法支持比较和计算操作。总的来说，我们已经实现了基于Proxy的通用加解密方案，可以完成对敏感数据的处置。根据目前可行的发现和处置措施，我们可以对当前的敏感数据进行整改。3.4存量数据处理我们可以将当前的业务数据分为两类：归档或备份类的冷数据，可以直接将整个文件加密存储在oss系统中，满足需求；线上数据，也就是业务会进行读写的数据，这种类型需要控制对业务的影响。3.4.1股票数据客户端加密这种模式是典型的源写加密。添加密文字段后，可以在表中重复使用条件匹配，找到没有写入密文的行，对找到的行进行锁定。之后可以查询对应行的明文字段中的数据，改写成编写好的sql，执行给具有加解密能力的SDK或Proxy，通过循环操作完成丢失的密文数据；这样业务可以自己Execute，风险相对可控，虽然会明显产生锁开销和额外的写入压力；读取配置，获取需要清洗的数据表字段，查询加密列为NULL的行的主键值，如(SELECTarticle,dealerFROM`test`.`shop`FORCEINDEX(`PRIMARY`)WHERE`article_cipher`ISNULLOR`dealer_cipher`ISNULLOR`price_cipher`ISNULLOR`price_cipher`ISNULLORDERBYarticle,dealerASCLIMIT10;)主键值，查询加密列的明文值，并加锁查询行，例如：(SELECTarticle,dealer,priceFROM`test`.`shop`FORCEINDEX(`PRIMARY`)WHERE`article`=1AND`dealer`='A'LIMIT1FORUPDATE;)之后获取明文数据，通过Proxy更新明文列，达到数据清洗的目的，例如：(UPDATE`test`.`shop`SET`article`=1,`dealer`='A',`price`=3.530000WHERE`article`=1AND`dealer`='A';)提交清洗事务，循环执行2、3、4清洗全表数据，当第2步查询返回空时3.4.2gh-ost工具加密（在线DDL更改工具+数据加密算法）我们依靠gh-ost工具实现对MySQL表的在线更改。它的机制是在原来的集群上创建影子表。通过select和Binlogrowcopy，将原表的数据倒入影子表，最后通过一个锁开关，改变访问目标。那么这个链接其实可以和我们做敏感数据治理的工作结合起来，因为实现的时候会需要建立密文字段（也可以不建立），所以加密历史数据的链接可以直接放在新增加的密文中，当一个段操作发生。4.数据链路上下游适配4.1业务访问改造对于敏感数据治理的数据库上游，很明显是涉及敏感数据的业务系统。标准数据落地；那么对于常规的业务访问，我们只需要在使用层使用已经集成在MySQL架构中的代理进行脱敏规则，传输的流量就可以进行无缝加解密，从而在计算层进行非破坏性的判断并配置脱敏规则，开启自动透明加解密的用户级开关，实现4.2实时采集在实时采集任务的原逻辑中，实时数据变化对应的Binlog会是从源头获取，解析成相对下游的格式，放在es/kafka或其他下游。因为加密使得密文实际存储在数据库中，所以Binlog中的数据也将是密文数据。在这个过程中，需要在获取层实现类似代理的解密能力，通过获取脱敏规则对密文字段的行进行改写。数据，然后向下游执行。5.总结与展望5.1从敏感数据的发现、处理、敏感数据治理适配方案总结：5.2展望5.2.1挑战通用脱敏方案只针对支持MySQL协议的数据库；不支持列计算和比较操作，SQL兼容性有限；目前主要关注存储层的加密。5.2.2优化规划针对这些，主要从两个方面进行规划：提高SQL兼容性，适应复杂的查询或写入场景；强化目前仅限于数据存储层的加密方案，扩展多源数据场景的治理方案，完成全生态的统一加解密方案。笔者介绍尚永兴，vivo互联网高级数据库研发工程师。
