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:
- Vault Unified Identity and ACL policies
- Control Groups
- Mount Filters
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.
» GDPR Overview
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.
» What data is covered under GDPR?
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.
» GDPR by roles
- Data subject: EU citizen or individual whose data is being processed within a EU member state
- Processor: individual or group who processes GDPR data
- Controller: individual or group who governs whether the processor has access to GDPR data and how that data is protected
- Data Protection Officer (DPO): executive in charge of protecting GDPR-relevant data
- Supervisory Authority: National regulatory body within EU-member country in charge of managing compliance with GDPR
» GDPR by the articles
There are 99 total articles in GDPR that fall into three key categories:
- Individual rights:
- Rights for data subjects to dictate how their data is used, retained, and stored
- Basis of processing:
- Legal rights to access data including consent and necessity
- Obligations to processors and controllers
- Governance, accountability, and security:
- How is GDPR managed and stored?
- How is GDPR data protected?
- What happens during a data breach?
» GDPR by individual rights
- Rights to information, access: know where and how your data is being used before consent
- Rights to erasure: demand your data is destroyed
- Rights to object, restrict process: right to object to data being used at any time as well as restrict how that data is being processed
- Right to portability: right to demand access to stored data
- Right to rectification: right to change data stored
- Right to lodge complaint: petition the supervisory authority
» GDPR by penalties (Article 83)
- Non-negligent penalties: greater of 10M Euros or 2% global annual revenue
- Negligent penalties: greater of 20M Euros or 4% global annual revenue
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.
» Unified Identity and Policies for Article 35
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:
- Use the Vault audit log to identify specifically which individuals had access to what data as well as to trace their patterns of access and mitigate data breaches, especially if you are using a SIM solution.
- Allow controllers to control processor access and restrict access to people that only need to use it via Vault's ACL policy system
- Employ dynamic secrets and tokens tied to policies provide least privilege access (approve or deny access) only during legitimate Basis of Processing.
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.
» Mount Filters
(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:
- Disaster Recovery Replication: In the event that an entire availability zone or data center fails, DR-mode replication enables another region or cluster outside of the risk of the original cluster to resume operations.
- Performance Replication: Performance replication allows a cluster to serve as a remote hub of read replicas as well as stage writes to allow Vault to expand linearly with use.
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.
» Control Groups for Article 26, 27, 28
(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.