Делегированные и application-разрешения

By Mirko Peters · 2026-04-26 · Updated 2026-07-18

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

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

Когда вы работаете с Microsoft Entra ID, понимание того, кто может что делать и при каких условиях, — это не техническая мелочь. Это основа безопасной разработки приложений, автоматизации и управления идентификацией в облаке Microsoft. Есть огромная разница между тем, чтобы позволить пользователям выдать приложению ровно столько доступа, сколько нужно для действий от их имени (делегированные разрешения), и тем, чтобы дать приложению ключи для самостоятельной работы (application-разрешения).

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

Введение и предыстория моделей разрешений в Microsoft Identity

Разрешения в Microsoft Entra ID — это не просто галочки, которые вы ставите. Это фундаментальная система, встроенная в то, как приложения и пользователи взаимодействуют в Microsoft 365, Azure и не только. Когда Microsoft перевела идентификацию в облако, ей понадобился способ, чтобы сервисы и сторонние инструменты взаимодействовали безопасно, без предоставления всем и всего полного доступа. Так появились делегированные и application-разрешения.

Эти модели позволяют точно управлять тем, кто к чему имеет доступ, и чётко разграничивают то, что отдельный пользователь может одобрить, и то, что может разрешить только администратор. Они появились в результате многолетнего опыта (иногда горького) с классическими сервисными учётными записями AD и громоздким доступом «всё или ничего». Понимание этих моделей — не просто хорошая гигиена. Это критически важно для соблюдения требований, внедрения Zero Trust и того, чтобы ежедневная работа не остановилась из-за ошибок настройки безопасности.

Application-разрешения и делегированные разрешения: основные концепции и сценарии из реальной жизни

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

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

При application-разрешениях приложение аутентифицируется под собственной идентичностью (субъект-служба, service principal) и получает собственный токен. Именно это обеспечивает автоматизацию и фоновые задачи, например интеграцию, которая ночью синхронизирует данные между SharePoint и вашей CRM. Участие пользователя не требуется: приложение выполняет задачи по своему расписанию и на своём уровне доступа, который определяется тем, что одобрит администратор.

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

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

Внутреннее устройство делегированных разрешений Microsoft Entra: поток аутентификации и ограничения

Делегированные разрешения в Microsoft Entra ID реализуют классический сценарий аутентификации, управляемый пользователем. Он начинается, когда пользователь входит в ваше приложение, используя свои учётные данные Microsoft. В этот момент приложение запрашивает конкретные разрешения (или области доступа — scopes), показывая пользователю (а иногда и администратору), к каким данным или действиям оно хочет получить доступ.

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

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

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

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

Избыточные разрешения приложений и безопасность токенов в Microsoft Entra ID

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

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

Разговор не ограничивается избыточными разрешениями. Токены и учётные данные, включая клиентские секреты и сертификаты, становятся золотой жилой для атакующих, если их не защитить. Утёкшего клиентского секрета приложения с регистрацией только для приложения достаточно, чтобы выдать себя за ваш сервис. Поэтому гигиена учётных данных обязательна: по возможности используйте управляемые удостоверения, регулярно меняйте секреты и никогда не храните клиентские учётные данные в коде или в незащищённых файлах. Для сред, которым нужен доступ не-людей, рассмотрите Microsoft Entra Workload Identities: они обеспечивают доступ без секретов, который можно аудировать, и избавляют от головной боли, связанной с устаревшими служебными учётными записями. Более подробно о том, почему workload identities необходимы для Zero Trust, читайте здесь.

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

Средства контроля и лучшие практики управления делегированными разрешениями и разрешениями приложений

• Внедрите встроенные средства Entra для управления разрешениямиИспользуйте встроенные в Microsoft Entra процессы согласия, процессы одобрения администратором и детализированные политики, чтобы ограничить, какие пользователи или группы могут предоставлять разрешения. Применяйте политики согласия администратора, чтобы высокорисковые области доступа получали только проверенные приложения.
• Соблюдайте принцип наименьших привилегийПредоставляйте приложениям только минимальный набор разрешений, необходимый для их функций. Проверяйте каждое разрешение, запрашиваемое при регистрации приложения, и удаляйте всё лишнее. Принцип наименьших привилегий – ваша главная защита от злоупотреблений и избыточного доступа.
• Регулярно проводите проверки разрешений и аудитНастройте плановые проверки доступа с помощью панелей разрешений и согласий Entra, чтобы находить и отзывать неиспользуемые или рискованные разрешения. По возможности автоматизируйте эти проверки для масштабируемого управления – как описано в руководствах по продвинутому управлению, например в этой стратегии Microsoft Purview.
• Отслеживайте изменения разрешений и настройте оповещенияНастройте мониторинг и оповещения, чтобы замечать новые выдачи OAuth, всплески использования разрешений приложений или неожиданные интеграции с администраторскими функциями. Проактивная отчётность даёт время отреагировать до того, как проблемы безопасности усугубятся.
• Защищайте хранение токенов и учётных данныхХраните клиентские секреты и токены в защищённых хранилищах, например в Azure Key Vault. Регулярно меняйте учётные данные, используйте сертификаты вместо общих секретов и отдавайте предпочтение рабочим удостоверениям (workload identities) для интеграций, не связанных с пользователями, так как они обеспечивают лучшее управление жизненным циклом и аудит.
• Внедряйте продвинутое управление и автоматизацию политикИспользуйте такие инструменты, как Microsoft Purview и Azure Policy, чтобы применять средства контроля на уровне всего клиента, сегментировать риски с помощью Data Loss Prevention и проектировать систему для непрерывного соответствия требованиям. Практический взгляд на использование политик для управления «по умолчанию» см. в статье о стратегии управления Azure для предприятий.

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

Вам также стоит послушать

Если вы изучаете делегированные и application-разрешения в Entra ID, эти выпуски добавят практического контекста для безопасного внедрения Microsoft 365, защиты данных, управления и управления рисками ИИ.

• Microsoft Purview – Simply Explained — Как классификация, хранение, соответствие требованиям и защита вписываются в единую модель управления данными Microsoft.
• Microsoft Defender XDR – Simply Explained — Как связать средства защиты данных с обнаружением, расследованием и реагированием.
• Conditional Access – Simply Explained — Как сигналы идентичности и риска добавляют контекст к решениям о доступе.
• Microsoft AI Agent Harness – Simply Explained — Какие средства контроля делают автоматизацию ИИ надёжнее, наблюдаемее и безопаснее.

Эти выпуски помогут превратить идеи статьи в практические решения по проектированию и внедрению.