Розбираємо прогалину в згоді Microsoft Graph: про що не пишуть навчальні посібники

By Mirko Peters · 2026-08-11

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

Titelbild: Mastering the Microsoft Graph Consent Gap: What Tutorials Leave Out

Ласкаво просимо до супровідного посібника до подкасту! Якщо ви колись налаштовували фонову задачу, натискали адміністративну згоду і сподівалися на краще, то ви точно не самотні. Багато розробників і адміністраторів проходять стандартні навчальні посібники, налаштовують фонові сервіси і припускають, що після запуску коду питання безпеки вже вирішено. Однак між тим, щоб інтеграція працювала в тестовому середовищі, і тим, щоб вона залишалася безпечною, надійною та придатною для аудиту у продуктивному середовищі, існує величезна прогалина. У цьому дописі ми детально розглядаємо приховані ризики доступу лише для застосунку, коли дозволи діють у межах усього клієнта без контексту користувача, чому одноразова згода може довго впливати на вашу безпеку і як зміни політик можуть непомітно зламати фонові задачі без нагляду. Щоб заглибитися в тему ще більше, обов’язково послухайте пов’язаний епізод подкасту Microsoft Graph App-Only Consent Explained.

Для кого цей матеріал

Адміністратори Azure AD / Entra ID та інженери з безпеки
Власники платформи M365 та адміністратори SharePoint, Exchange і Teams
Розробники, які створюють безнаглядні сервіси, Azure Functions, Logic Apps або інтеграції
Команди з відповідності вимогам, аудиту та управління

Прогалина в згоді (чого пропускають навчальні посібники)

Делеговані дозволи проти дозволів застосунку: у режимі лише для застосунку немає контексту користувача, а після надання згоди області видимості діють у межах усього клієнта.
Одноразова згода, довгостроковий вплив: широкі ролі (наприклад, Sites.ReadWrite.All) діють доти, доки їх явно не відкличуть.
Зміни політик ламають застосунки: налаштування згоди або зміни умовного доступу можуть непомітно зупинити отримання токенів.
Видимість для аудиту слабка, якщо ви свідомо не журналюєте та не перевіряєте дозволи корпоративних застосунків.

Спочатку найменші привілеї (вибір дозволів)

Де це можливо, віддавайте перевагу вузьким областям ресурсів замість *.ReadWrite.All.
Приклади, які варто ретельно перевірити:
- Каталог: спочатку розгляньте User.Read.All (базовий профіль), а не Directory.Read.All.
- SharePoint: спробуйте шаблони доступу в межах окремого сайту або каталоги застосунків замість Sites.ReadWrite.All.
- Пошта та календарі: використовуйте Mail.Read і Calendars.Read, якщо запис справді не потрібен.
Ніякого «захисту на майбутнє» через надмірні області. Додавайте області лише тоді, коли цього вимагає функція.

Правильна реєстрація застосунку (покроково)

Зареєструйте застосунок у Entra ID → збережіть ідентифікатор застосунку (клієнта) та ідентифікатор клієнта.
Автентифікація: оберіть метод облікових даних клієнта:
- Сертифікат (рекомендовано), що зберігається й оновлюється через Key Vault, або
- Секрет клієнта (короткий термін дії та політика ротації), або
- Керована ідентичність (найкраще для навантажень, розміщених в Azure).
Дозволи API → вкладка Application → додавайте лише мінімальні області Graph.
Надавайте адміністративну згоду свідомо (документуйте, хто, чому і коли).
Корпоративні застосунки: обмежте обов’язкове призначення, власників, а також журналювання входів і аудиту.

Адміністративна згода, політики та засоби контролю

Лише привілейовані адміністратори можуть надавати дозволи застосунку.
Розглядайте адміністративну згоду як прийняття ризику: фіксуйте мету, дані, яких торкається, і дату завершення дії або поновлення.
Узгодьте з обмеженнями клієнта, політиками надання дозволів та умовним доступом для субʼєктів-служб.

Токени на практиці (як насправді відмовляє автентифікація)

Типові збої: прострочені секрети або сертифікати, неправильний ресурс (область .default), відсутня роль, невідповідність клієнта.
Зміцніть потік токенів:
- Використовуйте облікові дані на основі сертифікатів або керовану ідентичність замість довготривалих секретів.
- Оновлюйте секрети та сертифікати задовго до закінчення терміну дії (нагадування в Key Vault і автоматизація).
- Повторюйте спроби з експоненційною затримкою і відстежуйте телеметрію 401/403 з ідентифікаторами кореляції.
- Кешуйте токени в межах одного запуску, але ніколи не між клієнтами і не довше безпечного терміну дії.

Моніторинг і аудит (готовність до аудиту)

Панелі моніторингу та сповіщення для: збоїв токенів, змін згоди, нових доданих дозволів і неактивних застосунків.
Квартальні перегляди: складіть перелік корпоративних застосунків, їхніх дозволів і міток часу останнього використання; видаліть застарілі реєстрації.
Журнал: хто надав згоду, дата й час, обґрунтування та які категорії даних зачіпає.
Key Vault: увімкніть сповіщення про закінчення терміну дії облікових даних і, де це можливо, автоматичне оновлення сертифікатів.

Мінімальні шаблони дозволів (стартова матриця)

Інвентаризація користувачів і звітність → User.Read.All
Аналітика використання Teams → Reports.Read.All
Експорт поштових скриньок лише для читання → Mail.Read
Синхронізація календарів (читання) → Calendars.Read
Широкий доступ на читання до SharePoint → Sites.Read.All (уникайте ReadWrite, якщо це не є обов’язковим)
Синхронізація профілів із HR → User.Read.All (+ конкретні області запису лише за справжньої потреби)

Практичне правило: якщо область закінчується на .ReadWrite.All, зупиніться і переоцініть потребу. Якщо без неї не обійтися, ізолюйте застосунок, задокументуйте обґрунтування та додайте додатковий моніторинг.

Типові помилки та швидкі виправлення

invalid_client / invalid_grant → прострочений секрет або сертифікат; оновіть їх у Key Vault і повторно розгорніть застосунок.
insufficient privileges to complete the operation → відсутній дозвіл рівня застосунку або не надано згоду адміністратора в цьому клієнті.
Помилка 403 у SharePoint для застосунку лише з дозволами застосунку → область надто широка або доступ на рівні сайту не узгоджено; перевірте дозволи сайту та підхід через каталог застосунків.
Періодичні помилки 401 → зміна політики умовного доступу або згоди; перевірте журнали входу та аудиту для службового принципалу.

Гарантії безпеки та відповідності

Розподіл обов’язків: різні відповідальні за реєстрацію застосунків, схвалення згоди та експлуатацію.
Позначайте корпоративні застосунки класифікацією даних (наприклад, мають доступ до даних HR, фінансів, PHI).
PIM для тих, хто надає згоду; для нових областей вимагайте тикет або запис про зміну.
Видаляйте невикористовувані застосунки та вимикайте застарілі кінцеві точки автентифікації.
Документуйте потоки даних для кожного застосунку; ведіть односторінковий запис на кожну інтеграцію.

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

Чи успадковують дозволи лише для застосунку ACL користувачів? Ні, дозволи лише для застосунку діють незалежно від контексту користувача.
Чи може звичайний користувач надати області лише для застосунку? Ні, потрібна згода адміністратора.
Чи анулюються токени разом із відкликанням доступу? Токени швидко спливають, але надані дозволи зберігаються, доки їх не відкликано.
Який спосіб автентифікації найкращий? Керована ідентичність (в Azure) або сертифікати + Key Vault; уникайте довгоживучих секретів.

План дій (спринт зміцнення безпеки на 90 хвилин)

Проінвентаризуйте корпоративні застосунки та дозволи застосунків Graph.
Позначте застосунки з *.ReadWrite.All і Directory.* для перегляду.
Оновіть кожен секрет, що спливає менш ніж за 30 днів; де можливо, перейдіть на сертифікат або керовану ідентичність.
Увімкніть сповіщення про зміни згоди та про закінчення терміну дії в Key Vault.
Складіть односторінковий опис для кожного застосунку: призначення, дані, що обробляються, області, власник, дата оновлення.
Призначте квартальний перегляд разом із SecOps і власниками застосунків.

Висновок

Захист інтеграцій із Microsoft Graph — це не одноразове налаштування. Розуміючи справжні наслідки розриву в згоді, застосовуючи шаблони дозволів за принципом найменших привілеїв, відмовляючись від крихких клієнтських секретів і налагоджуючи ретельний моніторинг, ви можете суттєво підвищити рівень безпеки свого клієнта. Не залишайте фонові завдання вразливими до непомітних збоїв і невідконтрольованого розширення доступу. Знайдіть час сьогодні, щоб пройти наш 90-хвилинний спринт зміцнення безпеки та провести аудит корпоративних застосунків. Для повного розбору цих концепцій і глибшого обговорення доступу лише для застосунків обов’язково послухайте відповідний епізод подкасту: Microsoft Graph App-Only Consent Explained.