Вы, наверное, слышали о «праве быть забытым», согласно которому Google должен удалять результаты поиска о вас, если вы их об этом попросите.
Согласно новому Общему регламенту ЕС о защите данных , право быть забытым означает, что субъект данных (пользователь) может запросить удаление своих данных из любого контроллера данных (включая веб-сайты), а контроллер данных должен удалить данные без задержки. Будь то профиль в социальной сети, товары, продаваемые в интернет-магазинах / аукционах, данные о местоположении, свойства, выставленные на продажу, даже комментарии на форуме.
Конечно, это не так просто, так как это зависит от договорных обязательств пользователя (даже с неявными договорами), и в Регламенте перечислено несколько случаев, некоторые из которых очень широкие, когда применимо право быть забытым, но суть в том, что такая функциональность должна поддерживаться.
Я процитирую соответствующие биты из Правил:
Статья 17
1. Субъект данных имеет право получить от контролера удаление персональных данных, касающихся его или ее, без неоправданной задержки, а контролер обязан удалить персональные данные без неоправданной задержки, если применяется одно из следующих оснований:
(а) личные данные больше не нужны в связи с целями, для которых они были собраны или обработаны иным образом;
(b) субъект данных отзывает согласие, на котором основывается обработка, в соответствии с пунктом (а) статьи 6 (1) или пунктом (а) статьи 9 (2), и если нет других правовых оснований для обработки ;
….
2. Если контролер обнародовал персональные данные и обязан в соответствии с пунктом 1 стереть персональные данные, контроллер, принимая во внимание доступные технологии и стоимость внедрения, должен предпринять разумные меры, включая технические меры, для информирования контроллеров. которые обрабатывают персональные данные, которые субъект данных запросил стирание такими контролерами любых ссылок, или копирование, или копирование этих персональных данных.
Этот «легальный» в основном означает, что ваше приложение должно иметь функцию «забудь меня», которая полностью удаляет пользовательские данные. Нет «удаленных» или «скрытых» флагов, нет «но наш бизнес основан на ваших данных», нет «это сломает наше приложение».
Также обратите внимание, что если ваши приложения отправляют данные в сторонние службы (загружают изображения на YouTube, изображения в imgur, синхронизируют данные с salesforce и т. Д.), Вы также должны отправлять запросы на удаление в эти службы.
Постановление вступит в силу в 2018 году, но, вероятно, стоит помнить об этом раньше. Не только потому, что существует действующая Директива и суды уже имеют решения в этих направлениях, но и потому, что при создании вашей системы вы должны поддерживать эту функциональность в рабочем состоянии. А поскольку в большинстве случаев все данные связаны с пользователем в вашей базе данных, то, таким образом, они, скорее всего, считаются «персональными данными» в широком определении в регламенте.
Технически это может быть достигнуто с помощью ON CASCADE DELETE в реляционных базах данных, или cascade=ALL в ORM, или моим ручным удалением прикладного уровня. Удаление вручную требует поддержки и расширения при добавлении новых сущностей / таблиц, но это безопаснее, чем использование общего каскадного удаления. И, как уже упоминалось выше, этого может быть недостаточно — сторонние интеграции также должны включать удаление. И большинство сторонних API имеют такую функциональность, поэтому ваш обработчик конечных точек «/ Forgot-Me», вероятно, будет выглядеть примерно так:
|
01
02
03
04
05
06
07
08
09
10
11
12
|
@Transactionalpublic void forgetUser(UUID userId) { User user = userDao.find(userId); // if cascading is considered unsafe, delete entity by entity fooDao.deleteFoosByUser(user); barDao.deleteBarsByUser(user); userDao.deleteUser(user); thirdPartyService1.deleteUser(user.getThirdPartyService1Token); thirdPartyService2.deleteUser(user.getThirdPartyService2Token); // if some components of your deployment rely on processing events eventQueue.publishEvent(new UserDeletionEvent(user));} |
Этот код может выполняться асинхронно. Его также можно запустить как часть «забывающего» запланированного задания — пользователи отправляют свои запросы на удаление, и задание забирает его. Регулирование не является строгим в отношении удаления в реальном времени, но оно должно происходить «без неоправданной задержки». Так что «раз в месяц» не вариант.
Моя точка зрения — вы должны учитывать эту особенность при разработке приложения, чтобы не оказалось, что невозможно удалить данные, не нарушая все.
И вы должны думать об этом не (просто), потому что некоторые нормативные акты ЕС так говорят, а потому, что данные пользователей не являются вашей собственностью. Да, пользователь решил просто добавить что-то в вашу базу данных, но вам это не принадлежит. Поэтому, если пользователь решит, что он больше не хочет, чтобы вы хранили какие-либо данные о нем — вы обязаны соблюдать этические (и теперь юридические) обязательства. Вы можете похоронить эту функцию на десяти экранах и двух формах паролей в глубине, но лучше быть там.
Будь это практично — я думаю, что это так. Например, он пригодится для приемочных испытаний , которые вы можете запускать против производственных (не полагаясь на жестко закодированные профили пользователей). Также не так сложно поддерживать функцию удаления, и это позволяет вам иметь гибкую модель данных.
То, будет ли Регламент применяться надлежащим образом, зависит от многих факторов, но технический может быть значительным для устаревших систем. И так как каждая система становится «наследием» через шесть месяцев, мы должны говорить об этом.
| Ссылка: | Право быть забытым в вашей заявке от нашего партнера по JCG Божидара Божанова в блоге на техническом блоге Божо . |