详解5大数据库安全威胁

在数据库的安全问题已跃至CSO的工作内容象限榜首的今天，对数据库安全的防御是艰苦的旅程，如何让针对业务安全和数据安全的攻击成为一场废鞋底的马拉松，防止恶意行为者利用漏洞威胁这个“线头”并最终扯下数据这条“线裤”的全部，让我们一起来关注在数据库安全能力建设中识别数据库的安全威胁。

安全威胁简介

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

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

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

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

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

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

在本文中，我们将讨论关系型数据库面临的五大数据库安全威胁。我们还将探讨确保大数据安全的需求，大数据通常是依赖敏感数据的业务分析和客户体验应用程序的首选存储库。

五大数据库安全威胁有哪些？

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

2.权限滥用

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

4.审计线索不足

5.不安全的存储介质

前两大威胁可以直接归因于内部威胁的增加。通常，企业网络被认为受到可保护边界的下一代防火墙的保护。但是，一旦恶意行为者越过防火墙，大多数企业中就没有可以检测到横向移动并防止重大数据泄露的保护机制，这对数据构成了重大威胁。

此外，外部威胁是持续不断的，内部流程不足会留下管理漏洞，因此，当今的安全最佳实践要求组织必须采取多层次、多方面的方法来有效保护数据并防止数据泄露。

让我们一起来详细探讨这五种数据库安全威胁。

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

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

此外，当某人在组织内的角色更改时，通常不会更新他对敏感数据的访问权限，以删除其新角色不再需要的权限。

统计称47％的公司用户拥有过多的权利

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

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

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

2. 权限滥用

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

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

数据库系统管理员（DBA）可以无限制地访问数据库中的所有数据。为了获得最佳安全性，DBA在管理数据库时不应直接访问数据库中的应用程序数据（应用程序数据/表）。当DBA直接通过数据库而不是应用程序界面访问应用程序数据时，他绕过了应用程序日志记录和检索限制，并避免了应用程序权限和安全性机制。 当某个使用防泄露方案的客户端收到以下警告：受信任的DBA已直接通过数据库而不是通过某应用程序入口访问了此应用程序表中的敏感数据，这些表包含DBA不应访问的财务信息。这一发现清楚地说明了内部威胁的风险。开发人员通常可以完全访问生产数据库，质量团队可以快照数据库以进行测试，而工程师可以调试实时生产系统。在这些情况下，敏感数据都容易受到特权滥用的影响。

什么是内部威胁?

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

恶意内部人威胁来自企业内部或与企业直接相关的人员（如员工、前雇员、供应商、合作伙伴），他们掌握有关企业的安全实践、数据和计算机系统的内部信息。Palerra曾提交的Insider Threat Spotlight报告指出，平均每50位用户中就有一位是恶意用户。

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

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

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

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

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

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

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

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

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

4. 审计线索不足

接下来，我们将讨论由内部流程不足或漏洞引起的威胁。监控整个企业中的数据访问应该是任何生产数据库的一部分。无法同时监视安全性和合规性异常以及无法收集数据库活动的适当审计详细信息，这在许多层面上都构成了严重的组织风险。

此外，具有薄弱的（或有时不存在）数据库审计机制的组织还发现，它们与行业和政府法规要求不符。旨在防止会计错误和欺诈行为的萨班斯-奥克斯利法案（SOX），以及医疗保健领域的《医疗保健信息携带和责任法案》（HIPAA），都是具有明确数据库审计要求的法规示例。

欧盟新颁布的通用数据保护条例（GDPR）是第一个对未能满足严格的数据保护措施（包括足以满足所有个人数据的审计和违规通知要求的数据库监控功能）的企业处以令人沮丧的罚款数额的条例。

为何审计跟踪具有挑战性

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

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

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

报告称只有19%的公司监控数据库的活动

具有对数据库（合法或恶意获得）的管理访问权的用户可以关闭本机数据库审计以隐藏欺诈性活动。审计功能和职责应与数据库管理员和数据库服务器平台分开，以确保职责之间的强烈隔离。

第二个挑战：审计处理

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

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

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

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

此活动有多个危险信号：

用户突然对从未尝试访问过的数据库产生兴趣

单个用户使用多个帐户

访问数据库的帐户没有权限，这可能会导致一个结论即该帐户根本不应该能够访问此数据库

曾数据泄露报告称超过3500万条记录丢失或被盗，其中44％与医疗或医疗保健相关。

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

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

不幸的是，当今使用的许多安全系统工具无法识别数据泄露，因为它们无法区分对数据库的可疑访问和正常访问。

这些工具产生了太多模糊的告警，这些告警需要进行大量调查分析才能具有可视化，从而造成了过度消耗。通用告警的这种过载是为什么只研究了不到百分之一的关键安全警告的原因。

对等组异常的一个例子是，一个开发人员在其开发工作中访问一个应用程序表，而另一名开发人员访问该表以查看同事的个人数据。

确定风险级别的关键是上下文，特别是要了解用户和对等用户的正常表访问权限。由于恶意内部人员会利用其特权从企业组织中窃取数据，因此无法区分上下文非常危险（请参阅“特权滥用”部分）。

本地审计工具无法区分不正常的用户访问和正常的内容，并经常导致过多的告警，所有这些都必须由专业安全人员进行筛选。

SIEM工具可以减小此范围并使其更易于可视化，但是它们缺乏此领域专业知识，并且仅是从源数据中提取出来，并且只为直接调查提供了有限的可操作选项。需要具有反入侵行为分析以及自动化的数据库监视和检测功能系统，可以提供关注实际威胁所需的情报，以一种上下文关联和可操作的方式关注真正的威胁。

5. 不安全的存储介质

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

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

威胁组合

到目前为止，讨论的每种数据库威胁肯定足以造成数据泄露，但是侥幸的恶意攻击者会寻找阻力最小的途径。许多时候，我们看到了多种威胁的组合使用，这些威胁会加快攻击者对数据的访问，并简化其在未被发现的情况下泄漏数据的能力。这里有一些例子：

当应用程序具有过多特权时，SQL注入或Web Shell会使数据库受到破坏

由于审计线索不足，难以发现特权滥用

当用户或应用程序拥有过多特权时，特权滥用会更加严重

57％的公司认为数据库是内部攻击最脆弱的资产

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

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

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

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

大数据—安全不是重点

大数据领域的某些人认识到对原生安全性和治理能力的需求，有早期的Apache项目正在寻求解决这些需求。不幸的是，这些项目经常有自己的安全问题，这些问题可能直接影响到它们试图保护的大数据系统的安全性。这些问题包括：

向应用程序添加身份验证过程。这需要更多的安全考虑，会使应用程序更加复杂。例如，应用程序需要定义用户和角色。基于此类数据，应用程序可以决定是否授予用户访问系统的权限。

输入验证。我们再次看到困扰RDBMS应用程序的问题又回来了，同样困扰着NoSQL数据库。OWASP现在建议测试NoSQL数据库（例如MongoDB）是否受到SQL注入式攻击。

应用意识。在每个应用程序都需要管理安全性的情况下，它必须了解每个其他应用程序。这是禁用对任何非应用程序数据的访问所必需的。

当新的数据类型添加到数据存储时，数据存储管理员必须弄清楚并确保哪些应用程序无法访问该特定数据。

弱代码。有许多大数据项目和产品，是通过敏捷开发方法实现的，没有为安全性检查和测试分配时间或资源。恶意行为者将利用有缺陷的开发方法，探索漏洞加以利用。

重复数据

NoSQL的强大功能也是它的安全性致命弱点。在这些系统中，数据并非严格保存在唯一表中。而是，将数据复制到许多表以优化查询处理。

因此，不可能根据特定的敏感表对进行分类。相反，可以在不同位置找到此类数据：交易日志、个人帐户详细信息、代表所有的特定表以及甚至可能没有考虑到的其他位置。

隐私问题

尽管我们专注于安全性，但是隐私问题也不容忽视。以医疗大数据平台为例，提供商可以共享患者数据。患者可以访问系统获取遗传信息，然后再访问有关药物信息的系统。

分析此数据的应用程序可以将信息关联起来，以找到与遗传和健康有关的购买趋势。问题在于，最初插入数据时未考虑这种类型的相关性。

因此，数据未被匿名化脱敏，从而可以从更大的趋势图中查明特定的个人。这将违反包括HIPAA和GDPR在内的多项法规。

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

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

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

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

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