Vault Secrets security model

This documentation explains the security model of HCP Vault Secrets. The product is built directly on top of HCP primitives, and is therefore an extension of HCP's Security Model.

High-level architecture

Vault Secrets is a SaaS application running in HCP, utilizing multiple AWS accounts and virtual private clouds to create an additional security boundary for Vault Secrets user's secrets. All customer API actions flow first through a load balancer, and are distributed to a Nomad cluster running the Vault Secrets Service API's containers. Vault Secrets apps, and secret metadata, including which app and/or tenant they belong to, are stored in an encrypted Amazon Aurora database. The secret values are further encrypted via the tokenization service and stored in an encrypted Amazon Aurora database. This database, and the compute resources that perform encryption operations, are accessible to services only via dynamic AWS credentials provided by Vault's AWS secrets engine.

Storage

All data is stored within, encrypted at rest Amazon Aurora databases, with the exception of service audit logs, which are stored within an encrypted Amazon S3 bucket.

Tokenization service

In addition to being encrypted at rest, data stored within the tokenization service is also encrypted with per-tenant AES256-GCM96 data keys, authenticated with HMAC-SHA256. The keyring, from which the per-tenant data keys are derived, is encrypted with AWS KMS. This keyring is cached, unencrypted, in memory for small periods of time to reduce the latency of data encryption operations.

Tenancy model

Vault Secrets is a multi-tenant service. All requests are handled by the same application containers, audit logs are stored in the same storage buckets, and all data is collocated in shared databases using table based multi-tenancy. Tenant data is keyed, depending on the context in which it is used, through a combination of the HCP Organization and Project IDs, the Vault Secrets application ID, and additional cryptographically strong random identifiers.

Within the Service API, a tenant is considered to be an HCP Project. An HCP Project is the level at which Role-Based Access Control is enforced. Thus, a user who is an administrator of Project A, has administrator access within all of Project A's Vault Secrets applications.

In the tokenization service, the tenancy is configurable depending on use. For Vault Secrets applications, the application's ID is the tenant ID. For Vault Secrets integration configurations, the HCP Project ID is the tenant ID.

The tokenization service requires registration of tenants. Our chosen tenant ID is traded for a Private ID that must be provided for future tokenization service operations related to that tenant. The tokenization service cannot perform a request acting on a tenant's data without that tenant's Private ID. A tenant's Private ID cannot be accessed from the Service API's database without explicit authorization for the app, or sync integration.

Auditing

HCP Vault Secrets audits all service requests and makes the entries available for customer consumption. This is generalized in the UI as Audit Logs and available in more detail, as raw audit entries, via authenticated requests to HCP’s centralized audit repository. Audits do not contain sensitive plaintext or encrypted data, such as tokenized values, but do retain metadata around the principal who attempted the action, the type of action (create, open/decrypt, delete, etc) and the resource that was targeted. More information about our internal security practices can be found in our security and privacy documentation.