下载掌阅APP，畅读海量书库
立即打开
网络安全、数据安全的整体有效性遵循“木桶原理”，即“一只木桶盛水的最多盛水量，取决于桶壁上最短的那块。”数据安全的建设是需要投入资金、时间和人员的，投资者希望通过数据安全的建设不仅仅满足合法合规的要求，而且能够真正解决风险问题。有些建设方案容易陷入功能、能力或者参数的陷阱——技术人员可能认为既然有预算，就多实现一些功能，但是往往没有从实际场景和实际需求出发，使得有些功能变成了“花瓶”式的摆设。本章从常见数据安全风险场景出发，做个简单的梳理，分析我们需要解决哪些问题。
在实际安全系统项目立项的过程中，一个企业可以把自己的需求和这些列出的风险场景做个对照，看看通过本期的项目资金投入建设，能够实实在在地解决哪些风险问题。换句话说，一个组织把现在的安全现状和这些风险场景做个对照，如果每周都能做出翔实的报告，感知这些风险问题是否存在，做到心中有数，那么这样的数据安全技术和运维建设就是较为成熟的。
在企业的发展过程中，信息系统是逐步建设起来的，数据库也会随之部署。在信息系统建设过程中，会根据企业业务情况、资金成本、数据库特性等条件来选择最合适的数据库，建立适当的数据存储模式，满足用户的各种需求。但一些数据库系统，特别是运行时间较长的系统，会出现数据库部署情况底数不清的状况，其主要由以下原因导致（图3-1）。
图3-1 数据库部署情况底数不清的原因
数字化时代，数据库使用场景非常丰富，例如用于生产、用于测试开发、用于培训、用于机器学习等各类场景。而大多数资产管理者往往只重视生产环境而忽略其他环境，又或者只重视硬件资产而对软件和数据等关注不足，从而导致在资产清单中未能完整记载资产信息，数据库资产信息有偏差。
由于安全可靠性的要求，数据库的部署方式也可能不同，典型的情况包括单机单实例、单机多实例、MPP、RAC、主数据库/备份数据库、读写分离控制架构等，部署的方式千差万别。最简单的主数据库/备份数据库部署方式由两个相同的数据库组成，但其对应用或客户端的访问出口是同一个IP地址和端口。当主数据库发生问题时，由备份数据库接管，对前端访问无感知。在这种情形下，如果只登记了前端一个IP地址的资产信息，就会造成遗漏，导致数据资产清单登记不完整。
数据库一般由系统管理员进行建设和运维管理。随着时间变化，系统管理员可能会出现离职、转岗等情况，交接过程可能会出现有意或无意的清单不完整的情况，导致数据资产信息的不完整。
以上因素将导致数据资产部署情况底数不清，使部分被遗漏的数据资产得不到有效监管和防护，从而引发数据泄露或丢失的风险。
在数据库安装和使用过程中，不适当的或不正确的配置可能会导致数据发生泄露。数据库基础配置不当通常会涉及以下几个因素（图3-2）。
图3-2 数据库配置不当的因素
通常数据库会内置默认账号，其中会有部分账号是过期账号或处于被禁用状态的账号，而其他账号则处于启用状态。这些默认账号通常会被授予一定的访问权限，并使用默认的登录密码。如果此类账号的权限较大而且默认登录密码未被修改，则很容易被攻击者登录并窃取敏感数据，造成数据泄露。
有些手动创建的运维或业务访问账号，基于便利性而被授予一些超出其权力范围的权限，即授权超出了应授予的“最小访问权限”，从而使这些账号可以访问本不应被访问的敏感数据，导致数据泄露。
对于采用静态密码认证的数据库，系统账号如采用默认密码或易猜测的简单密码，如个人生日、电话号码、111111、123456等，攻击者只需通过简单的尝试就可以偷偷登录数据库，获取数据库访问权限，导致数据泄露。
数据库通常包含日志审计功能，而且能直接审计到数据库本地操作行为。但开启该功能后一般会占用较大的计算和存储资源，因此很多数据库管理人员关闭该功能，从而导致数据库操作无法被审计记录，后续发生数据泄露或恶意操作行为时无法溯源。
在数据库运行期间，安全人员可能发现诸多数据库安全漏洞。安全人员把数据库漏洞报告提交给数据库厂商后，数据库厂商会针对漏洞发布补丁程序。当该版本的数据库软件相关补丁不能及时更新时，攻击者就能利用该漏洞攻击数据库，从而导致数据泄露。
当数据库所在的网络操作系统未设置安全的防火墙访问策略，且数据库自身也未限制访问来源时，在一个比较开放的环境中，数据库可能会面临越权访问。例如，攻击者通过泄露的用户名和密码、通过一个不受信任的IP地址也能访问数据库，轻易地获取数据库内部存储的敏感数据密码，从而造成数据泄露。
在互联网企业中，通过数据驱动决策优化市场运营活动、改进自身产品，已是寻常操作；而在传统企业中，“数据驱动”的概念也在近年逐渐普及，大部分组织都在进行数字化转型，创建了数据安全管理部门。既然数据在企业决策中如此重要，它们的数量、分布、来源、存储、处理等一系列情况又是如何呢？
一个企业的数据库系统，少则有几千张、多则有几万张甚至更多数据表格（图3-3）。将各个数据库系统进行统计，所拥有的数据信息可能达到几亿条，甚至几十亿条、上百亿条。一些第三方研究组织的调研结果显示：目前许多企业的首席信息安全官无法对自家企业的敏感重要数据分布情况做出翔实而客观的描述。
图3-3 企业的数据库系统示意图
敏感重要数据分布情况底数不清，意味着对数据处理活动的风险无法准确评估，也就难以有针对性地进行数据的分类分级保护。
在各行各业数据处理实践当中，造成上述问题最常见的原因是，低估了敏感重要数据分布的广泛性。这里的广泛性有以下两种含义。
一是部分业务类型的数据敏感性没有被客观认知。例如，个人身份信息、生物特征信息、财产信息、地址信息等容易得到重视，被标记为敏感数据；而在某些特定背景下，同样应该被标记为敏感重要数据的，如人员的身高、体重、生日、某些行为的时间信息、物品要素信息等数据，却往往被忽略。二是“敏感重要数据”的界定是动态的，不同的数据获取方式将会影响同类数据的敏感级别判定结果。
业务数据分散在各个数据库系统中。一个企业的应用软件可能涉及多个提供商，很多企业实际使用着多达上百个数据库，而在本就庞杂的数据存储环境中又有不断新增的业务数据。如果不进行详细的摸查并完整记录敏感数据的分布情况，那么可能导致敏感数据暴露。
综上所述，为了避免敏感数据暴露或失窃的情况发生，首先要对所有的敏感重要数据的分布情况摸查清楚、完整记录并进行持续关注和保护。
敏感数据和重要数据过度授权的现象屡见不鲜。在展开讨论之前，我们需要先明确这里的“权限”如何界定。以Oracle为例，权限可以分为“系统权限”与“实体权限”。
“系统权限”可以理解为允许用户做什么。如授予“CONNECT”权限后，用户可以登录Oracle，但不可以创建实体，也不可以创建数据库结构；而授予“RESOURCE”权限后，则允许用户创建实体，但仍不可以创建数据库结构；在授予数据库管理员的权限后，则可以创建数据库结构，同时获得最高的系统权限。
“实体权限”则可理解为针对表或视图等数据库对象的操作权限，如select、update、insert、alter、index、delete等，它约束的是用户仅对相应数据库对象的具体操作权限。
在实际的情况中，我们遇到的过度授权问题主要对应以下两类。
（1）给只需要访问业务数据表的角色授予了创建数据库结构的权限、系统表访问权限、系统包执行权限等。
（2）将业务上只需给A子部门的数据表，设为了A、B子部门均可见（这不仅是因为数据库权限这一层的控制出现了过度授权问题，也有可能是多个用户共用同一个账号造成的）。
第一类问题主要会增加操作风险，而第二类问题则有可能造成额外的内控风险。
所以应该严格确认并授予用户最小够用权限，避免由于授予过多权限导致的数据被越权访问，发生数据泄露的情况。
原则上，数据账号权限的管理应当遵循权限最小化原则，但在实际应用中，特别是对于一些老系统可能实际情况并非如此。主要原因有二，一是过去对于数据库系统并不强调三权分立（管理员、审核员、业务员），数据库授权通常都是数据库开发人员自行赋权，没有严格的管理规范与第三方人员审核；二是对于Oracle、Db2、SQLServer等大型商用数据库，历史上由于资源配置问题，通常都是将数据库部署在配置最高、性能最好的服务器或小型机上（即传统的“IOE架构”），因此很多核心的业务逻辑是通过数据库自身的package、user defined type、procedure、trigger、udf、job、schedule等实现的。由于涉及大量的对象引用与赋权，为了节省时间，以Oracle数据库为例，数据库工程师或开发人员往往选择将一个高权限的角色，如DBA、exp_full_database、execut any procedure等，直接赋予数据库用户。
管理员可能将一些高权限的角色或权限直接赋予了一些通用角色，如public角色。这样，任意用户通过“间接赋权”的方式就可获得较高的权限，且由于是间接赋权，再加上public角色通过基础数据字典如dba_roles或dba_role_privs是无法查到的，因此很难被察觉。笔者之前就曾遇到过某互联网金融公司运维人员无意中将DBA角色赋权给public角色，结果导致任意用户都具有DBA角色。
在分布式事务的数据库中创建dblink的对端账号，可能具有较高的权限或角色如resource，select any table等。这就导致当前用户虽然在本地仅是一个常规权限用户，但对对端数据库实例具有非常高的权限且不易感知。
“沉睡”账号可能导致管控问题。沉睡账号的产生通常有以下两种原因。
（1）数据库运维外包给第三方，由第三方的工程师自己创建的运维账号，主要用于定期巡检、排错、应急响应。此类账号日常鲜有登录，且账号权限不低，当工程师离职时如果交接没有做好，账号可能就一直沉睡在数据库系统中了。
（2）业务系统已经迁移或下线，但未对数据库账号相应处理。此类账号通常只有自身对象的相应权限，但如泄露，攻击者利用一些已知漏洞（如Oracle 11g著名的with as派生表漏洞）也可对系统造成极大的破坏。
通常数据库的权限管理都是基于RBAC模型的（MySQL 8.0之后的版本也有类似角色的功能）。角色是多种权限的集合，也可以是多种角色的集合，角色间相互可以嵌套。想要厘清这些关系确实非常困难，这也给历史用户的权限梳理造成了极大的干扰。
针对以上问题，以Oracle数据库为例，可以查询各个数据库用户所拥有的权限与角色，并返回结果（图3-4）。
图3-4 数据库用户权限与角色
数据库可展示所查询用户拥有的系统或对象权限、权限属于哪个组、是否可将此权限赋予其他用户等信息。
在实际的工作场景中，对于进出机房及带出硬件一般都会进行严格的检查和审批，因此这类数据硬件失窃的风险相对较低，属于小概率事件。常见的硬件失窃主要有以下途径。
（1）到维护期需要更换新的硬件，在旧的设备被替换后，直接申请报废，无人维护和管理，造成数据丢失。
（2）磁盘阵列或服务器RAID组中某一块硬盘或磁带库（光盘）中的某一卷故障，被替换后无人管理造成丢失。
（3）磁盘或其他设备故障后，未经妥善的数据处理就送去维修，导致数据失窃。
以上问题的本质都是对被淘汰设备的管理不到位。为避免此类问题，应当建立完善的数据存储设备更换、保存、销毁流程和制度，避免因管理疏漏造成的数据丢失或其他财产损失。即便有些硬件盗窃事件的嫌疑人只对偷窃的硬件感兴趣或无法破译硬件上的安全措施，我们也不能因此就掉以轻心。
随着虚拟化、云计算技术的普及，越来越多的企业选择将自身业务放在公有云或者混合云上，如何保护云上数据文件的安全便成为一个令各个企业困扰的难题。在各类数据库体系结构中，可直接用于数据获取的数据文件主要有两类，一类是数据存储文件如Oracle的datafile，MySQL的ibd文件等；另一类为事务日志文件，如Oracle的redo日志、archive log、MySQL的binlog等。事务日志文件中存放的是数据块中数据的物理或逻辑变更，依赖一些工具如Oracle logminer、MySQL binlog2sql等可以直接转化为相应的SQL操作，进而获取一个时间段内的数据。
对攻击者从数据库或应用程序接口（Application Programming Interface，简称API）获取数据的行为，可以通过数据审计、Web审计、日志等方式进行监控；而针对攻击者通过各种文件传输协议如FTP、SAMBA、NFS、SFTP甚至HTTP等进行数据文件窃取的行为，需要对数据文件传输进行监控。
分析型数据、测试型数据是指从生产环境导出线上数据，并导入独立数据，用作数据分析、开发测试的场景。为何要单独对这两类场景进行分析并关注其安全风险呢？因为这两类场景在越来越多的组织中都有着强烈的需求，同时在这两类场景中数据存在较大的安全隐患，容易造成泄密风险（图3-5）。下面将详细阐述这两类场景的过程及泄密风险点。
图3-5 数据测试开发使用场景
随着大数据应用的成熟，数据分析的商用价值被日益重视。无论数据拥有者自身或是第三方，都希望通过对线上数据进行分析，从中提炼有效的信息，为商业决策提供可靠支撑；或将数据导入人工智能系统中，锻炼智能学习算法模型，期望将经过锻炼的智能系统部署上线，自动化地完成部分决策功能。无论是人工分析或是机器学习分析，均需要将数据从原始数据环境导出到独立的数据库进行作业，而用于数据分析的数据库环境可能是在实验室，也可能在开发者的个人计算机上，甚至是在第三方的系统中。数据分发的过程已将数据保护的责任一并交到了对方手上，组织的核心敏感数据是否得以保全完全取决于对方的安全意识及安全防护能力。如果分析环境没有任何保护措施，那么敏感数据等同于直接暴露、公开。对组织而言，数据不仅脱离了管控，同时可能因数据泄露而造成巨大损失。
同数据分析场景一样，数据开发测试场景也需要将数据从生产环境导出到独立的数据库上进行后续操作。开发测试人员为确保测试结果更符合真实环境，往往希望使用与真实数据相似的数据，或者直接使用真实数据的备份进行测试和验证。开发测试环境往往不像生产环境那样有严密的安全防护手段，同时因权限控制力度降低，数据获取成本降低，与外界存在更多接触面，这让不法分子能够更轻易地从开发测试库获取敏感数据。另外还有可能因获取门槛较低，让个别内部人员有机会窃取敏感数据。
考虑到数据导出后其安全性已不再受控，故需要针对导出的数据进行处理，尽量减小泄密风险，同时预留事后追溯途径。
例如，某大型酒店曾经真实发生的一起数据泄密事件。因该酒店同时与多个第三方咨询公司合作，需要客户入住信息用作统计分析，酒店工作人员在未做任何处理的情况下将数据导出交给了多个咨询公司。后被发现有超过50万条客户隐私信息遭泄露，但因无据可查，最终也无法确定究竟是从哪家咨询公司泄密。若酒店在把数据交给第三方时经过了脱敏，则可避免泄密事件的发生；或添加好水印再将数据交出，则至少能在事后进行追查，定位泄密者。
综上所述，对于数据安全而言，不仅要关注实际生产环境下的数据安全，也要做好开发测试库及数据分析库的安全保障。在日益严峻的数据安全大背景下，只有完善的防护体系和可靠的防护策略，才能更有效地提高数据安全防护能力，保障组织的数据安全，防止因开发测试或数据分析等环节出现数据泄露而导致损失。
2021年5月13日，美国Verizon公司发布了《2021年数据泄露调查报告》。该报告指出，2021年数据泄露的主要原因是Web应用程序攻击、网络钓鱼和勒索软件，其中85%涉及人为因素。该报告分析了79635起安全事件，其中29207起满足分析标准，5258起确认是数据泄露事件，这些事件来自全球88个国家。
近几年数据泄露事件越发普遍，数据泄露的成本也越来越高，隐私安全和数据保护成为当下严峻的问题。为了更好地规避风险，下面总结了6种常见的数据泄露事故。
（1）黑客窃取数据。
在日常生活中，数据泄露防不胜防，黑客能以专用的或自行编制的程序来攻击网络，入侵服务器，窃取数据。
（2）员工失误。
组织中许多数据泄露事故常常是内部人员疏忽或意外造成的。某咨询公司的一项研究发现，40%的高级管理人员和小企业主表示，疏忽和意外损失是他们最近一次安全事件的根本原因。
（3）员工有意泄露。
内部员工（前雇员或在职人员）可能是造成数据泄露最大的出口。内部员工，尤其是肩负重要职位的人员，通常是组织中最先得到大量核心数据的人，他们会在各种可能的情况下出卖或带走数据。2017年1月17日，国内某著名科技公司就曾内部通报了已离职的6名员工涉嫌侵犯知识产权，将公司商业机密泄露给竞争关系公司，涉嫌构成侵权的专利估值高达300万元。
（4）通信风险。
通信是我们日常工作和生活中无处不在的一部分，而通信工具的漏洞和风险无处不在（包括常见的即时通信工具）。最令人恐惧的是，大量员工使用个人设备或个人账户来传送敏感信息，这些简单的社交工具缺少监管和防护措施，很容易造成数据泄露。
（5）网络诈骗。
近年来，电子邮件成为钓鱼诈骗的重灾区。许多人的收件箱中垃圾邮件泛滥成灾，其中不乏混杂着各种诈骗邮件。同时，黑客攻破单个员工的计算机也会泄露大量组织数据。
（6）电子邮件泄露。
很多数据泄露事件发生在电子邮件中，因此要特别小心邮件地址和密码的泄露风险。
在信息时代，人们在享受着信息化社会所带来的简单、高效、便捷的同时，也对自身的个人信息安全产生了深深的担忧……“信息裸奔”让人们成了“透明人”，隐私泄露层出不穷，财产受损现象频繁发生。
（1）个人数据泄露的危害。
①金融账户，如支付宝、微信支付、网银等账号与密码被曝光，会被不法分子用来进行金融犯罪与诈骗。
②用户虚拟账户中的虚拟资产可能被盗窃、被盗卖。
③个人隐私数据的泄露会导致大量广告、垃圾信息、电商营销信息等发送给个人，给个人生活上带来极大的不便。
（2）企业数据泄露的危害。
①企业品牌和声誉。企业网站受到攻击，最先受到影响的是企业品牌和声誉。企业绝对不会想要把名声与入侵事件或客户信用卡信息丢失事件联系起来。
②流量损失。无论是信息型网站，还是电子商务网站，网络流量关系到可见性与受欢迎性。如果网站遭受攻击，那些谨慎的客户就可能不再访问该网站，不仅如此，企业网站在搜索引擎上的排名也将受到影响。例如，谷歌通常定期抓取网站数据并进行识别，并将那些被黑客攻击或出现“可疑活动”的网站列入黑名单。
③企业人力成本增加。企业网站受到攻击造成数据泄露时，受影响的不仅仅只是企业声誉；作为企业负责人或负责网站安全的专业人员，也可能会因此去职或被辞退。
④时间成本、资金成本增加。一旦网站受到攻击，造成数据泄露，而且不知道还会有哪些其他风险和漏洞，对于人力物力来说，都是很大的花费。
（3）国家数据泄露的危害。
进入信息化时代，数据被广泛采集汇聚和深度挖掘利用，在促进科技进步、经济发展、社会服务的同时，安全风险不断凸显：有的数据看似不保密，一旦被窃取却可能威胁国家安全；有的数据关系国计民生，一旦遭篡改破坏将威胁经济社会安全。
数据作为企业的重要资产保存在数据库中，SQL注入可能使攻击者获得直接操纵数据库的权限，带来数据被盗取、篡改、删除的风险，给企业造成巨大损失。
SQL注入可能从互联网兴起之时就已诞生，早期关于SQL注入的热点事件可以追溯到1998年。时至今日，SQL注入在当前的网络环境中仍然不容忽视。
SQL注入产生的主要原因是，应用程序通过拼接用户输入来动态生成SQL语句，并且数据库管理对用户输入的合法性检验存在漏洞。攻击者通过巧妙地构造输入参数，注入的指令参数就会被数据库服务器误认为是正常的SQL指令而运行，导致应用程序和数据库的交互行为偏离原本业务逻辑，从而导致系统遭到入侵或破坏。
所有能够和数据库进行交互的用户输入参数都有可能触发SQL注入，如GET参数、POST参数、Cookie参数和其他HTTP请求头字段等。
攻击者通过SQL注入可以实现多种恶意行为，如：绕过登录和密码认证，恶意升级用户权限，然后收集系统信息，越权获取、篡改、删除数据；或在服务器植入后门，破坏数据库或服务器等。
SQL注入的主要流程（图3-6）如下：
（1）Web服务器将表格发送给用户；
（2）攻击者将带有SQL注入的参数发送给Web服务器；
（3）Web服务器利用用户输入的数据构造SQL串；
（4）Web服务器将SQL发给DB服务器；
（5）DB服务器执行被注入的SQL，将结果返回Web服务器；
（6）Web服务器将结果返回给用户。
图3-6 SQL注入的主要流程
攻击者常用的SQL注入有以下5种类型。
（1）Boolean-based blind SQL injection（布尔型注入）。在构造一条布尔语句时通过AND与原本的请求链接进行拼接。当这条布尔语句为真时，页面应该显示正常；当这条语句为假时，页面显示不正常或是少显示了一些内容。以MySQL为例，比如，攻击者使用在网页链接中输入https://test.com/view？id=X and substring（version（），1，1）=Y（X和Y分别为某特定值），如果MySQL的版本是6.X的话，那么页面返回的请求就和原本的一模一样，攻击者可以通过这种方式获取MySQL的各类信息。
（2）Error-based SQL injection（报错型注入）。攻击者不能直接从页面得到查询语句的执行结果，但通过一些特殊的方法却可以回显出来。攻击者一般是通过特殊的数据库函数引发错误信息，而错误的回显信息又把这些查询信息给泄露出来了，因此攻击者就可以从这些泄露的信息中搜集各类信息。
（3）Time-based blind SQL injection（基于时间延迟注入）。不论输入何种请求链接，界面的返回始终为True，即返回的都是正常的页面情况，则攻击者就可以构造一个请求链接。当一个请求链接的查询结果为True时，通过加入特定的函数如sleep，让数据库等待一段时间后返回，否则立即返回。这样，攻击者就可以通过浏览器的刷新情况来判断输入的信息是否正确，从而获取各类信息。
（4）UNION query SQL injection（可联合查询注入）。联合查询是可合并多个相似的选择查询的结果集，它等同于将一个表追加到另一个表，从而将两个表的查询组合在一起，通过联合查询获取所有想要的数据。联合注入的前提是，页面要有回显位，即查询的结果在页面上要有位置可以展示出来。
（5）Stacked queries SQL injection（可多语句查询注入）。这种注入危害很大，它能够执行多条查询语句。攻击者可以在请求的链接中执行SQL指令，将整个数据库表删除，或者更新、修改数据。如输入：https://test.com/view？id=X；update userInfo set score='Y'where 1=1；（X和Y分别为某特定值），等到下次查询时，则会发现score全部都变成了Y。
时至今日，数据库的漏洞已经广泛存在于各个主流的关系型与非关系型数据库系统中，美国Verizon公司就“核心数据是如何丢失的”做过一次全面的市场调查，结果发现，75%的数据丢失情况是由于数据库漏洞造成的。这说明及时升级数据库版本，保证数据库尽可能避免因自身漏洞而被攻击是非常重要的。
据CVE的数据安全漏洞统计，Oracle、SQLServer、MySQL等主流数据库的漏洞数量在逐年上升，以Oracle为例，当前漏洞总数已经超过了7000个。数据库漏洞攻击主要涉及以下两类。
第一类是拒绝服务攻击，典型代表有Oracle TNS监听服务远程利用漏洞（CVE-2012-1675）。攻击者可以自行创建一个和当前生产数据库同名的数据库，用伪数据库向生产数据库的监听模块进行注册。这样将导致用户连接被路由指向攻击者创建的实例，造成业务响应中断。还有MySQL:sha256_password认证长密码拒绝式攻击（CVE-2018-2696），该漏洞源于MySQL sha256_password认证插件。该插件没有对认证密码的长度进行限制，而直接传给my_crypt_genhash（），用SHA256对密码加密求哈希值。该计算过程需要大量的CPU计算资源，如果传递一个很长的密码，会导致CPU资源耗尽。SHA256函数在MySQL的实现中使用alloca（）进行内存分配，无法对内存栈溢出保护，可能导致内存泄漏、进程崩溃。
第二类是提权攻击，如Oracle 11g with as派生表越权；Oracle 11.1-12.2.0.1自定义函数提权；PostgreSQL高权限命令执行漏洞（CVE-2019-9193）。通过此类漏洞，攻击者可获得数据库或操作系统的相关高级权限，进而对系统造成进一步的破坏。
API作为数据传输流转的重要通道，承担着连接服务和传输数据的重任，在政府、电信、金融、医疗、交通等诸多领域得到广泛应用。API技术已经渗透到了各个行业，涉及包含敏感信息、重要数据在内的数据传输、操作，乃至业务策略制定等环节。伴随着API的广泛应用，传输交互数据量飞速增长，数据敏感程度不一，API安全管理面临巨大压力。近年来，国内外已发生多起由于API漏洞被恶意攻击或安全管理疏漏导致的数据安全事件，对相关组织和用户权益造成严重损害，逐渐引起各方关注。
API的初衷是使得资源更加开放和可用，而各个API的自身安全建设情况参差不齐，将API安全引入开发、测试、生产、下线的全生命周期中是安全团队亟须考虑的问题。建设有效的整体API防护体系，落实安全策略对API安全建设而言尤为重要。API数据共享安全威胁包含外部和内部两个方面的因素。
从近年API安全态势可以看出，API技术被应用于各种复杂环境，其背后的数据一方面为组织带来商机与便利，另一方面也为数据安全保障工作带来巨大压力。特别是在开放场景下，API的应用、部署面向个人、企业、组织等不同用户主体，面临着外部用户群体庞大、性质复杂、需求不一等诸多挑战，需时刻警惕外部安全威胁。
（1）API自身漏洞导致数据被非法获取。
在API的开发、部署过程中不可避免会产生安全漏洞，这些漏洞通常存在于通信协议、请求方式、请求参数和响应参数等环节。不法分子可能利用API漏洞（如缺少身份认证、水平越权漏洞、垂直越权漏洞等）窃取用户信息和企业核心数据。例如在开发过程中使用非POST请求方式、Cookie传输密码等操作登录接口，存在API鉴权信息暴露风险，可能使得API数据被非法调用或导致数据泄露。
（2）API成为外部网络攻击的重要目标。
API是信息系统与外部交互的主要渠道，也是外部网络攻击的主要对象之一。针对API的常见网络攻击包括重放攻击、DDoS攻击、注入攻击、Cookie篡改、中间人攻击、内容篡改、参数篡改等。通过上述攻击，不法分子不仅可以达到消耗系统资源、中断服务的目的，还可以通过逆向工程，掌握API应用、部署情况，并监听未加密数据传输，窃取用户数据。
（3）网络爬虫通过API爬取大量数据。
“网络爬虫”能够在短时间内爬取目标应用上的大量数据，常表现为在某时间段内高频率、大批量进行数据访问，具有爬取效率高、获取数据量大等特点。通过开放API对HTML进行抓取是网络爬虫最简单直接的实现方式之一。不法分子通常采用假UA头和假IP地址隐藏身份，一旦获取组织内部账户，可能利用网络爬虫获取该账号权限内的所有数据。如果存在水平越权和垂直越权等漏洞，在缺少有效的权限管理机制的情况下，不法分子可以通过掌握的参数特征构造请求参数进行遍历，导致数据被全量窃取。
此外，移动应用软件客户端数据多以JSON形式传输，解析更加简单，反爬虫能力更弱，更易受到网络爬虫的威胁。
（4）API请求参数易被非法篡改。
不法分子可通过篡改API请求参数，结合其他信息匹配映射关系，达到窃取数据的目的。
以实名身份验证过程为例，其当用户在用户端上传身份证照片后，身份识别API提取信息并输出姓名和身份证号码，再传输至公安机关进行核验，并得到认证结果。在此过程中，不法分子可通过修改身份识别API请求参数中的姓名、身份证号码组合，通过遍历的方式获取姓名与身份证号码的正确组合。可被篡改的API参数通常有姓名、身份证号码、账号、员工ID等。此外，企业中员工ID与职级划分通常有一定关联性，可与员工其他信息形成映射关系，为API参数篡改留下可乘之机。
在应对外部威胁的同时，API也面临许多来自内部的风险挑战。一方面，传统安全通常是通过部署防火墙、WAF、IPS等安全产品，将组织内部与外部相隔离，达到防御外部非法访问或攻击的目的，但是这种安全防护模式建立在威胁均来自组织外部的假设前提下，无法解决内部隐患。另一方面，API类型和数量随着业务发展而扩张，通常在设计初期未进行整体规划，缺乏统一规范，尚未形成体系化的安全管理机制。从内部脆弱性来看，影响API安全的因素主要包括以下几方面。
（1）身份认证机制。
身份认证是保障API数据安全的第一道防线。一方面，若企业将未设置身份认证的内网API接口或端口开放到公网，可能导致数据被未授权用户访问、调用、篡改、下载。不同于门户网站等可以公开披露的数据，部分未设置身份认证机制的接口背后涉及企业核心数据，暴露与公开核心数据易引发严重安全事件。另一方面，身份认证机制可能存在单因素认证、无密码强度要求、密码明文传输等安全隐患。在单因素身份验证的前提下，如果密码强度不足，身份认证机制将面临暴力破解、撞库、钓鱼、社会工程学攻击等威胁。如果未对密码进行加密，不法分子则可能通过中间人攻击，获取认证信息。
（2）访问授权机制。
访问授权机制是保障API数据安全的第二道防线。用户通过身份认证即可进入访问授权环节，此环节决定用户是否有权调用该接口进行数据访问。系统在认证用户身份之后，会根据权限控制表或权限控制矩阵判断该用户的数据操作权限。常见的访问权限控制策略有三种：基于角色的授权（Role-Based Access Control）、基于属性的授权（Attribute-Based Access Control）、基于访问控制表的授权（Access Control List）。访问授权机制风险通常表现为用户权限大于其实际所需权限，从而使该用户可以接触到原本无权访问的数据。导致这一风险的常见因素包括授权策略不恰当、授权有效期过长、未及时收回权限等。
（3）数据脱敏策略。
除了为不同的业务需求方提供数据传输，为前端界面展示提供数据支持也是API的重要功能之一。API数据脱敏策略通常可分为前端脱敏和后端脱敏，前者指数据被API传输至前端后再进行脱敏处理；后者则相反，API在后端完成脱敏处理，再将已脱敏数据传输至前端。如果未在后端对个人敏感信息等数据进行脱敏处理，且未加密便进行传输，一旦数据被截获、破解，将对组织、公民个人权益造成严重影响。
此外，未脱敏数据在传输至前端时如被接收方的终端缓存，也可能导致敏感数据暴露。而脱敏策略不统一可能导致相同数据脱敏后结果不同，不法分子可通过拼接方式获取原始数据，造成脱敏失效。
（4）返回数据筛选机制。
如果API缺乏有效的返回数据筛选机制，可能由于返回数据类型过多、数据量过大等原因形成安全隐患。首先，部分API设计初期未根据业务进行合理细分，未建立单一、定制化接口，使得接口臃肿、数据暴露面过大。其次，在安全规范欠缺或安全需求不明确的情况下，API开发人员可能以提升速度为目的，在设计过程中忽视后端服务器返回数据的筛选策略，导致查询接口会返回符合条件的多个数据类型，大量数据通过接口传输至前端并进行缓存。如果仅依赖于前端进行数据筛选，不法分子可能通过调取前端缓存获取大量未经筛选的数据。
（5）异常行为监测。
异常访问行为通常指在非工作时间频繁访问、访问频次超出需要、大量敏感信息数据下载等非正常访问行为。即使建立了身份认证、访问授权、敏感数据保护等机制，有时仍无法避免拥有合法权限的用户进行非法数据查询、修改、下载等操作，此类访问行为往往未超出账号权限，易被管理者忽视。异常访问行为通常与可接触敏感数据岗位或者高权限岗位密切相关，如负责管理客户信息的员工可能通过接口获取客户隐私信息并出售谋利；即将离职的高层管理人员可能将大量组织机密和敏感信息带走等。企业必须高度重视可能由内部人员引发的数据安全威胁。
（6）特权账号管理。
从数据使用的角度来说，特权账号指系统内具有敏感数据读写权限等高级权限的账号，涉及操作系统、应用软件、企业自研系统、网络设备、安全系统、日常运维等诸多方面，常见的特权账号有admin、root、export账号等。除企业内部运维管理人员外，外包的第三方服务人员、临时获得权限的设备原厂工程人员等也可能拥有特权账号。多数特权账号可通过API进行访问，居心不良者可能利用特权账号非法查看、篡改、下载敏感数据。此外，部分企业出于提升开发运维速度的考虑会在团队内共享账号，并允许不同的开发运维人员从各自终端登录并操作，一旦发生数据安全事件，难以快速定位责任主体。
（7）第三方管理。
当前，需要共享业务数据的应用场景日益增多，造成第三方调用API访问企业数据成为企业的安全短板。尤其对于涉及个人敏感信息或重要数据的API，如果企业忽视对第三方进行风险评估和有效管理、缺少对其数据安全防护能力的审核，一旦第三方机构存在安全隐患或人员有不法企图，则可能发生数据被篡改、泄露甚至非法贩卖等安全事件，对企业数据安全、社会形象乃至经济利益造成损失。
综上，API是数据安全访问的关键路径，不安全的API服务和使用会导致用户面临机密性、完整性、可用性等多方面的安全问题。用户在选择解决方案时也需要综合考虑大量API的改造成本和周期问题。
制订妥善的备份恢复计划是组织保证数据完整性、稳定性的有效手段，尤其是遇到勒索病毒之时，备份更成为抵御勒索病毒的最后一道防线。
首先，数据库备份可能存在的主要问题是部分企业只做了逻辑备份，没有做物理备份。例如像MySQL这类开源数据库，其原生版本不提供物理备份，需要借助xtrabackup等第三方备份工具实现数据库备份，对于各种公有云上的RDS来说，这个问题尤为突出。
逻辑备份作为一种数据迁移、复制手段，在中小规模数据量下具备一定的优势，例如进行异构或跨版本的数据复制迁移。然而，逻辑备份本身不支持“增量备份”，这造成基于逻辑备份恢复数据后还需要借助如Oracle logminer、MySQL binlog等来提取恢复时间点之后的数据进行二次写入；同时，在写入时还需要比对逻辑备份时的scn或gtid，以避免重复写入。因此，逻辑备份在恢复效果和速度上都不如物理备份。
而对于物理备份，则需要制订合理的备份计划，从而保证备份的可用性。物理备份特别是在线备份，需要在备份集中设置一个检查点（checkpoint）。如果不设置检查点，则可能导致备份不可用。因此，需要定期对备份集做恢复演练，来保证备份计划和备份集的有效性。
其次，需要保护好备份集，做好备份集的冗余，即做好备份的备份工作。备份是避免数据库勒索的终极手段，因此目前很多勒索病毒都将攻击对象蔓延到了数据库备份上。特别是对于像Oracle、SQLServer这种备份信息本身就可以保存在数据字典中的数据库来说更加容易遭受此类攻击。
最后，无论是逻辑备份还是物理备份，都应当做好备份加密工作，以避免被复制后在异地恢复时造成数据泄露。加密可借助于数据库自身的加密技术来实现，如用Oracle tde或在expdp导出时指定ENCRYPTION、ENCRYPTION_MODE等参数，MySQL可以在mysqldump时通过openssl及zip压缩。参考：
其中manager1为加密密码，使用时建议定期更换。
在日常的开发和数据库运维中，数据误操作是非常常见的，几乎每个数据库开发人员、数据库管理员、数据仓库技术（Extract-Transform-Load，简称ETL）开发人员都或多或少遇到过相关的问题。常见的场景：比如同时打开两个数据库客户端工具，一个连接生产环境，一个连接测试环境，由于生产与测试通常只用schema或用户名来区分（如生产环境中称作App，测试环境中则称作App_dev），其他对象名均完全一致。这时候往往本应执行删除测试环境中的数据（App_dev），结果却误删了生产环境（App）的数据。又或者是发生delete、update逻辑错误，本应删除上周的数据，结果误删了本周的数据，凡此种种不胜枚举。
避免数据误操作的关键是，保证数据或元数据的变更必须流程化、规范化，一定要经过严格的审核后才可执行。操作前一定要做好数据快照或备份，特别是对于truncate table、drop table（purge）这类不可逆的DDL操作来说，操作前的数据备份更是尤为重要，一旦发现问题，立刻通过回滚将损失降到最低。
还有一种少见但影响面极大、危害极高的人为误操作——数据库文件误删除。在笔者的数据库管理员生涯中曾多次遇到过一些灾难恢复场景，如Oracle无备份情况下删除current redo导致的宕机、删除MySQL的ibdata文件或其他数据文件导致MySQL实例宕机等。此类文件均属于数据库实例运行时的必要文件，一旦被误删，数据库实例会立即崩溃。因此，需要避免在数据库服务器上使用rm -rf等高危操作，或者将rm alias改为mv，通过alias实现回收站的效果，从而减少误操作造成的损失。