Когда приложение работает на вашем ноутбуке, пароль от базы можно просто положить в файл рядом с кодом. В облаке так нельзя: код видят коллеги, файлы попадают в систему контроля версий, серверов много и они появляются и исчезают сами. Поэтому в AWS есть отдельные сервисы для двух задач, которые раньше решались «как-нибудь»: где безопасно хранить секреты и как понимать, что вообще происходит внутри ваших серверов.

Эта статья — про четыре таких сервиса. Secrets Manager и SSM Parameter Store хранят пароли и настройки. KMS отвечает за шифрование. CloudWatch собирает логи, метрики и присылает оповещения, когда что-то пошло не так. Рядом разберём и CloudTrail — сопутствующий инструмент аудита, который фиксирует, кто и что делал в аккаунте. Пройдёмся по каждому по очереди, человеческим языком и с примерами команд, которые можно попробовать самому.

Secrets Manager: сейф для паролей

Секрет — это любая чувствительная строка: пароль от базы данных, ключ к стороннему API, токен. Secrets Manager — это управляемое хранилище таких строк. Вы кладёте секрет один раз, а приложение запрашивает его при старте по имени.

Главное, что вы получаете взамен пары строк в файле:

  • Шифрование — секрет хранится зашифрованным, в открытом виде его нет нигде на диске.
  • Версии — при смене пароля старое значение не теряется, можно откатиться.
  • Аудит — каждое чтение секрета фиксируется, видно кто и когда обращался.
  • Автоматическая ротация — Secrets Manager умеет сам менять пароль базы по расписанию.

Положить секрет и прочитать его — две команды:

aws secretsmanager create-secret --name prod/db/password --secret-string "s3cr3t-value"
aws secretsmanager get-secret-value --secret-id prod/db/password --query SecretString --output text

Ротация устроена интереснее, чем кажется. Когда вы её включаете для базы RDS, AWS заводит маленькую функцию (Lambda), которая по расписанию проходит четыре шага: создаёт новый пароль, прописывает его в базу, проверяет вход с новым паролем и только потом делает его текущим. Во время смены оба пароля — старый и новый — какое-то время работают, поэтому приложение не падает: даже если оно ещё держит старое значение, оно успеет перечитать новое. Это и называется сменой пароля без простоя.

Кто имеет право читать секрет? Не человек, а роль сервиса — об IAM-ролях подробно в статье про основы AWS. В итоге пароля нет ни в коде, ни в системе контроля версий, ни в переменных сборки — только в Secrets Manager. Это закрывает целый класс утечек: украсть нечего, потому что в репозитории секрета просто нет.

SSM Parameter Store: настройки и дешёвые секреты

SSM Parameter Store (часть сервиса AWS Systems Manager) — это хранилище для настроек приложения: адреса других сервисов, признаки включённых функций, имена бакетов. Параметры бывают двух типов: обычная строка (String) и зашифрованная (SecureString). SecureString шифруется через KMS — то есть Parameter Store тоже умеет хранить секреты.

aws ssm put-parameter --name /prod/app/feature-x --type String --value enabled
aws ssm put-parameter --name /prod/db/password --type SecureString --value "s3cr3t-value"
aws ssm get-parameter --name /prod/db/password --with-decryption --query Parameter.Value --output text

Зачем тогда два сервиса? Разница простая и в основном про деньги и удобство. Стандартный уровень Parameter Store бесплатный — ни за хранение, ни за обращения платить не нужно. Secrets Manager стоит около 0,40 доллара за секрет в месяц плюс копейки за обращения, но даёт то, чего у Parameter Store нет: автоматическую ротацию паролей и готовую интеграцию с базами.

Практическое правило новичка:

  • нужна автоматическая смена пароля базы — Secrets Manager;
  • просто настройки или редкий секрет без ротации, и хочется не платить — SSM Parameter Store с типом SecureString.

И ещё одна аналогия для границы между секретом и настройкой: стыдно было бы увидеть это значение в логе — значит, это секрет, и шифруем. Не стыдно (адрес сервиса, флаг) — обычный параметр.

KMS: где живут ключи шифрования

Любое шифрование держится на ключе. Если ключ лежит рядом с зашифрованными данными — толку от шифрования мало. KMS (Key Management Service) решает эту проблему: ключи хранятся внутри защищённого оборудования AWS и никогда его не покидают. Вы не получаете сам ключ — вы просите KMS зашифровать или расшифровать что-то этим ключом.

Для новичка KMS чаще всего выглядит как «галочка, которую нельзя забыть». При создании диска, бакета S3, базы RDS или очереди есть опция «шифровать при хранении» (encrypt at rest) — и она использует именно KMS. Современный подход простой: шифруем всё.

Ключи бывают двух видов:

  • AWS managed — AWS создаёт и обслуживает ключ за вас. Подходит для большинства данных.
  • Customer managed — вы сами заводите ключ, можете его отозвать и видите в аудите каждое использование. Берут для особо чувствительных данных.

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

CloudTrail: кто что сделал в аккаунте

CloudTrail записывает каждое действие в аккаунте AWS: кто, что, когда и откуда вызвал. Это не инструмент только для безопасников — это ваш способ разобраться, когда что-то сломалось. «Кто удалил очередь?», «когда поменяли настройку базы?», «какая роль читала секрет?» — ответ находится за минуты. CloudTrail включён по умолчанию; от вас требуется знать, что он есть, и заглядывать в него при разборе происшествий.

CloudWatch: логи, метрики и оповещения

CloudWatch — родная система наблюдения AWS. У неё три части, которые легко перепутать:

  • Logs — текстовые логи приложений и сервисов.
  • Metrics — числа во времени: загрузка процессора базы, длина очереди, число запросов.
  • Alarms — правила вида «если метрика превысила порог — пришли оповещение».

Большой плюс для начинающего: метрики управляемых сервисов появляются в CloudWatch сами, без настройки. Создали базу RDS — её загрузка процессора и число соединений уже видны. Дальше на любую метрику вешается аларм:

aws cloudwatch put-metric-alarm \
  --alarm-name rds-cpu-high \
  --namespace AWS/RDS \
  --metric-name CPUUtilization \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2

Логи приложения можно отправлять в CloudWatch и искать по ним. Полезный совет на старте: пишите логи структурированно (в формате JSON, а не сплошным текстом) — тогда по ним удобно фильтровать и строить метрики. Минимум полезных полей — уровень (error/info), сообщение и идентификатор запроса, по которому можно связать строки одного обращения.

Одна важная деталь про счета: в CloudWatch вы платите за объём логов и за собственные метрики. Если логировать каждую мелочь или заводить метрику на каждый уникальный параметр — счёт быстро растёт. Держите объём логов под контролем, и расходы останутся предсказуемыми.

Многие команды используют CloudWatch вместе со своими инструментами наблюдения (например, Grafana): метрики приложения и трассировки запросов хранят у себя, а метрики управляемых сервисов забирают из CloudWatch в общую панель. Так получается один экран на всё с двумя источниками данных — частая зрелая схема.

Где это применяется

Эти четыре сервиса встречаются в любом облачном проекте, как только он выходит за пределы «запустил у себя на ноутбуке». Secrets Manager и SSM прячут пароли при работе с базами из статьи про управляемые данные и DynamoDB; шифрование KMS включают для S3 и объектного хранилища; CloudWatch ставят рядом с масштабированием и доступностью и бессерверными функциями, чтобы видеть нагрузку. Когда вы описываете инфраструктуру кодом — через Terraform, CloudFormation или CDK — секреты, ключи и алармы тоже задаются там, а сборочные конвейеры из раздела про CI/CD читают секреты из этих хранилищ, а не из своих переменных.

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

  • Секрет в коде или в системе контроля версий. Самая частая утечка. Пароль всегда живёт в Secrets Manager или SSM, в репозитории — только имя секрета.
  • Слишком широкие права у роли. Роль сервиса должна читать только свои секреты и свои бакеты — это принцип наименьших привилегий, про роли см. основы AWS и IAM.
  • Шифрование забыли включить. Лишняя галочка кажется ненужной ровно до первого аудита. Включайте шифрование сразу при создании ресурса.
  • Нет алармов, узнаём о проблеме от пользователей. Хотя бы пара алармов на загрузку базы и на ошибки приложения экономят много нервов.
  • Логи валятся сплошным текстом, и счёт за CloudWatch неожиданно большой. Структурируйте логи и не пишите лишнего.

Что учить дальше: разберитесь с IAM и сетью — на них держится доступ к секретам и шифрованию; посмотрите, как подключить эти сервисы из приложения, в статье про интеграцию приложения с AWS; затем — отказоустойчивость и аварийное восстановление и оптимизацию расходов, где логи и метрики помогают находить лишние траты. Сводный взгляд на всё это даёт Well-Architected Framework.