Управление секретами
Тема дорожной карты · Backend разработчик
Управление секретами — это практика безопасного хранения, распространения, ротации и аудита чувствительных учётных данных: ключей API, паролей к базам данных, TLS-сертификатов и ключей подписи JWT, — гарантируя, что они никогда не попадут в исходный код или в журналы CI/CD. Золотым стандартом управления секретами является специализированное хранилище: HashiCorp Vault предоставляет динамические секреты (учётные данные, генерируемые по запросу с автоматическим истечением срока), тогда как AWS Secrets Manager и Google Secret Manager нативно интегрируются с IAM для детального управления доступом и автоматической ротации. В Kubernetes-окружениях секреты обычно инжектируются в поды в виде переменных окружения или примонтированных томов через External Secrets Operator, синхронизирующийся с Vault или облачными менеджерами секретов, заменяя нативный kubectl create secret, который хранит значения в base64-кодировке (а не шифрованными) в etcd. Код приложения должен получать секреты через переменные окружения (process.env.DB_PASSWORD в Node.js, os.environ['DB_PASSWORD'] в Python) или SDK (boto3.client('secretsmanager').get_secret_value()), но не через захардкоженные строки в Git. Аудиты управления секретами должны предусматривать короткие периоды ротации (90 дней и менее), сканирование репозиториев инструментами truffleHog или gitleaks для выявления случайных коммитов с секретами, а также мониторинг журналов аудита Vault на предмет несанкционированного доступа.
Как это работает
Управление секретами включает аутентификацию (кто вы?) и авторизацию (что можете?). Современная auth: OAuth 2.0 + OpenID Connect для делегированной identity, session-куки для традиционных веб-приложений, JWT для stateless distributed-систем. Пароли всегда хешируйте через bcrypt или argon2id. CSRF-защита на state-changing endpoints; CORS осознанно (не * в production). Авторизация: RBAC (роли), ABAC (атрибуты), policy engines (OPA, Casbin). MFA/2FA для любой привилегированной операции.
Когда применять
Session-куки — для монолитных веб-приложений (HttpOnly + Secure + SameSite=Lax): проще, отзываемо, server-side state. JWT — только когда реально нужна stateless distributed-валидация; иначе session безопаснее. Identity отдавайте провайдеру (Yandex ID, Keycloak, Auth0, Authentik) — DIY identity = место утечек. Rate-limit на auth-endpoints с первого дня.
Типичные ошибки
Ловушки Управление секретами: пароли через MD5/SHA1/SHA256 (быстро, brute-force-friendly — используйте argon2id); JWT-секрет в клиентском коде или git-history; JWT без expiry или revocation list (потерянный девайс = пожизненный доступ к аккаунту); своя крипта (используйте библиотеки); admin-endpoints без auth "потому что internal" (внутренняя сеть не граница безопасности). Регулярные auth-аудиты.