定义：应用层加密（ALE）是指在将数据发送到数据存储之前对其进行加密。有很多变化形式，但核心就是这样。
几种常见的应用层加密（ALE）形式：
３种典型的实现形式：
-
Code vs. Service：在某些实现中，加密/解密确实发生在应用程序内部，它在程序内部调用encrypt（）或decrypt（）方法实现。还有其他的形式，通过中间服务或代理完成了这项工作。
-
Client vs. Server：一些系统严格要求只在客户端加密和解密数据，这导致使用端到端加密（E2EE）的零信任数据系统。E2EE是应用层加密的一个子集。同样，加密/解密也可以在服务器上执行。对于服务器端应用层加密（ALE）和SaaS环境，最安全的选择是客户持有的密钥（customer-held keys），每个客户将其主KEK保存在自己的KMS（密钥管理系统）系统中。我们还看到了混合模型，其中一些数据是端到端加密的，而另一些数据是服务器端加密的。
密钥管理：这是系统差异最大的地方。理想情况下，每条数据都有自己的密钥，称为文档加密密钥（DEK），该DEK由主密钥或密钥加密密钥（KEK）包裹。这被称为信封加密。如果操作得当，KEK将保存在密钥管理服务器（KMS）中，无法导出，并由硬件安全模块（HSM）提供支持。每行、每字段或每租户可以有多个不同的KEK，KEK应该定期轮换，这样KEK的数量就会随着时间的推移而增加。但是，虽然这是一种强大的应用层加密方法，但许多实现都重用密钥以相同的方式加密所有内容，并将密钥存储在不安全的地方。
不要迷恋名词（Don’t Fall for the B.S.）
安全解决方案供应商重复了一种模式：一旦某个术语开始流行，整个行业就会把它放在他们的网站上，并说这就是他们所做的。他们扩大和扩展了定义，把水弄得一团糟，直到基本上失去了最初的含义。这可能会令人沮丧。
例如，“零信任”一词现在在整个行业都很突出，但很少有人配得上这个标签。
“同态加密”是另一个例子。它有一个非常具体的定义，基于一个称为同态的数学抽象。但安全供应商已经将定义扩展到几乎所有涉及使用加密数据的内容。过去，当我们看到有人声称使用同态加密时，我们会很兴奋。现在我们大多翻白眼，继续前进。🙄
最新的受害者是“应用层加密”，也称为应用层加密，也称为ALE。这就是促使我们写这篇文章的原因。什么是应用层加密（ALE）很容易验证。
ALE加密的一个简单测试（A Simple Test）
下次有人说他们正在使用应用层加密(ALE)时，应用这个简单的测试：如果你有（可能是被盗的）凭据和访问权限，可以查询数据存储，并且你用它来获取数据，那么当你取回数据时，这些数据中的任何一个都是加密的吗？如果是就是ALE，否则就不是。（译者注释：例如你有个数据库账户，是否能看到数据库的明文，如果是，就是ALE，否则就不是）
另一个测试是：如果你的基础设施提供商获得了对你数据的执法令（译者注释：想看你的数据），如果只能看到被混淆的数据，那就是ALE，否则就不是ALE。
更具体地说，如果您在AWS、GCP或Azure中为数据库、键值存储或对象存储启用了加密，那很好，但这不是应用层加密（ALE）（译者注释： 作者的意思是，云服务商还是有可能可以看你的数据）。KMS是否只接受某些应用程序的请求并不重要。如果数据在存储级别透明加密，则不是应用层加密。
为什么重要
我们最近在Azure中看到了导致大量Cosmos DB实例可公开访问的缺陷。如果这些受影响的公司暴露的数据是不透明加密的，那么他们就不用那么担心了。
另一个重要的原因是，在复杂的云环境中意外暴露数据非常容易。五分之一的数据泄露是由于云配置错误造成的（根据Ponemon的说法）。一个经典的例子是，发现《财富》500强中的许多公司都有开放的AWS存储桶。这些问题本可以通过不透明的加密来缓解。
作为最后一个例子，我们有最新的T-mobile漏洞。一名黑客在他们的网络中站稳脚跟，然后找到了他们保存的数据库凭据。查询数据库会返回未加密的数据，包括：身份证信息等。
请记住，很多透明加密是有用的，但它主要是防止被盗硬盘攻击。
应用层加密带来了一个重要的保护层，这对攻击者来说意味着额外的障碍和挑战。它完全挫败了许多常见的攻击。
From Here to There
应用层加密（ALE）不是银弹，但它至关重要。虽然定义很简单，但实现应用层加密（ALE）可能很复杂，而且充满陷阱。我们已经看到了应用层加密方案，人们将未保护的加密密钥直接放入数据库中。我们已经看到一个密钥被用于所有值并被重用。我们见过密钥永远不能轮转的设计。这只是冰山一角。
使用海獭数据-ALE，我们努力让任何人都可以直接在他们的应用程序中添加应用层加密，即使是多租户SaaS。我们已经使其面向开发人员，因此没有人会意外地做错事。如果您想了解我们如何帮助您加速和增强数据安全，让我们谈谈。
