Secrets Management

«Закоммитил токен, удалил следующим коммитом — ок» — фраза, после которой я начинаю говорить про ротацию немедленно. Токен остался в истории git, в reflog, в форках, в кэше CI и в локальной копии у каждого, кто успел сделать pull. Удаление коммита не помогает — секрет ротируется сразу. Secrets Management — это дисциплина: централизованное хранилище (Vault, Secrets Manager, Sealed Secrets), наименьшие привилегии на доступ, регулярная ротация, полный журнал аудита, отрепетированный экстренный отзыв. Главная практика внутри L1 Information Security; соседи по рантайм-периметру — Access Control & IAM, Security Chaos Engineering и Compliance Frameworks.

Что должен уметь

Главный навык на уровне L6+ — уходить туда, где секрета нет вовсе. Между сервисами mTLS вместо общего пароля, короткоживущие учётные данные через workload identity (AWS IRSA, GCP Workload Identity, SPIFFE/SPIRE). Любой долгоживущий секрет — это утечка, которая просто ещё не случилась, а учётные данные с TTL в минуты и часы убирают целый класс рисков. Я регулярно вижу команды, которые старательно ротируют долгоживущие секреты вместо того, чтобы избавиться от них совсем. Шаг правильный, но не последний.

Понимает, что считается секретом (токен, пароль, приватный ключ, сертификат, ключ SSH); никогда не коммитит их в git; находит секреты своего сервиса в Vault или Secrets Manager команды.
Знает, с какой периодичностью ротируются секреты его сервиса; держит локальный хук на коммит (gitleaks, detect-secrets).

Настраивает доступ к secrets через IAM/RBAC по принципу наименьших привилегий: сервис A не видит секретов сервиса B; разработчик читает секреты прода только под запись в журнал.
Встраивает Vault или Secrets Manager в сервис: sidecar, SDK, подстановка в переменные окружения, Kubernetes Secrets через External Secrets Operator. Код работает со ссылкой на секрет, а не с самим значением.

Проектирует жизненный цикл секрета: выдача, ротация (автоматическая или по календарю), отзыв, срок жизни. Автоматическая ротация для доступов к базам и короткоживущих токенов — норма.
Внедряет процедуру экстренного отзыва на случай утечки: runbook, скрипты, эскалация — и всё это отрепетировано на game day, а не написано впервые во время инцидента.
Настраивает аудит: кто, когда и какой секрет запросил; отдаёт это в SIEM или в централизованные логи; ставит алерты на аномальные обращения.

L6+

Проектирует стратегию для организации: выбор инструментов, способы встраивания, требования комплаенса (SOC 2, PCI-DSS, GDPR, HIPAA).
Применяет zero-trust к доступу: mTLS между сервисами вместо общих паролей, короткоживущие учётные данные через workload identity, отсутствие секрета как целевое состояние.

Материалы

Книги и руководства

OWASP Secrets Management Cheat Sheet. Один из самых актуальных публичных документов по теме: централизация, жизненный цикл, стандарты шифрования, специфика облаков, реакция на утечку.
HashiCorp Vault Documentation. Канонический инструмент в этой области; документация работает как справочник по архитектуре, движкам секретов, способам аутентификации и динамическим учётным данным.

Статьи

The Twelve-Factor App, фактор III «Config». Принцип хранения конфигурации в окружении, а не в коде.

Инструменты

HashiCorp Vault — централизованное хранилище с динамическими секретами, множеством способов аутентификации и журналом аудита. По моим наблюдениям, стандарт для тех, кто не привязывается к одному облаку.
AWS Secrets Manager / GCP Secret Manager / Azure Key Vault — облачные альтернативы. Минимум возни со встраиванием, если вы целиком внутри одного облака; автоматическая ротация для RDS и Cloud SQL идёт через управляемые функции.
External Secrets Operator — оператор Kubernetes: тянет секреты из внешнего хранилища в родные Kubernetes Secrets. Стандарт для тех, кто живёт в Kubernetes.
Sealed Secrets (Bitnami) — контроллер, который позволяет держать зашифрованные секреты прямо в git. Альтернатива External Secrets там, где отдельного хранилища нет.
SOPS — шифрование файлов в git через age, KMS или PGP, без привязки к формату. Удобно для конфигов, где секреты идут вперемешку с обычными настройками.
Поиск утечек — gitleaks (регулярки плюс энтропия, хук на коммит, встраивание в CI), detect-secrets, trufflehog. Обязательны и локально, и в CI.

Best practices

Секрет не коммитится в git никогда. Ни на минуту, ни в приватный репозиторий, ни «я сразу удалю». Удаление коммита не помогает: секрет остаётся в истории, в reflog, в форках, в кэше CI и в локальной копии у каждого, кто успел сделать pull. Pre-commit hooks с gitleaks или detect-secrets — не паранойя, а обязательный нижний слой защиты.

Ротация — регулярная практика, а не реакция на взлом. Динамические credentials для баз, короткоживущие токены с TTL в минуты и часы, календарный ритм для того, что автоматизировать не вышло. Логика простая. Чем старше секрет, тем больше вокруг него накопилось копий и небрежного обращения: он лежит в чьём-то локальном .env, всплывает в старом тикете, куда его вставили для воспроизведения бага, попадает в переписку и в скриншот из чата, про который забыли все, кроме поисковой индексации.

Про наименьшие привилегии всё известно, и всё равно я регулярно вижу «дадим всем доступ в прод ко всем секретам, чтобы не блокировать людей». Цена такого решения выясняется при компрометации одной учётки: атакующий получает сразу всё. Правильная схема скучная и известная: доступ выдаётся строго по необходимости через IAM/RBAC, каждое обращение к секрету пишется в audit log с именем и временем, а повышение прав выдаётся под конкретную задачу и живёт минуты, а не до следующей инвентаризации.

Автоматическая ротация там, где возможно; ручная — исключение. Ручная ротация держится на дисциплине, а дисциплина ломается примерно через полгода. По моим наблюдениям, в командах с заявленной политикой «ротируем раз в квартал» через год реально ротируются только те токены, для которых это делает машина. Инструменты дешёвые — dynamic secrets в Vault, rotation Lambda в AWS Secrets Manager — и окупаются они на первом же инциденте.

Поиск утечек — это защита в глубину, а не «мы аккуратные». Достаточно одного новичка или одного отладочного захода в три часа ночи, чтобы токен уехал в коммит. Уровней три: хук локально, скан в CI, регулярный скан всей истории. Последний забывают чаще всего, и я регулярно вижу команды, где секрет находят через год после коммита именно потому, что настроенный gitleaks всё это время смотрел только на новые изменения, а до накопленной истории руки так и не дошли.

Emergency revocation отрепетирована, а не «прочитали runbook». Утечка в проде — и команда первый раз в жизни открывает UI Vault в поисках кнопки revoke. Минуты уходят, а секрет всё это время работает на атакующего. Лечится это game day: симулируем утечку, отрабатываем отзыв на время, фиксируем это время как метрику. Непроверенный runbook — документ, а не процедура.

Связанные листья

Infrastructure as Code — IaC хранит ссылку на секрет (vault.lookup("db/prod")), но никогда само значение.
Service Ownership — владелец сервиса он же владелец его секретов и их ротации.
Networking — TLS-сертификаты — частный случай секрета; mTLS вместо общих паролей — движение в сторону zero-trust.
Incident Response — утечка секрета — отдельный класс инцидентов со своим набором действий: отозвать, ротировать, поднять журналы, уведомить.
Runbooks — runbook на экстренный отзыв, ротацию и восстановление после утечки — обязательная часть набора дежурного.
Supply Chain Security — пересечение по федерации через OIDC; централизованная инфраструктура подписи — это тот же secrets management, только применённый к ключам подписи.
Vulnerability Management — уязвимость часто оборачивается утечкой секрета; ротация и узкая область действия снижают цену скомпрометированного.
Access Control & IAM — IAM отвечает на вопрос «кто», секреты — на вопрос «чем»; вместе получается единая модель аутентификации и авторизации.
Workload Identity — делает большинство общих секретов ненужными: криптографическая identity вместо API-токена, mTLS вместо bearer.
Compliance Frameworks — шифрование, управление ключами и контроль доступа — сквозные требования во всех фреймворках; SOC 2 CC6.6, PCI-DSS Req 3.
Security Code Review — поиск секретов (gitleaks, trufflehog) — общий для обеих практик слой: ревью ловит захардкоженный секрет до мержа, а этот лист отвечает за его жизнь в хранилище.

Открытые вопросы

Большая часть того, что раньше висело здесь как открытые вопросы, уже разъехалась по отдельным листьям. Threat Modeling ушёл под Secure Development. Access Control & IAM и Security Code Review стоят рядом и слинкованы выше. Workload Identity забрал SPIFFE/SPIRE, AWS IRSA, Workload Identity в GCP и Azure, OIDC federation в CI/CD. Compliance Frameworks — SOC 2, PCI-DSS, GDPR и HIPAA как драйверы требований к шифрованию, ротации ключей и журналу аудита.

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