Рекомендации по наилучшей практике управляемой идентификации
Управляемые удостоверения в Azure предоставляют безопасный и удобный способ управления учетными данными для приложений, работающих в ресурсах Azure. В этой статье описаны рекомендации по наилучшей практике выбора между управляемыми удостоверениями, назначаемыми пользователем, и теми, которые назначаются системой. Это поможет вам оптимизировать управление удостоверениями и сократить административные затраты.
Выбор управляемых удостоверений, назначенных системой или пользователем
Управляемые удостоверения, назначенные пользователем, эффективны в более широком спектре сценариев, чем управляемые удостоверения, назначенные системой. В следующей таблице приведены некоторые сценарии и рекомендации по назначению пользователем или системой.
Идентификаторы, назначаемые пользователем, могут использоваться несколькими ресурсами, и их жизненные циклы независимы от жизненных циклов ресурсов, с которыми они связаны. Сведения о ресурсах, которые поддерживаются управляемыми удостоверениями см. в этой статье.
Этот жизненный цикл позволяет распределить ответственность за создание ресурса и управление удостоверением. Удостоверения, назначенные пользователем, и назначение их ролей можно настроить заранее, до появления ресурсов, которым они требуются. Пользователям, создающим ресурсы, требуется доступ только для назначения пользовательских удостоверений, без необходимости создавать новые удостоверения или назначения ролей.
Поскольку удостоверения, назначенные системой, создаются и удаляются одновременно с ресурсом, назначение ролей не может быть выполнено заранее. Эта последовательность может вызвать сбои при развертывании инфраструктуры, если пользователь, создающий ресурс, не имеет доступа для создания назначений ролей.
Если в вашей инфраструктуре необходимо, чтобы несколько ресурсов имели доступ к одним и тем же ресурсам, им можно назначить один назначенный пользователем идентификатор. Затраты на администрирование сокращаются, так как управлять необходимо меньшим числом отдельных учетных записей и назначений ролей.
Если требуется, чтобы каждый ресурс имел собственное удостоверение, или у вас есть ресурсы, для которых требуется уникальный набор разрешений, и необходимо, чтобы удостоверение удалялось вместе с ресурсом, следует использовать удостоверение, назначенное системой.
| Сценарий | Рекомендация | Примечания. |
|---|---|---|
| Быстрое создание ресурсов (например, эфемерные вычисления) с помощью управляемых удостоверений | Назначаемая пользователем идентичность | Если вы пытаетесь создать несколько управляемых удостоверений в короткий промежуток времени, например, развертывая несколько виртуальных машин, каждая с собственным системным удостоверением, может быть превышено ограничение скорости для создания объектов Microsoft Entra, и запрос завершится ошибкой HTTP 429. Если ресурсы создаются или удаляются быстро, вы можете превысить ограничение на количество ресурсов в Microsoft Entra ID, если используются удостоверения с системным назначением. Хотя удаленное удостоверение системы больше не доступно никаким ресурсом, оно учитывается в вашем лимите до полной очистки через 30 дней. При развертывании ресурсов, связанных с пользовательской назначенной идентичностью, требуется создание только одного субъекта-службы (Service Principal) в Microsoft Entra ID, что позволяет избежать ограничения лимита скорости запросов. При использовании одного удостоверения, созданного заранее, снижается риск задержек репликации, которые могут возникнуть при создании нескольких ресурсов с собственным удостоверением. Дополнительные сведения см. в разделе Ограничения службы для подписки Azure. |
| Реплицированные ресурсы и приложения | Назначаемое пользователем удостоверение | Для ресурсов, выполняющих одну и ту же задачу, например повторяющиеся веб-сервера или одинаковые функции, выполняемые в службе приложений и в приложении на виртуальной машине, обычно необходимы одинаковые разрешения. При использовании одной и той же идентичности, назначенной пользователем, требуется меньше назначений ролей, что снижает затраты на управление. Ресурсы не должны быть одного типа. |
| Соответствие нормативным требованиям | Назначаемое пользователем удостоверение | Если в вашей организации требуется, чтобы все создание удостоверений проходило через процесс утверждения, использование одного удостоверения, назначаемого пользователем, для нескольких ресурсов требует меньше утверждений, чем удостоверения, назначаемые системой, которые создаются при создании новых ресурсов. |
| Требуется получить доступ перед развертыванием ресурса | Удостоверение, назначаемое пользователем | Для некоторых ресурсов в рамках развертывания может потребоваться доступ к определенным ресурсам Azure. В этом случае удостоверение, назначаемое системой, не может быть создано вовремя, поэтому необходимо использовать предварительно назначаемое пользователем удостоверение. |
| Ведение журнала аудита | Назначаемый системой идентификатор | Если вам нужно регистрировать, какой конкретный ресурс выполнил действие, а не какое удостоверение, используйте системно назначенное удостоверение. |
| Управление жизненным циклом разрешений | Назначаемое системой удостоверение | Если разрешения для ресурса необходимо удалить вместе с ресурсом, используйте удостоверение, назначенное системой. |
Использование назначенных пользователем идентификаторов для сокращения административной нагрузки.
На диаграммах показано различие между системными и пользовательскими идентификациями, используемыми для того, чтобы позволить нескольким виртуальным машинам получить доступ к двум учетным записям хранения.
На схеме показаны четыре виртуальные машины с идентичностями, назначенными системой. Каждая виртуальная машина имеет те же назначения ролей, которые предоставляют им доступ к двум учетным записям хранения.
Если с четырьмя виртуальными машинами связано назначенное пользователем удостоверение, требуется только два назначения ролей, а если удостоверение назначено системой, требуется восемь назначений ролей. Если для идентификатора виртуальных машин требуется больше назначений ролей, они предоставляются всем ресурсам, связанным с этой идентичностью.
Для уменьшения необходимого количества назначений ролей можно также использовать группы безопасности. На этой схеме показаны четыре виртуальных машины с удостоверениями, назначенными системой, которые были добавлены в группу безопасности, при этом назначения ролей добавлены в группу вместо удостоверений, назначенных системой. Хотя результат аналогичен, эта конфигурация не предоставляет те же возможности шаблона Resource Manager, что и удостоверения, назначенные пользователем.
Несколько управляемых удостоверений
Ресурсы, поддерживающие управляемые удостоверения, могут иметь как удостоверение, назначенное системой, так и одно или несколько удостоверений, назначенных пользователем.
Эта модель позволяет использовать общее удостоверение, назначенное пользователем, и при необходимости применять детализированные разрешения.
В следующем примере "Виртуальная машина 3" и "Виртуальная машина 4" могут получить доступ как к учетным записям хранения, так и к хранилищам ключей, в зависимости от того, какое удостоверение, назначаемое пользователем, используется при проверке подлинности.
В следующем примере "Виртуальная машина 4" имеет удостоверение, назначаемое пользователем, предоставляя ему доступ как к учетным записям хранения, так и к хранилищам ключей, в зависимости от того, какое удостоверение используется при проверке подлинности. Назначения ролей для системного удостоверения специфичны для этой виртуальной машины.
Ограничения
Просмотрите сведения об ограничениях для управляемых удостоверений, а также для настраиваемых ролей и назначений ролей.
При предоставлении доступа следуйте принципу минимальных привилегий.
При предоставлении любому удостоверению, включая управляемое удостоверение, разрешений на доступ к службам всегда назначайте минимальные разрешения, необходимые для выполнения предполагаемых действий. Например, если управляемое удостоверение используется для чтения данных из учетной записи хранения, не нужно предоставлять этому удостоверению права на запись данных в учетную запись хранения. Предоставление избыточных разрешений, например, назначение управляемой идентичности в качестве участника в подписке Azure, когда это не требуется, увеличивает потенциальные последствия для безопасности, связанные с данной идентичностью. Следует всегда сокращать радиус воздействия угрозы безопасности, чтобы взлом учетных данных вызывал как можно меньший ущерб.
Рассмотрим эффект назначения управляемых удостоверений ресурсам Azure и (или) предоставления разрешений пользователю
Важно отметить, что когда ресурсу Azure, например, логическому приложению Azure или виртуальной машине, назначается управляемое удостоверение, все разрешения, предоставленные управляемому удостоверению, становятся доступны этому ресурсу Azure. Это важно, поскольку если пользователь имеет доступ к установке или выполнению кода в этом ресурсе, то у него есть доступ ко всем удостоверениям, назначенным или связанным с ресурсом Azure. Целью управляемого удостоверения является предоставление коду, выполняемому в ресурсе Azure, доступа к другим ресурсам без необходимости обрабатывать или помещать учетные данные непосредственно в код для получения этого доступа.
Например, если управляемое удостоверение (ClientId = 1234) предоставляется полный доступ (чтение и запись) к StorageAccount7755 и назначается LogicApp3388, то Алиса, не имеющая прямого доступа к хранилищу StorageAccount7755, но имеющая разрешение на выполнение процессов в LogicApp3388, также может считывать и записывать данные из StorageAccount7755 путем выполнения кода, использующего управляемое удостоверение.
Аналогичным образом, если Алиса имеет разрешения на назначение управляемого удостоверения самостоятельно, она может назначить его другому ресурсу 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 Role Based Access Control (Azure RBAC) реализация использует маркеры доступа, выданные Microsoft Entra ID для аутентификации каждого удостоверения. Если удостоверение добавляется в группу или роль, это выражается в виде заявлений в токене доступа, выданном Microsoft Entra ID. Azure RBAC использует эти утверждения для дальнейшего анализа правил авторизации для разрешения или запрета доступа.
Учитывая, что группы и роли удостоверения являются утверждениями в токене доступа, любые изменения авторизации не вступают в силу до его обновления. Для реального пользователя это не является проблемой, так как он может получить новый маркер доступа, выйдя из системы и снова войдя в нее (или дождаться истечения срока действия маркера, по умолчанию — 1 час). Однако маркеры управляемых удостоверений кэшируются базовой инфраструктурой Azure для обеспечения производительности и устойчивости. Внутренние службы управляемых удостоверений хранят кэш для каждого URI ресурса в течение около 24 часов. Это означает, что для вступления в силу изменений в членстве управляемого удостоверения в группе или роли может потребоваться несколько часов. Сегодня невозможно обновить токен управляемого удостоверения в принудительном порядке до истечения срока его действия. Если вы изменяете членство в группе или роли управляемого удостоверения для добавления или удаления разрешений, вам может потребоваться несколько часов, пока ресурс Azure, использующий удостоверение, получит правильный доступ.
Если эта задержка неприемлема для ваших требований, рассмотрите варианты отказа от использования групп или ролей в токене. Чтобы изменения разрешений для управляемых удостоверений вступили в силу быстро, рекомендуется группировать ресурсы Azure с управляемым удостоверением, назначаемым пользователем, которому разрешения применяются непосредственно, вместо добавления или удаления управляемых удостоверений из группы Microsoft Entra, имеющей разрешения. Назначаемое пользователем управляемое удостоверение может использоваться как группа, так как оно может быть назначено одному или нескольким ресурсам Azure для использования. Операцией назначения можно управлять с помощью ролей участника управляемого удостоверения и оператора управляемого удостоверения.