Как настроить работу с GDPR

Многие компании, которые работают с клиентами из Евросоюза, столкнулись с регулированием GDPR, вступившим в силу 25 мая 2018 года. KeepSolid — мультипродуктовая компания, а это значит, что нам пришлось разрабатывать решение, которое позволит выполнять требования GDPR как для отдельного продукта, так и для аккаунта в целом (KeepSolid ID).

Нормы GDPR обязывают компанию предоставлять конечному пользователю возможность:

1. Полностью удалить свой аккаунт из сервиса.
2. Получить экспорт всех хранящихся данных аккаунта.

Немного статистики: в среднем в месяц мы получаем 3500 запросов на удаление аккаунта и 800 запросов на экспорт данных.

Потенциальная проблема была в том, что каждый продукт — это своя отдельная экосистема с своим набором сервисов, API и т.д. А еще были следующие ограничения:

1. Операции GDPR могут выполняться не мгновенно — особенно экспорт данных.
2. В момент, когда пользователь запрашивает операцию в рамках GDPR, API одного из продуктов может быть недоступен.
3. Один из продуктов должен отвечать за GDPR в целом, уведомлять о проблемах и обслуживать все операции.

Самый простой вариант реализации поддержки GDPR — отправка синхронных запросов каждому продукту, ожидание результатов ответов и отправка ответа пользователю. Но такой подход не проходит ни по одному из ограничений, которые я указал выше.

Учитывая все ограничения, мы решили реализовать шину данных на очередях. Основные сервисы, которые участвуют в реализации GDPR, такие:

1. Персональный кабинет пользователя — отправная точка. Тут пользователь может выбрать все или каждый продукт в отдельности для экспорта или удаления данных.
2. GDPR Command Service — сервис, который управляет всеми операциями GDPR.
3. KeepSolid API — основной API для управления KeepSolid-аккаунтом.

В качестве транспорта сообщений был выбран RabbitMQ — благодаря удобному функционалу маршрутизации по разным очередям. Для временного хранилища данных экспорта используем Amazon S3.

Для примера рассмотрим обобщенную диаграмму активности GDPR-операции продукта VPN Unlimited:

1. Пользователь выбирает тип GDPR-операции и продукты, по которым хочет получить результат.
2. Personal Office отправляет первичный запрос на основной API KeepSolid.
3. Пользователь получает ответ «Ваш запрос поступил в обработку».
4. KeepSolid API формирует запрос с списком сервисов пользователя и другой полезной нагрузкой.
5. Отправляем все данные в GDPR Service.
6. GDPR Service сохраняет в базе состояние GDPR-операции и по отдельности состояния указанных продуктов.
7. Отправляем сформированные сообщения в IN Exchange, маршрутизация при этом осуществляется с помощью routing key (см. иллюстрацию ниже).
8. RabbitMQ, используя routing key, переадресовывает сообщение с GDPR-операцией продукта VPN Unlimited в нужную очередь.
9. На стороне продукта VPN Unlimited запущен слушатель очереди, который вычитывает из нее сообщения.
10. Слушатель обрабатывает GDPR-запрос, формирует полезную нагрузку, в случае экспорта — формирует файл и выгружает его на S3. Также на этом этапе формируется ответное сообщение, которое содержит: успешность операции, полезную нагрузку, ошибки в случае провала.
11. Отправляем сообщение в общую очередь ответов.
12. GDPR Service вычитывает очередь ответов от продуктов.
13. Обновляем состояния операций по продуктам и GDPR-операции в целом.

В дальнейшем логика работы GDPR Service довольно проста. Если все сервисы отвечают успешно — формируется запрос с полезной нагрузкой для пользователя, и ему отправляется письмо через сервис рассылки. В случае же если GDPR операция не была финализирована в течение 24 часов, GDPR Service уведомляет backend-отдел об ошибке.

Плюсы и минусы нашего подхода

Плюсы:

1. Асинхронность обработки запросов.
2. Отказоустойчивость и возможность масштабирования. Каждый сервис ответствен только за свою часть.
3. Довольно быстрая расширяемость за счет централизованности основных операций.

Минусы:

1. Зависимость от инфраструктуры. В случае если RabbitMQ не доступен из «мира», а есть продукт, который размещается в другой экосистеме (например, в облаке), необходимо создавать промежуточного GDPR Worker.
2. Согласованность формата сообщений в очередях.

Итог

В итоге такая реализация стала для нас первой и единственной — мы практически не столкнулись с проблемами GDPR. Мониторинг работает исправно, и если сервис конкретного продукта не смог совершить GDPR-операцию, это всегда можно оперативно починить вручную или изменить бизнес-логику обработки в конкретном продукте.