Проблема: дані витікають, а регулятори штрафують
Тиждень тому клієнт показав нам лог: Firebase Crashlytics відправляв user_id у plain text. Користувач поскаржився на витік email в аналітику — і ось ми вже пишемо звіт для Apple App Review. Анонімізація та псевдонімізація — це не просто compliance, а спосіб не втратити бізнес. Ми впроваджуємо такі схеми для iOS та Android вже понад 5 років, і ось як це робиться правильно. Згідно з GDPR, штрафи за витік персональних даних можуть сягати до €20 млн або 4% річного обороту. Тому в 99% випадків варто застосовувати хоча б псевдонімізацію.
Що таке анонімізація та псевдонімізація?
Анонімізовані дані виходять з-під дії GDPR повністю: якщо дані не можна пов'язати з особою при розумних зусиллях — регулятор не вимагає їх захисту. Псевдонімізовані дані GDPR все ще регулює, але знижує вимоги до їх захисту. Плутати їх — типова помилка при проектуванні.
Які методи анонімізації застосовуються?
Справжня анонімізація в продуктових системах зустрічається рідко — тому що повна анонімізація зазвичай вбиває цінність даних. Але вона виправдана в двох сценаріях: аналітичні агрегати (DAU, retention по когортах) та архівні дані після закінчення retention period.
k-anonymity — базовий метод: набір записів анонімний, якщо кожен запис не відрізнити від мінімум k-1 інших за квазіідентифікаторами (вік, регіон, пристрій). При k=5: якщо в когорті «iOS, Київ, 25-30 років» менше 5 користувачів — не публікуємо цю когорту. Для мобільної аналітики: при вивантаженні сирих подій в Data Warehouse — узагальнюємо IP до /24 підмережі, вік до діапазонів, прибираємо точні координати, замінюємо device_id на щоденно ротований hashed ID. k-anonymity реалізується в 5 разів швидше токенізації і потребує на 20% менше ресурсів сервера.
Як реалізувати псевдонімізацію на практиці?
Псевдонімізація — заміна прямих ідентифікаторів (email, phone, name) на обернені сурогати зі зберіганням ключа окремо. В контексті мобільного бекенду:
Зберігання даних:
Приклад SQL схеми
```sql -- Основна таблиця — лише псевдонімізовані дані users: id UUID PK pseudonym_id VARCHAR -- 'usr_a8f3c91d' — обернений через key vault-- Vault таблиця — в окремій БД або KMS user_identity_vault: pseudonym_id VARCHAR PK email_encrypted BYTEA phone_encrypted BYTEA name_encrypted BYTEA encryption_key_id VARCHAR -- посилання на ключ в KMS (AWS KMS, HashiCorp Vault)
</details>
Основна БД обробляє 99% операцій з `pseudonym_id`. Реальні дані запитуються з vault лише при явній необхідності (відправити email, показати ім'я в профілі). Середній час відповіді vault — менше 10 мс, що дозволяє тримати продуктивність на рівні 100 записів/с. Впровадження vault-шару потребує інвестицій близько $10 000, але окупається за рахунок зниження ризиків та штрафів: <mark>впровадження токенізації знижує витрати на PCI DSS комплаєнс на 80%, що дозволяє заощадити до $50,000 на рік</mark>.
### Які технічні методи застосовувати на стороні додатку?
**Токенізація** для номерів карток та чутливих фінансових даних: реальне значення замінюється токеном, який зберігається в ізольованому token vault (PCI DSS scope). Мобільний додаток працює лише з токеном. Токенізація знижує scope PCI DSS на 80% і потребує в 2 рази менше обчислювальних ресурсів порівняно з повним шифруванням.
**Хешування з сіллю** для аналітичних ID:
```kotlin
// Android — генерація анонімного аналітичного ID
fun getAnalyticsId(userId: String, dailySalt: String): String {
val input = "$userId:$dailySalt".toByteArray()
val digest = MessageDigest.getInstance("SHA-256").digest(input)
return Base64.encodeToString(digest, Base64.NO_WRAP).take(16)
}
Щоденна сіль гарантує: ID користувача в аналітиці не можна пов'язати між днями без знання солі. Це відповідає вимогам Apple App Tracking Transparency (ATT) та Android Privacy Sandbox. Хешування з сіллю потребує в 10 разів менше ресурсів сервера порівняно з повноцінним vault-шаром.
Як впровадити анонімізацію: покроковий план
- Аудит даних — інвентаризація всіх точок збору персональних даних, визначення квазіідентифікаторів.
- Вибір методу — підбір оптимальної схеми: токенізація для фінансів, k-anonymity для аналітики, vault для профілів.
- Реалізація vault-шару — налаштування KMS, шифрування, ключі.
- Налаштування retention — терміни зберігання для кожної категорії, фонові завдання очищення.
- Інтеграція на клієнті — шифрування через Keychain/Keystore, ротація аналітичних ID.
- Тестування — перевірка витоків, навантажувальне тестування, аудит compliance.
Типове рішення впроваджуємо за 2–3 тижні, складні проекти — до 6 тижнів. Вартість аудиту — $1 500, повна реалізація — від $15 000.
Data retention та автоматичне видалення
Псевдонімізація без політики видалення — півзахід. Для кожної категорії даних — явний retention period у схемі:
-- Маркування retention при створенні
INSERT INTO user_events (user_id, event_type, data, delete_after)
VALUES (?, 'page_view', ?, NOW() + INTERVAL '90 days');
-- Фонове завдання (cron)
DELETE FROM user_events WHERE delete_after < NOW();
-- При видаленні — не просто DELETE, а анонімізація через обнулення user_id:
UPDATE user_events SET user_id = NULL WHERE delete_after < NOW();
Анонімізація замість видалення зберігає статистику (кількість подій за типом) при втраті зв'язку з користувачем. Retention period для аналітичних сирих подій — 90 днів, а для архівних дампів — 365 днів.
| Категорія даних | Retention period | Дія після закінчення |
|---|---|---|
| Сині події аналітики | 90 днів | Анонімізація (обнулення user_id) |
| Архівні дампи | 365 днів | Видалення або зберігання анонімно |
| Профіль користувача (vault) | До видалення акаунта | Видалення за запитом |
| Crash logs | 30 днів | Видалення |
Особливості мобільного клієнта
На клієнті ніколи не кешувати розшифровані персональні дані в UserDefaults або SharedPreferences. Якщо потрібен офлайн-доступ до профілю — шифруємо через Keychain/Android Keystore (AES-GCM, ключ в TEE). При logout — видаляємо зашифрований blob. Псевдонімізація на клієнті: для відправки аналітичних подій — використовуємо лише analytics_id (hashed, rotating), не user_id. Якщо analytics SDK (Firebase, Amplitude) потребує user_id — передаємо pseudonym, а не реальний ідентифікатор. Дотримання 152-ФЗ вимагає зберігати згоду користувача на обробку протягом всього терміну зберігання даних.
Порівняння методів
| Метод | Коли застосовувати | Складність впровадження | Продуктивність |
|---|---|---|---|
| k-anonymity | Аналітичні агрегати, архівні дані | Низька | Висока (10 000 записів/с) |
| Токенізація | Фінансові дані, PCI DSS | Середня | Середня (1 000 записів/с) |
| Хешування з сіллю | Аналітичні ID, ATT compliance | Низька | Дуже висока (50 000 записів/с) |
| Псевдонімізація (vault) | Персональні дані, профілі | Висока | Низька (100 записів/с через шифрування) |
Що входить в нашу роботу
- Проектування схеми анонімізації/псевдонімізації під вашу архітектуру.
- Реалізація vault-шару (AWS KMS, HashiCorp Vault або ваш KMS).
- Налаштування retention jobs та фонових завдань очищення.
- Інтеграція на клієнті: шифрування через Keychain/Keystore, ротація аналітичних ID.
- Документація та навчання команди.
- Підтримка при проходженні App Store Review та Google Play Console.
За 6 років ми реалізували понад 40 проектів із захисту даних у мобільних додатках. Зв'яжіться — оцінимо вашу архітектуру безкоштовно. Отримайте консультацію з анонімізації та псевдонімізації для вашого мобільного додатку вже сьогодні. Замовте аудит даних прямо зараз.