Что нужно сделать ИТ-компаниям для соответствия новым правилам защиты данных в ЕС

25 апреля 2018, 13:17

CEO стартапа по обнаружению внешнего воздействия на ИТ-системы Dhound.io Денис Колошко написал для dev.by колонку о том, как компаниям стоит подготовиться к вступлению в силу европейских правил по защите данных — и каким компаниям стоит это сделать.

Читать далее

Иллюстрация: Tinobusiness

Все слышали о General Data Protection Regulation (GDPR) (Regulation (EU) 2016/679), который вступает в силу 25 мая 2018 года. Как и любой официальный документ, он написан сухо и может трактоваться по-разному. Цель этой статьи — не разъяснить, что такое GDPR (об этом уже много написано), а дать практические советы техническим людям, что необходимо сделать в вашей системе, чтобы она соответствовала GDPR. Вся информация основана на анализе десятка различных веб-систем на соответствие новым правилам.

Интересные моменты в регламенте

  • Если у компании есть хотя бы один клиент из Европы, чьи персональные данные хранятся на серверах, она автоматически попадает под действие GDRP;
     
  • Регламент базируется на трёх основных идеях: защита персональных данных, защита прав и свобод людей в защите их данных, ограничение перемещения персональных данных в рамках Евросоюза;
     
  • Великобритания всё ещё входит в состав ЕС, поэтому подпадает под действие GDPR, после Brexit-а GDPR будет заменён на Data Protection Bill, который по своей сути очень схож с GDPR;
     
  • Серьезно ограничивается трансфер данных в третьи страны. Европейская комиссия определяет, в какие «третьи» страны или в какие сектора или организации в этих странах разрешён трансфер персональных данных (ст. 45). К примеру, Беларуси в списке нет;
     
  • Продемонстрировать насколько крута безопасность системы и процессов можно только «на бумаге». Если безопасность процессов, системы и персональных данных не задокументирована, значит компания не соответствует GDPR (ст. 24).

Реализация GDPR на практике

1. Публичные страницы на сайте

  • Privacy Policy — основной документ, который требует соответствия с GDPR
    • Должно быть четко прописано, какую Personal и Non-personal информацию система собирает;
    • Для каких целей собирается информация;
    • Какие права пользователь имеет (ст. 15-18);
    • Политика хранения данных (Data Retention Policy)
      • Данные нельзя хранить дольше, чем это необходимо для целей, для которых персональные данные собирались (ст.5)
    • Трансфер данных в другие страны (ст.45);
    • Как данные будут защищены;
    • Контактная информация, включая юридический адрес, а также контакты Data Protection Officer, если он есть;
       
  • В условиях пользования необходимо добавить жирным шрифтом текст о возрастном ограничении «The Website is available only to individuals who are at least 16 years old», если система не работает целенаправленно с детьми или детским контентом. В противном случае, нужно добавлять в систему функциональность по определению возраста пользователя в виде чекбокса на странице регистрации и получению родительского согласия, если пользователю меньше 16 (ст.8);
     
  • Compliance & Security — опционально, но пользователи уже сейчас интересуются ситуацией с GDPR у компаний, поэтому лучше иметь раздел, где будет детально расписана организация защиты данных;
     
  • Payment Policy, Cookie Policy — расписывается как проходят платежи, и какие куки использует система;

2. Страница регистрации:

  • Количество полей должно быть минимальным и обоснованным (ст.5);
     
  • Подробное согласие (Granular Consent) (ст.7)
    • Обязательный чекбокс, что пользователь согласен с Условиями использования и Политикой приватности;
    • Отдельный чекбокс, если компания хочет подписать пользователя на почтовую рассылку.

Иллюстрация: altalex.com

3. Страница профиля пользователя:

  • Пользователь должен иметь возможность изменить любое поле о себе (ст.16)
     
  • Кнопка Delete Account (ст.17). Пользователь должен иметь возможно удалить себя и всю свою информацию из системы;
     
  • Кнопка Restrict Processing Mode (ст.18). Если пользователь включил этот режим, персональная информация не должна быть больше доступна ни в публичном доступе, ни другим пользователям и даже администраторам системы. Подход GDPR предполагает, что это является альтернативой полного удаления пользователя из системы;
     
  • Кнопка получения собстенной информации Export Personal Data (ст.20). Выгружать её можно в любом формате: XML, JSON, CSV;
     
  • Снова подробное согласие (ст.7)
    • Возможность дать/забрать согласие на действия системы по работе с персональными данными (например, подписка на новости или маркетинговый материал)

4. Дополнительная функциональность

  • Автоматическое удаление или анонимизирование персональных данных, которые больше не нужны (ст.17). Например, информация из уже обработанных заказов;
  • Автоматическое удаление персональных данных в других сервисах, с которыми интегрирована система (ст.19).

5. Организационные меры по защите данных

  • Разработка следующих политик и документов
    • Personal Data Protection Policy (ст.24(2));
    • Inventory of Processing Activities (ст.30);
    • Security incident response policy:  
      • В течение 72 часов необходимо уведомить надзорный орган об утечке информации (ст.33);
      • нужно уведомить субъекта данных, что его данные утекли. При определённых условиях этого можно и не делать. (ст.34);
    • Data Breach Notification Form to the Supervisory Authority (ст.33);
    • Data Breach Notification Form to the Data Subjects (ст.34);
    • Data Retention Policy
       
  • Документы, которые погут пригодиться
    • Data Disposal Policy
    • Backup policy
    • System access control Policy
    • SLA and escalation procedures
    • Cryptographic control policy
    • Disaster Recovery and business continuity
    • Coding standards and rollout procedure
    • Employment policy and processes
       
  • Чтобы не плодить кучу документов, можно объединить их в один — IG Policy (Information Governance Policy).

6. Технические меры по защите данных

  • В GDPR нет чётких предписаний, какие меры безопасности применять, но архитектура должна быть построена по принципу Data protection by design and by default (ст.25);
     
  • Фаерволы, доступ по VPN;
     
  • Шифрование для неиспользуемых данных;
     
  • Шифрования данных во время их передачи (HTTPS, IPSec, TLS, PPTP, SSH);
     
  • Контроль доступа (физический и технический);
     
  • Обнаружение и предотвращение вторжений, мониторинг состояния системы;
     
  • Шифрование бэкапов;
     
  • Двухфакторная аутентификация, жёсткая авторизация;
     
  • Антивирус;
     
  • И другие меры, в зависимости от системы

Несколько специфических моментов, при которых возможно потребуют привлечения юристов:

  • Обработка ‘special data’ (ст.4) по умолчанию запрещена. Сбор персональной информация относительно здоровья, сексуальной жизни и ориентации, биометрических и генетических данных, философских и религиозных верований также запрещён (ст.9), за исключением случаев, описанных в документе;
     
  • Если контроллер или процессор не зарегистрированы в зоне ЕС, то должен быть назначен официальный и документально подтвержденный представитель (ст.27);
     
  • Все субконтракторы, с которыми работает data controller — неважно, где они находятся — также должны соответствовать GDPR, а соответствующие изменения также должны быть внесены в контракты (ст.28);
     
  • Субконтрактор не в праве пользоваться услугами другого субконтрактора без письменного согласия data controller-а (ст.28);
     
  • Существуют серьёзные ограничения на трансфер данных, поэтому лучше ознакомиться со всеми условиями трансфера, если данные отсылаются или хранятся вне рамок ЕС (глава 5);
     
  • Data Protection Officer. Эта роль обязательна, если компания обрабатывает «особые категории информации» или обработка данных осуществляется государственным органом (ст.37)

Полезные ссылки:

Обсуждение