Configuration Drift та ризики відповідності GDPR: Як непомічені зміни створюють порушення

Що таке Configuration Drift

Configuration drift — це поступова, часто непомічена розбіжність між фактичним станом системи та її задокументованим або бажаним станом.

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

Типові приклади:

• IAM-роль, що розширилася через «тимчасовий» доступ для налагодження виробничої проблеми 8 місяців тому
• S3-бакет, де публічний доступ увімкнено для швидкого шерингу файлів і ніколи не вимкнено
• Логи, що містять PII через новий рядок налагодження, доданий розробником
• Retention policy, що була змінена з «90 днів» на «нескінченно» для аналітичного дашборду
• Шифрування, деактивоване «тимчасово» через проблему з продуктивністю

Чому GDPR робить Drift особливо небезпечним

GDPR ґрунтується на принципі підзвітності (ст. 5(2)): контролер не просто повинен дотримуватися GDPR, він повинен довести дотримання. Це означає, що:

1. Документована відповідність ≠ фактична відповідність
2. Регулятори перевіряють реальний стан систем, не лише документи
3. Порушення, спричинені дрейфом, трактуються як системні (не одноразові), що збільшує штрафи

Стаття 25 вимагає «Privacy by Design та by Default» — тобто технічні заходи захисту повинні бути вбудовані і підтримуватися постійно, а не лише на момент аудиту.

Найнебезпечніші вектори Configuration Drift

1. Права доступу та IAM

Що дрейфує: Принцип мінімальних привілеїв (least privilege) поступово розширюється.

Як це відбувається:

• «Тимчасовий» адміністративний доступ для співробітників, що ніколи не скасовується
• Групові ролі, що розширюються без відповідної документації
• Сервісні акаунти з надмірними правами
• Права колишніх співробітників, не деактивовані вчасно (порушення ст. 32)

Наслідки GDPR: Неавторизований доступ до PII є порушенням принципу цілісності та конфіденційності (ст. 5(1)(f)).

2. Логування та моніторинг

Що дрейфує: Налаштування логів поступово включають все більше PII.

Як це відбувається:

• debug: true залишається у продакшн середовищі
• Новий middleware логує всі параметри запитів (включно з PII)
• Error tracking (Sentry, Datadog) перехоплює stack traces з PII

Ознака проблеми: Audit log вашої системи містить email-адреси, IP-адреси або будь-яку іншу PII.

3. Data Retention

Що дрейфує: Строки зберігання даних збільшуються або скасовуються.

Як це відбувається:

• Cron job для очищення старих даних видалено під час рефакторингу
• S3 lifecycle policy перезаписана при оновленні інфраструктури
• «Архівні» таблиці в БД, що ніколи не видаляються
• Резервні копії, що зберігаються довше, ніж основні дані

Наслідки GDPR: Порушення принципу обмеження зберігання (ст. 5(1)(e)).

4. Шифрування та TLS

Що дрейфує: Застарілі протоколи залишаються активними.

Як це відбувається:

• TLS 1.0/1.1 залишені для підтримки «застарілих клієнтів»
• Ключі шифрування не ротуються
• Нові компоненти системи додаються без шифрування у стані спокою

5. Маскування/анонімізація в середовищах

Що дрейфує: Реальні дані витікають у dev/staging середовища.

Як це відбувається:

• Щотижневий dump prod БД у staging «для реалістичного тестування»
• Скопійовані prod-конфіги без маскування PII
• Завантажені реальні файли клієнтів для тестування нової функції

Виявлення Configuration Drift

Автоматизовані рішення

Infrastructure as Code (IaC):

# Terraform drift detection
terraform plan -refresh=true

# AWS Config Rules для PII-захисту
aws configservice describe-config-rules --query 'ConfigRules[?ConfigRuleName==`restricted-ssh`]'

Інструменти:

• AWS Config — моніторинг змін конфігурацій у реальному часі
• HashiCorp Terraform + Sentinel — enforce policy as code
• Chef InSpec / OpenSCAP — compliance as code
• Datadog / Prometheus — моніторинг метрик безпеки

Ручні аудити для GDPR

Щомісячний чеклист:

Ознаки проблем, що сигналізують про Drift

1. «Ми не знаємо, чому цей доступ налаштований»
2. «Це з'явилося під час оновлення X місяців тому»
3. «Ми плануємо виправити це наступного спринту» (вже 6 місяців)
4. Різниця між тим, що описано в ROPA, і реальним станом систем

Управління Drift у контексті GDPR

Реєстр змін (Change Management)

Кожна зміна, що впливає на обробку PII, повинна:

1. Бути задокументована
2. Пройти security review
3. Бути відображена в ROPA (Record of Processing Activities)
4. Мати план відкату

Privacy Impact Assessment для змін

Навіть «маленькі» технічні зміни можуть мати наслідки для конфіденційності:

• Нова бібліотека логування → перевірте, що логує
• Зміна хмарного провайдера → перевірте угоди щодо даних
• Оновлення analytics → перевірте, які дані збираються

Continuous Compliance Monitoring

Впровадьте GDPR-specific monitors:

• Алерт, якщо у логах знайдено email-адресу або SSN
• Алерт, якщо retention policy змінена без погодження
• Алерт, якщо новий S3 бакет без шифрування
• Регулярне автоматичне сканування PII у тестових середовищах

Висновок

Configuration drift — тиха загроза відповідності GDPR. Системи, що відповідали вимогам при впровадженні, поступово деградують через звичайні операційні зміни.

Вирішення — не разовий аудит, а безперервний моніторинг: IaC, automated compliance checks, і культура «compliance as code», де захисні заходи перевіряються автоматично при кожній зміні.

Джерела:

• ENISA — Заходи безпеки відповідно до GDPR
• EDPB — Підзвітність і управління