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

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

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

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

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

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

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

Каталог удостоверений

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Доступ к клиенту для пользователей самостоятельной регистрации

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

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

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

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

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

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

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

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

Удостоверения рабочей нагрузки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Соавторы

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

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

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

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

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

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

Ознакомьтесь с методами архитектуры для удостоверений в мультитенантных решениях.