How Vault Encrypts Application Data During Transit and at Rest

How Vault Encrypts Application Data During Transit and at Rest

Jun 14 2017    Chris Kent

Companies today are adopting the cloud and looking for ways to accelerate application delivery. These migrations can often times create challenges for organizations around data privacy and secrets management, since distributed applications and infrastructure need to share and transmit data between different components and layers. Considering these components might live in different datacenters or even different clouds, the task of securing application data and communication becomes even more complicated and important.

HashiCorp Vault focuses on keeping application data secure across distributed infrastructure. Vault achieves this by tightly controlling access and exposure to organization's secrets, such as API keys, passwords, certificates, and more. Vault acts as pass-through for users that want to encrypt application data but not necessarily store the values in Vault. Vault also takes secrets management and data encryption an important step further: it encrypts the data during transit and at rest, giving users increased security throughout the lifecycle of the data. While Vault inherently provides users the ability to store data securely, it also exposes that ability to encrypt data during transit, as a service. Vault’s Encryption as a Service (EaaS) or Secrets as a Service, can encrypt the data during transit and return the encrypted data to applications. This is particularly useful for web applications that don’t need to store the data over time, such as single-page web apps, or applications that use different data stores (e.g. databases, etc.).

How it works

Check out more on How HashiCorp uses Vault for Managing Secrets

Vault’s EaaS extends other native functionality through Vault’s Transit Backend, such as audit operations, data verification and signing, hash and HMAC generation, as well as TLS/SSL credential issuance also acting as a certificate authority. Vault logs any encryption or decryption operation, allowing users to get a holistic audit history of how data is being accessed, encrypted, and decrypted. Vault’s Secret Backend enables users to generate signed SSH certificates along with dynamic keys and one-time passwords.

For users encrypting data in a single datacenter, Vault open source is the best option. For users that need to encrypt application data across multiple datacenters, Vault Enterprise makes this possible with multi-datacenter replication. The replication architecture allows multiple Vault clusters to communicate in a one-to-many near real-time flow. The primary cluster acts as the system of record and asynchronously replicates most Vault data to a series of remote clusters, known as secondary clusters or secondaries. The secondaries keep track of their own tokens and leases but share the underlying configuration, policies, and supporting secrets (K/V values, encryption keys for transit, etc.). In practice, most high-volume workloads (reads in the generic backend, encryption/decryption operations in transit, etc.) can be satisfied by the local secondary, allowing Vault to scale relatively horizontally with the number of secondaries rather than vertically.

Whether in one datacenter or across global datacenters, Vault’s Encryption as a Service provides users with on-demand encryption expertise and capabilities. It puts the burden of proper encryption and decryption on Vault, versus the user, allowing for faster adoption and community support. This alleviates development costs, time, and expertise needed to create or implement local COTS or custom-written solutions.

Want to learn more about getting started with Vault’s EaaS? Check out: Quick Start with Vault Transit

For more information on Vault, Transit, and Secret Backends, check out