写在前面

数据库安全问题

数据库的安全问题已经是数据安全领域面临的最严峻的问题，对数据库安全的防御是艰苦的旅程。
如何让针对业务安全和数据安全的攻击成为一场废鞋底的马拉松， 防止恶意行为者利用漏洞威胁这个“线头”并最终扯下数据这条“线裤”的全部，让我们一起来关注在数据库安全能力建设中识别数据库的安全威胁。

安全威胁简介

数据泄露对每个企业都构成威胁，其损失不仅超出了敏感数据、机密数据和品牌损害带来的实际损失或披露范围，公司还承担了与补救和多年法律责任索赔相关的重大财务成本。

风险敏感的企业组织必须在数据库安全性方面保持领先地位，以保护和防御其数据免受各种外部和内部威胁。

是什么使您的数据成为主要目标？

根据 Verizon2019DBIR 报告，黑客的动机可能是受到经济利益、间谍活动、意识形态或怨恨甚至娱乐的鼓动，71%的泄露事件是出于经济动机发生的，大多数掠食者通过阻力最小的路径攻击最弱的猎物。

好消息是，这意味着您的安全性虽然并不一定是完美的，但它已经足以阻止恶意攻击者–让他们去其他地方寻找更容易的猎物。

坏消息是许多公司都难以实现一种多重安全防御方法，该方法可以检测、监视、预防和缓解威胁。

数据库安全威胁有哪些？

1. 过多的、不适当的和未使用的特权
2. 权限滥用
3. Web 应用程序安全性不足
4. 审计线索不足
5. 不安全的存储介质

前两大威胁可以直接归因于内部威胁的增加。通常，企业网络被认为受到可保护边界的下一代防火墙的保护。

但是，一旦恶意行为者越过防火墙，大多数企业中就没有可以检测到横向移动并防止重大数据泄露的保护机制，这对数据构成了重大威胁。
此外，外部威胁是持续不断的，内部流程不足会留下管理漏洞，因此，当今的安全最佳实践要求组织必须采取多层次、多方面的方法来有效保护数据并防止数据泄露。

1.过多的、不适当的和未使用的特权

当您授予某人超出其工作职能的数据库特权时，这些特权可能会被滥用。
例如，其工作能力是需要更新员工休假信息的 HR，可能会利用过多的数据库特权，对同事或高管的薪资数据进行未经授权的查询。

应用程序的复杂性和使用的相应数据结构意味着，管理员倾向于默认情况下授予过多的特权，只是为了避免由于缺少访问特权而导致应用程序失败的风险。

因此，用户可能被授予远远超出其特定工作要求的通用或默认访问特权，或者他们可能随时间推移累积这些特权。
通常，企业可以保护或“强化”处于高级职位（例如 CEO、CFO 等）的员工的设备免受外部（和内部）攻击者的侵害，以保护对这些用户所需敏感数据的广泛访问，这种加强有助于发现威胁情况，终止访问以及本地存储数据的潜在破坏。

但是，自带设备办公情况下这不是可行的解决方案。
当普通用户的设备受到攻击时，很可能更难以检测到，如果该用户拥有过多特权，则可能会造成破坏，从而导致大规模数据丢失事件。

2. 权限滥用

在一项来自多个企业数据的长达两年的研究中表明，在每个企业中人们都使用数据库服务帐户来访问数据库，并且这些用户滥用这些特权服务帐户来直接访问敏感数据，从而绕过了应用程序界面。

此外，某些“特权用户”可能会出于未经授权的目的滥用合法的数据库特权。
组织中的某些用户组由于其职业和活动而有权访问整个数据库。特权用户的两个主要类别是数据库系统管理员和开发人员。

数据库系统管理员（DBA）可以无限制地访问数据库中的所有数据。为了获得最佳安全性，DBA 在管理数据库时不应直接访问数据库中的应用程序数据（应用程序数据/表）。当 DBA 直接通过数据库而不是应用程序界面访问应用程序数据时，他绕过了应用程序日志记录和检索限制，并避免了应用程序权限和安全性机制。

当某个使用防泄露方案的客户端收到以下警告：受信任的 DBA 已直接通过数据库而不是通过某应用程序入口访问了此应用程序表中的敏感数据，这些表包含 DBA 不应访问的财务信息。这一发现清楚地说明了内部威胁的风险。开发人员通常可以完全访问生产数据库，质量团队可以快照数据库以进行测试，而工程师可以调试实时生产系统。在这些情况下，敏感数据都容易受到特权滥用的影响。

什么是内部威胁?

内部威胁可以分为三类：恶意、疏忽和受到威胁：

恶意内部人威胁来自企业内部或与企业直接相关的人员（如员工、前雇员、供应商、合作伙伴），他们掌握有关企业的安全实践、数据和计算机系统的内部信息。

疏忽大意的内部人员是没有恶意企图的企业内部人员或与企业直接相关的人员，但是由于粗心大意的行为，他们会将敏感数据暴露，导致于数据泄露。

受威胁的用户成为利用或接管组织系统的“外部”恶意攻击者的受害者。 外部攻击者可以使用多种技术来攻击组织，包括使用直接攻击、计算机病毒、社会工程学、网络钓鱼和其他不断发展的技术。

3. Web 应用程序安全性不足

大多数企业组织严重依赖应用程序与客户进行交互，对可公开访问的应用程序的攻击有很多类型，可以暴露数据。
针对数据库的两种常见的 Web 应用程序攻击是 SQL 注入和 WebShell。

多年来，SQL注入（SQLi）攻击一直是头号威胁。SQLi 攻击是输入验证不完整或不充分的结果，它使不良行为者以从未曾预料到的方式通过 Web 应用程序将 SQL 命令传递给数据库。

Web Shell攻击是一种隐蔽方法，用于获得对服务器的未经授权的远程访问。
Web Shell 是利用 Web 服务器核心功能（为远程客户端提供服务）获得持久远程访问并通过与服务器 Shell 的接口获得对服务器的完全或有限控制的后门程序。
根据 Verizon DBIR 由 Web Shell 后门造成的 Web 应用程序攻击破坏数量仅次于凭据被盗。

WebShell 可以使用 Shell 的功能来破坏企业组织数据库并泄露数据而不被检测到。

攻击者使用 Shell 程序的文件浏览功能从应用程序的配置文件中查找和窃取合法应用程序使用的数据库凭据。
Shell 固有地拥有服务器应用程序/守护进程本身的 OS 特权，从而使之成为可能。

此外，在某些应用程序中，数据库凭证（用户名和密码）以明文形式存储在配置文件中。

4. 审计线索不足

监控整个企业中的数据访问应该是任何生产数据库的一部分。
无法同时监视安全性和合规性异常以及无法收集数据库活动的适当审计详细信息，这在许多层面上都构成了严重的组织风险。

为何审计跟踪具有挑战性

第一个原因是，许多企业转向其数据库供应商提供的数据库本地审计功能，或者依赖临时和手动解决方法，并认为这些方法已足够。
本地审计不会记录支持安全性和合规性审计或检测攻击所需的上下文详细信息，也不提供事件取证。

此外，本地数据库审计机制由于数据库服务器的 CPU 和磁盘资源的不稳定和过度消耗而臭名昭著，这迫使许多企业缩减或完全取消本机审计。

最后，大多数本地审计机制是此类数据库服务器平台所独有的。例如，Oracle 日志与 MSSQL 不同，并且 MSSQL 日志与 DB2 不同。
对于具有异构数据库环境的企业，这对实施统一、可扩展的审计流程和报告构成了重大障碍。

第二个挑战：审计处理
拥有正确的审计记录只是保护数据的第一步。
第二步是了解数据活动和访问尝试记录，以处理该数据并确定可信威胁。
如果您没有为该任务构建工具，则很难识别访问数据库的实体并区分 DBA、应用程序、用户和作业进程。

您需要了解对数据库的哪些访问是可疑的，例如，登录失败尝试是数据库访问中的常见现象。用户由于忘记或键入错误的凭据或更改密码而无法登录数据库。

但是，当用户多次未能成功登录数据库而从未尝试过再次登录时，或者当用户试图成功访问企业中的多个数据库而未成功时，则是可疑的，可能表明用户没有获得访问应用程序的授权。

在一些帐户安全研究中，发现确定了一个用户，该用户尝试访问一个他从未访问过的数据库，然后在不到一个小时的时间内使用四个不同的帐户而没有成功，他使用第五个帐户成功登录了数据库，但是该帐户没有足够的特权来对该数据库执行任何操作。

此活动有多个危险信号：

• 用户突然对从未尝试访问过的数据库产生兴趣
• 单个用户使用多个帐户
• 访问数据库的帐户没有权限，这可能会导致一个结论即该帐户根本不应该能够访问此数据库

此事件中将该活动标记为高风险，并提供了一项分析，指出此事件是由受威胁的内部人员实施的。
为了识别此类事件，您需要了解哪些用户是人类用户（而不是作业进程和应用程序）。

然后，您需要了解用户的正常行为-他们访问哪些数据库、使用哪些数据库帐户、借助哪些工具、何时使用它们以及最终定义对等的正常用户和正常行为的更多详细信息
（数据库准入因子自学习：数据库安全能力：安全准入控制矩阵模型构建与实践）。

5. 不安全的存储介质

上次关注存储介质备份的威胁是什么时候？通常，它是完全不受保护的。
许多管理漏洞涉及数据库备份磁盘和磁带的被盗或意外暴露。
采取适当措施保护敏感数据的备份副本不仅是数据安全的最佳实践，而且是许多法规的强制性要求。

此外，特权较高的用户通常将具有直接访问数据库服务器的权限。
这种物理上的接触意味着他们可以插入类似拇指大小的 USB 驱动器，并直接对数据库执行 SQL 命令，这可以关闭本地审计功能并绕过除数据库服务器内核级别部署的保护机制之外的所有保护机制。
我们需要健壮的数据库监控和防御工具，不允许这些类型的违规行为的工具。

大数据应用程序的安全威胁

大数据应用程序的安全威胁不可忽略。

大数据应用程序仍处于起步阶段，在不根据每个公司的特定需求进行自定义的情况下进行部署，几乎没有成熟的商业解决方案。
在市场发展的现阶段，仍然缺少了解大数据技术并能跟上其快速发展的专家。

在大多数情况下，内部开发人员设计、编写代码、测试和部署大数据应用程序和硬件时，却没有得到足够的培训、需求定义、时间或资源。

人们可能误认为，大数据“开源”软件包是一种快速成功的安装方式，实际上这些系统要复杂得多。
构建软件时的第二个问题是缺乏可行的本机安全性或审计框架，该框架不会妨碍定制解决方法。缺少本地模型使安全性实现变得不容易，并且需要深入的设计和持续不断的维护。
因此，需要考虑的安全和审计功能会被反复推迟，从而使您的数据容易受到攻击。

隐私问题

尽管我们专注于安全性，但是隐私问题也不容忽视。

大数据处理过程中保护用户隐私的策略：

• 数据匿名化：使用k-匿名化、l-多样性和t-接近度等方法，在不泄露用户身份的情况下对数据进行分析和处理。
• 数据加密：采用数据加密技术，如AES等，将数据转化为密文，只有拥有密钥的人才能解密并获取原始数据，确保数据在传输和存储过程中的安全性。
• 数据最小化：仅收集和使用完成特定任务所必需的数据，避免收集不必要的数据，减少数据泄露的风险。

大数据环境中应对DDoS攻击的策略

• 流量过滤和封堵：使用防火墙、入侵防御系统（IDS）和入侵防护系统（IPS）等工具来检测和过滤恶意流量。配置网络设备以限制来源IP地址、端口和特定协议的流量。
• 负载均衡和弹性扩展：使用负载均衡设备分发流量，并使用云服务提供商或内容分发网络（CDN）在全球范围内分发流量，减轻单一服务器的压力。配置自动扩展机制，根据流量负载的变化动态增加或减少服务器资源。
• 限制协议和连接：通过配置防火墙、负载均衡设备或网络设备，限制特定协议（如ICMP、UDP）的流量。设置最大连接数、连接速率和请求频率等限制，防止单个IP地址或用户过多地占用资源。
• 增强网络基础设施：使用高带宽和高容量的网络连接，以更好地抵御大流量的DDoS攻击。部署分布式防御设备和缓存服务器，提高整体网络的容量和性能。
• 实时监测和响应：配置实时监测工具，及时发现DDoS攻击并进行响应。这包括设置告警系统、自动封禁恶意IP地址等措施。

如何创建全面的数据安全解决方案

数据安全性需要对数据和用户活动进行统计。
此过程从指纹识别，发现数据库服务器，然后分域管理进行准入访问/活动监控，还需要连续的用户权限管理来阻止特权滥用。

最佳实践的解决方法会考虑到数据访问的每个实例（包括特权用户的实例），敏感数据的匿名化脱敏，为用户和应用程序构建完整的安全配置策略。
在异构环境下的数据库审计日志方面，及日常行为中关注上下文使用机器自学习，可以准确地识别内部威胁并防止数据泄露。

而加强访问数据库的应用程序安全也很重要。SQLi 和 Web Shell 只是 Web 应用程序面临的两种威胁，同时也需要能够阻止 SQLi、Web Shell 事件并防止复杂的业务逻辑攻击的类似高级 Web 应用防火墙的数据库业务防火墙，为防止未经授权的数据访问提供重要的保护。

如您所见对数据库的上述威胁需要多重安全防御机制，仅仅依靠本机工具或忽略外部和内部攻击者能够利用并且将会利用的安全漏洞已不再足够。
保护数据库中的数据对于保护客户、声誉和企业业务生存能力至关重要。

数据库安全作为数据库系统的护城河,通过认证机制、用户角色与权限管理(RBAC)、对象访问控制(ACL)、审计机制与预警、数据隐私保护(数据脱敏、数据加密、导入导出安全)以及安全信道等技术手段防止恶意攻击者访问、窃取、篡改和破坏数据库中的数据,阻止未经授权用户通过系统漏洞进行仿冒、提权等路径恶意使用数据库。

认证机制可以包括但不限于：

• trust认证
• 口令认证， 如sha256加密口令认证(PBKDF2单向加密算法)等方式。
• 证书认证(表示使用SSL客户端进行认证,不需要提供用户密码)
  • 在该认证模式下,客户端和服务端数据经过加密处理。在连接通道建立后,服务端会发送主密钥信息给客户端以响应客户端的握手信息,这个主密钥将是服务端识别客户端的重要依据。值得注意的是,该认证方式应只支持hostssl类型的规则。
• gss认证(表示使用基于gssapi的kerberos认证)
  • 该认证方法依赖kerberosserver组件,一般用于支持集群内部通信认证和外部客户端连接认证
• 黑白名单
• 连接数限制
• 端口限制和IP地址限制

安全信道：
SSL 协议是安全性更高的协议标准, 它们加入了数字签名和数字证书来实现客户端和服务器的双向身份验证,保证了通信双方更加安全的数据传输。

支持SSL的数据库系统，应默认开启SSL认证模式。认证所需要的证书和密钥信息需要初始化时产生或者商家初始化配置。
这些证书由 CA 可信中心颁发。假定服务器的私钥为server.key,证书为server.crt,客户端的私钥为client.key,证书为client.crt,CA 根证书名称为cacert.pem。这些证书信息存放在服务器的安全角落。