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

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

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

  • Проверка удостоверения пользователя, известного как проверка подлинности

  • Обеспечение разрешений пользователя в рамках тенанта, известное как авторизация

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

Внимание

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

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

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

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

  • Рассмотрите возможность реализации современных стандартов проверки подлинности и авторизации, таких как OAuth2 и OpenID Connect.

  • Оцените, ограничена ли проверка подлинности приложениями на основе пользовательского интерфейса или доступ к API также применяется к клиентам и сторонним системам.

  • Определите, необходимо ли арендаторам объединяться с собственными IdP и нужно ли поддерживать несколько IdP для каждого арендатора. Например, у вас могут быть арендаторы с идентификатором Microsoft Entra ID, Auth0 и службами федерации Active Directory, где каждый арендатор соединён с вашим решением через федерацию. Определите, какие протоколы федерации используют поставщики удостоверений, так как эти протоколы определяют, какие протоколы ваш поставщик удостоверений должен поддерживать.

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

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

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

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

Каталог идентичностей

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

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

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

  • Социальный идентификатор: Социальный idP позволяет пользователям использовать удостоверение, которое у них есть в социальной сети или другом общедоступном idP, например Facebook, Google или личной учетной записи Майкрософт. Социальные поставщики удостоверений обычно используются в B2C-решениях SaaS для бизнеса и потребителей.

  • Каталог Microsoft Entra ID арендатора: Во многих SaaS-решениях для бизнеса (B2B) арендаторы часто уже имеют собственный каталог Microsoft Entra ID и хотят, чтобы ваше решение использовало их каталог в качестве поставщика удостоверений (IdP) для доступа к вашему решению. Этот подход возможен при создании решения в виде мультитенантного приложения Microsoft Entra.

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

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

Хранение сведений о проверке подлинности и авторизации клиента

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

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

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

  • Сведения, относящиеся к арендатору, такие как роли арендатора и права доступа, для авторизации.

Внимание

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

Рассмотрим следующие варианты хранения сведений об удостоверениях:

  • Храните все сведения об удостоверении и авторизации в каталоге поставщика удостоверений (IdP) и делитесь ими между несколькими арендаторами.

  • Сохраните учетные данные пользователя в каталоге IdP. Храните данные авторизации на уровне приложения, а также сведения о клиенте.

Определение количества идентификаторов для пользователя

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

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

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

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

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

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

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

Если ваше решение ограничивает доступ к данным для одного клиента, рассмотрите следующие решения:

  • Как IdP определяет, каким арендатором пользуется пользователь.

  • Объясните, как idP передает идентификатор клиента приложению. Как правило, в токен включается утверждение идентификатора арендатора.

Если одному пользователю необходимо предоставить доступ к нескольким клиентам, рассмотрите следующие решения:

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

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

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

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

Процесс создания учетной записи для локальных удостоверений или социальных удостоверений

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

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

  • Укажите, позволяет ли ваше решение использовать только определенные домены электронной почты, если используются локальные удостоверения. Например, определите, может ли арендатор ограничить регистрацию пользователям с адресом электронной почты @contoso.com.

  • Основное имя пользователя (UPN), используемое для идентификации локальных учетных записей, должно быть четко установлено. К унифицированным именам участников относятся адреса электронной почты, имена пользователей, номера телефонов или идентификаторы членства. Так как унифицированные имена участников могут изменяться, рекомендуется ссылаться на неизменяемый уникальный идентификатор для авторизации и проверки. Примером является идентификатор объекта (OID) в Microsoft Entra ID.

  • Может потребоваться проверка UPN для обеспечения их точности. Этот процесс может включать проверку владения адресом электронной почты или номером телефона перед предоставлением доступа.

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

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

Доступ арендатора для пользователей, самостоятельно регистрирующихся

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

  • Определите, как поток регистрации определяет, предоставлен ли пользователю доступ к конкретному клиенту.

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

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

Автоматическое управление жизненным циклом учетных записей

Распространенное требование для корпоративных или корпоративных клиентов решения — это набор функций, позволяющих автоматизировать подключение и отключение учетных записей. Открытые протоколы, такие как system for Cross-Domain Identity Management (SCIM) (SCIM), предоставляют стандартный подход к автоматизации. Этот автоматизированный процесс обычно включает создание и удаление записей удостоверений и управление разрешениями клиента. При реализации автоматического управления жизненным циклом учетных записей в мультитенантном решении следует учитывать следующие факторы:

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

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

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

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

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

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

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

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

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

Идентичности рабочих нагрузок

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

Microsoft Entra поддерживает идентификации рабочих нагрузок, а другие поставщики удостоверений их также часто поддерживают.

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

Если клиенты могут включить доступ к удостоверению рабочей нагрузки в мультитенантном решении, следует учитывать следующие факторы:

  • Определите, как создаются и управляются идентификации рабочей нагрузки в каждом арендаторе.

  • Определите, как запросы, связанные с идентификацией рабочих нагрузок, определяются в контексте арендатора.

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

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

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

Объединение с провайдером удостоверений для SSO (единого входа)

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

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

Если вы ожидаете, что арендаторы будут интегрироваться с вашим решением, рассмотрите следующие аспекты:

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

  • Определите, какие протоколы федерации поддерживает ваше решение.

  • Установите процессы, которые предотвращают предоставление доступа к незапланированным арендаторам из-за неправильной настройки федерации.

  • Запланируйте, нужно ли идентификационный провайдер одного арендатора федеративно связать с несколькими арендаторами в вашем решении. Например, если у клиентов есть тестовый и продуктивный арендаторы, им может понадобиться связать один и тот же поставщик удостоверений (IdP) с каждым арендатором.

Модели авторизации

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

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

  • Авторизация на основе ресурсов: Решение предоставляет набор отдельных ресурсов, каждый из которых имеет собственный набор разрешений. Конкретный пользователь может быть администратором одного ресурса и не иметь доступа к другому ресурсу.

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

Права и лицензирование

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

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

Масштаб и том проверки подлинности удостоверений

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

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

  • Оцените, обрабатывает ли процесс проверки подлинности ожидаемое количество входов и регистрации.

  • Определите, существуют ли пики, которые система проверки подлинности не может обрабатывать. Например, в 9:00 по Тихоокеанскому времени все сотрудники в западной части США могут начать работу и войти в систему, что создает всплеск запросов на вход. Эти сценарии иногда называются штормами входа.

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

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

Соавторы

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

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

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

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