Масштабування: керування пагінацією, тротлінгом і аудитом великих клієнтів Microsoft 365

By Mirko Peters · 2026-08-11

Раді знову вітати вас у блозі! Якщо ви керуєте масштабним середовищем Microsoft 365, ви вже знаєте, що стандартні готові інструменти звітності лише ледь торкаються поверхні…

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

Titelbild: Scaling Up: Managing Pagination, Throttling, and Large Tenant M365 Audits

Ласкаво просимо назад до блогу! Якщо ви керуєте масштабним середовищем Microsoft 365, ви вже знаєте, що стандартні вбудовані інструменти звітності лише ковзають по поверхні. Коли команди безпеки та офіцери з відповідності дивляться на великі клієнти, базові скрипти та стандартні подання центру адміністрування просто не витримують навантаження з тисячами користувачів, груп і файлів. Аудит великих клієнтів M365 потребує більше, ніж базових скриптів: він вимагає тактичного, програмного підходу з використанням Microsoft Graph API. У цьому докладному посібнику ми продовжуємо нашу недавню розмову в епізоді подкасту «Map Microsoft 365 Users, Groups, Files, and Shares with Graph». Розберемо, як обробляти пагінацію @odata.nextLink, враховувати обмеження частоти 429 за допомогою експоненційної затримки та уникати поширених пасток, як-от Page 1 bias (упередженість щодо першої сторінки), щоб досягти повної видимості всього клієнта.

Вступ: виклики аудиту M365

Корпоративні середовища зростають органічно. Користувачі приходять і йдуть, проєкти за одну ніч створюють нові відділи, а зовнішні постачальники запрошуються до спільних просторів. З часом адміністративна видимість погіршується. Стандартні центри адміністрування показують лише ізольовані фрагменти вашої інфраструктури, залишаючи сліпі зони, якими можуть скористатися зловмисники або необережні внутрішні користувачі. Щоб отримати справжню картину безпеки вашого клієнта, потрібно перейти від ручного аудиту «клік за кліком» до автоматизованого обходу графа через API. Однак масштабування таких запитів до корпоративних розмірів породжує складні перешкоди: великі обсяги даних, агресивний тротлінг і глибоко вкладені реляційні структури.

Чому M365 не ізольований: розуміння реляційного доступу

Одна з фундаментальних особливостей Microsoft 365 полягає в тому, що такі служби, як SharePoint, Teams і OneDrive, не є ізольованими silo. Вони постійно взаємопроникають через членство в групах і базові списки контролю доступу. Одна адміністративна дія, наприклад додавання користувача до групи безпеки, може поширитися на десятки сайтів команд, бібліотек документів і приватних каналів, не залишаючи очевидного сліду аудиту в стандартних поданнях.

Це створює приховані ризики відповідності. Посилання для гостей, надіслані в ізольованих чатах, файли, продубльовані в різних бібліотеках команд, і «осиротілі» спільні доступи від давно завершених проєктів створюють невидимі шляхи до ваших корпоративних даних. Доступ у M365 за своєю природою реляційний, а не прив'язаний до місця розташування. Щоб ефективно проводити аудит, потрібно відображати ці каскадні зв'язки, а не розглядати кожну службу як окремий острів.

Картографування слідів за допомогою Graph Explorer

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

Прив'язка до користувача: почніть з отримання базового об'єкта користувача за допомогою GET /v1.0/users/{userPrincipalName}?$select=id,displayName,userPrincipalName.
Перелік членств: отримайте групи та ролі, пов'язані з цією ідентичністю, за допомогою GET /v1.0/users/{id}/memberOf?$select=id,displayName.
Перехід від груп до ресурсів: для груп Microsoft 365 і команд знайдіть основний сайт SharePoint за допомогою GET /v1.0/groups/{groupId}/drive/root/children?$select=id,name,lastModifiedDateTime,webUrl або перелічіть диски сайту безпосередньо через GET /v1.0/sites/{siteId}/drives.
Перевірка дозволів і посилань на елементи: перегляньте доступ до окремого файлу за допомогою GET /v1.0/drives/{driveId}/items/{itemId}/permissions?$select=id,grantedToV2,link,roles,shareId.
Простежте, хто що відкривав: співставте дії користувачів за журналами входу або сповіщеннями безпеки разом із контекстом файлів і сайтів.
Замкніть цикл на дописах Teams: шукайте в повідомленнях каналів посилання на конкретні файли за допомогою GET /v1.0/teams/{teamId}/channels/{channelId}/messages?$search="filename" (зважаючи на дозволи та вимоги для beta-версії).

Фільтри для відсіювання шуму, які ви справді використовуватимете

Запити до Microsoft Graph без фільтрів швидко перевантажать систему потоком даних. Щоб виявити реальні ризики, потрібні точні стратегії фільтрації. Ось шаблони запитів, які варто застосовувати:

Зовнішні спільні доступи за останні 7 днів: знаходьте посилання з анонімним доступом або доступом для всієї організації за допомогою GET /v1.0/drives/{driveId}/items/{itemId}/permissions?$filter=link/scope eq 'anonymous' or link/scope eq 'organization'.
Лише ризиковані типи файлів: додайте фільтри на кшталт $filter=endsWith(resourceReference/name,'.xlsm') або endsWith(resourceReference/name,'.pst'), щоб знайти файли з макросами та архіви.
Згадки чутливих термінів у Teams поза робочим часом: шукайте в повідомленнях каналів такі терміни, як confidential, а потім відфільтровуйте результати за часовими мітками створення, які виходять за межі звичайного робочого часу.
Тримайте навантаження мінімальним: завжди додавайте параметри $select, щоб повертати лише потрібні ідентифікатори, назви, URL-адреси та часові мітки.
Обмеження для швидкої перевірки: використовуйте $top=50 для експрес-перевірок, але видаляйте цей параметр під час повних експортів у ваше сховище даних.

Обов'язкові речі для масштабу підприємства: пагінація та обмеження частоти запитів

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

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

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

Навіть досвідчені адміністратори стикаються з перешкодами під час масштабування аудитів M365. Ось найпоширеніші помилки та способи їх усунення:

Помилка: експорти у форматі CSV поступово розходяться зі схемою, коли вона змінюється. Виправлення: використовуйте Graph API напряму з версійованими перетвореннями та коректно обробляйте невідомі поля.
Помилка: змішані ідентифікатори, як-от GUID та імена користувачів (UPN), ламають з'єднання в базі даних. Виправлення: приведіть усе до єдиної семантичної моделі, що охоплює користувачів, групи, сайти, диски, елементи та дозволи.
Помилка: упередження до першої сторінки приховує більшість інцидентів безпеки, які ховаються глибше в результатах. Виправлення: завжди фіксуйте загальну кількість оброблених сторінок і налаштуйте сповіщення, якщо очікуваний обсяг даних раптово зменшується.
Помилка: потоки нерелевантних файлів перевантажують системи обробки. Виправлення: застосовуйте суворі фільтри за областями спільного доступу, часовими вікнами та переліками чутливих термінів.
Помилка: спільні ресурси Teams відірвані від базових файлів. Виправлення: зіставляйте веб-URL-адреси повідомлень каналів безпосередньо з елементами дисків і зберігайте обидва ідентифікатори разом.

Ключові показники для керівництва, які це відкриває

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

Швидкість появи зовнішнього доступу: вимірюйте кількість нових гостьових посилань, створених за тиждень, з розбивкою за сайтами та командами.
Частка звернень до чутливих файлів: відстежуйте унікальних переглядачів мічених матеріалів, відокремлюючи внутрішніх користувачів від зовнішніх гостей.
Ризик від змін у групах: вимірюйте файли, які стали доступними протягом 24 годин після значних змін у складі груп.
Неконтрольоване поширення: відстежуйте чутливі файли, що з'являються в кількох командах або на кількох сайтах протягом одного спринту.
Ефективність очищення: відстежуйте кількість відкликаних посилань і показники часу до усунення з плином часу.

Швидкий старт: рецепт запитів

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

Отримайте основні дані користувача та його членство в групах: /users/{upn}?$select=id,displayName і /users/{id}/memberOf?$select=id,displayName.
Для кожної групи M365 перелічіть елементи диска: /groups/{groupId}/drive/root/children?$select=id,name,webUrl,lastModifiedDateTime&$top=200, не забуваючи переходити за @odata.nextLink.
Для кожного елемента отримайте дозволи: /drives/{driveId}/items/{itemId}/permissions?$select=id,roles,grantedToV2,link, відфільтровуючи області anonymous або organization.
Експортуйте рядки у призначене сховище даних, фіксуючи час клієнта, ідентифікатори сайтів, ідентифікатори дисків, ідентифікатори елементів, веб-URL-адреси, власників, області дії та дані про строк дії.
Візуалізуйте нормалізовані дані в Power BI для панелей керівництва та оперативних панелей.

Перетворення на живу панель

Одноразовий аудит – це знімок, а безперервний аудит – це програма безпеки. Щоб перетворити необроблені виклики Graph на динамічну панель, завантажте дані в Power Dataflows, щоб отримати нормалізовані таблиці для Users, Groups, Sites, Drives, Items, Permissions і Messages. Побудуйте модель даних за схемою «зірка» з Items у центрі та чіткими зв’язками з Users і Groups.

Налаштуйте інкрементальне оновлення на основі полів lastModifiedDateTime і запускайте оновлення протягом дня для сайтів із високим ризиком. Насамкінець налаштуйте автоматичні сповіщення, які спрацьовуватимуть щоразу, коли з’являються нові зовнішні посилання на вмістом із мітками, або коли сплески «group-ripple» вказують на несанкціоноване розширення доступу.

План впровадження на 30 днів

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

Тиждень 1: налаштуйте реєстрацію застосунку в Azure, призначте дозволи Graph API з мінімально необхідними привілеями та встановіть базові показники для перших запитів із параметрами $select і $filter.

Тиждень 2: розробте скрипти пагінації, нормалізуйте ідентифікатори до єдиних UPN і назв пристроїв та виконайте перший успішний наскрізний експорт даних.

Тиждень 3: побудуйте модель даних Power BI і налаштуйте ключові показники ефективності, як-от зовнішня доступність, ризик поширення та часові проміжки від відкриття доступу до його відкликання.

Тиждень 4: автоматизуйте оновлення даних, впровадьте сповіщення про аномалії та задокументуйте стандартні операційні процедури для команди розслідування інцидентів безпеки.

Кому варто подивитися

Цей фреймворк призначений насамперед для адміністраторів M365 і керівників SecOps, які підозрюють, що «зелені» панелі приховують сірі зони, для команд комплаєнсу, яким потрібна наскрізна видимість спільного доступу без зайвих сторонніх інструментів, і для власників співпраці, відповідальних за безпечні практики зовнішнього спільного доступу.

Практичні поради

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

Висновок

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

Для глибшого занурення, прикладів коду та реальних рецептів Graph послухайте нашу повну розмову в подкасті. Перегляньте відповідний епізод і дізнайтеся всі деталі за посиланням Map Microsoft 365 Users, Groups, Files, and Shares with Graph. Залишайтеся в безпеці, продовжуйте автоматизувати процеси, і до зустрічі в наступному епізоді!