BitLocker 实务指南——恢复密钥的查找方法与安全管理

“更新 BIOS 之后，出现蓝色界面要求输入 48 位数字。”“明明不记得自己设置过，设备加密却是打开的。”遇到 BitLocker 相关的麻烦时，当前 Windows 是否还能启动决定了首先该做什么。

如果已经卡在恢复界面，那么在更改设置或重置之前，先查找与界面上恢复密钥 ID 相符的密钥。如果还能启动，就不要只看加密的开关，而要确认保护状态和恢复密钥的保存位置。把这两种情形分开，需要做的工作就更容易看清。¹²

本文是面向个人电脑用户、中小企业 IT 负责人，以及管理业务应用和设备用电脑的开发者的实务指南。前半部分讲恢复和状态确认，后半部分讲部署、维护和报废。文中的管理命令都是在 Windows 上以管理员权限执行的示例，不是能够直接在恢复界面上执行的步骤。技术信息依据截至 2026 年 9 月 8 日已核实的 Microsoft 公开资料。

图中实线表示始终成立的关系，虚线表示带条件的关系（成立条件写在详情页各关系的说明中）。关系的完整列表（共 48 条，附依据与确信度）以及主要概念的定义，汇总在知识地图详情页（日文）。数据：JSON-LD / Turtle

1. 出现恢复界面时，先找密钥再考虑重置

1.1. 要输入的 48 位数字和用于查找的 ID 是两回事

面向一般用户的界面上所说的“BitLocker 恢复密钥”，通常指由 48 位数字组成的恢复密码，既不是 Windows 的登录密码，也不是 Windows Hello 的 PIN。而界面上显示的恢复密钥 ID 是用来从已保存的密钥中挑出正确那一个的标识符，本身并不是用于解锁的机密。¹

先记下密钥 ID 的前 8 个字符。它不一定只有数字，所以不要把它当成“8 位密码”。用另一台电脑或手机打开保存位置，从 ID 相符的条目中取出 48 位恢复密钥，输入到恢复界面。有时同一个电脑名下还留着旧记录，因此不要只凭电脑名来挑选。在 Windows 11 24H2 及以后的版本中，恢复界面有时还会显示用于推测保存位置所属 Microsoft 账户的线索。¹

flowchart TB
        accTitle: 恢复密钥 ID 与恢复密钥的作用
        accDescr: 说明用界面上的 ID 核对保存位置中的条目，再输入对应 48 位数字的步骤。
        A["记下恢复界面的密钥 ID"] --> B["在另一台设备上打开保存位置"]
        B --> C["查找 ID 相符的记录"]
        C --> D["输入对应的 48 位数字"]

图1：ID 用于查找密钥，48 位数字用于解锁驱动器。

1.2. 不要臆断保存位置，要追溯到当初启用的时候

这些是有代表性的保存位置，并不是互相排斥的四选一。同一个密钥也可以保管在多个地方。不能因为“用了 Microsoft 365，所以密钥一定在公司这边”或“现在用的是本地账户，所以 Microsoft 账户里不会有”就下结论。要确认设置这台电脑的人、加入组织的状态、启用当时的策略，以及后来做过的备份。¹³⁴

技术文档会区分 48 位的恢复密码和保存在 U 盘等介质上的 .bek 格式恢复密钥。本文沿用面向一般用户的叫法，把前者称为“恢复密钥”，但 .bek 文件并不是拿来当成 48 位数字输入的。请按照实际配置使用相应的恢复步骤。³

1.3. 即使找不到密钥，删除数据的操作也要放到最后

在还没找到密钥的阶段，不要去尝试清除 TPM、更改安全启动设置或重置系统。增加那些本身就可能触发恢复要求的变更，并不会让原本没有保存下来的恢复密钥出现。组织内的电脑要向管理员核实，确认是否存在事先配置的数据恢复代理等其他正规恢复手段。³⁵

如果所有有效的解锁手段都已丢失，Microsoft 支持部门也无法取出或重新生成恢复密钥。到了这一步，就要确认能否从另外保管的数据备份中恢复。为了重新使用这台电脑而进行的重置、重新安装，和把原来的加密数据取回来是两件不同的事。请在理解重置会丢失本地文件之后再做判断。¹

flowchart TB
        accTitle: 找不到恢复密钥时的判断
        accDescr: 先向管理员核实并确认其他恢复手段，再把数据备份和电脑的再利用分开判断。
        A["在常规保存位置找不到"] --> B["向管理员和当初设置的人核实"]
        B --> C{"是否存在有效的解锁手段"}
        C -- "有" --> D["按正规步骤恢复"]
        C -- "没有" --> E["确认数据备份"]
        E --> F["确认丢失范围后判断能否再利用"]

图2：关键在于不要把找密钥、恢复数据和重置电脑当成同一个操作。

2. BitLocker 保护什么，不保护什么

BitLocker 是 Windows 中以卷为单位的加密功能。它的主要目的是降低因丢失、被盗或不当报废，导致已存储的数据被离线读取的风险。例如把 SSD 拆下来接到另一台电脑上，只要没有有效的解锁手段，也无法把加密后的内容当作普通文件读取。另外，“整个驱动器”这种说法并不意味着连 EFI 等启动分区在内的一切都会被加密。⁶

另一方面，在 Windows 已启动、驱动器处于解锁状态期间，拥有访问权限的应用可以读写文件。仅靠 BitLocker 并不能防住恶意软件、勒索软件，以及从已登录设备上带走数据的行为，它也不能代替数据备份。评估加密时，要把保护处于哪种状态的设备、防范什么样的对手分开考虑。⁷

flowchart TB
        accTitle: BitLocker 发挥作用的场景
        accDescr: 说明离线驱动器的保护与启动后应用的访问属于不同的层面。
        A["已存储的业务数据"] --> B["离线的驱动器"]
        A --> C["已启动的 Windows"]
        B --> D["由 BitLocker 保护内容"]
        C --> E["还需要权限和应用侧的措施"]

图3：存储数据的加密与启动后的访问控制，承担的角色不同。

TPM 不是加密数据的装置，而是保护密钥的机制

在常见配置中，BitLocker 利用 TPM 来保护密钥。启动组件的度量结果会记录到 TPM 的 PCR 中，满足所配置的验证条件后，才能使用正常启动所需的密钥。这既不表示 TPM 本身在加密 SSD 上的全部数据，也不表示它会一律拒绝所有 BIOS 变更。⁶⁸

flowchart TB
        accTitle: 使用 TPM 的 BitLocker 正常启动与恢复
        accDescr: 启动环境的度量值满足验证条件时正常解锁，不满足时就需要恢复手段。
        A["度量启动环境并记录到 PCR"] --> B{"是否满足所配置的验证条件"}
        B -- "满足" --> C["使用 TPM 正常解锁"]
        B -- "不满足" --> D["需要用恢复手段解锁"]

图4：启动环境的变更是否会引发恢复要求，还取决于验证的条件。

BIOS/UEFI 更新、禁用或清除 TPM、更改安全启动设置、更换主板、把驱动器移到别的机器等，都可能成为要求恢复的触发条件。正规的维护作业也会引发，所以不能仅凭出现了恢复界面就断定“被攻击了”或“坏了”。反过来，如果毫无缘由地反复出现，就需要调查更新历史、配置变更和硬件状态。³

也有把 TPM 与启动时 PIN 组合起来的配置，以及使用启动密钥的配置。没有 TPM 时，在受支持的版本和策略下同样可以加密操作系统驱动器。不过，针对没有 TPM 的操作系统驱动器的密码方式存在抗暴力破解能力不足的问题，默认是禁用的。请不要把它与固定数据驱动器的密码保护混为一谈。TPM 的细节见“Windows 的 TPM 是什么”。⁶

3. Home 与 Pro 的差异，以及 Windows 11 的自动加密

3.1. “设备加密”同样使用 BitLocker 的技术

“BitLocker 驱动器加密”和“设备加密”并不是互不相关的两种加密产品。后者使用 BitLocker 的技术，让受支持的电脑更容易启用加密。两者的设置界面和可管理的范围不同。⁹

设备加密的对象是操作系统驱动器和内置的固定驱动器，U 盘等可移动驱动器不在范围内。如果要在公司电脑上精细管理启动时身份验证和策略，就先确认所需的版本和管理服务的要求。⁶⁹

3.2. 24H2 改变的是适用条件，而不是给所有电脑一律启用

在 Windows 11 24H2 中，自动设备加密的要求去掉了 HSTI/Modern Standby 以及部分与 DMA 有关的条件，因此适用的硬件范围扩大了。不过，TPM 和 UEFI 安全启动等条件、安装方式，以及组织和厂商的配置同样有影响。这并不表示“所有升级到 24H2 的电脑都会当场必然被加密并受到保护”。另外，这次要求放宽不适用于 Windows IoT 版本。⁸

在全新安装后的自动启用中，加密的初始化和保护的启用是两个不同的阶段。初始状态下存在明文密钥，即使已经加密，保护也还没有生效。当备份到 Microsoft 账户、Entra ID，或已配置恢复策略的 AD DS 等适用路径的条件齐备后，基于 TPM 的保护才会启用，明文密钥随之被移除。⁶

flowchart TB
        accTitle: 自动加密的开始与保护的启用
        accDescr: 在受支持电脑的自动加密中，从存在明文密钥的初始状态出发，经过保存恢复信息，保护才会启用。
        A["满足自动加密条件的电脑"] --> B["初始化加密"]
        B --> C["存在明文密钥、保护尚未启用"]
        C --> D["通过适用路径保存恢复信息"]
        D --> E["启用 TPM 保护"]
        E --> F["移除明文密钥"]

图5：加密处理在往前推进，与已经处于可防范第三方的状态，并不是一回事。

“只用本地账户就无法启用保护”这种说法，讲的是上述自动启用流程。它并不表示在 Pro 等版本上由管理员手动配置 BitLocker 时也“用本地账户无法加密”。另外，也存在过去已启用保护、后来切换成本地账户使用的电脑，所以不要从当前的账户名推测保护状态，而要用下一章的命令确认。⁶²

如果找不到相应的设置项，可以以管理员身份启动 msinfo32.exe，查看“设备加密支持”的信息。不过这是用来查看是否满足支持条件的显示项，请把它与用于确认驱动器当前是否受保护的显示项分开来读。⁹

4. 状态确认要区分加密百分比、保护状态和锁定状态

4.1. 一开始使用不输出机密的命令

在 Windows 能够启动的状态下，以管理员身份打开终端。先做下面的状态确认就足够了。C: 请替换为目标操作系统驱动器。¹⁰

manage-bde -status C:

在可以使用 BitLocker PowerShell 模块的环境中，可以只显示需要的项。这里不会输出恢复密码的值。¹¹

Get-BitLockerVolume -MountPoint 'C:' -ErrorAction Stop |
    Select-Object MountPoint, VolumeStatus, EncryptionPercentage,
        ProtectionStatus, LockStatus, EncryptionMethod

例如出现FullyEncrypted、100%、ProtectionStatus: Off的组合时，不能当作“已经加密所以完成了”。要查清它是处于暂停期间，还是初始化后正在等待启用，或者组织的配置还没有生效。反过来，即使是ProtectionStatus: On，也不能证明能从管理位置取到恢复密钥。²¹¹

flowchart TB
        accTitle: 加密、保护与可恢复性的确认
        accDescr: 需要分别确认加密处理、保护状态，以及恢复密钥能否取到。
        A["确认状态"] --> B["加密处理是否已完成"]
        B --> C["保护是否为 On"]
        C --> D["能否从另一台设备取到恢复密钥"]
        D --> E["把确认结果记入台账"]

图6：不只看加密百分比，还要确认保护已生效、恢复手段也在管控之下。

对于把业务数据放在D:等卷上的电脑，那个卷也要纳入范围。用manage-bde -status查看整体情况，检查是否只加密了操作系统驱动器而漏掉了数据驱动器。¹⁰

4.2. 显示恢复密钥的操作要与状态确认分开对待

如果已经配置了恢复密码，并且可以在 Windows 上管理目标驱动器，就能用下面的命令查看密钥保护器的信息。但要注意，48 位的机密有可能被直接显示出来。不要把输出整段贴到公开聊天、GitHub Issue、支持请求、屏幕共享或采集的日志里。¹²

:: 注意: 会显示恢复密码的值。不要直接共享输出内容
manage-bde -protectors -get C:

如果只需要类型和 ID，就用 PowerShell 限定显示项。这个示例是为了避免把恢复密钥的值和记入台账的标识符混为一谈。¹¹

(Get-BitLockerVolume -MountPoint 'C:' -ErrorAction Stop).KeyProtector |
    Select-Object KeyProtectorType, KeyProtectorId

这个操作并不是从无法启动的电脑里取出未知密钥的窍门，它只是查看当前可访问的卷上配置了哪些保护手段。如果没有恢复密码，或者尚未确认已备份到保存位置，就按组织的步骤完成添加、保存和取用确认。²

5. 公司电脑要管到“能够恢复”，而不是止于“已加密”

5.1. 保存位置和取用权限要成对确定

已加入 Entra ID 的电脑，代表性的管理位置是 Entra ID；已加入 AD 域的电脑则是 AD DS。不过，不要仅凭“已加入”这一事实，就认定期望的密钥已经保存好了。还要确认保存到 AD DS 的策略、Entra ID 和 Intune 侧的配置，以及备份处理是否成功。即使是混合加入，只要设计上要用到两个保存位置，就需要分别确认两边都确实存在。¹³¹⁴

小规模组织不使用域或 Entra ID 时，也可以在受支持的版本上手动配置，并管理受访问控制的保管位置或纸质留底。关键在于不要只依赖负责人个人的 Microsoft 账户，而要做到即使负责人离职、即使电脑无法启动，有权限的人也能取出密钥。也要避免把密钥和电脑放进同一个包里这种保管方式。⁴

flowchart TB
        accTitle: 恢复密钥的保管与取用确认
        accDescr: 不只是从电脑保存到管理位置，还要确认有权限的负责人能从另一台设备取到。
        A["纳入管理的电脑"] --> B["备份到经批准的保存位置"]
        B --> C["有权限的负责人"]
        C --> D["从另一台设备核对 ID 并取出"]
        D --> E["确认其缺席时的替补人员"]

图7：运维要做到有权限的负责人实际取到密钥，而不是停留在“应该已经保存了”。

台账里记录资产编号、目标卷、恢复密钥 ID、保存位置、可以取用的负责人和最后确认日期，会更便于处理。48 位数字本身要从普通的资产台账中分离出来，作为机密信息保管。还要确认访问备份位置时，是否必须用到那台已经无法启动的电脑。以上是本文建议的运维确认项。

5.2. 新部署时，把保存恢复信息作为启用的前提

使用 AD DS 时，可以通过“选择如何恢复受 BitLocker 保护的操作系统驱动器”等策略，配置恢复信息的保存内容，以及在保存到 AD DS 之前不启用 BitLocker 的设置。固定数据驱动器也要确认对应的策略。使用 Entra ID 和 Intune 时，同样要结合设备的加入状态选择对应的策略，包括要求备份的设置。¹³¹⁴

flowchart TB
        accTitle: 组织内部署 BitLocker 的顺序
        accDescr: 先确定恢复信息的保存位置和策略，并且不把保存失败的设备算作已完成。
        A["确定保存位置、取用权限和方式"] --> B["应用强制备份的策略"]
        B --> C["在设备上执行启用步骤"]
        C --> D{"是否确认恢复信息已保存"}
        D -- "否" --> E["查明原因，不结束部署"]
        D -- "是" --> F["确认加密和保护均已完成"]

图8：比起赶着加密，更应优先避免造出没有恢复手段的设备。

单台电脑可以从控制面板的“管理 BitLocker”依次完成启用、保存恢复密钥和选择加密范围。用于组织批量部署的脚本，需要把中途失败的情况也一并设计进去。不要只把Enable-BitLocker -TpmProtector这一行发到所有电脑，然后按“密钥以后再保存就行”的方式运维。请先在少量验证设备上确认强制保存的策略和恢复信息的取用。²

5.3. 事后备份已有恢复密码的示例

下面是只把已经存在的恢复密码备份到 Entra ID 的示例。它不会开始加密、不会创建新的恢复密码，也不会删除旧的密钥保护器。请在能够备份到 Entra ID 的加入状态和配置下，以管理员身份执行。¹⁵

$mountPoint = 'C:'
$volume = Get-BitLockerVolume -MountPoint $mountPoint -ErrorAction Stop
$recoveryProtectors = @(
    $volume.KeyProtector |
        Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' }
)

if ($recoveryProtectors.Count -eq 0) {
    throw '没有恢复密码。请按组织的步骤进行添加和保存。'
}

foreach ($protector in $recoveryProtectors) {
    BackupToAAD-BitLockerKeyProtector -MountPoint $mountPoint `
        -KeyProtectorId $protector.KeyProtectorId -ErrorAction Stop | Out-Null
}

Write-Output '保存处理已完成。请在管理位置确认各个 ID 的恢复密钥。'

如果配置为保存到 AD DS，就把上面循环中的备份处理替换成下面这段。这不是一个把两者无理由地连续执行的示例。请确认目标域和策略等前提条件。¹⁶

Backup-BitLockerKeyProtector -MountPoint $mountPoint `
    -KeyProtectorId $protector.KeyProtectorId -ErrorAction Stop | Out-Null

命令执行成功后，要在管理位置核对密钥 ID，并确认有权限的负责人能够取到。示例中抑制输出，是为了不让恢复密钥流入日常的运维日志。要避免用一条成功消息代替加密百分比、保护状态、恢复信息保存位置这三项确认。

6. BIOS 更新时不要把“暂停”和“禁用”混为一谈

6.1. 暂停期间即使已加密，保护也会变弱

BitLocker 的暂停保护，是在保持数据加密的前提下，用明文密钥让系统能够启动的操作。而禁用是解密驱动器、取消 BitLocker 保护的操作。维护时需要的是前者，如果执行了后者，就会带来漫长的解密处理和保护的丧失。Microsoft 也说明，不要把禁用当作通用的故障排查步骤。¹⁷²

flowchart TB
        accTitle: 暂停与禁用的区别
        accDescr: 暂停会保持加密而临时停止保护，禁用则会解密驱动器。
        A["更改 BitLocker 的状态"] --> B["暂停保护"]
        A --> C["禁用"]
        B --> D["保持加密、使用明文密钥"]
        C --> E["解密驱动器"]

图9：暂停不是解密，但这并不表示暂停期间也和平时一样安全。

不要因为处于暂停状态的电脑不会要求恢复密钥，就把它放着不管，或者就这样交给外部单位。明文密钥会削弱离线状态下的保护，所以要限定作业时间和物理管控范围，作业结束后恢复保护。¹⁷

6.2. 先确认密钥，作业后确认到 On 为止

并不是所有 Windows 更新都需要手动暂停。具体做法会因更新内容、电脑厂商的更新工具，以及所使用的 TPM 验证配置文件而不同。先确认厂商的步骤，对于需要暂停的作业，要先确认能从另一台设备取到恢复密钥，然后再执行。⁸

flowchart TB
        accTitle: 计划性固件更新的步骤
        accDescr: 确认恢复手段，只在必要时暂停保护并更新，最后以恢复保护和状态确认收尾。
        A["确认能取到恢复密钥"] --> B["确认厂商的更新步骤"]
        B --> C["必要时暂停保护"]
        C --> D["执行更新和必要的重启"]
        D --> E["恢复保护并确认为 On"]

图10：维护的收尾标准不是能够重启成功，而是确认保护已经恢复。

下面是一次重启就能完成作业时的示例。-RebootCount 1表示在指定的重启次数之后自动恢复保护。¹⁷

# 先完成恢复密钥的取用确认和厂商步骤确认，再执行
Suspend-BitLocker -MountPoint 'C:' -RebootCount 1 -ErrorAction Stop | Out-Null

接下来在这里执行更新作业和重启。并不是不做更新作业就紧接着执行恢复命令。作业之后如果没有自动恢复，就按厂商的步骤确认必要的作业已经完成，然后恢复保护。¹⁸

Resume-BitLocker -MountPoint 'C:' -ErrorAction Stop | Out-Null
Get-BitLockerVolume -MountPoint 'C:' -ErrorAction Stop |
    Select-Object MountPoint, VolumeStatus, ProtectionStatus

对于需要多次重启的更新，如果第一次重启后保护就恢复了，后续的变更可能导致进入恢复界面。所需的次数要与厂商的步骤保持一致。-RebootCount 0不是“不重启”的意思，而是不按重启次数自动恢复保护的设定。如果采用它，就要在步骤中写明作业负责人和手动恢复的确认。即使指定了自动恢复，最后对ProtectionStatus: On的确认也不能省略。¹⁷¹⁹

7. 维修、恢复之后以及丢失时该做的事

7.1. 用过恢复密钥之后，按需更换

使用过恢复密码之后，建议把该密码作废并更新。交给维修商之后也一样。为了不出现失去恢复手段的时间窗，本文建议采用添加新的恢复密码 → 确认备份和取用 → 按 ID 指定删除旧的这一顺序。先把旧的全部删掉的做法，一旦后续处理失败，就有失去恢复手段的风险。²

flowchart TB
        accTitle: 更换恢复密码的顺序
        accDescr: 先确认新恢复密码已保存且能取到，再只删除作为目标的旧密钥保护器。
        A["添加新的恢复密码"] --> B["备份到经批准的保存位置"]
        B --> C["确认用新 ID 能够取到"]
        C --> D["只删除旧的密钥保护器"]
        D --> E["确认台账和保护状态"]

图11：先确保新的恢复手段，删除对象按 ID 指定，而不是整个类型。

在加入 Entra ID 或混合加入的配置中，也有对使用过的恢复密码进行自动轮换的策略。不过它有前提条件，例如相应的加入状态、强制备份恢复信息的设置等。不要想着“是公司电脑，应该会自动更换”，而要确认实际生效的策略和新密钥是否已保存。¹³

另外，更换密钥并不是一项能把已经被复制的数据或过去获取的磁盘映像收回来的功能。如果怀疑恢复密钥已泄露，不要只更新密钥就结束处理，还要评估被访问到的范围。

7.2. 即使丢失的是已加密电脑，也不要断定泄露为零

发生丢失时，先从平时的管理记录确认保护当时是否生效。除此之外，还要查清设备当时处于断电、睡眠还是已登录状态，有没有处于暂停状态，以及恢复密钥有没有和电脑一起带在身上。BitLocker 是重要的措施，但仅凭“已加密”这一项，无法否定所有泄露的可能性。⁷

flowchart TB
        accTitle: 丢失时要确认的保护条件
        accDescr: 除了是否加密，还要确认保护状态、电源状态和密钥泄露的可能性，据此评估影响。
        A["电脑丢失"] --> B["查看保护状态的管理记录"]
        B --> C["确认电源状态和使用情况"]
        C --> D["确认恢复密钥泄露的可能性"]
        D --> E["按组织的安全事件处理流程评估影响"]

图12：是否加密是判断丢失影响的重要依据之一。

离职或归还电脑时，也要避免密钥只留在个人账户里的状态。归还后再分配时，把恢复信息的管理、必要数据的移交和重新装机当作一整套步骤来处理，即使负责人更换也更容易延续运维。

8. 加密方式和性能要在部署前确定并实测

8.1. 更改方式不是改一下配置就完事

在常规的软件加密中，如果不用策略更改，默认是 XTS-AES 128。不过，在受支持硬件与 Windows 的组合下还有硬件加速等情况，实现和默认值也存在例外。因此，不要认定“只要是 BitLocker，当前方式就一定是 128 位”，而要确认实际设备上的EncryptionMethod。方式和密钥长度要结合组织的要求和设备的性能来选择。¹³²⁰

已经加密的驱动器，其方式不会因为只改了策略就切换。更改需要先解密再重新加密，所以要把保护变弱的时间窗、备份和可停机时间一并纳入计划。在首次装机之前就定下来，比在运维过程中更改更容易处理。¹³

flowchart TB
        accTitle: 确定加密方式的时机
        accDescr: 新部署要先确定方式，已有设备要确认当前方式以及更改所需的解密工序。
        A["确认方式和密钥长度的要求"] --> B{"是否已经加密"}
        B -- "否" --> C["在部署前确定策略"]
        B -- "是" --> D["确认实际设备上的方式"]
        D --> E["必要时规划解密和重新加密"]

图13：更改策略和更改已有驱动器的加密方式，不是同一项工作。

判断性能时，要把“加密之后大概会变慢”的印象和实测分开。用与生产环境相当的数据量、存储和应用测量处理时间、读写量和 CPU 负载，并区分加密处理过程中的临时负载与完成后的持续影响。与其不说明设备条件就断言“影响为零”“一定慢百分之几”，不如确认是否满足要求，这样更贴合实务。²⁰

8.2. “仅已用空间”要注意过去删除的数据

对于新驱动器，用“仅加密已用空间”可以缩短首次处理的时间。而对于过去以明文保存过机密数据的驱动器，已删除文件所占的区域就成了问题。在文件系统上虽然是空闲空间，但数据痕迹可能仍然残留，而只加密已用空间时，这部分不在加密范围内。²

flowchart TB
        accTitle: 仅加密已用空间时的注意事项
        accDescr: 已删除的数据可能残留在空闲空间，只加密已用空间时它就落在保护范围之外。
        A["过去保存过明文的机密数据"] --> B["删除文件"]
        B --> C["痕迹残留在空闲空间的情况"]
        C --> D["仅已用空间时不在范围内"]
        D --> E["考虑全盘加密或适当的擦除"]

图14：删除了文件，与其内容已从介质上消失，是两回事。

不要只看首次处理的速度来选择，还要确认驱动器的使用历史。另外，全盘加密不等于报废时的擦除证明。报废或转让时，要像第 10 章那样另行制定擦除步骤。

9. 业务应用、无人值守设备和克隆部署中的注意事项

9.1. 应用的机密信息还需要另外的措施

通常情况下，在已解锁的 BitLocker 卷上，应用照常使用文件 API。正因如此，把连接字符串或 API 密钥放在明文文件里的问题，并不会因为启用了 BitLocker 就得到解决。对于运行中的应用，或以同一使用者权限就能读到的信息，需要按另一层边界来考虑。⁷

flowchart TB
        accTitle: 驱动器加密与应用的机密信息
        accDescr: 即使用 BitLocker 保护了存储介质，启动后应用处理的机密仍然需要设计保存方式和访问权限。
        A["用 BitLocker 保护介质"] --> B["Windows 启动后解锁驱动器"]
        B --> C["应用按权限读写"]
        C --> D["另行设计机密的保存方式和权限"]

图15：BitLocker 与应用侧的机密信息保护是互相配合，而不是互相替代。

使用 DPAPI 等机制时，也要考虑把保护绑定到哪个用户或哪台计算机。用了 DPAPI 并不表示拥有同一用户权限的攻击者一定读不到。具体例子见“Windows 应用的机密信息保存在哪里”。²¹

9.2. 能够无人值守重启和能够恢复是两回事

仅使用 TPM 的配置可以减少正常启动时的输入，但它并不能消除启动环境变化所引发的恢复要求。选择 TPM+PIN 后，正常启动时通常需要输入。对于无人值守运行的设备，要同时确认安全要求和现场是否有人能够输入。网络解锁等专用配置需要另行设计，并不是只要启用 PIN 就能继续无人值守运行。⁶²²

flowchart TB
        accTitle: 无人值守设备的正常启动与恢复准备
        accDescr: 即使能把常规重启自动化，出现恢复要求时的负责人和密钥取用步骤仍然需要另行准备。
        A["选择无人值守设备的启动方式"] --> B["确认常规重启是否可行"]
        B --> C["同时设想停在恢复界面的情况"]
        C --> D["准备现场负责人和取用步骤"]

图16：不只要测试无人值守重启，还要为停在恢复界面的情况准备运维方案。

把启动密钥放在 U 盘上时，也要同时做到需要时能用，以及不会和电脑一起被偷走。另外，不要因为 Windows IoT 不在 24H2 要求放宽的适用范围内，就认定它不会被加密。要把实际的状态确认纳入装机流程。关于整台设备的限制，可以参考“用信息亭模式固化业务终端”。⁸²

9.3. 不要做成反复使用同一恢复密钥的母映像

不要把已启用保护的母机状态直接复制到大量电脑上当作前提。BitLocker 也提供部署时预配这一机制，但它把使用明文密钥的准备阶段与每台设备各自启用保护分开了。既不是“加密过的映像就全都不行”，也不是“母机的恢复密钥可以全部设备共用”。²³

flowchart TB
        accTitle: 为每台设备建立保护的部署步骤
        accDescr: 映像部署后要为每台设备配置密钥保护器和恢复信息，并逐台确认保存位置和保护状态。
        A["按部署方式部署映像"] --> B["为每台设备配置密钥保护器"]
        B --> C["保存每台设备的恢复信息"]
        C --> D["确认 ID、能否取到和保护状态"]

图17：可以统一的是安装步骤，而不是所有电脑的恢复密钥。

即使采用“用 winget + PowerShell 自动化 PC 装机”这类自动化方案，最后也要保留一道工序：不只看加密的处理结果，还要确认每台设备的恢复信息和保护状态。

10. 报废时把加密和擦除当作两项不同的工作

BitLocker 有助于降低不当报废导致信息外流的风险。但是，不能仅凭“已加密”“已从 Microsoft 账户删除密钥”这些事实，就判断介质的擦除已经完成，因为其他解锁手段或密钥留底可能还在。⁶³

本文建议的顺序是：先保全必要的数据，再选择符合介质特性和组织标准的擦除或销毁方式，确认实施结果，最后整理资产台账和恢复密钥的记录。如果急着先删掉密钥记录，就可能导致还需要的数据无法访问。

flowchart TB
        accTitle: 报废已加密电脑的顺序
        accDescr: 先确保必要的数据，确认介质的擦除结果，再按组织的保存方针整理密钥和台账。
        A["保全必要的数据"] --> B["采用适合介质的擦除或销毁"]
        B --> C["确认实施结果和凭证"]
        C --> D["按保存方针整理密钥记录"]
        D --> E["更新资产台账"]

图18：整理恢复密钥记录要放在确认必要数据已保全、介质已处理之后。

AD DS 和 Entra ID 中的记录还涉及组织的保留和审计方针。不要把“当场删除所有旧密钥”定为一律的步骤，而要按管理员的流程整理。包含账户、许可证和资产管理在内的整体检查，汇总在“报废 Windows 电脑前应该做的事”一文中。

11. 总结——把“能取出恢复密钥”纳入运维

关于 BitLocker，最先要确认的不是“该不该关掉加密”，而是哪些内容被加密了、保护是否生效、哪一个恢复密钥由谁能够取出。

卡在恢复界面时，以密钥 ID 为线索查找保存位置。Windows 还能运行时，就完成状态确认和恢复密钥的取用确认。维护之前先确保恢复手段，只在必要时暂停保护，作业后确认到 On 为止。把这些嵌入电脑的部署、更新和归还流程，就能把“只有启用它的人才清楚的加密”变成负责人更换后依然可控的保护。

参考链接

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

BitLocker 的恢复密钥在哪里？

请依次查看个人 Microsoft 账户、工作或学校的管理位置、打印出来的纸质件，以及保存在 U 盘或其他位置的文件。仅凭当前的登录方式无法断定保存位置，密钥也可能在最初设置这台电脑的人的账户里。请以恢复界面上恢复密钥 ID 的前 8 个字符为线索，查找相符的密钥。如果是公司电脑而使用者本人无法查看，就向 IT 管理员咨询。

找不到恢复密钥时，是不是只能马上重置？

在重置之前，请先向组织的管理员、当初完成设置的人核实，并查看已保存的留底。组织也可能配置了其他恢复手段。如果所有有效的解锁手段都已丢失，Microsoft 支持部门也无法重新生成恢复密钥。请把“从数据备份中恢复”和“会丢失本地文件的重置、重新安装”分开来判断。

加密百分比达到 100% 就安全了吗？

仅凭加密百分比无法判断。在保护处于暂停期间，或自动加密正在等待启用时，即使已经加密，ProtectionStatus 也可能是 Off。请分别确认 VolumeStatus 和 ProtectionStatus，并确认恢复密钥确实能从管理位置取到。使用 Windows 期间 LockStatus 为 Unlocked 本身并不异常。

Windows 11 Home 也能使用 BitLocker 吗？

在受支持的电脑上，Home 也可以使用采用 BitLocker 技术的“设备加密”。另一方面，启用 BitLocker 驱动器加密以及进行详细管理，需要 Pro、Enterprise、Education 系列的版本。Windows 11 24H2 放宽了纳入自动加密范围的硬件条件，但这并不表示 24H2 的所有电脑都必然会自动受到保护。

更新 BIOS 之前需要禁用 BitLocker 吗？

通常不是执行会解密整个驱动器的“禁用”，而是根据机型和更新步骤考虑“暂停保护”。请先确认能够取到恢复密钥，并按电脑厂商的步骤操作。暂停期间驱动器虽然仍处于加密状态，但离线时的保护会变弱，因此作业结束后要恢复保护，并确认 ProtectionStatus 为 On。这并不意味着所有 Windows 更新都需要手动暂停。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。