184 lines
10 KiB
Plaintext
184 lines
10 KiB
Plaintext
---
|
||
layout: docs
|
||
page_title: Security Model
|
||
description: Learn about the security model of Vault.
|
||
---
|
||
|
||
# Security Model
|
||
|
||
Due to the nature of Vault and the confidentiality of data it is managing,
|
||
the Vault security model is very critical. The overall goal of Vault's security
|
||
model is to provide [confidentiality, integrity, availability, accountability,
|
||
authentication](https://en.wikipedia.org/wiki/Information_security).
|
||
|
||
This means that data at rest and in transit must be secure from eavesdropping
|
||
or tampering. Clients must be appropriately authenticated and authorized
|
||
to access data or modify policy. All interactions must be auditable and traced
|
||
uniquely back to the origin entity. The system must be robust against intentional
|
||
attempts to bypass any of its access controls.
|
||
|
||
# Threat Model
|
||
|
||
The following are the various parts of the Vault threat model:
|
||
|
||
- Eavesdropping on any Vault communication. Client communication with Vault
|
||
should be secure from eavesdropping as well as communication from Vault to
|
||
its storage backend or between Vault cluster nodes.
|
||
|
||
- Tampering with data at rest or in transit. Any tampering should be detectable
|
||
and cause Vault to abort processing of the transaction.
|
||
|
||
- Access to data or controls without authentication or authorization. All requests
|
||
must be proceeded by the applicable security policies.
|
||
|
||
- Access to data or controls without accountability. If audit logging
|
||
is enabled, requests and responses must be logged before the client receives
|
||
any secret material.
|
||
|
||
- Confidentiality of stored secrets. Any data that leaves Vault to rest in the
|
||
storage backend must be safe from eavesdropping. In practice, this means all
|
||
data at rest must be encrypted.
|
||
|
||
- Availability of secret material in the face of failure. Vault supports
|
||
running in a highly available configuration to avoid loss of availability.
|
||
|
||
The following are not parts of the Vault threat model:
|
||
|
||
- Protecting against arbitrary control of the storage backend. An attacker
|
||
that can perform arbitrary operations against the storage backend can
|
||
undermine security in any number of ways that are difficult or impossible to protect
|
||
against. As an example, an attacker could delete or corrupt all the contents
|
||
of the storage backend causing total data loss for Vault. The ability to control
|
||
reads would allow an attacker to snapshot in a well-known state and rollback state
|
||
changes if that would be beneficial to them.
|
||
|
||
- Protecting against the leakage of the existence of secret material. An attacker
|
||
that can read from the storage backend may observe that secret material exists
|
||
and is stored, even if it is kept confidential.
|
||
|
||
- Protecting against memory analysis of a running Vault. If an attacker is able
|
||
to inspect the memory state of a running Vault instance then the confidentiality
|
||
of data may be compromised.
|
||
|
||
- Protecting against flaws in external systems or services used by Vault.
|
||
Some authentication methods or secrets engines delegate sensitive operations to
|
||
systems external to Vault. If an attacker can compromise credentials or otherwise
|
||
exploit a vulnerability in these external systems, then the confidentiality or
|
||
integrity of data may be compromised.
|
||
|
||
- Protecting against malicious plugins or code execution on the underlying host.
|
||
If an attacker can gain code execution or write privileges to the underlying host,
|
||
then the confidentiality or the integrity of data may be compromised.
|
||
|
||
- Protecting against flaws in clients or systems that access Vault. If an attacker
|
||
can compromise a Vault client (e.g., system, browser) and obtain this client’s Vault
|
||
credentials, they can access Vault with the level of privilege associated with this
|
||
client.
|
||
|
||
# External Threat Overview
|
||
|
||
Given the architecture of Vault, there are 3 distinct systems we are concerned
|
||
with for Vault. There is the client, which is speaking to Vault over an API.
|
||
There is Vault or the server more accurately, which is providing an API and
|
||
serving requests. Lastly, there is the storage backend, which the server is
|
||
utilizing to read and write data.
|
||
|
||
There is no mutual trust between the Vault client and server. Clients use
|
||
[TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security) to verify the
|
||
identity of the server and to establish a secure communication channel. Servers
|
||
require that a client provides a client token for every request which is used
|
||
to identify the client. A client that does not provide their token is only
|
||
permitted to make login requests.
|
||
|
||
All server-to-server traffic between Vault instances within a cluster (i.e,
|
||
high availability, enterprise replication or integrated storage) uses
|
||
mutually-authenticated TLS to ensure the confidentiality and integrity of data
|
||
in transit. Nodes are authenticated prior to joining the cluster, by an
|
||
[unseal challenge](/docs/concepts/integrated-storage#vault-networking-recap) or
|
||
a [one-time-use activation token](/docs/enterprise/replication#security-model).
|
||
|
||
The storage backends used by Vault are also untrusted by design. Vault uses a
|
||
security barrier for all requests made to the backend. The security barrier
|
||
automatically encrypts all data leaving Vault using a 256-bit [Advanced
|
||
Encryption Standard
|
||
(AES)](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) cipher in
|
||
the [Galois Counter Mode
|
||
(GCM)](https://en.wikipedia.org/wiki/Galois/Counter_Mode) with 96-bit nonces.
|
||
The nonce is randomly generated for every encrypted object. When data is read
|
||
from the security barrier the GCM authentication tag is verified during the
|
||
decryption process to detect any tampering.
|
||
|
||
Depending on the backend used, Vault may communicate with the backend over TLS
|
||
to provide an added layer of security. In some cases, such as a file backend
|
||
this is not applicable. Because storage backends are untrusted, an eavesdropper
|
||
would only gain access to encrypted data even if communication with the backend
|
||
was intercepted.
|
||
|
||
# Internal Threat Overview
|
||
|
||
Within the Vault system, a critical security concern is an attacker attempting
|
||
to gain access to secret material they are not authorized to. This is an internal
|
||
threat if the attacker is already permitted some level of access to Vault and is
|
||
able to authenticate.
|
||
|
||
When a client first authenticates with Vault, an auth method is used to verify
|
||
the identity of the client and to return a list of associated ACL policies.
|
||
This association is configured by operators of Vault ahead of time. For
|
||
example, GitHub users in the "engineering" team may be mapped to the
|
||
"engineering" and "ops" Vault policies. Vault then generates a client token
|
||
which is a randomly generated, serialized value and maps it to the policy list.
|
||
This client token is then returned to the client.
|
||
|
||
On each request a client provides this token. Vault then uses it to check that
|
||
the token is valid and has not been revoked or expired, and generates an ACL
|
||
based on the associated policies. Vault uses a strict default deny
|
||
enforcement strategy. This means unless an associated policy allows for a given action,
|
||
it will be denied. Each policy specifies a level of access granted to a path in
|
||
Vault. When the policies are merged (if multiple policies are associated with a
|
||
client), the highest access level permitted is used. For example, if the
|
||
"engineering" policy permits read/update access to the "eng/" path, and the
|
||
"ops" policy permits read access to the "ops/" path, then the user gets the
|
||
union of those. Policy is matched using the most specific defined policy, which
|
||
may be an exact match or the longest-prefix match glob pattern. See
|
||
[Policy Syntax](/docs/concepts/policies#policy-syntax) for more details.
|
||
|
||
Certain operations are only permitted by "root" users, which is a distinguished
|
||
policy built into Vault. This is similar to the concept of a root user on a
|
||
Unix system or an Administrator on Windows. Although clients could be provided
|
||
with root tokens or associated with the root policy, instead Vault supports the
|
||
notion of "sudo" privilege. As part of a policy, users may be granted "sudo"
|
||
privileges to certain paths, so that they can still perform security sensitive
|
||
operations without being granted global root access to Vault.
|
||
|
||
Lastly, Vault supports using a [Two-person
|
||
rule](https://en.wikipedia.org/wiki/Two-person_rule) for unsealing using [Shamir's
|
||
Secret Sharing
|
||
technique](https://en.wikipedia.org/wiki/Shamir's_Secret_Sharing). When Vault
|
||
is started, it starts in a _sealed_ state. This means that the encryption key
|
||
needed to read and write from the storage backend is not yet known. The process
|
||
of unsealing requires providing the master key so that the encryption key can
|
||
be retrieved. The risk of distributing the master key is that a single
|
||
malicious actor with access to it can decrypt the entire Vault. Instead,
|
||
Shamir's technique allows us to split the master key into multiple shares or
|
||
parts. The number of shares and the threshold needed is configurable, but by
|
||
default Vault generates 5 shares, any 3 of which must be provided to
|
||
reconstruct the master key.
|
||
|
||
By using a secret sharing technique, we avoid the need to place absolute trust
|
||
in the holder of the master key, and avoid storing the master key at all. The
|
||
master key is only retrievable by reconstructing the shares. The shares are not
|
||
useful for making any requests to Vault, and can only be used for unsealing.
|
||
Once unsealed the standard ACL mechanisms are used for all requests.
|
||
|
||
To make an analogy, a bank puts security deposit boxes inside of a vault. Each
|
||
security deposit box has a key, while the vault door has both a combination and
|
||
a key. The vault is encased in steel and concrete so that the door is the only
|
||
practical entrance. The analogy to Vault, is that the cryptosystem is the
|
||
steel and concrete protecting the data. While you could tunnel through the
|
||
concrete or brute force the encryption keys, it would be prohibitively time
|
||
consuming. Opening the bank vault requires two-factors: the key and the
|
||
combination. Similarly, Vault requires multiple shares be provided to
|
||
reconstruct the master key. Once unsealed, each security deposit boxes still
|
||
requires the owner provide a key, and similarly the Vault ACL system protects
|
||
all the secrets stored.
|