在当今的大多数企业堆栈中，数据库是我们存储所有秘密的地方。它是安全屋，是待命室，也是用于存储可能非常私密或极具价值的物品的集散地。对于依赖它的数据库管理员、程序员和DevOps团队来说，保护它免受所有入侵是最重要的工作之一。
不过，这项工作并不容易。虽然数据库创建者为我们提供了所有工具，并且建立了良好的安全措施，但是实践过程中存在的无数潜在失误、疏忽以及愚蠢的错误，却使保护数据库安全成为一场无休止的挑战。
为了帮助企业认识错误并保持警觉，以下列出了12种不同的故障模式，即便是团队中最优秀的人也不可避免地会出现这些失误。
1. 权限管理不到位
许多数据库存在于它们自己的设备上，这台设备应该尽可能地锁定。只有必要的用户才能以数据库管理员的身份登录，并且登录应仅限于网络和其他设备的有限范围。防火墙可以阻止IP地址。相同的规则也应适用于操作系统层，而且如果它在虚拟机上运行，则适用于管理程序或云管理。虽然这些限制会减缓软件更新和修复问题的工作，但同时也能限制攻击者可以采取的路径，一切都是值得的。
2. 轻松地物理访问
我们永远不知道狡猾的攻击者可能会在服务器机房内做些什么。云公司和主机托管设施提供的服务等同于在戒备森严的建筑物内提供了一个上锁的笼子，而且访问受限。但如果您没有选择云或主机托管服务，而是将数据本地存储在您自己的数据中心，那么请遵循相同的规则，确保只有受信任的少数人才能访问存放物理磁盘驱动器的房间。
3. 未受保护的备份
一个团队在保护数据库服务器方面做得很好，但却忘记了备份，这种情况并不少见。要知道，它们拥有相同的信息，因此需要获取同样等级的保护。磁盘、驱动器和其他静态介质应锁在保险箱中，而且最好是存放在另一个位置，以免原件遭遇火灾或洪水破坏的同时也损坏了备份。
4. 未加密的静态数据
加扰数据的算法通常是值得信赖的，因为它们已经过广泛测试，并且当前的标准没有公开已知的弱点。如今，为数据库和备份添加良好的加密，是对所有静态数据都很容易实现的。不过，即使算法和实现是安全的，也必须小心保护密钥。云提供商和服务器开发人员正在创建与普通工作流程不同的可信硬件，以便密钥在内部更安全。即便系统不完美，有也总比没有好。当数据需要静态加密一段时间时，有些人更喜欢将密钥放在不同的物理位置，并且处于离线状态;而有些人甚至会打印出密钥信息并将纸锁在保险箱中。
5. 不使用隐私保护算法
只要您可以保护好密钥，加密就能成为保护数据库物理副本的好帮手。各种各样的好算法也会永久地加扰数据。它们不能解决所有问题，但当不需要保留所有敏感数据时，它们会非常有效。最简单的可能只是用随机假名替换名字。数十种其他方法使用恰到好处的数学运算来保护个人数据，同时仍然保留足够的数据以实现数据库的目标。
6. 缺乏增殖控制
当数据被使用时，它会被复制到缓存和运行的服务器中。数据存储架构师的目标是尽量减少副本的数量，并确保在数据不使用时立即销毁它们。许多数据库提供常规镜像或备份选项，作为防御机器故障的功能。虽然这对于提供稳定的服务至关重要，但在设计过程中仔细考虑增殖问题是值得的。在某些情况下，完全有可能在限制猖獗复制的同时不过多地影响服务。有时，如果可以限制攻击者的“入口”数量，那么选择速度较慢、冗余较少的选项可能会更好。
7. 缺乏数据库控制
最好的数据库是由几十年无休止的测试和安全研究驱动进化的产物。选择一个好的数据库是第一要求。此外，数据库创建者还在其中添加了用于管理和限制访问的好工具。请务必记得使用它们。确保只有正确的应用程序才能得到想要的结果，同时记得不要对所有应用程序重复使用相同的密码。当然，也不要使用默认值。在可行的情况下，限制对本地进程或本地网络的访问同样至关重要。
8. 易受攻击的二级数据库
许多堆栈使用高速的内存缓存(如Redis)来加快响应速度。这些二级数据库和内容交付网络通常拥有与数据库中相同的信息副本。正确配置它们所花的时间通常跟配置主数据库一样多。
9. 拥有数据访问权限的脆弱应用程序
当受信任的应用程序——尤其是拥有所有数据访问权限的应用程序——出现故障时，所有部署谨慎的数据库都发挥不了作用。一个常见问题是SQL注入，这种攻击会诱使编码错误的应用程序将恶意SQL传递到数据库。另一个是应用程序本身的安全性差。在许多架构中，应用程序拥有几乎所有数据的访问权限，如果不能对其进行有效控制，所有数据都将面临泄露的风险。
10. 有风险的网络暴露
数据库是生活在没有公开访问的网络部分的理想候选人。虽然一些开发人员希望通过向通用互联网开放数据库来简化他们的生活，但是任何意识到隐私重要性的人都应该有不同的看法。如果您的数据库只与前端服务器通信，那么它就可以愉快地生活在只有这些前端服务器可以访问它的网络部分。
11. 缺乏完整性管理
现代数据库提供了多种功能，可以防止错误和不一致进入数据集。为数据指定模式可确保各个数据元素遵循一组规则。使用数据库事务和锁定(transactions and locking)功能可以防止当一个表/行更新而另一个没有更新时引入错误。部署这些完整性管理选项虽然会增加财务支出，但尽可能多地使用它们可以减少随机错误的影响，还可以防止用户插入不一致或不正确的数据。
12. 保留不需要的数据
有时候，最安全的解决方案是销毁数据库。开发团队的行为通常很像“堆积鼠”(packrat，有在窝中贮藏东西的习性)，会为可能永远不会到来的未来存储信息。要知道，有时防止数据泄露最简单的方法就是擦除数据。如果你不需要这些数据来提供一些未来的服务，而且客户永远不会要求查看它们，您可以选择将这些信息归零，也省去了保护它们所需的时间、精力和财力。如果您不能完全确定是否会再次利用这些数据，也可以删除在线副本，并仅将离线备份保存在访问受到进一步限制的深度存储中。
原文链接：http://www.d1net.com/security/news/571836.html
