NTFS 上的重写文件是否使用相同的块?

信息安全 ntfs 处理
2021-08-18 23:13:35

假设我们在 Windows 7 机器 NTFS 文件系统上生成一个敏感文档。当我们编写文档时,它会变长,我们会一直保存它,这意味着编辑器会从头开始覆盖它,将其截断为零长度并重新创建新内容。

假设编辑器本身重用了相同的文件系统对象,我们是否保证文件系统将使用磁盘上相同的物理块来处理文件中已经存在的所有部分?或者它可以立即分配新块,因为文件的尾端被截断了?

还是取决于文件的写入方式:覆盖后显式截断,而不是打开覆盖?

与安全性相关的是,如果释放了先前的块并且可能为文件分配了不同的块,则仅通过粉碎文件来销毁它是不够的;我们必须在完成多次保存后擦除所有可用空间。为避免这种情况,我们必须一次生成文件,否则在每次保存之前在编辑器之外粉碎磁盘上的副本。

4个回答

一般来说,块分配是文件系统中最昂贵的操作,因此文件系统会尽力避免它,特别是在可能的情况下重用块。这将意味着以下内容:

  • 覆盖现有文件时,会重复使用相同的块。当新文件数据超过被覆盖文件的数据时,分配新块。

  • 截断现有文件时,所有块都被释放,因此可能可重用于其他文件操作。在这种情况下,新文件可能会分配新块。不能保证新文件内容会重新分配相同的块,特别是旧块可能同时被重新分配给其他文件。

但是,它在很大程度上取决于文件系统内部。日志结构文件系统在整个分区中按顺序执行所有写入,因此使用这样的文件系统几乎可以保证新文件不会覆盖旧文件中的块。日志文件系统可以将文件内容复制到一个额外的结构(“日志”),除了实际的永久存储(取决于日志是扩展到文件内容,还是只是元数据)。一些文件系统还使用“阶段树”,可以将其视为日志结构的文件系统,使用树而不是列表;对于这些,可能会或可能不会发生覆盖。

需要考虑的重要一点是块分配策略不仅取决于文件系统,还取决于实现例如,不能保证 Windows XP 和 Windows 7 在同一个 NTFS 文件系统上的行为相似。一个操作系统版本可能会发现保留旧块以“加速(重新)分配”是值得的,而另一个操作系统版本可能会采用另一种策略。这都是启发式的,经过调整和重新调整。因此,无法真正回答您关于“NTFS”的问题;人们不得不谈论“在 OS foobar 中实现的 NTFS,版本 42.17,构建 3891”。


此外,所有这些块都是操作系统看到的;实际上物理存储可能会有所不同,并且可以移动/复制数据。这是 SSD 中典型的磨损均衡算法。一般来说,在 SSD 上覆盖/粉碎文件是不可靠的(有关详细信息和指针,请参阅此答案)。但是磁盘也可能发生一些数据移动(特别是当检测到片状扇区时;重新映射是即时完成的,并且旧扇区永远保持不变)。

这基本上意味着文件粉碎不能很好地工作,因为它不能保证数据会被破坏。当其他方法失败或错误地未应用时,您应该仅将文件粉碎用作紧急措施。永久销毁文件的正确方法是:

  • 整个磁盘的批发销毁,例如通过将其溶解在酸中。
  • 加密:当数据被加密时,破坏密钥就足以使数据无法恢复。虽然这并不能完全解决问题(您仍然必须销毁数据元素),但它使问题变得更容易(密钥很小:销毁 128 位比销毁 128 GB容易得多)。

安全擦除,当磁盘正确实施时,与加密技巧一起使用。

首先,如果驱动器是 SSD,则不会,因为除了操作系统正在执行的任何操作之外,驱动器还将执行磨损均衡,这意味着即使操作系统正在写入相同的块,数据也可能会被写入不同的驱动器位置。

在 Windows 中,文件描述符包括文件名,不像大多数 Linux 系统将物理数据分配 9inone) 与目录条目(文件名)分开。因此,当您开始重写现有文件时,操作系统将取消所有后续块与第一个块的链接,因此第一个块保持不变,但后续块将被重新分配 a,d 可以以不同方式分配。

可以使用安全擦除文件的工具,这些工具对文件执行破坏性写入而不截断它,然后重命名文件名以覆盖目录条目。

您不能假设将使用相同的块。正如其他答案中所说,使用 SSD 和磨损均衡,它超出了您的控制范围。对于敏感文档,我建议使用加密容器,例如TrueCrypt. 不要忘记使用加密的交换文件。

这种行为肯定是您正在使用的文档处理软件的特征吗?自从我查看OOXML 标准以来已经有一段时间了,如果您获取该文档,它是相当……健康的。我假设您使用的是 Microsoft Office,如果我迈得太大,请原谅我。再加上 OOXML 用作容器的 Zip 格式使得规范中的设施可以从容器中流式传输文件的一部分,我想不出以这种方式创建的文档是不可变数据的原因 -结构体。

如果它不是 Office,并且应用程序确实像这样运行,我不确定它不会在编译器或内核中得到优化,除非软件工程师明确禁止此功能。

但是如果你想做一些检查,你总是可以使用fsutil来查找文件 ID,类似的概念是 Posix INodes 或 VNodes,如果你安装了 cygwin,你可以使用ls -i.

我需要复习各种 SSD 架构的内部结构,但我想知道这个问题是否源于 TRIM,以及(至少在某一点上)您可能无法确信用随机函数覆盖文件会实际上已经覆盖了文件,而是应用了磨损均衡算法来平滑驱动器上的 IOP。

我希望有人能对此有所了解,但也许如果不仅仅是为了心理体操,你可能会关注错误的问题。如果您需要对您的静态数据进行一些合理的保证,并且该文档足够敏感以至于您担心泄漏;也许文档或驱动器应该被加密。