Проблема фрагментації у реальному світі
Середня організація розміром 500+ співробітників використовує від 3 до 7 різних інструментів для виявлення, маскування або анонімізації PII. Кожен інструмент придбаний для конкретного завдання, кожен управляється окремою командою.
Типова ситуація:
- DLP-система від постачальника A (мережевий трафік)
- CASB від постачальника B (хмарні додатки)
- Маскування БД від постачальника C (структуровані дані)
- Ручна редакція документів (юридична команда, Power PDF)
- Спеціальний скрипт Python (команда даних)
- Email DLP від постачальника D (інтегрований в Office 365)
Що спільного в цих рішень? Вони не знають одне про одного.
Чому фрагментація призводить до провалів аудиту
1. Непослідовні визначення PII
Кожен інструмент має власне визначення того, що є PII. Один вважає IP-адресу PII, інший — ні. Один виявляє Codice Fiscale, інший — ні.
Результат для аудиту: Аудитор перевіряє, чи документ A оброблений правильно. Інструмент 1 каже «так», інструмент 2 каже «ні». Яке рішення є правильним?
Відповідь: GDPR застосовує принцип найвищого стандарту — якщо будь-який інструмент вважає щось PII, це PII. Але якщо ваша команда не знає, що думає кожен інструмент — провал неминучий.
2. Прогалини в покритті
Жоден з інструментів не покриває весь потік даних:
- DLP бачить мережевий трафік, але не внутрішні передачі через БД
- Маскування БД охоплює структуровані поля, але не вільний текст у полях приміток
- Email DLP не обробляє файли, що вивантажуються через браузер
Результат: Дані, що проходять через «щілини» між інструментами, не захищені.
3. Неузгодженість журналів аудиту
GDPR (ст. 5(2)) вимагає підзвітності. Підзвітність вимагає доказів — тобто журналів.
З множинними інструментами:
- Журнали в різних форматах (CSV, JSON, Syslog, власний формат)
- Різні рівні деталізації
- Різні строки зберігання
- Розрізнені системи журналів без кореляції
При аудиті: «Покажіть мені, хто мав доступ до цих даних пацієнта 15 березня між 14:00 і 16:00». Ви маєте запити до 4 різних систем, нормалізувати формати, вручну зіставити події.
4. Суперечливі налаштування
Система A налаштована блокувати передачу SSN. Система B дозволяє завантаження SSN у хмарне сховище для аналізу. Хто правий?
Без єдиної политики та управління — ніхто не знає. І аудитор точно запитає.
5. Розрив у навчанні команди
Кожен інструмент розробляє власну підгрупу «експертів» у команді. Коли ключова людина звільняється — знання йдуть разом із нею.
Типові провали аудиту через фрагментацію
Сценарій 1: «Ми не знали, що там є PII»
Аудитор знаходить PII у системі, яку компанія вважала безпечною. Чому? Тому що ця система не підключена до жодного з DLP-інструментів.
Сценарій 2: «Ми думали, що воно зашифровано»
Одна команда встановила шифрування, але оновлення компонента його відключило. Ніхто не помітив, бо система моніторингу відстежувала лише первинне налаштування.
Сценарій 3: «Наші журнали не охоплюють цей період»
Строки зберігання журналів у різних системах відрізняються. Аудитор запитує дані за 18 місяців, але журнали з одного інструменту зберігаються лише 12 місяців.
Сценарій 4: «Різні відповіді від різних команд»
ІТ-відділ: «Дані зашифровані». Юридична команда: «Ці документи обробляються вручну». Команда безпеки: «DLP охоплює 85% трафіку».
Аудитор чує суперечливі версії і починає глибше копати.
Шляхи до уніфікованої стратегії
1. Єдина таксономія PII
Перший крок — визначити, що є PII для вашої організації, і застосовувати цю класифікацію однаково в усіх інструментах.
Приклад єдиної таксономії:
| Категорія | Типи даних | Рівень захисту |
|---|---|---|
| Ідентифікатори | ПІБ, email, телефон, адреса | Стандартний |
| Урядові ідентифікатори | SSN, паспорт, ІПН | Підвищений |
| Фінансові дані | IBAN, картки, рахунки | Підвищений |
| Медичні дані | Діагнози, ліки, PHI | Максимальний |
2. Єдиний журнал аудиту
Агрегування журналів з усіх інструментів в єдину SIEM-систему (Security Information and Event Management):
- Нормалізований формат (CEF або JSON)
- Єдині строки зберігання (відповідно до вимог GDPR)
- Кореляція подій між системами
3. Централізоване управління политиками
Єдина система управління политиками, з якої всі інструменти отримують правила:
- Зміна политики реалізується скрізь одночасно
- Немає «тіньових» правил у окремих інструментах
- Versioning политик для аудиту
4. API-first підхід
Вибирайте інструменти з відкритим API, що дозволяє:
- Єдину точку входу для всіх PII-запитів
- Програмну конфігурацію (Infrastructure as Code)
- Автоматизоване тестування відповідності
5. Platform Consolidation
У довгостроковій перспективі — консолідація кількох інструментів на одній платформі. Менша кількість інструментів = менше «щілин», простіша документація, нижча загальна вартість.
Висновок
Фрагментація інструментів PII — системна проблема, що провалює аудити не через технічні вади окремих інструментів, а через відсутність узгодженості між ними.
Рішення не в заміні всіх інструментів одразу (це нереалістично), а в побудові уніфікованого рівня управління над існуючими рішеннями: спільна таксономія, єдиний журнал аудиту, централізовані политики.
Джерела: