Общие сведения о поставщиках удостоверений для 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 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.com, URL-адрес для входа на пользовательский портал будет следующим: 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 идентификатора или 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 для установления удостоверений. Так как Microsoft Entra id и AD FS используют протоколы согласованно, вы можете использовать библиотеку проверки подлинности Майкрософт (MSAL) для получения маркера безопасности для проверки подлинности в локальной среде или в Azure (в сценарии с подключением). С помощью MSAL можно также использовать такие средства, как Azure PowerShell и Azure CLI, для управления ресурсами в нескольких облаках и локальной среде.

Удостоверения и система идентификации

К удостоверениям для Azure Stack Hub относятся учетные записи пользователей, группы и субъекты-службы.

При установке Azure Stack Hub несколько встроенных приложений и служб автоматически регистрируются в поставщике удостоверений в клиенте каталога. Некоторые регистрируемые службы используются для администрирования. Другие службы доступны для пользователей. При стандартной регистрации основные службы получают удостоверения, которые могут взаимодействовать между собой и с удостоверениями, которые будут добавлены позже.

Если вы настроили идентификатор Microsoft Entra с мультитенантностью, некоторые приложения распространяются на новые каталоги.

Аутентификация и авторизация

Проверка подлинности, выполняемая приложениями и пользователями

Удостоверения между слоями Azure Stack Hub

Для приложений и пользователей архитектура Azure Stack Hub описывается с помощью четырех слоев. При взаимодействии между каждым из этих слоев могут использоваться разные типы проверки подлинности.

Уровень Проверка подлинности между слоями
Средства и клиенты, например портал администрирования Чтобы получить доступ к ресурсу в Azure Stack Hub или изменить его, средства и клиенты используют веб-токен JSON для вызова azure Resource Manager.
Azure Resource Manager проверяет веб-маркер JSON и просматривает утверждения в выданном маркере, чтобы оценить уровень авторизации пользователя или субъекта-службы в 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, необходимо иметь следующие сведения:

  1. URL-адрес для системы идентификации (центр). URL-адрес, по которому можно связаться с поставщиком удостоверений. Например, https://login.windows.net.
  2. URI идентификатора приложения для Azure Resource Manager: уникальный идентификатор для Azure Resource Manager, который регистрируется у вашего поставщика удостоверений. Он уникален для каждой установки Azure Stack Hub.
  3. Учетные данные. Учетные данные, которые вы используете для выполнения проверки подлинности с помощью поставщика удостоверений.
  4. 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) и групп для создания списка ресурсов, к которым субъект может получить доступ.

Схема протокола обмена маркерами

Примечание

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

Использование контроля доступа на основе ролей

Управление доступом на основе ролей (RBAC) в Azure Stack Hub реализовано так же, как и в Microsoft Azure. Вы можете управлять доступом к ресурсам путем назначения соответствующей роли RBAC пользователям, группам и приложениям. Для получения дополнительных сведений об использовании RBAC в 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.

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

Дальнейшие действия