Оглавление

• Кому важно и какая выгода
• Типичные ошибки
• Модель угроз коротко
• Где хранить секреты
  • .env и Kubernetes Secret: почему мало
  • Шифрование ключом облака (KMS)
  • Центральный менеджер секретов (Vault/SSM/Secret Manager)
• Ротация без простоя: паттерны
  • Пароль БД: две учётки и мягкое переключение
  • Токены внешних сервисов
  • JWT‑ключи и JWKS
  • Клиентские сертификаты для mTLS
• Kubernetes: автоматизация ротации
  • External Secrets Operator + AWS Secrets Manager
  • Vault Agent Injector: секреты как файлы и env
  • Sealed Secrets для GitOps
• План внедрения за 2 недели
• Метрики и алерты
• Аудит и соответствие требованиям
• Экономика: сколько стоит и что даёт
• Чек-лист
• FAQ

Кому важно и какая выгода

Если у вас B2B/B2C‑сервис, мобильное приложение, платёжные интеграции или партнерские API — у вас есть секреты: пароли БД, ключи подписи, токены платёжек, вебхуки. Их безопасное хранение и своевременная ротация — это:

• меньше инцидентов и штрафов за утечки,
• быстрая реакция на компрометацию доступа (минуты, а не дни),
• предсказуемые релизы без простоя при смене паролей и ключей,
• соответствие требованиям клиентов и регуляторов.

Типичные ошибки

• Секреты в git или в .env, разлетаются по ноутбукам и CI‑логам.
• Один и тот же токен в проде и тесте.
• Отсутствие ротации: «сделали год назад и забыли». Секреты не меняются годами.
• Хранение в Kubernetes Secret «как есть»: это base64, а не безопасность.
• Ручная ротация ночью: простаивают сервисы, откаты, сорванные дедлайны.
• Логи и метрики с чувствительными данными (URL с паролем, заголовки авторизации).

Модель угроз коротко

• Утечка из репозитория/CI: секрет попал в историю коммитов, артефакты или переменные окружения.
• Компрометация сервера: доступ к файловой системе/окружению контейнера.
• Сторонний подрядчик/сотрудник уходит, а пароль не сменили.
• Утечка через баг — мы печатаем секреты в логи, метрики, ошибки.
• Злоумышленник брутит внутренние сервисы, если нет ограничения доступа и мTLS.

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

Где хранить секреты

.env и Kubernetes Secret: почему мало

.env удобен для локальной разработки, но в проде это:

• риск попасть в git/бэкапы/логи CI;
• отсутствие аудита и контроля доступа;
• сложная ротация.

Kubernetes Secret хранится в etcd в base64. Минимально — включить шифрование Secret в etcd через поставщика KMS кластера и ограничить доступы RBAC. Но это только база, без аудита и ротации.

Шифрование ключом облака (KMS)

KMS — это управляемый сервис шифрования (AWS KMS, GCP KMS, Azure Key Vault Keys). Он даёт:

• шифрование «конвертом» (когда мастер‑ключ шифрует рабочие ключи),
• контроль доступа через IAM/ролями,
• аудит вызовов API,
• ротацию мастер‑ключей.

Пример ручного шифрования файла ключом KMS:

aws kms encrypt --key-id alias/app-prod --plaintext fileb://secret.txt \
  --output text --query CiphertextBlob > secret.enc.base64

# Расшифровать на машине с правами к KMS
aws kms decrypt --ciphertext-blob fileb://secret.enc.base64 \
  --output text --query Plaintext | base64 -d > secret.txt

Такой подход лучше совмещать с автоматизацией (например, sops) или с менеджером секретов, чтобы приложение не знало о KMS напрямую.

Центральный менеджер секретов (Vault/SSM/Secret Manager)

• HashiCorp Vault — гибкий и мощный, с динамическими секретами (например, выдаёт временный пароль БД на N минут).
• AWS Systems Manager Parameter Store / Secrets Manager, GCP Secret Manager, Azure Key Vault — управляемые облачные альтернативы с интеграциями и аудитом.

Плюсы: контроль доступа по ролям, аудит, автоматическая ротация, интеграции с Kubernetes и CI, удобные API. Это базовый выбор для прод‑сред.

Ротация без простоя: паттерны

Пароль БД: две учётки и мягкое переключение

В PostgreSQL нет «двойного пароля» на одну учётку. Рабочий паттерн:

1. Создаём вторую учётку с теми же правами.
2. Обновляем секрет приложения на новую учётку.
3. Перекатываем приложение (rolling update), проверяем, что все новые соединения — под новой учёткой.
4. Гасим старые соединения, удаляем старую учётку.

SQL для PostgreSQL (роль прав отдельно, два логина на одну роль):

-- Роль с правами приложения
CREATE ROLE app_role;
GRANT CONNECT ON DATABASE appdb TO app_role;
GRANT USAGE ON SCHEMA public TO app_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_role;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_role;

-- Текущая учётка
CREATE ROLE app_v1 LOGIN PASSWORD 'S3cure#2025';
GRANT app_role TO app_v1;

-- Новая учётка для ротации
CREATE ROLE app_v2 LOGIN PASSWORD 'S3cure#2026';
GRANT app_role TO app_v2;

-- После переката на app_v2
REVOKE app_role FROM app_v1;
DROP ROLE app_v1;

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

• используйте пул соединений (PgBouncer) — переключение быстрее и мягче;
• держите таймаут жизни соединений короче, чем окно ротации;
• не шейрите одну учётку на все сервисы — тогда ротация точечная.

MySQL поддерживает «двойной пароль» для одной учётки (c 8.0.14), можно включить новый пароль как «второй», перекатить, затем удалить старый.

Токены внешних сервисов

• Проверьте, поддерживает ли сервис вторую пару ключей (многие платёжки и мессенджеры — да). Сначала создаём вторую, переключаемся, потом удаляем старую.
• Делайте токены короткоживущими и обновляйте по refresh‑процессу. Не храните вечные ключи в коде и образах.

JWT‑ключи и JWKS

Для подписи токенов используйте пару ключей и публикуйте открытые ключи через JWKS‑эндпойнт. При ротации добавляйте новый ключ (с новым kid), дайте потребителям подтянуть его, потом уберите старый.

Проверка токена по JWKS на стороне потребителя (Node.js):

const jwksClient = require('jwks-rsa');
const jwt = require('jsonwebtoken');

const client = jwksClient({
  jwksUri: 'https://auth.example.com/.well-known/jwks.json',
  cache: true,
  cacheMaxEntries: 5,
  cacheMaxAge: 10 * 60 * 1000
});

function getKey(header, cb) {
  client.getSigningKey(header.kid, function(err, key) {
    if (err) return cb(err);
    const signingKey = key.getPublicKey();
    cb(null, signingKey);
  });
}

function verify(token) {
  return new Promise((resolve, reject) => {
    jwt.verify(token, getKey, { algorithms: ['RS256'] }, (err, decoded) => {
      if (err) return reject(err);
      resolve(decoded);
    });
  });
}

Клиентские сертификаты для mTLS

Используйте cert-manager в Kubernetes и короткие сроки жизни сертификатов (дни/недели). Ротация пройдёт автоматически без простоя.

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: app-ca
  namespace: app
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: app-mtls
  namespace: app
spec:
  secretName: app-mtls
  commonName: app
  duration: 168h # 7 дней
  renewBefore: 24h
  issuerRef:
    name: app-ca
    kind: Issuer

Kubernetes: автоматизация ротации

External Secrets Operator + AWS Secrets Manager

ESO синхронизирует секреты из облака в Kubernetes Secret и умеет обновлять их по расписанию. Поды перезапускаются при изменении Secret.

ServiceAccount для доступа к секретам (в EKS — через роль IAM, упрощённо):

apiVersion: v1
kind: ServiceAccount
metadata:
  name: eso-sa
  namespace: app

SecretStore с AWS Secrets Manager:

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: aws
  namespace: app
spec:
  provider:
    aws:
      service: SecretsManager
      region: eu-central-1
      auth:
        jwt:
          serviceAccountRef:
            name: eso-sa

ExternalSecret для базы:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-db
  namespace: app
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws
    kind: SecretStore
  target:
    name: app-db
    creationPolicy: Owner
  data:
  - secretKey: DATABASE_URL
    remoteRef:
      key: app/prod/db
      property: url

Использование в Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
  namespace: app
spec:
  replicas: 3
  selector:
    matchLabels: { app: app }
  template:
    metadata:
      labels: { app: app }
    spec:
      serviceAccountName: eso-sa
      containers:
      - name: app
        image: registry.example.com/app:1.2.3
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: app-db
              key: DATABASE_URL

Vault Agent Injector: секреты как файлы и env

Vault умеет подсаживать агента‑сайдкар, который кладёт секреты в файловую систему или переменные окружения и обновляет их.

Политика Vault (HCL):

path "kv/data/app/prod/*" {
  capabilities = ["read"]
}

Аннотации Deployment для инжектора:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
  namespace: app
  annotations:
    vault.hashicorp.com/agent-inject: 'true'
    vault.hashicorp.com/role: 'app-role'
    vault.hashicorp.com/agent-inject-secret-db: 'kv/data/app/prod/db'
    vault.hashicorp.com/agent-inject-template-db: |
      {{- with secret "kv/data/app/prod/db" -}}
      DATABASE_URL={{ .Data.data.url }}
      {{- end -}}
spec:
  replicas: 2
  selector:
    matchLabels: { app: app }
  template:
    metadata:
      labels: { app: app }
    spec:
      containers:
      - name: app
        image: registry.example.com/app:1.2.3
        envFrom:
        - secretRef:
            name: vault-secrets

Sealed Secrets для GitOps

Чтобы не хранить открытые Secret в git, используйте Sealed Secrets: в репозитории — только зашифрованные объекты, а в кластере контроллер их расшифровывает.

kubectl create secret generic app-db \
  --from-literal=DATABASE_URL='postgres://app_v2:pass@db:5432/app' \
  -n app --dry-run=client -o json \
| kubeseal --controller-namespace kube-system --format yaml > app-db-sealed.yaml

kubectl apply -f app-db-sealed.yaml

План внедрения за 2 недели

День 1–2: аудит секретов

• Составьте реестр: что, где хранится, кто использует, период ротации, владелец.
• Найдите секреты в коде/истории git/CI через сканер (trufflehog, gitleaks).

День 3–4: выбор инструмента

• Если вы в облаке и у вас Kubernetes — начните с облачного менеджера секретов + External Secrets Operator.
• Нужны динамические секреты и тонкие политики — рассмотрите Vault.

День 5–7: пилот на одном сервисе

• Перенесите 1–2 секрета в менеджер, подключите к приложению.
• Настройте ротацию для пароля БД по паттерну двух учёток.
• Добавьте алерты: срок жизни, ошибки синхронизации, отказы агентов.

День 8–10: распространение

• Описываем шаблоны YAML/Helm, политики, роли.
• Переводим остальные сервисы пачками по 2–3 в день.

День 11–14: операционные мелочи

• Включите шифрование Secret в etcd (если не включено).
• Запретите секреты в логах и метриках (редакторы, фильтры).
• Пропишите регламент: кто владелец секрета, кто и как его ротирует.

Метрики и алерты

• Возраст секрета > X дней (SLO ротации, например 90 дней для статичных секретов, 1–7 дней для токенов/сертификатов).
• Ошибки инжекции/синхронизации (ESO/Vault Agent): количество ошибок за 5 минут > 0.
• Количество подов с устаревшей версией секрета > 0.
• Неудачные попытки чтения в Vault/KMS (по аудит‑логам).
• Неудачная верификация JWT из‑за неподходящего kid (проблема с JWKS ротацией).

Примеры правил Prometheus (псевдонимы метрик — адаптируйте под свой стек):

- alert: VaultLeaseRenewalErrors
  expr: rate(vault_agent_renewal_errors_total[5m]) > 0
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: Сбой продления секрета через Vault Agent

- alert: ExternalSecretSyncFailed
  expr: increase(externalsecret_sync_calls_failed_total[10m]) > 0
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: Ошибка синхронизации ExternalSecret

Аудит и соответствие требованиям

• Включите аудит в Vault/KMS/облачном менеджере секретов. Логируйте кто, что и когда читал/менял.
• Для Kubernetes: аудит‑лог сервера API и ограничения RBAC (минимальные права).
• DLP‑проверки на репозитории и артефакты CI.
• Политики «минимально необходимого доступа» для сервис‑аккаунтов.
• Регламент инцидентов: что делать при утечке (отозвать, сменить, уведомить, проверить логи).

Экономика: сколько стоит и что даёт

Затраты:

• Часы инженеров на внедрение (1–2 недели на базовый контур для среднего проекта).
• Лицензии/сервисы (Vault — open source, но инфраструктура; облачные менеджеры — плата за секрет/запросы).

Выигрыш:

• Снижение риска утечки и простоя (вероятность × ущерб). Один предотвращённый инцидент часто окупает всё внедрение.
• Быстрая ротация при компрометации: минуты против часов/дней.
• Проходим аудит клиентов быстрее, повышаем конверсию в сделки Enterprise.

Чек-лист

• Секреты не лежат в git/образах/логах.
• Шифрование Secret в etcd включено (провайдер KMS).
• Выбран и настроен менеджер секретов (Vault/облако).
• Kubernetes интегрирован: ESO или Vault Agent.
• Ротация БД по паттерну двух учёток отработана на стенде.
• JWKS опубликован, потребители кэшируют ключи по kid.
• Метрики и алерты по ротации/ошибкам включены.
• Аудит запросов к секретам настроен.
• Регламенты и владельцы секретов определены.

FAQ

В: Нужно ли шифровать значения в Kubernetes Secret, если у нас уже есть Vault? О: Да, включите шифрование Secret в etcd — это базовая гигиена. Vault решает доставку и ротацию, а шифрование в etcd защищает от утечки снапшотов/бэкапов кластера.

В: Как часто ротировать пароли БД? О: Если нет динамических секретов — раз в 90 дней. Если есть подозрение на компрометацию — немедленно. Для особо критичных сервисов рассмотрите динамические секреты с TTL 1–24 часа.

В: Можно ли хранить секреты только в переменных окружения контейнера? О: Можно, но следите, чтобы они не попали в логи/дампы/диагностику. Для особо чувствительных значений лучше монтировать как файл с ограниченными правами и коротким TTL, а приложение перечитывает файл.

В: Что выбрать: Vault или облачный Secret Manager? О: Если вы в одном облаке и хотите быстрее — начните с облачного. Если нужна мультиоблачность, динамические секреты для БД, гибкие политики — Vault.

В: Как убедиться, что все поды обновились на новый секрет? О: В ESO при изменении Secret меняется его ресурс‑версия, и контроллер Deployment делает rolling update. В Vault Agent можно включить отправку сигнала приложению при обновлении файла. Добавьте проверку версий секретов в readiness‑пробу или экспозер метрики версии.