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

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

  • Статья

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

Примечание.

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

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

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

Федерация

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

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

Общие сведения о федерации см. в шаблоне федеративных удостоверений.

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

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

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

Единый вход

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

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

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

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

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

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

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

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

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

Имперсонация

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

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

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

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

Авторизация

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

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

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

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

Дополнительные сведения см. в разделе "Роли приложения".

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

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

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

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

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

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

Использование идентификатора Microsoft Entra или Azure AD B2C

Корпорация Майкрософт предоставляет идентификатор Microsoft Entra, Внешняя идентификация Microsoft Entra и Azure AD B2C, которые являются платформами управляемых удостоверений, которые можно использовать в собственном мультитенантном решении.

Многие мультитенантные решения — это программное обеспечение как услуга (SaaS). Выбор того, следует ли использовать идентификатор Microsoft Entra, Внешняя идентификация Microsoft Entra или Azure AD B2C, отчасти зависит от способа определения клиентов или базы клиентов.

  • Если ваши клиенты или клиенты являются организациями, они уже могут использовать идентификатор Microsoft Entra для таких служб, как Office 365, Microsoft Teams или для собственных сред Azure. Вы можете создать мультитенантное приложение в собственном каталоге Microsoft Entra, чтобы сделать решение доступным для других каталогов Microsoft Entra. Вы даже можете перечислить решение в Azure Marketplace и сделать его доступным для организаций, использующих идентификатор Microsoft Entra.
  • Если ваши клиенты или клиенты не используют идентификатор Microsoft Entra или если они частные лица, а не организации, рассмотрите возможность использования Внешняя идентификация Microsoft Entra или Azure AD B2C. Как Внешняя идентификация Microsoft Entra, так и Azure AD B2C предоставляют набор функций для контроля регистрации и входа пользователей. Например, вы можете ограничить доступ к решению только пользователям, которые вы уже пригласили, или вы можете разрешить самостоятельную регистрацию. Используйте пользовательские политики в Azure AD B2C, чтобы полностью контролировать взаимодействие пользователей с платформой удостоверений. Вы можете использовать настраиваемую фирменную символику и настроить федерацию Azure AD B2C с собственным клиентом Microsoft Entra, чтобы предоставить своим сотрудникам возможность входить в систему. Azure AD B2C также включает федерацию с другими поставщиками удостоверений.
  • Некоторые мультитенантные решения предназначены для обоих ситуаций, перечисленных выше. У некоторых клиентов могут быть собственные клиенты Microsoft Entra, а другие — нет. Вы также можете использовать Azure AD B2C для этого сценария и использовать пользовательские политики, чтобы разрешить вход пользователей из каталога Microsoft Entra клиента. Однако если вы используете пользовательские политики для установления федерации между клиентами, убедитесь, что вы считаете ограничения на количество настраиваемых политик , которые может использовать один каталог Azure AD B2C.

Дополнительные сведения см. в статье "Рекомендации по использованию Azure Active Directory B2C в мультитенантной архитектуре".

Неподходящие антишаблоны

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

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

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

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

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

Не удается рассмотреть требования клиентов

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

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

Подключение пользователей и клиентов

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

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

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

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

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

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

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

Соавторы

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

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

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

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

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