AI DLP-система не бачить витік: де ламається захист
Типова картина: в AI DLP-системі заведено правила, служба безпеки звітує про покриття, а витік конфіденційних даних усе одно розкривається ззовні — з листа контрагента або зі скарги співробітника, який помітив зайве в загальному чаті. Служба дізнається про інцидент постфактум, коли файл уже в отримувача.
Справа не в кількості правил, а в їхній природі. Правило ловить шаблон: номер, набір символів, знайомий заголовок документа.
Те, заради чого будується захист персональних даних, так не виглядає — клієнтська база в архіві, фрагмент договору в листуванні, вивантаження звіту в особисту хмару.
Контроль доступу до даних при цьому налаштований на периметр: кому яка папка і який сервіс доступні. Витік же йде дозволеними каналами — право читати є, обмеження на копіювання немає.
Розбір інцидентів витоку перетворюється на археологію: журнали зібрано, зв'язків між подіями немає, маршрут документа вдається відновити рідко.
Другий ефект — шум. Хибні спрацьовування на кожен шаблонний номер привчають аналітиків закривати оповіщення не читаючи, і справжня подія тоне в потоці.
Далі розбираємо, як це закривається: що змінюється в правилах, розмітці та реакції, коли класифікацію і пріоритет бере на себе модель, а не список винятків.
Що дає керована класифікація даних
Класифікація починається з того, що в кожного документа з'являється мітка: загальнодоступно, внутрішнє, конфіденційно, комерційна таємниця.
Автоматична розмітка документів іде за вмістом, а не за папкою чи іменем файлу — модель розбирає текст, вкладення й структуру, а правило підтверджує результат.
Частка документів, розмічених без участі людини, зазвичай виходить за 85–90 %, решта йде на розбір за зрозумілою ознакою, а не «тому що так вирішив спеціаліст».
Звідси головний ефект для служби безпеки — зменшення ручного розбору. Інцидент приходить у чергу вже з міткою та контекстом: які дані, чиї вони, куди йдуть.
Розбір з нуля замінюється перевіркою готового стислого підсумку, тому час реакції на інцидент вимірюється годинами, а не днями, і скорочується далі в міру накопичення правил під реальні сценарії.
Контроль тіньових сервісів тримається на тій самій мітці. Коли співробітник надсилає конфіденційний файл у зовнішній сервіс або особисте сховище, спрацьовує політика, а не здогад адміністратора: потік або блокується, або йде на підтвердження власнику даних.
Тіньовий сервіс перестає бути сліпою зоною, а в DLP-системі з'являється перелік каналів, якими дані реально залишають периметр.
Окремий знятий клас — помилки ручної розмітки. Людина втомлюється й трактує той самий договір по-різному в понеділок і в п'ятницю; правило дає однакову відповідь на однакову ознаку, а спірні випадки виносяться на рев'ю окремо.
У звіті залишаються показники, за якими видно роботу: час реакції на інцидент, частка автоматично розібраних випадків, повнота розмітки та кількість спрацьовувань за тіньовими каналами.
Порівняння підходів до контролю потоків даних
Вибір підходу впирається в те, хто відповідає за розмітку даних і на якому етапі вона з'являється.
Вбудований контроль платформи — поштовий шлюз, хмарне сховище, агент на кінцевій точці — працює за метаданими й готовими шаблонами: розгортається швидко, не потребує окремої інфраструктури і закриває регулярні канали.
Ручний контроль силами служби тримається на експертизі аналітиків і розборі інцидентів вручну. Розмітка за вмістом — окреме завдання: сенс документа не читається ні з імені файлу, ні з розширення, його потрібно обчислювати за текстом, і тут підходи розходяться найсильніше.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Вбудований контроль платформи | Регулярні канали: пошта, хмарні диски, знімні носії, права доступу | Реагує на метадані та шаблони. Перейменований файл, скриншот, вставлення в тіло листа або архів проходять повз правила |
| Ручний контроль силами служби | Невеликий потік, висока ціна помилки, разові перевірки перед публікацією | Пропускна здатність обмежена людьми: класифікація відстає від потоку, рішення суб'єктивні й погано відтворюються при зміні аналітика |
| Виділений контур класифікації | Змішаний потік документів, багато форматів, потрібна розмітка за вмістом і єдина політика | Потребує навчання моделей на своїх даних, налаштування порогів і постійного контролю якості розмітки |
На практиці підходи комбінують: платформенні правила знімають масові спрацьовування за метаданими, а класифікація за вмістом доопрацьовує те, що до них не доходить. Далі розбираємо, як це стикується з уже працюючими засобами захисту.
Як ми впроваджуємо контроль даних: етапи робіт
Ставити правила одразу після розгортання — швидкий спосіб отримати потік хибних спрацьовувань і втратити довіру користувачів. Тому робота йде від інвентаризації до точкового налаштування: спочатку фіксуємо, де дані живуть і як переміщуються, і лише потім вмикаємо контроль.
- Аудит потоків даних. Фіксуємо канали: пошта, месенджери, хмарні диски, знімні носії, друк, доступ до баз. Інтерв'ю з власниками систем і журнали доступу дають перелік точок, де конфіденційні дані реально з'являються.
- Схема маршрутів даних. Простежуємо шлях документа від джерела до зовнішнього отримувача: хто створює, копіює, де лежить копія. Схему погоджують служба ІБ і власники процесів — вона стає опорою і для правил, і для розбору інцидентів.
- Розмітка та навчання класифікації. Задаємо категорії — персональні дані, комерційна таємниця, проєктна документація — і розмічаємо наявні масиви. Модель навчається на ваших документах і розпізнає галузеві формулювання, а не абстрактний набір.
- Налаштування правил контролю. Для кожного маршруту задаємо свою дію: журналювання, попередження користувачу, блокування надсилання. Окремо прописуємо винятки для легітимного обміну, щоб не зупинити роботу підрозділів.
- Перевірка на реальних даних. Вмикаємо тіньовий режим на частині підрозділів: рахуємо частку хибних спрацьовувань і пропусків, донавчаємо модель, коригуємо поріг. Блокування вмикаємо там, де точність підтверджена заміром.
- Передача в експлуатацію. Віддаємо адміністраторам регламенти реакції на інцидент, конфігурацію та порядок розбору спірних випадків. Перші тижні супроводжуємо, поки служба не вийде на самостійний режим.
Що залишається у вас на руках після впровадження
Впровадження системи класифікації та захисту даних не закінчується запуском — у вашої команди має залишитися комплект артефактів, за якими систему можна розвивати, перевіряти й передавати між адміністраторами.
Ми фіксуємо не лише працюючі правила, а й логіку рішень за ними: без цього будь-яка правка політик перетворюється на експеримент над продакшеном.
- Схема маршрутів даних — де інформація з'являється, через які сервіси та сховища проходить, у яких точках ставиться контроль. Потрібна, щоб нова інтеграція не з'явилася в обхід політик.
- Матриця політик доступу — відповідність «категорія даних → хто і за яких умов отримує доступ → що відбувається при порушенні». Формулювання однозначні, щоб правило відтворювалося без автора.
- Конфігурації класифікатора — ознаки чутливих категорій, пороги спрацьовування та списки винятків, які знімають хибні позначки.
- Регламент розбору спрацьовувань — хто реагує, за який час, які дії відповідають рівню ризику, як фіксується рішення і коли подія закривається.
- Інструкції для адміністраторів — типові операції: додати категорію, змінити правило, розібрати чергу подій, відкотити невдалу правку.
- Документація щодо впровадження — архітектурні рішення та їх обґрунтування, схема розміщення компонентів, залежності й точки відмови.
- Журнал змін політик із процедурою відкату — кожна правка версіонується, попередній набір правил повертається однією операцією.
Такий комплект скорочує строк введення нового адміністратора й прибирає залежність від підрядника: розбір спрацьовувань іде за регламентом, а не з пам'яті конкретного інженера.
Якщо потрібен лише один блок — наприклад, схема маршрутів даних або матриця доступу — зберемо його окремо.
Розбір впровадження: метрики до і після
До: черга, яку не встигали розбирати
У роздрібній мережі захист даних спирався на правила за шаблонами: спрацьовування за номерами карт, рахунками та паспортними даними потрапляли в єдину чергу розбору.
Близько дев'ятисот сигналів на місяць підтверджувалися одиницями — аналітик закривав потік як хибний, а частина черги не доходила до перевірки взагалі. Час реакції на реальний витік розтягувався на дві-три доби: поки розбирали шум, вивантаження вже йшло зовнішнім каналом.
Що змінили і що вийшло
Наші інженери залишили перехоплення на стороні Microsoft Purview, а зверху додали класифікатор, навчений на внутрішньому корпусі документів замовника: він дивиться на контекст, а не лише на шаблон, тому типове вивантаження з облікової системи перестало виглядати витоком.
Поріг чутливості підбирали за розміченою вибіркою інцидентів, а перед бойовим увімкненням модель прогнали на подіях минулих періодів — це дало метрики до і після на одному й тому самому наборі.
| Показник | До | Після |
|---|---|---|
| Частка хибних спрацьовувань | 76% | 8% |
| Оповіщення на ручному розборі | ~900 на місяць | ~70 на місяць |
| Час реакції на витік | 2-3 доби | до 15 хвилин |
| Знахідки після надсилання файлу | регулярно | поодинокі |
Черга перестала бути вузьким місцем: аналітик працює з підтвердженими випадками, а не фільтрує шум. Окремий ефект — стійкість уваги: чим менше хибних сигналів, тим вищий шанс, що реальний помітять у перші хвилини.
Що робити, якщо система вже стоїть, але хибних спрацьовувань багато
Хибні спрацьовування майже ніколи не пов'язані з якістю моделі — їх дає накопичений шар правил, який роками дописували вручну без перегляду.
Тому починаємо не із заміни движка, а з аудиту наявного захисту: вивантажуємо історію спрацьовувань за кілька місяців і дивимося, на які правила припадає основний потік повідомлень.
Далі — точність розмітки. З вивантаження формуємо вибірку за кожним правилом і типами даних, розмічаємо її вручну разом із вашою службою безпеки: подія справді потребує реакції чи ні.
Без такого еталона переналаштування правил перетворюється на вгадування, тому що пороги змінюються наосліп.
З еталоном стає видно, де правило шумить через надто широку умову, а де — через неправильний поріг спрацьовування.
Тоді переналаштування йде точково: звужуємо область перевірки, додаємо контекстні умови — тип отримувача, напрямок передачі, наявність мітки, — виключаємо легітимні потоки й об'єднуємо дублювальні правила в одну політику.
Порядок такий: аудит і розмітка, перезбирання правил у тестовому контурі на історичних даних, тіньовий режим на живому трафіку, потім поступове увімкнення блокувань за групами користувачів.
Захист при цьому не зупиняється — чинні політики продовжують працювати, поки нові перевіряються паралельно.
Результат оцінюємо за двома метриками одразу: частка хибних спрацьовувань і кількість пропущених інцидентів. Якщо перше падає, а друге зростає — правило звузили надто сильно.
Розумний ритм — переглядати розмітку й пороги раз на квартал, інакше правила знову розходяться з реальними процесами в компанії.
Технічні сумніви перед стартом робіт
Сумніви на старті майже завжди ті самі: чи не перетвориться захист на потік хибних блокувань, чи не почне гальмувати робоча машина, чи можна вмикати це частинами і що робити з підрядниками на своїх облікових записах. Нижче — як кожне із цих питань вирішується на рівні налаштування, а не обіцянок.
Наскільки точна класифікація і що з хибними спрацьовуваннями?
Модель навчається на розміченому корпусі замовника і калібрується під його документообіг, тому поріг упевненості виставляється під кожне правило окремо.
На старті вмикаємо режим лише-повідомлення: система пише вердикт у журнал, але не блокує, і аналітик бачить реальну частку хибних міток. Далі правила з високим порогом переводимо в блокування, а спірні залишаємо на ручному розборі — так хибне спрацьовування не зупиняє роботу.
Яке буде навантаження на робочі місця співробітників?
Важка обробка винесена на серверний бік, на машині залишається клієнт, який віддає подію і продовжує працювати. Для документів великого обсягу налаштовуємо чергу й відкладений аналіз.
Перед промисловим запуском знімаємо заміри на реальному парку: важливо, щоб надсилання листа або збереження файлу не відчувалися повільнішими.
Чи можна впроваджувати поетапно?
Так, і ми наполягаємо саме на цьому. Спочатку — пілот на одному підрозділі й вузькому наборі правил, потім розширення за відділами, і лише потім загальна політика.
У кожного етапу свої критерії приймання, а зміна правил версіонується: відкат до попередньої версії займає хвилини й не потребує простою.
Як бути із зовнішніми підрядниками та їхніми доступами?
Для них заводимо окремі облікові записи й окрему політику: обмежений набір каналів, строк дії доступу, обов'язкове журналювання дій. Система бачить активність підрядника як окремий суб'єкт, тому розбір інциденту не тоне в загальній масі подій. Після завершення робіт доступ закривається автоматично за розкладом.
Обговоримо задачу й повернемося з планом робіт
Розмову починаємо не з презентації, а з вашого контуру: щоб повернутися з оцінкою обсягу робіт і планом впровадження, а не із загальними слайдами, нам потрібен мінімум вступних даних. Нижче — що варто тримати під рукою до першої зустрічі. Якщо за частиною пунктів відповіді поки немає, це не блокує старт: частину картини зберемо разом.
- Звідки дані йдуть. Пошта, файлові сховища, хмарні диски, месенджери, вивантаження з облікових систем, знімні носії — які канали реально використовуються і які з них сьогодні закриті.
- Що саме захищаємо. Категорії: персональні дані, комерційна таємниця, договори, конструкторська й фінансова документація. За кожною — чи допустиме копіювання у внутрішню мережу або заборонено повністю.
- Типи й обсяг потоків. Порядок величини: скільки користувачів, скільки файлів і листів на добу, чи зростає обсяг сезонно. Від цього залежить схема розбору трафіку й режим роботи моделей класифікації.
- Як влаштована інфраструктура. Ізольований контур, власні сервери, гібрид або хмара; чи є пряма заборона на передачу вмісту документів за межі мережі — тоді система ставиться всередину периметра.
- Регламент реагування. Хто отримує повідомлення про інцидент, де межа між попередженням і блокуванням, хто розбирає хибні спрацьовування і з якою періодичністю.
- Точки інтеграції. Каталог користувачів, внутрішня система моніторингу подій, системи контролю доступу, журнали — куди система має віддавати події та звідки брати ролі співробітників.
- Поточні правила й вимоги. Що вже зафіксовано у внутрішніх документах, чи є галузеві вимоги до строків зберігання й порядку розбору інцидентів.
- Власник системи на вашому боці. Хто прийме роботу, хто буде вести політики після запуску і в якому вигляді зручно передавати знання команді.
За цими відповідями ми збираємо склад робіт із захисту даних: які канали закриваємо на першому етапі, які — другим, де потрібне ручне налаштування правил під ваш документообіг.
Опишіть задачу у зручному вигляді — повернемося з оцінкою обсягу робіт, схемою етапів і планом впровадження зі зрозумілими строками.
