Разработка приложений и GDPR: гайд и чек-лист

Разберёмся, что GDPR изменил для разработчиков приложений и как взаимодействовать с европейской аудиторией, не рискуя деньгами.

Положения регламента (GDPR) нацелены на одно — дать гражданам ЕС больше контроля над персональными данными (ПД). Ответственность за исполнение регламента лежит на тех, кто обрабатывает эти данные. Это — в том числе и издатели приложений. Чтобы напомнить суть GDPR (полный текст — по этой ссылке), мы выписали, основные требования регламента:

С точки зрения проектирования приложений для любых платформ GDPR диктует несколько общих задач относительно работы с персональными данными. Фактически он потребует создания дорожной карты для работы с ПД. Она даст понимание того, какие данные в случае с вашим приложением можно отнести к ПД, где нужно их хранить и обрабатывать, как будет организована защита и доступ к этим данным.

Кратко о том, что вам потребуется сделать:

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

Например, европейский стартап Teemo, собирающий данные о местоположении пользователей через сторонние приложения, не так давно попал в поле зрения властей ЕС. Причиной послужил тот факт, что сервис и его партнёры не получали явного согласия на обработку ПД — не было условного баннера, который бы информировал пользователей и собирал подтверждения.

Требование об информировании пользователей уже успело вызвать у всех раздражение, когда люди начали массово получать письма от издателей приложений и сервисов с запросом на такое подтверждение согласия обработки ПД. Но есть и менее очевидные нюансы, которые помогут избежать штрафов при работе с европейской аудиторией. Вот некоторые из них.

По-настоящему плохой пример обращения с ПД продемонстрировало приложение Консервативной партии Великобритании. В сентябре стало известно, что оно позволяло любому пользователю видеть личные телефоны и почты министров. В этом случае разработчики сознательно отправили данные в публичный доступ. Теперь их ждёт расследование комиссии.

В других случаях утечки происходят против воли разработчиков. Сведения попадают не в те руки непреднамеренно, но операторы ПД всё равно несут ответственность, так как они допустили слив. Чтобы минимизировать риски, лучше хранить данные в зашифрованном виде, В самом GDPR шифрование ПД приводится в качестве одной из мер их защиты. В таком случае важно сообщить пользователям, что их личные данные будут зашифрованы.

Недавно Google объявила о закрытии своей социальной сети Google+. Одной из причин послужили проблемы с безопасностью. Найденный в марте баг на протяжении нескольких лет позволял сторонним приложениям получать доступ к данным из профилей Google+.

Пользователи сами давали разрешение на автозаполнение полей в других сервисах, однако теперь такой подход не соответствует GDPR. В свете этого бага Google пересмотрела взгляды на доступ к данным пользователей. Теперь большинство сторонних приложений будут ограничены в доступе, например, к журналам вызовов и SMS.

Разработчикам есть смысл выяснить, как сторонние сервисы собирают данные из приложения. Если есть подозрение, что те нарушают GDPR, лучше ограничить им доступ. Помимо этого, есть риск потерять данные, пока те передаются из вашего приложения на партнёрскую платформу.

Это возвращает нас к разговору о хранении и обработке ПД в зашифрованном виде плюс шифровании канала связи. Как минимум здесь не повредит обновление SSL-сертификатов и переход на HTTPS. Это поможет не нарушить регламент.

В среднем одно приложение использует более 18 SDK (software development kit — комплект средств разработки). Если каждый из них в отдельности не нарушает положения регламента GDPR, в этом нет ничего страшного. Но так бывает не всегда — кейс уже упомянутого Teemo служит тому примером. Поэтому GDPR — хороший повод провести ревизию SDK для приложения.

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

Как только об этом стало известно, дело дошло до суда. В условиях GDPR такой кейс точно повлечёт за собой многомиллионные штрафы и дополнительные судебные иски.

Рассмотрим кейс с Facebook. Компания предлагает несколько сервисов авторизации пользователей в приложениях — Account Kit с регистрацией по номеру телефона и вход с помощью аккаунта соцсети. В октябре Facebook признала уязвимость, которая затронула 50 млн пользователей. Пользуясь багом, злоумышленники украли токены доступа, позволяющие аккаунтам оставаться авторизированными в соцсети без ввода пароля.

Вице-президент по управлению продуктами компании Facebook сообщил, что уязвимость, возможно, распространяется и на сторонние приложения, которые используют такие сервисы. Например, с помощью уязвимости Account Kit можно было получить доступ к учётным записям в Tinder.

Facebook сообщает разработчикам, что при использовании Account Kit издатель приложения остаётся обработчиком ПД и несёт ответственность за сохранность данных, согласно GDPR. Поэтому, выбирая систему авторизации стороннего разработчика, важно взвесить все риски и тщательно изучить возможные узкие места выбранного решения.

Некоторые приложения используют IP-адреса и данные о местоположении пользователя при авторизации. Это позволяет предотвратить попытки взлома аккаунтов. Разработчики должны знать несколько нюансов относительно этой и других функций, по которым можно установить местоположение человека.

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

Ещё до вступления в силу регламента приложения, собирающие и передающие геолокационные данные третьим лицам без явного согласия пользователей, попали под удар. Целый ряд такого ПО незадолго до принятия GDPR был удалён из App Store.

В то же время компании, собирающие данные в приложениях, начали перерабатывать свои продукты. Например, Factual, которая анализирует геолокационные данные из сторонних приложений, удалила базу со сведениями о европейских пользователях, чтобы после перестроить её в соответствии с требованиями GDPR.

Некоторые компании не успели залатать дыры в системе сбора данных о местоположении пользователей, и теперь у них могут возникнуть серьёзные проблемы. Этим летом выяснилось, что приложение европейской компании Polar, производителя и ритейлера фитнес-оборудования, раскрывало местоположение пользователей против их воли.

Если раньше такая утечка могла вызвать скандал и судебные разбирательства, теперь к этому прибавилось и расследование уполномоченного по защите данных Финляндии, где базируется компания. Если выяснится, что Polar нарушила положения GDPR, компании грозит серьёзный штраф.

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

Если вы пользуетесь услугами IaaS-провайдера для размещения приложения, вам важно знать, что и он, и ваша компания несут ответственность за соблюдение GDPR. Поэтому сейчас самое время поднять SLA и проверить, обеспечивает ли партнёр соблюдение положений регламента.

Другие наши заметки про облачные технологии:

И подборки книг для разработчиков на vc.ru: