Два вопроса возникают у любого сервиса, как только он выходит за пределы «работает на моём ноутбуке»: где хранить секреты (пароли к базе, ключи, токены) и как понять, что происходит внутри, когда что-то идёт не так. Первое — про безопасность, второе — про наблюдаемость. В Yandex Cloud под каждую задачу есть сервис, чтобы не изобретать своё. Доступ ко всем ним выдаётся через Cloud IAM.

Lockbox: хранилище секретов

Lockbox — управляемое хранилище секретов: паролей, ключей, токенов. Идея простая: секреты не живут в коде, в конфигах и в git, а лежат в Lockbox, откуда приложение забирает их при старте по правам своего сервисного аккаунта.

Зачем так, а не «положить пароль в переменную окружения и забыть»:

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

Правило новичку: любой пароль или ключ, попавший в git, считается скомпрометированным. Даже если удалить его следующим коммитом — он остаётся в истории. Lockbox снимает соблазн «просто захардкодить».

KMS: шифрование

KMS (Key Management Service) управляет ключами шифрования. Он нужен, когда данные надо шифровать, но сами ключи не хочется хранить рядом с данными (иначе смысл теряется). KMS хранит ключи, а сервисы обращаются к нему, чтобы зашифровать и расшифровать. На ключах KMS шифруют диски, бэкапы, содержимое бакетов и сами секреты в Lockbox. Для новичка достаточно понимать: данные шифруются, а доступ к ключам — отдельно управляемое право.

Cloud Logging: логи

Когда сервис работает не на вашем ноутбуке, а в облаке, да ещё в нескольких копиях, смотреть логи через ssh на каждую машину невозможно. Cloud Logging собирает логи со всех ресурсов в одно место, где их можно искать и фильтровать. Приложения и managed-сервисы пишут туда автоматически или через агент.

Практический совет: пишите логи структурированно (в формате, где есть поля — уровень, идентификатор запроса, сервис), а не сплошным текстом. По структурированным логам можно искать и строить фильтры; по «простыне» текста — почти нет. Общие правила логирования не зависят от облака — их разбирает Observability style guide.

Monitoring: метрики и алерты

Логи говорят, что случилось в конкретный момент; Monitoring показывает картину во времени — метрики: загрузку процессора, задержку ответов, число ошибок, длину очереди. Из метрик собирают дашборды (наглядные графики) и, что важнее, алерты — правила вида «если ошибок больше стольки-то за минуту — разбудить дежурного».

Ключевая мысль для новичка: наблюдаемость нужна до аварии, а не после. Метрики и алерты, настроенные заранее, превращают «пользователи жалуются, а мы не понимаем почему» в «нам пришло уведомление, и мы уже чиним».

Audit Trails: кто что сделал

Audit Trails пишет журнал действий в облаке: кто создал ресурс, кто поменял права, кто удалил базу. Это не про ошибки приложения, а про действия людей и сервисов над инфраструктурой — незаменимо при разборе инцидентов безопасности («откуда взялся этот открытый наружу бакет?»).

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

Эта четвёрка — секреты в Lockbox, шифрование на KMS, логи в Cloud Logging, метрики и алерты в Monitoring — базовый гигиенический минимум любого боевого сервиса. Без них сервис вроде бы работает, но при первой же проблеме вы оказываетесь слепы и беззащитны.

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

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

Что учить дальше: как приложение получает доступ ко всему этому без ключей — в Cloud IAM; как обращаться к секретам из кода — в интеграции со Spring Boot; общие правила — в style guide по безопасности и наблюдаемости. Аналогичный набор в AWS — безопасность и наблюдаемость в AWS.