уничтожение данных

Попробуйте BCWipe от Jetico, она затирает и названия файлов.

Пофайловое стирание в современных файловых системах и на современных носителях – ненадёжный метод уничтожения информации. Тогда уж нужно затирать весь носитель целиком.

В Unix программа shred вроде трёт и названия файлов, но вот с названиями директорий у неё какая-то беда.


Есть простая контрмера: создаёте шифрованный LVM-том (раздел) нужного небольшого размера и делаете его чистую копию на другой LVM-том (раздел). Когда надо затереть файлы, просто делаете luksClose, luksKillSlot и форматируете его заново, после чего восстанавливаете содержимое из чистой копии (бэкапа). Это быстрый и надёжный способ удаления файлов. А в других разделах исходите из того, что быстро затереть их нельзя. В общем, это скорее организационный вопрос.

спасибо, попробую BCWipe поскольку работаю под windows.

Очевидно удачный пример использования LVM-ов. Разве что пересоздавать файловую систему заново и заново переносить все файлы на чистую FS может занять заметное время.

Есть ещё всякие free-space-over-FS вайперы, наподобие secure-delete, но особого доверия к ним нет.

Поэтому нужно делать такие файловые системы компактными и хранить на них только то, что реально необходимо — например, логи и настроки IM. У меня примерно такая схема работает для юзера, из-под которого запускается TBB. На файловой системе ничего кроме нескольких конфигов и распакованного бандла TBB нет, всё распаковывается и зачищается за секунды, при этом можно быть уверенным, что всё временное и неважное, связанное с работой браузера в сети, надёжно зачищается.

Поэтому нужно делать такие файловые системы компактными и хранить на них только то, что реально необходимо — например, логи и настроки IM.

С теми же целями (если данные нужны в пределах одного сеанса) можно использовать tmpfs, даже слоты в случае чего убивать не нужно.

Everything stored in tmpfs is temporary in the sense that no files will be created on the hard drive; however, swap space is used as backing store in case of low memory situations.

Но swap лучше шифровать или отключать.

Можно, и это даёт ряд преимуществ, но менее гибко. Например, если у меня есть временный пул важных файлов, который я ещё не успел перенести на постоянный раздел, я буду расстроен, если они утеряются из-за внезапного зависания системы и перезагрузки. К тому же, иногда надо перезагрузиться, а времени скопировать файлы нет — в этом случае копирование можно отложить, если используется убивание слотов LUKS, но нельзя, если используется tmpfs.

Подтверждаю. + В тему этих комментариев: делаешь, как описано — df показывает всё равно наличие некоторого свободного места на файловой системе. Повторяешь с другим именем файла — и оно иногда уменьшается, иногда нет. Но факт, что второй файл создаётся, а также создаётся и третий и т.д. Где они создаются, если ФС уже забита? Значит, не всё забито, есть ещё место для хранения данных, есть какие-то резервы. И, вообще, в отличие от BSD, в Linux df показывает где-то на 5% меньше свободного места для ФС, чем есть на самом деле (Used+Avail≠Size в df).

Есть ещё такая параноическая мысль: в Unix используется корневая древовидная система для файлов. Когда в какой-то каталог монтируется внешняя иная файловая система с другого раздела, что происходит? Может ли так быть, что какие-то файловые структуры/метаданные из внутренней ФС могут переползти во внешнюю? Вроде это звучит глупо, тем более, что файловые системы могут быть вообще разными, но вот мало ли... Вдруг я чего-то не знаю? Скажем так, насколько такая изоляция данных (всё критичное подмонтировано с иных разделов, но на ту же корневую ФС) надёжна?

И, вообще, в отличие от BSD, в Linux df показывает где-то на 5% меньше свободного места для ФС, чем есть на самом деле (Used+Avail≠Size в df).

Зарезервировано для рута.

. -m reserved-blocks-percentage Specify the percentage of the filesystem blocks reserved for the super-user. This avoids fragmentation, and allows root-owned daemons, such as sys- logd(8), to continue to function correctly after non-privileged processes are prevented from writing to the filesystem. The default percentage is 5%.

Для чистки дисков нужно использовать стандартную команду – Secure Erase. После неё заполнить устройство случайными данными, для неразличимости использумых участков от неиспользуемых. Эти два шага дают максимальную защиту, которая сейчас доступна. Все остальные способы небезопасны.

Спасибо за информацию. Теперь заодно понял, почему раньше ноль писалось, а потом перестало (ранее из-под рута тёр).


Вы про низкоуровневый доступ к SSD? Там с HPA что-то не очень вразумительное происходит.


А люди не верят в возможность надёжного частичного затирания данных на SSD, если вы об этом.

Ну, и, вообще, SSD — это отдельный вопрос.

Вы про низкоуровневый доступ к SSD? Там с HPA что-то не очень вразумительное происходит.

К любому ATA-устройству. В HPA разве записываются пользовательские данные? Скорей всего нет, поэтому даже если Secure Erase его не затирает, в этом нет необходимости.

А люди не верят в возможность надёжного частичного затирания данных на SSD, если вы об этом.

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