Общие сведения о поставщиках удостоверений для Azure Stack Hub
Для Azure Stack Hub требуется идентификатор Microsoft Entra или службы федерации Active Directory (AD FS) (AD FS), поддерживаемый Active Directory в качестве поставщика удостоверений. Решение о выборе поставщика принимается один раз во время развертывания Azure Stack Hub. Основные понятия и сведения об авторизации из этой статьи могут помочь вам выбрать поставщика удостоверений.
Выбор идентификатора Microsoft Entra или AD FS определяется режимом развертывания Azure Stack Hub:
- При развертывании в подключенном режиме можно использовать идентификатор Microsoft Entra или AD FS.
- Если вы выполнили развертывание в отключенном режиме без подключения к Интернету, поддерживается только AD FS.
В зависимости от среды Azure Stack Hub изучите дополнительные сведения о доступных вариантах в следующих статьях:
- Пакет средств разработки Azure Stack Hub: рекомендации по идентификации.
- Интегрированные системы Azure Stack Hub: решения по планированию развертывания для интегрированных систем Azure Stack Hub.
Внимание
Azure AD Graph устарел и будет прекращен 30 июня 2023 г. Дополнительные сведения см. в этом разделе.
Общие понятия о поставщиках удостоверений
В следующих разделах рассматриваются основные понятия, связанные с поставщиками удостоверений, и сведения об их использовании в Azure Stack Hub.
Организации и клиенты каталога
Каталог — это контейнер, который содержит информацию о пользователях, приложениях, группах и субъектах-служб.
Клиент каталога — это организация, например, корпорация Майкрософт или ваша компания.
- Microsoft Entra ID поддерживает нескольких клиентов и может поддерживать несколько организаций (каждую в собственном каталоге). Если вы используете идентификатор Microsoft Entra и имеете несколько клиентов, вы можете предоставить приложения и пользователи из одного клиента доступ к другим клиентам этого же каталога.
- AD FS поддерживает только один клиент, и, следовательно, только одну организацию.
Пользователи и группы
Учетные записи пользователей (удостоверения) — это стандартные учетные записи, выполняющие проверку подлинности отдельных пользователей с помощью идентификатора и пароля пользователя. Группы могут содержать пользователей или другие группы.
Способ создания пользователей и групп и управление ими зависит от используемого вами решения для идентификации.
В Azure Stack Hub учетные записи пользователей имеют следующие свойства.
- Создаются в формате username@domain . Хотя AD FS сопоставляет учетные записи пользователей с экземпляром Active Directory, AD FS не поддерживает использование формата \<domain>\<alias> .
- Настраиваются для использования многофакторной проверки подлинности.
- Ограничены каталогом, в котором они были впервые зарегистрированы. Это каталог организации.
- Их можно импортировать из локальных каталогов. Дополнительные сведения см. в разделе "Интеграция локальных каталогов с идентификатором Microsoft Entra".
При входе на портал пользователей вашей организации вы используете URL-адрес https://portal.local.azurestack.external. При входе на портал Azure Stack Hub из других доменов, кроме указанного при регистрации Azure Stack Hub, необходимо добавить к URL-адресу портала имя домена, которое использовалось для регистрации Azure Stack Hub. Например, если Azure Stack Hub зарегистрирован в fabrikam.onmicrosoft.com, а вход учетной записи пользователя — это admin@contoso.comURL-адрес, используемый для входа на пользовательский портал: https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.
Гостевые пользователи
Гостевые пользователи — это учетные записи пользователей из других клиентов каталога, которым предоставили доступ к ресурсам в вашем каталоге. Для поддержки гостевых пользователей используйте идентификатор Microsoft Entra и включите поддержку мультитенантности. Если поддержка включена, вы можете предоставить гостевому пользователю доступ к ресурсам в вашем клиенте каталога. Это в свою очередь позволяет активировать совместную работу за пределами организации.
Чтобы пригласить гостевых пользователей, облачные операторы и пользователи могут использовать совместную работу Microsoft Entra B2B. Приглашенные пользователи получают доступ к документам, ресурсам и приложениям из вашего каталога, сохраняя при этом контроль над собственными ресурсами и данными.
В качестве гостевого пользователя вы можете войти в другой клиент каталога организации. Для этого добавьте имя каталога организации в URL-адрес портала. Например, если вы принадлежите организации Contoso и хотите войти в каталог Fabrikam, используйте его. https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.
Приложения
Вы можете зарегистрировать приложения в Microsoft Entra ID или AD FS, а затем предложить приложения пользователям в вашей организации.
В число приложений входят:
- Веб-приложения: это, например, портал Azure и Azure Resource Manager. Они поддерживают вызовы веб-API.
- Собственный клиент. В качестве примера можно привести Azure PowerShell, Visual Studio и Azure CLI.
Приложения могут поддерживать два типа клиентской модели:
Один арендатор: поддерживает пользователей и службы только из того же каталога, в котором зарегистрировано приложение.
Примечание.
Так как AD FS поддерживает только один каталог, приложения, созданные в топологии AD FS, являются по своей природе приложениями с одним клиентом.
Несколько арендаторов: поддерживает использование пользователями и службами из каталога, в котором зарегистрировано приложение, и других каталогов арендаторов. С помощью мультитенантных приложений пользователи другого каталога клиента (другой клиент Microsoft Entra) могут войти в приложение.
Дополнительные сведения о мультитенантности см. в статье Поддержка мультитенантности в Azure Stack.
Дополнительные сведения о разработке мультитенантного приложения см. в статье Как реализовать вход любого пользователя Azure Active Directory (AD) с помощью шаблона мультитенантного приложения.
При регистрации приложения создаются два объекта:
Объект приложения: глобальное представление приложения во всех арендаторах. С программным приложением устанавливается отношение "один к одному", которое существует только в каталоге, в котором оно было впервые зарегистрировано.
Объект субъекта службы: учетные данные, которые создаются для приложения в каталоге, в котором оно зарегистрировано впервые. Субъект-служба также создается в каталоге каждого дополнительного клиента, в которых используется это приложение. С программным приложением может устанавливаться отношение "один ко многим".
Дополнительные сведения об объектах приложения и субъекта-службы см. в разделе "Объекты приложения и субъекта-службы" в идентификаторе Microsoft Entra.
Субъекты-службы
Субъект-служба — это набор учетных данных для приложения или службы, которые предоставляют доступ к ресурсам в Azure Stack Hub. Использование субъекта-службы разделяет разрешения приложения от разрешений пользователя приложения.
Субъект-служба создается в каждом клиенте, в котором используется приложение. Она создает удостоверения для входа и доступа к ресурсам (например, пользователям), защищенных этим клиентом.
- Приложение с одним арендатором имеет только один субъект-службу в каталоге, в котором оно было впервые создано. Субъект-служба создается и дает согласие быть использованной во время регистрации приложения.
- Веб-приложение или API с несколькими арендаторами имеет субъект-службу, созданный в каждом арендаторе, в котором пользователь из такого арендатора предоставляет согласие на использование приложения.
В качестве учетных данных для субъектов-служб могут использоваться ключ, который был создан на портале Azure, или сертификат. Использование сертификата хорошо подходит для автоматизации, так как сертификаты считаются более безопасными, чем ключи.
Примечание.
При использовании AD FS с Azure Stack Hub только администраторы могут создавать субъекты-службы. При использовании AD FS для субъектов-служб требуются сертификаты. В таком случае субъекты-службы создаются с помощью привилегированной конечной точки. Инструкции см. в статье Использование удостоверения приложения для доступа к ресурсам.
Дополнительные сведения о субъектах-службах для Azure Stack Hub см. в этой статье.
Службы
Службы в Azure Stack Hub, которые взаимодействуют с поставщиками удостоверений, регистрируются как приложения с поставщиком удостоверений. Как и в случае с приложениями, регистрация позволяет службе выполнить проверку подлинности с помощью системы идентификации.
Все службы Azure используют протоколы OpenID Connect и JSON Web Tokens для идентификации. Так как идентификатор Microsoft Entra и AD FS последовательно используют протоколы, вы можете использовать библиотеку проверки подлинности Майкрософт (MSAL) для получения маркера безопасности для проверки подлинности локальной среды или Azure (в подключенном сценарии). С помощью MSAL можно также использовать такие средства, как Azure PowerShell и Azure CLI для межоблачного и локального управления ресурсами.
Удостоверения и система идентификации
К удостоверениям для Azure Stack Hub относятся учетные записи пользователей, группы и субъекты-службы.
При установке Azure Stack Hub несколько встроенных приложений и служб автоматически регистрируются в поставщике удостоверений в клиенте каталога. Некоторые регистрируемые службы используются для администрирования. Другие службы доступны для пользователей. При стандартной регистрации основные службы получают удостоверения, которые могут взаимодействовать между собой и с удостоверениями, которые будут добавлены позже.
Если вы настроили идентификатор Microsoft Entra с несколькими клиентами, некоторые приложения распространяются в новые каталоги.
Проверка подлинности и авторизация
Проверка подлинности, выполняемая приложениями и пользователями
Для приложений и пользователей архитектура Azure Stack Hub описывается с помощью четырех слоев. При взаимодействии между каждым из этих слоев могут использоваться разные типы проверки подлинности.
| Уровень | Проверка подлинности между слоями |
|---|---|
| Средства и клиенты, например портал администрирования | Чтобы использовать или изменять ресурсы в Azure Stack Hub, средства и клиенты указывают JSON Web Token при вызове Azure Resource Manager. Azure Resource Manager проверяет JSON Web Token и просматривает утверждения в выданном маркере, чтобы оценить уровень авторизации пользователя или субъекта-службы в Azure Stack Hub. |
| Платформа Azure Resource Manager и ее основные службы | Azure Resource Manager взаимодействует с поставщиками ресурсов для передачи данных от пользователей. Для передачи данных используются прямые императивные вызовы или декларативные вызовы через шаблоны Azure Resource Manager. |
| Поставщики ресурсов | Вызовы, передаваемые поставщикам удостоверений, защищены проверкой подлинности на основе сертификатов. Azure Resource Manager и поставщик удостоверений затем взаимодействуют с помощью API. Каждый вызов, полученный из Azure Resource Manager, поставщик удостоверений проверяет с помощью сертификата. |
| Инфраструктура и бизнес-логика | Поставщики ресурсов взаимодействуют с бизнес-логикой и инфраструктурой с помощью режима проверки подлинности на свой выбор. Стандартные поставщики удостоверений, которые поставляются с Azure Stack Hub, используют проверку подлинности Windows для защиты этой связи. |
Проверка подлинности в Azure Resource Manager
Чтобы выполнить проверку подлинности с помощью поставщика удостоверений и получить JSON Web Token, необходимо иметь следующие сведения:
- URL-адрес для системы идентификации (центр). URL-адрес, по которому можно связаться с поставщиком удостоверений. Например, https://login.windows.net.
- URI идентификатора приложения для Azure Resource Manager: уникальный идентификатор для Azure Resource Manager, который регистрируется у вашего поставщика удостоверений. Он уникален для каждой установки Azure Stack Hub.
- Учетные данные. Учетные данные, которые вы используете для выполнения проверки подлинности с помощью поставщика удостоверений.
- URL-адрес для Azure Resource Manager. URL-адрес — это расположение службы Azure Resource Manager. Например, https://management.azure.com или https://management.local.azurestack.external.
Когда субъект (клиент, приложение или пользователь) выполняет запрос на проверку подлинности для доступа к ресурсу, запрос должен содержать следующие данные:
- Учетные данные субъекта.
- URI идентификатора приложения для ресурса, к которому субъект хочет получить доступ.
Учетные данные проверяются поставщиком удостоверений. Поставщик удостоверений также проверяет, чтобы URI идентификатора приложения использовался для зарегистрированного приложения и чтобы субъект имел правильные разрешения для получения маркера для ресурса. Если запрос допустимый, предоставляется JSON Web Token.
Затем маркер передается в заголовке запроса к Azure Resource Manager. Azure Resource Manager в любом порядке выполняет следующее:
- Проверяет утверждение издателя, чтобы убедиться, что маркер получен из правильного поставщика удостоверений.
- Проверяет утверждение аудитории, чтобы убедиться, что маркер был выдан Azure Resource Manager.
- Проверяет, что JSON Web Token подписан с помощью сертификата, настроенного через OpenID, известного для Azure Resource Manager.
- Просматривает утверждения времени выдачи и окончания срока действия, чтобы убедиться, что маркер активный и может быть принят.
После выполнения всех проверок, Azure Resource Manager использует утверждения идентификатора объекта (oid) и групп для создания списка ресурсов, к которым субъект может получить доступ.
Использование контроля доступа на основе ролей
Управление доступом на основе ролей (RBAC) в Azure Stack Hub реализовано так же, как и в Microsoft Azure. Вы можете управлять доступом к ресурсам путем назначения соответствующей роли RBAC пользователям, группам и приложениям. Для получения дополнительных сведений об использовании RBAC в Azure Stack Hub ознакомьтесь со следующими статьями:
- Начало работы с управлением доступом на основе ролей на портале Azure.
- Использование управления доступом на основе ролей для контроля доступа к ресурсам в подписке Azure.
- Создание пользовательских ролей для управления доступом на основе ролей в Azure.
- Управление доступом на основе ролей в Azure Stack Hub.
Проверка подлинности с помощью Azure PowerShell
Сведения об использовании Azure PowerShell для проверки подлинности в Azure Stack Hub см. в статье Подключение к Azure Stack в роли пользователя с помощью PowerShell.
Проверка подлинности с помощью Azure CLI
Сведения об использовании Azure CLI для проверки подлинности в Azure Stack Hub см. в статье Развертывание и администрирование ресурсов в Azure Stack с помощью Azure CLI.
Политика Azure
Политика Azure обеспечивает применение стандартов организации и помогает оценивать их соблюдение. С помощью панели мониторинга соответствия она предоставляет агрегированное представление для оценки общего состояния среды с возможностью детализации до каждого ресурса, детализации на уровне политики. Также вы можете привести ресурсы в соответствие требованиям, используя средства пакетного исправления для существующих ресурсов и автоматического исправления для новых ресурсов.
Политика Azure широко применяется для реализации средств контроля за согласованностью ресурсов, соответствием нормативным требованиям, безопасностью, расходами и управлением. Определения политик для этих распространенных вариантов использования уже встроены в среду Azure, чтобы помочь вам приступить к работе.
Примечание.
Политика Azure в настоящее время не поддерживается в Azure Stack Hub.
Azure AD Graph
Microsoft Azure объявила о прекращении использования Azure AD Graph 30 июня 2020 г. и датой выхода на пенсию 30 июня 2023 г. Корпорация Майкрософт сообщила клиентам по электронной почте об этом изменении. Дополнительные сведения см. в блоге о прекращении использования Azure AD Graph и модуле PowerShell.
В следующем разделе описывается, как это нерекомендуется повлиять на Azure Stack Hub.
Команда Azure Stack Hub тесно сотрудничает с командой Azure Graph, чтобы гарантировать, что ваши системы продолжают работать после 30 июня 2023 г. при необходимости, чтобы обеспечить плавный переход. Наиболее важным действием является обеспечение соответствия политике обслуживания Azure Stack Hub. Клиенты получат оповещение на портале администрирования Azure Stack Hub и потребуются для обновления домашнего каталога и всех подключенных гостевых каталогов.
Большинство самой миграции будет выполнено интегрированным интерфейсом обновления системы; В каждом каталоге Microsoft Entra, используемом в средах Azure Stack Hub, будет выполняться ручной шаг, необходимый клиентам для предоставления новых разрешений для этих приложений. После завершения установки пакета обновления с этими изменениями на портале администрирования создается оповещение, на котором вы будете выполнять этот шаг с помощью многотенантного пользовательского интерфейса или скриптов PowerShell. Эта же операция выполняется при подключении дополнительных каталогов или поставщиков ресурсов; Дополнительные сведения см. в статье "Настройка нескольких клиентов" в Azure Stack Hub.
Если вы используете AD FS в качестве системы удостоверений с Azure Stack Hub, эти изменения Graph не повлияют непосредственно на систему. Однако для последних версий таких средств, как Azure CLI, Azure PowerShell и т. д., требуются новые API Graph, и они не будут работать. Убедитесь, что вы используете только версии этих средств, которые явно поддерживаются при заданной сборке Azure Stack Hub.
Помимо оповещения на портале администрирования, мы будем обмениваться изменениями с помощью заметок о выпуске обновления и сообщить, какой пакет обновления требует обновления домашнего каталога и всех подключенных гостевых каталогов.