6. Безопасность и аудит
Цель — закрепить production-подход к Vault: аудит всех обращений к API, минимальные привилегии, короткоживущие credentials и осознанная модель угроз (компрометация кластера, root token). Ниже — типы audit devices, практики и короткие примеры.
Зачем audit в production
Audit device записывает попытки обращения к Vault (успех/отказ, клиент, путь, тип операции). Это не замена логам приложений, а юридически и операционно важный след для расследований и соответствия требованиям.
Best practices:
- минимум один надёжный audit sink (файл на отдельный том / syslog / SIEM);
- нельзя блокировать все audit devices одновременно — Vault откажет в новых запросах при полной потере audit (block on failure — понимать риск);
- ротация и ёмкость диска под логи; отдельные политики доступа к файлам audit на ОС;
- не логировать сами секретные значения в сторонних системах — audit Vault фиксирует метаданные запросов по дизайну продукта, но при интеграциях следите за тем, что уходит в SIEM.
Audit devices: file и syslog
| Device | Когда использовать | Комментарий |
|---|---|---|
| file | Локальный файл на защищённом томе, далее сборщик (Fluent Bit, Filebeat) | Частый выбор on-prem и VM; задать путь вне мира с общим чтением. |
| syslog | Централизованный syslog / rsyslog → SIEM | Удобно в «классических» датацентрах; согласовать facility/severity. |
| socket (опционально) | Прямой поток в коллектор | Реже; нужна устойчивость канала. |
Примеры включения
# Файловый аудит (путь адаптируйте под свой стандарт)
vault audit enable -path=file-audit file \
file_path=/var/log/vault/audit.log \
mode=0600
# Syslog (тег и facility — для фильтрации в SIEM)
vault audit enable -path=syslog-audit syslog \
tag="vault-audit" \
facility="LOCAL5"
Комментарий: имя устройства (file-audit, syslog-audit) и параметры зависят от вашей политики; несколько audit devices допустимы (дублирование на файл + отправка в syslog).
Просмотр активных устройств (нужны права):
vault audit list -detailed
Security best practices
Least privilege (минимальные права)
| Уровень | Практика |
|---|---|
| Политики | Только нужные path и capabilities; запрет по умолчанию, явные разрешения. |
| Роли auth | Одна роль — один класс доступа (сервис/среда), без «супер-роли» для всех путей. |
| Админы | Отдельные break-glass политики, MFA на IdP, журналирование. |
Short-lived tokens
- TTL по умолчанию и max_ttl на ролях auth;
- периодическое renew только там, где процесс долгоживущий;
- batch tokens — осознанно, под нагрузочные read-only сценарии.
# Пример: токен только на чтение KV (политика app-readonly-kv создаётся заранее)
# explicit-max-ttl — жёсткий потолок жизни даже при renew
vault token create \
-policy=app-readonly-kv \
-ttl=30m \
-renewable=true \
-explicit-max-ttl=4h
Rotation
| Объект | Идея |
|---|---|
| Статические секреты в KV | Процесс ротации + версии KV v2; не держать «вечные» пароли. |
| AppRole secret_id | Периодическое перевыдавание; компрометация — отзыв роли/secret_id. |
| TLS сертификаты | PKI с коротким TTL leaf + автоматическое обновление агентом/ингрессом. |
| Ключи облака для unseal / AWS root в движках | Отдельные CMK/IAM; смена по инциденту или расписанию. |
Минимальная политика (практика)
Разрешить только чтение конкретного KV-пути приложения:
# policy: app-orders-minimal.hcl
path "secret/data/orders/*" {
capabilities = ["read"]
}
path "secret/metadata/orders/*" {
capabilities = ["read", "list"]
}
# Явный запрет на админские пути (дополнительный hardening)
path "sys/*" {
capabilities = ["deny"]
}
vault policy write app-orders-minimal app-orders-minimal.hcl
Комментарий: блок deny на sys/* для приложений обычно уместен; для операторов — отдельная политика без такого deny.
Threat modeling (кратко)
«Что если скомпрометирован Vault?»
| Сценарий | Последствия | Что делать заранее |
|---|---|---|
| Утечка токена приложения | Доступ в границах политик этого токена | Короткий TTL, отзыв token/revoke, узкие policy, аудит по client_token accessor |
| Утечка unseal ключей / KMS | Риск расшифровки storage при доступе к данным | Shamir разделение, KMS IAM, физическая/организационная изоляция |
| Компрометация ноды | Чтение памяти, локальных файлов конфигурации | Hardening ОС, шифрование дисков, минимум секретов на диске, сеть DMZ |
| Злоумышленник с root/token admin | Почти полный контур | Запрет root в daily ops, MFA, отдельный audit, emergency процедуры |
Практика: раз в квартал учения «утечка token» / «потеря audit» по runbook.
Как защищать root token
| Правило | Деталь |
|---|---|
| Создать и отозвать после bootstrap | Использовать root только для первичной настройки, затем token revoke + операторские методы. |
| Не хранить в менеджерах паролей команды «на всякий случай» | Только break-glass сейф / процедура с двумя лицами. |
| Альтернатива | Операции через OIDC/LDAP с сильными политиками + MFA на IdP. |
# После того как настроены admin-политики и другой способ входа (пример)
vault token revoke "<root-token-or-id>"
Комментарий: отзыв root требует осознанности; убедитесь, что есть хотя бы один путь администрирования без root.
Сводный checklist
| # | Практика |
|---|---|
| 1 | Audit device(s) включены, диск/SIEM подготовлены |
| 2 | Политики — минимальные; сервисы без доступа к sys/ и чужим mount’ам |
| 3 | TTL/max_ttl на ролях и токенах согласованы с SLA job/Pod |
| 4 | Root не в daily workflow; runbook на инциденты |
| 5 | Ротация секретов и TLS по процессу, не «по памяти» |