Делегированные и прикладные разрешения: выбираем модель для вашего приложения

By Mirko Peters · 2026-08-11

Добро пожаловать обратно в подкаст и в нашу серию, которая помогает освоить Microsoft 365, Azure и инструменты разработчика, на которых держится современная облачная экосистема. Если вы когда-либо создавали интеграцию, писали скрипт или внедряли корпоративную автоматизацию с помощью Microsoft Graph API, то наверняка уже упирались в стену разрешений. Защитить клиент и одновременно создать работающи

Automatically translated with AI from the original post. Read the English original

Добро пожаловать обратно в подкаст и в нашу серию, которая помогает освоить Microsoft 365, Azure и инструменты разработчика, на которых держится современная облачная экосистема. Если вы когда-либо создавали интеграцию, писали скрипт или внедряли корпоративную автоматизацию с помощью Microsoft Graph API, то наверняка уже упирались в стену разрешений. Защита клиента при создании функциональных приложений — один из самых важных балансов, с которым вы столкнетесь как администратор или разработчик. Выбор между разными моделями разрешений напрямую влияет на ваш уровень безопасности, скорость развертывания и общую архитектуру системы.

Чтобы глубже разобрать эту тему, недавно мы записали подробный выпуск. Обязательно послушайте полное аудиообсуждение по ссылке Microsoft Graph Permissions and Consent Models Explained. В этом сопроводительном посте мы раскроем эти концепции: разберем ключевые различия между делегированными и прикладными разрешениями, рассмотрим модели согласия, изучим лучшие практики и предложим комплексную схему, которая поможет сохранить безопасность и соответствие требованиям ваших приложений.

Обзор разрешений Microsoft Graph API

Прежде чем переходить к нюансам конкретных сценариев авторизации, полезно понять, что такое разрешения Microsoft Graph API. По сути, Microsoft Graph выступает единым шлюзом к данным, хранящимся в сервисах Microsoft 365, включая Exchange Online, SharePoint, Microsoft Teams, OneDrive и Azure Active Directory (Microsoft Entra ID). Вместо того чтобы заставлять разработчиков проходить аутентификацию в нескольких изолированных конечных точках, Microsoft Graph предоставляет одну конечную точку REST API. Однако, поскольку этот API открывает доступ практически ко всем уголкам цифровой среды организации, для его защиты требуется надежная и детализированная система разрешений.

Делегированные и прикладные разрешения

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

Делегированные разрешения предназначены для клиентских приложений с пользовательским интерфейсом, например одностраничных веб-приложений, мобильных приложений или настольных утилит, где пользователь, выполнивший вход, активно присутствует. В этой модели ваше приложение действует *от имени* пользователя. Оно может получать доступ только к данным и выполнять только те действия, на которые у самого пользователя есть права. Когда пользователь запускает приложение, ему предлагается войти и явно предоставить согласие, в результате чего выдается маркер доступа OAuth 2.0, содержащий и идентификатор пользователя, и согласованные области доступа.

Прикладные разрешения, напротив, используются фоновыми службами, демонами, веб-заданиями и автоматизированными runbook-сценариями, которые работают независимо от контекста какого-либо пользователя. Здесь приложение действует под собственной идентификацией. Для получения маркера доступа только для приложения из Azure AD оно использует учетные данные клиента, например клиентский секрет, пару сертификатов «открытый/закрытый ключ» или управляемое удостоверение. Поскольку за клавиатурой не сидит человек, который прошел бы аутентификацию, эти разрешения распространяются на ресурсы всего клиента. Поэтому они несут значительно более высокие риски для безопасности и всегда требуют явного согласия администратора клиента.

Ключевые различия и сценарии использования

Понимание того, когда применять каждую модель разрешений, помогает избежать архитектурных узких мест и уязвимостей безопасности. Давайте посмотрим на краткое сравнение:

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

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

Делегированные разрешения в Microsoft Graph

Как работают делегированные разрешения

Делегированный доступ тесно связан с идентификацией пользователя. Когда ваше приложение запрашивает делегированное разрешение, оно по сути просит сервер авторизации разрешить ему действовать от имени вошедшего пользователя в заданных границах. Токен доступа, который возвращается в потоке OAuth с кодом авторизации, содержит определённые утверждения областей (scope claims), отражающие как собственные права пользователя, так и разрешения, запрошенные приложением.

• Делегированный доступ означает, что ваше приложение действует напрямую от имени пользователя.
• И регистрация приложения, и сам пользователь должны обладать соответствующими базовыми правами.
• Области (scopes) задают точный предел того, что ваше приложение может делать от имени пользователя.
• Полученный токен доступа объединяет идентификацию приложения и контекст пользователя.

Типичные сценарии использования делегированных разрешений

Делегированные разрешения лежат в основе большинства повседневных интеграций для повышения продуктивности. Например, если корпоративное приложение для заметок должно синхронизировать файлы с OneDrive пользователя, оно запрашивает область Files.ReadWrite. Если у пользователя нет прав на доступ к конкретному документу, Graph API отклонит запрос, даже если область приложения технически это позволяет. Аналогично, приложения, использующие Microsoft Graph SDK для отправки автоматических уведомлений по электронной почте от имени пользователя, опираются на делегированные области вроде Mail.Send.

Безопасность и соображения, связанные с согласием

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

Разрешения приложения в Microsoft Graph

Как работают разрешения приложения

Разрешения приложения исключают человека из процесса аутентификации. Вместо взаимодействия с окном входа приложение проходит аутентификацию непосредственно в Microsoft Entra ID с помощью учётных данных клиента. Полученный токен содержит роли приложения, а не делегированные области, и предоставляет субъекту-службе (service principal) широкий, неограниченный доступ к ресурсам всего клиента.

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

Когда использовать разрешения приложения

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

Согласие администратора и последствия для безопасности

Поскольку разрешения приложения обходят ограничения отдельных пользователей и дают доступ на уровне всего клиента, обычные пользователи не могут дать согласие на них. Предоставить согласие на разрешения приложения может только привилегированный администратор. Неправильно настроенные разрешения приложения, например выдача Directory.ReadWrite.All или Mail.ReadWrite.All ненадёжному или плохо написанному фоновому приложению, могут оставить весь клиент Microsoft 365 уязвимым для полной компрометации. Регулярно проверяйте субъекты-службы корпоративных приложений.

Плюсы и минусы разрешений Microsoft Graph API

Плюсы

• Единая модель разрешений: единая, последовательная система авторизации для всех служб Microsoft 365 упрощает администрирование.
• Гранулярные области: детальные делегированные и прикладные области позволяют строить точные архитектуры с принципом наименьших привилегий.
• Стандартный OAuth2/OpenID Connect: использование отраслевых протоколов безопасности упрощает интеграцию идентификации.
• Интеграция с RBAC: Бесшовно подключается к ролям Azure AD и политикам условного доступа для централизованного соответствия требованиям.
• Инкрементальное согласие: Позволяет приложениям запрашивать дополнительные разрешения постепенно, а не требовать всё сразу.

Недостатки

• Сложность: Разобраться в сочетании делегированных областей, ролей приложений и моделей согласия администратора может быть непросто для новичков.
• Риски высоких привилегий: Неправильная настройка широких разрешений (например, Sites.FullControl.All) может открыть доступ к огромным объёмам корпоративных данных.
• Узкие места в согласовании администратором: Требование одобрения администратора для разрешений с серьёзным влиянием может замедлить гибкие циклы разработки.
• Фрагментация документации: Разработчикам часто приходится сверяться с несколькими репозиториями документации Microsoft, чтобы понять точное поведение API.

Модели согласия и лучшие практики

Пользователь или администратор: согласие в Microsoft Graph

Управление тем, как получается согласие, критически важно для корпоративного управления. Согласие пользователя позволяет отдельным людям разрешать приложениям доступ к их личным данным. Согласие администратора переносит точку одобрения на ИT-администраторов, которые оценивают запросы приложений от имени всей организации. Современные базовые конфигурации безопасности предприятий часто полностью отключают согласие пользователей, и все подключения приложений проходят через формализованный процесс предварительного одобрения администратором.

Влияние политик клиента на разрешения

Корпоративные политики клиента могут существенно изменить поведение вашего приложения во время выполнения. Если администратор включил строгие политики условного доступа, например требование многофакторной аутентификации (MFA) или совместимых гибридных устройств, присоединённых к Azure AD, приложение, которое запрашивает токен Graph без соблюдения этих условий, будет заблокировано. Разработчики должны проектировать приложения так, чтобы корректно обрабатывать сбои получения токенов и выводить понятные инструкции по устранению ошибок.

Стратегии для бесперебойного процесса согласия

Чтобы избежать неудобств для пользователей и препятствий со стороны администраторов, продумайте стратегию разрешений до написания кода. Реализуйте шаблоны инкрементального согласия: приложение запрашивает базовые области идентификации сразу, а специализированные разрешения к ресурсам запрашивает только тогда, когда пользователь переходит к соответствующим функциям. Используйте автоматизированные процессы предварительного одобрения в Microsoft Entra ID, чтобы ускорить разработку и сохранить строгий контроль безопасности.

Распространённые ошибки в разрешениях Microsoft Graph API

• Путаница между делегированными разрешениями и разрешениями приложения, а также непонимание требований к контексту пользователя.
• Запрос избыточных разрешений сразу, вместо подхода с минимальными привилегиями.
• Игнорирование требований согласия администратора при развёртывании фоновых служб.
• Предположение, что изменения разрешений в портале Azure вступают в силу мгновенно, без обновления токенов.
• Использование делегированного токена доступа там, где требуется токен client credentials.
• Игнорирование политик условного доступа, которые блокируют запросы к Graph API во время выполнения.
• Отсутствие проверки утверждений области (scope claims) в коде приложения во время выполнения.
• Отсутствие регулярного аудита выданных разрешений приложений и субъектов-служб.

Контрольный список разрешений Microsoft Graph API

Используйте этот практический контрольный список, чтобы безопасно проектировать, внедрять и проверять разрешения Microsoft Graph API в вашей команде:

Заключение

Разобраться в разрешениях Microsoft Graph API не обязательно должно быть мучительным. Понимая операционные различия между делегированными разрешениями (которые требуют вошедшего пользователя и работают в рамках его ограничений) и разрешениями приложения (которые работают в фоне без ограничений и требуют согласия администратора), вы сможете спроектировать безопасные и масштабируемые решения. Соблюдение принципа наименьших привилегий, строгий аудит и использование инструментов корпоративного управления помогут сохранить безопасность вашей среды Microsoft 365 без замедления инноваций.

Для более глубоких экспертных рекомендаций, практических стратегий и разбора безопасности облачной среды послушайте полную аудиоверсию по теме связанного эпизода: Microsoft Graph Permissions and Consent Models Explained. Держите разрешения под строгим контролем, учётные данные в безопасности и удачной разработки!