Клиент попросил удалить свои данные, вы сделали DELETE. Данные остались в файле

[cpud47]

secure_delete это миф. И даже шифрование не всегда спасает. Если вам реально важно удаление пд, то это большая инженерная и аналитическая работа. Никаких волшебных палочек здесь нет.

[DAlexis]

А почему не спасает шифрование? Из-за сложной инфраструктуры работы с ключами такого шифрования?

[cpud47]

А здесь довольно много разных факторов. Перечислю их безотносительно их критичности.

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

Дальше вопрос а как часто эти пд расшифровуются. Если на каждый запрос, то встаёт риск, что они куда-нибудь утекут после расшифровки: в логи, при ошибке, в другой микросервис, во внешнюю систему, в отчёт и прочее. Чтобы их расшифровывать пореже нужно аккуратно понять, а что именно шифровать, что нет. И дальше нужно очень аккуратно писать код, чтобы он мог работать с шифрованными данными.

Аналогичный вопрос, что с пд происходит до шифрования. Здесь тоже полно мест для утечки.

Ну и сама работа с ключами тоже весёлая. Ключи могут утечь из памяти в своп или кордамп. ВМ могут заснапшотить с памятью — тогда ключи можно достать из снапшота. К счастью, в логи обычно ключи не пишут (хотя бывает =().

Плюс ключи ведь нужно где-то хранить, в отдельном микросервисе например. И этот микросервис тоже нужно бэкапить. В нём тоже нужно как-то реализовывать физическое удаление и всё прочее.

С бэкапами тоже интересно. По-хорошему бэкапы должны быть иммутабельными и храниться где-нибудь отдельно. В частности их могут хранить на каком-нибудь (внешнем) s3 — а как оно там мутируется и удаляется никто не знает. Ну и при мутации бэкапов есть риск сломать его...

Здесь также есть всякая экзотика, что даже перезапись данных нулями не гарантирует их полного удаления. WAL может довольно долго не транкатиться (особенно в условном mssql). Есть всякие CoW фс по типу btrfs, которые при перезаписе создадут копию. А при прямом доступе к диску, бывает можно восстановить часть данных даже после перезаписи. Например всякий page redirect на ssd.

Короче говоря, рисков очень много разных. И самый главный вопрос: "а оно Вам надо"? ** Чаще всего удаление ПД подразумевает "к данным нельзя обратиться штатными средствами и они не используются при штатной обработке". В частности, формально даже soft delete является корректной мерой. Поэтому меры против такой вот археологии нужно отдельно обосновывать в рамках Вашей модели угроз.

**не является юридическим советом, проконсультируйтесь с юристом.

P.S. Я уже не говорю о том что шифрование, а тем более шифрование в бд довольно сложное (легко сделать неправильно). Многие программисты могут просто захардкодить ключ шифрования...

[r_o_m_k_o_l_a]

Про копии и реплики — самое больное место, и обычно про него вспоминают последним.

У нас в августе был внутренний аудит по 152-ФЗ, и удаление по запросу выглядело закрытым вопросом: есть ручка, есть DELETE, есть каскады. Дыра нашлась не в базе. Значения персональных полей уезжали в прикладные логи (мы логировали тело запроса при ошибках валидации), в дампы для отладки и в аналитическую копию, которая наливалась раз в сутки и жила своим сроком хранения. То есть после честного DELETE + VACUUM данные оставались ещё в трёх местах, ни одно из которых не считалось хранилищем персданных.

Что помогло: сначала выписать все места, куда значение вообще может утечь по пути (лог, метрика, очередь, реплика, бэкап, отчёт), а уже потом чинить удаление. Список получился неприятно длинным, зато после него VACUUM перестал казаться решением задачи.

Отдельно плюсую за шифрование поля отдельным ключом. Это единственный подход, который работает с бэкапами задним числом: выкинули ключ — и старые копии перестали быть персданными, перебирать их не нужно.

[gr-pr-moi-do]

Шифровать чувствительные поля отдельным ключом на запись или на клиента.

тут что-то с падежами.

а где хранить этот ключ, чтоб он не утекал с бэкапами?

[jbenderov]

1) Спасибо, поправил.
2) Главное - хранить ключ вне базы данных. Например: в системе управления секретами / KMS / клиентском хранилище. Плюс у него должен быть отдельный цикл бэкапирования и строгий аудит доступа (чтобы другие пайплайны случайно не получали к нему доступ).