Рекомендации по управляемых удостоверениях
Управляемые удостоверения для ресурсов Azure — это функция идентификатора Microsoft Entra. Каждая служба Azure, которая поддерживает управляемые удостоверения для ресурсов Azure, используется в соответствии с собственной временной шкалой. Прежде чем начать работу, обязательно проверьте состояние доступности управляемых удостоверений для своего ресурса и ознакомьтесь с известными проблемами.
Выбор управляемых удостоверений, назначенных пользователем или системой
Управляемые удостоверения, назначенные пользователем, эффективны в более широком спектре сценариев, чем управляемые удостоверения, назначенные системой. В таблице ниже приведены некоторые сценарии и рекомендации для управляемых удостоверений, назначенных пользователем или системой.
Удостоверения, назначенные пользователем, могут использоваться несколькими ресурсами, а их жизненные циклы отделены от жизненных циклов ресурсов, с которыми они связаны. Сведения о ресурсах, которые поддерживаются управляемыми удостоверениями см. в этой статье.
Этот жизненный цикл позволяет распределить ответственность за создание ресурса и управление удостоверением. Удостоверения, назначенные пользователем, и их назначения ролей можно настроить раньше ресурсов, которым они требуются. Пользователям, создающим ресурсы, требуется доступ только для назначения удостоверений. Им не нужно создавать удостоверения или назначения ролей.
При создании и удалении удостоверений, назначенных системой, вместе с ресурсом назначения ролей не могут быть созданы заранее. Эта последовательность может вызвать сбои при развертывании инфраструктуры, если пользователь, создающий ресурс, не имеет доступа для создания назначений ролей.
Если для инфраструктуры требуется, чтобы нескольким ресурсам требовался доступ к тем же ресурсам, им можно назначить одно назначенное пользователем удостоверение. Административные затраты будут сокращены, так как требуется управлять меньшим количеством определенных удостоверений и назначений ролей.
Если требуется, чтобы каждый ресурс имел собственное удостоверение, или у вас есть ресурсы, для которых требуется уникальный набор разрешений, и необходимо, чтобы удостоверение удалялось вместе с ресурсом, следует использовать удостоверение, назначенное системой.
| Сценарий | Рекомендация | Примечания. |
|---|---|---|
| Быстрое создание ресурсов (например, временных вычислений) с помощью управляемых удостоверений | Назначаемое пользователем удостоверение | Если вы пытаетесь создать несколько управляемых удостоверений в короткий промежуток времени , например, развертывание нескольких виртуальных машин с собственным удостоверением, назначаемым системой, может быть превышено ограничение скорости для создания объектов Microsoft Entra, и запрос завершится ошибкой HTTP 429. Если ресурсы создаются или удаляются быстро, можно также превысить ограничение на количество ресурсов в идентификаторе Microsoft Entra, если используются удостоверения, назначенные системой. Хотя удаленное удостоверение, назначенное системой, больше не доступно ни для одного из ресурсов, оно будет учитываться в вашем лимите, пока не будет очищено через 30 дней. При развертывании ресурсов, связанных с одним удостоверением, назначенным пользователем, потребуется создать только одного субъекта-службы в идентификаторе Microsoft Entra ID, избегая ограничения скорости. Использование одного созданного ранее удостоверения также снизит риск задержек репликации, которые могут произойти, если несколько ресурсов создаются с собственными удостоверениями. Дополнительные сведения см. в разделе Ограничения службы для подписки Azure. |
| Реплицированные ресурсы и приложения | Назначаемое пользователем удостоверение | Для ресурсов, выполняющих одну и ту же задачу, например повторяющиеся веб-сервера или одинаковые функции, выполняемые в службе приложений и в приложении на виртуальной машине, обычно необходимы одинаковые разрешения. При использовании одного и того же удостоверения, назначенного пользователем, требуется меньшее количество назначений ролей. Это снижает расходы на управление. Ресурсы не должны быть одного типа. |
| Соблюдение закона | Назначаемое пользователем удостоверение | Если для вашей организации требуется, чтобы при создании все удостоверения проходили процесс утверждения, при использовании одного удостоверения, назначенного пользователем, в нескольких ресурсах потребуется меньше утверждений, чем при использовании удостоверений, назначенных системой, которые создаются вместе с ресурсами. |
| Требуется получить доступ перед развертыванием ресурса | Назначаемое пользователем удостоверение | Для некоторых ресурсов в рамках развертывания может потребоваться доступ к определенным ресурсам Azure. В этом случае удостоверение, назначенное системой, может не быть создано вовремя, поэтому следует использовать уже имеющееся удостоверение, назначенное пользователем. |
| Ведение журнала аудита | Назначаемое системой удостоверение | Если вам нужно регистрировать, какой конкретный ресурс (а не удостоверение) выполнил действие, используйте удостоверение, назначенное системой. |
| Управление жизненным циклом разрешений | Назначаемое системой удостоверение | Если разрешения для ресурса необходимо удалить вместе с ресурсом, используйте удостоверение, назначенное системой. |
Использование удостоверений, назначенных пользователем для сокращения расходов на администрирование
На диаграммах показано различие между удостоверениями, назначенными системой и пользователем, которые используются для предоставления нескольким виртуальным машинам доступа к двум учетным записям хранения.
На схеме показаны четыре виртуальные машины с удостоверениями, назначенными системой. Каждая виртуальная машина имеет те же назначения ролей, которые предоставляют им доступ к двум учетным записям хранения.
Если с четырьмя виртуальными машинами связано назначенное пользователем удостоверение, требуется только два назначения ролей, а если удостоверение назначено системой, требуется восемь назначений ролей. Если для идентификатора виртуальных машин требуется больше назначений ролей, они будут предоставлены всем ресурсам, которые с ним связаны.
Для уменьшения необходимого количества назначений ролей можно также использовать группы безопасности. На этой схеме показаны четыре виртуальные машины с удостоверениями, назначенными системой, которые были добавлены в группу безопасности с назначениями ролей, а не удостоверениями, назначенными системой. Хотя результат аналогичен, эта конфигурация не предоставляет те же возможности шаблона Resource Manager, что и удостоверения, назначенные пользователем.
Несколько управляемых удостоверений
Ресурсы, поддерживающие управляемые удостоверения, могут иметь как удостоверение, назначенное системой, так и одно или несколько удостоверений, назначенных пользователем.
Эта модель позволяет использовать общее удостоверение, назначенное пользователем, и при необходимости применять детализированные разрешения.
В приведенном ниже примере "Виртуальная машина 3" и "Виртуальная машина 4" могут получить доступ как к учетным записям хранения, так и к хранилищам ключей, в зависимости от назначенного пользователем удостоверения, используемого при проверке подлинности.
В приведенном ниже примере "Виртуальная машина 4" имеет удостоверение, назначенное пользователем, которое предоставляет ей доступ к учетным записям хранения и хранилищам ключей, в зависимости от удостоверения, используемого при проверке подлинности. Назначения ролей для удостоверения, назначенного системой, относятся к этой виртуальной машине.
Ограничения
Просмотрите сведения об ограничениях для управляемых удостоверений, а также для настраиваемых ролей и назначений ролей.
При предоставлении доступа следуйте принципу минимальных привилегий.
При предоставлении любому удостоверению, включая управляемое удостоверение, разрешений на доступ к службам всегда назначайте минимальные разрешения, необходимые для выполнения предполагаемых действий. Например, если управляемое удостоверение используется для чтения данных из учетной записи хранения, нет необходимости разрешать этому удостоверению записывать данные в учетную запись хранения. Предоставление чрезмерных разрешений, например, на создание управляемого удостоверения для участника в подписке Azure, если это не требуется, увеличивает радиус нарушения безопасности, связанного с этим удостоверением. Следует всегда сокращать радиус нарушения безопасности, чтобы компрометация удостоверения вызывала минимальный ущерб.
Рассмотрим эффект назначения управляемых удостоверений ресурсам Azure и (или) предоставления разрешений пользователю
Важно отметить, что когда ресурсу Azure, например приложению логики Azure, функции Azure, виртуальной машине и т. д., назначается управляемое удостоверение, все разрешения, предоставленные этому управляемому удостоверению, становятся доступны ресурсу Azure. Это важно, поскольку если пользователь имеет доступ к установке или выполнению кода в этом ресурсе, то у него есть доступ ко всем удостоверениям, назначенным или связанным с ресурсом Azure. Целью управляемого удостоверения является предоставление коду, выполняемому в ресурсе Azure, доступа к другим ресурсам без необходимости обрабатывать или помещать учетные данные непосредственно в код для получения этого доступа.
Например, если управляемое удостоверение (ClientId = 1234) было предоставлено доступ на чтение и запись к служба хранилища Account7755 и было назначено LogicApp3388, то Алиса, которая не имеет прямого доступа к учетной записи хранения, но имеет разрешение на выполнение кода в LogicApp33388 также может считывать и записывать данные в служба хранилища Account7755 выполнив код, использующий управляемое удостоверение.
Аналогичным образом, если Алиса имеет разрешения на назначение управляемого удостоверения самостоятельно, она может назначить его другому ресурсу Azure и получить доступ ко всем разрешениям, доступным управляемому удостоверению.
В общем случае при предоставлении пользователю административного доступа к ресурсу, который может выполнять код (например, приложение логики) и имеет управляемое удостоверение, следует подумать, позволяет ли роль, назначенная пользователю, установить или запустить код в ресурсе. Если это так, то назначайте данную роль только в том случае, если пользователь действительно нуждается в ней.
Обслуживание
Удостоверения, назначенные системой, автоматически удаляются при удалении ресурса, в то время как жизненный цикл удостоверения, назначенного пользователем, не зависит от ресурсов, с которыми он связан.
Необходимо вручную удалить удостоверение, назначаемое пользователем, если оно больше не требуется (даже если с ним не связано ни одного ресурса).
Назначения ролей не удаляются автоматически при удалении управляемых удостоверений, назначаемых системой или пользователем. Эти назначения ролей следует удалять вручную, чтобы не превышать ограничение назначений ролей на подписку.
При просмотре на портале назначения роли, связанные с удаленными управляемыми удостоверениями, будут отображаться с сообщением "Удостоверение не найдено". Дополнительные сведения
Назначения ролей, которые больше не связаны с пользователем или субъектом-службой будут отображаться со ObjectType значением Unknown. Чтобы удалить их, можно передать сразу несколько команд Azure PowerShell, чтобы сначала получить все назначения ролей, отфильтровать только те из них, которые имеют ObjectType значение Unknown, а затем удалить эти назначения ролей из Azure.
Get-AzRoleAssignment | Where-Object {$_.ObjectType -eq "Unknown"} | Remove-AzRoleAssignment
Ограничение использования управляемых удостоверений для авторизации
Использование групп идентификаторов Microsoft Entra для предоставления доступа к службам — отличный способ упростить процесс авторизации. Идея проста — предоставьте разрешения группе и добавьте в нее удостоверения, чтобы они наследовали те же разрешения. Это хорошо зарекомендовавший себя шаблон в различных локальных системах, который хорошо работает, когда удостоверения представляют пользователей. Другим вариантом управления авторизацией в идентификаторе Microsoft Entra является использование ролей приложений, что позволяет объявлять роли , относящиеся к приложению (а не группы, которые являются глобальной концепцией в каталоге). Вы можете назначать роли управляемым удостоверениям, а также пользователям и группам.
В обоих случаях для нечеловеческих удостоверений, таких как приложения Microsoft Entra и управляемые удостоверения, точный механизм представления этой информации авторизации приложению не идеально подходит сегодня. Сегодня реализация с идентификатором Microsoft Entra ID и контроль доступа на основе ролей Azure (Azure RBAC) использует маркеры доступа, выданные Идентификатором Microsoft Entra для проверки подлинности каждого удостоверения. Если удостоверение добавляется в группу или роль, это выражается как утверждения в маркере доступа, выданном идентификатором Microsoft Entra. Azure RBAC использует эти утверждения для дальнейшего анализа правил авторизации для разрешения или запрета доступа.
С учетом того, что группы и роли удостоверения представлены в виде утверждений в маркере доступа, любые изменения авторизации вступают в силу только после обновления маркера. Для реального пользователя это не является проблемой, так как он может получить новый маркер доступа, выйдя из системы и снова войдя в нее (или дождаться истечения срока действия маркера, по умолчанию — 1 час). Однако маркеры управляемых удостоверений кэшируются базовой инфраструктурой Azure для обеспечения производительности и устойчивости. Внутренние службы управляемых удостоверений хранят кэш для каждого URI ресурса в течение около 24 часов. Это означает, что может пройти несколько часов, прежде чем изменения членства в группе или роли управляемого удостоверения вступят в силу. Сейчас невозможно принудительно обновить маркер управляемого удостоверения до истечения его срока действия. Если вы изменяете членство в группе или роли управляемого удостоверения для добавления или удаления разрешений, вам может потребоваться несколько часов, пока ресурс Azure, использующий удостоверение, получит правильный доступ.
Если в соответствии с вашими требованиями такая задержка недопустима, рассмотрите альтернативы использованию групп или ролей в маркере. Чтобы изменения разрешений для управляемых удостоверений вступили в силу быстро, рекомендуется группировать ресурсы Azure с помощью управляемого удостоверения, назначаемого пользователем, с разрешениями, применяемыми непосредственно к удостоверению , вместо добавления или удаления управляемых удостоверений из группы Microsoft Entra, которая имеет разрешения. Назначаемое пользователем управляемое удостоверение может использоваться как группа, так как оно может быть назначено одному или нескольким ресурсам Azure для использования. Операцией назначения можно управлять с помощью ролей участника управляемого удостоверения и оператора управляемого удостоверения.