Storage backend и барьер шифрования

Разбираем, куда Vault складывает зашифрованные секреты и почему даже доступ к диску не раскрывает их.

Storage backend — внешнее хранилище (файл, Consul, интегрированное хранилище Raft, облачное хранилище), куда Vault записывает все свои данные в зашифрованном виде.

Сам Vault не хранит данные внутри себя — он процесс без состояния. Всё состояние (секреты, политики, конфигурация движков) лежит в storage backend. Это важно: перезапуск Vault не теряет данные, а отказоустойчивость строится на отказоустойчивости хранилища.

Storage backend — недоверенный

Ключевой принцип: Vault считает хранилище недоверенным. Администратор Consul, владелец диска или провайдер облака видят только зашифрованные байты. Расшифровать их можно лишь внутри запущенного, распечатанного Vault.

[ Клиент ] --HTTPS--> [ Vault (процесс) ]
                            |
                  криптографический барьер
                            |
                  [ Storage backend ]
                  (только шифртекст:
                   Raft / Consul / файл)

Криптографический барьер

Барьер (barrier) — это слой шифрования между ядром Vault и хранилищем. Всё, что пересекает барьер по пути в storage, шифруется; всё, что читается обратно, расшифровывается. Снаружи барьера — только зашифрованные данные.

Барьер шифрует данные ключом шифрования (encryption key). Но этот ключ тоже нельзя просто положить рядом — иначе кража диска раскроет всё. Поэтому ключ шифрования сам зашифрован мастер-ключом, и без мастер-ключа барьер не открыть. Так возникает запечатанное (sealed) состояние, о котором речь в следующем уроке.

Какие бывают backend'ы

Backend	Когда выбирают
Integrated Storage (Raft)	рекомендуемый по умолчанию: HA встроена, не нужен внешний кластер
Consul	исторический выбор, отдельный кластер Consul для HA
file	только для dev и обучения, без HA
in-memory	dev-режим, данные исчезают при остановке

Как работает под капотом

Конфигурация storage задаётся в HCL-файле Vault. Минимальный продакшн-конфиг с Raft:

storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-1"
}

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_cert_file = "/etc/vault/tls/cert.pem"
  tls_key_file  = "/etc/vault/tls/key.pem"
}

api_addr     = "https://vault-1.internal:8200"
cluster_addr = "https://vault-1.internal:8201"

Когда клиент пишет секрет, ядро сериализует его, барьер шифрует результат и кладёт в Raft-лог. Чтение идёт в обратном порядке. Именно поэтому компрометация одного лишь хранилища бесполезна для атакующего.

Частые ошибки

Считать storage доверенным и складывать туда что-то в открытом виде — Vault так не работает, всё уже шифруется барьером.
Использовать file/in-memory в проде — нет HA и легко потерять данные.
Не делать бэкап storage — потеря Raft-данных = потеря всех секретов.

Итог

Vault — процесс без состояния, всё хранится в storage backend в зашифрованном виде.
Storage считается недоверенным: доступ к диску не раскрывает секреты.
Барьер шифрует данные на границе с хранилищем; ключ шифрования сам защищён мастер-ключом.