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

Управление токенами для Zero Trust

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

Убедитесь, что ваше приложение соответствует принципу "нулевого доверия" и принципу наименьших привилегий, а также предотвращает использование такими способами, которые могут скомпрометировать ваши цели. Ограничьте доступ пользователей с помощью методик "Just-In-Time" и "Just-Enough-Access" (JIT/JEA), а также адаптивных политик, основанных на анализе рисков, и средств защиты данных. Разделите конфиденциальные и мощные разделы приложения. Предоставьте только авторизованный доступ пользователей к этим областям. Ограничить пользователей, которые могут использовать свое приложение и возможности, которые они имеют в приложении.

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

Упростите управление авторизациями в вашем приложении для клиентов. Уменьшите затраты на создание и настройку пользователей и процессы вручную. Автоматическая подготовка пользователей позволяет ИТ-администраторам автоматизировать создание, обслуживание и удаление пользовательских удостоверений в целевых хранилищах удостоверений. Клиенты могут автоматизировать изменения пользователей и групп с использованием управления приложениями или управления на основе данных HR в Microsoft Entra ID.

Используйте токен-утверждения в ваших приложениях

Используйте клеймы в ID токенах для пользовательского опыта в вашем приложении в качестве ключей в базе данных. Предоставление доступа к клиентскому приложению. Маркер идентификатора — это основное расширение, которое OpenID Connect (OIDC) добавляет в OAuth 2.0. Приложение может получать маркеры идентификатора вместе с маркерами доступа или вместо маркеров доступа.

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

  • Утверждение аудитории (aud) — это идентификатор клиента вашего приложения. Принимайте только токены для идентификатора клиента API.
  • Предъявление tid — это идентификатор арендатора, выдавшего токен. Утверждение oid является неизменяемым значением, которое однозначно идентифицирует пользователя. Используйте уникальное сочетание утверждений tid и oid утверждений в качестве ключа, если необходимо связать данные с пользователем. Используйте эти значения утверждений для подключения данных к идентификатору пользователя в идентификаторе Microsoft Entra ID.
  • Утверждение sub является неизменяемым значением, уникальным образом удостоверяющим пользователя. Утверждение субъекта также уникально для вашего приложения. Если вы используете утверждение sub для связывания данных с пользователем, невозможно использовать ваши данные, чтобы связать их с пользователем в Microsoft Entra ID.

Приложения могут использовать область openid для запроса токена идентификатора из платформы идентификаций Майкрософт. Стандарт OIDC управляет openid областью вместе с форматом и содержимым ID-токена. OIDC указывает следующие области:

  • Используйте openid контекст для входа пользователя и добавления sub утверждения в токен идентификатора. Эти области действия предоставляют идентификатор пользователя, уникальный для приложения и пользователя, и вызывают конечную точку UserInfo.
  • Область действия email добавляет email утверждение, содержащее адрес электронной почты пользователя в маркер идентификатора.
  • Область profile добавляет утверждения с основными атрибутами профиля пользователя (имя, имя пользователя) в маркер идентификатора.
  • Область offline_access позволяет приложению получать доступ к данным пользователей, даже если пользователь отсутствует.

Библиотека проверки подлинности Майкрософт (MSAL) всегда добавляет области openid, email и profile в каждый запрос токена. В результате MSAL всегда возвращает идентификационный токен и токен доступа при каждом вызове AcquireTokenSilent или AcquireTokenInteractive. MSAL всегда запрашивает область действия offline_access. Платформа идентификации Microsoft всегда возвращает offline_access область, даже если запрашивающее приложение не указывает область offline_access.

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

Например, Microsoft Graph определяет User.Read область, которая разрешает приложению доступ к полному профилю пользователя текущего пользователя и имени клиента. Microsoft Graph определяет разрешения в полном диапазоне функциональных возможностей, доступных в этом API.

После авторизации платформа идентификации Майкрософт возвращает вашей программе токен доступа. При вызове ресурса приложение предоставляет этот маркер в качестве части заголовка авторизации HTTP-запроса к API.

Управление временем существования токенов

Приложения могут создавать сеанс для пользователя после успешной проверки подлинности с идентификатором Microsoft Entra. Управление сеансами пользователей приводит к частоте повторения проверки подлинности пользователем. Роль системы в поддержании аутентифицированного пользователя в рамках приложения с правильными привилегиями и на нужное время имеет решающее значение. Время существования сеанса должно основываться на утверждении exp в ID-токене. Утверждение exp — это момент, когда истекает срок действия маркера идентификатора, и момент, после которого вы больше не сможете использовать маркер для аутентификации пользователя.

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

Как правило, убедитесь, что токены допустимы и не истекли. Утверждение аудитории (aud) должно соответствовать идентификатору клиента. Убедитесь, что токен поступает из авторитетного издателя. Если у вас есть мультитенантный API, можно отфильтровать, чтобы только определенные клиенты могли вызывать API. Убедитесь, что вы обеспечиваете соблюдение времени существования токена. Проверьте утверждения nbf (не раньше) и exp (срок действия), чтобы убедиться, что текущее время находится в пределах значений этих двух утверждений.

Не стремитесь к исключительно длинным или коротким срокам существования сеанса. Пусть срок действия предоставленного маркера идентификатора определяет это решение. Сохранение активности сеансов приложения за пределами допустимости маркеров нарушает правила, политики и проблемы, которые привели ИТ-администратора установить срок действия маркера, чтобы предотвратить несанкционированный доступ. Короткие сеансы ухудшают взаимодействие с пользователем и не обязательно повышают уровень безопасности. Популярные платформы, такие как ASP.NET, позволяют задавать время истечения сеанса и cookies в зависимости от срока действия токена Microsoft Entra ID. Следуйте сроку действия токена поставщика удостоверений, чтобы убедиться, что сеансы пользователя не превышают ограничения, установленные политиками поставщика удостоверений.

Кэш и маркеры обновления

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

Библиотеки MSAL обрабатывают механизмы протокола OAuth 2.0, включая процессы обновления токенов. Если вы не используете MSAL, убедитесь, что ваша библиотека будет эффективно использовать маркеры обновления.

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

Управление ошибками токенов и багами

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

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

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

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

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

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

Дальнейшие действия

  • Last updated on