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

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

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

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

Команда 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.Read.All и User.ReadWriteUser.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. В нем объясняется, как настроить маркеры для повышения гибкости и контроля при увеличении безопасности нулевого доверия приложений с минимальными привилегиями.
• Настройка утверждений групп и ролей приложений в маркерах показывает, как настроить приложения с определениями ролей приложения и назначить группы безопасности ролям приложений. Эти методы помогают повысить гибкость и контроль при увеличении безопасности нулевого доверия приложений с минимальными привилегиями.
• Запрос разрешений, требующих административного согласия , описывает разрешение и взаимодействие с согласием, когда разрешения приложений требуют административного согласия.
• В этом кратком руководстве. Защита веб-API с помощью платформа удостоверений Майкрософт скачайте и запустите пример кода, демонстрирующий защиту веб-API ASP.NET.
• В этом руководстве описано, как преобразовать и защитить API в Azure Управление API, узнайте о настройке общих политик для скрытия сведений о стеке технологий и исходных URL-адресов в тексте ответа HTTP API.
• Рекомендации по авторизации помогут реализовать лучшие модели авторизации, разрешения и согласия для приложений.