162 lines
8.6 KiB
Plaintext
162 lines
8.6 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.
|
|
|
|
- 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.
|
|
|
|
# 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.
|
|
|
|
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](../concepts/policies.mdx#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-man
|
|
rule](https://en.wikipedia.org/wiki/Two-man_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.
|