Делеговані та застосункові дозволи в Microsoft Entra ID: що потрібно знати адміністраторам

By Mirko Peters · 2026-10-28

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

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

Інтегруючи сторонні інструменти або власні застосунки в середовище Microsoft 365, важливо розуміти різницю між делегованими та застосунковими дозволами. Це необхідно для захисту хмарної інфраструктури, запобігання витокам даних і дотримання принципу найменших привілеїв у Microsoft Entra ID.

Головне

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

Розуміння OAuth-дозволів у хмарі Microsoft

Коли ви підключаєте зовнішній інструмент продуктивності або внутрішній скрипт автоматизації до свого робочого простору Microsoft 365, запускається базовий процес OAuth 2.0. Однак отримати токен доступу — лише половина справи. Справжню межу безпеки визначає те, що цей токен насправді може робити. В екосистемі ідентичності Microsoft, яка базується на Microsoft Entra ID (раніше Azure Active Directory), дозволи поділяються на два принципово різні типи: делеговані дозволи та застосункові дозволи.

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

Делеговані дозволи: дія від імені користувача

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

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

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

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

Застосункові дозволи: фонові служби та доступ на рівні всього клієнта

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

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

Чому адміністративна згода є обов’язковою

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

Microsoft Graph і роль областей дії OAuth

Незалежно від того, використовує застосунок делеговані чи дозволи для застосунків, зрештою він спрямовує свої запити через єдиний потужний шлюз: Microsoft Graph. За Microsoft Graph доступні всі чати команд, документи SharePoint, файли OneDrive і листи Outlook, якщо застосунок, що робить запит, пред’являє дійсний токен доступу OAuth.

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

Дотримання принципу найменших привілеїв у вашому клієнті

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

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

Висновок

Щоб розібратися в механіці сучасної хмарної ідентичності, потрібно дивитися повз прості кнопки входу і вивчати лежачі в основі структури дозволів. Чи ви керуєте мобільними застосунками для користувачів з делегованими областями дії, чи складними корпоративними автоматизаціями, що покладаються на дозволи для застосунків, розуміння цих меж є необхідним для безпечного середовища Microsoft 365.

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

Поширені запитання

Чи можуть звичайні користувачі надавати згоду на дозволи для застосунків у Microsoft Entra ID?

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

Що станеться, якщо користувач намагається отримати доступ до файлу через застосунок із делегованими дозволами, на які він не має прав?

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

Який основний ризик безпеки дозволів для застосунків?

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

Як Microsoft Graph взаємодіє з токенами OAuth і дозволами?

Microsoft Graph є шлюзом API для Microsoft 365. Кожен запит до Graph повинен містити токен доступу OAuth, у якому вбудовано певні області дії, що визначають делеговані або програмні дозволи.