← назад к разделу

Две темы, которые в облаке устроены иначе, чем on-premise — и обе в зоне ответственности разработчика, а не только безопасников. Секреты: в AWS им есть штатное место, и «пароль в ConfigMap» перестаёт быть вынужденным компромиссом. Наблюдаемость: у AWS свой стек, и надо решить, как он сочетается с привычным Prometheus/Grafana.

Secrets Manager: секреты как сервис

Secrets Manager хранит секреты (пароли БД, API-ключи, токены) с шифрованием, версиями, аудитом доступа и — главное — автоматической ротацией: для RDS он умеет менять пароль базы по расписанию сам, без участия людей и рестартов.

Доступ из Spring — через property source, без кода:

spring:
  config:
    import: aws-secretsmanager:/prod/order-service/

Права на чтение секрета — у IAM-роли сервиса, не у человека. Итоговая картина: секрет не существует ни в git, ни в CI-переменных, ни в манифестах — только в Secrets Manager, и каждый факт чтения виден в аудите. Это закрывает целый класс находок Gitleaks по построению. Parameter Store — младший брат для несекретной конфигурации (фиче-флаги, адреса) — дешевле и проще, граница простая: стыдно показать в логе — Secrets Manager, не стыдно — Parameter Store.

В EKS тот же результат достигается через External Secrets Operator: секрет из Secrets Manager синхронизируется в k8s Secret — манифесты остаются чистыми (деплой-статья запрещала секреты в git именно так).

KMS: один корень шифрования

KMS — управление ключами шифрования, и для разработчика это в основном галочки, которые надо не забыть: шифрование EBS-дисков, S3-бакетов, RDS, SQS — везде «encrypt at rest with KMS key». Современный дефолт: шифровано всё, ключи — customer managed для чувствительных данных (можно отозвать, виден аудит использования), AWS managed — для остального.

Когда KMS появляется в коде — это envelope encryption для шифрования на уровне приложения: данные шифруются data-ключом, data-ключ — мастер-ключом в KMS, который никогда не покидает HSM. Нужно редко (поле с особыми требованиями, клиентские данные с обязательством шифрования у приложения) — и тогда берётся готовая обвязка (AWS Encryption SDK), а не самописная криптография.

CloudTrail: кто что сделал

CloudTrail пишет каждый API-вызов в аккаунте: кто, что, когда, откуда. Для разработчика это не «инструмент безопасников», а инструмент разбора: «кто удалил очередь», «когда поменяли параметр RDS», «какая роль читала секрет» — отвечается за минуты. Включён по умолчанию; знать о его существовании — обязанность, пользоваться — суперсила при инцидентах.

Наблюдаемость: CloudWatch против своего стека

CloudWatch — родной стек AWS: метрики всех managed-сервисов появляются в нём автоматически (CPU RDS, глубина SQS, лаг MSK), логи — через агентов и интеграции, алармы — на любую метрику.

Развилка для приложенческой телеметрии: слать её в CloudWatch или держать свой стек (Prometheus/Grafana, как в observability-гайде)? Честные критерии:

  • CloudWatch достаточно, когда сервисов немного, команда маленькая и хочется нулевой эксплуатации мониторинга. Цена внимания: стоимость custom-метрик и логов растёт быстро (кардинальность здесь — буквально деньги), язык запросов беднее PromQL.
  • Свой стек поверх — когда есть k8s и привычка к Prometheus/Grafana/OTel: приложенческие метрики и трейсы — в своём стеке, инфраструктурные метрики managed-сервисов — забираются из CloudWatch экспортёром в тот же Prometheus. Это самая частая зрелая конфигурация: одна Grafana, два источника.

Не-развилка: структурированные логи, корреляция trace id, RED-метрики — обязательны в обоих вариантах; меняется только бэкенд хранения.

Чек-лист сервиса в AWS

  1. Секреты — только в Secrets Manager / External Secrets; в git и CI-переменных секретов нет.
  2. Роль сервиса узкая: свои очереди, свои бакеты, свои секреты (least privilege).
  3. Шифрование at rest включено на всех хранилищах; чувствительные данные — customer managed key.
  4. Алармы на инфраструктурные метрики managed-сервисов: соединения RDS, глубина и возраст SQS, лаг консьюмеров MSK.
  5. Логи структурированы, метрики с контролируемой кардинальностью — счёт за CloudWatch предсказуем.
  6. Доступ людей — через SSO-роли с MFA; постоянных access key у людей нет.

Что почитать дальше

  • Security Style Guide — SAST, Gitleaks и криптоправила, которые AWS не отменяет.
  • Observability Style Guide — логи, метрики и трейсы независимо от бэкенда.
  • Fundamentals — IAM-модель, на которой стоит весь этот раздел.
  • Интеграция из Spring — spring.config.import для Secrets Manager в коде.