Cyber Security Academy · Урок

Хранилища секретов

Централизация секретов с помощью инструментов вроде Vault

Урок 2 из 413 шагов

«Хранилища секретов» — бесплатный урок Cyber Security Academy на CoddyKit. Это урок 2 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Cyber Security Academy, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Cyber Security Academy содержит 4 уроков всего.

Что решает хранилище secret

Хранилище secret (или защищённое хранилище) — это централизованный защищённый сервис, единственная задача которого — хранить секреты, управлять доступом к ним и вести аудит. Оно заменяет разрозненные файлы и переменные окружения, из-за которых секреты распространяются по системе.

Хороший менеджер секретов предоставляет четыре основные возможности:

Централизованное хранение — единый достоверный источник данных.
Контроль доступа — детализированные политики, определяющие, кто и что может прочитать из каждого хранилища.
Журналирование доступа — запись каждого обращения для реагирования на инциденты.
Шифрование — секреты зашифрованы при хранении и передаче.

К таким решениям относятся HashiCorp Vault, AWS Secrets Manager, Azure Key Vault и GCP Secret Manager.

Как устроен HashiCorp Vault

HashiCorp Vault — популярный менеджер секретов с открытым исходным кодом. Он организует функциональность в виде подключаемых движков секретов, смонтированных по путям.

Движок KV хранит статические секреты в формате «ключ — значение».
Движок баз данных создаёт динамические учётные данные базы данных с коротким сроком действия.
Движок PKI выдаёт сертификаты TLS по запросу.
Движок Transit предоставляет шифрование как услугу без раскрытия ключей.

Вы взаимодействуете с Vault через HTTP-интерфейс или CLI. Каждый путь регулируется политиками, определяющими, кто может читать или записывать данные по этому пути.

# Enable a KV v2 secrets engine at the 'secret/' path
vault secrets enable -path=secret kv-v2

# Write and read a static secret
vault kv put secret/app/db password='S3cr3t' user='app'
vault kv get secret/app/db

Модель запечатывания и распечатывания

Vault защищает свои данные с помощью механизма запечатывания и распечатывания. При запуске Vault запечатан — он знает, где находятся зашифрованные данные, но не может их расшифровать.

Мастер-ключ, расшифровывающий хранилище, сам зашифрован ключом распечатывания. С помощью схемы разделения секрета Шамира этот ключ распечатывания разделяется на несколько фрагментов, которые распределяются между разными операторами.

Чтобы восстановить ключ и распечатать Vault, необходимо предоставить настраиваемый порог — например, 3 из 5 фрагментов. Ни один человек не может распечатать его в одиночку, что защищает от компрометации изнутри.

# Initialize Vault: 5 key shares, threshold of 3 to unseal
vault operator init -key-shares=5 -key-threshold=3

# Each operator supplies one shard until threshold is met
vault operator unseal <shard-1>
vault operator unseal <shard-2>
vault operator unseal <shard-3>

Аутентификация: кто вы

Прежде чем прочитать secret, клиент должен пройти аутентификацию и получить токен. Vault поддерживает множество методов аутентификации, предназначенных для разных типов идентичности:

AppRole — для приложений и систем CI (идентификатор роли + secret ID).
Kubernetes использует токен сервисной учётной записи пода.
AWS/GCP/Azure IAM доверяет идентичности облачной платформы.
OIDC/LDAP — для людей через SSO.

Главный принцип: идентичность предоставляет платформа, а не долгоживущий пароль. Под Kubernetes-подтверждает свою личность с помощью собственного токена сервисной учётной записи — начальный secret, который мог бы утечь, не нужен.

# App authenticates via AppRole to receive a token
vault write auth/approle/login \
  role_id="db-app-role" \
  secret_id="$WRAPPED_SECRET_ID"
# Response includes client_token used for subsequent reads

Авторизация с помощью политик

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

Эта политика позволяет службе читать только собственный secret базы данных и ничего больше:

Возможности соответствуют глаголам API: read, create, update, delete и list. По умолчанию запрещайте доступ, а разрешения предоставляйте явно.

# policy: billing-app.hcl
path "secret/data/billing/*" {
  capabilities = ["read"]
}
path "database/creds/billing-readonly" {
  capabilities = ["read"]
}
# everything else is implicitly denied

Облачные хранилища секретов

Если вы работаете в одном облаке, управляемое хранилище провайдера снимает операционную нагрузку: не требуется запечатывание и распечатывание, не нужны серверы для обновления:

AWS Secrets Manager интегрируется с IAM и поддерживает встроенную замену с помощью функций Lambda.
Azure Key Vault хранит секреты, ключи и сертификаты, используя RBAC.
GCP Secret Manager хранит версии секретов, доступ к которым контролируется привязками IAM.

Доступ регулируется IAM облака, поэтому рабочая нагрузка читает secret с помощью уже существующей роли — отдельный пароль не нужен. Компромисс заключается в зависимости от поставщика и менее развитой поддержке нескольких облаков по сравнению с Vault.

# Read a secret from AWS Secrets Manager (workload uses its IAM role)
aws secretsmanager get-secret-value \
  --secret-id prod/billing/db \
  --query SecretString --output text

# GCP equivalent
gcloud secrets versions access latest --secret=billing-db

Шифрование как услуга

Иногда вам вообще не нужно хранить secret — вы хотите шифровать данные приложения, не допуская, чтобы приложение когда-либо получало ключ шифрования. Именно это делает движок Transit в Vault.

Приложение отправляет открытый текст в Vault, получает шифротекст и никогда не видит ключ. Расшифровка выполняется таким же образом. Это называется шифрованием как услугой.

Преимущество в том, что ключи находятся только внутри Vault, их можно централизованно заменять, а скомпрометированное приложение не может раскрыть ключ, которым никогда не обладало.

# Encrypt data without the app ever seeing the key
vault write transit/encrypt/orders-key \
  plaintext=$(echo -n 'card=4111...' | base64)
# returns: ciphertext=vault:v1:abc123...

# Decrypt later
vault write transit/decrypt/orders-key ciphertext='vault:v1:abc123...'

Внедрение секретов в рабочие нагрузки

Хранилище полезно только в том случае, если приложения могут получать секреты без жёстко заданных пути или токена. Распространённые способы внедрения:

Вспомогательный контейнер/агент — Vault Agent работает рядом с приложением, проходит аутентификацию и записывает секреты в общий том в памяти.
Драйвер CSI — Kubernetes подключает секреты как файлы с помощью драйвера CSI для хранилища секретов.
Получение через SDK — приложение напрямую вызывает API хранилища при запуске.

Предпочитайте подключение к файловой системе в памяти (tmpfs), а не использование переменных окружения, и не записывайте секреты на диск, где они могут сохраниться.

# Vault Agent template renders a secret to an in-memory file
template {
  contents = "DB_PASS={{ with secret \"secret/app/db\" }}{{ .Data.data.password }}{{ end }}"
  destination = "/run/secrets/db.env"
}

Ведение журнала аудита и подотчётность

Каждое событие чтения, записи и аутентификации в хранилище следует записывать в журнал аудита. Благодаря этому управление секретами можно обоснованно защищать при расследовании инцидента.

Журналы аудита отвечают на важнейшие вопросы: кто получил доступ к какому секрету, когда и откуда. Хранилище хеширует конфиденциальные значения в журналах, поэтому сами журналы не раскрывают секреты.

Передавайте журналы аудита в отдельную систему, защищённую от незаметного изменения (SIEM), чтобы злоумышленник, скомпрометировавший узел хранилища, не смог одновременно стереть свидетельства своих действий.

# Enable a file audit device (HMAC-hashes secret values)
vault audit enable file file_path=/var/log/vault/audit.log

# Forward to a SIEM/syslog endpoint for tamper resistance
vault audit enable syslog tag="vault" facility="AUTH"

Защита самого хранилища

Централизованное хранилище концентрирует риск: если хранилище выйдет из строя, выйдет из строя всё. Защитите его как наиболее критически важный ресурс:

Используйте TLS на всех конечных точках; никогда не открывайте программный интерфейс без шифрования.
Разместите хранилище в частной сети за строгими правилами брандмауэра.
Включите автоматическое снятие блокировки через облачный KMS, чтобы не обрабатывать фрагменты ключа вручную, но тщательно защитите этот ключ KMS.
Используйте короткие TTL токенов и возобновляемые аренды, чтобы украденные токены быстро истекали.
Своевременно устанавливайте исправления и отслеживайте аномалии в журналах аудита.

Хранилище заменяет множество точек отказа одной, чрезвычайно хорошо защищённой точкой.

Выбор подходящего хранилища

Одного универсально лучшего инструмента не существует — выберите хранилище в соответствии с вашей средой:

Одно облако, простые потребности — используйте встроенный менеджер облака (AWS, облачная платформа Microsoft или GCP), чтобы свести операционные затраты к минимуму.
Несколько облаков или локальная инфраструктура — хранилище HashiCorp предоставляет единый переносимый уровень абстракции.
Нужны динамические секреты или шифрование как услуга — движки хранилища обладают наиболее широкими возможностями.
Активное использование Кубернетеса — объедините хранилище с драйвером CSI или оператором вроде «Внешних секретов».

Что бы Вы ни выбрали, цель одна: единый проверяемый источник истины с контролем доступа, который заменяет разрозненные секреты в открытом виде.

Проверка знаний

Проверьте, насколько Вы понимаете модель защиты хранилища.

Ответь в интерактивном уроке

Повторение: хранилища и хранилища секретов

Вы научились заменять разрозненные секреты централизованным хранилищем с аудитом.

Хранилище секретов обеспечивает централизованное хранение, контроль доступа, ведение журнала аудита и шифрование.
Хранилище HashiCorp использует подключаемые движки секретов и модель блокировки и разблокировки, защищённую схемой разделения секрета Шамира.
Методы аутентификации получают идентификационные данные от платформы (Кубернетес, IAM, AppRole), а политики обеспечивают минимально необходимые привилегии.
Облачные хранилища (AWS, облачная платформа Microsoft, GCP) жертвуют переносимостью ради низких операционных затрат.
Движок транзита предоставляет шифрование как услугу, поэтому приложения никогда не хранят ключи.
Внедряйте секреты через агентов или CSI в хранилище в памяти, записывайте каждый доступ в журнал и защищайте хранилище как наиболее критически важный ресурс.

Далее мы сделаем секреты ещё безопаснее, создавая их динамически и выдавая на короткий срок.

Можно начать бесплатно

Изучай Cyber Security Academy с ИИ-репетитором — бесплатно

Пиши и запускай код прямо в браузере, получай мгновенную помощь от ИИ-репетитора 24/7 и продолжи учиться на сайте или в приложении.

Курсы: 76
Уроки: 303

Начать учиться бесплатно Посмотреть полный курс

Часто задаваемые вопросы

Урок «Хранилища секретов» бесплатный?

Да — полный текст урока «Хранилища секретов» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Cyber Security Academy, подпишись на CoddyKit PRO. Курс Cyber Security Academy содержит 4 уроков всего.

Чему я научусь в уроке «Хранилища секретов»?

Централизация секретов с помощью инструментов вроде Vault Ты практикуешь Cyber Security Academy с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать Cyber Security Academy?

Предыдущий опыт не требуется. Cyber Security Academy на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 2 из 4.

Сколько времени занимает урок «Хранилища секретов»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке Cyber Security Academy?

Да. Каждый урок Cyber Security Academy включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

← Назад к Cyber Security Academy