Andy Manoske is the Product Manager for HashiCorp Vault based out of San Francisco, CA.
Here at HashiCorp, we've been releasing features and constructing a roadmap for Vault that specifically assists in helping your organization comply with GDPR, or the General Data Protection Regulation standard that is set to go live in May 25, 2018. We're excited to share and explain how some of these Vault features can be used to comply with specific GDPR articles, including:
We specifically developed Vault to manage, store, and protect sensitive information in a way that reduces secret sprawl but also enables global organizations to operate at a very large scale. In a world where secrets are spread in a global manner, this use case is critical especially if you are spanning your infrastructure across multiple public and private clouds. In the context of GDPR, this use case becomes extremely critical, as it requires us to be more sensitive to where our data is moving or sitting at any given time physically and forces us to put our best effort to protect the data sovereignty of our sensitive information.
For a more personal conversation, you can watch Webinar: Preparing for GDPR Compliance with HashiCorp Vault on-demand.
Note: This overview is not meant to be comprehensive or serve as legal advice. We highly recommend speaking to an auditor or lawyer to dig into the details of the full regulation as there are major components of GDPR that are left to auditor and supervisory authority interpretation.
GDPR governs security requirements for the use and storage of PII (Personally Identifiable Information) for EU citizens and rights for EU citizens to their data - as well as potentially all PII processed and stored within the EU. It is extraterritorial - i.e. applies to EU data regardless of that data's location.
There are 99 total articles in GDPR that fall into three key categories:
Negligence is determined by the number of factors including bona fide security effort, alignment with GDPR, audit of security controls, etc.
Note: Supervisory Authorities can institute supplemental fees.
Released in Vault Open Source and Vault Enterprise 0.8, with unified identity if you are accessing Vault with an identity system that spans across GCP and Active Directory, Vault would be able to span across all of them and recognize common identity whether they are logging in through LDAP or supplying a GCP-based JWT token.
Applies to: Article 35
Recommended use: in the event of a data breach, have audit log capabilities to map actions to entities to track data breach taxonomy including:
While it's possible to do all of the above without unified identity, being able to simplify how one orchestrates Role-Based Access Control in an environment that spans across complex infrastructures is critical. Particularly, we wanted to reduce complexity that can expose vulnerability to side channel attacks or denial of service attacks.
(Note: this is a Vault Enterprise Premium feature)
A key principle of Article 35 is that GDPR data cannot move to a locale that does not have at least as good data protection requirements as what GDPR requires. Being able to restrict the physical movement of data in a dynamic, multi-cloud world is very difficult. We built mount filters in Vault 0.8 to allow you to, during replication, spin up and spin down different clusters of Vault that can share data in one of two ways, via disaster recovery or performance replication.
Let's step back a moment and discuss some principles behind replication. In Vault, replication can operate within two modes:
Mount Filters are a feature within Performance Replication that allow you to specify (either via whitelist or blacklist) which secret mounts are moved as part of the mirroring for Replication. Using Mount Filters, Vault can span its identity structure and centralize management globally while control which secrets are moved between which geographies.
Applies to: Article 35
Recommended use: Ensure GDPR data is segmented by secret mount and blacklist the movement of those secret mounts to non-GDPR territories.
For example, let us assume you are a EU organization that has a Vault infrastructure within France and want to span your environment to a location in the Eastern United States via a second cluster. You would like to centralize management as an EU organization to provide localized access, minimize round-trip delay, and scale rights linearly - i.e. provide a basis for scaling globally to other locales.
Let us assume have a secret backend that stores sensitive EU GDPR database credentials.
Let us also assume that you have another set of database credentials for US non-GDPR specific data.
You want to share some of the data but also make sure you're centralizing management of identity, etc. In order to do so, you enable a Replication relationship, setting the EU cluster as the primary cluster.
By deploying a Performance mode secondary cluster to the US, you will allow applications within the US to minimize round trip latency and retrieve secrets faster while you centrally manage Vault within the European Union. However, we now potentially expose GDPR data to a non-GDPR aligned geography: the United States.
Now we need to limit the movement of GDPR data. When configuring your replication relationship on the France-based primary, select mount filter mode to
blacklist all the GDPR data going into the US from the EU GDPR cluster. Then generate your token.
This will ensure that the French performance primary is able to replicate only non-GDPR data. Using this secondary, navigate to the Vault secondary cluster and initiate a replication relationship. Note that when a secondary is being spawned, it will clear all the data in the cluster and start mirroring the infrastructure of whatever is in the primary.
Vault will now start migrating in its identity management, secrets, policies, and token infrastructure into the US-based secondary for transparent use by its local applications. No GDPR data will be migrated, and the whole environment will be manageable by the EU-based primary.
(Note: this is a Vault Enterprise Pro feature)
Specifically designed to align with GDPR terminology and regulations, control groups provide the capability to require other authorizers' approval when attempting to access secrets. By selecting an identity group within Vault and marking it as a control group for a specific path, access to all secrets within that path must require the explicit approval of entities within its corresponding control group.
Recommended use: Implement joint controller provisions that directly map to Control Groups functionality. This can be augmented with HashiCorp Sentinel to ensure that access requires other points of approval / authorization such as Multi-Factor Authentication.
GDPR is a comprehensive and complex set of requirements. In addition to the explicit provisions of the articles within GDPR, the oversight of the supervisory authorities in EU member states entails that additional implicit requirements and/or financial implications may arise depending on the region in which GDPR PII is processed within the European Union. It is critical that you consult with legal counsel and your auditors to ensure that you are aligned and prepared for the release of GDPR in 2018.
If you're interested in seeing these Vault Enterprise features for yourself, get a 30-day free trial here.
Learn how to build scalable, role-based SSH access with SSH certificates and HashiCorp Vault.
The HashiCorp Vault Helm chart has achieved Red Hat OpenShift Certification to help OpenShift users more readily deploy secrets management on Kubernetes.
Learn how to build an automated HashiCorp Vault onboarding system with Terraform using sensible naming standards, ACL policy templates, pre-created application entities, and workflows driven by VCS and CI/CD.