Комментарии 26
В задачи СУБД общего назначения и не входит очистка дисков от данных. Это достаточно ресурсоёмкая операция, и было бы удивительно, если бы она выполнялась просто так, без предъявленных требований по защите информации.
А инструмент, конечно, интересный.
А потом сертифицированная система управления базой данных должна дать команду сертифицированной системе бакапов, для сертифицированного удаления сертифицированных архивных копий где могут находиться данные требующие сертифицированного удаления
Иначе даже сертифицированная база данных не сможет надежно удалить данные. Их всегда можно поднять из бакапа
Появление данных в новом файле WAL при исследовании Postgres скорее всего произошло из-за переиспользования этих файлов. Пытались ли вы прописать постгре команду "архивации", которая бы затирала "архивируемый" сегмент?
:-) Вы еще не пробовали искать "удаленные" секретные данные на "сырых" носителях... А не в файловой системе... :-) Вот где будет "много сюрпризов".... А на "уровне виртуализации" эти "приключения" еще "интереснее"....
Да, всё так, но справедливо только для опенсорсных систем. В основных энтерпрайзных СУБД эта проблема решена с помощью специальных утилит.
Например, В Postgres Pro есть механизмы, которые позволяют удалять данные безвозвратно, заполняя нулями освобожденные СУБД файлы. Вообще-то это могут делать и соответствующие утилиты ОС; но вот способность базы вовремя почистить ненужные ей более версии строк, фрагменты журнальных файлов и блоки памяти уникальна.
Вот тут в деталях: https://postgrespro.ru/docs/postgrespro/17/memory-purge-cert
Мы используем частенько MySQL и MariaDB. А что если перед удалением апдейтить значения? Проблемы не будет?
Скорее всего в логах транзакций будут и те, и другие. Но надо проверять, конечно.
А так, вообще идея была такая: создаём в таблице столбец is_deleted. При фейковом удалении ставим 1. А когда захотим по-настоящему удалить данные, то чувствительные столбцы апдейтим нуллами или иными пустышками.
Буду очень рад, если посмотрите через свою систему. Важный вопрос вы подняли.
Ну вот я попробовал. Добавил те же данные, а потом затёр их. В WAL все сохранилось.
Скриншот
Ага, спасибо. Вы на постгресе попробовали. Что касается MariaDB и MySQL, можно сделать так:
mysql> PURGE BINARY LOGS BEFORE NOW();Но в интернетах пишут, что есть нюанс.
В /etc/my.cnf нужно включить log-bin=mysql-bin, иначе эффекта не будет.
Если потом опять отключить эту опцию и перезапустить сервер, то логи создаваться уже не будут.
Сохраняйте в зашифрованном виде. При необходимости удалить просто "выкидывайте" ключ для расшифровки вместе с удалением данных. Тогда задача хотя бы сводится к надёжному хранению и удалению ключей.
Дельное предложение. Спасибо
Разве ключ для расшифровки у вас свой для каждой [удаляемой] строки? Скорее всего нет, поэтому задача к этому не сводится. Я могу себе условно представить один ключ на таблицу, и выкинуть его при удалении строк ни никак не получится.
Идея-то насчет шифрования хорошая, но похоже непрактичная.
Шифрование не просто хорошая, а обязательная вещь. И раз пошла такая пьянка/паранойя, можно перешифровывать имеющиеся записи. В простейшем виде так: когда удаляем N строк, перед этим создаём новый ключ, неудаляемые записи перешифровываем с ним, удаляемые забиваем нулями. Затем убиваем старый ключ. Затем выполняем (сброс буферов|checkpoint) и переключение на новый WAL/redo log/etc. Осталось сделать бекап (базы|табличного пространства|таблицы) и надёжно затереть архивный (WAL|транзакционный лог|etc).
Не вижу принципиальных проблем держать свой ключ на каждую строку или перешифровывать всю колонку единым ключом кроме удаляемой ячейки (можно оптимизировать пакетированием - делать раз в сутки, например). Практичность будет определяться требованиями к надёжному удалению в том числе.
По-моему почти все (ну или многие) практически существующие (для постгреса, для определенности) системы шифрования предполагают, что ключ у клиента. Просто потому, что одно из применений шифрования - это защита данных от админа в том числе. Я бы посмотрел, как вы будете распространять клиентам (особенно если их число заранее неизвестно) вновь выпускаемые ключи, и управлять удаляемыми ключами для удаленных строк.
Ну т.е. я не хочу сказать, что это сделать невозможно, но это далеко нетривиальная задача, которую, как мне кажется, никто реально не решил, и готового такого решения на рынке нет. Я могу ошибаться разумеется, потому что исхожу просто из документации на постгрес, где предлагается пяток примерно решений для шифрования, ни одно из которых под ваше описание не подходит. Если по-простому - то везде один ключ на базу. Даже до ключа на таблицу никто не доходит (хотя по-хорошему, как раз ролевая модель с правами на уровне таблиц, она достаточно типична, и в ней ключ на таблицу был бы логичен).
Вот, нашёл заметку о cryptographic erasure, где пишут, что большие корпорации уже используют такой подход: https://www.techtarget.com/searchcloudcomputing/feature/How-Azure-AWS-Google-handle-data-destruction-in-the-cloud
Заметьте, что там написано про tenant encryption key, т.е. это конечно разговор про шифрование и пр. - но скорее применительно к облакам, где вы можете случайно (ну или неслучайно) получить доступ к чужим данным, когда в облаке много разных компаний. Т.е. речь о защите скорее базы целиком, нежели отдельных записей. Это вполне реальный случай, и к нам наши безопасники регулярно с такими вопросами приходят - но это другой случай.
Но я быстро прочитал, если вы там видите что-то другое - ткните пальцем, это правда интересно.
Фундаментальная проблема отдельного ключа на каждую строку - в том, что к хранению ключей предъявляются те же самые требования, что и к хранению шифруемых данных. Иными словами, для хранения ключей нужна сертифицированная СУБД с надёжным удалением. Но если такая СУБД есть - зачем вообще трястись над ключами, если можно хранить в ней сразу необходимые данные?
Одни и те же требования, серьёзно? Вот у вас дома холодильник стоит. Вы его с собой таскаете или всё-таки ключ от замка в том доме у вас в кармане лежит? Точно так же и KMS для генерации/хранения/удаления криптоключей - она сильно проще, дешевле и легче, чем СУБД с кучей фичей под кучу типов данных с тем же уровнем предсказуемого стирания.
Как надёжно стереть секретную информацию из базы данных