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

Архитектурные подходы к идентификации в мультитенантных решениях

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

Примечание.

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

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

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

Федерация

Может потребоваться федеративное взаимодействие с внешними поставщиками удостоверений. Федерацию можно использовать для включения следующих сценариев:

  • Социальное имя входа, которое позволяет пользователям входить с помощью учетной записи Google, Facebook, GitHub или личной учетной записи Майкрософт.

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

Дополнительные сведения см. в шаблоне федеративных удостоверений.

Если вы решили поддерживать идентификационные провайдеры, специфичные для клиента, укажите, какие услуги и протоколы поддерживает ваше приложение. Например, определите, следует ли поддерживать протокол OpenID Connect и протокол языка разметки утверждений безопасности или ограничить федерацию экземплярами идентификатора Microsoft Entra ID.

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

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

Единый вход

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

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

В мультитенантном решении можно включить другую форму единого входа. Если пользователям разрешен доступ к данным в нескольких клиентах, может потребоваться обеспечить простой интерфейс, когда пользователи изменяют контекст с одного клиента на другой. Рассмотрите, требуется ли вашему решению поддерживать бесшовный переход между клиентами. Если это так, рассмотрите, следует ли вашему поставщику удостоверений повторно выпускать токены с определёнными утверждениями арендатора. Например, когда пользователь входит на портал Azure, он может переключаться между различными каталогами идентификаторов Microsoft Entra. Этот переход активирует повторную проверку подлинности и создает новый маркер из вновь выбранного экземпляра идентификатора Microsoft Entra ID.

Оценка рисков при входе

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

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

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

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

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

Выдача себя за другое лицо

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

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

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

Некоторые платформы удостоверений поддерживают олицетворение как встроенную функцию, так и с помощью пользовательского кода. Например, можно добавить пользовательское утверждение в Microsoft Entra External ID для имитируемого идентификатора пользователя или заменить утверждение идентификатора субъекта в выданных токенах.

Авторизация

Авторизация — это процесс определения того, что может сделать пользователь.

Данные авторизации могут храниться в нескольких местах, в том числе в следующих расположениях:

  • В вашем провайдере удостоверений: Например, если вы используете Microsoft Entra ID в качестве провайдера удостоверений, можно использовать такие функции, как роли приложений и группы для хранения сведений об авторизации. Затем приложение может использовать связанные утверждения маркера для принудительного применения правил авторизации.

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

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

Добавление удостоверений арендаторa и сведений о роли в токены

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

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

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

Авторизация на основе приложений

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

Используйте Microsoft Entra ID или внешний идентификатор

Идентификатор Microsoft Entra и внешний идентификатор — это платформы управляемых удостоверений, которые можно использовать в собственном мультитенантном решении.

Многие мультитенантные решения работают как SaaS. Выбор использования идентификатора Microsoft Entra или внешнего идентификатора зависит от того, как вы определяете клиентов или базу клиентов.

Это важно

Azure AD B2C также поддерживает многие сценарии, приведенные в этой статье. Однако начиная с 1 мая 2025 г. он больше недоступен для покупки новыми клиентами, поэтому мы не рекомендуем его для новых решений. Дополнительные сведения см. в статье "Часто задаваемые вопросы о Azure AD B2C".

Антипаттерны, которых следует избегать

Создание или запуск собственной системы управления идентичностью

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

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

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

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

Не учитываются требования арендаторов

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

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

Смешивание пользователей и арендаторов

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

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

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

Настройка ролей и авторизации ресурсов

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

Не удалось записать журналы аудита

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

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основные авторы:

Другие участники:

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.

  • Last updated on