支持业务或流程的数据，需要立即访问。因此，供应商、分析师和工程师花费大量时间优化数据库性能也就不足为奇了。以至于性能的概念往往掩盖了同样重要的数据安全问题。

在数据库技术的早期，主要瓶颈是硬件，这使得可访问性和安全性相互矛盾，因为它们本质上是在争夺同样有限的计算资源。

现在，计算资源是几乎是无限的，它是在该组织的运作，该速度已成为更大的问题。像创建新数据库这样的操作——在本地硬件世界中很容易需要几个月的时间——现在只需要几分钟。在现代 DevOps 世界中，每个月都有成百上千的产品发布，工程团队在安全团队做出反应之前就创建了新的基础设施。

这就是为什么它已经成为明显的是t他架构性能优化纯粹的威胁者是同样进行了优化。这一启示已经过去了几十年，但没有将安全性纳入数据库设计和资源分配仍然是一个普遍存在的问题。

除了性能和安全性之间不断的拉锯战之外，还有另一个同样重要的成本概念。很多时候，决定平衡点的都是沉默的法官。同样，这种平衡通常不会有利于安全。

数据库安全能力

在传统的本地数据库世界中，安全问题从概念上归结为适当的资源工程。数据库安全功能，如监控和审计所需的系统资源，允许的资源越多，他们期望的性能就越好。

数据库服务器本身在组织范围内运行，允许更严格的访问控制和使用情况的可见性——只有受信任的用户才能访问数据库运行的基础设施。此外，生产应用程序与数据库的耦合非常紧密，通常除了少数管理员之外没有人允许直接访问这些数据库。

这并不是说数据泄露没有发生。他们确实做到了，但它们远不及我们今天所遇到的问题的比例。

那么，人们理所当然地想知道，云是否应该凭借其所有敏捷资源工程功能和基础设施即代码 (IaC) 使数据库安全变得更容易？在某种程度上，它确实做到了：在云中管理和保护数据从未如此便宜。但它也从未觉得如此困难。

云时代的数据安全

想象一下保护现代数据层的复杂性呈指数级增长。如今，一个典型的组织不再使用几种精心配置的本地数据库，而是使用分布在多个云中的大量数据库、数据仓库和管道。

将按需动态配置任何类型数据库的 DevOps 模型添加到等式中，通常针对每个微服务，很少有敏捷控件可用于正确调节对它们的访问。

然而，这并不全是厄运和忧郁。以云和 IaC 明显有助于数据库安全的最佳示例之一为例：自动补丁管理的概念。这种已经变得普遍的做法为组织节省了数千小时的劳动力，毫无疑问，潜在的违规成本还会增加数百万。这可能是许多 IT 专业人士认为公共云在安全性方面优于他们自己的数据中心的原因之一——它可以帮助轻松避免基本的人为错误，例如未能安装最新补丁。

然而，云中数据安全的基本困境仍然存在：实施任何控制来监控数据库访问仍然意味着您处于性能敏感的道路上。

一个简单的读取请求要求数据库执行诸如语法分析、查询优化、计划执行和从物理媒体获取结果等任务。在该路径前面放置一个控制点，您不可避免地会减慢链中的其余进程。

在加强安全方面的一些不太成功的尝试包括引入直接位于基础设施中的代理，对所有活动进行背景分析，以期捕捉未经授权的访问或任何可疑活动。

然而，参与这些检查每一个微秒的意思是小号放缓关闭应用程序，这反过来又影响了用户体验，最终的整体业务表现。例如，银行家无需意识到，在发放贷款时，与数小时前相比，在几秒钟内获取关键客户信息之间存在很大差异。

在提高安全性的同时回避性能问题

幸运的是，还有其他方法可以保护数据，这些方法已被证明更有效。以异步分析为例，它假设未经授权的读取请求可以到达数据层，只要结果可以被阻止。通过这种方法，对数据层的读取请求没有任何延迟，而数据层正在并行处理它们以确定是否应该允许或阻止相应的结果。

当然，为了提供这项技术，您还需要采用某种形式的无状态代理，将所有会话状态管理交给数据层连接。这种无状态代理将拦截任何类型的数据请求，并通过异步分析提供对性能几乎没有影响的结果。

除了技术创新之外，一些保护数据云的新方法侧重于如何为数据提供安全性所涉及的特定流程和实践。数据安全已经从安全团队的特权演变为共同的责任，这已经不是什么秘密了。例如，考虑到数据基础设施是通过他们编写的代码立即扩展和启用的事实，工程承担了更重的负担。

例如，如今，许多采用 DevOps 的工程团队每年以数千次发布的频率发布新代码。以如此高的速度，确保高数据安全标准需要安全即代码等实践，这些实践将安全测试、扫描和访问策略直接实施到持续集成和部署 (CI/CD) 管道中。这些检查中的每一项都使工程团队能够在开发过程中更早地了解和修复安全问题。因此，安全问题立即得到解决，避免了开发过程结束时潜在的代价高昂的延迟和返工。

这些新方法虽然仍处于采用初期，但有理由感到乐观。事实上，我们当中比较乐观的人甚至可能会说，数据库性能和安全性之间永无止境的拉锯战可能已经成为过去。