Как я могу надежно уничтожить некоторые данные с помощью SQL-сервера 2008? (использование DOD защищает очистку или эквивалент),
Это то, что вы пытаетесь сделать
WITH StrTable AS
(
SELECT 'ABC123' My_ID_String
UNION
SELECT '12355555'
UNION
SELECT 'ABC456'
UNION
SELECT NULL
UNION
SELECT 'DEF123'
UNION
SELECT 'DEF456'
UNION
SELECT 'GHI123'
UNION
SELECT 'GHI456'
UNION
SELECT 'GHI789'
)
SELECT CONCAT( LEFT(My_ID_String, 3),
MAX(REPLACE(My_ID_String, LEFT(My_ID_String, 3), ''))
) Result
FROM StrTable
WHERE TRY_CAST(LEFT(My_ID_String, 3) AS INT) IS NULL
AND My_ID_String IS NOT NULL
GROUP BY LEFT(My_ID_String, 3);
Возвращает:
+--------+
| Result |
+--------+
| ABC456 |
| DEF456 |
| GHI789 |
+--------+
7 ответов
Используйте некоторую форму шифрования для хранения полей данных в таблице.
Когда Вы решите "удалить", повторно зашифровать данные, Вы продолжите использовать с новым ключом. Удалите старый ключ и удалите строки, зашифрованные со старым ключом. Уменьшение.
Даже если кто-то восстановит строки, w/o старый ключ, то никто не сможет восстановить данные. Просто удостоверьтесь, что старый ключ действительно удален - у Вас может быть он на единственном usb, придерживаются только и уничтожают палку, и т.д.
Из книг онлайн:
Удалите операции из таблицы или обновите операции, которые заставляют строку перемещаться, может сразу освободить пространство на странице путем удаления ссылок на строку. Однако при определенных обстоятельствах, строка может физически остаться на странице данных как фантомная запись. Фантомные записи периодически удаляются фоновым процессом. Эти остаточные данные не возвращаются Механизмом базы данных в ответ на запросы. Однако в средах, в которых находится в опасности физическая безопасность файлов данных или файлов резервных копий, можно использовать
sp_clean_db_free_spaceубрать эти фантомные записи.
Это должно обнулить Ваши "бесплатные" страницы данных. Это может также использоваться, если Мгновенная Инициализация использовалась, но Вы решили, что хотите обнулить страницы вместо этого.
Отвечать на Ваш обновленный вопрос, "Как я могу убедить свои клиенты, что их данные не могут быть восстановлены", что запись BOL указывает это ясно, "Фантомные записи периодически удаляются фоновым процессом".
В основном, нет. Стандартная операция не сделает этого, и если бы это сделало данные, то мог бы все еще быть восстановлен из журналов транзакций и т.д. Вероятно, самое близкое, можно приехать, должно сделать это внешне, копируя и производя чистку базы данных к другому устройству, затем делание высококачественного куста удаляет на старом устройстве, но как парень безопасности я не уверен, что даже хотел бы сказать, что это было sssured, удаляют.
Безопасный удаляют, трудная проблема. Вы могли бы добиться большего успеха с криптографическим подходом, как "ephemerizer" Radia Perlman.
Я не уверен, встречает ли это requirments DOD, но как минимум я прошел бы следующее.
- Удалите записи стандартный путь
- Возьмите новое резервное копирование базы данных (для будущего использования)
- Удалите все существующие резервные копии (Поскольку у них есть данные), с помощью стандартного процесса удаления файла, который соответствует стандартам
- Уменьшите базу данных для освобождения неиспользуемого места от удаленных записей.
Я думаю, что это получит Вас достаточно близкий, ключ, хотя управление операцией уменьшения, которая я не на 100% уверен, как это очищает/обрабатывает данные. Во-вторых, удаление старых резервных копий было бы "самым большим риском", если бы Вы смотрели подверженные риску точки, по-моему.
Удалите данные. Сделайте простое резервное копирование и восстановление на новом жестком диске и запишите старый диск.
Уничтожение объектов является единственным способом действительно убедить людей, что 'вещей' действительно не стало.
На самом деле, возможности получения данных, уничтоженных с DELETE являются довольно большими, близко к 100% :)
Данные, которые Вы удаляете, сохранены в журнале транзакций, это - часть того, как транзакции работают. В другом случае Вы любой не смог бы ROLLBACK транзакция или a COMMIT взял бы навсегда (как в старых версиях PostgreSQL).
Лучше всего можно обойтись без питания с файлами данных:
- Удалите свои данные.
- Выполните несколько
UPDATEs на таблице для уничтожения старых данных. - Выполните несколько больших транзакций и фиксируйте их, чтобы журнал trasaction был усеченным. Сколько точно зависит от Вашего размера журнала.
CleanSweepместо на диске занято старыми журналами транзакций.
- Выполните несколько
Ну, я просто играю здесь, но Вы пробуете это, это будет довольно безопасно.
Не используйте типичное резервное копирование.
Сценарий схема, если Вы уже не имеете.
Сценарий все данные так, чтобы весь ток мог быть вставлен со сценарием со многими операторами INSERT. Удаленные данные не обнаружатся в этом файле, очевидно. Конечно, Вы захотите использовать Объемную Вставку и все что вернуть данные туда.
Теперь используйте sdelete для удаления всех файлов данных и журналов, связанных с базой данных. Теперь, восстановление из сценария вставки.:)
Между прочим, Ваш вопрос и редактирование, которое Вы сделали, говоря Вас, не хотят решения, но причины, почему не к противоречит Вашему целому вопросу. Так или иначе серьезное основание не, чтобы сделать это состоит в том, что никто не делает его. Если Вы хотите сделать что-то в вычислениях (кроме создания некоторого совершенно нового вида приложения или чего-то как этот), что никто больше не делает, это - вероятно, плохая идея. Нет никаких академических бумаг или бумаг DOD к моему знанию, которые описывают метод, чтобы сделать это.
Большая проблема - то, какая информация будет "пропущена" от записей, которые Вы удалили к записям, которые не были удалены. Отметьте, здесь я имею в виду "утечку" в смысле информационного потока.
Хотя, честно говоря, метод, который я обрисовал в общих чертах выше, по существу выполнит Вашу цель.