Реалізація анонімізації/псевдонімізації даних у мобільному додатку
Анонімізація та псевдонімізація — два різні інструменти з різними правовими наслідками. Анонімізовані дані виходять з-під дії GDPR повністю: якщо дані не можна пов'язати з особистістю при розумних усиллях — регулятор не вимагає їх захисту. Псевдонімізовані дані GDPR все ще регулює, але зі знизженими вимогами. Плутати їх — типова помилка при проектуванні.
Анонімізація: коли та як
Справжня анонімізація в продуктових системах зустрічається рідко — тому що повна анонімізація зазвичай убиває цінність даних. Але вона оправдана в двох сценаріях: аналітичні агрегати (DAU, retention по когортам) та архівні дані після істечення retention period.
k-anonymity — базовий метод: набір записів анонімен, якщо кожен запис неотличим від мінімум k-1 інших за quasi-ідентифікаторами (вік, регіон, пристрій). При k=5: якщо в когорті «iOS, Москва, 25-30» менш 5 користувачів — не публікуємо цю когорту.
Для мобільної аналітики: при експорті сирих событий в Data Warehouse — узагальнюємо IP до /24 підсети, вік до діапазонів, видаляємо точні координати, замінюємо device_id на щодня ротуваний hashed ID.
Псевдонімізація на практиці
Псевдонімізація — заміна прямих ідентифікаторів (email, phone, name) на обратимі суррогати з хранінням ключа окремо. У контексті мобільного бекенда:
Зберігання даних:
-- Основна таблиця — тільки псевдонімізовані дані
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)
Основна БД обробляє 99% операцій з pseudonym_id. Реальні дані запитуються з vault тільки при явній необхідності (відправити email, показати ім'я у профілі).
Технічні методи на рівні додатку
Токенізація для номерів карт та чутливих фінансових даних: реальне значення замінюється маркером, який зберігається в ізольованому token vault (PCI DSS scope). Мобільний додаток працює тільки з маркером.
Hashing з сіллю для аналітичних ID:
// 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 ATT та Android Privacy Sandbox.
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();
Анонімізація замість видалення зберігає статистику (кількість событий по типу) при утраті зв'язку з користувачем.
Особливості мобільного клієнта
На клієнті ніколи не кешувати расшифровані персональні дані в UserDefaults або SharedPreferences. Якщо потрібен офлайн-доступ до профілю — шифруємо через Keychain/Android Keystore (AES-GCM, ключ у TEE). При logout — видаляємо зашифрований blob.
Псевдонімізація на клієнті: для відправки аналітичних событий — використовуємо тільки analytics_id (hashed, rotating), не user_id. Якщо analytics SDK (Firebase, Amplitude) вимагає user_id — передаємо pseudonym, а не реальний ідентифікатор.
Терміни — 2–3 дні: проектування схеми псевдонімізації, реалізація vault-шару, настройка retention jobs, оновлення аналітичного шару на клієнті.