在当今的大多数企业技能堆栈中，数据库是聚集数字资产的重地，对于依赖它的数据库管理员、程序员和DevOps团队来说，保护数据库免受攻击是最重要的工作之一。
但是，虽然有足够多的安全工具，接纳了良好的安全措施，依然会有许多潜在的错误、疏忽甚至愚蠢行为，为数据库安全防护埋下隐患。以下我们整理了十二个最危险的“地雷”：
01
权限管理不到位
许多数据库运行在本地物理服务器上，这台机器应该尽大概地被锁定，只有必要的用户才能以数据库管理员的身份登录，而且登录应仅限于网络和其他机器的狭窄范围，防火墙可以阻止IP地址。相同的规则也应适用于操作系统层，如果它在假造机上运行，则适用于管理程序或云管理。这些限制会减慢更新软件和修复问题的工作，但限制攻击者的可用路径是值得的。
02
松垮的物理访问控制
你永久不知道调皮的攻击者大概会在服务器机房内做什么。云公司和主机托管办法在警备森严的建筑物内提供上锁的笼子，而且访问受限。如果您的数据本地存储在您自己的数据中央，请遵循相同的规则，确保只有受信任的少数人才能访问存放物理磁盘驱动器的房间。
03
未受保护的备份
很多时候，一个团队在保护数据库服务器方面做得很好，但却忘记了保护备份，这种环境并不少见。备份与原件拥有相同的信息，因此需要同样品级的防护。磁带、驱动器和其他静态介质应锁在保险箱中，最好是在另一个位置，这样它们不会被一场大火或者洪灾与原件一起被毁掉。
04
未加密的静态数据
加扰数据的算法通常是值得信任的，因为它们已经过广泛的测试，而且当前的标准没有发现公开的弱点。为数据库添加良好的加密技能，可以轻松地对所有静态数据进行备份。但纵然算法和实现是安全的，也必须警惕保护密钥。
云提供商和服务器开发人员正在创建与平凡工作流程不同的可信硬件，因此密钥在内部更安全。纵然系统不完美，也有总比没有好。当数据将在一段时间内保持加密状态时，有些人更喜好将密钥放在不同的物理位置，最好是离线的。有些人甚至打印出钥匙放在保险箱中。
05
未使用隐私保护算法
只要您可以保护密钥，加密就是保护数据库物理副本的好工具。各种各样的好算法也会永久地加扰数据。虽然它们无法解决所有问题，但当不需要保留所有敏感数据时，它们会非常有用。最简单的大概只是用随机假名更换名字。数十种其他方法使用恰到好处的数学运算来保护个人数据，同时仍然保留足够的数据来实现数据库的目标。
06
缺乏扩散控制
当数据被使用时，它会被复制到缓存和运行的服务器中。数据存储架构师的目标是尽量减少副本的数量，并确保一旦数据不被使用就将其销毁。许多数据库提供常规镜像或备份选项，以防装备故障。虽然这对于提供稳定的服务至关重要，但在设计过程中仔细思量扩散风险是值得的。在某些环境下，可以限制过量的复制而不会过多地影响服务。有时，如果可以限制攻击者的攻击面，那么选择速度较慢、冗余较少的方案大概会更好。
07
缺乏数据库控制
最好的数据库是几十年进化的产物，由无休止的测试和安全研究驱动其不停发展，其安全性能是毋庸置疑的。此外，数据库厂商添加了用于管理和限制访问的好工具。用户需要用好这些工具，确保只有精确的应用程序才能访问精确的表。不要对所有应用程序重复使用相同的暗码。当然，不要使用默认值。在可行的环境下限制对本地历程或本地网络的访问。
08
易受攻击的辅助数据库
许多技能堆栈使用高速内存缓存（如Redis）来加快响应速度。这些辅助数据库和内容交付网络通常在数据库中拥有相同信息的副本。耗费与精确配置主数据库一样多的时间。
09
可访问数据的易受攻击的应用程序
当受信任的应用程序体现不佳时，特别是当受信任的应用程序可以访问所有数据时，所有的数据库安全措施都没有多大意义。一个常见问题是SQL注入，这是一种利用编码错误的应用程序将恶意SQL传递到数据库的攻击。另一个是应用程序本身的安全性差。在许多架构中，应用程序可以看到一切信息。如果不能很好地阻止过度访问，所有这些数据都大概被泄露出去。
10
有风险的网络暴露
数据库通常被放置在没有公共访问的内部网络区域。虽然一些开发人员盼望通过互联网访问数据库来简化他们的生活，但任何保护重要信息的人都不应该有这种想法。
11
缺乏诚信管理
当代数据库提供了多种功能，可以防止错误和不一致进入数据集。为数据指定模式可确保各个数据元素符合一组规则。使用事务和锁定可防止在更新一个表或行而另一个未更新时引入错误。部署这些完备性管理选项会增加计算开销，但尽大概多地使用可以减少随机错误的影响，还可以防止用户插入不一致或不精确的数据。
12
保留不需要的数据
有时最安全的解决方案是销毁数据库。开发团队经常会像花栗鼠一样，存储一些永久用不上的信息。有时，防止数据泄露的最简单方法是擦除数据。如果您不能完全确定数据不会再次被使用，您可以删除在线副本，并仅在访问受到进一步限制的深度存储中保留离线备份。 |
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡
