In the era of Facebook data scandals and Edward Snowden whistleblowers, data has never been as valuable as it is today.

在Facebook数据丑闻和Edward Snowden告密者时代，数据从未像今天这样有价值。

Consumers are starting to catch on that their data is actually valuable. Enterprises and businesses have always understood (and profited from) the value of data. When you have something valuable, you protect it.

消费者开始发现他们的数据确实有价值。 企业和企业始终了解数据的价值(并从中获利)。 当您拥有有价值的东西时，就可以保护它。

One of the most powerful tools we have to protect application-layer data is encryption, but it’s challenging to evaluate and integrate an application layer encryption system into products, processes, and businesses.

加密是保护应用层数据的最强大工具之一，但是要评估并将应用层加密系统集成到产品，流程和业务中是一项挑战。

Depending on who your customers are, different values drive the demands for data protection. We explore six focusing questions to ask before committing to application layer data encryption.

根据您的客户是谁，不同的价值驱动着数据保护的需求。 在致力于应用程序层数据加密之前，我们将探讨六个重点问题。

问题1：为什么需要应用程序层数据加密？ (Question 1: Why Do You Need Application Layer Data Encryption?)

So, you think there’s a need to encrypt your data. There probably is. But why? By encrypting the data, what is the value-add to the customer or end-user?

因此，您认为有必要对数据进行加密。 可能有。 但为什么？ 通过加密数据，对客户或最终用户的增值是什么？

好答案 (Good answers)

Often, products in regulated industries, such as health care, defense, and finance, require it as a prerequisite to enter the market. Regulations often drive the requirements, such as GDPR, CCPA, HIPAA, FIPS, Common Criteria, NIST Cybersecurity Framework, etc. — but not always.

通常，诸如医疗保健，国防和金融等受管制行业中的产品都要求将其作为进入市场的先决条件。 法规通常会推动要求，例如GDPR， CCPA ，HIPAA，FIPS，通用标准，NIST网络安全框架等，但并非总是如此。

When consumer products integrate encryption, what they’re saying is that data is valuable and worth protecting.

当消费类产品集成了加密功能时，他们的意思是数据非常宝贵且值得保护。

For example, the secure messaging app Signal holds a strong belief that your communications should be private, and the encryption enforces that privacy — without the end-user even having to think about it.

例如，安全的消息传递应用程序Signal坚信您的通信应该是私有的，并且加密可以实现这种隐私-最终用户甚至不必考虑它。

错误的答案 (Bad answers)

Any request not linked to a specific business goal or concrete go-to-market strategy is a red flag.

任何与特定业务目标或具体的上市策略无关的请求都是一个危险信号。

For example, if an investor says to a founder: “You’ll have better market adoption with encryption in your product, so you should add it ASAP.” This is terrible advice. It prescribes a direction without expanding on the underlying value system that’s driving the demand.

例如，如果一位投资者对创始人说：“您的产品将采用加密技术，从而可以更好地被市场采用，因此您应该尽快添加它。” 这是可怕的建议。 它规定了一个方向，而不会扩展驱动需求的基础价值体系。

Even if it’s true, it doesn’t help the founder build a secure system, because it fails to speak to a specific threat model.

即使是事实，它也无法帮助创始人建立安全的系统，因为它无法说明特定的威胁模型。

问题2：您的特定威胁模型是什么？ (Question 2: What Is Your Specific Threat Model?)

Just encrypting data solves nothing.

仅加密数据无法解决任何问题。

Encrypting data transforms the problem of protecting your sensitive data into the problem of protecting your encryption keys. This way, your encrypted data can safely traverse less-secure and untrusted parts of the system.

加密数据将保护敏感数据的问题转变为保护加密密钥的问题。 这样，您的加密数据可以安全地遍历系统中不安全和不受信任的部分。

To define a threat model is to identify the parts of your system that are trusted and untrusted. Risk only comes from sensitive data passing over untrusted portions. Within the untrusted portions of your system, the following three axes segregate risk even further:

定义威胁模型是确定系统中受信任和不受信任的部分 。 风险仅来自敏感数据经过不可信部分的传递。 在系统的不受信任的部分中，以下三个轴将风险进一步隔离：

1. Space: A compromise in one part of the system should not compromise any other parts of the system.空间：系统某一部分的妥协不应损害系统的任何其他部分。
2. Time: A compromise in the past should not compromise the future operation.时间：过去的妥协不应该损害未来的运作。
3. Use: A compromise related to over-use should not be possible.使用：与过度使用有关的折衷办法是不可能的。

In the end, you’ll have an answer to the question: “Secure against who or what?”

最后，您将得到以下问题的答案：“确保对抗谁或什么？”

好的威胁模型 (Good threat models)

The more explicitly defined boundaries between trusted and untrusted, the better.

可信和不可信之间的界限越明确，越好。

For example, maybe you committed to protecting the PII (Personally Identifiable Information) in your logs.

例如，也许您致力于保护日志中的PII(个人身份信息)。

Then, it’s straightforward to satisfy your threat model by encryption your logs in the trusted portion of your system (your server). Now, you can safely offload logs to the untrusted part of your system, your log backup solution.

然后，通过对系统(服务器)受信任部分中的日志进行加密，可以轻松满足威胁模型的要求。 现在，您可以安全地将日志卸载到系统的不受信任的部分，即日志备份解决方案。

不良威胁模型 (Bad threat models)

Vague boundaries between trusted and untrusted parts of your system are insecure because different interpretations lead to miscommunications.

系统的受信任和不受信任的部分之间的模糊边界是不安全的，因为不同的解释会导致通信错误。

Further, if you declare too much of your system to be “trusted,” it exposes you (and your customers) to a broader attack surface. Finally, if you don’t segment your risk domains, then a single breach may compromise the entire system.

此外，如果您声明太多系统无法“信任”，那么您(和您的客户)将面临更广泛的攻击面。 最后，如果您不对风险域进行细分，那么一次违规可能会损害整个系统。

问题3：应用程序层加密的总拥有成本是多少？ (Question 3: What Is the Total Cost of Ownership of Application Layer Encryption?)

The total cost of ownership is dependent on your implementation.

总体拥有成本取决于您的实施。

建立你自己的 (Build your own)

• Upfront costs: Extremely high.前期成本：极高。
• Ongoing costs: Extremely high.持续成本：极高。

Unless you have an entire product security team, crypto team, SRE team, QA team, and in-house red-team, and you’re building an extremely focused highly-specialized system, this approach is probably not for you.

除非您拥有整个产品安全团队，加密团队，SRE团队，QA团队和内部团队， 并且您要构建一个高度专注的高度专业化的系统，否则这种方法可能不适合您。

Building an encryption system in-house incurs the most cost, risk, and long-term engineering debt (in the form of bugs, legacy code, and non-standard implementation).

内部构建加密系统会招致最大的成本，风险和长期工程负担(以错误，遗留代码和非标准实现的形式)。

Even if open source or third-party managed services do not do exactly what you’re looking for, perhaps it’s worthwhile asking yourself why the standards chose not to.

即使开放源代码或第三方托管服务不能完全满足您的要求，也许还是值得问自己，为什么标准选择不这样做。

部署开源项目 (Deploy an open-source project)

• Upfront costs: Medium.前期费用：中。
• Ongoing costs: High.持续成本：高。

Although using open-source encryption tools can significantly mitigate upfront costs, the open-source community provides little to no cost mitigation for on-going expenses.

尽管使用开源加密工具可以显着降低前期成本，但开源社区几乎没有或根本没有降低持续费用的成本。

For example, Hashicorp’s Encryption as a Service is part of its open-source offering. Still now, in addition to running your own set of highly available services, you also have ensured the high availability of theirs.

例如， Hashicorp的加密即服务是其开源产品的一部分。 到目前为止，除了运行您自己的一组高可用性服务之外，您还确保了其高可用性。

Often, this forces you to hire an area expert to maintain and scale the solution. And how about the long-term security of running an open-source project?

通常，这迫使您聘请区域专家来维护和扩展解决方案。 以及运行开源项目的长期安全性如何？

To avoid security breaches from newly discovered security vulnerabilities, you have to update regularly. Lastly, consider your engineers: now, they’ll need a set of debugging tools for the encrypted portions of your system. Was it included as part of the open-source project, or are critical engineering needs not met?

为避免新发现的安全漏洞造成的安全漏洞，您必须定期进行更新。 最后，考虑一下您的工程师：现在，他们将需要一套调试工具来对系统的加密部分进行调试。 它是否包含在开源项目中，还是没有满足关键的工程需求？

使用第三方托管服务 (Use a third-party managed service)

Upfront costs: Low.Ongoing costs: Medium.

前期成本：低;持续成本：中。

Fully-managed services are excellent because they just work. The initial overhead is low. They abstract away all the grit of the technical implementation.

全面管理的服务非常出色，因为它们可以正常工作。 初始开销很低。 他们将技术实施的所有要点抽象出来。

Backward compatibility works. As for security updates, you don’t even need to think about them outside of just updating your software.

向后兼容。 至于安全更新，您甚至不必在更新软件之外就考虑它们。

So, what’s the catch? Why do we still see home-baked encryption systems?

那么，有什么收获呢？ 为什么我们仍然看到自制的加密系统？

Because finding a strong threat model in third-party managed services is difficult. For example, most KMS solutions require your key to be in the cloud, their cloud, (prohibiting you and your customers from using on-prem keys).

因为很难在第三方托管服务中找到强大的威胁模型。 例如，大多数KMS解决方案都要求您的密钥位于云及其云中(禁止您和您的客户使用本地密钥)。

If you’re going after health care, defense, and finance — tread carefully, secrets are seldom permitted in the cloud (like encryption keys). Even if you’re not in those verticals, watch out.

如果您要注意医疗保健，国防和金融事务-谨慎行事，则云中很少允许使用秘密(例如加密密钥)。 即使您不在这些行业中，也要当心。

For example, consider a threat model that includes privacy against third-party services, such as Google’s Pub/Sub service. So, if you encrypt your data with Google’s KMS services, and then send it over Google’s PubSub, what exactly are you doing? And why?

例如，考虑一种威胁模型，其中包括针对第三方服务(例如Google的发布/订阅服务)的隐私。 因此，如果您使用Google的KMS服务加密数据，然后通过Google的PubSub发送数据，那么您到底在做什么？ 又为什么呢

问题4：会扩展吗？ (Question 4: Will It Scale?)

As you 10x, from 10K to 100K and 1M clients, what happens to the encryption and decryption services? Will they be able to keep up?

当您从10K到100K和1M客户端增加10倍时，加密和解密服务会发生什么？ 他们能跟上吗？

好答案 (Good answers)

Systems that scale tend to offload the bulk of encryption and decryption operations to the pieces of software performing those operations.

规模化的系统倾向于将大量的加密和解密操作转移给执行这些操作的软件。

To achieve this, you’ve got to securely distribute keys to parts of your system that need them, and that secure key distribution mechanism needs to scale well too.

为了实现这一目标，您必须将密钥安全地分发到需要它们的系统部分，并且安全密钥分发机制也需要很好地扩展。

错误的答案 (Bad answers)

When many clients blast a centralized service with “this is my plaintext, please encrypt it” and “this is my ciphertext, please decrypt it” are the most expensive types of systems to scale.

当许多客户使用“这是我的纯文本，请对其进行加密”和“这是我的密文，请对其进行解密”来破坏集中式服务时，这是扩展规模最昂贵的系统类型。

Scaling will increase cost, both in the form of dedicated engineering time, SRE time, and raw cloud-compute time (depending on the type of encryption system).

扩展将以专用的工程时间，SRE时间和原始云计算时间(取决于加密系统的类型)的形式增加成本。

It might be tempting to use a centralized system as a root of trust, and build on top of that — but now you’re building an in-house solution.

使用集中式系统作为信任的基础并以此为基础可能很诱人，但是现在您正在构建内部解决方案。

问题5：它将支持客户控制的密钥和本地密钥所有权吗？ (Question 5: Will It Support Customer-Controlled Keys and On-Prem Key Ownership?)

On-prem key ownership comes from a threat model that is suspect of cloud-deployed services. Many customers will not explicitly ask for this, but most enterprise customers will expect it — especially in regulated verticals such as health care, defense, and finance.

本地密钥所有权来自可疑云部署服务的威胁模型。 许多客户不会明确要求这样做，但是大多数企业客户会希望这样做-尤其是在诸如医疗保健，国防和金融等受监管的垂直行业中。

In consumer space, we see a spike of customer-controlled keys too, especially with the advent of cryptocurrency wallets or even secure communications apps.

在消费者领域，我们也看到了由客户控制的密钥的激增，特别是随着加密货币钱包甚至安全通信应用程序的出现。

好答案 (Good answers)

Providing the option for on-prem key ownership for when your customer’s threat model requires it today will ensure you never get locked out of a market due to insufficient security.

在客户的威胁模型今天需要时提供本地密钥所有权的选项，将确保您永远不会由于安全性不足而被锁定在市场之外。

A smooth, non-disruptive, and self-service transition mechanism from in-cloud key ownership to on-prem key ownership, is also expected.

从云内密钥所有权到本地密钥所有权的平稳，无中断和自助式过渡机制也有望实现。

错误的答案 (Bad answers)

Ignoring this requirement as a “good problem to have” will make it extremely difficult to break into pragmatic majority markets when you attempt to cross the chasm in any well-regulated vertical.

忽略此要求是“要解决的好问题”，这将使您在尝试跨越任何受到良好监管的垂直领域的鸿沟时都很难进入务实的多数市场。

Even in the consumer space, there is a shift towards on-device key ownership for those that take their security seriously.

即使在消费者领域，对于那些认真对待安全性的人来说，它们也朝着设备上的密钥所有权转移。

问题6：它是否支持加密敏捷性？ (Question 6: Does It Support Crypto-Agility?)

Crypto-agility refers to the ability to dynamically switch from one cipher-suite to another, without having to release new software. Crypto-Agility is a critical aspect of modern application layer encryption schemes.

加密敏捷性是指无需发布新软件即可从一个密码套件动态切换到另一个密码套件的能力。 加密敏捷性是现代应用程序层加密方案的关键方面。

For instance, imagine you decide to use RSA-2048 in a secure key delivery mechanism, but RSA-2048 will one day be obsolete. As attacks evolve, building secure systems need crypto-agility to pivot off compromised encryption algorithms and compromised implementations quickly.

例如，假设您决定在安全的密钥传递机制中使用RSA-2048，但是有一天RSA-2048将被淘汰。 随着攻击的发展，构建安全系统需要加密敏捷性，以Swift解决受损的加密算法和受损的实现。

好答案 (Good answers)

A well versioned, dynamic, and centralized control pane is the only way to provide crypto-agility for application-layer encryption.

版本良好，动态且集中的控制面板是为应用程序层加密提供加密敏捷性的唯一方法。

Specifically, decisions on: “What crypto-algorithm should this client use?” or even “What key should that client use to encrypt?” should be centralized and controlled from a centralized single pane of glass — not hardcoded or decided by the clients.

具体来说，以下决策：“此客户端应使用哪种加密算法？” 甚至“该客户端应使用什么密钥进行加密？” 应该从一个集中的单一窗格进行集中控制，而不是由客户进行硬编码或确定。

错误的答案 (Bad answers)

Any hard-coded decision about algorithms, modes of operations, or key lengths caked into clients will result in a world of hurt when you try to rotate off of those decisions later.

当您稍后尝试放弃这些决策时，任何有关算法，操作模式或键长度的硬编码决策都会给客户带来很大的伤害。

If there are no versioning mechanisms already in place in the legacy clients, it’s not even possible to retire old algorithms.

如果旧版客户端中尚无版本控制机制，则甚至不可能淘汰旧算法。

介绍Peacemakr (Introducing Peacemakr)

Peacemakr is an application layer data security platform. It abstracts away all the hard problems described above behind a simple interface. It uses a dedicated SaaS to provide centralized configuration management for all integrated clients.

Peacemakr是一个应用程序层数据安全平台。 它在一个简单的界面后面抽象了上面描述的所有难题。 它使用专用的SaaS为所有集成客户端提供集中的配置管理。

The SDKs focus on end-user simplicity and performance, so you don’t need a dedicated security team to build and maintain secure application-layer encryption in your product.

这些SDK专注于最终用户的简单性和性能，因此您不需要专门的安全团队来在产品中构建和维护安全的应用程序层加密。

Unlike KMS solutions, Peacemakr is a full-stack solution for application-layer encryption. It offers secure key delivery, key lifecycle management, crypto-agility, and even on-prem key derivation for you and your customers with a single solution.

与KMS解决方案不同，Peacemakr是用于应用程序层加密的全栈解决方案。 它通过单一解决方案为您和您的客户提供安全的密钥交付，密钥生命周期管理，加密敏捷性，甚至是本地密钥派生。

For more information, check out https://peacemakr.io or our open-source Peacemakr Crypto SDKs on GitHub.

有关更多信息，请访问https://peacemakr.io或我们在GitHub上的开源Peacemakr Crypto SDK。

Even if you don’t want to integrate directly into your applications, there’s an open-source peacemakr-cli that encrypts and decrypts strings or files in your system.

即使您不想直接集成到应用程序中，也可以使用开源的Peacemakr-cli来加密和解密系统中的字符串或文件。

This is especially useful for debugging secured ciphertexts, or, even just encrypting your logs.

这对于调试安全的密文，甚至仅加密日志特别有用。