Делегированные и application-разрешения в Microsoft Entra ID: что нужно знать администраторам

By Mirko Peters · 2026-10-28

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

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

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

Главное

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

Разрешения OAuth в облаке Microsoft

Когда вы подключаете внешний инструмент для продуктивности или внутренний скрипт автоматизации к своему рабочему пространству Microsoft 365, запускается процесс OAuth 2.0. Однако получить токен доступа — это только половина дела. Реальная граница безопасности определяется тем, что этому токену фактически разрешено делать. В экосистеме идентификации Microsoft, основой которой является Microsoft Entra ID (ранее Azure Active Directory), разрешения делятся на два принципиально разных типа: делегированные разрешения и application-разрешения.

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

Делегированные разрешения: действия от имени пользователя

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

В этом сценарии приложение действует от вашего имени. Оно может получить доступ только к тем данным, к которым у вас уже есть разрешение, и ни к чему больше. Если у вашей учётной записи нет права чтения конкретной папки SharePoint или календаря коллеги, приложение тоже не получит к ним доступ. Поскольку зона возможного ущерба естественно ограничена разрешениями отдельного пользователя, Microsoft рекомендует использовать делегированные разрешения всякий раз, когда в процессе участвует человек.

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

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

Application-разрешения: фоновые службы и доступ ко всему клиенту

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

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

Почему согласие администратора обязательно

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

Microsoft Graph и роль областей действия OAuth

Независимо от того, использует ли приложение делегированные или разрешения приложения, все его запросы в конечном счёте проходят через один мощный шлюз: Microsoft Graph. Каждый чат в Teams, каждый документ SharePoint, каждый файл OneDrive и каждое письмо Outlook доступны через Microsoft Graph, если вызывающее приложение предъявляет действительный токен доступа OAuth.

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

Соблюдение принципа наименьших привилегий в вашем клиенте

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

• Всегда отдавайте предпочтение делегированным разрешениям перед разрешениями приложений, когда приложением взаимодействует живой пользователь.
• Внимательно проверяйте запросы согласия, чтобы убедиться, что приложения не запрашивают лишние области действия.
• Регулярно просматривайте корпоративные приложения, зарегистрированные в Microsoft Entra ID, чтобы отзывать неиспользуемые токены и удалять неиспользуемые регистрации приложений.
• Обеспечивайте административный контроль над любым потоком client credentials, работающим в безголовых средах.

Заключение

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

Чтобы глубже разобраться в основах того, как работают эти процессы авторизации, послушайте полный выпуск подкаста: в нём без лишнего жаргона разбирается OAuth 2.0, жизненный цикл токенов и четыре участника каждого процесса авторизации.

Часто задаваемые вопросы

Могут ли обычные пользователи одобрять разрешения приложений в Microsoft Entra ID?

Нет. Разрешения приложений работают без вошедшего в систему пользователя и распространяются на весь клиент. Поэтому предоставлять разрешения приложений может только администратор с соответствующими правами в клиенте.

Что произойдёт, если пользователь попытается получить доступ к файлу через приложение с делегированными разрешениями, при этом у самого пользователя прав на этот файл нет?

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

Какой основной риск безопасности связан с разрешениями приложений?

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

Как Microsoft Graph взаимодействует с токенами OAuth и разрешениями?

Microsoft Graph выступает шлюзом API для Microsoft 365. Каждый запрос к Graph должен содержать маркер доступа OAuth, в котором встроены определённые области (scopes), задающие делегированные или прикладные разрешения.