一、背景介绍
随着数据时代的到来，越来越多的国家、企业都遭受到信息泄露的困扰，例如2022年发生的某某汽车数据泄露事件，标志着外部攻击者常规的攻击手段逐渐从传统的服务破坏转变为信息窃取，为应对攻击方的手段进化，甲方安全体系架构设计也逐步从以网络、终端为核心的保护理念过渡到以数据为核心的保护方式，近年来伴随着国际上例如欧盟 GDPR 等数据安全严令的颁布，大陆也相继在2021年颁布了《中华人民共和国数据安全法》、《中华人民共和国个人信息保护法》（后续简称数据安全法及个人信息保护法），标志着国内信息安全保护新纪元的到来。
二、数据安全保护措施介绍
针对数据安全的保护实践，并不是单一保护措施就能够解决的安全问题，而是需要从数据收集生成、数据使用、数据传输、数据存储、数据分享与披露、数据销毁整个生命周期去考虑，将需要的控制方法和理念融入到产品的开发过程、技术体系搭建及流程设计体系之中。本次文章的内容受限于篇幅，主要针对数据存储加密及数据展示脱敏两部分的实践探索进行重点介绍，其中数据存储加密只说明结构化数据加密的部分，非结构化数据的加密及鉴权并不进行涉及。
图1：数据泄露的走向呈现多元性
为保证文章内容的通读适用性，故在第二部分优先先介绍各自的基础概念及其解决的核心问题，便于不同领域的读者进行理解和回顾。
2.1 数据展示脱敏
问题一、什么是数据脱敏？
数据脱敏是按照一定规则对数据进行变形、隐藏或者部分隐藏的数据处理方式，让处理后的数据不会直接泄露原有数据的敏感属性，从而实现对于敏感及机密数据的保护。
以手机号举例，完整的手机号为11位存在一定规律性的数字字段，那么脱敏后的手机号可能就是 138*****413（用*替代了中间的数字）
问题二、脱敏解决什么问题？
针对现有的产品形态，展示敏感数据的介质可能是网页、APP、小程序等，在展示敏感信息，特别是机密或者个人信息的时候，可通过肩窥、任意复制等形式出现泄露。
我们举一个比较常见的案例，企业任何形式的通讯录中均包含了公司全体的手机号及个人信息，如果默认展示不存在任何脱敏措施可以进行任意查询，是否可能存在有人通过批量脚本进行查询导出的方式，从而导致员工手机号大量泄露。
2.2 数据存储加密
问题一、什么是数据加密?
在早些年提起所谓“数据安全”的概念时，大部分人们会联想到的都是所谓的“存储安全”概念，在一个时期内，数据安全和存储安全是划上了狭义的等号的，这个阶段内数据视为一种静态的资源进行保护。随着理念的提升，数据被人们认知为一种动态的资源，这种情况下，数据存储作为原始数据的基础保存形式，需要被作为源头保护起来。
图2：加密和解密样例
问题二、加密解决什么问题?
数据加密主要的目的就是为了防止原始数据被窃取之后导致的敏感数据泄露，例如数据库文件被拖走，经过加密的数据字段，在外部攻击者拿到文件后，也无法进行解密，敏感数据不至于泄露。
三、安全方案调研及选型
方案调研及选型是数据安全实践中极为重要的阶段，因为这其中涉及到确定方案后调整难度较大的问题，故该过程中需要技术架构、安全、DBA、CI/CD等多方的共同讨论和确定，充分识别方案中的风险及实际可行性。
3.1 敏感数据的定义
3.1.1 可参考的国内法律法规
前文提到2021年度国家颁布了适用于国内情况的个人信息保护法及数据安全法，在个人信息保护法中存在针对个人信息的描述，指的是以电子或其他形式记录的能够单独或者与其他信息结合识别自然人个人身份的信息，包括但不限于自然人的姓名、生日、身份证号码、个人生物识别信息、住址、电话号码等。
因目前针对于互联网私营企业尚未有规范化明确定义的敏感数据分类分级标准，故在实际实践过程中，调研方案可结合目前已经公布的较为成熟适用于金融领域的《金融数据安全数据安全分级指南》（JR/T 0197—2020），以及适用于电信领域的《基础电信企业数据分类分级方法》（YD/T 3813-2020）中针对敏感数据的定义及分类分级标准。
3.1.2 综合考虑意见
结合上述国内相关的合规要求，以及考虑到后续针对加密及脱敏的业务场景接入适配情况，可以从以下几个方面整体界定何为敏感数据；
- 业务数据：敏感个人信息以及涉及个人隐私的数据、UGC生成数据、企业内定义机密数据；
- 基础支持数据：口令、加解密密钥等；
最终结合整体考虑及业务实际存储数据情况，可确定适用于实际情况的敏感数据定义分类分级标准，以下为部分重点可考虑字段。
图3：敏感数据定义部分样例
3.1.3 敏感数据分类分级打标
在完成敏感数据定义的阶段后，下一步较为重要的工作是针对敏感数据分布的调研工作，是针对数据资产识别的重要步骤，根据企业内部确定的数据分类分级标准内容，对原始数据的保存情况进行识别确定，针对识别得到的个人敏感数据及重要数据标签分布，和对应业务线研发进行下一步精细确认，确保敏感数据资产分布识别的准确性。为全面推进数据加密的落地及数据的集中统一，打好相应基础工作。
在确认敏感数据分类分级分布的过程中，工具的选择主要分为扫描部分与打标部分。
敏感数据扫描抽取方案
针对扫描部分需根据实际公司情况进行选择和使用，例如公司存在大数据HIVE平台的，如对接了全局数据库数据，可以考虑从HIVE中抽取数据内容进行数据字段结构确认和示例数据标注。
如果公司只存在数据库实例可进行分布确认工作，那么针对线上数据库的扫描需同步考虑稳定性需求，在抽取数据的SQL查询方法选择上存在多种方案可选，其各自也会存在优缺点，以下做相应介绍：
方案一：顺序抽取一定数量的数据进行样本匹配
优点：实现较为简单。
缺点：如数据库实例中前期存在部分测试数据，顺序抽取的数据样本关联性会存在影响。
方案二：随机抽取一定数量的数据进行样本匹配
优点：从统计学角度来说，该种方式匹配的样本数据准确度最高。
缺点：随机抽取的样本如果SQL编写不当，且数据库数据量较大，会直接导致较多的慢查询出现。
方案三：倒序抽取一定数量的数据进行样本匹配
优点：抽取样本数据为最新产生数据，匹配准确率能够提升。
缺点：如数据库数据处于新增状态，其匹配的数据结果可能存在不一致的情况，如主键或唯一值是自增的情况，可考虑使用唯一值进行范围标定。
敏感数据识别打标方案
针对打标识别部分，目前市面上较为常见的还是通过复合规则的方案进行标定，例如对样例数据进行正则匹配，针对标准化字段名进行匹配等。但在面对庞大的数据库字段情况下，必然会出现部分误报和漏报的情况，亦如上文提到的一样，这个过程依然需要一定程度的人工介入，降低错误打标的问题。
在该部分的实践中，如考虑排查人力成本问题，建议针对识别规则选择设定的更为宽松，漏报的排查难度会高于误报的排查难度，故识别规则的宽松适当使得误报出现提升，可以有效降低对于人力的投入。
3.2 数据脱敏方案调研
3.2.1 脱敏接入方式的选择
针对数据脱敏方式的选择，目前主流的脱敏方案主要存在以下几种：
- API接口脱敏
- 数据库view方案
- JS前端脱敏
- 匿名去标识化脱敏
API接口脱敏
优点：提供的方式较为标准化，且能够支持不同的脱敏需求；
缺点：依赖于针对整体接口的统计及配置接入，防止出现遗漏从而达到整体脱敏效果；
数据库view方案
优点：可实现动态脱敏方案，适用于web应用场景，逻辑可封装在视图中，便于维护开发；
缺点：碰到较为复杂的脱敏逻辑时，其占用的空间成本及较大的性能开销都会较为凸显；
示例：
图4：创建用户信息表
针对上表创建脱敏视图
create view user_info_view asselect id,name,concat(left(phone,3),'****',right(phone,3)) as phone,concat(left(id_card,4),'**************') as id_card from user_info; 图5：创建脱敏视图表
JS前端脱敏方案
优点：实现成本最低，能够快速实现脱敏需求；
缺点：实际为伪脱敏，容易被外部攻击者进行还原，并未起到真正脱敏的效果；
匿名化方案
优点：实现相对简单，不需要复杂的算法和技术支持；
缺点：使用场景主要集中于数据集发布或共享，因泛化及抑制的限制，匿名化数据的效用会被降低，特定查询无法进行造成信息损失。
方案最优解
考虑到脱敏应当尽量从源头进行脱敏的原则，以及实际业务场景仍然可能需要查看明文数据的情况，选择通过API接口脱敏的方案进行具体实践是目前的最优解。
3.2.2 脱敏标准的确定
前文明确了需要保护数据的范围和范畴，针对数据展示脱敏的实践，我们即需要考虑到针对已定义敏感数据根据其数据特征的安全保护，又需要兼顾实际使用人在查看脱敏信息过程中，对于内容的一定可识别性，我们以身份证号和手机号来进行举例。
图6：大陆公民身份证号编码结构
图7：大陆手机号编码结构
从上述大陆身份证及手机号的编码结构组成来看，每个人的这两组信息都是由几个分段组合而成，特别是后四位是相当重要的一个识别标签。
在这里我们引用加拿大学者ElEmam等人定义了三类常见的隐私攻击场景，并结合其评估指标计算方式，针对脱敏标准的方案进行计算，尽量降低风险暴露风险，可得到以下几项结论。
图8：三种重识别攻击场景
图9：评估指标计算风险示例
评估指标结论：
- 脱敏强度位数越多，重识别及泄露风险越低，但实际情况中需考虑预期适用范围，保持数据可用性；
- 仅对手机号中间4位机身份证出生年月日进行脱敏处理，被重识别的风险概率较高，风险较高；
- 针对身份证后4位及手机号后8位进行脱敏处置，可以将平均重识别风险较低到一个较低的标准；
- 结合第三点的结论，如果保留仅保留手机号的前3位及身份证的前两位，可以将风险进一步降低；
结合以上指标考虑结论，目前国内较多企业的最佳实践，以及用户最小够用原则，以下脱敏使用实践提供参考：
图10：敏感数据定义部分样例
一个企业内部，在实践过程中最好大家需约定使用一套脱敏标准，避免出现因脱敏标准不一致，而出现被恶意利用拼凑出完整敏感信息的情况，例如一个企业内的两个AB业务，A业务针对手机号码的脱敏方式为隐藏中间4位，展示为138****6123，而B业务选择隐藏后4位，展示为1386454****，那么在这个业务场景中，攻击者就有办法通过查询AB两业务的数据进行比对，获得完整的手机号，这点需要特别注意。
3.3 数据加密的调研
3.3.1 加密算法选择
针对加密算法的选择工作，主要会出现以下几种选项和考虑内容：
- 采用国际通用加密算法还是采用目前国内规定的国密算法；
- 采用非对称加密算法还是采用对称加密算法；
- 采用加密强度最高的算法，还是选择相对适中强度的算法；
针对以上三个问题，是在加密算法选型过程中考虑最多的内容，我们逐一对三个选择进行各自的解读，便于读者知晓在实际业务场景中如何进行更好的选择。
问题一：国际还是国内加密算法？
针对该问题，主要的业务背景在于随着国内密码法的落地，国内针对于关键基础设施的密码保护要求出现了一定的变化，所以是否必须使用国密算法，主要核心的点在于该企业或者机关单位是否为认定的关键基础设施，如果一经认定，那么使用国密算法是较为稳妥的选择。
问题二：非对称还是对称加密算法？
非对称和对称在实际业务场景中，存在各自的优缺点，例如对称加密算法相较于非对称加密算法来说其加解密速度更快，更适用于大规模数据的加解密操作，而非对称算法则相反，其更适用于小规模数据的加解密操作或进行数据签名操作，在实际的加解密方案选择中，两者会结合使用，使用对称加密大规模业务数据，使用非对称保护密钥及校验加密数据内容。
问题三：强度最高还是适中的加密算法？
并不是强度越高的算法，在实际业务运用中就安全性越高，还需要出于业务性能、可用性、以及高强度算法本身缺陷等多方面的考虑，故实际的业务使用，需以实际业务数据进行加解密性能测试后进行选择。
3.3.2.加密密钥的管理机制
密钥管理是整个数据安全加密过程中最为重要的一个环节，一个安全的加密系统，至少需要二级及二级以上的加密机制，特别是密钥系统在应用自身管理下的场景，故针对加密密钥的管理在评估阶段重点针对以下几项内容进行了讨论和考虑。
- 密钥生成是否需考虑随机数的添加；
- 密钥是否需要具备轮转机制；
- 密钥存储在何种可信KMS中进行存储；
- 加密是否采用分层密钥结构（根密钥、密钥加密密钥、工作密钥）；
- 密钥是否需考虑动态转换和过期失效丢失等场景；
针对密钥管理KMS系统的最终实现，可以具体查看下述引用链接内容的介绍进行了解（WKMS微盟密钥管理系统）。
3.3.3.加密方式的选择
从整体数据流动的全生命周期来看，根据部署方式及部署环节的不同，会存在多种加密技术方案可供选择，各技术方案有其优势和劣势，在评估阶段需结合实际业务场景进行考虑，以下列举在实际业务场景中较为实际可用于评估的方案内容进行介绍。
图11：加密方式整体图示
技术一：CASB代理网关
原理解析
部署位置：终端-应用服务器之间
图12：CASB代理网关原理
原理：CASB代理网关（Cloud Access Security Broker）是一种委托式安全代理技术，无需改造目标应用，只需通过适配目标应用，对客户端请求进行解析，并分析出其包含的敏感数据。
优势：与业务结合的数据安全保护，可以基于用户、资源、操作和业务属性，灵活利用访问者所对应属性集合决定是否有权访问目标数据。
劣势：实施成本较高。
技术二：应用内加密（集成SDK）
原理解析
部署位置：应用服务器
图13：应用内加密（集成密码SDK）技术原理
原理：应用内加密（集成密码SDK）是指应用系统通过开发改造的方式，与封装了加密业务逻辑的密码SDK进行集成，并调用其加解密接口，使目标应用系统具备数据加密防护能力。
优势：
1.适用范围广，应用系统的开发商可以自行解决数据加解密的绝大多数问题，对数据库系统本身或第三方的数据安全厂商没有依赖；
2.灵活性高，应用服务端加密，主要是针对于应用服务器的加密方式，因为应用服务端加密可与业务逻辑紧密结合。
劣势：
需要对应用系统开发改造。应用系统加密的实现需要应用系统开发投入较大的研发成本，时间周期较长，后期实施和维护成本较高，也面临大量代码改造带来的潜在业务风险；
技术三：数据库加密网关
原理解析
部署位置：应用服务器-数据库之间
图14：数据库加密网关技术原理
原理：数据库加密网关是部署在应用服务器和数据库服务器之间的代理网关设备，通过解析数据库协议，对传入数据库的数据进行加密，从而获得保护数据安全的效果。
优势：
应用系统与加解密功能分离。相比较于传统的应用内加密（集成密码SDK）技术，数据库加密网关技术具有独立性，能够使用户从高度复杂且繁重的加密解密处理逻辑的开发工作解放出来。
劣势：
高性能和高可用实现难度大。数据库加密网关增加了额外的处理节点，在大数据量和高并发访问场景下，要实现高性能、高可用，面临工程化实现难点。
技术四：数据库外挂加密
原理解析
部署位置：数据库
图15：数据库外挂加密技术原理
原理：数据库外挂加密通过针对数据库定制开发外挂进程，使进入数据库的明文先进入到外挂程序中进行加密，形成密文后再插入数据库表中。这种技术使用“触发器”+“多层视图”+“扩展索引”+“外部调用”的方式实现数据加密，可保证应用完全透明。通过扩展的接口和机制，数据库系统用户可以通过外部接口调用的方式实现对数据的加解密处理。
优势：
独立权控体系。使用数据库外挂加密技术，可以在外置的安全服务中提供独立于数据库自有权控体系之外的权限控制体系，适用于对“独立权控体系”有相关需求的场景，可以有效防止特权用户（如DBA）对敏感数据的越权访问。
劣势：
1.仅支持Oracle等少量数据库类型。数据库外挂加密，目前大多数的技术实现形式，存在功能性依赖，仅支持开放高级接口的Oracle等少量数据库；
2.数据库性能损耗较高。数据库外挂加密是通过触发器、多级视图，进行外部接口调用来实现加解密，触发器或视图的运行机制要求对加密表中的每一条数据中的每个加密列的读写都会进行外部接口调用，因此，当遇到比如“查询中涉及的加密列较多”等情况时，会对数据库的读写性能存在明显影响；
3.可扩展性差。在业务变化引起数据库表结构发生变化时，需要对外挂程序业务逻辑进行调整，甚至需重新定制开发，存在后期维护成本。
技术五：TDE透明数据加密
原理解析
部署位置：数据库
图16：透明数据加密技术原理
原理：透明数据加密（Transparent Data Encryption，简称为TDE）是在数据库内部透明实现数据存储加密、访问解密的技术，数据在落盘时加密，在数据库内存中是密文，当攻击者“拔盘”窃取数据，由于数据库文件无法获得密钥而只能获取密文，从而起到保护数据库中数据的效果。
优势：
1.独立权控体系。与数据库外挂加密类似，使用插件形式的透明数据加密技术，同样可以在外置的安全服务中提供独立于数据库自有权控体系之外的权限控制体系；
2.性能损耗较低。透明数据加密技术只对数据库引擎的存储管理层进行了性能增强，不影响数据库引擎的语句解析和优化等处理过程，数据库自身性能得以更好保留，透明数据加密技术在数据库加密技术中，性能损耗较低。
劣势：
1.防护颗粒度较粗。TDE本身是一种落盘加密技术，数据在内存中处于明文状态，需要结合其他访问控制技术使用。在实战场景中难以防范DBA等风险；
2.数据库类型适用性上有限制。透明数据加密因使用插件技术，对数据库的版本有较强依赖性，且仅能对有限几种类型的数据库实现透明数据加密插件，在数据库类型适用性上有一定限制。
图17：加密技术优劣势比较
在整体技术方案的选型中，最终方向选取了应用层加密的方式来实现业务实践落地方案，但在该过程中，也出现了两个扩展方向进行讨论。
方向一：统一敏感数据收敛到中台，减少数据落地，实现敏感信息出入口最小化
优点：数据汇总统一，使敏感数据加密接入方减少，且可统一未来敏感数据出入口
缺点：对敏感信息服务的可用性要求高，且存在数据收敛改造成本
方向二：各业务及应用接入加密，根据实际业务情况接入开发
优点：各业务可根据自身情况灵活接入SDK实现加密方案
缺点：实际各业务系统的改造，工程量大，时间周期长，研发成本高
3.3.4 加密带来的影响
从上述描述加密方案选型的内容来看，加密并不是一件只有好处没有坏处的事情，其可能带来的问题也需要在方案评估阶段尽可能的考虑，如确实存在未考虑到或实际场景存在变化的情况，也需要在项目进行过程中，结合多方意见进行调整，以下总结并列出了以下几项可预见性的影响。
- 问题一：加密后带来的数据检索、数据运算、数据排序等业务需求问题如何满足；
- 问题二：加密后带来的上下游数据同步及使用问题；
问题一：
如果要对加密后的数据进行检索等操作，目前是存在较多的困难的，虽然理论学术上目前存在同态加密技术来解决相关问题，但在我们实际的工程实践中其应用场景还是较为有限，故要考虑到通用性的检索场景，目前存在两种折中的方法：
- 添加加密关键字段用于检索辅助，根据分段关键字减少搜索范围，实现检索；
- 增加辅助字段，用于检索内容的范围缩小（例如地址信息，增加省、市、区等不加密字段，通过收缩检索范围到具体街道，从而实现检索）；
问题二：
对于任何一个企业的数据来说，其都是一个动态流动的过程，且对于数据加密改造来说，必然会存在历史明文数据字段，以往的数据上下游交互一定同步使用的是明文字段，那么在加密后一定会带来原始数据同步下游的相关问题，该点会在最终明文数据完全去除的过程中爆发。
故针对该点，可考虑方案采用明文，密文字段并存双写，并在后期做服务切换的过程中，监控相应数据库 SQL 审计内容，来确定明文字段的相应流量，保证上下游改造的一致性。
四、改造实践方案探讨
推动企业内部进行数据存储加密改造以及数据展示脱敏改造，如果不是一个全新从零起步的系统服务，都会面临着对于历史服务的改造，以及保证新上线业务能够遵循已确定的数据安全改造需求。
推动历史存量的改造，会涉及到相应应用服务的改造、历史数据的清洗、接口或流量切换等工作，但也不能忽视针对增量的管控措施，从风险的角度来说，越早发现越早解决，相应风险产生的可能性及影响都会更低，所以在解决历史存量的问题过程中，从事前、事中、事后的角度考虑管控措施，有助于整体数据安全风险的降低。
4.1 数据脱敏改造步骤
4.1.1 脱敏存量改造
考虑到业务模块的复杂性及多样性，在存量改造过程中，需要广泛地获得研发及产品的相应支持，针对对应的业务模块进行统计汇总，确认改造范围，并根据各自业务模块的排期、接口模块的使用热度、业务重要性等多方面维度进行考量，分别管理其项目推进接入计划内容。在多期接入方案完成后，配合产品及研发对其模块进行复盘，确定相应脱敏遗漏情况。
4.1.2 脱敏增量管控
事前阶段：
方案评审过程嵌入数据安全评审项目，明确项目是否存在敏感数据展示；
事中阶段：
针对全局接口的上线过程进行准入控制，在过程中明确相应接口的出参内容是否包含敏感数据字段并进行字段敏感类型定义；
图18：字段敏感定义示意图
事后阶段：
定期通过 API 流量审计系统监控系统服务中敏感数据使用及传输接口的敏感数据脱敏实际情况，并与事中阶段登记的敏感接口列表进行比对，如发现敏感数据接口未进行敏感字段登记、登记有误或者未进行脱敏，则通过内部通知的方式告知应用负责人进行整改工作。
图19：流量系统中的敏感字段展示
4.2 数据加密改造步骤
数据加密改造是一项风险高，周期长的改造工作，需分多阶段多步骤逐步推进相应工作，且需要做到各阶段取得阶段性工作目标后进行相应的核对检查无误后，进入下一阶段，在该过程中，研发、DBA、CI/CD、大数据、安全等多部门需要配合恰当，共同确认和推进相关过程。
4.2.1 加密存量改造
图20：改造工作步骤图
各改造阶段需注意检查项
- 新增加密字段阶段：表结构字段长度和密文长度匹配，防止出现长度不足，同时加密字段需保留原明文字段索引，减少性能影响。
- 数据双写阶段：自增ID需要建立检查机制，如果是原表新增密文字段可不考虑，新建表双写需进行校验。
- 应用服务切换阶段：数据读取逻辑两步进行比对，灰度切换过程中需要进行双边比对，完善打点记录，保证报错后进行排查，制定完善且逐步的灰度切换计划。
- 存量数据加密刷数阶段：存量数据需保证100%刷写密文，防止遗漏。
- 数据库流量监控阶段阶段：作为明文下线前的最后阶段，要在这个阶段内核实是否存在访问流量。
- 明文下线阶段：明文字段应进行灰度置空操作，避免一次性操作，预留灰度观察时间。
4.2.2 加密增量管控
事前阶段：
方案评审过程嵌入数据安全评审项目，明确项目是否存在敏感数据需要进行存储；
事中阶段：
在应用上线环节中，研发在建表过程中定义其新应用服务涉及的敏感数据字段，并通过针对“CREATE TABLE”、“ALTER TABLE table_name ADD COLUM”等语句增加sql审计检测，检测技术标准中敏感参数定义的方式，明确事中环境的敏感数据标识打标准入，并且联动CI/CD过程中的告警触达进行规范的传达；
事后阶段：
定期针对数据库进行增量扫描，对增量数据库字段抽取其样例数据及字段特征，判断其是否存储敏感数据，比对前期登记情况，如因为项目排期问题或者因为事中阶段通知触达遗漏等情况导致未进行存储加密，对未加密的敏感字段，通知业务方进行整改。
图21：定期增量字段扫描
五、总结
数据安全实践是一个长期且艰难的过程，其涉及业务线广泛、实施难度大、流程集成性要求高、改造周期长等多方面的难题，故数据安全改造实践也处于一个长期改进探索调整的过程当中，本文介绍的加密和脱敏只是数据安全实践的其中两个环节，只有不断根据数据安全生命周期添加不同环节对应的安全措施，才能够提升企业整体的数据防护能力，保障用户的数据及隐私安全。
随着数据安全落地实践的进一步深入，数据属于动态资产的概念越发明显，我们加密了数据库，保护了数据展示的过程，是否就能高枕无忧？数据安全的推进工作没有终点，还有很多的实践工作等着我们进一步探索。
六、参考资料
[1].[绿盟科技]，大数据下的隐私攻防02：身份证号+手机号如何脱敏才有效 (https://cloud.tencent.com/developer/article/1636078)
[2].[炼石网络CG]，一文读懂十种数据存储加密技术 (https://www.zhihu.com/people/lian-shi-wang-luo-cg)
[3].JR/T 0197—2020，金融数据安全数据安全分级指南
[4].YD/T 3813-2020，基础电信企业数据分类分级方法
[2].[Eleven_Liu]，利用数据库视图实现WEB查询敏感信息接口动态脱敏 (https://www.cnblogs.com/Eleven-Liu/p/11234324.html)
作者:朱瀛海
来源:微信公众号:微盟技术中心
出处:https://mp.weixin.qq.com/s/7RDGtYHwFexB7P0-hewcOg