M365Con 2027 – безкоштовна онлайн-конференція · 11–22 Jan 2027 · 120 sessions→ m365con.net

Блог · Mirko Peters

Опановуємо Graph Explorer: відстеження сліду користувача від початку до кінця

By ·

Ласкаво просимо назад до супровідного блогу подкасту! У сьогоднішньому дописі ми виходимо далеко за межі фрагментованих інтерфейсів адміністрування, які всі ми знаємо і з якими інколи маємо клопіт…

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

▶ BLOGMastering GraphExplorer: Tracing a Us……M365.FM
Titelbild: Mastering Graph Explorer: Tracing a User Footprint End-to-End

Ласкаво просимо назад до подкаст-блогу! У сьогоднішньому дописі ми виходимо далеко за межі розрізнених інтерфейсів адміністрування, з якими всі ми знайомі й іноді маємо труднощі. Якщо ви колись намагалися зібрати повний журнал аудиту того, до чого конкретний користувач мав доступ, чим ділився або з чим працював у Microsoft 365, ви вже знаєте, наскільки фрагментованими можуть здаватися вбудовані центри адміністрування. Тому ми глибоко занурюємося в Microsoft Graph. Завдяки Graph API ми можемо без зусиль переходити від окремих користувачів до груп, сайтів SharePoint, файлів, зовнішніх посилань і навіть активних переглядачів. Якщо ви хочете послухати аудіообговорення, яке безпосередньо доповнює цей посібник, обов’язково перегляньте пов’язаний епізод Map Microsoft 365 Users, Groups, Files, and Shares with Graph.

Чому M365 не ізольований

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

  • Чати Teams, бібліотеки SharePoint і папки OneDrive пов’язані між собою через членство в групах.
  • Одна проста дія «додати одного користувача до однієї групи» може непомітно відкрити доступ до численних базових сайтів, каналів і зовнішніх спільних ресурсів, не залишаючи очевидного сліду в стандартних звітах аудиту.
  • Ваш ризик для відповідності вимогам походить саме від цих невидимих шляхів: гостьових посилань, надісланих у приватні чати, файлів, дубльованих у кількох бібліотеках, та «забутих» спільних ресурсів, які лишаються після завершення проєктів.

Картування сліду за допомогою Graph Explorer (точки дотику користувача до файлів)

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

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

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

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

  • Виділення зовнішніх спільних ресурсів, створених за останні 7 днів, за допомогою фільтрів області:
  • Виділення ризикованих типів файлів за допомогою розширень імен файлів:
    Додайте $filter=endsWith(resourceReference/name,'.xlsm') or endsWith(resourceReference/name,'.pst')
  • Відстеження згадок конфіденційних термінів у каналах Teams поза робочим часом:
    GET /v1.0/teams/{teamId}/channels/{channelId}/messages?$search="confidential", далі відфільтруйте результати за createdDateTime поза звичайними робочими годинами.
  • Тримайте навантаження легким та ефективним, завжди додаючи $select, щоб повертати лише ідентифікатори, назви, веб-URL, часові мітки останньої зміни та мінімальні поля дозволів.
  • Обмежуйте кількість результатів для швидкого сортування, використовуючи $top=50 для швидких вибіркових перевірок, але не забувайте прибрати це обмеження, коли експортуєте дані в постійне сховище.

Найважливіші вимоги для масштабування (пагінація та обмеження частоти запитів)

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

  • Вибірка даних не вважається завершеною, доки ви не пройдете за властивістю @odata.nextLink для кожної сторінки результатів.
  • Враховуйте відповіді HTTP 429 про обмеження частоти запитів: реалізуйте процедури експоненційної затримки (exponential backoff) і переконайтеся, що скрипт може безпечно продовжити роботу з місця зупинки.
  • Розумно групуйте запити. Віддавайте перевагу меншій кількості великих, добре структурованих запитів замість лавини дрібних викликів і агресивно кешуйте відповідності між групами та сайтами.
  • Розбивайте масові обходи клієнта за ідентифікаторами сайтів SharePoint або діапазонами дат, щоб уникнути тайм-аутів запитів, і плануйте такі важкі операції на години з низьким навантаженням.

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

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

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

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

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

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

Швидкий рецепт запиту (потік копіювання й вставлення)

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

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

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

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

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

Готові застосувати це в своїй організації? Дотримуйтеся цієї структурованої чотиритижневої програми впровадження:

  • Тиждень 1: завершіть реєстрацію застосунку, призначте Graph API дозволи з найменшими необхідними привілеями та створіть базові запити з точними параметрами $select і $filter.
  • Тиждень 2: Створіть скрипти пагінації, реалізуйте нормалізацію ідентифікаторів від ID до UPN і виконайте свій перший успішний експорт даних.
  • Тиждень 3: Побудуйте модель даних у Power BI та базові KPI, зокрема відстеження зовнішнього доступу та аналіз ризику каскадного поширення.
  • Тиждень 4: Автоматизуйте оновлення даних, налаштуйте сповіщення про аномалії та задокументуйте стандартні операційні процедури для команд безпеки та відповідності вимогам.

Кому варто звернути увагу

Ця методологія створена саме для певних ролей у вашій організації:

  • Адміністраторам Microsoft 365 і керівникам SecOps, які підозрюють, що стандартні адміністративні панелі приховують критичні сірі зони.
  • Командам відповідності вимогам, яким потрібна наскрізна видимість спільного доступу без додавання дорогого стороннього ПЗ.
  • Власникам співпраці, які несуть остаточну відповідальність за безпечний і контрольований зовнішній спільний доступ.

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

Тримайте ці практичні поради під рукою, поки будуєте автоматизацію на основі Graph:

  • Завжди починайте розслідування або з користувача, або з файлу, а потім досліджуйте зв'язки в обох напрямках, щоб не пропустити сліпих зон.
  • Ставтеся до дії «додати до групи» як до зміни з високим ризиком і переглядайте наслідки для доступу в подальших ланцюгах протягом 24 годин.
  • Ведіть актуальний короткий список чутливих термінів для пошуку в повідомленнях Teams і назвах файлів та регулярно переглядайте його.
  • Пильно фіксуйте в журналах кількість оброблених сторінок і обсяги записів: іноді повна тиша в журналах і є сигналом про те, що завдання конвеєра зламалося.

Висновки

Опанування Microsoft Graph для відстеження слідів користувачів від початку до кінця долає розрив між розрізненими адміністративними представленнями та справжньою видимістю в межах організації. Перейшовши від ізольованих сховищ до реляційного відображення доступу, ви зможете проактивно захищати чутливі дані, усунути неконтрольоване поширення файлів і надати керівництву KPI, які можна використати на практиці. Щоб дізнатися більше експертних розборів, реальних прикладів і детальніших розглядів подібних сценаріїв, обов'язково послухайте повний епізод за посиланням Map Microsoft 365 Users, Groups, Files, and Shares with Graph.

Підпишіться
Більше поглиблених розборів і практичних рецептів роботи з Graph шукайте в нових епізодах на m365.show/subscribe

Entities in this article

Microsoft Graph Graph Explorer SharePoint Audit logs OneDrive Microsoft 365 OData Power BI SharePoint document libraries

Related articles

RSS