Делеговані та застосункові дозволи: вибір правильної моделі для вашого застосунку

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, що містить як ідентичність користувача, так і погоджені області (scopes).

Застосункові дозволи, навпаки, використовуються фоновими службами, демонами, веб-завданнями та автоматизованими runbook-сценаріями, які працюють незалежно від контексту будь-якого користувача. Тут застосунок працює під власною ідентичністю. Він використовує облікові дані клієнта — наприклад, клієнтський секрет, пару відкритого та закритого ключів сертифіката або керовану ідентичність — щоб отримати з Azure AD токен доступу лише для застосунку. Оскільки за клавіатурою немає людини, яка б автентифікувалася, ці дозволи поширюються на ресурси всього клієнта. Тому вони несуть значно вищі ризики для безпеки та завжди потребують явної згоди адміністратора клієнта.

Ключові відмінності та сценарії використання

Розуміння того, коли застосовувати кожну модель дозволів, дозволяє уникнути архітектурних вузьких місць і вразливостей безпеки. Ось короткий порівняльний огляд:

• Делеговані дозволи: застосунок працює від імені користувача. Користувач має увійти в систему та надати згоду. Застосунок може бачити лише те, що бачить користувач. Ця модель ідеально підходить для клієнтських застосунків, які читають або змінюють персональні дані, як-от окремі календарі чи електронні листи.
• Застосункові дозволи: застосунок працює як самостійна сутність. Жодному користувачеві входити в систему не потрібно. Згоду має надати адміністратор. Застосунок може переглядати та змінювати дані в межах усього клієнта. Ця модель ідеально підходить для фонової синхронізації, адміністративної звітності та автоматизованих завдань управління.

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

Делеговані дозволи в Microsoft Graph

Як працюють делеговані дозволи

Делегований доступ тісно пов’язаний з ідентичністю користувача. Коли ваш застосунок запитує делегований дозвіл, він по суті просить сервер авторизації дозволити йому діяти від імені користувача, який увійшов у систему, в межах визначених обмежень. Токен доступу, отриманий через потік авторизації OAuth з кодом авторизації, містить конкретні заявки області дії, які відображають як власні права користувача, так і дозволи, запитані застосунком.

• Делегований доступ означає, що ваш застосунок діє безпосередньо від імені користувача.
• І реєстрація застосунку, і окремий користувач мають мати відповідні базові права.
• Області дії визначають точну межу того, що ваш застосунок може робити від імені користувача.
• Отриманий токен доступу поєднує ідентичність застосунку та контекст користувача.

Поширені сценарії використання делегованих дозволів

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

Безпека та міркування щодо згоди

Хоча делеговані дозволи за своєю природою безпечніші за загальнооргановані дозволи застосунку, оскільки їх обмежують права користувача, вони все ж створюють specific проблеми безпеки. Якщо застосунок запитує надто широкі області дії, наприклад повний доступ до всієї поштової скриньки та профілю каталогу користувача, успішна фішингова атака або компрометація застосунку може призвести до витоку чутливих персональних даних. Розробники мають суворо дотримуватися принципу найменших привілеїв, запитуючи лише ті області дії, які необхідні для поточної функціональності.

Дозволи застосунку в Microsoft Graph

Як працюють дозволи застосунку

Дозволи застосунку виключають людину з процесу автентифікації. Замість взаємодії із запитом на вхід застосунок автентифікується безпосередньо в Microsoft Entra ID за допомогою облікових даних клієнта. Отриманий токен містить ролі застосунку, а не делеговані області дії, що надає субʼєкту служби широкий, необмежений доступ до ресурсів у всьому клієнті.

• Дозволи застосунку працюють повністю без користувача, який увійшов у систему.
• Застосунок отримує токен лише для застосунку, щоб запитувати ресурси.
• Доступ визначається ролями застосунку, призначеними субʼєкту служби, а не привілеями окремих користувачів.

Коли використовувати дозволи застосунку

Дозволи застосунку варто суворо обмежувати серверними робочими навантаженнями, фоновими демонами без участі користувача та інтеграціями між системами. Прикладами є рушії автоматизованого надання користувачів, централізовані системи резервного копіювання, інструменти реагування на інциденти безпеки та скрипти міграції клієнта.

Згода адміністратора та наслідки для безпеки

Оскільки дозволи застосунку обходять обмеження окремих користувачів і надають доступ на рівні всього клієнта, звичайні користувачі не можуть надавати на них згоду. Надати згоду на дозволи застосунку може лише адміністратор із привілеями. Неправильно налаштовані дозволи застосунку, наприклад надання 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

Керування тим, як отримується згода, є критично важливим для корпоративного управління. Згода користувача дає окремим особам змогу авторизувати застосунки для доступу до їхніх особистих даних. Згода адміністратора переносить етап погодження до ІТ-адміністраторів, які оцінюють запити застосунків від імені всієї організації. Сучасні базові корпоративні політики безпеки часто повністю вимикають згоду користувача, тож усе підключення застосунків відбувається через формалізовані процеси попереднього погодження адміністратором.

Вплив політик клієнта на дозволи

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

Стратегії плавного процесу згоди

Щоб уникнути незручностей для користувачів і адміністративних перешкод, сплануйте стратегію дозволів до написання коду. Впроваджуйте шаблони поступової згоди: ваш застосунок запитує базові області ідентифікації одразу, а спеціалізовані дозволи ресурсів — лише тоді, коли користувач переходить до відповідних функцій. Використовуйте автоматизовані процеси попереднього схвалення в Microsoft Entra ID, щоб прискорити розробку й водночас зберігати суворий контроль безпеки.

Поширені помилки щодо дозволів Microsoft Graph API

• Плутанина між делегованими дозволами та дозволами застосунку, а також нерозуміння вимог до контексту користувача.
• Запит надмірних дозволів одразу замість дотримання принципу найменших привілеїв.
• Ігнорування вимог згоди адміністратора під час розгортання фонових служб.
• Припущення, що зміни дозволів у порталі Azure миттєво набувають чинності без оновлення токена.
• Використання токена делегованого доступу там, де потрібен токен облікових даних клієнта.
• Ігнорування політик умовного доступу, які блокують запити Graph API під час виконання.
• Нехтування перевіркою декларацій областей дії в коді застосунку під час виконання.
• Відсутність аудиту наданих дозволів застосунків і субʼєктів служби з плином часу.

Контрольний список дозволів Microsoft Graph API

Скористайтеся цим практичним контрольним списком, щоб допомогти команді безпечно проєктувати, впроваджувати та перевіряти дозволи Microsoft Graph API:

Висновок

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

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