Масштабирование: управление пагинацией, ограничением частоты запросов и аудитом крупных клиентов M365

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

Это создает скрытые риски соответствия требованиям. Гостевые ссылки, отправленные в изолированных чатах, файлы, продублированные в разных библиотеках команд, и забытые общие ресурсы давно завершенных проектов создают невидимые пути к корпоративным данным. Доступ в 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" (учитывая разрешения и требования бета-версии).

Фильтры для отсеивания лишнего, которые вы действительно будете использовать

Запросы к 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 о превышении лимита запросов. Реализуйте надежную логику экспоненциальной задержки, чтобы скрипт делал паузу, ждал окончания периода ограничения и корректно продолжал работу с того места, где остановился. Группируйте запросы разумно: предпочитайте меньшее количество крупных логических запросов и кешируйте сопоставления групп и сайтов. Для очень больших клиентов разбивайте сканирование по сайтам или диапазонам дат и планируйте его на внепиковые часы, чтобы не влиять на производительность рабочих систем.

Типичные ошибки и быстрые решения

Даже опытные администраторы сталкиваются с препятствиями при масштабировании аудитов Microsoft 365. Вот самые частые ошибки и способы их исправить:

Ошибка: выгрузки в CSV со временем расходятся со схемой данных. Решение: работайте напрямую с Graph API, используйте версионированные преобразования и корректно обрабатывайте неизвестные поля.
Ошибка: смешанные идентификаторы, например GUID и имена участников (UPN), ломают соединения в базе данных. Решение: приведите все данные к единой семантической модели, включающей пользователей, группы, сайты, диски, элементы и разрешения.
Ошибка: смещение к первой странице скрывает большинство инцидентов безопасности, спрятанных глубже в результатах. Решение: всегда логируйте общее количество обработанных страниц и настраивайте оповещения, если ожидаемый объем данных внезапно падает.
Ошибка: поток нерелевантных файлов перегружает системы обработки. Решение: применяйте строгие фильтры по областям общего доступа, временным окнам и спискам чувствительных терминов.
Ошибка: общие ресурсы Teams не связаны с нижележащими файлами. Решение: сопоставляйте веб-URL сообщений канала с элементами диска и храните оба идентификатора вместе.

Ключевые показатели для руководства, которые это открывает

Технические данные имеют ценность только тогда, когда их можно превратить в практичную бизнес-аналитику для руководства. Автоматизированный конвейер аудита через Graph открывает важные KPI для руководителей:

Скорость роста внешнего доступа: количество новых гостевых ссылок, созданных за неделю, с разбивкой по сайтам и командам.
Частота обращений к чувствительным файлам: количество уникальных просмотров помеченного контента с разделением на внутренних пользователей и внешних гостей.
Волновой риск групп: количество файлов, ставших доступными в течение 24 часов после крупных изменений состава групп.
Теневое распространение: отслеживание чувствительных файлов, которые появляются в нескольких командах или на нескольких сайтах в рамках одного спринта.
Эффективность очистки: динамика количества отозванных ссылок и времени устранения рисков.

Быстрый старт: рецепт запросов

Если вы готовы начать собственный конвейер сбора данных, используйте этот пошаговый набор запросов, чтобы быстро стартовать:

Получите основные данные пользователя и его членство в группах: /users/{upn}?$select=id,displayName и /users/{id}/memberOf?$select=id,displayName.
Для каждой группы Microsoft 365 перечислите элементы диска: /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 и получите нормализованные таблицы: Пользователи, Группы, Сайты, Диски, Элементы, Разрешения и Сообщения. Смоделируйте данные по звездообразной схеме с Элементами в центре и чёткими связями с Пользователями и Группами.

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

План внедрения на 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. Оставайтесь в безопасности, продолжайте автоматизировать процессы, и увидимся в следующем выпуске!