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

Key Vault: хранилище секретов и ключей

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

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

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

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

Azure Monitor и Log Analytics

Когда сервис работает в облаке, да ещё в нескольких копиях, смотреть логи через вход на каждую машину невозможно. Azure Monitor — единая система наблюдаемости; логи собираются в Log Analytics, где их ищут и фильтруют мощным языком запросов (KQL), а метрики (загрузка процессора, задержка, число ошибок) собираются в дашборды и алерты — правила вида «если ошибок больше стольки-то за минуту — разбудить дежурного».

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

Application Insights

Application Insights — часть Azure Monitor, заточенная под само приложение (APM, application performance monitoring): она показывает время ответа по эндпоинтам, частоту ошибок, зависимости (запросы к базе и внешним сервисам) и трассировки запросов сквозь сервисы. Это переход от «сервер жив» к «конкретный запрос пользователя тормозит вот на этом вызове базы».

Defender for Cloud и Activity Log

Microsoft Defender for Cloud оценивает состояние безопасности: находит открытые наружу ресурсы, незашифрованные хранилища, слабые настройки и подсказывает, что исправить. А Activity Log пишет журнал действий над инфраструктурой: кто создал ресурс, кто поменял права, кто удалил базу — незаменимо при разборе инцидентов («откуда взялся этот публичный контейнер?»).

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

Эта связка — секреты в Key Vault, логи и метрики в Azure Monitor, трассировки в Application Insights — базовый гигиенический минимум любого боевого сервиса. Без неё сервис вроде бы работает, но при первой же проблеме вы оказываетесь слепы.

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

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

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