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

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

• Проверка того, является ли пользователь (проверка подлинности).
• Принудительное применение разрешений пользователя в пределах области клиента (авторизация).

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

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

• Будет ли использоваться удостоверение пользователя или идентификаторы рабочей нагрузки для доступа к одному приложению или нескольким приложениям внутри семейства продуктов? Например, семейство розничных продуктов может иметь как приложение для точки продажи, так и приложение для управления инвентаризацией, которое совместно используют одно и то же решение для идентификации.
• Планируется ли реализовать современную проверку подлинности и авторизацию, например OAuth2 и OpenID Connect?
• Предоставляет ли ваше решение проверку подлинности только приложениям на основе пользовательского интерфейса? Или вы также предоставляете доступ к API клиентам и третьим лицам?
• Потребуется ли арендаторам объединять свои собственные поставщики удостоверений, и будет ли необходима поддержка нескольких разных поставщиков удостоверений для каждого арендатора? Например, у вас могут быть арендаторы с идентификатором Microsoft Entra ID, Auth0 и службой федерации Active Directory (AD FS), и каждый из них пожелает установить федеративные отношения с вашим решением. Кроме того, необходимо понять, какие протоколы федерации IdP ваших арендаторов будут поддерживаться, так как протоколы влияют на требования для вашего IdP.
• Существуют ли конкретные требования к соблюдению, которым они должны следовать, например GDPR?
• Требуются ли вашим арендаторам идентификационные данные, размещённые в определенном географическом регионе?
• Требуется ли пользователям вашего решения доступ к данным из одного клиента или из нескольких клиентов в вашем приложении? Требуется ли им возможность быстро переключаться между клиентами или просматривать консолидированную информацию из нескольких клиентов? Например, пользователи, вошедшие в портал Azure, могут легко переключаться между различными каталогами идентификаторов Microsoft Entra и подписками, к которым у них есть доступ.

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

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

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

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

• Локальный поставщик услуг идентификации. Локальный поставщик удостоверений позволяет пользователям зарегистрироваться в службе. Пользователи предоставляют имя пользователя, адрес электронной почты или идентификатор, например номер карты вознаграждения. Они также предоставляют учетные данные, например пароль. IdP сохраняет идентификатор пользователя и учетные данные.
• Поставщик социальных удостоверений личности. Поставщик удостоверений социальных сетей позволяет пользователям использовать удостоверение, которое они имеют в социальной сети или другом общедоступном поставщике удостоверений, таких как Facebook, Google или личная учетная запись Майкрософт.
• Используйте каталог Microsoft Entra ID арендатора. Арендаторы могут уже иметь в наличии собственный каталог Microsoft Entra ID, и потом они могут захотеть, чтобы ваше решение использовало их каталог в качестве поставщика IdP для доступа к вашему решению. Этот подход возможен при создании решения в виде мультитенантного приложения Microsoft Entra.
• Федерация с поставщиком удостоверений арендатора. Арендаторы могут иметь собственный поставщик услуг идентификации, отличный от Microsoft Entra ID, и они могут захотеть, чтобы ваше решение могло федеративно интегрироваться с этим. Федерация включает возможности единого входа и позволяет клиентам управлять жизненным циклом и политиками безопасности своих пользователей независимо от вашего решения.

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

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

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

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

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

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

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

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

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

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

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

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

• Как IdP определяет, к какому арендатору обращается пользователь?
• Как idP передает идентификатор клиента приложению? Как правило, в токен добавляется утверждение идентификатора арендатора.

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

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

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

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

• Какие источники удостоверений разрешены пользователям для регистрации? Например, может ли пользователь создать локальное удостоверение и также использовать провайдера социальных идентификаторов?
• Если разрешены только локальные идентификаторы, будут разрешены только определенные домены электронной почты? Например, может ли клиент указать, что только пользователи, у которых есть @contoso.com адрес электронной почты, разрешены для регистрации?
• Какое имя пользователя (UPN) следует использовать для уникальной идентификации каждой локальной учетной записи во время процесса входа? Например, адрес электронной почты, имя пользователя, номер телефона и номер карты вознаграждений — это распространенные варианты для унифицированных идентификаторов пользователя. Однако UPN (имена пользователей в каталоге) могут меняться со временем. Если вы ссылаетесь на идентичность в правилах авторизации приложения или журналах аудита, рекомендуется использовать основной неизменяемый уникальный идентификатор идентичности. Идентификатор Microsoft Entra предоставляет идентификатор объекта (OID), который является неизменяемым идентификатором.
• Требуется ли пользователю подтвердить свой UPN? Например, если адрес электронной почты или номер телефона пользователя используется в качестве UPN, как вы удостоверитесь в точности информации?
• Должны ли администраторы арендатора утвердить подписки?
• Нужны ли арендаторам специфический процесс регистрации или URL-адрес? Например, требуют ли ваши арендаторы фирменный процесс регистрации для пользователей? Требуется ли арендаторам возможность перехватывать запрос на регистрацию и выполнять дополнительную проверку перед его обработкой?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интеграция с поставщиком удостоверений для SSO (единого входа)

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

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

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

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

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

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

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

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

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

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

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

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

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

• Будет ли каталог пользователей масштабироваться до количества необходимых пользователей?
• Будет ли процесс проверки подлинности обрабатывать ожидаемое количество входов и регистрации?
• Будут ли пики, которые система проверки подлинности не может обрабатывать? Например, на 9 утра PST все пользователи в западной США регионе могут начать работу и войти в решение, что приводит к всплеску запросов на вход. Эти ситуации иногда называются бурями аутентификации.
• Может ли высокая нагрузка в других частях решения повлиять на производительность процесса проверки подлинности? Например, если процесс проверки подлинности требует вызова в API уровня приложений, будет ли большое количество запросов проверки подлинности вызвать проблемы для остальной части решения?
• Что произойдет, если ваш idP становится недоступным? Существует ли резервная служба аутентификации, которая может обеспечить непрерывность бизнеса, пока провайдер идентификации недоступен?

Соавторы

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

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

• Джон Даунс | Главный инженер программного обеспечения
• Даниэль Скотт-Райнсфорд | Стратег технологий партнеров
• Арсен Владимирский | Главный инженер клиента, FastTrack для Azure

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

• Jelle Druyts | Главный инженер клиента, FastTrack для Azure
• Лэндон Пирс | Старший инженер клиента
• Сандер ван ден Ховен | Старший стратег технологий партнеров
• Ник Уорд | Старший архитектор облачных решений

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

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