Сценарий. Использование Microsoft Entra ID для защиты доступа к платформам и приложениям SAP

В этом документе приводятся рекомендации по техническая разработка и конфигурация платформ и приложений SAP при использовании Microsoft Entra ID в качестве основной службы проверки подлинности пользователей для служб SAP Cloud Identity Services. Облачные службы удостоверений SAP включают проверку подлинности, подготовку удостоверений, каталог удостоверений и управление авторизацией. Узнайте больше о начальной настройке проверки подлинности в интеграции единого входа Microsoft Entra с SAP Cloud Identity Services. Дополнительные сведения о подготовке и других сценариях см. в статье план развертывания Microsoft Entra для подготовки пользователей с помощью исходных и целевых приложений SAP и управляемого доступа к приложениям SAP.

Терминология, используемая в этом руководстве

Обзор

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

Так как существует множество вариантов возможных сценариев для настройки, мы сосредоточимся на одном сценарии, который соответствует стратегии идентификации в первую очередь в Microsoft Entra. Мы сделаем следующие предположения:

• Вы хотите централизованно управлять всеми удостоверениями только через Microsoft Entra ID.
• Вы хотите сократить усилия по обслуживанию как можно больше и автоматизировать проверку подлинности и доступ приложений между Корпорацией Майкрософт и SAP.
• Общие рекомендации по Microsoft Entra ID с IAS применяются для приложений, развернутых в приложениях BTP и SAP SaaS, настроенных в IAS. Также будут предоставлены конкретные рекомендации, применимые к BTP (например, использование сопоставлений ролей с группами Microsoft Entra) и приложений SaaS SAP (например, использование службы подготовки удостоверений для авторизации на основе ролей).
• Мы также предполагаем, что пользователи уже зарегистрированы в Microsoft Entra ID и в любых системах SAP, где требуется наличие пользователей для работы. Независимо от того, как это было достигнуто: предоставление могло осуществляться вручную, из локальной Active Directory через Microsoft Entra Connect или через системы управления персоналом, такие как SAP SuccessFactors. Поэтому в этом документе SuccessFactors считается приложением, как и любое другое, в которое будут входить (существующие) пользователи. Мы не рассматриваем непосредственное предоставление пользователей из SuccessFactors в Microsoft Entra ID. Дополнительные сведения о включении пользователей в Microsoft Entra ID для использования с рабочими нагрузками SAP см. в разделе планирование развертывания Microsoft Entra для подготовки пользователей с использованием исходных и целевых приложений SAP и управление доступом к приложениям SAP.

Основываясь на этих предположениях, мы главным образом сосредоточимся на продуктах и услугах, представленных на схеме ниже. Это различные компоненты, наиболее важные для проверки подлинности и авторизации в облачной среде.

Если вы использовали SAP Identity Management (IDM), можно перенести сценарии управления удостоверениями из SAP IDM в Microsoft Entra. Дополнительные сведения см. в статье Миграция сценариев управления удостоверениями из SAP IDM в Microsoft Entra.

Recommendations

Сводка

• 1. Использование федеративной проверки подлинности в SAP Business Technology Platform и приложениях SAP SaaS через службу проверки подлинности удостоверений SAP
• 2 — используйте Microsoft Entra ID для проверки подлинности и IAS/BTP для авторизации
• 3 — используйте группы Microsoft Entra для авторизации с помощью коллекций ролей в IAS/BTP
• 4. Используйте одну подучетную запись BTP только для приложений, имеющих аналогичные требования к идентификации.
• 5. Используйте производственное окружение IAS для всех пользователей при аутентификации и авторизации
• 6. Определение процесса для обновления сертификатов подписи SAML

1. Использование федеративной проверки подлинности в SAP Business Technology Platform и приложениях SAP SaaS через службу проверки подлинности удостоверений SAP

Контекст

Приложения в BTP могут использовать поставщики удостоверений с помощью конфигураций доверия для проверки подлинности пользователей с помощью протокола SAML 2.0 между BTP/XSUAA и поставщиком удостоверений. Обратите внимание, что поддерживается только SAML 2.0, даже если протокол OpenID Connect используется между приложением и BTP/XSUAA (не относится к этому контексту).

В BTP вы можете настроить конфигурацию доверия для SAP Cloud Identity Services — Identity Authentication (это по умолчанию), но если ваш основной каталог пользователей — Microsoft Entra ID, вы можете настроить federation, чтобы пользователи могли выполнить вход с помощью существующих учетных записей Microsoft Entra.

На основе федерации можно дополнительно настроить предоставление пользователей, чтобы пользователи Microsoft Entra были заранее подготовлены в BTP. Однако для этого нет собственной поддержки (только для Microsoft Entra ID -> SAP Identity Authentication Service). Интегрированное решение с поддержкой на уровне платформы будет служба управления идентификацией BTP. Подготовка учетных записей пользователей заранее может оказаться полезной для авторизации (например, для добавления пользователей в роли). Однако в зависимости от требований вы также можете добиться этого с помощью групп Microsoft Entra (см. ниже), что может означать, что вам вообще не нужна подготовка пользователей.

При настройке отношения федерации существует несколько вариантов:

• Вы можете напрямую установить федерацию с Microsoft Entra ID из BTP/XSUAA.
• Вы можете настроить федерацию с IAS, которая, в свою очередь, настроена для федерации с Microsoft Entra ID в качестве поставщика корпоративных удостоверений (также называемого "SAML Proxying").

Для приложений SAP SaaS IAS подготовлен и предварительно настроен для простого подключения конечных пользователей. (Примеры этого: SuccessFactors, Marketing Cloud, Cloud for Customer, Sales Cloud и другие.) Этот сценарий менее сложный, так как IAS напрямую связан с целевым приложением и не связан с XSUAA. В любом случае для этой настройки применяются те же правила, что и для Microsoft Entra ID с IAS в целом.

Что мы рекомендуем?

Если вашим основным каталогом пользователей является Microsoft Entra ID, рекомендуется настроить конфигурацию доверия BTP в отношении IAS. В свою очередь IAS настраивается для федерации с Microsoft Entra ID в качестве поставщика корпоративных идентификаторов.

В конфигурации доверия в BTP рекомендуется включить функцию "Создание теневых пользователей во время входа". Таким образом, пользователи, которые еще не были созданы в BTP, автоматически получают учетную запись при входе через IAS /Microsoft Entra ID в первый раз. Если этот параметр отключен, только предварительно подготовленные пользователи будут разрешены для входа.

Почему эта рекомендация?

При использовании федерации можно настроить конфигурацию доверия на уровне субаккаунта BTP. В этом случае необходимо повторить конфигурацию для каждого субаккаунта, который вы используете. Используя IAS в качестве промежуточной конфигурации доверия, вы получаете преимущество от централизованной настройки через несколько учетных записей и можете задействовать такие функции IAS, как аутентификация на основе рисков и централизованное обогащение атрибутов утверждения. Для защиты взаимодействия с пользователем эти расширенные функции безопасности должны применяться только в одном расположении. Это может быть IAS, или если Microsoft Entra ID остается единственным авторитетным хранилищем пользователей (как подразумевается в этом документе), это будет централизованно обрабатываться Microsoft Entra Conditional Access.

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

Сводка по реализации

В Microsoft Entra ID:

• При необходимости настройте Microsoft Entra ID для бесшовного единого входа (Seamless SSO), который автоматически авторизует пользователей, когда они находятся на корпоративных устройствах, подключенных к корпоративной сети. При включении пользователи не должны вводить пароли для входа в Microsoft Entra ID, а обычно даже вводить имена пользователей.

В Microsoft Entra ID и IAS:

• Следуйте документации по подключению Microsoft Entra ID к IAS в режиме федерации (прокси)(SAP doc, Microsoft doc). Следите за настройкой NameID в конфигурации SSO в Microsoft Entra ID, потому что идентификаторы UPN не обязательно являются адресами электронной почты.
• Настройте пакетное приложение для использования Microsoft Entra ID, перейдя на страницу "Conditional Authentication" и задайте для поставщика корпоративных удостоверений значение по умолчанию, представляющее каталог Microsoft Entra.

В BTP:

• Настройте конфигурацию доверия для IAS (документация SAP) и убедитесь, что "Доступно для входа пользователей" и "Создание теневых пользователей во время входа" включены оба параметра.
• При необходимости отключите параметр "Доступно для входа пользователя" в настройке доверия SAP ID Service, чтобы пользователи всегда аутентифицировались через Microsoft Entra ID и не видели экран выбора поставщика удостоверений.

2. Использование Microsoft Entra ID для проверки подлинности и IAS/BTP для авторизации

Контекст

При настройке BTP и IAS для пользователя аутентификации через федерацию с Microsoft Entra ID существует несколько вариантов настройки авторизации:

• В Microsoft Entra ID можно назначить пользователей и группы Microsoft Entra корпоративному приложению, представляющему экземпляр SAP IAS в Microsoft Entra ID.
• В IAS можно использовать проверку подлинности на основе рисков, чтобы разрешить или заблокировать вход, что позволяет предотвратить доступ к приложению в BTP.
• В BTP коллекции ролей можно использовать для определения пользователей и групп доступа к приложению и получения определенных ролей.

Что мы рекомендуем?

Мы рекомендуем не помещать авторизацию непосредственно в самой Microsoft Entra и явно отключить "Назначение пользователей обязательно" в корпоративном приложении Microsoft Entra ID. Обратите внимание, что для приложений SAML этот параметр включен по умолчанию, поэтому необходимо выполнить явное действие, чтобы отключить его.

Почему эта рекомендация?

С точки зрения Microsoft Entra ID, когда приложение федеративно через IAS, пользователь фактически аутентифицируется в IAS во время входа. Это означает, что Microsoft Entra ID не имеет сведений о том, в каком окончательном приложении BTP пользователь пытается войти в систему. Это также означает, что авторизация в Microsoft Entra ID может использоваться только для выполнения очень укрупненной авторизации, например разрешить пользователю войти в любое приложение в BTP или ни в одно. Это также подчеркивает стратегию SAP по изолированию приложений и механизмов проверки подлинности на уровне субаккаунта BTP.

Хотя это может быть действительной причиной использования "Обязательное назначение пользователей", это означает, что в настоящее время существует два разных места, где требуется хранить сведения об авторизации: как в корпоративном приложении Microsoft Entra ID (где оно относится ко всем приложениям BTP), а также в каждом субаккаунте BTP. Это может привести к путанице и неправильной настройке, когда параметры авторизации обновляются в одном месте, но не в другом. Например, пользователь был разрешен в BTP, но не назначен приложению в Microsoft Entra ID что привело к сбою проверки подлинности.

Сводка по реализации

Во корпоративном приложении Microsoft Entra, представляющем федеративную связь с IAS, отключите "требуется назначение пользователя". Это также означает, что можно безопасно пропустить назначение пользователей.

3. Использование групп Microsoft Entra для авторизации с помощью коллекций ролей в IAS/BTP

Контекст

Если вы хотите настроить авторизацию для приложений BTP, существует несколько вариантов:

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

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

Что мы рекомендуем?

Если вы хотите использовать Microsoft Entra ID в качестве авторитетного источника для точной авторизации, рекомендуется использовать группы Microsoft Entra и назначать их коллекциям ролей в BTP. Предоставление пользователям доступа к определенным приложениям, а затем просто означает добавление их в соответствующие группы Microsoft Entra без дополнительной настройки, необходимой в IAS/BTP.

В этой конфигурации рекомендуется использовать идентификатор группы Microsoft Entra (идентификатор объекта) в качестве уникального идентификатора группы, а не отображаемого имени (sAMAccountName). Это означает, что идентификатор группы должен использоваться в качестве утверждения "Группы" в токене SAML, выданном Microsoft Entra ID. Кроме того, идентификатор группы используется для назначения набора ролей в BTP.

Почему эта рекомендация?

Если вы назначите пользователей непосредственно коллекциям ролей в BTP, централизованная авторизация в Microsoft Entra ID не будет осуществляться. Это также означает, что пользователь уже должен существовать в IAS, прежде чем его можно добавить в Коллекцию ролей BTP, и учитывая, что мы рекомендуем федерацию вместо подготовки пользователей, это означает, что теневая учетная запись пользователя может еще не существовать в IAS в момент назначения пользователя. Использование групп Microsoft Entra и назначение их коллекциям ролей устраняет эти проблемы.

Назначение групп коллекциям ролей может противоречить предыдущей рекомендации не использовать Microsoft Entra ID для авторизации. Даже в этом случае решение о авторизации по-прежнему принимается в BTP, это просто то, что решение в настоящее время основано на членстве в группах, сохраняемых в Microsoft Entra ID.

Рекомендуется использовать идентификатор группы Microsoft Entra, а не своё имя, потому что идентификатор группы является глобально уникальным, неизменяемым и никогда не может быть повторно использован для другой группы позже. Использование же имени группы может привести к проблемам при изменении имени, и существует риск безопасности, если группа будет удалена, а затем создана другая с тем же именем, но с пользователями, которым не должен предоставляться доступ к приложению.

Сводка по реализации

В Microsoft Entra ID:

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

  • Задайте для атрибута Source значение "Идентификатор группы" и имя Groups (орфографировано точно так же, как это, с верхним регистром G).

  • Кроме того, чтобы уменьшить размер данных в утверждениях и избежать ситуации, когда Microsoft Entra ID ограничивает количество групповых утверждений до 150 в SAML-утверждениях, мы настоятельно рекомендуем ограничить группы, возвращаемые в утверждениях, только тем, которые были явно назначены.

    • В разделе "Какие группы, связанные с пользователем, должны быть возвращены в утверждении?" ответьте: "Группы, назначенные приложению". Затем для групп, которые необходимо включить в качестве утверждений, назначьте их корпоративному приложению с помощью раздела "Пользователи и группы" и выберите "Добавить пользователя или группу".

    

В IAS:

• В конфигурации поставщика корпоративных удостоверений в параметрах федерации удостоверений убедитесь, что вы отключите "Использовать хранилище пользователей для аутентификации удостоверений"; в противном случае сведения о группе из Microsoft Entra ID не будут сохранены в токене SAML в сторону BTP и авторизация завершится ошибкой.

В BTP:

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

4. Используйте один субаккаунт BTP только для приложений, имеющих аналогичные требования к идентификации.

Контекст

В BTP, каждый субаккаунт может содержать несколько приложений. Однако с точки зрения IAS "Пакетное приложение" является полным субаккаунтом BTP, а не более мелкими приложениями внутри него. Это означает, что все параметры доверия, настройка аутентификации и доступа, а также брендинг и параметры макета в IAS применяются ко всем приложениям в этой учетной записи. Аналогичным образом, все параметры доверия и коллекции ролей в BTP также применяются ко всем приложениям в этой подучетной записи.

Что мы рекомендуем?

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

Почему эта рекомендация?

Объединяя несколько приложений с очень разными требованиями к удостоверению в одну учетную запись субаккаунта в BTP, вы рискуете получить небезопасную конфигурацию или неправильно ее настроить. Например, при изменении конфигурации общего ресурса, например поставщика удостоверений, для одного приложения в BTP это влияет на все приложения, использующие этот общий ресурс.

Сводка по реализации

Тщательно подумайте, как вы хотите сгруппировать несколько приложений в субаккаунтах BTP. Дополнительные сведения см. в документации по модели учетной записи SAP.

5. Использование производственного тенанта IAS для проверки подлинности и авторизации конечных пользователей

Контекст

При работе с IAS у вас обычно есть производственный и разработочный/тестовый арендатор. Для различных субаккаунтов или приложений в BTP можно выбрать, какого поставщика удостоверений (арендатор IAS) использовать.

Что мы рекомендуем?

Мы рекомендуем всегда использовать производственный IAS-тенант для любого взаимодействия с конечными пользователями, даже в контексте версии разработки или тестовой среды приложения, в который они должны войти.

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

Почему эта рекомендация?

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

6. Определение процесса для ротации сертификатов подписи SAML

Контекст

При настройке федерации между Microsoft Entra ID и IAS, а также между IAS и BTP, происходит обмен метаданными SAML, которые содержат сертификаты X.509, используемые для шифрования и криптографических подписей токенов SAML, передаваемых между обеими сторонами. Эти сертификаты имеют срок действия и должны периодически обновляться (даже в чрезвычайных ситуациях, когда сертификат был скомпрометирован, например).

Примечание. Срок действия начального сертификата Microsoft Entra по умолчанию, используемый для подписывания утверждений SAML, составляет 3 года (и обратите внимание, что сертификат относится к корпоративному приложению, в отличие от токенов OpenID Connect и OAuth 2.0, подписанных глобальным сертификатом в Microsoft Entra ID). Вы можете создать новый сертификат с другой датой окончания срока действия или создать и импортировать собственный сертификат.

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

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

Однако IAS позволяет настраивать поставщиков корпоративных удостоверений только через импорт XML-файла метаданных. Он не поддерживает предоставление конечной точки метаданных для динамического извлечения метаданных Microsoft Entra (например, https://login.microsoftonline.com/my-azuread-tenant/federationmetadata/2007-06/federationmetadata.xml?appid=my-app-id). Аналогичным образом BTP не позволяет настроить новую конфигурацию доверия из конечной точки метаданных IAS (например https://my-ias-tenant.accounts.ondemand.com/saml2/metadata, она также требует однократной отправки XML-файла метаданных.

Что мы рекомендуем?

При настройке федерации удостоверений между любыми двумя системами (например, Microsoft Entra ID и IAS, а также IAS и BTP), убедитесь, что вы фиксируете дату окончания срока действия используемых сертификатов. Убедитесь, что эти сертификаты можно заменить заранее, и что существует документированный процесс обновления новых метаданных во всех проверяющих сторонах, которые зависят от этих сертификатов.

Как описано ранее, мы рекомендуем настроить конфигурацию доверия в BTP для IAS, которая, в свою очередь, настроена для федерации с Microsoft Entra ID в качестве поставщика корпоративных удостоверений. В этом случае важны следующие сертификаты (которые используются для подписывания и шифрования SAML):

• Сертификат субаккаунта в BTP: в этом случае нужно обязательно обновить конфигурацию SAML 2.0 приложения в IAS.
• Сертификат клиента в IAS: при этом необходимо обновить конфигурацию SAML 2.0 корпоративного приложения в Microsoft Entra ID и конфигурацию доверия в BTP.
• Сертификат приложения предприятия в Microsoft Entra ID: если этот сертификат изменяется, необходимо обновить конфигурацию службы удостоверения личности предприятия SAML 2.0 в IAS.

SAP предлагает примеры реализации уведомлений о сертификатах клиента с использованием SAP Cloud Integration и обработки почти истекших сертификатов. Это можно адаптировать с помощью служб Azure Integration Services или Power Automate. Однако им потребуется адаптироваться для работы с сертификатами сервера. Такой подход требует индивидуальной реализации.

Почему эта рекомендация?

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

Сводка по реализации

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

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

Дальнейшие шаги

• Дополнительные сведения о начальной настройке в этом руководстве
• план развертывания Microsoft Entra для предоставления доступа пользователям в исходные и целевые приложения SAP и
• управление доступом к приложениям SAP
• Узнайте о дополнительных сценариях интеграции SAP с идентификатором Microsoft Entra и других возможностях.