Реализация анонимизации/псевдонимизации данных в мобильном приложении
Анонимизация и псевдонимизация — два разных инструмента с разными правовыми последствиями. Анонимизированные данные выходят из-под действия GDPR полностью: если данные нельзя связать с личностью при разумных усилиях — регулятор не требует их защиты. Псевдонимизированные данные GDPR всё ещё регулирует, но снижает требования к их защите. Путать их — типичная ошибка при проектировании.
Анонимизация: когда и как
Настоящая анонимизация в продуктовых системах встречается редко — потому что полная анонимизация обычно убивает ценность данных. Но она оправдана в двух сценариях: аналитические агрегаты (DAU, retention по когортам) и архивные данные после истечения retention period.
k-anonymity — базовый метод: набор записей анонимен, если каждая запись неотличима от минимум k-1 других по квазиидентификаторам (возраст, регион, устройство). При 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, обновление аналитического слоя на клиенте.