Как управляемые удостоверения устраняют жёстко заданные пароли в Azure

By Mirko Peters · 2026-08-13

Добро пожаловать обратно в сопутствующий блог нашего подкаста! Если вы создаёте приложения достаточно долго, вы, скорее всего, сталкивались с давней проблемой о…

Automatically translated with AI from the original post. Read the English original

Добро пожаловать обратно в сопутствующий блог к нашему подкасту! Если вы довольно долго создаёте приложения, то наверняка сталкивались с давней проблемой: как подключить код к базе данных, API или учётной записи облачного хранилища. Раньше разработчики решали её, просто записывая строку подключения, пароль к базе данных или клиентский секрет прямо в конфигурационный файл, переменную среды или, что ещё хуже, жёстко прописывая их в исходный код репозитория. Пока приложение могло прочитать этот секрет, оно могло пройти аутентификацию и выполнять свою работу. Но что происходит, когда такой код случайно попадает в публичный репозиторий GitHub? Что происходит, когда недовольный сотрудник уходит из компании или злоумышленник получает доступ на чтение к настройкам вашего приложения? Вся ваша инфраструктура мгновенно оказывается скомпрометирована. В современной облачной архитектуре это недопустимый риск. Сегодня мы подробно разберём, как управляемые удостоверения (Managed Identities) в Microsoft Azure полностью устраняют необходимость в жёстко заданных паролях, заменяя статические секреты динамическими краткоживущими токенами доступа.

Введение в облачную безопасность и жёстко заданные секреты

Традиционная модель безопасности, основанная на периметре, в значительной мере полагалась на идею, что однажды оказавшись внутри корпоративной сети, пользователю можно доверять. Внутри этого периметра приложения взаимодействовали с помощью статических сервисных учётных записей, жёстко заданных паролей и долгоживущих токенов, которые редко, если вообще когда-либо, истекали. Если злоумышленнику удавалось преодолеть периметр, у него появлялся доступ к кладовой статических учётных данных, которые можно было использовать повторно бесконечно.

Облачные вычисления полностью разрушили этот периметр. Наши рабочие нагрузки теперь распределены между мультиоблачными средами, локальными центрами обработки данных, SaaS-платформами и распределёнными бессерверными функциями. В этом новом мире безопасность должна следовать за идентичностью самой рабочей нагрузки. Жёстко заданные секреты — это бомбы с часовым механизмом. Они не ротируются автоматически, их крайне сложно аудировать, и при утечке они не оставляют практически никакого запаса для ошибки. Чтобы добиться по-настоящему эшелонированной модели Zero Trust, мы должны полностью отделить учётные данные от исходного кода. Нам нужен механизм аутентификации, при котором приложения могут доказать, кто они такие, и при этом им никогда не нужно знать или хранить пароль.

Пользовательские и рабочие удостоверения в Entra ID: в чём разница

Чтобы понять, как эволюционировала облачная безопасность, сначала нужно разобраться, как Microsoft Entra ID управляет сущностями, которые обращаются к нашим системам. В общих чертах Microsoft Entra ID делит удостоверения на две основные группы: пользовательские удостоверения и рабочие удостоверения.

Пользовательские удостоверения представляют людей: сотрудников, партнёров, подрядчиков и клиентов. Люди динамически взаимодействуют с системами и проходят аутентификацию методами, рассчитанными на человека, такими как пароли, Windows Hello для бизнеса, ключи безопасности FIDO2 и многофакторная аутентификация. Люди забывают пароли, становятся жертвами фишинга и требуют административного сброса паролей.

Рабочие удостоверения, напротив, представляют программное обеспечение. Сюда относятся приложения, фоновые службы, сценарии автоматизации, Azure Functions, Logic Apps, конвейеры развёртывания DevOps и агенты ИИ. Рабочие нагрузки не пьют кофе, не кликают по фишинговым письмам и не могут пройти интерактивный запрос многофакторной аутентификации на смартфоне. Им нужно проходить аутентификацию неинтерактивно, программно и непрерывно. Относиться к рабочему удостоверению как к пользовательскому, присвоив ему статический пароль, — одна из самых распространённых ошибок в облачной архитектуре. Рабочие удостоверения требуют собственных специализированных моделей управления, жизненного цикла и автоматизированных потоков аутентификации.

Разбираемся с регистрациями приложений, субъектами-службами и управляемыми удостоверениями

Если вы хоть немного настраивали приложения в Microsoft Entra ID, то наверняка натыкались на три термина, которые часто вызывают путаницу: регистрации приложений (Application Registrations), субъекты-службы (Service Principals) и управляемые удостоверения (Managed Identities). Давайте просто разберём каждый из них.

Регистрация приложения (Application Registration) — это глобальное определение, или шаблон, вашего приложения. Когда вы регистрируете приложение в Microsoft Entra ID, вы создаёте его глобальную идентичность во всей экосистеме с несколькими клиентами. Здесь вы определяете, какие разрешения может понадобиться приложению, какие конечные точки аутентификации оно использует и какие URI с ним связаны. Представьте регистрацию приложения как шаблон паспорта.

Субъект-служба (Service Principal) — это локальный экземпляр этого приложения в конкретном клиенте. Если приложение многоклиентское, у него будет одна регистрация приложения в клиенте издателя, но отдельный субъект-служба в каждом клиенте заказчика, где оно развёрнуто и получило согласие. Именно субъект-служба — это место, где администраторы фактически назначают разрешения, применяют политики условного доступа и контролируют, кто может получить доступ к приложению локально. Представьте субъект-службу как уже проштампованный паспорт, по которому вас пускают в конкретную страну.

Управляемая идентификация (Managed Identity) делает ещё один шаг в этой концепции именно для ресурсов, работающих внутри Microsoft Azure. Вместо того чтобы разработчик вручную создавал регистрацию приложения, генерировал клиентский секрет, сохранял этот секрет в переменной среды и писал код для управления жизненным циклом аутентификации, Azure берёт на себя весь процесс за кулисами. Azure создаёт, управляет и автоматически обновляет лежащие в основе учётные данные. Разработчику достаточно указать ресурсу Azure использовать его управляемую идентификацию, а Azure сделает всё остальное.

Как управляемые идентификации устраняют пароли и жёстко заданные учётные данные

Главная особенность управляемых идентификаций — в том, как они меняют сам процесс аутентификации. Когда вы используете управляемую идентификацию для ресурса Azure, например Azure App Service, виртуальной машины или Azure Function, в вашем коде или настройках конфигурации действительно не хранится ни пароль, ни секрет, ни сертификат.

Когда приложению нужен доступ к защищённому ресурсу, например к базе данных или API, оно не ищет сохранённый пароль. Вместо этого приложение выполняет локальный вызов к конечной точке службы метаданных экземпляра Azure (IMDS), которая доступна безопасно только изнутри этого конкретного ресурса Azure. Платформа ресурса Azure запрашивает у Microsoft Entra ID краткоживущий токен JSON Web Token (JWT) от имени приложения.

Microsoft Entra ID проверяет идентичность ресурса Azure, выдаёт криптографически подписанный токен доступа с очень коротким сроком жизни (обычно около одного часа) и передаёт его приложению. Затем приложение использует этот токен для аутентификации в целевой службе. Поскольку токен быстро истекает, даже если злоумышленнику удастся его перехватить, окно уязвимости будет крайне узким. Кроме того, так как в коде не записан статичный пароль, разработчику нечего случайно слить в публичный репозиторий.

Интеграция Azure Key Vault и краткоживущих токенов доступа

Управляемые идентификации избавляют от необходимости в паролях приложений, но вы можете спросить, как приложения работают с секретами, которые действительно являются внешними, например с API-ключами сторонних сервисов, не поддерживающих аутентификацию Microsoft Entra. Здесь на помощь приходит Azure Key Vault, который работает в тандеме с управляемыми идентификациями.

Вместо того чтобы жёстко прописывать API-ключ стороннего сервиса в исходном коде, вы безопасно сохраняете этот секрет в Azure Key Vault. Затем вы предоставляете управляемой идентификации вашего ресурса Azure разрешение на чтение секретов из этого Key Vault с помощью управления доступом на основе ролей Azure (Azure RBAC) или политик доступа Key Vault.

Когда приложение запускается, оно использует свою управляемую идентификацию для аутентификации в Azure Key Vault, динамически получает нужный API-ключ стороннего сервиса в память и использует его. Ни в какой момент учётные данные не попадают в исходный код. Приложение использует безопасный механизм, основанный на идентичности, чтобы получить секрет, а не полагается на статичную строку, встроенную в конфигурационный файл.

Защита рабочих идентификаций с принципом наименьших привилегий и управлением

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

Прежде всего необходимо строго придерживаться принципа наименьших привилегий. Не назначайте широкие роли Contributor и избыточные разрешения Microsoft Graph идентификатору рабочей нагрузки только ради того, чтобы быстро заставить всё работать. Если фоновому скрипту автоматизации нужно лишь считывать элементы из одного конкретного контейнера Azure Storage, выдайте ему роль Storage Blob Data Reader только для этого контейнера — и ничего больше. Если такой идентификатор рабочей нагрузки когда-либо будет скомпрометирован, радиус поражения останется минимальным.

Во-вторых, нужно постоянно отслеживать и проверять идентификаторы рабочих нагрузок. Организации часто создают субъекты-службы и управляемые идентификаторы для проектов proof of concept, скриптов автоматизации и временных интеграций, а затем оставляют их работать бессрочно с высокими привилегиями. Регулярно проводите проверки безопасности, чтобы находить осиротевшие субъекты-службы, неиспользуемые учётные записи автоматизации и устаревшие учётные данные. Использование таких возможностей, как Microsoft Entra ID Protection, и настройка надёжного логирования через Azure Monitor обеспечивают полную видимость того, когда и как идентификаторы рабочих нагрузок обращаются к вашей среде.

Выбор правильной стратегии идентификации для каждой облачной рабочей нагрузки

В экосистеме идентификации Microsoft доступно так много вариантов. Как выбрать подходящую стратегию аутентификации для конкретной рабочей нагрузки? Решение обычно зависит от того, где работает ваше приложение и как оно устроено.

Если ваш код работает внутри Microsoft Azure — будь то Azure App Services, Azure Functions, Virtual Machines, Container Instances или Azure Kubernetes Service, — выбирайте в первую очередь управляемое удостоверение. Можно использовать управляемое удостоверение, назначаемое системой (его жизненный цикл на 1:1 привязан к ресурсу Azure) или управляемое удостоверение, назначаемое пользователем (его можно создать отдельно и назначить сразу нескольким ресурсам Azure, что упрощает управление).

Если ваше приложение работает за пределами Azure — например, на локальных серверах, в AWS или в составе конвейера CI/CD в GitHub Actions, — управляемые удостоверения, которые предоставляет инфраструктура Azure, использовать нельзя. В таких сценариях применяйте федерацию удостоверений рабочих нагрузок. Она позволяет внешним платформам напрямую обмениваться токенами с Microsoft Entra ID по доверию OpenID Connect (OIDC) и полностью исключает необходимость создавать, ротировать и хранить долгоживущие секреты клиента.

Наконец, для традиционных корпоративных приложений на заказ, которым требуется аутентификация клиента, когда ни управляемые идентификаторы, ни федерация неприменимы, сертификаты, управляемые должным образом, всегда должны иметь приоритет над долгоживущими клиентскими секретами. Сочетая Microsoft Entra Workload Identities, Azure Key Vault, принципы Zero Trust и доступ по принципу наименьших привилегий, ваша организация может полностью искоренить жёстко заданные пароли и построить на удивление устойчивую облачную архитектуру.

Итоги и следующие шаги для современной облачной безопасности

Жёстко заданные пароли и статические строки подключения — реликты устаревшей эры в ИТ-безопасности. Благодаря Microsoft Entra Workload Identities и управляемым идентификаторам Azure мы можем полностью устранить риски, связанные с встроенными учётными данными, защитить репозитории исходного кода от случайной утечки и обеспечить строгий доступ по принципу наименьших привилегий во всех облачно-нативных приложениях. Короткоживущие токены доступа гарантируют, что даже если токен будет перехвачен, срок его действия слишком мал, чтобы нанести серьёзный ущерб, и это фундаментально переводит нашу позицию в безопасности от реактивной защиты к проактивной.

Чтобы глубже разобраться в теме и услышать практические советы из первых рук, обязательно послушайте связанный выпуск подкаста: Entra Workload Identities - Simply Explained. Мы подробно разберём эти концепции, чтобы помочь вам защитить среды Azure и Microsoft 365 как профессионал!