Многие компании, которые работают с клиентами из Евросоюза, столкнулись с регулированием GDPR, вступившим в силу 25 мая 2018 года. KeepSolid — мультипродуктовая компания, а это значит, что нам пришлось разрабатывать решение, которое позволит выполнять требования GDPR как для отдельного продукта, так и для аккаунта в целом (KeepSolid ID).
Нормы GDPR обязывают компанию предоставлять конечному пользователю возможность:
- Полностью удалить свой аккаунт из сервиса.
- Получить экспорт всех хранящихся данных аккаунта.
Немного статистики: в среднем в месяц мы получаем 3500 запросов на удаление аккаунта и 800 запросов на экспорт данных.
Потенциальная проблема была в том, что каждый продукт — это своя отдельная экосистема с своим набором сервисов, API и т.д. А еще были следующие ограничения:
- Операции GDPR могут выполняться не мгновенно — особенно экспорт данных.
- В момент, когда пользователь запрашивает операцию в рамках GDPR, API одного из продуктов может быть недоступен.
- Один из продуктов должен отвечать за GDPR в целом, уведомлять о проблемах и обслуживать все операции.
Самый простой вариант реализации поддержки GDPR — отправка синхронных запросов каждому продукту, ожидание результатов ответов и отправка ответа пользователю. Но такой подход не проходит ни по одному из ограничений, которые я указал выше.
Учитывая все ограничения, мы решили реализовать шину данных на очередях. Основные сервисы, которые участвуют в реализации GDPR, такие:
- Персональный кабинет пользователя — отправная точка. Тут пользователь может выбрать все или каждый продукт в отдельности для экспорта или удаления данных.
- GDPR Command Service — сервис, который управляет всеми операциями GDPR.
- KeepSolid API — основной API для управления KeepSolid-аккаунтом.
В качестве транспорта сообщений был выбран RabbitMQ — благодаря удобному функционалу маршрутизации по разным очередям. Для временного хранилища данных экспорта используем Amazon S3.
Для примера рассмотрим обобщенную диаграмму активности GDPR-операции продукта VPN Unlimited:
- Пользователь выбирает тип GDPR-операции и продукты, по которым хочет получить результат.
- Personal Office отправляет первичный запрос на основной API KeepSolid.
- Пользователь получает ответ «Ваш запрос поступил в обработку».
- KeepSolid API формирует запрос с списком сервисов пользователя и другой полезной нагрузкой.
- Отправляем все данные в GDPR Service.
- GDPR Service сохраняет в базе состояние GDPR-операции и по отдельности состояния указанных продуктов.
- Отправляем сформированные сообщения в IN Exchange, маршрутизация при этом осуществляется с помощью routing key (см. иллюстрацию ниже).
- RabbitMQ, используя routing key, переадресовывает сообщение с GDPR-операцией продукта VPN Unlimited в нужную очередь.
- На стороне продукта VPN Unlimited запущен слушатель очереди, который вычитывает из нее сообщения.
- Слушатель обрабатывает GDPR-запрос, формирует полезную нагрузку, в случае экспорта — формирует файл и выгружает его на S3. Также на этом этапе формируется ответное сообщение, которое содержит: успешность операции, полезную нагрузку, ошибки в случае провала.
- Отправляем сообщение в общую очередь ответов.
- GDPR Service вычитывает очередь ответов от продуктов.
- Обновляем состояния операций по продуктам и GDPR-операции в целом.
В дальнейшем логика работы GDPR Service довольно проста. Если все сервисы отвечают успешно — формируется запрос с полезной нагрузкой для пользователя, и ему отправляется письмо через сервис рассылки. В случае же если GDPR операция не была финализирована в течение 24 часов, GDPR Service уведомляет backend-отдел об ошибке.
Плюсы и минусы нашего подхода
Плюсы:
- Асинхронность обработки запросов.
- Отказоустойчивость и возможность масштабирования. Каждый сервис ответствен только за свою часть.
- Довольно быстрая расширяемость за счет централизованности основных операций.
Минусы:
- Зависимость от инфраструктуры. В случае если RabbitMQ не доступен из «мира», а есть продукт, который размещается в другой экосистеме (например, в облаке), необходимо создавать промежуточного GDPR Worker.
- Согласованность формата сообщений в очередях.
Итог
В итоге такая реализация стала для нас первой и единственной — мы практически не столкнулись с проблемами GDPR. Мониторинг работает исправно, и если сервис конкретного продукта не смог совершить GDPR-операцию, это всегда можно оперативно починить вручную или изменить бизнес-логику обработки в конкретном продукте.
Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: