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