数据库安全的十二颗“地雷”

2021年9月26日作者：GoUpSec

在当今的大多数企业技术堆栈中，数据库是聚集数字资产的重地，对于依赖它的数据库管理员、程序员和DevOps团队来说，保护数据库免受攻击是最重要的工作之一。

但是，虽然有足够多的安全工具，采取了良好的安全措施，依然会有许多潜在的错误、疏忽甚至愚蠢行为，为数据库安全防护埋下隐患。以下我们整理了十二个最危险的“地雷”：

权限管理不到位

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

松垮的物理访问控制

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

未受保护的备份

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

未加密的静态数据

加扰数据的算法通常是值得信赖的，因为它们已经过广泛的测试，并且当前的标准没有发现公开的弱点。为数据库添加良好的加密技术，可以轻松地对所有静态数据进行备份。但即使算法和实现是安全的，也必须小心保护密钥。

云提供商和服务器开发人员正在创建与普通工作流程不同的可信硬件，因此密钥在内部更安全。即使系统不完美，也有总比没有好。当数据将在一段时间内保持加密状态时，有些人更喜欢将密钥放在不同的物理位置，最好是离线的。有些人甚至打印出钥匙放在保险箱中。

未使用隐私保护算法

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

缺乏扩散控制

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

缺乏数据库控制

最好的数据库是几十年进化的产物，由无休止的测试和安全研究驱动其不断发展，其安全性能是毋庸置疑的。此外，数据库厂商添加了用于管理和限制访问的好工具。用户需要用好这些工具，确保只有正确的应用程序才能访问正确的表。不要对所有应用程序重复使用相同的密码。当然，不要使用默认值。在可行的情况下限制对本地进程或本地网络的访问。

易受攻击的辅助数据库

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

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

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

有风险的网络暴露

数据库通常被放置在没有公共访问的内部网络区域。虽然一些开发人员希望通过互联网访问数据库来简化他们的生活，但任何保护重要信息的人都不应该有这种想法。

缺乏诚信管理

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

保留不需要的数据

有时最安全的解决方案是销毁数据库。开发团队经常会像花栗鼠一样，存储一些永远用不上的信息。有时，防止数据泄露的最简单方法是擦除数据。如果您不能完全确定数据不会再次被使用，您可以删除在线副本，并仅在访问受到进一步限制的深度存储中保留离线备份。