Регламент по защите данных (GDPR), вступивший в силу в мае этого года, в первую очередь направлен на то, чтобы дать гражданам Евросоюза возможность знать, как обрабатывается информация о них. Согласно регламенту, люди имеют право потребовать, чтобы их личные данные были исправлены или удалены. С другой стороны, есть блокчейн — технология, которая создаёт то, что называют неизменным реестром. Блокчейн сильно затрудняет изменение или удаление любой хранящейся в нём информации.
Таким образом, основополагающие принципы GDPR и блокчейна вступают в конфликт с друг другом. GDPR требует регулируемости, блокчейн обеспечивает консенсус. Возникает сложная ситуация, которая в реалиях GDPR ставит вопрос о том, должны ли компании, использующие блокчейн для обработки персональных данных в ЕС, прекратить предоставлять свои услуги.
Для ответа на него в первую очередь нужно ясное понимание термина «блокчейн». Также нужно разработать новые приложения, которые используют компоненты блокчейна теми способами, которые соответствуют закону о защите персональных данных.
GDPR и персональные данные
GDPR применяется ко всем, кто обрабатывает персональные данные в Евросоюзе. И это не только компании в ЕС. Закон касается всех предприятий за пределами союза, которые обрабатывают личные данные его граждан в процессе предоставления им услуг.
Личные данные — очень обширный термин. Он охватывает любую информацию, которая может применяться для идентификации человека, включая зашифрованные данные.
По общему признанию, блокчейн, который использует полностью анонимные данные, не будет затронут этим законом. Но трудно представить себе сервис, в котором одна сторона ничего не знает о другой. Многим предприятиям необходимо идентифицировать личность клиента в соответствии с правилами KYC/AML. Таким образом, в случае соблюдения требований KYC/AML необходимо соответствовать GDPR.
GDPR: подотчётность и защита
Чтобы понять, чего требует GDPR, рассмотрим два его основополагающих принципа. Во-первых, GDPR требует подотчётности в обработке персональных данных. В рамках GDPR сервисы, которые занимаются обработкой данных, называются контроллерами и процессорами. Контроллер данных выступает стороной, которая определяет цели и методы обработки. Это своего рода шеф-повар, который составляет меню, а также рецепты блюд. Процессор данных больше похож на су-шефа, который следует инструкциям контроллера и обрабатывает данные от его имени.
В рамках GDPR стороны, участвующие в обработке данных, должны определить свои роли в качестве контроллеров или процессоров и договориться о них в соглашении.
Во-вторых, GDPR даёт людям права. Как субъект данных вы имеете право запрашивать доступ к информации о вас, которую хранит компания. Если эта информация неправдива, у вас есть право попросить исправить её. Если вы не хотите, чтобы компания хранила определённую информацию, вы имеете право потребовать её удалить.
Рассмотрим простой пример. Люди порой лгут в резюме насчёт своих навыков и даже уровня образования. Как обнаружить такой обман? Группа университетов может создать блокчейн для подтверждения выданных дипломов. Каждый университет будет иметь свой собственный секретный ключ — то есть каждый диплом, зарегистрированный в блокчейне, будет настоящим. Работодатели могут выполнить поиск по блокчейну, чтобы проверить подлинность предоставленной кандидатами информации.
В сведениях об образовании содержатся личные данные, поэтому возникает вопрос: будет ли университетский блокчейн соответствовать требованиям GDPR? Ответ зависит от того, какой блокчейн используют учебные заведения. Тут есть два варианта.
Первый предполагает открытый блокчейн, созданный университетами. Любой может загрузить и запустить его на своём компьютере. Любой, кто это сделает, становится узлом в блокчейне. Результатом могут стать сотни или даже тысячи узлов. Это очень устойчивая система, но она также очень неоднозначна с точки зрения GDPR.
Во-первых, давайте рассмотрим подотчётность. Университеты могли разработать систему, но не они сами обрабатывают данные в блокчейне. Это делают узлы, которые не имеют никакого контроля над тем, как работает система.
В этой модели университеты не похожи на шеф-повара. Система больше напоминает книгу рецептов с блюдами, которые каждый может приготовить дома. Кто же тут контроллер, а кто — процессор? И как эти стороны должны заключать соглашения о контроллерах и процессорах?
Во-вторых, давайте посмотрим на права субъекта данных. Предположим, вы больше не хотите, чтобы ваш диплом хранился в блокчейне. Чтобы выполнить вашу просьбу об исключении, университетам пришлось бы убедить каждый узел удалить ваши данные из своей копии блокчейна. Даже если узлы согласны, с самой блокчейн-технологией есть проблема. Удаление данных изменяет хеш, который связывает блоки в цепочку.
Второй вариант предполагает закрытый блокчейн. Для этого университеты запускают блокчейн только на своих компьютерах или пользуются услугами облачного хостинга. Каждый университет становится узлом в закрытом блокчейне.
Этот вариант намного лучше с точки зрения GDPR. Что касается подотчётности, то университеты создают и управляют системой вместе. В результате они могут квалифицироваться как контроллеры. Облачный провайдер, вероятно, станет процессором, поскольку он обрабатывает данные от имени университетов. Таким образом, учебные заведения и облачный провайдер должны подписать соглашение о контроллерах и процессорах.
Но как насчёт прав на данные? Разве удаление данных не разорвёт цепочку хешей в блокчейне? Чтобы соответствовать требованиям GDPR, в блокчейне нужно будет выполнить три следующих действия:
- найти все копии персональных данных, которые относятся к субъекту данных;
- извлечь эти данные и предоставить их субъекту данных в переносном формате;
- отредактировать или удалить данные по запросу субъекта.
Наиболее сложную часть представляет собой редактирование данных и их удаление из блокчейна.
Как удалить данные из блокчейна
Данные блокчейна не являются неизменяемыми — их просто сложно изменить. Узлы управляют всеми копиями блокчейна. Они могут изменять хранящиеся в блокчейне данные, переходя к его новой версии, называемой форком.
Таким образом, если университеты достигнут консенсуса, то смогут удалить данные об определённом субъекте. Это приведёт к разрыву хешей между блоками, но университеты могут просто обновить ссылки путём повторного хеширования. В закрытых блокчейнах нет необходимости в использовании Proof-of-Work, так что это не потребует больших вычислительных мощностей.
В ряде случаев этого должно быть достаточно, чтобы узлы поручились за целостность блокчейна (они должны быть в консенсусе при форках). Работодатели в таком случае будут просто доверять данным закрытого блокчейна. Но если доверие станет проблемой, нужно будет проявить творческий подход.
Возможность удаления при сохранении целостности блокчейна
Это звучит как парадокс: включить возможность удаления данных при сохранении целостности блокчейна. Тем не менее есть перспективные решения, которые достигают этого путём удаления читаемых персональных данных.
Первый метод использует шифрование. В приведённом выше примере университеты могут зашифровать каждую запись в блокчейне собственной парой ключей и хранить в системе только зашифрованный текст. Вместо того, чтобы удалить зашифрованный текст, университет просто удалит связанный открытый ключ. Текст останется в блокчейне, но не сможет быть расшифрован.
По общему признанию, такой подход довольно рискован. В краткосрочной перспективе открытый ключ может быть скомпрометирован перед удалением. В долгосрочной перспективе механизм шифрования может быть в конечном итоге взломан (например, страшным квантовым компьютером).
Второй, более безопасный метод использует хранилище вне блокчейна (офчейн). В приведённом выше примере университеты могут принимать хеш диплома, который хотят проверить, вводя свою хеш-функцию. Затем они сохраняют полученный хеш в блокчейне, сохраняя при этом данные о самом дипломе вне блокчейна. Удаление личных данных из хранилища вне блокчейна оставило бы только хеш.
Теоретически хеш, оставшийся в блокчейне, согласно GDPR по-прежнему может квалифицироваться как личные данные. Любой, у кого есть входные данные, может запустить его через ту же хеш-функцию, а затем связать хеш с основным пользователем. Решением этой проблемы может быть добавление нонса (случайной строки) к персональным данным. Это метод предполагает усложнение (для посторонних) связывания хеша с субъектом данных. Однако некоторые криптографы предупреждают, что переработанные хеши не полностью защищены, так как они полагаются на сохранение «секретности на стороне сервера». Если безопасность нонса скомпрометирована, то посторонние могут связать хеш с пользователем. В целом пока неясно, будет ли такой хеш квалифицироваться как личные данные.
Вышеприведённые примеры иллюстрируют творческие подходы к созданию и использованию закрытых блокчейнов, которые соответствуют GDPR. Эти методы можно использовать и в публичных блокчейнах, хотя они не решат проблему контроллеров и процессоров. Тем не менее некоторые предлагают применять «привязывающие сетевые правила» (binding network rules) для назначения подотчётности, и исследования в этой области продолжаются.
По материалам The Next Web
