12个常见数据库风险

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

创作者为我们提供了所有工具。他们建立了良好的安全措施并记录下来。然而，许多潜在的错误、疏忽和错误既愚蠢又可以理解，使它成为一个无休止的挑战。

为了帮助跟踪并保持警觉，这里列出了即使是我们中最好的人也会绊倒的不同故障模式。

1. 权限管理不到位

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

2. 方便的物理访问

不知道聪明的攻击者可能会在服务器机房内做什么。云公司和主机托管设施在戒备森严的建筑物内提供上锁的笼子，而且访问受限。如果您的数据本地存储在您自己的数据中心，请遵循相同的规则，确保只有受信任的少数人才能访问存放物理磁盘驱动器的房间。

3. 未受保护的备份

一个团队在保护数据库服务器方面做得很好，但却忘记了备份，这种情况并不少见。他们拥有相同的信息，因此需要同样的照顾。磁带、驱动器和其他静态介质应锁在保险箱中，最好是在另一个位置，它们不会被可能毁坏原件的同一火灾或洪水损坏。

4. 未加密的静态数据

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

5. 不使用隐私保护算法

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

6. 缺乏扩散控制

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

7. 缺乏数据库控制

最好的数据库是几十年进化的产物，由无休止的测试和安全研究驱动。选择一个好的。此外，数据库创建者添加了用于管理和限制访问的好工具。你应该使用它们。确保只有正确的应用程序才能看到正确的表。不要对所有应用程序重复使用相同的密码。当然，不要使用默认值。在可行的情况下限制对本地进程或本地网络的访问。

8. 易受攻击的辅助数据库

许多堆栈使用快速的内存缓存（如 Redis）来加快响应速度。这些辅助数据库和内容交付网络通常在数据库中拥有相同信息的副本。花费与正确配置主数据库一样多的时间。

9. 可以访问数据的易受攻击的应用程序

当受信任的应用程序表现不佳时，特别是当受信任的应用程序可以访问所有数据时，所有谨慎的数据库安全都没有多大价值。一个常见问题是SQL 注入，这是一种欺骗编码错误的应用程序将恶意 SQL 传递到数据库的攻击。另一个是应用程序本身的安全性差。在许多架构中，应用程序可以看到一切。如果它不能很好地阻止正确的用户，所有这些数据都可能被泄露出去。

10. 有风险的网络暴露

数据库是生活在没有公共访问的网络部分的理想选择。虽然一些开发人员希望通过向一般互联网开放数据库来简化他们的生活，但任何保护重要信息的人都应该有不同的想法。如果您的数据库只与前端服务器通信，它可以愉快地生活在只有这些前端服务器可以访问它的网络部分。

11. 缺乏诚信管理

现代数据库提供了多种功能，可以防止错误和不一致进入数据集。为数据指定模式可确保各个数据元素符合一组规则。使用事务和锁定可防止在更新一个表或行而另一个未更新时引入错误。部署这些完整性管理选项会增加计算开销，但尽可能多地使用可以减少随机错误的影响，还可以防止用户插入不一致或不正确的数据。

12. 保留不需要的数据

有时最安全的解决方案是销毁数据库。开发团队通常像包装鼠一样思考，为可能永远不会到来的未来存储信息。有时，防止数据泄露的最简单方法是擦除数据。如果您不需要这些位来提供某些未来的服务并且客户永远不会要求查看它，您可以将信息归零并免于保护它。如果您不能完全确定数据不会再次被使用，您可以擦除在线副本，并仅在访问受到进一步限制的深度存储中保留离线备份。