下载掌阅APP，畅读海量书库
立即打开
数据安全策略是数据安全的长期目标，数据安全策略的制定需从安全和业务相互平衡的角度出发，满足“守底线、保重点、控影响”的原则，在满足合法合规的基础上，以保护重要业务和数据为目标，同时保证对业务的影响在可控范围之内。
由于数据安全与业务密不可分，数据安全的工作开展不可避免地需要专职安全人员、业务人员、审计、法务等人员组成的团队的参与，在最后的落地实施上，还需要全员配合。无论使用何种数据安全策略，都需要专门的数据安全组织的支持。因此需建立对数据状况熟悉的专责部门来负责数据安全体系的建设工作。数据安全组织建设涉及以下三个方面的内容。
组织架构可参考数据安全能力成熟度模型（DSMM）中的组织架构进行建设，包括决策层、管理层、执行层、监督层和普通员工（图4-1）。
图4-1 组织架构
组织成员需包含业务领域领导、业务领域中负责安全职能的人员、安全负责人、专职安全部门、审计团队、普通员工等。监督层是独立的组织，其成员不建议由其他部门兼任，一般由审计部门担任。监督层需要定期向决策层汇报当前数据安全状况。
权责机制指依据权责对等的原则，为每个岗位角色制定相应的权力和职责描述，明确数据安全治理的责任、岗位人员的技能要求等。
数据安全治理的工作开展应遵循自上而下的原则，即需要在数据安全工作的前期先就总体策略在管理层达成共识，确定数据安全体系的目标、范围、安全事项的管理原则。这也是DSG框架倡导的方式。
传统的信息安全风险评估基本上是围绕信息系统和网络环境开展安全评估工作；而数据安全风险评估则是以数据为核心，通过现场调研和技术评估相结合的方式对数据运行现状开展全面风险评估，了解数据管理制度与实施控制的存在性及有效性，评估分析数据整体的安全风险，将其作为安全体系规划建设的重要参照依据。数据安全风险评估报告至少需包含本组织掌握的重要数据的种类和数量，涵盖收集、存储、加工和使用数据的情况。
数据安全风险评估可以从全局视角、业务场景视角、个人信息数据视角三个维度进行。
根据《信息安全技术 数据安全能力成熟度模型》（GB/T 37988—2019）的要求，对组织的系统、平台、组织等开展数据安全能力成熟度的评估工作，发现数据安全能力方面的短板，了解整体的数据安全风险，明确自身的数据安全管理水平；参照数据安全能力成熟度模型，制定有针对性的数据安全改进方案及整体提升计划，指导组织后期数据安全建设的方向。
从组织全局的角度，以身份认证与数据安全为核心，以数据的全生命周期的阶段作为各个安全过程域，从组织建设、制度与流程、技术与工具、人员能力四个维度对数据安全防护能力进行评估，进而全面了解本单位目前的数据安全管理运行现状。
基于业务场景的数据安全风险评估的做法是，通过调研业务流和数据流，综合分析评估资产信息、威胁信息、脆弱性信息、安全措施信息，最终生成风险状况的评估结果。
为了达成安全性的整体目标，基于业务场景的数据安全风险评估围绕数据相关业务开展详细的风险调研、分析，生成数据风险报告，并基于数据风险报告提出符合单位实际情况并且可落地推进的数据风险治理建议。建立数据采集的风险评估流程主要包括：明确数据采集的风险评估方法，确定评估周期和评估对象，研究和理解相关的法律法规并纳入合规评估要求，例如是否符合《中华人民共和国网络安全法》《中华人民共和国数据安全法》《中华人民共和国个人信息保护法》等国家法律法规及行业规范。
个人信息数据风险评估包括横向和纵向两个维度的评估（横向指同一数据项从采集、传输、存储、处理、交换到销毁的全过程评估，纵向指同一加工节点上针对不同数据类别的措施评估），以及第三方交互风险评估。通过制定针对性管理和技术措施形成个人信息保护规范指引，重点为隐私安全进行管理规划，确定合法合规的具体条例和主管部门，确定数据安全共享方式的细化方案等。个人信息数据风险评估能够在规避数据出境、数据越权使用等风险的同时，最大化地发挥数据价值。
个人信息安全影响评估是个人信息控制者实施风险管理的重要组成部分，旨在发现、处置和持续监控个人信息处理过程中的安全风险。在一般情况下，个人信息控制者必须在收集和处理个人信息前开展个人信息安全影响评估，明确个人信息保护的边界，根据评估结果实施适当的安全控制措施，降低收集和处理个人信息的过程对个人信息主体权益造成的影响；另外，个人信息控制者还需按照要求定期开展个人信息安全影响评估，根据业务现状、威胁环境、法律法规、行业标准要求等情况持续修正个人信息保护边界，调整安全控制措施，使个人信息处理过程处于风险可控的状态。
数据分类分级管理不仅是加强数据交换共享、提升数据资源价值的前提条件，也是数据安全保护的必要条件。《中华人民共和国数据安全法》《科学数据管理办法》《国务院关于印发“十三五”国家信息化规划的通知》等法规和文件对数据分类分级提出了明确要求。
数据分类和数据分级是两个不同的概念。其中，数据分类是指企业、组织的数据按照部门归属、业务属性、行业经验等维度对数据进行类别划分，是个复杂的系统工程。数据分级则是从数据安全、隐私保护和合规的角度对数据的敏感程度进行等级划分。确定统一可执行的规则和方法是数据分类分级实践的第一步，通常以业务流程、数据标准、数据模型等为输入，梳理各业务场景数据资产，识别敏感数据资产分布，厘清数据资产使用的状况。从业务管理、安全要求等多维度设计数据分类分级规则和方法，制定配套的流程机制。同时，完成业务数据分类分级标识，形成分类分级清单，结合数据场景化设计方案，明确不同敏感级别数据的安全管控策略和措施，构建不同业务领域的场景化数据安全管理矩阵，最后输出数据分类分级方法和工作手册等资料，作为数据分类分级工作的实施参考依据。
攻防两方信息不对称是网络安全最大的问题。攻击方只要攻击一个点，而防守方需要防守整个面。
从大量的实践案例来看，很多单位并不清楚自己有多少数据库资产；或者虽然有详细的数据库资产信息记录，但是实际上还有很多信息没有被记录或记录内容与实际情况不相符。
我们无法防护或者感知我们不知道或者无接触的数据库。这些我们看不到的或者无人进行常态化管理的数据库，会产生巨大的风险。因为无接触，所以常规性的安全运维加固就会忽略这些系统、照顾不到这些孤立的数据库，很容易产生很多配置风险，比如直接暴露在外、包含很多已知的漏洞、包含弱口令等。这些风险就容易成为攻击方的突破口，从而产生数据安全事件。
通过数据库服务探测与基线检查工具提供的数据库漏洞检查、配置基线检查、弱口令检查等手段进行数据资产安全评估，通过安全评估能有效发现当前数据库系统的安全问题，对数据库的安全状况进行持续化监控，保持数据库的安全健康状态。
以Oracle为例，Oracle数据库安全基线配置检查如下。
（1）数据库漏洞。
a.授权检测。
b.模拟黑客漏洞发现。
（2）账号安全。
a.删除不必要的账号。
d.限制超级管理员远程登录。
e.开启用户属性控制。
f.开启数据字典访问权限。
g.限制TNS登录IP地址。
（3）密码安全。
a.配置账号密码生存周期。
b.重复密码禁止使用。
c.开启认证控制。
d.开启密码复杂度及更改策略配置。
（4）日志安全。
a.开启数据库审计日志。
（5）通信安全。
a.开启通信加密连接。
b.修改默认服务端口。
总之，数据库服务探测与基线核查的目的是识别风险并降低风险。
第三方安全产品通过以下几个方面来识别风险并降低风险。
（1）通过自动化的工具探测全域数据库服务资产，资产信息包含数据库类型、数据库版本号、数据库IP地址、数据库端口等信息，形成数据库服务资产清单。
（2）通过自动化的工具扫描数据库服务，核查数据库是否存有未修复的漏洞，漏洞风险的级别。基于实际情况，建议采用虚拟补丁的方式对数据库做漏洞防护，防止漏洞被利用。
（3）通过自动化的工具扫描数据库服务，核查数据库是否存在弱口令；如有，需把弱口令修改成符合要求的安全密码。
（4）通过自动化的工具扫描数据库服务，核查数据库配置是否按数据库厂商的要求或最佳实践开启相关安全基线配置，如密码复杂度达标、限制超级管理员远程登录等。
（5）建议对数据库服务开启可信连接配置，业务账号仅允许“业务IP”连接，运维账号仅允许“堡垒机IP”建立连接。
（6）建议按月定期开展安全扫描检查并输出风险评估报告，确保数据库服务的自身环境安全可靠。
可参考如图4-2所示的方式部署扫描工具进行检查。
图4-2 扫描工具部署拓扑图
是否存在一种通用的标准和方法，可以用于设计所有行业的数据安全分类分级模型，并在其基础上定义具体的数据安全分类类目与分级级别？答案是否定的。
大部分行业采用的是五级或四级的分级标准。国内的定级要素主要参考的是数据安全性遭到破坏后可能造成的影响，如可能造成的危害、损失及潜在风险。即影响程度与影响对象是主要的划分依据。
当前，国内已有多个行业发布过数据分类分级指引文件，《证券期货业数据分类分级指引》（JR/T 0158—2018）、《金融数据安全 数据安全分级指南》（JR/T 0197—2020）、《基础电信企业数据分类分级方法》（YD/T 3813—2020）、《信息安全技术 健康医疗数据安全指南》（GB/T 39725—2020）等。
以《金融数据安全 数据安全分级指南》为例，该指南中列举了4种影响对象：国家安全、公众权益、个人隐私、企业合法权益；而在影响程度方面也列举了4种严重程度：严重损害、一般损害、轻微损害、无损害。结合以上两个维度，金融机构数据的安全级别从高到低划分为5级、4级、3级、2级、1级。
在《基础电信企业数据分类分级方法》中，数据分级依据同时考虑数据对象发生安全事件时对国家安全、社会公共利益、企业利益及用户利益的影响程度，并选取重要敏感程度最高的等级。安全级别的划分从高到低为4级、3级、2级、1级。
此外，在《公安大数据处理 数据治理 数据分类分级技术要求》中，更有一些复杂的情形：“敏感级别按照0X～9X进行设置，另外也可以根据需要对每一个级别进一步细化，最多可细化成01～99级，数值越小，敏感级别越高。”
数据安全分类分级是一种根据特定和预定义的标准，对数据资产进行一致性、标准化分类分级，将结构化和非结构化数据都组织到预定义类别中的数据管理过程；也是根据该分类分级实施安全策略的方法。
在数据安全实践的范畴中，分类分级的标识对象通常为“字段”，即数据库表中的各个字段根据其含义的不同会有不同的分类和分级（图4-3）。而在一些情况下则可以适当放宽分类分级的颗粒度，在“数据表”这一级别进行统一分类分级标识即可。
图4-3 字段级别的分类分级结果
在当前的数字化时代，使用大数据技术有助于强化自己的竞争力，在激烈的行业竞争中争取先机，因而很多科技公司都转型成为大数据公司。当数据成为组织最关键的核心资产时，逐渐暴露出数据庞杂这一现实问题。例如，一家企业的数据库系统里可能拥有几亿条、几十亿条，甚至上百亿条数据信息。
（1）风险问题的控制。
在上述背景下，倘若不展开系统性的分类分级工作，我们便不知道拥有什么数据资产及其所处的位置。如果不知道敏感数据存在哪里，也就无法讨论最小化授权、精细化权限管控。而过度授权，引发数据泄露的风险问题将始终难以得到控制。
（2）合规监管的要求。
根据我国相关法律法规的规定，要建立数据分类分级保护制度，对数据实行分类分级保护，加强对重要数据的保护。所有涉及数据处理活动的单位都必须开展敏感数据分类分级工作。
（3）数据保护的前提。
数据安全分类分级是任何数据资产安全和合规程序的重要组成部分，是其他数据安全能力发挥作用的基础条件。进行数据安全分类分级的主要目的是确保敏感数据、关键数据和受到法律保护的数据得到真正的保护，降低发生数据泄露或其他类型网络攻击的可能性。
很显然，完全靠人工的方法是难以有效完成敏感数据梳理的。我们需要借助专业的数据分类分级工具，以高效完成这一任务，从而避免在满足大量数据安全性及合规性需求时力不从心。
敏感数据分类分级建议（图4-4）可以帮助企业有效地开发和落地数据安全分类分级的流程，进而满足企业数据安全、数据隐私及合规性要求。
图4-4 敏感数据分类分级建议
（1）根据目标制订落地计划。
不能盲目地进行数据安全分类分级。在进行之前，需考虑为什么进行数据安全分类分级。分类分级是一个动作而不是目的，分类分级可以无穷无尽地开展下去，所以定好初期的业务需求目标非常关键。是为了安全、合规还是保护隐私？是否需要查找个人身份信息、银行卡号等数据？敏感数据具有很多类型，而且对于多个数据库，确定哪些作为切入点也十分重要。比如：如果企业有一个可能包含许多敏感数据的客户关系管理（Customer Relationship Management，简称CRM）数据库，那么可以此作为切入点。
（2）使用软件工具实现自动化流程。
在以数据为中心的时代，手动进行数据发现和分类分级已不适用。手动方法无法保证准确性和一致性，具有极高的风险，也可能会出现分类分级错漏，而且十分耗时。建议构建一种自动化的数据发现和分类分级解决方案，从而直接从表中搜索数据，以得到更精准的结果。在实践中，数据分类分级工具往往会提供以下三个方面的算法支持：敏感数据识别、模板类目关联、手动梳理辅助。具体技术方面的内容介绍详见6.2节。
（3）持续优化。
数据发现和分类分级并非一次性任务。数据是动态变化的、分布式的和按需处理的；会不断有新的数据和数据源汇入，并且数据会被共享、移动和复制。此外数据也会随着时间的变化而发生改变。如在某个时间点某些数据并不是敏感数据，但是当时间发生变化后可能变为敏感数据。自动化数据分类分级过程需要可重复、可扩展且有一定的时效性。
（4）采取行动。
最重要的便是从现在开始，投入实践。首先强化对重点的敏感数据源和数据进行分类分级；然后实施有效的访问策略，例如脱敏及“网闸”等技术，也可以通过UEBA技术持续监控，发现可疑或异常行为，部署用于保护敏感数据（如保障数据可用不可见）的软件或灵活的加密解决方案等。
对任何企业、任何业务阶段，重视敏感数据的分类分级都是至关重要的。例如企业正在准备将业务迁移至公有云或私有云中，以提高敏捷性和生产力，那么就应注意防御网络攻击风险，并要满足越来越严格的数据安全合规性要求。
因此，对数据安全分类分级的需求比以往任何时候都更加紧迫。
利用分类分级辅助工具，通过人工+自动、标签体系、知识图谱、人工智能识别等技术，对数据进行分类分级。
数据分类是指，把相同属性或特征的数据归集在一起，形成不同的类别，方便通过类别来对数据进行的查询、识别、管理、保护和使用，是数据资产编目、标准化，数据确权、管理，提供数据资产服务的前提条件。例如：行业维度、业务领域维度、数据来源维度、数据共享维度、数据开放维度等，根据这些维度，将具有相同属性或特征的数据按照一定的原则和方法进行归类。
数据分级是指，根据数据的敏感程度和数据遭到篡改、破坏、泄露或非法利用后对受害者的影响程度，按照一定的原则和方法进行定义。数据分级参考数据敏感程度（公开数据、内部数据、秘密数据、机密数据、绝密数据等）或受影响的程度（严重影响、重要影响、轻微影响、无影响等）。
第三方分类分级产品应具备以下能力：数据源发现与管理、敏感数据自动识别、分类分级标注、行业模板配置、自定义规则配置等。分类分级工具部署拓扑图如图4-5所示。
图4-5 分类分级工具部署拓扑图
企业在对自身数据进行分类分级之后，需要基于业务运行需求及分类分级结果对数据库账号进行精细化的权限管控。目前数据权限管控普遍的需求主要有两大类，一类是行级别（row或cell）的管控，一类是字段级别（column）的管控。
对于业务账号来说，原则上需要赋予该账号所需的能保障业务正常运行的最小权限（principle of least privilege），但如何在操作中界定最小权限，实际上存在着种种困难，由于权限直接继承与间接继承的复杂性（参见3.5高权限账号管控较弱），对于如何根据访问行为，发现过度授权行为，还是存在一定难度的。为了解决该问题，Oracle在12c以后的版本中引入了一个新特性：Privilege Analysis。该功能是Oracle database vault的一个模块，其核心原理是通过捕获业务运行时数据库用户实时调用的对象，结合其自身具备的权限来判断该数据库用户是否存在多余的系统或对象权限，并给出相应的优化建议。
由于上述工具内置在Oracle database vault中，无论是购买还是使用均存在较高成本，这不是所有企业都能接受的，但我们可以借鉴其思路，结合数据审计产品，依靠人工进行梳理和总结。
首先，我们需要获取当前用户本身已经具有的权限，再从数据审计中抽取一段时间内的审计日志（比如一周内），数据审计可以针对用户调用的对象、执行的操作进行汇聚统计。通过这些统计，可以发现该用户对数据库对象的操作情况。如user1同时具有对user2下某些对象的select权限，但在一段时间内的数据审计日志中，从未发现user1有查询user2下的表的行为记录，由此我们就可以进一步怀疑，将user2下的对象授权给user1是不是一种过度授权行为。
另外，对于存储过程、函数、触发器等预编译对象，则可以借助于相关视图（如Oracle的ALL_DEPENDENCIES等）来判断这些对象具体引用了哪些表。如果过程、函数、包等未加密，还可展开分析代码，判断引用对象的具体操作，再借助数据审计中业务账号对这些udf、存储过程、package的调用情况来判断是否应该将相应权限赋予该业务账号。
其次，将数据账号权限梳理完成后，我们需要通过数据库自身的权限控制体系（简称权控体系）进行权限的授予（grant）或回收（revoke）。切记权限的操作需要在业务高峰时间段内发起，特别是对于像Oracle、DB2这类有执行计划缓存的数据库。对于字段级别的控制，除了像MySQL等特殊的数据库类型，大多只能通过上层封装视图来实现。另外，通过查看视图源码也可以找到底层的基表与字段，但效果不甚理想。而对于行级别的限制，目前主流数据库依靠自身能力均难以实现。
以上两类需求若要精准实现，通常通过数据库安全网关进行基于字段或返回行数的控制。基于字段的访问控制可结合用户身份与数据分类分级结果，数据库用户基于自身的业务需求及身份类型精细化控制指定表中哪些字段可以访问、哪些字段不能访问。如MySQL的root用户仅能访问业务中二级以下的非敏感数据，二级以上的敏感数据如无权限申请请求，则一律拒绝访问或返回脱敏后的数据。
基于行数的访问控制，主要采用针对SQL请求中返回结果集记录条数的阈值来进行控制。例如，正常情况下一个分页查询只能查500条记录，超过500条以上的返回行数则拒绝访问。行数控制的另外一种使用场景是在数据操作（Data Manipulation Language，简称DML）中，数据库安全网关预先判断删除或升级的影响范围是否会超过指定值，一旦超过则进行阻断。
综上，独立于数据库自身的权控体系以外，使用第三方数据库安全网关的优势在于可支持的数据库类型多，且对业务和数据库自身无感知，数据库本身无须增加额外配置，从而极大地降低权限控制系统的使用门槛。
我们通常会通过部署第三方数据安全网关产品，基于IP地址、客户端工具、数据库用户、数据库服务器等对象，实施细粒度权限管理，实现数据安全访问控制。
数据的特权账号通常属于数据库管理员、CTO及数据仓库开发人员等用户。这些用户会被赋予业务层面的select any table权限账号。对于特权用户的监管是非常重要但同时也是非常困难的。对于系统用户，像Oracle的sys、MySQL的root、SQLServer的sa账号等，在一些特定场景下可以将其禁用来降低安全风险。但在实际运维操作中，终究还是需要一个高权限的账号来做数据库日常的备份、监控等工作，禁用账号的本质只是将账号重新命名，无法解决实际问题。而账号也无法对自身权限进行废除（revoke）。因此，仅依靠数据库自身的能力很难限制特权账号的权限范围，需要借助于类似Oracle VPD之类的安全组件，但这类组件只针对特定数据库的特定版本，并不具备普遍适用性。
另外，RDBMS的特权账号往往存在多人共用一个账号的现象，虽然企业会通过堡垒机、网络层面的ACL等手段来进行限制，但这些限制非常容易被绕开，一旦相关限制策略被绕行，特权账号可以在避开数据库自身监管的情况下进行任意检索，修改数据库中的业务数据、审计记录、事务日志等，甚至是直接删除核心数据。
对于特权账号的管控，首先要做到账号与人的绑定。除特殊场景外，尽量减少sys、root等账号的使用；同时关闭数据库的OS验证，所有账号登录时均需提供密码。对于像Oracle之类的商业数据库，有条件的情况下可以将账号与AD进行绑定，再结合数据库网络访问审计与本地审计能力，保证数据的操作行为可以直接定位到人。MySQL的企业版也提供了ldap模块，能实现类似的功能。对于云上的RDS服务，则需要严格管理控制台的账号，做到专人专号；对于通过数据库协议访问RDS的，建议通过黑、白名单机制来限制从指定的网络、IP地址登录，登录时必须通过数据库安全网关提供七层反向代理IP及端口才能登录RDS数据库。
特权账号在对业务数据访问与修改时，需要结合分类分级的成果，确定访问的黑、白名单。例如指定某一类别中某敏感级别以上的数据，如无审批一律不得访问或修改。利用数据库安全网关对特权账号进行二次权限编排，仅给其职责范围内的权限，如查看执行计划、创建sql plan基线、扩展表空间、创建索引等，对于业务数据的curd操作则一律回收。而对于业务场景，当排错需要查看或修改部分真实数据时，需提交运维申请，申请通过后方可执行。
对于通过申请的特权账号，还可以结合数据库安全网关的返回行数控制+返回值控制+动态数据脱敏（也称动态脱敏）来进行细粒度的限制，只允许该用户查看指定业务表的若干行数据，同时返回结果集中不得包含指定的内容一旦超出设定的范围则立即阻断或告警。同时，利用动态脱敏技术限制该账号访问非授权的字段，在不影响数据存储和业务正常运行的情况下，阻止特权账号查询到真实的敏感数据。
基于数据库自身权限管控的基础上，一般通过提供第三方数据安全网关解决特权用户账号权限过高和精细化细粒度权限管理问题。
在数据库中，数据通常是以明文的形式进行存储。要保证其中敏感数据的存储层的安全，加密无疑是最有效的数据防护方式。数据以密文的形式进行存储，当访问人员通过非授权的方式获取数据时，获取的数据是密文数据。虽然加密算法可能是公开的，但在保证密钥安全的情况下，仍可以有效防止数据被解密获取。数据的加密应使用通过国家密码认证的加密产品完成加密，满足数据安全存储的同时能够满足相关合规要求。
除了保证数据的保密性，还要用其他一些方法来辅助加密的可用性，其中包括权限控制、改造程度和性能影响。
对于密文数据的访问，需要进行权限控制，此时的权限控制应该是独立于数据库本身的增强的权限控制。当密文访问权限未授予时，即使数据库用户拥有对数据的访问权限，也只能获取密文数据，而不能读取明文数据；只有授予了密文访问权限，用户才能正常读取明文数据。
在数据加密时，还要考虑透明性，尤其对于一些已经运行的应用系统，应尽量避免应用系统的改造。因为如果为了实现数据加密需要对应用或数据库进行较大的改造工作，则会加大加密的落实难度，同时修改代码或数据库也可能带来更多问题，影响业务正常使用。
性能也是要着重考虑的事情。数据加密和解密必然带来计算资源消耗，不同的加密方式会有一定差别，但总体来讲与加密/解密的数据量成正比，尤其是数据列级。当数据加密后查询时，全表扫描可能导致全部数据解密后才能获得预期数据结果，而这个过程通常需要很多计算资源和时间，使得业务功能无法正常使用。
当前很多主流的数据库都会提供数据加密功能，如MySQL的5.7.11版本会提供表空间数据加密功能。为实现表空间数据加密，需要先安装keyring_file插件，该插件仅支持5.7.11以上版本，对于具有主数据库/备份数据库、读写分离等的高可用环境，需要对每个节点进行单独部署。首先检查数据库的版本。参考语句：
在数据库服务器上创建和保存keyring的目录，并授予MySQL用户相应权限，如未提供SSH，可手动创建并指定。参考语句：
执行结果如下：
/usr/local/mysql
安装keyring插件：
为keyring插件指定目录：
此目录为默认目录，前一个keyring为需要手动创建的目录，后一个keyring为安装插件后自动生成的密钥文件，生成时文件为空，加密数据表后，将生成密钥。
进行如上配置以后需修改my.cnf，防止重启失效。在my.cnf文件的［mysqld］下添加：
查看插件状态语句参考如下：
执行结果如下：
Plugin_name plugin_status
Keyring_file ACTIVE
如不再需要加密则可卸载该插件。卸载前建议检查是否仍然有密文表未解密，如果直接卸载插件，则可能造成密文表无法解密的情况。查看密文表的语句可参考如下：
在确认后，可参考如下语句卸载插件：
第三方安全产品通过对本地数据实施加密/解密，实现防拖库功能。
（1）业务系统数据传输到数据库中，直接通过加密/解密系统自动加密。
（2）加密后数据以密文的形式存储。
（3）用户层面无感知，在不修改原有数据库应用程序的情况下实现数据存储加密（图4-6）。
图4-6 数据存储加密
在数据分发过程中，因分发对象的安全防护能力不可控，有可能造成数据泄密事件发生，因此需要对数据进行事先处理，通常我们采用将数据脱敏或为数据打水印的方法。
数据脱敏是指，在指定规则下，将原始数据进行去标识化、匿名化处理、变形、修改等技术处理（图4-7）。脱敏后的数据因不再含有敏感信息，或已无法识别或关联到具体敏感数据，故能够分发至各类数据分析、测试场景进行使用。早期的脱敏多为手动编写脚本的方式将敏感数据进行遮蔽或替换处理，而随着业务系统扩张，需要脱敏的数据量逐渐增多，另外，由于数据需求方对脱敏后的数据质量提出了更高的要求，如需要满足统计特征、需要满足格式校验、需要保留数据原有的关联关系等，使得通过脚本脱敏的方式已经无法胜任，从而催生出了专门用作脱敏的工具化产品，以针对不同的使用场景和需求。这里将从以下7个场景展开描述。
图4-7 数据脱敏示意图
场景一：功能或性能测试
随着业务系统对稳定性和可靠性要求逐渐提升，新系统上线前的测试环节也加入了更多细致、针对性较强的测试项，不仅要保障系统在正常状态下稳定运行，还要尽可能保障极端情况下核心关键模块依然能够提供最基础服务；测试目的不仅要测试出异常问题，还需要测试出各个临界值，让技术团队可以事先准备应急响应方案，确保在异常情况下也能够有效控制响应时间。
为了达到此类测试目的，测试环节需要尽量模拟真实的环境，以便观察有效测试结果。因此如果使用脱敏后的数据进行测试，则脱敏后的数据要能保持原有数据特征及关联关系，例如需要脱敏后的数据依然保持身份证号码的格式，能够通过机器格式校验；需要脱敏后的数据不同字段间依然保留脱敏前的关联关系。
场景二：机器学习或统计分析
大数据时代，人工智能技术在各行业遍地开花，企业决策者需要智能BI系统根据海量数据、样本得出分析结果，并以此作为决策依据；在医疗行业中，需要将病患数据交由第三方研究组织进行分析，在保障分析结果的同时不泄露病患隐私信息，这就需要脱敏后的数据依旧满足原始数据的统计特征、分布特征等；手机购物App向个人用户推送的商品广告，也是通过了解用户的使用习惯及历史行为后构造了对应的人物画像，然后进行针对性展示。
这类智能系统在设计、验证或测试中，往往都需要大量的有真实意义或满足特定条件的数据，例如，去除字段内容含义但保留标签类别频次特征；针对数值型数据，根据直方图的数量统计其数据分布情况，并采样重建，确保脱敏后的数据依然保留相近的数据分布特征；要求脱敏后的数据依然保持原数据的趋势特征（图4-8）；要求脱敏后数据依然保留原数据中各字段的关联关系等（图4-9）。脱敏后的数据必须满足这些条件，才能被使用到这类场景中。
图4-8 脱敏前后数据分布统计趋势示意图
图4-9 脱敏前后数据关联关系图
场景三：避免被推导
脱敏后的数据将可能分发至组织外使用，数据已脱离组织管控范围。为有效去标识化和匿名化，脱敏过程应当保证对相同数据分别执行的多次脱敏结果不一致，防止不法分子通过多次获取脱敏后的数据，并根据比对和推理反向推导原始数据。
场景四：多表联合查询
与上一个场景不同，在某些情况下，因使用方式的需要，必须保证相同字段每次脱敏处理后的结果都要保持一致，以便协作时能够进行匹配和校验。这是比较特别的情况，此时将要求脱敏结果的一致性。例如多张数据表需要配合使用，或需要完成关联查询且其中关联字段为敏感数据需要脱敏，此时若脱敏结果不一致，则无法完成关联查询操作。
场景五：不能修改原始数据
数字水印技术是指将事先指定的标记信息（如“XX科技有限公司”）通过算法做成与原始数据相似的数据，替换部分原始数据或插入原始数据中，达到给数据打上特定标记的技术手段。数字水印不同于显性图片水印。数字水印具有隐蔽性高、不易损毁（满足健壮性要求）、可溯源等特性，常见的水印技术有伪行、伪列、最小有效位修改、仿真替换等，根据不同场景，可使用不同的水印技术来满足需求。
在有些场景下，因数据处理的需要，不能对原始数据进行修改，或是敏感级别较低的数据字段，可对外进行公开。此时可添加数字水印。一旦发现泄密或数据被恶意非法使用，可通过水印溯源找到违规操作的单位对其进行追责。伪行（图4-10）、伪列（图4-11）的水印技术，顾名思义是在不修改原始数据的前提下，根据指定条件，额外插入新的行或列，伪装成与原始数据含义相似或相关联的数据。这些新插入的数据即为水印标记，可用作溯源。
图4-10 伪行水印技术示意图
图4-11 伪列水印技术示意图
场景六：溯源成功率要求高，数据可以被打乱重组
在有些情况下，因为环境较为复杂，管控力度相对较弱，为了给数据安全追加一道防护手段，在完成数据脱敏处理后，可另外挑选一些非敏感数据打上数字水印，以确保发生泄密事件时能够有途径进行追溯，此时会要求水印溯源的成功率要尽可能更高。同时由于无法保证获取的数据是分发出去的版本，数据可能已经遭到多次拼接、修改，那么就要求溯源技术能够通过较少的不完整的数据来还原水印信息。脱敏水印技术可仅通过一行数据就还原出完整的水印信息，适合此类需求（图4-12）。
图4-12 仿真替换水印技术示意图
场景七：不修改原始数据业务含义，隐蔽性要求较高
针对不能变更数据业务含义的场景，通常需要保留各字段间的业务关联关系。由于数据在业务环境中的使用不能被影响，因此对水印插入的要求极为苛刻。LSB（Least Significant Bit），即最低有效位算法，又称最小有效位算法。使用该算法可通过在数据末位插入不可见字符如空格，或修改最小精度的数值数据（如将123.02改为123.01）等方法来实现最小限度地修改原始数据并插入数字水印标记（图4-13）。在数据使用过程中，若已做好一些格式修正设置（如去除字符串首末位空格，或数据精度可接受一定的误差），这种水印技术几乎可以做到不影响业务使用。同时由于修改位置比较隐蔽，难以被发现打了水印，一般常被用在C端业务中。
图4-13 最小位修改水印技术示意图
除了应当能够应对不同场景的具体需求，数据脱敏系统还应当具备下列核心功能以满足快速发展的业务需要。
（1）自动化。考虑到需要脱敏的数据量通常为每天万亿字节规模甚至更多，为避免高峰期脱敏影响生产系统性能，脱敏工作往往在半夜执行。出于人性化考虑，脱敏任务需要能够自动执行。管理员只需事先编排好脱敏任务的执行时间，系统将在指定时间自动执行脱敏操作。
（2）支持增量脱敏。针对数据增长较频繁或单位时间增长量较大的系统，脱敏系统还应支持增量脱敏，否则每次全量执行脱敏任务，很有可能导致脱敏的速度跟不上数据增长的速度，最终导致系统无法使用或脱敏失败。
（3）支持引用关系同步。当原数据库表存在引用关系时（如索引），脱敏后应当保留该引用关系，确保表结构不被破坏，不然可能造成数据表在使用过程中异常报错。
（4）支持敏感数据发现及分组。当需要处理的数据量较为庞大时，不可能针对每个字段逐个配置脱敏策略，此时需要将数据字段根据类别分组，针对不同类别字段可批量配置脱敏策略，故脱敏系统能够发现识别的敏感数据字段种类及数量对系统使用体验极为关键。
（5）支持数据源类型。随着越来越多业务SaaS化，脱敏系统不仅需要适配传统关系型数据，也需要支持大数据组件如HIVE、ODPS等；同时，在数据分发的场景中，以文件形式导出的需求也逐渐增多，因此还需要脱敏系统支持常见的文件格式，如csv、xls、xlsx等，并支持FTP、SFTP等文件服务器作为数据源进行添加。
（6）数据安全性。数据脱敏系统为工具，目的是保护敏感数据，降低泄密风险，因此对其自身的系统漏洞、加密传输等安全特性亦有较高的要求。可将数据脱敏系统视作常规业务系统进行漏洞扫描发现，同时尽可能选择已通过安全检测的产品。另外，数据脱敏系统的架构应当满足业务数据不落地的设计要求，应避免在脱敏系统中存储业务数据。
可以通过部署专业的数据脱敏系统来满足日常工作中的脱敏需求。常见的数据脱敏系统能够用主流的关系型数据（Oracle、MySQL、SQLServer等）、大数据组件（Hive、ODPS等）、常用的非结构化文档（xls、csv、txt等）作为数据来源，从其中读取数据并向目标数据源中写入脱敏后的数据；能够自定义脱敏任务并记录为模板，方便重复使用，同时能按需周期性执行脱敏任务，让脱敏任务能避开业务高峰自动执行。另外，为确保数据脱敏系统的工作效率，应当选择支持表级别并行运行的脱敏系统。相较于任务级别并行运行，表级别细粒度更小，脱敏效率提升效果更为明显。
一般的数据脱敏系统多为旁路部署，仅需确保数据脱敏系统与脱敏的源库及目标库网络可达即可（图4-14）。
图4-14 数据脱敏系统部署拓扑图
网络防泄露注重数据内容的安全，依据数据特点及用户泄密场景设置对应规范，保障数据资产的传输和存储安全，最终实现数据泄露防护。该系统采用深度内容识别技术，如自然语言、数字指纹、智能学习、图像识别等，通过统一的安全策略，对网络中流动的数据进行全方位、多层次的分析和保护，对各种违规行为执行监控、阻断等措施，防止企业核心数据以违反安全策略规定的方式流出而泄密，实现对核心数据的保护和管理。
（1）多网络协议的实时解析。支持IPv4和IPv6混合网络环境SMTP、HTTP、HTTPS、FTP、IM等主流协议下的流量捕捉还原和监控，支持非主流协议下的定制开发。
（2）应用内容实时审计。支持主流应用协议的识别，支持几十种基于HTTP的扩展协议的解析，包括但不限于以下邮箱应用传输内容监测，如表4-1所示。
表4-1 邮箱应用传输内容监测
应用内容实时审计还包括但不限于以下应用传输内容监测，如表4-2所示。
表4-2 应用传输内容监测
（1）基于多规则组合及机器学习的敏感数据的实时检测。
①关键字。
根据预先定义的敏感数据关键字，扫描待检测数据，通过是否被命中来判断是否属于敏感数据。
②正则表达式。
敏感数据往往具有一些特征，表现为一些特定字符及这些特定字符的组合，如身份证号码、银行卡号等，它们可以用正则表达式来标记与识别特征，并根据是否符合这个特征来判断数据是否属于敏感数据。
③结构化、非结构化指纹。
支持办公文档、文本、XML、HTML、各类报表数据的非结构化指纹生成，支持对受保护的数据库关键表的结构化指纹生成，形成敏感数据指纹特征库。然后将已识别敏感数据的指纹（结构化指纹、非结构化指纹）与待检测数据指纹进行比对，确认待检测数据是否属于敏感数据。
④数据标识符。
身份证号码、手机号、银行卡号、驾驶证号等数据标示符都是敏感数据的重要特征，这些数据标识符具有特定用处、特定格式、特定校验方式。系统支持多种类型的数据标识符模板，包括身份证号码、银行卡号、驾驶证号、十进制IP地址、十六进制IP地址等。
（2）基于自然语言处理的机器学习和分类。
由于数据分类分级引擎以中文自然语言处理中的切词为基础，通过引入恰当的数学模型和机器学习系统，能够支持基于大数据识别特征，遵守机器学习自动生成的识别规则，实现基于内容识别的、且不依赖于数据自身的标签属性的、海量的、非结构化的、敏感数据发现。
根据应用场景及要求不同，网络防泄露有串行阻断部署和旁路审计部署两种模式。
（1）串行阻断部署。串行阻断部署在物理连接上采用串联方式将系统接入企业网络，实现网络外发敏感内容的实时有效阻断。若流量超过系统处理能力，则需要在客户网络环境中添加分流器，对大流量进行分流，同时增加系统设备，对网络流量进行实时分析处理。图4-15所示为串行阻断部署示意图（不带分流设备）。
图4-15 串行阻断部署示意图（不带分流设备）
（2）旁路部署。旁路部署采用旁路方式将旁路设备接入企业网络，实现网络外发敏感内容的实时有效监测，但不改变现有用户网络的拓扑结构。若流量超过系统处理能力，则需要在用户网络环境中添加分流器，同时增加系统设备。图4-16所示为旁路部署示意图（不带分流设备）。
图4-16 旁路部署示意图（不带分流设备）
随着信息技术的日益发展与国家数字化转型的逐步深入，信息系统已然成为业务工作的重要支撑，其中所使用的数据更是成为核心资产，终端系统成为企业重要数据、商业机密信息等的重要载体。通过桌面终端窃取商业机密、篡改重要数据、攻击应用系统等事件屡见不鲜。
终端防泄露的有效实施既需要考虑人性化的方面也需要关注技术的高效性。基于行为的保护方式，因其与内容无关，管控手段粗放，导致客户体验不佳，因此需要融合以内容安全为抓手，以事中监控为依托，以行为监控为补充的三位一体的终端数据防泄露体系。
（1）终端状态监控。收集并上报终端信息，包括操作系统信息、应用软件信息和硬件信息；实时监控终端状态，包含进程启动情况、CPU使用情况、网络流量、键盘使用情况、鼠标使用情况等，有效监控网络带宽的使用及系统运行状态。
（2）终端行为监控。监控并记录终端的用户行为，实现用户对移动存储介质和共享目录的文件/文件夹的新建、打开、保存、剪切、复制、拖动操作，打印操作，光盘刻录操作；支持U盘插入、拔出操作，CD/DVD插入、弹出操作；支持SD卡插入、拔出操作的实时监测与审计。
（3）终端内容识别防泄露。通过采用文件内容识别技术（详见6.7节），实现终端侧对于文件的使用、传输和存储的有效监控，防止敏感数据通过终端的操作泄露，能够有效进行事中的管控，避免不必要的损失。
系统由管理端与Agent端组成。管理端主要实现策略管理、事件管理、行为管理、组织架构管理及权限管理等功能模块。Agent端配合管理端实施策略下载、事件上传、心跳上传、行为上传、基础监控等功能项，以及权限对接、审批对接两项需要定制开发的功能模块。系统组成如图4-17所示。
图4-17 终端数据防泄露系统
管理端主要负责管理Agent端，其提供一个基于Web的集中式管理界面，用户通过该平台可以进行策略管理、事件管理、行为管理，以及权限管理和组织架构管理。例如，添加、修改、删除Agent端设备，控制相关设备的启停，管理、维护及下发监测策略和白名单，审计、统计、操作H-DLP上报的事件，管理系统账号、对访问系统的各类角色进行定义和权限分配。
Agent端负责管理终端PC及虚拟云环境下的终端用户，负责监控人员的操作行为、设备的状态、人员正在使用中的数据，同时监测和拦截复制到移动存储设备、共享目录的保密数据，对网络打印机的打印内容和光盘刻录内容进行有效甄别，实现终端敏感数据和行为的有效监控。
终端防泄露由管理服务端和客户端两部分组成，采用C/S的部署方式，并提供管理员B/S管理中心，在系统部署时主要分两部分进行。
在服务器区域中部署安装管理服务端程序与数据库服务器，管理员通过管理中心访问管理服务器，可实现策略定制下发、事件日志查看等功能。
客户端则以代理Agent的形式部署安装在用户工作区域各办公电脑当中，客户端负责实现终端的扫描检测、内容识别、外发监控、事件上报等功能。终端部署示意如图4-18所示。
图4-18 终端部署示意图
SQL注入的主要原因是程序对用户输入数据的合法性没有进行正确的判断和处理，导致攻击者可以在程序中事先定义好的SQL语句中添加额外的SQL语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步获取到数据信息，甚至删除用户数据。
针对SQL注入的主要原因，本节将介绍如何避免SQL注入和漏洞。
防范SQL注入需要做到两点：避免动态SQL，避免用户输入参数包含SQL片段影响正常的业务逻辑。针对这两点，可采取以下几种具体实施方案：
①使用参数化语句；
②使用存储过程；
③对用户输入进行过滤；
④对用户输入进行转义。
（1）使用参数化语句。
参数化语句（Prepared Statements），即预编译语句，要求开发者预先定义好SQL语句的结构，指定输入参数，然后在查询时传入具体的数据。例如Java编程语言中使用PreparedStatement实现参数化语句：
参数化语句模板：
使用变量userName保存用户输入的用户名：
将用户输入参数添加到SQL查询中：
上述参数化语句中使用问号‘？’作为占位符，指定输入参数的位置。参数化语句使得攻击者无法篡改SQL语句的查询结构。假设输入参数为“Alice' or '1'='1”，参数化语言将会在数据库中查询字面上完全匹配上述字符串的用户名，而不会对原本的查询逻辑产生影响。
（2）使用存储过程。
数据库存储过程允许开发者以参数化形式执行SQL语句。和参数化语句的区别在于，存储过程的SQL代码保存在数据库中，以接口形式被程序调用。例如Java编程语言中使用CallableStatement调用数据库存储过程：
其中proc_getBalance为预定义的存储过程。
需要注意的是，存储过程并非绝对安全，因为某些情况下存储过程的定义阶段可能存在SQL注入的风险。如果存储过程的定义语句涉及用户输入，则必须采用其他机制（如字符过滤、转义）保证用户输入是安全的。
（3）对用户输入进行过滤。
过滤可以分成两类：白名单过滤和黑名单过滤。
白名单过滤旨在保证符合输入满足期望的类型、字符长度、数据大小、数字或字母范围及其他格式要求。最常用的方式是使用正则表达式来验证数据。例如验证用户密码，要求以字母开头，长度在6～18之间，只能包含字符、数字和下画线，满足条件的正则表达式为：‘^［a-zA-Z］\w｛5，17｝$’。
黑名单过滤旨在拒绝已知的不良输入内容，例如在用户名或密码字段出现SELECT、INSERT、UPDATE、DELETE、DROP等SQL关键字都属于不良输入。
白名单和黑名单需要相互补充。一方面，当难以确定所有可能的输入情况时，白名单规则实现起来可能会较为复杂；另一方面，潜在的恶意输入内容往往很多，黑名单也难以穷尽所有可能，当黑名单很长时会影响执行效率，而且黑名单需要及时更新，增加了维护的难度。需要根据业务场景选择合适的过滤策略。
（4）对用户输入进行转义。
在把用户输入合并到SQL语句之前对其转义，也可以有效阻止一些SQL注入。转义方式对于不同类型的数据库管理系统可能会有所差异，每一种数据库都支持一到多种字符转义机制。例如，Oracle数据库中单引号作为字符串数据结束的标识，如果它出现在用户输入参数中，并且以动态拼接的方式生成SQL语句，则可能会导致原本的SQL结构发生改变。因此可以用两个单引号来替换用户输入中的单个单引号，即在Java代码中使用。
这样一来，即使用户输入“Alice'or'1'='1”转换成“Alice''or''1''=''1”，其中成对出现的引号也不会对SQL语句的其他部分造成影响。
通过第三方安全产品进行防护，主要从用户输入检查、SQL语句分析、返回检查审核等方面进行。
（1）安装部署Web应用防火墙。Web应用防火墙是部署在应用程序之前的一道防护，检测的范围主要是Web应用的输入点，用以分析用户在页面上的各类输入是否存在问题，可以检查用户的输入是否存在敏感词等安全风险，是防范SQL注入的第一道防线。
（2）安装部署数据库防火墙。数据库防火墙是部署在应用程序和数据库服务器之间的一道防护，主要检测的内容是将前端用户输入的数据与应用中SQL模板拼接而成的完整SQL语句，同时还可以检测任何针对数据库的SQL语句，包括Web应用的注入点，数据库本身的注入漏洞等。数据库防火墙的防护主要通过用户输入敏感词检测、SQL执行返回内容检测、SQL语句关联检测进行，是防范SQL注入的第二道防线。
（3）安装部署数据审计系统结合大数据分析平台。数据审计和大数据分析是部署在数据库服务器之后的一道防护，主要目的是审计和分析已经执行过的SQL语句是否存在注入风险。首先，数据审计系统会将所有与数据库的连接和相关SQL操作都完整地记录下来，如Web应用程序执行的SQL的查询、更新、删除等各类请求；然后，通过大数据分析平台，结合AI分析挖掘算法分析用户或应用系统单条SQL请求或一段时间内的所有SQL行为，发现疑似的SQL注入行为。是防范SQL注入的第三道防线。如图4-19展示了安装数据审计系统和大数据分析中心的建议部署图。
图4-19 防范SQL注入部署建议
对于数据库系统来说，要想始终保持系统时刻运行在最佳状态，必要的补丁和更新是必不可少的。所有数据库均有一个软件的生命周期，以Oracle为例，技术支持主要分为标准支持（Primer Support）与扩展支持（Extend Support）。原则上一旦超过了图4-20所示的付费扩展支持（Paid Extended Support）时间，便不再提供任何支持。Oracle与MySQL的生命周期如图4-20和图4-21所示。
图4-20 Oracle各版本支持时间线
图4-21 MySQL各版本支持时间线
对于目前还在使用诸如Oracle 11.2.0.4及MySQL5.6.x等较早期版本的用户，建议尽快升级到最新版本。及时升级数据库不仅可以让用户避免一系列的数据安全威胁，还能体验到新版本的新特性。比如MySQL 8.0以后支持hash join，提升了在大结果集下多表join的性能；另外也提供了一系列分析函数，提升了开发效率。Oracle 12c以后的flex ASM与多租户功能极大节约了用户构建数据库的成本；提供了基于分区的分片（sharding）支持，扩展了海量数据下的数据检索能力。
通常，用户对于数据库补丁更新与大版本升级的主要顾虑在于：第一，可能需要停机，影响业务正常运行；第二，升级中存在一定风险，可能导致升级失败或宕机；第三，跨度较大的升级往往会导致SQL执行计划异常，进而导致性能下降；第四，新版本往往对现有组件不支持，如MySQL升级到8.0.22之后，由于redo格式发生变化，导致当时的xtrabackup无法进行物理备份。
为了解决以上问题，数据库也提供了相应的措施进行保障，如Oracle 11.2.0.4以后大多数psu可以在线升级，或者可以借助于rac、dataguard进行滚动升级。而MySQL因为没有补丁的概念，需要直接升级basedir到指定版本，该升级同样可利用MySQL的主/从复制进行滚动升级，即：先对从数据库升级并进行验证；即便升级中遇到问题，也不会对主数据库造成影响。Oracle提供了性能优化分析器（SQL Performance Analyzer，简称SPA）功能，可以直接dump share pool中正在执行的SQL，导入目标版本的数据库实例中进行针对性优化，基于代价的优化方式（Cost-Based Optimization，简称CBO）会基于版本特性自动适配当前版本中的新特性，自动对SQL进行调整优化，同时给出性能对比；当业务迁移完成后会自动适配优化后的SQL及执行计划，极大地降低了开发人员及数据库管理员的工作量。相比之下MySQL就无法提供此类功能了，建议在测试环境中妥善测试后再进行升级。对于MySQL 8.0之前的版本，应升级到MySQL 8.0以上。老版本MySQL不提供严格的SQL语法校验，特别是对于MySQL 5.6之前的版本，sql_mode默认为非严格，可能存在大量的脏数据、不规范SQL和使用关键字命名的对象，将导致升级后此类对象失效或SQL无法使用的情况，因此升级之前一定要做好SQL审核及对象命名规范审核。
此外还可借助于第三方数据库网关类的产品。此类产品大多都具备虚拟补丁的能力。虚拟补丁是指安全厂商在分析了数据库安全漏洞及针对该安全漏洞的攻击行为后提取相关特征形成攻击指纹，对于所有访问数据库的会话和SQL，如果具备该指纹就进行拦截或告警。
以下用两个影响较大的安全漏洞来阐述数据库防火墙虚拟补丁的实现思路及应用。
（1）Oracle利用with as字句方式提权。涉及版本Oracle 11.2.0.x～12.1.0.x，该漏洞借助with as语句的特性，可以让用户绕开权控体系，对只拥有select权限的表可以进行dml操作。
解决该安全漏洞的最有效手段是打上相关的CPU或PSU，需要购买Oracle服务后通过MOS账号下载相应的补丁。升级数据库补丁也存在一定风险，因此很多企业不愿冒险升级。而通过数据库网关就可以有效地阻止该安全漏洞，在针对该漏洞的虚拟补丁没有出来之前，可在数据库网关上配置相应访问控制策略，仅允许foo用户查询bar.tab_bar，其他一律拒绝。由于网关的访问控制规则是与数据库自身的权控体系剥离的，同时网关自身具备语法解析的能力，也不依赖数据库的优化器生成访问对象，因此无法被with as子句绕开，在数据库没有相关补丁的情况下就可以很好地解决该问题。而在用户充分利用数据库网关配置细粒度访问控制的情况下，该问题甚至根本不会出现。
（2）sha256_password认证长密码拒绝式攻击，参见图4-22～图4-24。该漏洞源于MySQL sha256_password认证插件，该插件没有对认证密码的长度进行限制，而直接传给my_crypt_genhash（）用SHA256对密码加密求哈希值。该计算过程需要大量的CPU计算，如果传递一个很长的密码，则会导致CPU耗尽。
图4-22 root用户本地验证，用户创建中
图4-23 远程通过其他用户访问数据库无响应
图4-24 会话
通过数据库网关阻止该攻击的办法也很简单，只要针对create user、alter user等操作限制SQL长度即可；也可以直接启用相关漏洞的虚拟补丁。
通过上述两个案例我们可以发现，对于数据库的各种攻击或越权访问，我们只要分析其行为特征，然后在数据库网关上配置规则，对符合相应特征的数据访问行为进行限制，就可以实现数据库补丁的功能。同时，还可借助第三方组件将数据库的授权从数据库原有的权控体系中剥离出来。
使用数据库安全网关，通过对访问流量安全分析，给数据库打上“虚拟补丁”。通过对攻击者对数据库漏洞利用行为的检测，并结合产品的安全规则，实现数据库的防护（图4-25）。
图4-25 数据库安全网关虚拟补丁防护能力
API安全风险主要体现在其所面临的外部威胁和内部脆弱性之间的矛盾。除了要求接口开发人员遵循安全流程来执行功能开发以减轻内部脆弱性问题，还应该通过收缩API的暴露面来降低外部威胁带来的安全隐患。
在收缩API风险暴露面的同时，也需要考虑到API“开放共享”的基础属性。在支撑业务良好开展的前提下，统一为API提供访问身份认证、权限控制、访问监控、数据脱敏、流量管控、流量加密等机制，阻止大部分的潜在攻击流量，使其无法到达真正的API服务侧，并对API访问进行全程监控，保障API的安全调用及访问可视（图4-26）。
图4-26 API数据共享安全机制
（1）身份认证机制。
身份认证机制为API服务提供统一叠加的安全认证能力。API服务开发者无须关注接口认证问题，只需兼容现有API服务的认证机制，对外部应用系统提供统一的认证方式，实现应用接入标准的统一。
（2）授权。
通过部署API安全网关，实现API访问权限的统一管理和鉴别能力。在完成API资产的发现、梳理、注册后，安全团队可启用API访问权限管控策略，为不同的访问主体指定允许访问的API接口。API安全网关在接收到访问请求后，将先与统一控制台联动，确认调用方（用户、应用）的访问权限，然后仅将符合鉴权结果的访问请求转发到真实的API服务处，从而拦截所有未授权访问，防止越权风险。在统一控制台的权限策略发生变化时，API安全网关实时做出调整，切断权限外的会话连接。
（3）审计。
确保所有的操作都被记录，以便溯源和稽核。应具备对API返回数据中包含的敏感信息进行监控的能力，为调用方发起的所有访问请求形成日志记录，记录包括但不限于调用方（用户、应用）身份、IP地址、访问接口、时间、返回字段等信息。对API返回数据中的字段名、字段值进行自动分析，从而发现字段中包含的潜在敏感信息并标记，帮助安全团队掌握潜在敏感接口分布情况。
（4）流量管控。
为了防止用户请求淹没API，需要对API访问请求实施流量管控。根据预设阈值，对单位时间内的API请求总数、访问者API连接数，以及API访问请求内容大小、访问时段等进行检查，进而拒绝或延迟转发超出阈值的请求。当瞬时API访问请求超出阈值时不会导致服务出现大面积错误，使服务的负载能力控制在理想范围内，保障服务稳定。
（5）加密。
确保出入API的数据都是私密的，为所有API访问提供业务流量加密能力。无论API服务本身是否支持安全的传输机制，都可以通过API安全网关实现API请求的安全传输，从而有效抵御通信通道上可能会存在的窃取、劫持、篡改等风险，保障通道安全。
（6）脱敏。
通过脱敏保证即使发生数据暴露，也不会造成隐私信息泄露。统一的接口数据脱敏，基于自动发现确认潜在敏感字段，安全团队核实敏感字段类型并下发脱敏假名、遮盖等不同的脱敏策略，满足不同场景下的脱敏需求，防止敏感数据泄露导致的数据安全风险。
使用第三方安全产品进行防护，是通过部署API接口安全管控系统为面向公众的受控API服务统一提供身份认证、权限控制、访问审计、监控溯源等安全能力，降低安全风险，在现有API无改造的情况下，建立安全机制。一是健全账号认证机制和授权机制，二是实时监控API账号登录异常情况，三是执行敏感数据保护策略，四是通过收窄接口暴露面建立接口防爬虫防泄露保护机制。一方面可以确保数据调用方为真实用户而非网络爬虫，另一方面可以保证用户访问记录可追溯。
登录异常行为监控：帮助企业建立API异常登录实时监控机制，监测异常访问情况，可对接口返回超时、错误超限等进行分析，发现异常情况及时预警。
敏感数据保护策略：帮助企业对开放API涉及的敏感数据进行梳理，在分类分级后按照相应策略进行脱敏展示，所有敏感数据脱敏均在后端完成，杜绝前端脱敏。此外，敏感数据通过加密通道进行传输，防止传输过程中的数据泄露（图4-27）。
图4-27 API接口安全管控系统部署示意图
一名合格的数据库管理员的主要职责之一就是，当遇到硬件或软件的灾难性故障时，能够在用户可接受的时间范围内及时恢复数据，同时保证已提交的数据不丢失。数据库管理员应该评估自身的准备工作是否到位，是否能够应对未来可能发生的上述灾难性故障。具体包括：数据库管理员对成功备份组织业务所依赖的数据，同时在允许的时间窗口内从这些备份中恢复数据有多大信心？是否能满足既定灾难恢复计划中指定的服务水平协议（Service Level Agreement，简称SLA）或恢复时间目标？数据库管理员是否已采取措施制订和测试备份恢复计划，以保护数据库可以从多种类型的故障中恢复？
为了达成上述目标，我们提供一个如下的检查清单供读者参考。
（1）是否有一个综合的备份计划。
（2）执行有效的备份管理。
（3）定期做恢复演练。
（4）与各个业务线负责人讨论，定制一套可接受的SLA。
（5）起草编写一份《灾难恢复应急预案》。
（6）时刻保持知识更新，掌握最新的数据备份恢复技术。
一份有效的备份计划，除了数据库系统本身的备份，还应关心数据库部署的操作系统、调用数据库的应用及中间件。
需要一并纳入备份计划的有以下内容。
（1）完整的操作系统备份。该备份主要用于数据库所部属主机故障或崩溃时的快速恢复。操作系统核心配置文件如系统路由表用户文件、系统参数配置等，在变更时都需要做好备份，用于异常时的回退。
（2）数据库软件。在任何CPU、PSU升级前都应当对数据库软件本身做好备份。
（3）数据库适配的相关软件、中间件。例如Oracle E-Business Suite、Oracle Application Server and Oracle Enterprise Manager（OEM）等。
（4）密码。所有特权账号、业务账号的密码都应当单独备份一份，备份可以通过在数据库中单独维护一个用户表，或者借助其他密码管理工具来实现。
选择一种适合业务系统的备份类型或方式，根据不同的业务场景或需求选择做逻辑备份或物理备份。
对于海量数据，在Oracle下可以选择开启多通道并行备份，同时开启块追踪（block trace）来加速增量备份。可以通过MySQL 5.7以后的新特性mysqlpump来实现多线程并行逻辑备份或使用xtrabackup实现并行备份（--parallel）。常见的大数据平台如Hadoop分布式文件系统由于实际生产环境中基本都有三份以上的冗余，因此通常情况下不需要对数据进行备份，而是备份namenode下的fsimage、editlog等。
制订一个合理的备份计划。备份的时间应当以不影响业务运行为首要原则，根据自身情况如数据量、数据每日增量、存储介质等制订备份计划。备份计划的核心目的是尽可能减少平均修复时间（Mean Time To Repair，简称MTTR），增量备份根据自身情况选择差异增量（differential）还是累积增量（incremental）。
选择合适的备份存储介质。如果用户本身的数据库为Oracle rac 11.2.0.1以上版本，建议直接将备份存储在ASM中。对于有条件的用户，建议在磁盘备份的基础之上再对备份多增加一份复制，冗余备份可存储在磁带或NAS上。
制定合理的备份保留策略，根据业务需求，备份一般保留7天至30天。
在制订了一套有效的执行计划之后，数据库管理员应当妥善管理这些备份，此时需要关注以下几点。
（1）自动备份。通过crontab或Windows计划任务自动执行备份，备份脚本中应当有完整的备份过程日志，有条件的用户建议用TSM、NBU等备份管理软件来管理备份集。
（2）监控备份过程。在备份脚本中添加监控，如备份失败可通过邮件、短信等方式进行告警。同时，做好备份介质的可用存储空间监控。
（3）管理备份日志。管理好备份过程日志，用于备份失败时的异常分析，对于Oracle数据库可以借助rman及内置相关数据字典来监控、维护备份，多实例的情况下可以搭建catalog server来统一管理所有备份。对于像MySQL等开源数据库，可在一个指定实例中创建备份维护表来模拟catalog server，实现对备份情况的管理与追踪。
（4）过期备份处理。根据备份保留策略处理过期备份，Oracle可通过rman的“delete obsolete”自动删除过期备份集；而对于MySQL，需要数据库管理员具备一定的shell脚本或Python开发能力，根据备份计划和保留策略，基于全备和增量的时间删除过期备份。
对于数据库系统来说，可能发生很多意外，但唯一不能发生的就是备份无法使用。保障数据备份的有效性、备份介质的可靠性、备份策略的有效性，以及确认随着数据量的增长、业务复杂度的上升，现在的备份能否满足既定的SLA，都需要定期做备份恢复测试。
恢复测试基于不同的目的，可以在不同的环境下进行。如本地恢复、异地恢复，全量恢复，或者恢复到某一指定的时间点。
数据库管理团队应当起草一份备份和恢复的SLA，其中包含备份内容、备份过程及恢复的时间线，与业务部门商讨敲定后让组织的管理层签字确认。SLA并不能直接提升恢复能力，而是设定业务（或管理层）对于恢复时间窗口的期望。数据库管理团队在这一期望值下尽可能朝着该值去努力，在发生故障时将损失降到最低。
根据自身情况及相关政策要求，制定异地灾备方案。有条件的用户可选两地三中心的灾备方案，在遇到一些突发或人力不可抗的意外情况后，能够及时恢复业务系统，保证生产稼动率。
作为一名合格的数据库管理员，必须时刻保持学习状态，与时俱进，实时掌握所运维数据库新版本的动态、对于备份恢复方面有哪些提升或改进、采用了什么新技术。在遇到问题恢复时，根本没时间现场调研有哪些新技术可以帮助你进行数据恢复。特别是对于使用非原生备份软件的企业，在数据进行大的升级前一定要了解升级后所用的备份软件是否存在兼容性问题。如Oracle 21c在刚推出之时，市面上主流的备份软件通过sys用户连接均存在问题，进而导致有一段时间备份只能通过维护rman脚本的方式来实现。
为防止系统出现操作失误或系统故障导致数据丢失，通过数据备份系统将全部或部分数据借助异地灾备机制同步到备份系统中（图4-28）。
图4-28 数据备份网络拓扑图
监控整个组织中的数据访问是追查取证的重要手段，实时感知数据的操作行为很有必要。无法监视数据操作的合规性异常，无法收集数据活动的审计详细信息，将导致在数据泄露后无法进行溯源分析，这在许多层面上都构成了严重的组织风险。异常的数据治理行为（例如非法执行数据查询脚本）会导致隐私泄露。如果没有分析审计手段，当异常行为发生时系统不能及时告警，那么异常行为发生后也无法追查取证。
发生重大敏感数据泄露事件后，必须要进行全面的事件还原和严肃的追责处理。但往往由于数据访问者较多，泄密途径不确定，导致定责模糊、取证困难，最后追溯行动不了了之。数据泄露溯源能力的缺乏极可能导致二次泄露事件的发生。
数据安全审计通过对双向数据包的解析、识别及还原，不仅对数据操作请求进行实时审计，而且还可对数据库系统返回结果进行完整的还原和审计，包括SQL报文、数据命令执行时长、执行的结果集、客户端工具信息、客户端IP地址、服务端端口、数据库账号、客户端IP地址、执行状态、数据类型、报文长度等内容。数据安全审计将访问数据库报文中的信息格式化解析出来，针对不同的数据库需要使用不同的方式进行解析，包括大数据组件、国产数据库及关系型数据库等，满足合规要求，解决数据安全需求的“5W1H”问题（见表4-3）。
表4-3 数据安全需求分析表
通过分析数据高危操作，如删表、删库、建表、更新、加密等行为，并通过用户活动行为提取用户行为特征，如登录、退出等，在这些特征的基础上，构建登录检测动态基准线、遍历行为动态基准线、数据操作行为动态基准线等。
利用这些动态基准线，可实现对撞库、遍历数据表、加密数据表字段、异常建表、异常删表及潜伏性恶意行为等多种异常行为的分析和检测，将这些行为基于用户和实体关联，最终发现攻击者和受影响的数据库，并提供数据操作类型、行数、高危动作详情等溯源和取证信息，辅助企业及时发现问题，阻断攻击。
通过部署第三方安全产品，如数据库审计系统（图4-29），可提供以下数据安全防护能力。
（1）基于对数据库传输协议的深度解析，提供对全量数据库访问行为的实时审计能力，让数据库的访问行为可见、可查、可溯源。
（2）有效识别数据库访问行为中的可疑行为、恶意攻击行为、违规访问行为等，并实时触发告警，及时通知数据安全管理人员调整数据访问权限，进而达到安全保护的目的。
（3）监控每个数据库系统回应请求的响应时间，直观地查看每个数据库系统的整体运行情况，为数据库系统的性能调整优化提供有效的数据支撑。
图4-29 全量访问审计部署拓扑
敏感数据溯源对数据生命周期过程中敏感数据的采集、查询、修改、删除、共享等相关操作进行跟踪，通过留存敏感数据流动记录等方式，确保敏感数据相关操作行为可追溯。敏感数据溯源与数据水印的主要区别在于，敏感数据溯源不会改变数据的完整性，因此，对于数据质量没有影响，能够适应更多需要溯源的业务场景。
敏感数据溯源实践场景举例如下。
场景一
某金融机构对高净值客户的个人敏感信息数据进行了高级别的访问防护。此类特殊客户的个人身份及财产信息一经被访问，就产生了访问记录，并且，设定访问频率、单次获取数据量的报警阈值。管理员可将重点客户的身份证号码、姓名等信息作为输入，溯源到相关数据被访问的时间点、访问的应用、IP地址等信息。
要实现场景一，需要对数据访问的双向流量进行解析，针对敏感数据的请求、返回值要能做记录。一个能快速部署，并且能较好实现场景一需求的系统组成和部署方式如图4-30所示。
图4-30 数据溯源系统组成和部署方式
系统主要部件由业务流量探针、数据库流量探针、数据溯源引擎组成。
业务流量探针解析API内容包括：API地址（ID）、访问源、行为、参数（数据）、返回（数据）、实体（IT资产）。
数据库流量探针解析数据库访问内容包括：访问源、行为（SQL）、参数（数据）、对象、返回（数据）、实体（IT资产）。
数据溯源引擎：以数据为核心，通过参数（具备唯一性的数据）、行为、时间等，建立访问源、对象、实体（IT资产）之间的关联关系；将敏感数据的流向及以数据为中心建立的关联关系进行可视化展现。
溯源效果如图4-31所示。
图4-31 场景一的溯源效果示意图
客户能清楚地看到数据流向，如数据在什么时间，通过什么方式流经哪些节点，以及其他详细信息。建立敏感数据的访问路径，客户能快速通过不同路径去排查数据泄露风险及取证。同时，通过对敏感数据路径的日常监控，能够更早地发现敏感数据访问异常，与其他监控和防护手段相结合，实现对敏感数据的长效监控。
场景二
企业发现自己内部的最新商业机密文件被竞争对手窃取。在部署过数据防泄露产品的情况下，该文件的所有传播节点都有记录。管理员可上传泄露的机密文件，进行溯源查询，得到该文件传播的路径、时间点，以及涉及的终端设备。
要实现场景二，需要在网络出口处部署网络防泄露产品，审计在网络上流经的各种文件，并且在终端部署防泄露产品，审计终端上的各种文件操作和流转情况。数据溯源引擎将网络上和终端上的审计记录与上传的机密文件进行关联，然后将机密文件的流向进行可视化展现。溯源效果如图4-32所示。
图4-32 场景二的溯源效果示意图
当前，各类用户通过在不同的数据安全场景部署各种有针对性的安全产品解决相应场景的数据安全问题。例如：在测试开发场景通过部署静态数据脱敏（也称静态脱敏）解决数据共享造成的隐私泄露问题；在运维环境部署数据安全运维类系统解决运维过程中的风险操作、误操作等问题；在业务侧通过部署数据库防火墙解决对外的数据库漏洞攻击、SQL注入问题等。在不同的数据使用场景中，数据安全产品各自为战，往往容易造成安全孤岛。因此，急需一套整合不同使用场景的数据安全防护、集中呈现数据安全态势、提供统一数据安全运营和监管能力的数据安全集中管理平台，实现各类安全数据的集中采集，可视化地集中呈现资产详情、风险分布、安全态势等，便于进行不同安全设备的集中管理、安全策略的动态调整、下发，以及实现日志、风险、事件的统一运营管理、集中分析。
在Gartner公司发布的《2022 Strategic Roadmap for Data Security》中将数据安全平台（Data Security Platforms，简称DSP）定义为以数据安全为中心的产品和服务，旨在跨数据类型、存储孤岛和生态系统集成数据的独特保护需求。DSP涵盖了各种场景下的数据安全保护需求。DSP是以数据安全为核心的保护方案，以数据发现和数据分类分级为基础，混合了多种技术来实现数据安全防护。例如：数据访问控制，数据脱敏，文件加密等。成熟的DSP也可能包含数据活动监控和数据风险评估的功能。
数据安全市场目前的特点是各业务厂商将其现有的产品功能集成到DSP中。常见的数据安全能力包括：数据发现、数据脱敏、数据标识、数据分类分级、云上数据活动监控、数据加密等。以前孤立的安全防护产品在一个共同的平台工具中结合起来，使DSP成为数据安全建设的关键节点。
图4-33展示了自2009年以来数据安全能力的演变，深色区域内的这些安全能力是目前一些DSP所具备的，与此同时，DSP也在不断发展，缩小安全能力差距并精细化数据安全策略。其中DAM代表数据活动监控、DbSec代表数据安全、DAG代表数据访问治理、DLP代表数据泄露防护、Data Masking代表数据脱敏、Tokenization代表标识化、Data Discovery代表数据发现、Data Risk Analytics代表数据风险分析。
DSP是从运营的角度进行产品化，以产品即服务的形式存在。DSP从最开始的数据活动监控演变为目前的数据安全生态体系，未来DSP要集成的安全能力会更多。通过安全平台+单个安全能力单元做联动联防管理，能够集成更多的数据安全能力，从而实现数据安全持续运营的目标。
图4-33 数据安全能力的演变
Gartner对DSP未来状态有更详细的描绘。DSP处于中心位置，“DSP数据安全平台”部分概述了这些安全技术的范围、它们在数据安全治理方面发挥的作用，以及所使用的最佳实践（图4-34）。未来的数据安全建设必然是从孤立的数据安全产品过渡到数据安全平台，促进数据的业务利用率和价值，从而实现更简单、端到端的数据安全。DSP产品能够实现这种功能整合。
图4-34 数据安全平台占据整体数据安全建设的中心位置
典型的数据安全管理平台的整体系统架构如图4-35所示。
图4-35 数据安全管理平台的整体系统架构
针对数据采集、传输、存储、处理、交换和销毁等环节，数据安全管理平台通过数据采集接口对各安全组件数据进行统一汇总、去重清洗、集中统计展示，同时利用UEBA学习、行为分析、数据建模、关联分析等方法对网络环境中的数据资产和数据使用情况进行统一分析，并对数据风险操作、攻击行为、安全事件、异常行为和未知威胁进行发现和实时告警，提供对采集到的审计日志、风险日志、事件日志信息数据的关联分析、安全态势的可视化展现等，实现数据可见、风险可感、事件可控和数据的集体智治。
数据安全管理平台将贯穿数据安全管理中的数据采集、应用防护、数据分发、运维管控、运营处置、合规检查等各场景，实现策略统一下发、态势集中展示、事件集中处理，为客户持续创造价值。
数据安全管理平台帮助用户实现对数据的统一管理。通过数据地图呈现能力，方便探索数据安全问题根源，增强用户业务洞察力；可以非常直观地查看数据资产分布、敏感表、敏感字段数量统计、涉敏访问源、访问量等，监控不同区域、业务的数据访问流向和访问热度，清楚洞察数据的静态分布和动态的访问情况。数据可见支持集中统一展示如下信息。
（1）数据资产分布。
对多源异构数据存在形式形成统一的数据资源目录，并且能够完成自动化内容识别，生成数据保护对象清单，充分掌握重要数据、个人数据、敏感数据的分布情况，并对不同等级的数据资源采取相应的安全防护措施。
（2）敏感数据分布。
梳理现网环境各业务系统后台数据库中存在的敏感表、敏感字段，统计敏感表、敏感字段数量、总量，标记数据的业务属性信息和数据部门归属等特性并展示详情。
（3）分类分级结果展示。
支持表列分布，分类结果、安全级别及分布等情况详情展示，方便数据拥有者了解敏感数据资产的分布情况。分类分级结果可与平台数据防护能力进行对接，一键生成敏感数据的细粒度访问控制规则、数据脱敏规则等，从而实现对数据全流程管理。
（4）数据访问流向记录。
记录数据动态访问详情，统计业务数据访问源，还原以网络访问、API、应用系统、数据库、账户行为等多层次的资产全方位视角，构建数据资产全生命周期内外部数据流转链路，为数据安全风险感知和治理监管提供可视化支撑。从源头上追踪、分析数据访问流向情况，方便溯源管理。
（5）数据访问热度展示。
提供数据访问热度分析能力，洞察访问流量较大、敏感级别较高的业务系统并实施重点监控、防护。结合静态数据资产梳理和动态数据访问热度统计，找出网络环境中的静默资产、废弃资产等，协助资产管理部门合理利用现有网络资源。
数据安全管理平台以数据源为起点，提供统一的数据标准、接口标准，从数据运行环境开始，关注数据生产、应用、共享开放、感知与管理等多个区域不同维度的安全风险，从数据面临的漏洞攻击、SQL注入、批量导出、批量篡改、未脱敏共享使用、API安全、访问身份未知等多角度审视数据资产的整体安全防护状态，打破信息孤岛，形成完整的风险感知、风险处置闭环。同时，平台提供基于用户视角的、对潜在威胁行为进行有效分析和呈现的能力，对于网络中活跃的各类用户及其行为进行精准监控与分析，结合UEBA技术，通过多种统计及机器学习算法建立用户行为模式，当数据攻击行为与合法用户出现不同时进行判定并预警。
数据安全管理平台支持对发现的数据安全事件进行统一呈现和处置能力，包括安全事件采集、安全事件通报、安全事件处置。通过多维度智能分析对已发现的安全事件进行溯源，追踪风险事件的风险源、发生时间和事件发生的整个过程，为采取有效的事件处置、后续改进防范措施提供科学决策依据。
平台根据安全基线和风险模型实时监控全资产运行和使用情况，并支持多种即时告警措施。当触发安全事件时，平台第一时间提供事件告警并告知事件危害程度，辅助安全管理人员、数据管理人员及时对异常事件信息做出反馈与决策。当事件影响级别较高需要及时处置时，安全管理人员通过工单形式向安全运维人员通报安全事件并下发事件处置要求。安全运维人员通过平台事件详情链接确认事件溯源详情及影响，进行处置后返回事件处置状态信息。
数据在采集、存储、传输、处理、交换、销毁的过程中数据结构和形态是不断变化的，需要采取多种安全组件设备支撑安全策略的实施。数据安全管理平台支持动态联动安全组件设备。可在平台中，定时、批量灵活地配置安全防护策略，动态优化安全防护策略，并同时下发至组件设备执行策略，分别对数据分类分级任务、数据脱敏加密、数据库安全网关策略等安全防护能力策略、敏感数据发现策略、数据流转监控策略实现集中化的安全策略管控。实时保持最高效的安全防护能力，帮助用户高效完成设备集中配置管理。
针对数据安全的风险，以数据为核心，以对所有的数据流转环节进行整体控制为目标，实现外向内防攻击、防入侵、防篡改，内向外防泄漏、防伪造、防滥用的综合防控能力，便于及时发现问题，阻止安全风险。
智能化数据安全治理平台工具。数据安全管理平台引入智能梳理工具，通过自动化扫描敏感数据的存储分布，定位数据资产。同时，关注数据的处理和流转，及时了解敏感数据的流向，时刻全局监测组织内数据的使用和面向组织外部的数据共享；通过机器UEBA学习技术，对数据访问行为进行画像，从数据行为中捕捉细微之处，找到潜藏在表象之下异常数据操作行为。
渗透于数据生命周期全过程域的安全能力。平台融合数据分类分级、数据标识、关联分析、机器学习、数据加密、数据脱敏、数据访问控制、零信任体系、API安全等技术的综合性数据智能安全管理平台，提供整体数据安全解决方案。平台监控数据在各个生命阶段的安全问题，全维度防止系统层面、数据层面攻击或者疏忽导致的数据泄露，为各类数据提供安全防护能力，并根据业务体系，持续应用到不同的安全场景之中。
鉴于数据安全形势日趋复杂，我国《中华人民共和国数据安全法》《中华人民共和国个人信息保护法》《网络数据安全管理条例（征求意见稿）》等法律法规加速落地实施，将数据的保护提高到法律层面，同时要求单位或企业围绕数据处理活动进行数据风险评估、检测，提高数据安全保障能力（图4-36）。
图4-36 数据安全评估要求
数据安全评估，主要针对数据处理者的数据安全保护和数据处理活动情况进行风险评估，旨在掌握数据安全总体情况，发现存在的数据安全风险和问题隐患，指导数据处理者健全数据安全管理制度，完善技术措施，加强人员管理，进一步防范数据安全风险。
数据安全评估，必然需要单位或者企业坚持一定的核心逻辑、评估方法、评估流程及协助评估的一款系统软件工具。
首先要以法律法规和标准作为数据安全评估的依据，其次要以数据生命周期安全为逻辑主线，最后还要结合各行业的业务特点，才能更好地开展数据安全评估工作（图4-37）。
图4-37 数据安全评估逻辑
数据安全评估人员采用的评估方法，包括但不限于：
（1）人员访谈：评估人员采取调查问卷、现场面谈或远程会议等形式对评估方相关人员进行访谈、对被评估的数据、数据处理活动和数据安全实施情况等进行了解、分析和取证。
（2）文档审核：评估人员通过数据安全的管理制度、安全策略、流程机制、合同协议、设开发和测试文档、运行记录、安全日志等进行审核、查验、分析，以便了解被评估方的数据安全实施情况。
（3）系统核查：评估人员通过查看被评估方数据安全相关网络、系统、设备配置、功能或界面，验证数据处理系统和数据安全技术工具实施情况。
（4）技术测试：评估人员通过手动测试或自动化工具进行技术测试，验证被评估方的数据安全措施有效性，发现可能存在的数据安全风险。
数据安全评估实施过程，主要包括评估准备、数据和数据处理活动识别、风险识别、风险分析与评价和评估总结五个阶段。具体工作及各阶段主要产出物如图4-38所示。
图4-38 数据安全评估流程
数据安全评估检查工具由检查能力集、检查知识库、检测信息引擎、工具硬件和基础系统环境组成，应用于完成监督检查评估工作任务。检查能力集包含合规检查、技术检测、扩展检查三个部分，分别体现以访谈问询和文字信息调查为主体的检查能力、以信息技术检测为主体的检查能力和对上述检查结果进行扩展检查的检查能力。检查知识库为各项检查能力的实现提供基础知识和规则模型支撑。检测信息引擎为技术检测能力的实现提供被查信息系统中的检测相关信息获取能力支撑。工具箱硬件和基础系统环境为检查工具的各项能力实现提供硬件和基础系统支撑（图4-39）。
图4-39 数据安全评估工具框架
数据安全运营是将技术、人员、流程进行有机结合的系统性工程，是保证数据安全治理体系有效运行的重要环节。数据安全运营遵循“运营流程化、流程标准化、标准数字化、响应智能化”的思想进行构建，数据安全运营的需要实现流程落实到人，责任到人，流程可追溯，结果可验证等能力。同时，数据安全运营需要贯穿安全监测、安全分析、事件处置、安全运维流程，全面覆盖安全运营工作，满足不同类型、不同等级安全事件的监测、分析、响应、处置流程全域可知和可控。数据安全运营主要包含数据安全资源运营、数据安全策略运营、数据安全风险运营、数据安全事件运营和数据安全应急响应几个部分（图4-40）。
图4-40 数据安全运营组成
数据安全运营包含持续性的安全基线检查、漏洞检测、差距分析，安全事件和安全风险的响应、处置、通报，数据安全复盘分析等，强调数据安全管理工作过程中对数据运营目标的针对性，如数据资产梳理（含数据地图、敏感数据梳理、数据分类分级、数据访问流向分析、数据访问热度分析等）、下发数据安全管控策略、数据安全持续性评估、数据安全运营指标监测、安全阈值的设定等，还包括通过运用流程检测和事件处置结果的考评，对运营人员的能力进行评估，对现有技术控制措施有效性的评估。
数据安全运营机制涵盖以下方面。
（1）预防检测。包括主动风险检查、渗透攻击测试、敏感核查和数据安全基线扫描等手段。
（2）安全防御。包括安全加固、控制拦截等手段。
（3）持续监测。包括数据安全事件监测和确定、定性风险检测、隔离事件等手段。
（4）应急预案。包括对数据安全事件的识别、分级，以及处置过程中组织分工、处置流程、升级流程等。
（5）事件及风险处置、通报。包括流程工单、安全策略管理、安全风险及事件处置、处置状态通报等手段。
邀请数据安全理论专家和技术专家开展针对数据安全业务人员和技术人员的安全基础专项培训，提升相关人员数据安全意识，掌握数据安全发展趋势，了解新型风险和攻防新技术，规范数据安全管理制度，提高数据安全防护能力。
数据安全策略需要结合策略运营数据进行持续优化运营才能达到一个比较理想的结果，运营通常分成五个阶段。运营时间矩阵表见表4-4。
表4-4 运营时间矩阵表
数据安全运营离不开“人”这一关键核心，人员能力最终决定安全运营效果，需对从事安全管理岗位的人员开展系统功能培训及定期开展安全知识培训，培训可分成四个阶段。员工培训时间矩阵表参见表4-5。
表4-5 员工培训时间矩阵表
