Короче говоря ... GDPR Право быть забытым может быть реализовано двумя способами:
Вариант A: Каждый потребитель / производитель данных несет ответственность за удаление данных PII. Удаление запускается либо вручную, проходя через всех игроков в экосистеме, либо передавая события. Когда данные удаляются, каждый потребитель / производитель данных сообщает о состоянии операции удаления, поэтому транзакция «Удаление» может быть зафиксирована / отправлена в отчет / т. Д.
Опция B: Данные шифруются приприем пищи и расшифровка по потреблению. Данные зашифрованы при приеме на основе ключа бизнес-объекта. Таким образом, данные удаляются, когда ключ бизнес-объекта удаляется. Просто чтобы быть ясно, что это не часть шифрования данных в состоянии покоя, где все хранилище данных шифруется на уровне хранилища.
Плюсы и минусы для варианта A:
Плюсы:
1. No performance impact on tx basis.
2. No hard requirements for data consumers or producers encrypting or decrypting data on ingestion or consumption.
3. No read auditing is required upon data retrieval.
4. Each data producer/consumer can run their own entity resolution/customer duplication and upon deletion request delete not single but multiple (duplicate) records.
5. Easy to main PII data dictionary per data consumer/producer. Using [Jasypt][1] (http://www.jasypt.org/hibernate.html) and hibernate mapping domain model can be annotated transparently without effecting too much domain model itself. I would exclude where data fields limited in length (for example in rational databases) would required schema refactoring.
Минусы:
1. Each data producer/consumer should be aware of PII data and have tools to delete data upon request.
2. Additional integration to "master GDRP orchestrator" if such by committing/marking deletion
transaction back.
3. Less/limited visibility and accuracy on potentially duplicated data as data scope is limited to a single dataproducer/consumer.
Плюсы и минусы для вариантаB:
Плюсы:
1. Transparent data deletion without interacting with data producer/consumer upon deletion request.
2. Scope of data marked for deletion is limited to encrypted data which means if your data gets ingested in encrypted form using business entity encryption key, data in backups, BI and etc gets encrypted automatically.
Минусы:
1. Performance impact as your data consumer/producer will be pooling encryption keys per business entity upon ingestion and consumption. Multiple in the same transaction most likely specially for 'search' like operations. Some sources claims that performance degradation is 3% using transparent data encryption with a static encryption key. In here we're talking about multiple calls to key vault per business entity.
2. Costly to main in case of HSM (Hardware based key vault).
3. Single point of failure/ha/availability/replication in generation which is a key vault.
4. Single point of lock for a data general in case key vault is jeopardized.
5. Field level encrypted data is no longer indexable.
6. Advanced search capabilities like in Oracle (wild, lexer and etc) are not longer available as data encrypted at application level and cannot be decrypted at the db level.
7. Data should be encrypted even for simple search like operations. For example simple usecase: you want to persist a customer, but before doing so you may want to check if that customer already exist. So traditionally you will try to look for a customer by his first/last/dob against your store. In case your data is encrypted at field level using business entity keys you have no possibility to search for a customer at the db level. In this case you need to load all data by decrypting it in memory or replicate/populate into your search index (which gets problematic as well in case search index lifespan is longer than what GDPR demands) in order to allow simple customer search.
У меня естьбольше для Минусы для вариант B , но остановимся здесь и попросим вас прокомментировать каждый из них. Я чувствую, что Вариант A более осуществим в реальности, чем Вариант B , который выглядит как падуб для реализации GDRP Art17.
Спасибо за комментарии / предложения. Не стесняйтесь также перечислять ваши варианты.