Как я могу безопасно уничтожить некоторые данные, используя SQL Server 2008? (используя DoD Secure Wipe или эквивалентный)

Question

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

Данные находятся в таблице, и я хочу уничтожить некоторые содержащиеся в ней строки.

Я мог бы сделать это вручную, удалив / экспортировав базу данных на другом компьютере / размагничивая жесткий диск / повторно импортировав сохраненные данные, но мне нужно автоматическое решение.

Существует ли эквивалент команды удаления (как в случае удаления * из foo), которая выполняла бы безопасное уничтожение данных (с использованием безопасного стирания DoD или что-то подобное?)

Видите ли вы другие способы выполнить это автоматическое удаление?

Кстати, я знаю, что вероятность того, что кто-то получит некоторые данные, которые я уничтожил с помощью команды sql delete, очень мала, но некоторым из моих клиентов это требуется. Поэтому, пожалуйста, не превращайте этот вопрос в глобальную дискуссию на тему процедур удаления данных!

Редактировать : проблема, которую я хочу решить, это не «Как уничтожить данные, чтобы их нельзя было восстановить», а скорее «Как я могу убедить своих клиентов, что их данные не могут быть восстановлены».

Answer 1

Используйте некоторую форму шифрования для хранения полей данных в таблице.

Когда вы решите «удалить», повторно зашифруйте данные, которые вы будете продолжать использовать с новым ключом. Откажитесь от старого ключа и удалите строки, зашифрованные старым ключом. Уменьшить размер.

Даже если кто-то восстановит строки, без старого ключа никто не сможет восстановить данные. Просто убедитесь, что старый ключ действительно удален - вы можете иметь его только на одной USB-флешке, уничтожить флешку и т. Д.

Answer 2

Из Электронных книг :

Удаление операций из таблицы или обновить операции, которые вызывают строку движение может немедленно освободить место на страницу, удалив ссылки на строка. Однако при определенных обстоятельства, ряд может физически остаться на странице данных как призрак запись. Призрачные записи периодически удален фоновым процессом. это остаточные данные не возвращаются Database Engine в ответ на запросы. Однако в средах которая физическая безопасность данные или резервные копии находятся под угрозой, вы можно использовать sp_clean_db_free_space для очистите эти записи о привидениях.

Это должно обнулить ваши "бесплатные" страницы данных. Его также можно использовать, если использовалась мгновенная инициализация, но вы решили вместо этого обнулить страницы.

Чтобы ответить на ваш обновленный вопрос: «Как я могу убедить своих клиентов в том, что их данные не могут быть восстановлены», что в записи BOL это ясно сказано: «Записи о призраках периодически удаляются фоновым процессом».

Answer 3

В основном нет. Стандартная операция не сделает этого, и если бы это было так, данные все равно можно было бы восстановить из журналов транзакций и т. Д. Вероятно, самое близкое, что вы можете получить, это сделать это извне, скопировав и очистив базу данных на другом устройстве, а затем выполни Качественное удаление скраба на старом устройстве, но я не уверен, что как охранник я бы даже сказал, что это был убранный delette.

Безопасное удаление - сложная проблема. Вы могли бы добиться большего успеха с помощью криптографического подхода, такого как «эфемеризатор» Радии Перлман.

Answer 4

Удалить данные. Сделайте простое резервное копирование и восстановление на новом жестком диске и запишите старый диск.

Уничтожение объектов - единственный способ убедить людей в том, что «вещи» действительно исчезли.

Answer 5

На самом деле шансы на получение данных, уничтоженных с помощью DELETE, довольно велики, близки к 100%:)

Данные, которые вы удаляете, хранятся в журнале транзакций, это часть работы транзакций. В другом случае вы либо не сможете ROLLBACK транзакцию, либо COMMIT будет длиться вечно (как в старых версиях PostgreSQL).

Лучшее, что вы можете сделать, не связываясь с файлами данных:

1. Удалить ваши данные.
   • Выполните несколько UPDATE с таблицы, чтобы уничтожить старые данные.
   • Выполните несколько крупных транзакций и передайте их для усечения журнала транзакций. Сколько именно зависит от размера вашего журнала.
   • CleanSweep место на диске, занимаемое старыми журналами транзакций.

Answer 6

Я не уверен, соответствует ли это требованиям Министерства обороны США, но, как минимум, я бы прошел через следующее.

1. Удалить записи стандартным способом
2. Создать новую резервную копию базы данных (для будущего использования)
3. Удалите все существующие резервные копии (поскольку у них есть данные), используя стандартный процесс удаления файлов, который соответствует стандартам
4. Сократите базу данных, чтобы освободить неиспользуемое пространство от удаленных записей.

Я думаю, что это достаточно близко, но главное - это управление операцией сжатия, в которой я не уверен на 100%, как это очищает / обрабатывает данные. Во-вторых, удаление старых резервных копий было бы «самым большим риском», если бы вы, по моему мнению, рассматривали точки риска.

Answer 7

Ну, я просто играю здесь, но вы попробуете это, это будет достаточно безопасно.

Не используйте типичную резервную копию.

Сценарий схемы, если вы этого еще не сделали.

Сценарий всех данных, так что все текущие могут быть вставлены с помощью сценария с множеством операторов INSERT. Удаленные данные не будут отображаться в этом файле, очевидно. Конечно, вы захотите использовать Bulk Insert и все это, чтобы вернуть туда данные.

Теперь используйте sdelete , чтобы удалить все файлы данных и журналы, связанные с базой данных. Теперь восстановите из сценария вставки. :)

Кстати, ваш вопрос и внесенные вами изменения говорят о том, что вам не нужно решение, но есть причина, почему не противоречит всему вашему вопросу. В любом случае, хорошая причина не делать этого - никто этого не делает. Если вы хотите сделать что-то в области вычислительной техники (кроме создания какого-то совершенно нового типа приложения или чего-то подобного), что никто другой не делает, это, вероятно, плохая идея. Насколько мне известно, нет ни академических статей, ни статей о ДО, которые описывали бы метод для этого.

Большая проблема в том, какая информация будет «вытекать» из записей, которые вы удалили, в записи, которые не были удалены. Обратите внимание, здесь я имею в виду «утечка» в смысле потока информации.

Хотя, честно говоря, метод, который я описал выше, по существу достиг бы вашей цели.