Поделиться через

Общие сведения о поставщиках удостоверений для Azure Stack Hub

Для Azure Stack Hub требуется Microsoft Entra ID или службы федерации Active Directory (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 ID или AD FS, а затем предложить приложения пользователям в вашей организации.

В число приложений входят:

  • Веб-приложения: это, например, портал Azure и Azure Resource Manager. Они поддерживают вызовы веб-API.
  • Собственный клиент. В качестве примера можно привести Azure PowerShell, Visual Studio и Azure CLI.

Приложения могут поддерживать два типа аренды:

  • Модель одного арендатора: поддерживает пользователей и службы только из того же каталога, в котором зарегистрировано приложение.

    Примечание.

    Так как AD FS поддерживает только один каталог, приложения, созданные в топологии AD FS, являются по своей природе приложениями с одним клиентом.

  • Несколько арендаторов: поддерживает использование пользователями и службами из каталога, в котором зарегистрировано приложение, и других каталогов арендаторов. С помощью мультитенантных приложений пользователи другого каталога клиента (другой клиент Microsoft Entra) могут войти в приложение.

    Дополнительные сведения о мультитенантности см. в статье Поддержка мультитенантности в Azure Stack.

    Для получения более подробной информации о разработке мультитенантных приложений см. Мультитенантные приложения.

При регистрации приложения создаются два объекта:

  • Объект приложения: глобальное представление приложения во всех арендаторах. С программным приложением устанавливается отношение "один к одному", которое существует только в каталоге, в котором оно было впервые зарегистрировано.

  • Объект сервисного принципала: учетные данные, которые создаются для приложения в каталоге, где приложение впервые зарегистрировано. Учетная запись службы также создается в каталоге каждого дополнительного арендатора, где используется это приложение. С программным приложением может устанавливаться связь типа "один ко многим".

Дополнительные сведения об объектах приложения и субъекта-службы см. в разделе "Объекты приложения и субъекта-службы" в идентификаторе Microsoft Entra.

Субъекты-службы

Учетная запись службы — это набор учетных данных для приложения или службы, которые предоставляют доступ к ресурсам в Azure Stack Hub. Использование учетной записи службы отделяет разрешения, предоставленные приложению, от разрешений, предоставленных пользователю приложения.

Субъект-служба создается в каждом клиенте, в котором используется приложение. Служебный принципал создает учетные данные для аутентификации и доступа к ресурсам (например, пользователям), защищенных этим арендатором.

  • Приложение с одним арендатором имеет только один служебный принципал, который находится в каталоге, в котором оно было впервые создано. Субъект-служба создается и дает согласие быть использованной во время регистрации приложения.
  • Веб-приложение или API с несколькими арендаторами имеет служебный принципал, созданный в каждой среде арендатора, где пользователь этого арендатора соглашается на использование приложения.

В качестве учетных данных для субъектов-служб могут использоваться ключ, который был создан на портале Azure, или сертификат. Использование сертификата хорошо подходит для автоматизации, так как сертификаты считаются более безопасными, чем ключи.

Примечание.

При использовании AD FS с Azure Stack Hub только администраторы могут создавать субъекты-службы. При использовании AD FS субъектам-служб требуются сертификаты и они создаются через привилегированную конечную точку (PEP). Инструкции см. в статье Использование удостоверения приложения для доступа к ресурсам.

Подробнее о служебных принципалах для Azure Stack Hub см. в Создание служебных принципалов.

Службы

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

Все службы Azure используют протоколы OpenID Connect и JSON Web Tokens для идентификации. Так как Microsoft Entra ID и AD FS последовательно используют протоколы, вы можете использовать библиотеку аутентификации Microsoft (MSAL) для получения токена безопасности для аутентификации в локальной среде или в Azure (в подключенном сценарии). С помощью MSAL можно также использовать такие средства, как Azure PowerShell и Azure CLI для межоблачного и локального управления ресурсами.

Идентичность и ваша система идентификации

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

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

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

Проверка подлинности и авторизация

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

Идентичность между слоями Azure Stack Hub

Для приложений и пользователей архитектура 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, необходимо иметь следующие сведения:

  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 выполняет следующее в произвольном порядке:

  • Проверяет утверждение издателя (iss), чтобы убедиться, что токен получен от правильного поставщика удостоверений.
  • Проверяет утверждение аудитории, чтобы убедиться, что маркер был выдан Azure Resource Manager.
  • Проверяет, что JSON Web Token подписан с помощью сертификата, настроенного через OpenID, известного для Azure Resource Manager.
  • Проверьте утверждения времени выдачи (iat) и окончания срока действия (exp), чтобы убедиться, что токен активен и может быть принят.

После выполнения всех проверок, Azure Resource Manager использует утверждения идентификатора объекта (oid) и групп для создания списка ресурсов, к которым субъект может получить доступ.

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

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

Управление доступом на основе ролей (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.

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

Следующие шаги

  • Last updated on