GDPR: шифрование в состоянии покоя вместо таблиц поиска данных - PullRequest
0 голосов
/ 18 июня 2020

Неактивное шифрование - хранит данные внутри вашего хранилища / базы данных в зашифрованном формате. Во время обработки вам нужно каждый раз расшифровывать данные, что-то вычислять, а затем зашифровать все обратно (шифрование управляется хранилищем).

Решает ли шифрование в состоянии покоя проблему «права на забвение»? Когда вы не можете go с шифрованием в состоянии покоя и должны выбрать таблицы поиска данных и псевдоанонимизацию?

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

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

1 Ответ

1 голос
/ 18 июня 2020

Если шифрование происходит на уровне хранения, то это не помогает с правом быть забытым. Если вы хотите использовать шифрование для решения проблемы с правом на забвение, я бы предложил использовать уникальный ключ шифрования для каждого субъекта данных. Если субъект данных необходимо забыть, вы можете удалить свою копию ключа шифрования, и вы эффективно «зашифровали» все данные, которые защищены этим ключом. Чтобы это работало наилучшим образом, вам необходимо тщательно спроектировать свою архитектуру (например, можно ли хранить ключ отдельно от данных, чтобы он не создавался резервной копией, и найти другой способ обеспечить доступность текущих ключей в сценарии аварийного восстановления и т. Д. c).

Таблица поиска данных является эквивалентом службы токенизации, где вы заменяете имя субъекта данных или другие детали токеном. Удалив (или изменив) токен в таблице поиска данных, вы лишили возможности преобразовывать токен обратно в фактический субъект данных. Это обеспечит меньшую степень уверенности в отношении достигнутого уровня «забывчивости», поскольку вы все еще можете косвенно идентифицировать субъект данных через другую информацию о нем. Взгляните на https://en.wikipedia.org/wiki/K-anonymity, чтобы понять эту концепцию более подробно.

...