应用层加密ALE（Application-Layer Encryption）定义（翻译稿）

以一种简单的方式来解释（杜绍森翻译）

ALE定义：

应用层加密（ALE）是指在将数据发送到数据存储之前对其进行加密。有很多变化形式，但核心就是这样。

几种常见的应用层加密（ALE）形式：

2种典型的实现形式：

1. Code vs. Service：在某些实现中，加密/解密确实发生在应用程序内部，它在程序内部调用encrypt（）或decrypt（）方法实现。还有其他的形式，通过中间服务或代理完成了这项工作。

2. 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）可能很复杂，而且充满陷阱。我们已经看到了应用层加密方案，人们将未保护的加密密钥直接放入数据库中。我们已经看到一个密钥被用于所有值并被重用。我们见过密钥永远不能轮转的设计。这只是冰山一角。

使用TrustZ-ALE，我们努力让任何人都可以直接在他们的应用程序中添加应用层加密，即使是多租户SaaS。我们已经使其面向开发人员，因此没有人会意外地做错事。如果您想了解我们如何帮助您加速和增强数据安全，让我们谈谈。

Definition: Application-layer Encryption (ALE) is when you encrypt data before sending it to a data store. There are many variations, but at its core, that’s it.

Variations

There are three main ways in which implementations may differ:

1. Code vs. Service: In some implementations, the encryption/decryption truly happens inside the application, which calls encrypt() or decrypt() routines. In others, an intermediate service or proxy essentially does that for you.
2. Client vs. Server: Some systems are strict about only encrypting and decrypting data in the client, which brings zero-trust data systems using end-to-end encryption (E2EE). E2EE is a subset of application-layer encryption. But encryption/decryption may alternately happen on the server. For server-side application-layer encryption and SaaS, the most secure option is customer-held keys where each customer keeps their master KEKs in their own KMS. We’ve also seen hybrid models where some data is end-to-end encrypted and other data is server-side encrypted.
3. Key Management: This is where systems differ the most. Ideally, each piece of data gets its own key, called a document encryption key (DEK), and that DEK is wrapped by a master key or key encryption key (KEK). This is called envelope encryption. When done right, the KEK is held in a Key Management Server (KMS) where it can’t be exported and is backed by a Hardware Security Module (HSM). There can be multiple different KEKs at a per-row, per-field, or per-tenant basis, and the KEKs should rotate regularly so the number of KEKs increases over time. But while that’s a strong application-layer encryption approach, plenty of implementations reuse keys to encrypt everything the same way and store keys in insecure places.

Don’t Fall for the B.S.

There’s a pattern repeated by security solution vendors: as soon as some term starts catching on, the whole industry puts it on their website and says that’s what they do. They expand and stretch the definition and muddy the waters until the original meaning is essentially lost. It can be frustrating.

For example, the term “zero-trust” is now prominent industry-wide, but few deserve the label. If you’re curious, we break down trust definitions in our trust models blog.

“Homomorphic encryption” is another example. It has a very specific definition that’s based on a mathematical abstraction called a homomorphism. But security vendors have stretched the definition to mean pretty much anything that involves the use of encrypted data. We used to get excited when we saw someone claiming homomorphic encryption. Now we mostly roll our eyes and move on. 🙄

The latest casualty is “application-layer encryption”, aka application-level encryption, aka ALE. Which is what spurred us to write this blog.

But this is an easy one to check.

A Simple Test

Next time someone says they’re using application-layer encryption, apply this simple test: if you had (possibly stolen) credentials and network access that let you query a data store, and you use that to fetch data, is any of that data encrypted when you get it back? It should be.

An alternate test: if your infrastructure provider gets a law enforcement warrant for your data, and they make the query, will they get back meaningful data? Or will it be garbled?

More concretely, if you’ve turned on encryption for your databases, key-value stores, or object storage in AWS, GCP, or Azure, that’s great, but that isn’t application-layer encryption. It doesn’t matter if the KMS only accepts requests from certain applications. If the data is transparently encrypted at the storage level, it’s not application-layer encryption.

Why It Matters

We’ve recently seen flaws in Azure that caused large numbers of Cosmos DB instances to be publicly accessible. Those impacted companies would have had much less to fear if their exposed data was non-transparently encrypted.

Another reason it matters is that it’s surprisingly easy to accidentally expose data in complex cloud environments. One in five data breaches is due to cloud misconfigurations (per Ponemon). The classic example is when much of the Fortune 500 was found to have open AWS buckets. These issues would have been mitigated by non-transparent encryption.

As a final example, we have the latest T-mobile breach. A hacker got a foothold inside their network and then ferreted out their saved database credentials. Querying the database gave back unencrypted data including social security numbers.

Remember, transparent encryption is useful, but it mostly protects against stolen hard drive attacks and it doesn’t help at all in these scenarios.

Application-layer encryption brings an important layer of protection that means extra hurdles and challenges for attackers. It completely foils many common attacks.

From Here to There

Application-layer encryption isn’t a silver bullet, but it’s critically important. And while the definition is simple, implementing application-layer encryption can be complicated and full of pitfalls. We’ve seen application-layer encryption schemes where people put unwrapped encryption keys directly in the database. We’ve seen a single key get used and reused for all values. We’ve seen designs where keys can never rotate. And that’s the tip of the iceberg.

At IronCore, we’ve worked hard to make it straight-forward for anyone to add application-layer encryption to their app, even if it’s multi-tenant SaaS. We’ve made it developer-proof so no one can accidentally do the wrong thing. If you’d like to understand how we might help you accelerate and supercharge your data security, let’s talk.