Пример API, защищенного платформой согласия удостоверений Майкрософт

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

Давайте рассмотрим, как API, защищенный платформой идентификации Майкрософт, использует Microsoft identity consent framework. Мы используем API Microsoft Graph в качестве примера, поскольку оно наиболее полно использует систему получения согласия платформы идентификации Microsoft.

Соглашение об именовании разрешений

Команда Microsoft Graph создала соглашение об именовании для имен разрешений, чтобы упростить связь разрешения с доступом к ресурсу, который разрешение предоставляет. Имена разрешений Microsoft Graph соответствуют простому шаблону resource.operation.constraint . Двумя основными операциями являются Read и ReadWrite (включая обновление и удаление).

Элемент ограничения влияет на степень доступа, которым обладает ваше приложение в каталоге. Microsoft Graph поддерживает следующие ограничения:

• Все предоставляют приложению разрешение на выполнение операций со всеми ресурсами указанного типа в каталоге.
• Общая предоставляет приложению разрешение на выполнение операций с ресурсами, к которым другие пользователи предоставили доступ пользователю, вошедшему в систему.
• AppFolder предоставляет приложению разрешение на чтение и запись файлов в выделенную папку в OneDrive. Это ограничение предоставляется только в объекте разрешений "Файлы " и допустимо только для учетных записей Майкрософт.
• Если указать Нет ограничений, приложение может выполнять только операции с ресурсами, которыми владеет пользователь, вошедший в систему.

Доступ и операции с определенными ресурсами

Давайте рассмотрим некоторые разрешения или области для объекта пользователя в Microsoft Graph, чтобы узнать, как конструкторы API Майкрософт включили определенный доступ и операции с определенными ресурсами:

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

Обратите внимание, что User.Read не просто предоставляет доступ к объекту пользователя. Каждое разрешение представляет определенный диапазон операций. Важно, чтобы разработчики и администраторы считывали описание разрешений, чтобы увидеть, какие разрешения разрешены. User.Readв дополнение к включению чтения полного профиля текущего пользователя приложение позволяет приложению просматривать основные сведения из объекта Organizations в Microsoft Graph.

Рассмотрим другое разрешение:

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

Рассмотрим несколько дополнительных разрешений для объекта пользователя Microsoft Graph:

Как и User.Read , User.ReadWrite и User.Read.AllUser.ReadWrite.All являются отдельными разрешениями, которые позволяют приложению следовать принципу наименьшего уровня привилегий Нулевого доверия.

User.Read.All интересен, так как каждый пользователь в организации имеет эту возможность (например, открыть Outlook, перейти вверх и вниз по цепочке отчетов). Вы, как отдельный пользователь, можете видеть полный профиль пользователя каждого другого пользователя в вашей организации. Однако дизайнеры API Microsoft Graph решили, что только администраторы должны разрешить приложению выполнять ту же операцию, так как User.Read.All включает в себя организационную иерархию клиента. Если злоумышленник получит доступ к этой информации, он может организовать целевую фишинговую атаку, где фишинговое письмо выглядит как отправленное менеджером этого человека или его непосредственным руководителем.

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

Разрешения, требующие согласия администратора

Учитывая возможности User.Read.All и User.ReadWrite.All, конструкторы API Microsoft Graph назначили эти разрешения как требование согласия администратора. Давайте добавим администратор? столбец в таблицу разрешений, чтобы указать, когда разрешение требует согласия администратора:

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

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

• Вызов API из другого API помогает обеспечить нулевое доверие, если у вас есть один API, который должен вызывать другой API и безопасно разрабатывать приложение при его работе от имени пользователя.
• Получение авторизации для доступа к ресурсам помогает понять, как лучше всего обеспечить нулевое доверие при получении разрешений доступа к ресурсам для приложения.
• Настройка токенов описывает информацию, которую можно получить в Microsoft Entra токенах. В нем объясняется, как настроить маркеры для повышения гибкости и контроля при увеличении безопасности приложений Zero Trust с минимальными привилегиями.
• Настройка утверждений о принадлежности к группам и ролей приложений в токенах объясняет, как настроить ваши приложения с использованием определений ролей и назначить группы безопасности ролям приложений. Эти методы помогают повысить гибкость и контроль при увеличении безопасности приложений Zero Trust с минимальными привилегиями.
• Запрос разрешений, требующих административного согласия, описывает опыт работы с разрешениями и согласием, когда разрешения для приложений требуют административного согласия.
• В этом кратком руководстве по защите веб-API с помощью платформы удостоверений Майкрософт скачайте и запустите пример кода, демонстрирующий защиту веб-API ASP.NET.
• В этом руководстве описано, как преобразовать и защитить API в службе управления API Azure, узнайте о настройке распространенных политик для скрытия сведений о стеке технологий и исходных URL-адресов в тексте ответа HTTP API.
• Рекомендации по авторизации помогут реализовать лучшие модели авторизации, разрешения и согласия для приложений.