12个数据库安全故障和错误

VSole2021-09-14 12:14:03

在当今的大多数企业堆栈中,数据库是我们存储所有秘密的地方。它是安全屋,是待命室,也是用于存储可能非常私密或极具价值的物品的集散地。对于依赖它的数据库管理员、程序员和DevOps团队来说,保护它免受所有入侵是最重要的工作之一。

不过,这项工作并不容易。虽然数据库创建者为我们提供了所有工具,并且建立了良好的安全措施,但是实践过程中存在的无数潜在失误、疏忽以及愚蠢的错误,却使保护数据库安全成为一场无休止的挑战。

为了帮助企业认识错误并保持警觉,以下列出了12种不同的故障模式,即便是团队中最优秀的人也不可避免地会出现这些失误。

1. 权限管理不到位

许多数据库存在于它们自己的设备上,这台设备应该尽可能地锁定。只有必要的用户才能以数据库管理员的身份登录,并且登录应仅限于网络和其他设备的有限范围。防火墙可以阻止IP地址。相同的规则也应适用于操作系统层,而且如果它在虚拟机上运行,则适用于管理程序或云管理。虽然这些限制会减缓软件更新和修复问题的工作,但同时也能限制攻击者可以采取的路径,一切都是值得的。

2. 轻松地物理访问

我们永远不知道狡猾的攻击者可能会在服务器机房内做些什么。云公司和主机托管设施提供的服务等同于在戒备森严的建筑物内提供了一个上锁的笼子,而且访问受限。但如果您没有选择云或主机托管服务,而是将数据本地存储在您自己的数据中心,那么请遵循相同的规则,确保只有受信任的少数人才能访问存放物理磁盘驱动器的房间。

3. 未受保护的备份

一个团队在保护数据库服务器方面做得很好,但却忘记了备份,这种情况并不少见。要知道,它们拥有相同的信息,因此需要获取同样等级的保护。磁盘、驱动器和其他静态介质应锁在保险箱中,而且最好是存放在另一个位置,以免原件遭遇火灾或洪水破坏的同时也损坏了备份。

4. 未加密的静态数据

加扰数据的算法通常是值得信赖的,因为它们已经过广泛测试,并且当前的标准没有公开已知的弱点。如今,为数据库和备份添加良好的加密,是对所有静态数据都很容易实现的。不过,即使算法和实现是安全的,也必须小心保护密钥。云提供商和服务器开发人员正在创建与普通工作流程不同的可信硬件,以便密钥在内部更安全。即便系统不完美,有也总比没有好。当数据需要静态加密一段时间时,有些人更喜欢将密钥放在不同的物理位置,并且处于离线状态;而有些人甚至会打印出密钥信息并将纸锁在保险箱中。

5. 不使用隐私保护算法

只要您可以保护好密钥,加密就能成为保护数据库物理副本的好帮手。各种各样的好算法也会永久地加扰数据。它们不能解决所有问题,但当不需要保留所有敏感数据时,它们会非常有效。最简单的可能只是用随机假名替换名字。数十种其他方法使用恰到好处的数学运算来保护个人数据,同时仍然保留足够的数据以实现数据库的目标。

6. 缺乏增殖控制

当数据被使用时,它会被复制到缓存和运行的服务器中。数据存储架构师的目标是尽量减少副本的数量,并确保在数据不使用时立即销毁它们。许多数据库提供常规镜像或备份选项,作为防御机器故障的功能。虽然这对于提供稳定的服务至关重要,但在设计过程中仔细考虑增殖问题是值得的。在某些情况下,完全有可能在限制猖獗复制的同时不过多地影响服务。有时,如果可以限制攻击者的“入口”数量,那么选择速度较慢、冗余较少的选项可能会更好。

7. 缺乏数据库控制

最好的数据库是由几十年无休止的测试和安全研究驱动进化的产物。选择一个好的数据库是第一要求。此外,数据库创建者还在其中添加了用于管理和限制访问的好工具。请务必记得使用它们。确保只有正确的应用程序才能得到想要的结果,同时记得不要对所有应用程序重复使用相同的密码。当然,也不要使用默认值。在可行的情况下,限制对本地进程或本地网络的访问同样至关重要。

8. 易受攻击的二级数据库

许多堆栈使用高速的内存缓存(如Redis)来加快响应速度。这些二级数据库和内容交付网络通常拥有与数据库中相同的信息副本。正确配置它们所花的时间通常跟配置主数据库一样多。

9. 拥有数据访问权限的脆弱应用程序

当受信任的应用程序——尤其是拥有所有数据访问权限的应用程序——出现故障时,所有部署谨慎的数据库都发挥不了作用。一个常见问题是SQL注入,这种攻击会诱使编码错误的应用程序将恶意SQL传递到数据库。另一个是应用程序本身的安全性差。在许多架构中,应用程序拥有几乎所有数据的访问权限,如果不能对其进行有效控制,所有数据都将面临泄露的风险。

10. 有风险的网络暴露

数据库是生活在没有公开访问的网络部分的理想候选人。虽然一些开发人员希望通过向通用互联网开放数据库来简化他们的生活,但是任何意识到隐私重要性的人都应该有不同的看法。如果您的数据库只与前端服务器通信,那么它就可以愉快地生活在只有这些前端服务器可以访问它的网络部分。

11. 缺乏完整性管理

现代数据库提供了多种功能,可以防止错误和不一致进入数据集。为数据指定模式可确保各个数据元素遵循一组规则。使用数据库事务和锁定(transactions and locking)功能可以防止当一个表/行更新而另一个没有更新时引入错误。部署这些完整性管理选项虽然会增加财务支出,但尽可能多地使用它们可以减少随机错误的影响,还可以防止用户插入不一致或不正确的数据。

12. 保留不需要的数据

有时候,最安全的解决方案是销毁数据库。开发团队的行为通常很像“堆积鼠”(packrat,有在窝中贮藏东西的习性),会为可能永远不会到来的未来存储信息。要知道,有时防止数据泄露最简单的方法就是擦除数据。如果你不需要这些数据来提供一些未来的服务,而且客户永远不会要求查看它们,您可以选择将这些信息归零,也省去了保护它们所需的时间、精力和财力。如果您不能完全确定是否会再次利用这些数据,也可以删除在线副本,并仅将离线备份保存在访问受到进一步限制的深度存储中。

数据库安全
本作品采用《CC 协议》,转载必须注明作者和本文链接
安全级别的顺序对应安全性的增加以及成本和复杂性的增加。用户无需额外软件即可实现较低级别安全,但随着段位提升,难度将逐渐变大,并且需要合适的安全产品和解决方案。
本篇文章是MongoDB数据库信息泄露漏洞复现,记录了实际中常见的MongoDB数据库未授权访问漏洞并如何使用,主要分为七个部分:MongoDB简介、MongoDB安装、MongoDB基本操作、MongoDB相关工具使用、MongoDB漏洞复现、MongoDB实战和MongoDB防御措施。
随着数据规模的TB级增长,通过释放数据价值来完成业务转型与增长,已经成为各行业数字化转型的基本方向。作为数据存储的主要技术手段,数据库系统在整个IT架构中的重要地位不言而喻。然而,伴随互联网技术的飞速发展,数据库被逐渐暴露在更开放、更复杂的网络环境中,传统网络安全体系已不再适用于云计算、多连接等环境,高速的场景迁移和猖獗的黑产交易,更使数据库面临更多安全挑战。
数据库里存储了大量个人信息,包括一些非常敏感的资料,让必须管理数据库的公司十分头痛。如今,运用各种高级工具和技术,数据库开发人员可以在保持信息私密的状态下放心执行各种操作。
数据库的安全性是指保护数据库免受未经授权的访问、篡改、破坏或丢失。
针对以上难点问题,目前业界逐步采用部署数据库安全审计防护系统的方式来解决。在保障业务连续性方面,大型国有银行数审系统针对生产系统服务器的性能指标和其自身的资源开销设置监控阈值和熔断策略,防止因数审系统占用过多系统资源而对生产系统性能造成业务影响。在数字化转型和数据安全治理齐头并进的过程中,部署数审系统对于银行业来说乃是大势所趋。
近日,有关“国内45亿个人信息被公开泄露”的消息引发大众关注。天融信数据库安全网关可实时监控数据库健康情况,并对数据库内部高权限人员进行有效管控,同时有效阻断高危的SQL操作或误操作。在“最小的代价换取尽量大的安全提升”原则的指导下,天融信帮助该集团客户实现了数据库内部的全面安全防护。自主创新是天融信的基因,开放融合是天融信的理念。
在当今的大多数企业堆栈中,数据库是我们存储所有秘密的地方。它是安全屋,是待命室,也是用于存储可能非常私密或极具价值的物品的集散地。对于依赖它的数据库管理员、程序员和DevOps团队来说,保护它免受所有入侵是最重要的工作之一。
VSole
网络安全专家