希望将应用程序部署到 Windows ">Azure 的企业客户（实际上是所有客户）最为关心的就是其数据的安全性。释放磁盘空间并将其重新分配给其他客户时，要确保新的所有者无法读取释放空间后磁盘上原来的数据，在数据保护中这一点有时会被忽视。一个极端的例子是，废弃处理从数据中心移除的驱动器或在其他任务中再次利用。释放之前先使用零或其他模式覆盖释放的空间，是确保这一点最简单的方式。这种覆盖可能会大大影响性能，因此 Azure 与大多数系统一样，会使用更为复杂但更有效的机制。
在本文中，我们将发现 Windows Azure 和 SQL Azure 软件为达到以下目的而实施的做法：防止在删除 Windows Azure 虚拟机实例、Windows Azure 虚拟机驱动器、Windows Azure 驱动器、Windows Azure 存储、SQL Azure 数据或 SQL Azure 实例本身时造成数据泄露或将一个客户的数据暴露给其他客户。这些机制的细节有所不同，但概念均类似，即：不允许任何用户从之前未写入数据的磁盘位置读取数据。
本文中的详细信息由 Windows Azure 首席软件工程师、杰出的安全架构师 Charlie Kaufman 提供。您可以在此处和此处找到 Charlie 的一些著作。Charlie，谢谢你！
关于数据保护的概念
在实践中，磁盘是稀疏分配的。这意味着在创建虚拟磁盘时，不会分配全部的磁盘空间量。而是创建一个表，将虚拟磁盘上的地址映射到物理磁盘上的区域，并且该表最初为空白。客户第一次在虚拟磁盘上写入数据时，将会分配物理磁盘空间并在表中设置标志。我们可以通过下面的一系列图表来了解其概念：
图 1：分配给用户的数据块
在上面的图 1 中，基于两个用户各自的写入请求为他们各分配两个数据块。
图 2：用户释放数据块
在上面的图 2 中，一个用户“删除”数据以释放数据块。数据块标记为可用，其他方面不受影响。
图 3：为用户分配最近释放的数据块
在上面的图 3 中，在新用户请求写入时为其分配最近释放的数据块以及之前未分配的数据块。之前释放的数据块仍然不受影响。实质上，该过程是这样的，当用户请求写入到磁盘时，必须确定已分配给该用户的现有磁盘上是否有足够的空间可存储新数据。如果有，新数据将覆盖现有块中的数据。如果没有，则将分配新的数据块并将数据写入到新块。可在下图中查看该逻辑。
图 4：用户请求将数据写入到磁盘
现在的问题是某个客户可能会读取其他客户已删除的数据，Azure 管理员也可能会读取客户已删除的数据。如果任何人尝试从虚拟磁盘上其尚未写入数据的区域进行读取，则不会为该区域分配物理空间，因此不会返回任何数据。我们可以在下图中查看该逻辑和结果。只有 Azure 管理员可以读取标记为可用的块，但管理员无法借助任何实用程序确定该块之前的所有者。
图 5：用户发出读取请求
从概念上说，这适用于对读取和写入进行跟踪的任何软件。对于 SQL Azure，由 SQL 软件执行此操作。对于 Azure 存储，由 Azure 存储软件执行此操作。对于 VM 的非持久驱动器，由主机操作系统的 VHD 处理代码执行此操作。由于客户软件只能访问虚拟磁盘（从虚拟地址到物理地址的映射发生在客户 VM 之外），因此无法对已分配给其他客户的物理地址或闲置的物理地址发出读取或写入请求。
注意：在某些情况下，写入逻辑（参见图 4）会被修改, 第二次写入块时不会覆盖磁盘上的数据。反之，会分配一个新的块并将数据写入该新块中。旧的块将被标记为可用。这种方法通常称为基于日志的文件系统。也许听起来效率不高，但通过这种方法可将大部分数据写入到物理磁盘上的连续位置，可最大限度地减少寻找时间并实现更好的性能。这些细节对客户是透明但相关的，因为它意味着即使客户在释放磁盘之前使用零显式覆盖虚拟磁盘上的每一个块，那也不能保证客户的数据不会仍存在于物理磁盘上。
Windows Azure 虚拟机 (VM)
删除 VM 后，原本存储其本地虚拟磁盘内容的磁盘空间会标记为可用，但并未完全清零。该空间最终将用于存储其他 VM 的数据，但并未规定过期内容留在磁盘上的时间上限。但是，虚拟化机制是为了确保再次写入数据之前其他客户（或同一客户）无法读取磁盘上的这些点，从而确保不会产生数据泄漏威胁。为 VM 创建新的虚拟磁盘后，虚拟磁盘看似已经清零，之所以会造成这种假象是因为在读取未写入的虚拟磁盘区域时, 我们总是返回零。如果对 VM 实例进行重新初始化，则相当于是将其移动到新的硬件。
Windows Azure VM 驱动器和 Windows Azure 驱动器 (X-Drive)
在 Windows Azure 中，VM 实例可以访问的虚拟驱动器有两种。计算节点的本地磁盘, 即 Web role 和 Worker role 中的 C: 盘、D: 盘和 E: 盘。这些盘上的数据并非以冗余方式存储，必须将其视为短暂性数据。如果发生硬件故障，则会将 VM 实例移动到其他节点，虚拟磁盘的内容将重置为初始值。如果对 VM 实例进行重新初始化，则 C: 盘、D: 盘和 E: 盘将恢复为初始状态，这相当于是将其移动到新的硬件。
Windows Azure 驱动器（也称为“X-Drive”）被存储于 Windows Azure 存储中的 Blob。X-Drive 是持久性的，除非客户采取显式操作将其更换，否则不会被重置。此数据以冗余方式存储，即使发生硬件故障也不会丢失。删除 VM 实例不会删除关联的 X-Drive 中的数据。删除 Blob 本身（或删除包含 Blob 的存储帐户）才会删除 X-Drive。请参阅下一节，其中说明了如何处理 Windows Azure 存储中的数据删除。
Windows Azure 存储（表、Blob、队列）
在 Windows Azure 存储子系统中，一旦调用删除操作，则客户数据将不可用。所有存储操作（包括删除）旨在立即实现一致。成功执行删除操作将删除相关数据项的所有引用，并且无法通过存储 API 对其进行访问。删除的数据项的所有副本最终都将被回收。当关联的存储块重新用于存储其他数据时，物理信息将被覆盖（即重新初始化），就像标准的计算机硬盘驱动器一样。
SQL Azure
在 SQL Azure 中，删除的数据标记为删除，但不会被清零。如果删除了整个数据库，则相当于删除了其全部内容。在任何情况下，SQL Azure 实现均可通过禁止对基础存储的所有访问（除非通过 SQL Azure API）来确保使用过的数据不被泄露。该 API 允许用户读取、写入和删除数据，但绝不允许用户读取之前未写入的数据。
自动备份和取证
通常情况下，客户希望确保他们的数据不会在未经授权的情况下被访问。在某些情况下，他们甚至希望确保已删除的数据不会在未经授权的情况下被访问。数据一旦删除或更改，就无法再通过提供给客户的接口进行检索，但这些数据可能会在相当长的时期内继续保留在磁盘上，并且理论上可使用内部取证工具对其进行恢复（但已删除的数据存在的可能性会随着时间而降低）。最终，从生产环境删除的任何物理磁盘都将完全清除或销毁。
我们正在考虑在不久的将来推出一些功能，使客户无需进行显式备份即可恢复已删除的数据（以及还原已更改的数据）。使用这些工具就无法完全向客户保证这些数据在删除后不会被得到授权的相关方访问。任何此类工具都只能在有限的时间内（不超过 30 天）检索已删除的数据，除非客户选择更长的备份时间。撰写本文时，有一些未公开的工具，可允许在 14 到 21 天内恢复从 SQL Azure 数据库中删除的数据。对于 Azure 存储或 Azure 计算临时磁盘，尚无此类工具。