• irinasniko

GDPR как повод для раздумий аналитика

Пост обновлен 22 нояб. 2020 г.

Одним из трендов современной ИТ-индустрии является персонализация услуг и сервисов, что повышает ценность персональных данных, а где ценности – там и угрозы. Правительства многих стран пытаются решить этот вопрос с помощью законов о защите персональных данных. Для ЕС таким регламентом является GDPR – General Data Protection Regulation. Рассмотрим вкратце, что это такое, чем это грозит и о чем нужно задуматься бизнес- и системным аналитикам.


Роли, права и обязанности

GDPR определяет роли, отношения и ответственности сторон в процессе работы с персональными данными.

Стороны выделены такие:

  • владелец данных (чаще всего это пользователь систем);

  • контроллер данных - компания, получающая и обрабатывающая данные для выполнения какой-то конечной цели;

  • процессор - компания, передающая и обрабатывающая данные для выполнения цели контроллера (без своих целей).

Основная суть GDPR: владелец данных имеет право

  • знать, с какой целью и какие данные о нем содержит любая система,

  • на защиту этих данных от несанкционированного им доступа,

  • отзыва этих данных.

А компании контроллеры и процессоры обязаны защитить эти данные и обеспечить реализацию прав пользователя по его запросу.


Персональные данные

Что такое персональные данные, в законах разных стран написано по-разному, но в общих чертах это набор информации, по которой из большого набора данных можно определить человека или малую группу лиц. Мария, Рыбы, Дракон, выпускница бакалавриата Института стран Азии и Африки 2018 года – в совокупности этих данных достаточно, чтоб по открытым источникам найти кто это (набор данных придуман специально для этой статьи, я не знаю, есть ли бакалавриат в ИСАА).


Таким образом, если в вашей системе есть пользователи и вы хоть что-то знаете о них (от них самих или в результате их действий с вашей системой), велика вероятность того, что у вас в системе есть персональные данные и их надо защищать. Поэтому для расчета мер по защите данных для начала проще всего (но вовсе не дешевле) работать не с персональными, а с пользовательскими данными, то есть считать все данные от пользователя персональными, требующими защиты.


Ситуация, когда данные передаются от пользователя сразу контроллеру данных (через 1 систему), очень редка сейчас, вероятнее всего, данные польются через цепочку систем, и эти ручейки будут сливаться, разливаться, поглощаться и перемешиваться с другими потоками, как воды Волги, впадающей в Каспийское море. Но с точки зрения GDPR любое ведро с водой из этой реки должно быть защищено и определено по целям, на которые пойдет эта вода!


План действий

Итак, если вы аналитик системы, в которой есть данные пользователя, какие действия могут ожидаться от вас теперь в связи с этими данными?

  • Инвентаризация – какие данные вообще есть? И для какой цели они нам нужны? И если на этом этапе цель не обнаружена, можем ли мы не иметь (в первую очередь, не хранить, а еще лучше – не собирать эти данные?).

  • Для найденных персональных данных мы должны обеспечить надежное хранение (без возможности несанкционированного доступа) и уничтожение, как только цель их сбора будет выполнена.


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

И все это – только основной сценарий!


При этом пользователь может отозвать у нас свое согласие на сбор и использование персональных данных. А может попросить нас рассказать, какие его данные есть у нас и с какой целью мы их используем. А может и сказать – забудьте про меня! Или отдайте мне обратно мои данные в машиночитаемом виде, я их отдам другим обработчикам. Или: прекратите мне слать ваш спам (маркетинговые рассылки)!

А если у нас есть передача этих данных в другую систему? Ооо, мы перед пользователем отвечаем и за себя, и за того парня, то есть должны протранслировать пользователю цели сбора другой системы и обработать запросы пользователя о его данных в обоих системах. И тут возникает множество интересных архитектурных задач (например, если мы не храним идентификаторы пользователя, чтоб обеспечить его анонимность, как же мы объясним нашим соседям, какие данные они должны удалить?).


Кто-нибудь скажет, что все эти ужасы не у нас, а в Европе. Ну ОК, но европейский закон защищает данные европейских пользователей по всему миру, а вы умеете отличать европейцев от остальных пользователей в вашей системе? И готовы урезать для них свою функциональность? Или хранить их данные только на территории ЕС? Кстати, в вашей стране тоже могут действовать законы о защите персональных данных (например, данные российских пользователей должны храниться и обрабатываться на территории России)


О боже, в каком сложном мире мы живем!


Итого:

  1. Сначала нам нужно заявить пользователю, какие данные с какими целями мы хотим собирать.

  2. Потом нам нужно защитить эти данные от несанкционированного доступа (а санкционирован доступ только с конкретными заявленными пользователю целями)

  3. Как только цель, ради которой мы собирали данные, выполнена, данные надо удалить.

  4. Как только пользователь заявил нам, что отзывает согласие на обработку, мы дол