Cyber Security Academy · Урок

Динамические секреты и аренда

Краткоживущие учётные данные с автоматическим истечением срока действия

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

Статические и динамические секреты

Статический секрет создаётся один раз и используется бесконечно долго — например, один и тот же пароль базы данных, которым десять служб пользуются годами. Статические секреты используются по умолчанию, но именно в этом и заключается проблема: они действуют долго, широко распространяются и плохо поддаются ротации.

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

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

Как работают динамические секреты

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

Администратор настраивает хранилище, указывая корневые учетные данные базы данных и шаблон создания.
Приложение проходит аутентификацию и запрашивает учетные данные.
Хранилище выполняет на базе данных команду CREATE USER и возвращает новое имя пользователя и пароль.
После истечения аренды хранилище автоматически выполняет команду DROP USER.

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

# Configure Vault's database engine with a creation statement
vault write database/roles/billing-readonly \
  db_name=appdb \
  creation_statements="CREATE ROLE \"{{name}}\" LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON billing TO \"{{name}}\";" \
  default_ttl="1h" max_ttl="24h"

Запрос динамических учетных данных

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

Каждый потребитель получает собственные учетные данные. Если запускаются два экземпляра одной службы, они получают разные имена пользователей, что позволяет проводить аудит по каждому потребителю на уровне базы данных.

vault read database/creds/billing-readonly

# Example response:
# lease_id     database/creds/billing-readonly/abc123
# lease_duration  1h
# password     A1b-2Cd3-temp-xyz
# username     v-approle-billing-9f3a2

Аренда: договор о сроке действия

Аренда — это договор, определяющий, как долго секрет остаётся действительным. Каждый динамический секрет содержит TTL (срок действия) и необязательный максимальный TTL.

default_ttl — срок действия учетных данных до истечения.
max_ttl — абсолютный предел срока действия, который нельзя превысить даже при продлении.

Когда аренда истекает, хранилище отзывает учетные данные — оно активно удаляет пользователя базы данных. Истечение срока — не просто отметка: оно запускает реальную очистку. Благодаря этому утёкшие динамические секреты самостоятельно теряют силу: украденные учетные данные становятся бесполезными в пределах окна TTL.

Продление и отзыв аренд

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

Операторы также могут немедленно отозвать аренду — это аварийный выключатель на случай инцидента. Отзыв аренды сразу удаляет соответствующие учетные данные независимо от оставшегося TTL.

Можно даже отозвать все аренды с заданным префиксом, чтобы мгновенно прекратить доступ всей службы или среды.

# Renew a lease before it expires
vault lease renew database/creds/billing-readonly/abc123

# Revoke a single lease immediately (incident kill switch)
vault lease revoke database/creds/billing-readonly/abc123

# Revoke every lease under a path prefix
vault lease revoke -prefix database/creds/billing-readonly

Не только базы данных

Динамические секреты не ограничиваются базами данных. Хранилище и аналогичные инструменты создают учетные данные с коротким сроком действия для многих систем:

Облачный IAM — временные ключи доступа AWS/GCP и других облачных платформ через механизм принятия роли в стиле STS.
SSH — подписанные сертификаты SSH с коротким сроком действия вместо статических ключей.
PKI/TLS — сертификаты, выдаваемые по запросу и действующие недолго.
RabbitMQ, MongoDB, Консул — временные учетные данные служб.

Везде применяется один и тот же принцип: запросить, недолго использовать, автоматически прекратить действие. Статические облачные ключи с длительным сроком действия часто становятся источником утечек, а динамические учетные данные IAM устраняют эту проблему.

# Generate temporary AWS credentials scoped to a role
vault read aws/creds/deploy-role
# returns short-lived access_key, secret_key, security_token

# Sign an SSH key for short-lived access (valid minutes, not forever)
vault write ssh/sign/admin public_key=@id_ed25519.pub ttl=15m

Почему динамические секреты уменьшают масштаб последствий утечки

Рассмотрим утёкшие учетные данные при каждом из подходов:

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

Динамические секреты превращают ротацию из сложного ручного проекта в автоматическое непрерывное свойство системы.

Компромисс с корневыми учетными данными

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

Меры защиты:

Ротируйте сами корневые учетные данные, чтобы даже хранилище не сохраняло исходный пароль администратора.
Ограничьте учетную запись ровно теми разрешениями, которые нужны для создания и удаления пользователей, и не более.
Изолируйте узел хранилища и тщательно отслеживайте его работу, поскольку теперь это особо ценный объект для атаки.

Хранилище может ротировать собственные корневые учетные данные, поэтому после настройки ни один человек не знает их.

# After configuring the engine, rotate the root credential
# so even operators no longer know the original password
vault write -force database/rotate-root/appdb

Обработка истечения срока действия в коде приложения

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

Получить учетные данные и запомнить их TTL аренды.
Продлить аренду или повторно получить новые учетные данные до истечения срока.
Корректно подключиться заново после отзыва старых учетных данных.

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

# Vault Agent auto-renews and re-templates on rotation
auto_auth { method "approle" { ... } }
template {
  contents    = "{{ with secret \"database/creds/billing-readonly\" }}{{ .Data.username }}:{{ .Data.password }}{{ end }}"
  destination = "/run/secrets/db"
  command     = "systemctl reload billing-app"
}

Когда статических секретов не избежать

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

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

Практическое правило: предпочитайте динамические секреты; если приходится использовать статические, неустанно ротируйте их и проводите аудит.

Динамические секреты в непрерывной интеграции и доставке

Конвейеры непрерывной интеграции и доставки — одно из главных применений. Обычно конвейер хранит ключи развертывания с длительным сроком действия, что делает его привлекательной целью. При использовании динамических секретов конвейер:

Проходит аутентификацию в хранилище с помощью своей идентификации OIDC, например токена OIDC для действий GitHub.
Запрашивает краткосрочные облачные учетные данные, действительные только в течение задания.
Позволяет им автоматически истечь после завершения задания.

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

# GitHub Actions job exchanges its OIDC token for a short-lived AWS role
# No static AWS keys stored as repo secrets
permissions:
  id-token: write
steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123:role/deploy
      aws-region: eu-central-1

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

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

Повторение: динамические секреты и аренды

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

Динамические секреты создаются по запросу, уникальны для каждого потребителя и автоматически истекают, в отличие от повторно используемых статических секретов.
Аренда определяет TTL и максимальный TTL; после истечения срока хранилище отзывает учетные данные и выполняет реальную очистку.
Долго работающие приложения могут продлевать аренды, а операторы могут отзывать их мгновенно как аварийный выключатель при инциденте.
Динамические секреты работают с базами данных, облачным IAM, SSH, PKI и другими системами, уменьшая масштаб последствий утечек и автоматизируя ротацию.
Компромисс заключается в наличии в хранилище привилегированных корневых учетных данных: ротируйте их и жёстко ограничивайте их область действия.
Приложения и конвейеры непрерывной интеграции и доставки должны корректно обрабатывать истечение срока; предпочитайте динамические секреты, а статические ротируйте, если их нельзя избежать.

Далее мы рассмотрим ротацию ключей и обнаружение утечек, когда они всё же происходят.

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

Урок «Динамические секреты и аренда» бесплатный?

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

Чему я научусь в уроке «Динамические секреты и аренда»?

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

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

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

Сколько времени занимает урок «Динамические секреты и аренда»?

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

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

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

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

← Назад к Cyber Security Academy