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

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

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

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

Из книг в Интернете:

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

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

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

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

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

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

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

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

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

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

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

1. Delete your data.
   • Perform multiple UPDATEs on the table to destroy old data.
   • Выполните несколько крупных транзакций и зафиксируйте их, чтобы журнал транзакций был усечен. Сколько точно зависит от размера вашего журнала.
   • CleanSweep места на диске занято старыми журналами транзакций.

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

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

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

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

Напишите схему, если вы еще этого не сделали.

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

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

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

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

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