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

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

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

Токен идентификатора платформы удостоверений Microsoft является частью стандарта OpenID Connect (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": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536361411,
  "iat": 1536274711,
  "nbf": 1536274711,
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Abe Lincoln",
  "preferred_username": "AbeLi@microsoft.com",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
}.
.[Signature]

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

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

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

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

Чтобы продемонстрировать проверку подлинности пользователей, давайте рассмотрим приложения, использующие 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 использует подход брокера проверки подлинности (auth broker) для родных приложений, как показано на следующей схеме.

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

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

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

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

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