Your company has a ton of daily active users and you have this amazingly efficient architecture to process requests at scale, but your InfoSec team asks you to use a key manager — there are so many out there, which one do you choose?

There are various different types of key managers, but in this post, we’ll cover the three most common key managers:

• Native Cloud Key Managers (Ex — AWS KMS, GCP KMS, Azure Key Vault, etc.)

• External Key Managers (Ex — Thales CipherTrust Manager, etc.)

• Hybrid Key Managers (Use the best of both worlds — Cloud managed services and external key managers)

First, the literal key to security — HSMs​

HSM stands for “Hardware Security Module”. These are physical devices that are usually tamper resistant which store keys and perform encrypt, decrypt and other cryptographic operations.

HSMs are needed in secure environments such as healthcare or financial institutions where you need to pass compliances such as PCI DSS.

Now Let’s Compare​

Let’s look at the pros and cons of each to help you decide what would work best for your organization.

Cloud Key Managers​

✅ Easy Integration with Cloud Managed Services

When using cloud key managers like AWS KMS (Key Management Service) it can be advantageous as you get the flexibility of AWS managing your keys as well as direct integration into your existing AWS managed services such as AWS S3, or AWS RDS (Relational Database Service), etc.

✅ HSMs provisioned and managed by a cloud provider (most of the time 🤞)

Most famous cloud providers have HSMs that they use in their data centers which store your keys, so you don’t have to worry about renting an HSM.

❌ No Separation of Trust 🕵️‍♀️

Since your cloud provider now hosts and controls your data and encryption keys. Your user data might not be as safe anymore as the cloud provider with malicious intent could easily decrypt your user data. This does not help in creating a zero-trust architecture. While it’s true that your cloud provider has your best interest; there are always hackers lurking around the internet trying to get malicious access to your data, so it’s best to store data in an isolated environment.

External Key Managers​

✅ Complete Separation of Trust

When running a product such as CipherTrust Manager, your architectures are zero-trust by default as 2 different entities have access to either your data or your keys and NOT both.

❌ Build your own custom integrations

Unless the key manager service has connectors, many-a-times, you would need to build your own connectors which could put a lot of engineering debt on your teams.

⚠️ Need to rent out your own HSM

You’d need to manage your own HSM, but fortunately, there are service providers that will rent out and manage the HSMs (just like a cloud provider) — so this is neither a pro nor a con. A great example of a hosted HSM is the Luna HSM.

Best of Both Worlds 🤔​

Yes, it’s possible! To implement the best data security practices, you would want the ease of integration with cloud-managed services as well as complete separation of trust to isolate encryption keys from data. This method is also called BYOK (bring your own key).

You can do this with products such as CipherTrust Manager Cloud Key Manager. This offers:

✅ Direct connection with cloud-managed KMS account

Once you connect your AWS or GCP or Azure account to CipherTrust Manager as shown in the tutorial linked below, you will be able to manage keys directly from CipherTrust Manager and encrypt data on cloud-managed services.

✅ Key Lifecycle Management in a few clicks

In just a few clicks you can setup key rotation which will rotate your keys every few months and provide the best data security standards for your organization.

How do I implement this?​

Luckily, it’s easy to implement in 3 simple steps. Here’s a tutorial I made that demos connecting CipherTrust Manager to my AWS KMS (Key Management Service) account and encrypt my AWS managed services such as S3 and RDS.

Now go ahead and encrypt all your cloud-managed services using this hybrid BYOK approach!

If you have any issues with implementation or questions about data encryption, go to the CipherTrust community and post a quesiton.

Building and deploying applications and services is super exciting. Still, when your security team prevents your application from going into production due to a lack of data encryption — this can be very annoying.

Let’s take a look at the different data encryption methods that are most commonly used and how we can implement some of them.

Data encrypted at-rest vs in-transit?

Well, it’s often hard to choose between encrypting a complete Postgres database or encrypting only specific fields of data in the database right before it gets written to a table.

The key difference between the two is that encrypting a database after data is written to it is called data encryption at rest and encrypting data before data is written to a database is called data encryption in-transit.

The illustration below should give you a good high-level understanding of the difference. Although data encryption at-rest was a standard encryption practice followed for many years, it involves developers writing and maintaining various different scripts or applications to ensure that the encryption is up to company standards. It is still useful while encrypting file systems and storage. On the other hand, data encryption in-transit is a lot more beneficial at times when you want to make your infrastructure database agnostic and provide high-security standards with significantly low developer effort.

Note that from the above diagram we can see that the method of encrypting data in-transit uses a side-car container which is a proxy used to intercept every request with sensitive fields or encrypted data and encrypt or decrypt the same respectively.

Advantages of Data Encryption in-Transit​

✅ No change to applications

The beauty of doing data-encryption in transit is that you don’t need to worry about changing any of your frontend apps, APIs, or databases. Since the side-car container does field-level encryption, you can granularly control all the data that needs to be encrypted and decrypted by remotely setting access policies from your key manager.

✅ Easy to deploy

Deploying a Data Protection Gateway side-car container is as easy to deploy as logging agents such as DataDog or Prometheus. You can just update your docker-compose, Kubernetes config files or just use Helm to install it.

✅ Developers can stop implementing data security policies

Now you can shift the responsibility of setting and implementing data security policies from developers over to InfoSec teams. This significantly helps prevent data breaches or unauthorized data access.

Disadvantages of Data Encryption in-Transit​

❌ Data encryption is only as strong as policies set

This applies to any method of data encryption. However, when we perform field-level encryption and decryption, InfoSec teams need to be aware of all data flowing through various API routes to prevent data breaches and unauthorized access to unencrypted data.

How Do I Implement Data Encryption in-Transit?​

You’re in luck 🙌 because I have a tutorial showing you how to easily implement data encryption in-transit with any of your containerized applications.

In this tutorial, I have used CipherTrust Manager’s Data Protection Gateway product which is extremely easy to set up and free to start using👇

Now go ahead and encrypt data in-transit from all your applications using side-car containers.

If you have any issues with implementation or questions about data encryption in-transit, feel free to leave a comment, tweet @snpranav, or raise a GitHub issue :)