GDPR - доверяй и проверяй

Возврат к бюрократии или Сотрудник на доверии
(рубрика - Нюх на баги)

Европейское сообщество решилось на усовершенствование охраны данных. Теперь тестировщикам и сотрудникам отделов тех-поддержки необходимо в срочном порядке совершенствовать свои знания в области юриспруденции.
Начать обучение следует с самого документа - "General Data Protection Regulation (GDPR)".
В большей мере вопрос касается персональных, конфиденциальных данных. А есть ли в них различие? Что об этом думают эксперты? Читайте "Experts on the GDPR #3: What is personal data under the GDPR?".
С технической точки зрения эксперты определили облачные сервисы для защиты данных - "Experts on the GDPR #4. Storing encrypted personal data in the cloud: What is the most secure option?", "EU GDPR: соблюдение требований регуляторов в сфере облачных вычислений".
Какая же ответственность теперь будет у сотрудников техподдержки первого уровня и тестировщиков? Для техподдержки объектом пристального внимания становится информация о кастомерах, которую необходимо дифференцировать по территориальному признаку - индивидуальные данные от покупателей и поставщиков следует хранить и обновлять в рамках GDPR, компаньонов из других стран позволено обслуживать в прежнем режиме, только если они не связаны с европейцами. Было бы проще ко всем применить политику GDPR, но Вы уверены, что иные страны не имеют более жёстких условий? Поэтому техподдержка первого уровня - одно из самых важных звеньев в процессе фильтрации данных. Например, баг от пользователя должен храниться во внутренней системе компании разработки, а все контакты пользователя в независимой базе, вплоть до отдельного сервера. Получается, связующее звено "техподдержка" при этом несёт полную ответственность за линковку данных об исправляемом баге и пересылаемом отчёте пользователю. Тестировщику, оформляющему баг в базу при этом придётся унифицировать проблему, применяя переименование и аггрегацию для сокрытия данных от сторонних глаз. А Ваши базы контрагентов и задач готовы к такой конфиденциальности?
Создавая и тестируя базы данных в программном продукте, выпускаемом Вашей компанией, следует более тщательно контролировать простоту наименований таблиц и полей, связей реляционных баз и доступность их описания. В этом плане хороший пример в OEBS, где таблицы и поля имеют нелогичные наименования, в основном состоящие из цифр, что хорошо запутывает взломщиков. Также должны быть усилены тесты по способам и местам хранения данных - физические носители, облачные сервисы, удалённое управление с ограничением прав доступа и функций. При пересылке данных должны использоваться высоко-защищённые от несанкционированного доступа способы, а пересылаемые данные защифрованы в обязательном порядке. Также не менее важно проверять объём информации, присылаемой с отчётом о баге, чтобы в ней не хранилось что-либо, идентифицирующее пользователя продукта. Объём и содержимое пересылаемых данных необходимо проверять на актуальность, необходимость и достаточность, предотвращать скрытые пересылки (без ведома пользователя) паролей, IP-адресов, списков баз и прав доступа, прочих идентификаторов.
Список ответственных за сохранность данных не ограничивается техподдержкой. Компания, выпускающая десктопный продукт и продающая его через свой сайт, вполне может быть распределённой: например, зарегистрирована компания в США, разработчики и тестировщики фактически раскиданы по России и Украине, маркетологи разъезжают по всему миру, сервера с исходниками и данными пользователей могут быть распределены  по всему миру. Удобнее иметь сервера с исходным кодом и задачами поближе к группе разработки, а сервис продаж в Европе. Но при этом копия базы данных покупателей обязана быть у разработчика в оригинале, а не переименованная, поскольку могут быть проблемы, напрямую зависящие от комбинации исходных данных. Такие моменты прописаны в GDPR как доступ к данным по запросу "Art. 15 GDPR  Right of access by the data subject". О предварительных действиях компании разработки рассказано в "How to prepare for Data Access Requests under GDPR", "GDPR data access portal: Logging into the GDPR data access portal, Making a data access request, The data access request excel template, Making a data deletion request, Making a data change request, Making a consent change request".

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