答案是“可能”,但最好假设“是”。
当您覆盖固态驱动器上的现有文件时,处理磨损均衡的特殊驱动程序通常通常不会真正覆盖旧数据所在的确切位置。这是因为在保存该位置的单元耗尽之前,固态驱动器只能有限次数地写入同一位置。因此,磨损均衡驱动程序不会覆盖旧位置,而是查看驱动器上哪些点磨损较少,并将其映射到您要覆盖的位置。旧的、被覆盖的数据本身被重新映射到没有被使用的地方。
这有点过于简单化了。这种重新映射并不总是发生,不同的 SSD 设备以不同的方式处理这个问题,这取决于操作系统是否知道它是一个固态驱动器。但是您永远不能认为覆盖任何单个文件会导致该文件的数据在任何 SSD 上被破坏,这包括 MicroSD 卡、USB 记忆棒和其他便携式固态设备。
擦除最旧的“已删除”数据的最佳方法是用随机数据填充该驱动器的所有未使用空间。如果您填满了驱动器上的全部未使用空间,那么您就有最好的机会覆盖之前删除的所有内容。但这有两个警告。第一个是,你会在你的驱动器上造成很多磨损。您将该驱动器上的每个单元可写入的次数减少了 1。另一个警告是,您不一定会以这种方式删除所有旧数据。这是因为许多固态驱动器,包括大多数更好的驱动器,都有一些不会向用户显示的额外空间。这个额外的空间被保留用于重新映射到单元几乎磨损的地方。然后,当它被重新映射时,旧的单元格被永久地映射出来,但它仍然有以前的东西。获取这些数据很困难,但通常并非不可能。许多制造商都有专有方法来查看重新映射的内容,并且可以访问旧数据。现在,一个单元在拥有敏感数据后立即停止服务的几率可能很低。这完全取决于您的驱动器上有多少敏感数据。但这不是零机会。
有两种通用方法可以覆盖驱动器上已删除的旧数据。您可以通过简单地创建一个增长以填满文件系统上所有空白空间的文件来非破坏性地(对文件系统和驱动器上的当前文件)执行此操作。您可以通过用随机数据填充该驱动器的块设备(从主干到尾端)来破坏性地做到这一点。
非破坏性: 在 Linux 中,您可以执行如下非破坏性方法:
$ dd if=/dev/urandom of=random.bin
Run Code Online (Sandbox Code Playgroud)
您可能需要以 root 身份执行此操作,以便也覆盖文件系统的保留部分。这会耗尽文件系统上的所有可用空间,因此当您在根文件系统上执行此操作时,可能会出现诸如 syslog 之类的东西无法再写入日志的后果。不过,这通常不是灾难性的,如果您在重新启动后快速删除 random.bin 文件,通常就可以了。更谨慎的方法是首先从 Live CD/DVD/USB 启动,然后挂载 SSD 文件系统并在其中执行上述操作。如果 SSD 上有多个文件系统,那么在删除其中任何一个文件系统上的 random.bin 之前,您需要对所有文件系统执行此操作。
破坏性: 这更容易,并且是最完整的方法,您可以使用它来避免驱动器的物理破坏。从 Live CD/DVD/USB 启动,然后一旦确定了用于 SSD 的物理设备,您就可以使用:
$ dd if=/dev/urandom of=/dev/sda bs=1M
Run Code Online (Sandbox Code Playgroud)
其中 /dev/sda 被替换为您的 SSD 设备。但是,您必须在执行此操作后重新制作所有分区。当您在 SSD 上进行分区以确保它们与设备的内部存储单元和块大小正确对齐时,有时会产生一些后果,因此请研究一下。
就地加密驱动器然后销毁密钥已被提议作为擦除驱动器的替代解决方案。这充其量并不比上面的破坏性方法好,最坏的情况是可以恢复驱动器的几乎全部内容。可能的问题是,某些加密产品默认情况下不会用随机数据覆盖可用空间,或者有办法将其关闭,它们不一定会覆盖现有分区之间或末尾的空闲空间驾驶。
简而言之,没有 100% 可靠的方法来确保任何 SSD 上的敏感数据都被覆盖。确保无法从固态驱动器中提取敏感数据的唯一方法是物理销毁它。我的意思是确保每个存储芯片中间的实际硅晶片断裂。有驱动碎纸机专为做到这一点而设计。在高温下燃烧也是有效的。
必须指出的是,几乎所有这些痛苦都可以通过预防来规避(或至少减轻)。从一开始就使用全盘加密系统,以便永远不会将未加密的数据写入驱动器,这是确保您的数据最安全的最佳方式。即便如此,在驱动器的 EoL 时,我仍然建议物理销毁驱动器或上述破坏性方法。
归档时间: |
|
查看次数: |
411 次 |
最近记录: |