Чому стандартні журнали аудиту M365 приховують небезпечний зовнішній обмін

By Mirko Peters · 2026-08-11

Раді вітати вас знову в нашому блозі! Якщо ви адмініструєте клієнт Microsoft 365, ви, мабуть, спокійно спите вночі, вважаючи, що вбудовані журнали аудиту вас захищають. Адже Microsoft надає надійні функції безпеки та відповідності одразу «з коробки», правда? На жаль, коли йдеться про зовнішній обмін у SharePoint і OneDrive, покладатися на стандартні параметри означає напрошуватися на біду. Організ

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

Раді вітати вас знову в нашому блозі! Якщо ви адмініструєте клієнт Microsoft 365, ви, мабуть, спокійно спите вночі, вважаючи, що вбудовані журнали аудиту вас захищають. Адже Microsoft надає надійні функції безпеки та відповідності одразу «з коробки», правда? На жаль, коли йдеться про зовнішній обмін у SharePoint і OneDrive, покладатися на стандартні параметри означає напрошуватися на біду. Організації звикли вважати, що раз аудит увімкнено, кожне переміщення файлу, вхід гостя і створення посилання надійно відстежуються та легко перевіряються. Насправді ж ваші стандартні журнали аудиту M365, імовірно, приховують небезпечні дії зі зовнішнім обміном просто на виду.

У цьому докладному посібнику ми заглянемо за лаштунки сліпих зон аудиту Microsoft 365, з'ясуємо, чому 90-денного збереження вже недостатньо для сучасної відповідності вимогам, і крок за кроком покажемо точний технічний план, який перетворює сирий, некерований потік даних на точну й придатну до використання аналітику безпеки. Заглибимося в те, як перестати працювати наосліп і знову повністю контролювати середовище спільної роботи.

Чому стандартні журнали аудиту M365 приховують небезпечний зовнішній обмін

Найбільша пастка в адмініструванні Microsoft 365 полягає в припущенні, що статус «Аудит увімкнено» означає повну видимість. Це не так. За замовчуванням стандартні параметри клієнта пропускають важливі детальні події, зокрема створення анонімних посилань, використання посилань гостьовими користувачами та певні взаємодії з доступом до файлів. Якщо користувач створює анонімний дозвіл «Будь-хто з посиланням» на чутливу фінансову таблицю, а зовнішній зловмисник її завантажує, ваш стандартний запит аудиту з коробки може повністю пропустити подію використання.

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

Налаштуйте основу аудиту (обов'язкові параметри)

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

• Увімкніть розширений аудит для SharePoint і OneDrive на рівні клієнта за допомогою Exchange Online PowerShell або порталу відповідності Microsoft Purview.
• Переконайтеся, що журналювання активне як для створення, так і для використання посилань, приділяючи особливу увагу анонімним і гостьовим посиланням.
• Подовжте політики збереження журналів аудиту значно довше за стандартні 90 днів, щоб відповідати сучасним вимогам відповідності та потребам внутрішніх розслідувань (рекомендовано від 180 до 365 днів).
• Стандартизуйте політики створення сайтів, щоб нově створені сайти SharePoint і групи Microsoft 365 автоматично успадковували ці посилені параметри аудиту без ручного втручання.

Від шуму до сигналу (PowerShell на практиці)

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

Зосередьтеся на запитах щодо подій високого ризику, таких як SharingCreated, SharingSet, AnonymousLinkCreated, AnonymousLinkUsed і AccessRequestApproved. Потім збагачуйте кожен рядок важливим контекстом:

• Класифікація домену призначення: автоматично відносьте домени до партнерських корпоративних, внутрішніх або особистих/споживчих доменів (наприклад, gmail.com, yahoo.com або outlook.com).
• Контекст чутливості файлу та контейнера: зіставляйте мітку конфіденційності Microsoft Purview, яка застосована до файлу, з батьківським сайтом або контейнером OneDrive.
• Контекст ризику дій користувача: перехресно перевіряйте користувача, що виконує дію, у системах кадрів або ідентифікації, щоб позначати співробітників, які звільняються, VIP-користувачів або скомпрометовані облікові записи.

Замість суб'єктивних припущень застосовуйте суворі правила: чутливий файл із міткою конфіденційності в поєднанні із зовнішнім особистим доменом одразу означає ВИСОКИЙ ризик. Результати виводьте у два окремі артефакти: «Чергу дій» з 10–50 рядками, які потребують перевірки людиною, та повністю нормалізований «Журнал доказів» для вашого SIEM або інструментів BI.

Сповіщення в реальному часі, які справді працюють

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

• Негайно надсилайте сповіщення команді SecOps щоразу, коли файл із міткою конфіденційності надається зовнішньому одержувачу, який не входить до попередньо затвердженого списку дозволених партнерів.
• Якщо для файлу з міткою конфіденційності створено анонімне посилання, надішліть сповіщення і одночасно запустіть автоматизований скрипт, який деактивує це посилання.
• Стежте за незвично високою швидкістю—наприклад, великою кількістю зовнішніх спільних доступів, виконаних одним користувачем за короткий проміжок часу,—і в такому разі застосовуйте тимчасове обмеження швидкості разом із сповіщенням.

Завжди передбачайте періоди охолодження та механізми дедуплікації, щоб запобігти втомі від сповіщень. Спрямовуйте сповіщення безпосередньо до цілеспрямованої черги тикетів або виділеного каналу SecOps із чітко визначеними відповідальними, плейбуками та посиланнями для відкату в один клік.

Масштабування на рівні підприємства

Ручні скрипти та щотижневі експорти CSV швидко перестануть працювати, щойно ваша організація перевищить кілька сотень користувачів. Щоб побудувати стійкий механізм моніторингу для великого підприємства, потрібна надійна автоматизована основа на базі Azure Automation або Azure Logic Apps, які виконують ковзні дельта-вибірки за 7 днів разом із щомісячними догрузками за минулий період.

Впровадьте суворе посторінкове завантаження та контрольні точки, щоб коректно відновлювати роботу з останнього курсора й акуратно обробляти обмеження API (помилки HTTP 429). Переконайтеся, що ваша автоматизація безперервно виявляє щойно створені сайти та автоматично застосовує базові правила аудиту і маркування. Нарешті, стежте за станом конвеєра: налаштуйте автоматичні сповіщення, якщо очікуваний обсяг подій раптово впаде, що вказуватиме на зламаний конвеєр прийому аудиту.

Швидкі перемоги цього тижня

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

• Увімкніть журналювання використання анонімних посилань і продовжте строк зберігання в порталі Purview.
• Створіть базовий список заборонених «особистих доменів», щоб позначати безкоштовні поштові сервіси, як-от Gmail, Yahoo і Hotmail.
• Застосуйте мітки конфіденційності до бібліотек документів фінансового відділу та відділу кадрів і заблокуйте створення анонімних посилань політикою.
• Щотижня надсилайте керівництву ІТ дайджест «10 найризикованіших спільних доступів» із власниками файлів і посиланнями для відкликання доступу в один клік.
• Створіть правило виявлення сплесків для користувачів, які виконують п'ять або більше зовнішніх спільних доступів протягом 10 хвилин.

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

Щоб впровадження було структурованим і керованим, дотримуйтеся цього поетапного плану на 30 днів:

• Тиждень 1: посилення політик аудиту, продовження строків зберігання, створення базових експортів і визначення списків дозволених та заборонених доменів.
• Тиждень 2: впровадження скриптів PowerShell для збагачення даних про мітки конфіденційності та домени, побудова матриць оцінювання ризиків і створення черги дій для сортування інцидентів.
• Тиждень 3: розгортання правил сповіщень у реальному часі з дедуплікацією, періодами охолодження та автоматичною деактивацією посилань для ризикових відкритих доступів.
• Тиждень 4: масштабування автоматизації через Azure Automation або Logic Apps, створення керівних панелей Power BI для керівництва та завершення операційних плейбуків.

KPI для керівництва та операцій

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

• Швидкість зовнішнього відкриття: кількість нових зовнішніх посилань, створених за добу, у розрізі сайтів, міток конфіденційності та доменів призначення.
• Частота витоків чутливих даних: how often files with sensitivity labels are shared with unapproved non-partner domains.
• Час до відкликання: середній час від моменту ризикового спільного доступу до моменту, коли доступ успішно відкликано.
• Аномалії сплесків: частота випадків, коли користувачі перевищують визначені порогові значення спільного доступу.
• Охоплення автоматичного усунення: відсоток ризикових посилань, які автоматично деактивовано або заблоковано політикою.

Поширені помилки, яких варто уникати

Під час побудови стратегії аудиту та усунення ризиків свідомо уникайте цих типових помилок:

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

Плейбуки, які варто мати під рукою

Забезпечте свої служби підтримки та безпеки чіткими, повторюваними плейбуками реагування на інциденти:

• Відкликати доступ і повідомити про зовнішній обмін: миттєво деактивуйте несанкціоноване посилання для спільного доступу, автоматично повідомте власника файлу та вимагайте повторного надання доступу лише через авторизовані домени партнерів.
• Перевірка при звільненні співробітника: перелічіть усі спільні ресурси OneDrive, пов’язані з користувачем, що звільняється, автоматично відкличте доступ, наданий на особисті споживчі домени, і передайте право власності безпосередньому керівнику.
• Особливий нагляд за керівництвом: застосовуйте жорсткіші пороги аномалій, коротший термін дії посилань і миттєве сповіщення про будь-яку активність із вмістом рівня керівництва.

Головне

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

Щоб дізнатися ще більше про захист свого клієнта Microsoft 365 і виявлення ризиків до того, як станеться катастрофа, обов’язково перегляньте пов’язаний випуск подкасту: Detect Risky SharePoint and OneDrive External Sharing. Ми докладніше розбираємо ці стратегії, щоб допомогти вам опанувати безпеку M365!