Контекст
Шифрование, ключи и TLS
Secrets management дополняет криптографию: ключи нужно не только выбрать, но и безопасно оперировать ими.
Secrets Management Patterns - это архитектурные правила безопасной выдачи, хранения и ротации секретов. Ошибки в этой зоне ведут к критическим инцидентам, даже если остальная security-архитектура выглядит зрелой.
Core secrets patterns
Centralized secret store
Secrets в специализированном хранилище (Vault/KMS/Secrets Manager), а не в коде, env-файлах и CI переменных без контроля.
Dynamic credentials
Выдача временных учетных данных для БД/очередей/облака вместо долгоживущих статических секретов.
Automatic rotation
Регулярная ротация ключей и токенов с проверкой rollback-сценариев и обратной совместимости.
Least privilege access
Каждому workload только необходимые секреты и права, с детальным audit log доступа.
In-memory usage
Секреты не пишутся в логи/дампы/метрики, минимизируется время их присутствия в памяти процесса.
Delivery and rotation patterns
- Pull model: сервис получает секреты при старте/по TTL, а не через жестко прошитые конфиги.
- Sidecar/agent model: локальный агент обновляет секреты и контролирует доступ.
- Envelope encryption: данные шифруются DEK, а DEK защищен KMS-master ключом.
- Break-glass доступ для аварийных сценариев с обязательным аудитом и лимитом времени.
Related
Supply Chain Security
Секреты в CI/CD - критичная часть защиты цепочки поставки.
Operational checklist
Есть inventory всех секретов с owner, ротацией и зависимыми сервисами.
Есть alarms на истечение/невалидность секретов до user-facing инцидента.
CI/CD блокирует утечки секретов (secret scanning + policy checks).
Ротация тестируется в staging и production game day режиме.
Секреты разделены по окружениям (dev/stage/prod) без shared credentials.
Типичные антипаттерны
Hardcoded secrets в коде и IaC шаблонах.
Один 'master secret' на десятки сервисов без сегментации.
Ротация 'когда-нибудь позже' без автоматизации и monitoring.
Секреты в логах ошибок и stack traces.