Делеговані та застосункові дозволи

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

Порівняйте делеговані та застосункові дозволи в Microsoft Entra ID і виберіть правильну модель доступу для захищених API, автоматизації та розробки застосунків.

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

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

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

Вступ до моделей дозволів у Microsoft Identity

Дозволи в Microsoft Entra ID — це не просто галочки, які ви ставите; це фундаментальна структура, вбудована в те, як застосунки та користувачі взаємодіють у Microsoft 365, Azure та не тільки. Коли Microsoft перенесла ідентичність у хмару, потрібен був спосіб, щоб служби та сторонні інструменти взаємодіяли безпечно, без того, щоб усім і всюди надавати повний доступ. Так з'явилися делеговані та застосункові дозволи.

Ці моделі дають змогу точно керувати тим, хто що може отримати доступ, і чітко розмежовують те, що окремий користувач може схвалити, і те, що має дозволяти лише адміністратор. Вони є результатом багатьох років досвіду (іноді здобутого важким шляхом) з класичними сервісними обліковими записами AD і незграбним доступом за принципом «все або нічого». Розуміння цих моделей — це не просто гарна практика: вони критично важливі для дотримання вимог відповідності, впровадження Zero Trust і того, щоб повсякденні операції не зупинялися через помилки конфігурації безпеки.

Застосункові та делеговані дозволи: основні концепції та реальні сценарії

Розберімо різницю між делегованими та застосунковими дозволами простими словами. Уявіть делеговані дозволи як помічника застосунку: він отримує доступ лише тоді, коли конкретний користувач увійшов у систему, і обмежений тим, що цей користувач може робити. Застосункові дозволи, натомість, дають змогу застосунку діяти самостійно, як менеджеру без нагляду, що має власний набір ключів. Присутність користувача для цього взагалі не потрібна.

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

За застосункових дозволів сам застосунок автентифікується як власна ідентичність (субʼєкт-служба) і отримує власний токен. Саме це забезпечує роботу автоматизації та фонових завдань, наприклад системної інтеграції, яка щоночі синхронізує дані між SharePoint і вашою CRM. Участь користувача не потрібна: застосунок виконує завдання за власним графіком і з власним рівнем доступу, який схвалює адміністратор.

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

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

Всередині делегованих дозволів Microsoft Entra: потік автентифікації та обмеження

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

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

Цей маркер доступу дозволяє застосунку викликати Microsoft Graph або API Microsoft 365, але діє він завжди з повноваженнями користувача. Тож якщо користувач є звичайним співробітником, застосунок не може раптом отримати адміністративні можливості. Щойно користувач виходить з системи, доступ застосунку припиняється, що обмежує радіус потенційної шкоди.

Але є обмеження: делеговані дозволи не працюють у сценаріях без участі людини. Якщо ви запускаєте фоновий процес, cron-завдання або інтеграцію служби, яка не має залежати від того, чи хтось активно входить в систему, делеговані дозволи не підходять. Вони прив'язують усе до присутності користувача, тож підтримка, автоматизація та нічні завдання рано чи пізно натикаються на стіну.

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

Надмірні дозволи для застосунків та безпека токенів у Microsoft Entra ID

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

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

Розмова не обмежується надмірними дозволами. Токени та облікові дані, зокрема клієнтські секрети й сертифікати, можуть стати золотою жилою для атакувальників, якщо їх не захистити. Для імітації вашої служби зловмиснику достатньо витеку клієнтського секрету з реєстрації застосунку, що працює без користувача. Тому гігієна облікових даних є обов'язковою: за можливості використовуйте керовані ідентичності, регулярно ротуйте секрети й ніколи не зберігайте облікові дані клієнта в коді або незахищених файлах. Для середовищ, які залежать від доступу не людей, розгляньте Microsoft Entra Workload Identities, що забезпечують доступ без секретів з можливістю аудиту та позбавляють від клопоту з унаслідуваними обліковими записами служб. Детальніше про те, чому робочі ідентичності є обов'язковими для Zero Trust.

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

Засоби контролю та найкращі практики керування делегованими дозволами та дозволами застосунків

• Застосуйте вбудовані засоби керування дозволами EntraВикористовуйте вбудовані в Microsoft Entra робочі процеси надання згоди, процеси затвердження адміністратором і детальні політики, щоб обмежити, які користувачі або групи можуть надавати дозволи. Скористайтеся політиками згоди адміністратора, щоб лише перевірені застосунки отримували області доступу високого ризику.
• Дотримуйтеся принципу найменших привілеївНадавайте застосункам лише мінімальний набір дозволів, необхідних для їхньої функції. Перевірте кожен дозвіл, який запитується під час реєстрації застосунку, і вилучіть усе зайве. Найменші привілеї — ваш найсильніший захист від зловживань і надмірного доступу.
• Плануйте регулярні перевірки дозволів і аудитиНалаштуйте планові перевірки доступу з використанням панелей дозволів і згоди Entra, щоб виявляти та відкликати невикористовувані або ризиковані дозволи. За можливості автоматизуйте ці перевірки для масштабованого управління, як описано в посібниках з просунутого управління, наприклад у цій стратегії Microsoft Purview.
• Відстежуйте зміни дозволів і налаштуйте сповіщенняНалаштуйте моніторинг і сповіщення, щоб виявляти нові надання OAuth, різке зростання використання дозволів застосунків або неочікувані інтеграції з адміністраторами. Проактивна звітність дає час відреагувати до того, як проблеми безпеки загостряться.
• Надійно зберігайте токени та облікові даніЗберігайте клієнтські секрети й токени в захищених сховищах, як-от Azure Key Vault. Регулярно оновлюйте облікові дані, використовуйте сертифікати замість спільних секретів і віддавайте перевагу робочим ідентичностям для неінтерактивного доступу, оскільки вони забезпечують кращe керування життєвим циклом і кращу здатність до аудиту.
• Впроваджуйте просунуте управління та автоматизацію політикВикористовуйте такі інструменти, як Microsoft Purview і Azure Policy, щоб застосовувати засоби керування на рівні всього клієнта, сегментувати ризики за допомогою Data Loss Prevention і проєктувати систему для безперервної відповідності вимогам. Практичний погляд на використання політик для управління «за задумом» дивіться у статті про стратегію корпоративного управління в Azure.

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

Вам також варто послухати

Якщо ви вивчаєте делеговані та застосункові дозволи в Entra ID, ці епізоди додадуть практичного контексту щодо безпечного впровадження Microsoft 365, захисту даних, управління та керування ризиками ШІ.

• Microsoft Purview – Simply Explained — Дізнайтеся, як класифікація, збереження, відповідність вимогам і захист вписуються в єдину модель управління даними Microsoft.
• Microsoft Defender XDR – Simply Explained — Поєднайте засоби захисту даних із виявленням, розслідуванням і реагуванням.
• Conditional Access – Simply Explained — Зрозумійте, як сигнали ідентичності та ризику додають контексту рішенням щодо доступу.
• Microsoft AI Agent Harness – Simply Explained — Ознайомтеся з засобами керування, які роблять автоматизацію на основі ШІ надійнішою, прозорішою та безпечнішою.

Ці епізоди допоможуть перетворити концепції статті на практичні рішення щодо проєктування та впровадження.