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


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

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

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

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

Маркер идентификатора платформа удостоверений Майкрософт является частью стандарта OpenID Подключение (OIDC), указывающего маркеры идентификатора в виде веб-маркеров JSON (JWT). Длинная строка JWT состоит из трех компонентов:

  1. Утверждения заголовка. Утверждения заголовков, присутствующих в маркерах идентификаторов, включают typ (утверждение типа), alg (алгоритм подписывания маркера) и kid (отпечаток для открытого ключа для проверки подписи маркера).
  2. Утверждения полезных данных. Полезные данные или текст (средняя часть веб-токена JSON) содержит ряд пар атрибутов имени. Стандарт должен иметь утверждение с iss именем издателя, которое отправляется в приложение, которое было выдано маркером ( audили утверждение аудитории).
  3. Подпись. Идентификатор Microsoft Entra создает подпись маркера, которую приложения могут использовать для проверки того, что маркер не изменен и вы можете доверять ему.

В следующем примере маркера идентификатора отображаются сведения о пользователе и проверка подлинности для использования приложения.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "1LTMzakihiRla_8z2BEJVXeWMqo"
}.
{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/3338040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "aud": "6cb04018-a3f5-46a7-b995-940c78f5aef3",
  "exp": 1536361411,
  "iat": 1536274711,
  "nbf": 1536274711,
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Abe Lincoln",
  "preferred_username": "[email protected]",
  "oid": "00000000-0000-0000-66f3-3332eca7ea81",
  "tid": "3338040d-6c67-4c5b-b112-36a304b66dad",
}.
.[Signature]

Маркеры идентификаторов в управлении доступом

Чтобы получить идентификатор приложения (клиента), зарегистрируйте приложение с помощью платформа удостоверений Майкрософт. При получении маркера с утверждением аудитории (aud), которое соответствует идентификатору клиента приложения, определяемый пользователь в маркере, прошедший проверку подлинности в приложении. ИТ-администраторы могут разрешить всем пользователям в клиенте использовать приложение. Они могут разрешить группе, из которой пользователь является членом приложения.

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

Эти сведения о утверждениях важны при проверке подлинности пользователя:

  • Веб-токен JSON действителен до истечения срока его действия. Утверждение exp (срок действия) сообщает вам, когда срок действия маркера истекает. Если текущее время до времени утверждения exp , маркер действителен.
  • Не учитывайте, что пользователь прошел проверку подлинности до времени, указанного nbf в утверждении (не до времени). Время nbf и exp время маркера определяют допустимое время существования маркера. Когда срок действия неизбежен, убедитесь, что вы получите новый маркер идентификатора.
  • ( sub утверждение субъекта) — это уникальный идентификатор для пользователя приложения. Тот же пользователь имеет другое sub утверждение для других приложений. Если вы хотите сохранить данные для связывания с пользователем и запретить злоумышленнику сделать это сопоставление, используйте утверждение субъекта. Так как он не предоставляет удостоверение Microsoft Entra пользователя, это самый частный способ связать данные с пользователем. Утверждение sub неизменяемо.
  • Если вы хотите предоставить общий доступ к данным в нескольких приложениях, используйте сочетание утверждений идентификатора клиента () и идентификатора объекта (tidoid), уникальных для пользователя. Объединенный идентификатор клиента и идентификатор объекта являются неизменяемыми.
  • Независимо от того, что происходит с личностью человека, suboidи tid утверждения остаются неизменяемыми. Что-либо о пользователе может измениться, и вы по-прежнему можете ключом к данным определить пользователя на основе темы или объединенных tid утверждений oid .

Проверка подлинности с помощью OIDC

Чтобы продемонстрировать проверку подлинности пользователей, давайте рассмотрим приложения, использующие OIDC для проверки подлинности пользователя. Те же принципы применяются к приложениям, используюющим язык разметки утверждений безопасности (SAML) или WS-Federation.

Приложение проверяет подлинность пользователя, когда приложение запрашивает маркер идентификатора из платформа удостоверений Майкрософт. Рабочие нагрузки (приложения, которые не имеют пользователей, а выполняются как службы, фоновые процессы, daemons) пропускают этот шаг.

Сначала этот маркер всегда должен запрашиваться автоматически. Чтобы автоматически получить маркер в библиотеках проверки подлинности Майкрософт (MSAL), приложение может начаться с AcquireTokenSilent метода. Если приложение может пройти проверку подлинности, не беспокоят пользователя, он получает запрошенный маркер идентификатора.

Если платформа удостоверений Майкрософт не может завершить запрос без взаимодействия с пользователем, приложение должно вернуться к методу MSALAcquireTokenInteractive. Чтобы интерактивно получить маркер, выполните запрос, открыв веб-поверхность для адреса в домене https://login.microsoftonline.com .

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

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

Рекомендуется создавать сеанс для пользователя после получения маркера идентификатора от идентификатора Microsoft Entra ID. В маркере идентификатора, который получает приложение, утверждение срока действия (exp) с меткой времени Unix. Эта метка времени указывает время окончания срока действия, для которого приложение не должно принимать JWT для обработки. Используйте это время истечения срока действия маркера, чтобы управлять временем существования сеансов пользователей. Утверждение exp играет важную роль в сохранении явно проверенного пользователя перед приложением с правой привилегией и в течение подходящего времени.

поддержка Единый вход

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

Как показано на следующей схеме, самый простой вариант использования общей веб-поверхности — это приложение, работающее в веб-браузере (например, Microsoft Edge, Google Chrome, Firefox, Safari). Вкладки браузера используют состояние единого входа.

Схема иллюстрирует сценарий общей веб-поверхности, в котором приложение работает в браузере.

Платформа удостоверений Майкрософт управляет состоянием единого входа в любом определенном браузере, если пользователь не открывает разные браузеры на одном устройстве. В Windows 10 и более поздней версии платформа удостоверений Майкрософт изначально поддерживает единый вход браузера Microsoft Edge. Когда пользователь вошел в Windows, размещение в Google Chrome (с помощью расширения учетных записей Windows 10) и в Mozilla Firefox v91+ (с помощью параметра браузера) позволяет каждому браузеру совместно использовать состояние единого входа в windows.

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

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

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

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

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

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

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

По проектированию базовые операционные системы (ОС) изолируют браузеры. Разработчикам требуется более тесное подключение к ОС, чтобы получить полный доступ к сведениям об устройстве. В Windows брокер проверки подлинности — это диспетчер веб-учетных записей Windows (WAM). На других устройствах брокер проверки подлинности — это приложение Microsoft Authenticator (для устройств под управлением iOS или Android) или приложение Корпоративный портал (для устройств под управлением Android). Приложения получают доступ к брокеру проверки подлинности с помощью MSAL. В Windows приложение может получить доступ к WAM без MSAL. Однако MSAL — это самый простой способ доступа к брокеру проверки подлинности приложений (особенно приложений, которые не являются универсальная платформа Windows приложениями).

Брокеры проверки подлинности работают в сочетании с идентификатором Microsoft Entra, чтобы использовать первичные маркеры обновления (PRT), которые снижают потребность пользователей в проверке подлинности несколько раз. PrTs может определить, находится ли пользователь на управляемом устройстве. Идентификатор Microsoft Entra id требует брокеров проверки подлинности, так как он вводит маркеры проверки владения, более безопасный вариант по маркерам носителя, которые распространены сегодня.

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