mirror of
https://github.com/hashicorp/vault.git
synced 2025-08-22 23:21:08 +02:00
0660ea6fac
* Update README Let contributors know that docs will now be located in UDR * Add comments to each mdx doc Comment has been added to all mdx docs that are not partials * chore: added changelog changelog check failure * wip: removed changelog * Fix content errors * Doc spacing * Update website/content/docs/deploy/kubernetes/vso/helm.mdx Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com> --------- Co-authored-by: jonathanfrappier <92055993+jonathanfrappier@users.noreply.github.com> Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com>
46 lines
2.3 KiB
Plaintext
46 lines
2.3 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: HSM security details
|
|
description: >-
|
|
Understand how to ensure the security of a Vault Enterprise HSM deployment.
|
|
---
|
|
|
|
> [!IMPORTANT]
|
|
> **Documentation Update:** Product documentation, which were located in this repository under `/website`, are now located in [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs), colocated with all other product documentation. Contributions to this content should be done in the `web-unified-docs` repo, and not this one. Changes made to `/website` content in this repo will not be reflected on the developer.hashicorp.com website.
|
|
|
|
# HSM security details
|
|
|
|
@include 'alerts/enterprise-only.mdx'
|
|
|
|
This page provides information to help ensure that a Vault HSM deployment is
|
|
performed as securely as possible.
|
|
|
|
## PKCS#11 authentication
|
|
|
|
PKCS#11 authentication occurs via a slot number and PIN. In practice, because
|
|
the PIN is not required to be numeric (and some HSMs require more complex
|
|
PINs), this behaves like a username and password.
|
|
|
|
Like a username and password, these values should be protected. If they are
|
|
stored in Vault's configuration file, read access to the file should be tightly
|
|
controlled to appropriate users. (Vault's configuration file should always have
|
|
tight write controls.) Rather than storing these values into Vault's
|
|
configuration file, they can also be supplied via the environment; see the
|
|
[Configuration](/vault/docs/configuration/seal/pkcs11) page for more details.
|
|
|
|
The attack surface of stolen PKCS#11 credentials depends highly on the
|
|
individual HSM, but generally speaking, it should be assumed that if an
|
|
attacker can see these credentials and has access to a machine on which Vault
|
|
is running, the attacker will be able to access the HSM key protecting Vault's
|
|
root key. Therefore, it is extremely important that access to the machine on
|
|
which Vault is running is also tightly controlled.
|
|
|
|
## Recovery key shares protection
|
|
|
|
Recovery key shares should be protected in the same way as your organization
|
|
would protect key shares for the cryptographic barrier. As a quorum of recovery
|
|
key shares can be used with the `generate-root` feature to generate a new root
|
|
token, and root tokens can do anything within Vault, PGP encryption should
|
|
always be used to protect the returned recovery key shares and the recovery
|
|
share holders should be highly trusted individuals.
|