25 мая 2018 года GDPR (Общий регламент по защите данных) наделал немало шума. Документ вступил в силу на всей территории Европейского союза. В нем прописаны требования к обеспечению защиты хранения и использования данных юзеров. GDPR распространяется на все компании, на чьи сайты или в чьи приложения заходят граждане ЕС.
Если вашим аппом пользуется хоть один резидент Европы, будьте добры придерживаться регламента. В противном случае вам грозит внушительный штраф. С вас сдерут либо 4% годового оборота, либо 20 млн евро (в зависимости от того, какая сумма больше).
Прошел практически год с момента выхода пугающего документа. За это время компания AppFox выпустила несколько аппов на западный рынок. Сегодня публикуем подробный список обязательных шагов для подгонки приложения под требования GDPR, но сперва определимся с терминологией.
Основные термины GDPR
Контроллер данных - это субъект (физическое или юридическое лицо), который определяет цели и средства сбора и обработки персональных данных. Если у вас есть веб-сайт или мобильное приложение, и вы решаете, что, как и зачем собирать, вы – контролер.
Обработчик данных - это организация, обрабатывающая личные данные от имени контроллера. Например, сторонние сервисы, которые подключаются к вашему веб-сайту или приложению: Google Analytics, KISSMetrics, облачные сервисы (AWS) и т. д.
Субъект данных - физическое лицо, данные которого обрабатываются. Например, пользователь приложения или посетитель сайта.
Персональные данные – любая информация, касающаяся субъекта данных, которая может его прямо или косвенно идентифицировать. Определение включает в себя широкий спектр понятий начиная от имени и email, заканчивая файлами cookie.
Полный список терминов вы найдете в статье 4 GDPR.
Все разработчики мобильных приложений должны корректно получать, передавать, хранить и обрабатывать персональные данные. Важно гарантировать юзерам безопасность.
Давайте последовательно рассмотрим 3 аспекта соответствия требованиям GDPR:
- дополнительные функции, которые необходимо реализовать в приложении;
- обеспечение защиты данных;
- типичные ошибки разработчиков.
11 функций приложения, соответствующего GDPR
1. Забудьте меня
У вас должен быть предусмотрен алгоритм, который принимает userId и удаляет все личные данные пользователя. Сложность реализации тесно связана с видом базы данных.
Удалить записи из обычной модели сравнительно просто, но при этом могут «отвалиться» некоторые внешние ключи. В этом случае есть 2 варианта: либо убедиться, что внешние ключи поддерживают обнуление, либо почистить все связанные данные (например, через каскадное удаление).
Намного сложнее реализовать функцию «Забудьте меня» в модели с источником событий, а также в структурах с блокчейн/хешчейн или опциями защиты от несанкционированного доступа. Теоретически вы можете удалить прошедшее событие и сгенерировать промежуточные заново или использовать хеш-функции хамелеоны.
2. Уведомить третьи стороны об удалении
Почистить собственную базу – лишь полдела. Удаляя объекты из вашей системы, не забывайте уведомить третьи стороны. Если вы отправляли персональные данные обработчикам, например, Salesforce, Hubspot, Twitter, вам следует запросить у них API, позволяющее стирать информацию о пользователях.
3. Ограничить обработку
В панели администратора в списке юзеров нужно предусмотреть опцию «Ограничить обработку». На страницу настроек пользователя следует поместить кнопку, нажав на которую и прочитав справку, человек сможет подать запрос на ограничение обработки личной информации. После подтверждения администратором, персональные данные станут непубличными.
4. Экспорт данных
На странице настроек также должна быть кнопка «Экспорт данных». Пользователь вправе потребовать предоставления полного списка информации о нем, которая хранится в вашей базе, с перечнем пояснений, с какой целью происходит сбор данных. Формат передачи - XML / JSON.
5. Разрешить пользователям редактировать профиль
Казалось бы, разрешение редактирования – очевидная функция, но ее внедряют далеко не все разработчики. Согласно GDPR, пользователи должны иметь возможность исправить все данные о них, в том числе собранные из других источников. Например, при авторизации через аккаунт Facebook в вашу базу может автоматически подтягиваться имя и email.
6. Чек-боксы согласия
Фразы «Я принимаю условия и положения» уже недостаточно для подтверждения согласия на обработку персональных данных. Для каждого конкретного процесса обработки нужно предусмотреть отдельный чек-бокс на экране регистрации. По умолчанию они должны быть неактивны. То есть юзер должен самостоятельно проставить «галочки».
7. Повторный запрос согласия
Если ваше приложение выпущено до 25 мая 2018 года и пользователи давали согласие неочевидно (т.е. не так как описано в пункте выше), вам придется повторно запросить разрешение на обработку. Первый вариант - сделать рассылку по базе email со ссылкой на страницу активации (крайне неэффективно). Второй – выпустить обновление с отображением чек-боксов при первом входе после апдейта.
8. Просмотреть все данные
Опция очень похожа на «Экспорт», за исключением того, что данные должны отображаться в пользовательском интерфейсе приложения, а не передаваться в формате XML / JSON. Важно, чтобы запрос на просмотр могли делать незарегистрированные пользователи.
9. Проверка возраста
Если приложением пользуются лица младше 16 лет, нужно получить разрешение от родителей. Мы до сих пор не нашли оптимального способа выполнения этого требования GDPR. Пока просим указать email опекунов и производим рассылку. Чисто технически апп соответствует регламенту, в реальности – нам не пришло ни одного ответа.
10. Ограниченный срок хранения
Собирая данные для определенных нужд (например, отправка квитанции о покупке в приложении), вы обязаны удалить информацию сразу же после совершения целевого действия.
11. Файлы cookie
На данный момент достаточно простого предупреждения с кнопками «Согласиться» / «Отказаться». Но ходит слух, что требование пересмотрят к концу 2019 года.
Защита данных в приложениях, соответствующих GDPR
Обязательные защитные меры:
- Шифрование данных в пути. Все контакты между сервером и приложением должны идти через TLS.
- Шифрование данных в состоянии покоя. Закрытый ключ может храниться у вас или на каком-либо облачном сервисе.
- Шифрование резервных копий. Без комментариев.
- Использование псевдонимов. Вы можете изменять часть персональных данных на «псевдонимы» для тестовых/промежуточных серверов.
- Защита целостности данных. Достаточно обширная тема, которую невозможно описать в пере слов. Самый известный способ реализации – проверка с использованием хеш-суммы.
- Ведение реестра деятельности по обработке персональных данных. Статья GDPR №30 обязует вас вести учет всех активностей, для которых вы используете личную информацию.
- Ведение журнала доступа к персональным данным. Все запросы к информации о пользователях должны автоматически регистрироваться. Так вы будете точно знали, кто и зачем интересовался персональными данными.
- Регистрация всех пользователей API.Ни в коем случае не разрешайте анонимный доступ по API к личным данным. Вы должны запрашивать название организации, контакты уполномоченных лиц и цель обращения к информации о юзерах.
5 типичных ошибок разработчиков
1. Несанкционированное использование данных
Вы обязаны использовать данные только для тех целей, с которыми согласились пользователи. Подумайте дважды, если хотите добавить дополнительные методы монетизации или начать обучать искусственный интеллект по информации о поведении юзеров. Вы должны сообщать о каждом таком нововведении и запрашивать разрешение. Возможно, обычный человек не заметит несанкционированного использования, но проверять ваш апп будут специалисты.
2. Передача всей информации обработчикам
Удаление информации со сторонних серверов – утомительная, а порой и невозможная процедура. Сократите до необходимого минимума объем передаваемых данных. В идеале – ограничьтесь ID.
3. Лишние поля в форме регистрации
Дизайнеры – стремятся сделать красиво, маркетологи – стараются собрать как можно больше точек контакта. Сохраняйте баланс между разработкой, UI/UX, отделом продаж и требованиями GDPR. Не собирайте лишние данные, например, домашний номер телефона, по которому можно вычислить адрес.
4. Сотрудничество с недобросовестными обработчиками
Помните, вы несете ответственность за разглашение данных сторонними организациями, если вы передаете им информацию. Спросите у обработчика, какие у него внедрены меры защиты и соответствует ли он требованиям GDPR.
5. Слепая вера в ISO XXX
Наличие ISO XXX – покрывает только 70% правил GDPR, что нисколько не снижает риск получения штрафа.
Заключение
Введение регламента – оправданная мера, призванная повысить ответственность разработчиков. Последовав нашим рекомендациям, вы создадите надежный продукт, достойный доверия. Это вам на руку, ведь в Европе царит настоящая паранойя на безопасность и конфиденциальность. Вы можете внести соответствие GDPR в перечень положительных сторон вашего продукта и повысить лояльность целевой аудитории.
