Drive Encryption 7.x 的常见问题
上次修改时间: 2020-02-05 15:14:10 Etc/GMT
环境
摘要
注意:
- DE 以前称为 Endpoint Encryption for PC (EEPC) 和 Endpoint Encryption for Mac (EEMac)。
- 要查看 Endpoint Assistant (EA) 的常见问题,请参阅 KB80070。EA 是 iOS 和 Android 上随附的一款应用程序,为搭配 DE 使用而开发。由于大部分的 DE 服务台成本通常与用户密码重置管理相关,因此,可以使用 EA 彻底消除用户的预引导密码重置相关服务台成本。借助 EA,即使用户由于正在乘坐飞机而无法使用电话呼叫服务台,也可以安全地重置预引导密码。
常规 | 产品信息、许可和其他主题,包括选择加入和选择退出用户。 |
兼容性 | 与其他产品和软件之间的交互: |
DE 7.1.x 支持的新产品和功能: Microsoft Device Encryption、OS Refresh Process、Windows 8.1、Windows 10. |
|
DE 7.1.x 和 EEPC 7.0.x: Active Directory、BitLocker、混合驱动器 JAWS、Novell eDirectory、Opal 驱动器、Open LDAP、固态硬盘、Windows 2012 |
|
安装/ 升级 |
安装和升级 |
DE 7.1.x 支持的新产品和功能: EEPC、ePO、McAfee Agent、用户数据升级 |
|
DE 7.1.x 和 EEPC 7.0.x: RAW 图像、迁移、密码、Windows 8 |
|
配置 | 最常见做法、优化、自定义和备份,包括屏幕键盘。 |
功能 | 特性和功能 |
DE 7.2.0 支持的新产品: Intel Software Guard Extensions (SGX) DE 7.1.x 支持的新产品和功能: |
|
DE 7.1.x 和 EEPC 7.0.x: 自动引导、上下文相关安全、快速初始加密(仅限已使用的扇区)、混合引导、Intel Active Management Technology、脱机激活、脱机用户、加密密钥(脱机激活)、电源故障保护、预引导文件系统、预引导智能检查、反应式自动引导、重置密码、远程补救、报告、安全引导、故障排除、平板电脑、UEFI、Windows 8、唤醒和修补(远程解锁) |
|
Opal 驱动器 | 与 DE 和 Opal 驱动器相关的问题:一般、支持能力、DE 使用 Opal 的情况、技术 |
您可能会看到日志中提及选择加入/选择退出用户(例如 failing policy enforcement: assigned OptIn user)。选择加入用户已在 ePO 中将其“基于用户的策略 (UBP) 实施”设置为 True,表示适用特定的 UBP。选择退出用户已将其 UBP 实施设置为 False,表示适用分配给计算机的 UBP。
为何需要 DE?
DE 的主要用途是仅保护处于静止状态的磁盘上的敏感数据。 此类保护可能也需要遵循身份保护法。
如果由于启用自动引导功能而禁用了预引导身份验证,那么我可以受到哪种保护?
尽管 DE 的主要用途是保护处于静止状态的磁盘,但是一旦磁盘遭到解锁,DE 便不再提供数据访问保护。因此,为确保系统的安全,请不要使用自动引导功能。自动引导功能可有效地删除预引导身份验证,继而完全消除产品的安全性。自动引导功能仅可作为临时方法使用。有关自动引导的详细信息,请参阅自动引导。有关更安全的受信任平台模块 (TPM) 自动引导的详细信息,请参阅 TPM(自动引导)。
返回目录
DE 7.2.0 的新兼容性
是否支持用于原状升级的 Windows 10 周年更新新命令行参数 /ReflectDrivers?
支持。Microsoft 已在 Windows 10 周年更新中纳入了一个新功能,该功能让用户可以使用 /Reflectdrivers 选项通过 ISO 和 SCCM 进行 OS 原状升级。
此命令开关会指定已启用第三方加密的计算机的加密驱动程序所在文件夹的路径。将会安装 PnP 驱动程序,并且升级可以继续。
注意:DE 7.1.3 修补程序 1148978 或更高版本同样支持 /Reflectdrivers 选项,但是 DE 7.2.0 通过更改产品安装程序而进一步简化了这一进程。
有关在装有 Drive Encryption 的情况下进行 Windows 10 原状升级的详细信息,请参阅 KB87909。
DE 7.1.0 的新兼容性
哪个 DE 版本支持 Windows 10?
DE 7.1 补丁 3 (7.1.3) 是第一个支持 Windows 10 的 DE 版本,不过它是在 Windows 10 正式版本推出之前发布的。因此,在 Windows 10 系统上部署和使用 DE 7.1.3 时可能需要注意一些问题。有关详细信息,请参阅 KB85784。
注意:低于 DE 7.1.3 的 EEPC 版本和 DE 7.1.x 版本不支持 Windows 10。
DE 是否支持 Windows 10 Enterprise Long-Term Servicing Branch (LTSB)?
不支持。目前,DE 仅支持所有正式的 Windows 10 内部版本,包括 Current Branch (CB) 和 Current Branch for Business (CBB)。
注意:LTSB 这一 Microsoft 术语表示的是一个持续性的内部版本,该版本不会接收功能更新,通常仅接收安全补丁。
是否可以将操作系统 (OS) 从 Windows 7 或 8 刷新到 Windows 10?
在装有 DE 7.1.3 及更高版本的 OS 上可以。有关如何在装有 DE 7.1 补丁 3 的情况下将 OS 升级到 Windows 10 的信息,请参阅 KB84962。所述的过程会将所需的 DE 驱动程序插入到 Microsoft 升级过程中。
如果已安装 DE 7.1.3,是否可以对计算机应用 Windows 10 11 月更新/Threshold 2 (TH2)?
可以。由于这是一项重大更新,因此必须遵照 KB84962 中所述的过程。
在 DE 已安装且处于活动状态的情况下,是否支持 Windows 10 选项“恢复到先前的内部版本”?
支持。
DE 7.1 是第一个支持 Windows 8.1 的版本。
注意:低于 DE 7.1 的 EEPC 版本不支持 Windows 8.1。
DE 支持哪些操作系统?
请参阅 KB79422。
DE 7.1 是否提供任何专用于 Windows 8.x 的新功能?
是。DE 7.1 中插入了帮助强化系统以防范冷引导攻击的功能。此外,DE 7.1 还提供称为“TPM 自动引导”的新自动引导方法。
Drive Encryption 是否可以与新的 Dell Cylance 高级威胁保护技术配合使用?该技术可以报告是否检测到引导攻击。
不可以。DE 尚未经过与 Dell Cylance 高级威胁防护的兼容测试。
Drive Encryption 是否支持 Intel 防盗技术(可以基于硬件锁定计算机)?
不支持。Intel 已终止 Intel Anti-Theft Service。
是否可以运行 Microsoft 升级任务将 Windows 8.0 系统升级到 Windows 8.1?
不可以。Microsoft 目前使用的功能会放置一个新的 WIM 映像,这实际是一个操作系统刷新过程,而非传统的升级或 Service Pack 升级。但是,DE 制定了一个 OS 刷新过程,可让您从 Windows 8.0 升级到 Windows 8.1,并在整个过程中使所有现有数据保持加密。有关此过程的帮助,请参阅以下资源:
为何要使用在 Windows BitLocker 系统上并不会使用的 DE 7.1 OS 刷新过程?
Microsoft 实施的机制会在升级期间公开 BitLocker 加密密钥,以使 WIM 覆盖进程能够运行。McAfee 并不采用这种方法,因为这会使得系统在 Windows 升级过程中容易受到攻击。
Microsoft 提到了一种称为设备加密的新功能。这是什么?
Microsoft 设备加密可视为非托管的缩小版 BitLocker。
Microsoft 设备加密是否会自动启用?
是。如果硬件达到或超过最低硬件要求,则 Windows 8.1 会自动启用设备加密。
如果将 DE 部署到已自动启用 Microsoft 设备加密的系统,会发生什么情况?
如果您的系统符合 Microsoft 设备加密的最低硬件要求,设备加密已自动启用并且已加密磁盘,则会发生以下情况:
- 预激活检查会将 BitLocker 确定为活动状态。请记住,Microsoft 设备加密只是 BitLocker 的非托管版本。
- 由于已使用 Microsoft 设备加密对磁盘进行加密,因此 DE 激活将会失败。
- 该状态将会回报给 ePO。
如果我的新系统符合 Microsoft 设备加密的最低硬件要求但装有 Windows 7 和 DE 7.1,然后我又决定升级到 Windows 8.1,则会发生什么情况?
如果您尚未使用 MSDN 帐户登录,则系统不会尝试启用 Microsoft 设备加密。如果您已使用 MSDN 帐户登录,则它确实会破坏操作系统。
Mac 硬件是否支持装有 DE/EEPC 的 Windows 操作系统?
不支持。因为尚未在任何 Mac 硬件上进行 DE/EEPC 测试。
Drive Encryption 是否支持 Windows 压缩驱动器?
不支持,因为尚未进行任何兼容性测试。
返回目录
以前提供的适用于 DE 的 EEPC 兼容性常见问题
支持。数据始终处于安全状态,甚至是缓存的数据。Intel SRT 是一个智能缓存组件,它只缓存经常访问的数据。操作在扇区级别进行,并使用 DE 过滤器驱动程序进行加密。
EEPC/DE 是否支持 Intel 快速启动 (IRS)?
不支持。IRS 需要在固态硬盘 (SSD)/硬盘驱动器 (HDD) 上占用一个额外的分区空间,该分区称为“休眠分区”。其大小必须大于或等于系统内存量。此分区没有盘符。IRS 提供低功率 S3 状态,它不会将状态存储到 S3 中的 DRAM 内存中,而是将内容刷新到 SSD 上的专用分区。由于 BIOS 负责向/从 SSD 刷新内容,EEPC 无法截获和加密内容。因此,DRAM 中的所有敏感数据将以纯文本写入到磁盘(这只会影响 S3 状态而不影响 S4)。
需要。不过,DE 7.1 一项允许脱机激活的新功能可让您在不连接 ePO 的情况下激活 DE 7.1。当系统可以成功地与 ePO 通信时,客户端将进入“联机”模式。只有不受 ePO 管理的系统可以在不连接 Active Directory 的情况下保持加密状态。另请参阅脱机激活常见问题。
管理 DE 7.1 客户端是否需要 Active Directory?
需要。目前,ePO 4.6 仅包括对 Active Directory 的 LDAP 支持。
如果在 Active Directory 中更改了“组”或“用户”等对象名称,是否会从 ePO 数据库中删除已分配的用户?
不会。下一次运行“LdapSync:同步用户和组”任务时,会检测对象名称的更改,并在 ePO 中进行更新。在执行后续的 ASCI 期间,任何用户对象名称更改都将同步到客户端。
否。建议您禁用此功能。自动修复加密磁盘可能会不小心破坏加密的操作系统文件并导致永久性的引导问题。旧版 Windows 会在开始修复之前询问您是否要修复您的系统,但是 Windows 8 会在检测到问题时立即启动到自动修复,因此很难防止加密数据遭到破坏。有关禁用 Windows 8 自动修复的信息,请参阅文章 KB76649。
DE 7.1.x 是否会检测 Windows 8 BitLocker 并停止 DE 激活?
是。DE 会在 DE 激活过程中检测 Windows 8 BitLocker,如果 BitLocker 处于活动状态,便会停止激活 DE。
DE 7.1.x 是否支持混合驱动器?
如果已将混合驱动器如任何其他驱动器一样显示给操作系统 (OS),则支持。如果混合驱动器不是以标准驱动器的形式显示给 OS 的话,则 DE 可能无法支持混合驱动器,因为 DE 可能无法确定哪个是引导分区。
注意:混合驱动器采用盘片技术,该技术使用固态设备 (SSD) 缓存来加速操作。
EEPC 7.x/DE 7.1 是否支持 Windows Server 2012?
DE 7.1 补丁 1 (7.1.1) 中引入了对 Windows Server 2012 R2 的支持。
DE 7.1 补丁 3 (7.1.3) 中引入了对 Windows Server 2012(非 R2)的支持。
DE 7.1.x 是否支持 WinPE 4?
McAfee 已根据验证 WinPE 3 所使用的用例对 WinPE 4 进行了验证。
DE 是否支持固态硬盘?
支持,因为固态硬盘 (SSD) 能够完美地模拟物理驱动器。
如果 ePO 服务器关闭,端点会发生什么情况?
如果产品已安装并处于活动状态,则客户端将使用缓存的策略副本继续运行。在客户端能够与 ePO 服务器通信之前,将不会发生其他策略更新或用户分配。如果产品尚未安装,则只有在重新建立与 ePO 服务器的通信之后,才能激活产品。
是否支持 Novell eDirectory?
不支持。要提交产品增强请求以包含此功能,请参阅“相关信息”部分。
是否支持 Open LDAP?
不支持。有关详细信息,请参阅文章 KB73550。
DE 7.1.x 客户端是否与 Microsoft BitLocker 兼容?
不兼容。它与同一系统上运行的 BitLocker 或任何其他全盘加密或扇区级加密软件都不兼容。
DE 7.1.x 是否与 Microsoft 加密文件系统 (EFS) 兼容?
兼容。您可以将 DE 与 EFS 结合使用,因为它们作用的级别不同,不会产生交互。EFS 作用于文件加密级别,而 DE 作用于扇区级别。
是否计划针对预引导客户端提供 JAWS for Windows 屏幕阅读软件支持,以便为视力较差的用户提供帮助?
否。JAWS 是只能在 Windows 上运行的软件产品,在预引导身份验证时不可用,因为此时尚未加载 Windows。
哪个版本的 Drive Encryption 支持 Opal 驱动器?
DE 7.1.x 支持受信任的计算组 (TCG) Opal v1.0 规格。有关 DE 和 Opal 驱动器的详细信息,请参阅本文的 Opal 驱动器支持能力部分。
什么是 Opal eDrive?DE 7.1.x 是否支持它?
Opal eDrive 是 Opal 2.0 版驱动器,它在单用户模式下操作并通过 OS 进行管理。
DE 7.1.x 不支持 eDrive。
返回目录
- EEPC 7
装有 EEPC 7.0.x 的系统可以升级到 DE 7.1。但是,必须先将 EEPC 扩展升级到 EEPC 7.0 补丁 2 (7.0.2) 或补丁 3 (7.0.3)。
请遵循《Drive Encryption 7.1 Product Guide》(Drive Encryption 7.1 产品手册,PD24867)中所述的详细步骤。有关文档更正,请参阅 KB79912。- EEPC 6
如果您使用 EEPC 6.1.2 或更高版本,必须先将所有扩展升级到 EEPC 7.0 补丁 2 或补丁 3。运行 EEPC 6.1.2 或更高版本的客户端系统可直接升级到 DE 7.1。已签入 EEPC 7.0 补丁 2 或 3 扩展的 ePO 安装可直接升级到 DE 7.1。将 EEPC 6.1.x 或 6.2.x 客户端升级到 DE 7.1 之前,McAfee 强烈建议您查看 KB81522 以了解更多详细信息。
请遵循《Drive Encryption 7.1 Product Guide》(Drive Encryption 7.1 产品手册,PD24867)中所述的详细步骤。- EEPC 5
装有 EEPC 5.2.x 的系统可直接迁移到 DE 7.1。
请遵循《Drive Encryption 7.1 Migration Guide》(Drive Encryption 7.1 迁移手册,PD24870)中所述的详细步骤。有关文档更正,请参阅 KB79912。
哪些旧的 EEPC 版本可迁移到 DE 7.1?
可直接迁移到 DE 7.1 的旧版本包括 EEPC 5.2.6、5.2.12 和 5.2.13。
如果我运行 EEPC 6.x,需要做些什么?
如果您使用 EEPC 6.1.2 或更高版本,则必须先将所有扩展升级到 EEPC 7.0.2 或 7.0.3。启动 DE 7.1 升级过程之前,不需要升级 EEPC 6.1.2(或更高版本)客户端。
将 EEPC 6.1.x 或 6.2.x 客户端升级到 DE 7.1 之前,McAfee 强烈建议您查看 KB81522,以了解更多详细信息。
请务必遵照 Drive Encryption 7.1 产品手册 (PD24867) 中的详细说明,另外,还应查看相应的文档更正文章 KB79912,以了解对产品手册内容所做的更新和更正。此文章介绍了升级到 DE 7.1 所需执行的步骤,此过程还需要安装 EEAdmin 7.0.4 扩展。
如果我要升级到最新版本的 DE 7.1.x,但已安装早期的 DE 7.1 版本,应该执行哪些步骤?
如果您已安装早期版本(例如 DE 7.1.1),但想要升级到更高的 DE 7.1.x 版本,请执行以下步骤:
- 确保未运行任何 LDAP 同步任务。如果有任何同步任务正在运行,请等待它们完成运行。
- 在启动升级之前禁用所有 LDAP 同步任务。
- 安装 DE 7.1.3 扩展。
- 签入 DE 7.1.3 代理和 PC 软件包。
- 重新启用所有 LDAP 同步任务。
- 将 DE 7.1.3 软件包部署到客户端系统。
- 部署任务完成后,重新启动客户端系统。
升级过程为何如此复杂?
因为与新引入的 ePO 功能存在相互依赖关系,以便能够处理新的 LDAPSync 和 User Directory 功能。
DE 7.1.x 支持的最低 ePO 版本是什么?
ePO 4.6.7 和 ePO 5.1.0.
为何需要升级到较新的 ePO 版本才能运行 DE 7.1.x?
因为只能通过这种方法来利用 ePO 4.6.7 和 ePO 5.1.0 中首次实施的 LDAPSync 与 User Directory 新功能。
如果我不打算使用 User Directory,是否必须升级到 ePO 4.6.7 或 5.1.x?
是。不管您是否要使用此功能,都需要升级 ePO 版本。
使用这种新的 User Directory 结构是否意味着必须更新用户数据?
是。如果您有现有的用户数据,则必须运行用户数据升级过程,将所有现有的用户数据升级到新的内部结构。
在以下网页中可以找到有关 User Directory 的视频:https://communitym.trellix.com/videos/1700DE 7.1 发行包中为何会包含一个 EEPC 7.0.4 EEAdmin 扩展,为何需要此扩展?
由于 LDAPSync 和 User Directory 发生更改,因此必须将现有的整个加密相关用户数据迁移到新结构。EEPC 7.0.4 包含一个称为“用户数据升级”的任务,可将所有现有数据移动到新的结构。
这仅仅是一个 ePO 扩展,还是另外需要进行客户端升级?
这只是一个 ePO 扩展。EEPC 7.0.4 不需要客户端更新。此 EEPC 7.0.4 扩展是否能够向后兼容,以便可以管理运行早期 EEPC 客户端版本的客户端?
是的,您仍可以在安装 7.0.4 ePO 扩展的情况下,对所有现有的 EEPC 7.0.x 或 6.x 客户端(EEPC 6.1.2 或更高版本)进行管理和报告。但是,仅当“用户数据升级”任务出于某种原因失败,从而阻止完成升级到 ePO 4.6.7 或 5.1 时,才能持续采用这种做法。
此 EEPC 7.0.4 EEAdmin 扩展支持哪些 ePO 版本?
支持 ePO 版本 4.6.4 到 4.6.7 以及 ePO 5.0.1 到 5.1。但是,EEPC 7.0.4 EEAdmin 扩展的主要功能和任务只能在 ePO 4.6.7 和 ePO 5.1.x 上正常工作。应该使用 EEPC 7.0.4 扩展多长时间?
越短越好。只能在执行用户数据升级之前使用 EEPC 7.0.4 扩展。完成此任务后,应立即升级到 DE 7.1。
如果我尝试转到 DE 7.1 而没有事先签入 EEPC 7.0.4 EEAdmin 扩展,会发生什么情况?
首先,DE 7.1 扩展的安装将会失败,因为该扩展无法在您的 ePO 版本上运行。其次,您无法将 ePO 更新到最低版本,因为用于加密的现有 ePO 扩展不支持它。最后,您无法完成升级,因为升级过程会检测到您尚未成功运行用户数据升级任务。升级到 DE 7.1 时,必须执行 EEPC 7.0.4 EEAdmin 扩展的安装步骤。
什么是用户数据升级?
用户数据升级是一个服务器端过程,可将所有现有的加密用户信息迁移到新的 LDAPSync 和 User Directory 内部结构。
为何必须要运行此任务?
必须将现有的用户数据更新到 User Directory 和 LDAP Sync 扩展使用的新数据结构。这是一次性的过程,必须在升级到 DE 7.1 之前完成。
可以在哪个 ePO 版本上运行用户数据升级?
只能在 ePO 4.6.7 和 ePO v5.1.x 上运行此任务。尽管可以在早期的 ePO 版本上安装 EEPC 7.0.4 扩展,但只有在将 ePO 服务器升级到 ePO 4.6.7 或 ePO 5.1.x 之后,您才可以运行此任务。
是否只能使用已签入的 EEPC 7.0.4 EEAdmin 扩展运行用户数据升级,或者说,我是否可以在早期的 EEPC 版本上运行该任务?
不可以。只能在 7.0.4 EEAdmin 扩展中使用该功能,并且只能在 ePO 4.6.7 或 5.1 上运行该任务。
此任务是否只与 ePO 相关?我是否还需要在客户端上执行某种操作?
此任务只与 ePO 相关。该任务将运行相应的软件,该软件只会在 SQL Server 中的内部结构上移动数据。该软件会将数据移到新结构,然后在完成移动之前验证其准确性和完整性。
是否需要关闭 ePO 服务器才能运行此任务?
不需要,可以在活动的 ePO 服务器上运行此任务。
运行用户数据升级需要花费多长时间?
这取决于数据库中的用户信息量。大致时间:
- 如果有 2000 个用户,则大约需要 5 分钟。
- 如果有 10000 个用户,则大约需要 8 分钟。
注意:性能将会因 SQL Server 的规格及其当前工作负载而异。这些数字是在配备 i5 处理器和 4 GB RAM 的测试系统上计算得出的。可能会影响运行时间的其他事项:包含其他用户令牌数据片段,例如单点登录 (SSO) 数据和自行恢复数据。
如何知道用户升级出错?
ePO 服务器任务日志会针对运行的升级任务显示失败状态。此外,审核日志条目中也会显示同一任务的失败状态。无法还原 EEPC 7.0.4 EEAdmin 扩展,但可以使用安装的 EEPC 7.0.4 EEAdmin 扩展管理现有的 EEPC 客户端系统。
如果用户数据升级失败,是否可以重新运行该任务?
可以。如果该任务失败,它会自动回滚数据,并自动重新启用所有用户相关功能。可根据需要任意多次地运行该任务,直到成功完成。
运行用户数据升级任务时,是否可以执行任何用户相关的加密操作?
不可以。运行用户数据升级任务时,ePO 中会禁用所有用户相关的操作。
何时重新启用用户相关的操作?
仅当用户数据升级任务已成功完成,并且 ePO 扩展已升级到 DE 7.1 时,才会启用这些操作。如果该任务失败并回滚了数据操作,则也会启用用户相关的操作。
运行用户数据升级任务时,ePO 中是否还会禁用其他任何功能?
会发生以下情况:
- “添加本地域用户”不会处理任何新用户。
- 不会执行任何用户相关的操作(例如,处理新密码或其他相关的用户令牌信息)。
- 也会禁用用户相关的 WebAPI。
但是,以下功能仍然可用:
- 导出计算机密钥
- 质询/响应(仅限计算机)
- 任何非用户恢复功能(AMT 或非 AMT)
在执行用户数据升级任务期间,客户端上是否会出现任何变化?
客户端会发生以下情况:
- 客户端上收到的现有策略将继续实施。
- 运行用户数据升级任务时,新策略将传入客户端,但不会实施。
- 运行升级任务时,新捕获的密码或其他令牌数据无法发送到 ePO,并且无法传播到其他系统。
注意:如果是进行恢复,计算机恢复功能仍然可用(与自行恢复一样),但是,用于重置密码的质询/响应将不可用。
如果在此期间我在客户端或 ePO 中尝试上述操作之一,会发生什么情况?
所有这些客户端操作将会正常失败,或者在 ePO 用户界面中被禁用/阻止。
我正在设置一台新的 ePO 服务器,并且想要移动 DE 客户端。是否支持此操作?
支持。DE 7.1.3 支持此操作。
使用任何版本的 EEPC 或早期版本的 DE 时,在不同的 ePO 服务器之间转移系统都会将该系统上的用户分配和用户令牌数据替换为目标服务器中的数据,这可能会丢失用户分配,并更改预引导环境中的用户凭据。
Drive Encryption 7.1.3 引入了客户端转移功能,它为 ePO 管理员提供了一个机制,可在不同的 ePO 服务器之间转移系统,同时保留用户分配和用户数据。如果已启用该功能,则 DE 7.1.3 系统会检测服务器更改,并请求新的 DE 7.1.3 管理服务器自动在新管理服务器的上下文中将用户分配到系统。如果分配成功,系统会将其用户令牌数据发送到新的管理服务器。未成功完成系统转移过程的所有系统将在目标服务器上通过直观的现成报告突出显示。
该版本中单独随附了一份《DE 7.1.3 客户端系统转移手册》,其中详细介绍了这个系统转移过程。有关详细信息,请参阅 PD25905。
返回目录
以前提供的适用于 DE 的 EEPC 安装常见问题
在升级到 DE 7.1 期间,是否需要解密再重新加密客户端?
不需要。升级进程旨在将旧代理的密钥传输给新代理。这就是 McAfee 处理升级的一贯方式。(这与从 Endpoint Encryption 4 升级到 5 类似。)
是否可以在 ePO 服务器之间自动迁移 DE 用户和系统?
我们所支持且可保证提供完整功能的唯一方法是在新的服务器系统上还原 ePO 数据库的备份。目前不能进行自动迁移。
您可以提交密钥、用户和系统的服务器到服务器自动传输产品功能增强请求 (PER)。要提交 PER,请参阅下面的“相关信息”部分。
在安装过程中,可以使用哪些方法来避免所有用户使用相同的默认密码?
有两种方法:
- 通过 DE 策略,可以弃用默认密码。这会强制系统提示用户输入他们所选的密码。
- 使用包含其他基于用户的策略 (UBP) 的策略分配规则,并在该规则中为分配了该 UBP 的用户定义不同的默认密码。
不可以。要提交产品增强请求以包含此功能,请参阅“相关信息”部分。
是否需要为 Drive Encryption 添加 VirusScan Antivirus 排除项(就像使用早期版本的 EEPC 5.x 一样)?
不需要。DE 提供不同的功能。不再需要 Antivirus 排除项。
返回目录
仅适用于 DE 7.2.0 的新功能常见问题
DE 7.2.0 如何利用 Intel Software Guard Extensions (SGX)?
Intel SGX 是一个 Intel 体系结构扩展,在第 6 代 Intel Core 处理器平台中引入,旨在通过反向沙盒机制提高软件的安全性。采用此方法时,无需在平台上尝试识别和隔离所有潜在威胁或攻击面,而可以将合法软件密封在某个区域内部,并防止其遭受此类威胁,不管威胁的权限级别如何。在 Drive Encryption 中利用 Intel SGX 可以进一步提高对基于内存的攻击(例如冷引导攻击)的防御能力,且不影响支持 SGX 的系统的性能,以及所应用的适用策略。
如何在 DE 7.2.0 中启用 SGX?
为确保 DE 在适当的情况下使用 SGX,在将 DE 7.2.0 部署到目标系统之前,必须启用对 SGX 的支持。
有关此新功能的技术要求的详细信息,请参阅 KB87256。
仅适用于 DE 7.1 和更高版本的新功能常见问题
当 BIOS 配置为使用 RAID 时,计算机是否支持 DE?
一般而言,只要计算机的 BIOS 能够识别磁盘,DE 就可在 RAID 模式下工作。
注意:
- 在 Legacy/MBR BIOS 模式下,DE 依赖于 Int13 调用来访问计算机的硬盘 (HDD)。
- 在统一可扩展固件接口 (UEFI) 模式下,DE 依赖于系统输入/输出协议,因此 DE 对 BIOS SATA 模式不可知。与此相关的唯一注意事项是,如果磁盘是 OPAL 或自加密驱动器 (SED) HDD,则必须将 DE 设置为高级主机控制器接口 (AHCI) 模式,因为 DE 具有自己的控制器驱动程序,并不依赖于使用 BIOS 进行硬盘访问。
注意:该注意事项仅适用于 OPAL 或 SED 驱动器的硬件加密;如果为软件加密配置了 OPAL HDD,则不适用。
是否可以对通过 USB 端口连接的可移动媒体存储设备加密?
不可以。DE 将会检测驱动器,并且只会对通过 SATA 端口检测到的驱动器加密。
User Directory 是什么?
User Directory 可将 ePO 托管的 DE 扩展到包含非托管、非域用户的系统。除了 Active Directory 中托管的用户以外,DE 现在还能利用这些 ePO 托管的用户进行预引导身份验证。现在,将从 Active Directory 同步用户数据,并将其缓存在 ePO 本地。这样,就不需要持续在 ePO 与 Active Directory 之间往返访问,从而大幅提高基于用户的策略检查的性能。
使用此 User Directory 后,是否就不必再依赖于 Active Directory?
是。
身为管理员,我是否需要执行任何特殊操作才能启用 User Directory?
是。必须安装 User Directory 扩展。可以在升级到 DE 7.1.x 之前或之后执行此操作,前提是符合 ePO 先决条件(即已安装 ePO 4.6.7 或 ePO 5.1.0)。
是否只有 DE 才能使用 User Directory,其他 McAfee 产品能否使用它?
目前只有 DE 才能使用 User Directory,但其他 McAfee 单点产品将来也可以使用它。
在哪里可以找到有关 User Directory 的更多信息?
请观看社区中发布的视频:https://communitym.trellix.com/videos/1700EEPC 5.x 中的独立用户与 User Directory 中的用户在概念上是否有任何差别?
没有,它们在概念上是相同的。
是否可以将 EEPC 5.x 独立用户迁移到 User Directory?
可以。是否可以在 User Directory 中创建用户?
可以。
是否可以在 User Directory 中删除、禁用或编辑用户?
可以。
禁用用户后,是否可以重新启用他们?
可以。
是否可以向用户分配证书?
不可以。
为何要向用户分配证书?
例如,使用基于 PKI 的智能卡时,就需要分配证书。
是否可以在 User Directory 中创建组织单位 (OU)?
可以。
是否可以在 OU 中添加或删除用户?
可以。
一个用户是否可以属于多个 OU?
不可以。
是否可以将用户从一个 OU 移到另一个 OU?
可以。
OU 是否可以嵌套?
可以。
如果我选择了某个 OU,是否可以查看构成该 OU 的所有用户(包括嵌套的 OU)?
您可以查看子 OU 中的所有用户,但不一定能够查看所有嵌套的 OU。根据识别名,您可以查看每个用户来自哪个子 OU。
在 ePO 权限方面,是否可以指定或限制每个管理员可在 User Directory 中执行的操作?
在 ePO 中,权限分成数个权限集。用户将分配到每个权限集。只要将管理员分配到不同的权限集,他们就可以拥有不同的权限。
可以为 User Directory 指定哪种级别的 ePO 权限?
User Directory 支持读/写和只读权限。无法限制对特定操作的访问,但授予只读访问权限或吊销所有权限时除外。
在 DE 用法方面,是否可以在 EEPC 7.0 和 DE 7.1 中以相同的方式管理用户?
工作流完全相同。从工作流角度看,不存在任何差别。
在管理用户时,无论用户是来自 Active Directory 还是 User Directory,我是否都会看到整个用户列表?
是。
如果我针对某个用户执行加密相关的操作,该用户是来自 Active Directory 还是 User Directory 是否会有影响?
不会。两者的工作流完全相同。
是否可以将 User Directory 中的用户和/或 OU 分配到某台计算机以用于预引导身份验证?
可以。
如果在 User Directory 中禁用某个用户,会发生什么情况?
发生的情况与在 Active Directory 中禁用某个用户相同。
如果从 User Directory 中删除某个用户,会发生什么情况?
发生的情况与在 Active Directory 中删除某个用户相同。
在脚本编写方面,用于“用户:计算机分配”的 ePO WebAPI 是否有变化?
否。
是否可以针对 User Directory 中的操作编写脚本?
可以。
什么是受信任平台模块 (TPM) 自动引导?
TPM 自动引导是 DE 7.1 中的一项新功能,它使用 TPM(如果存在该硬件)增强传统的自动引导功能,以保护密钥。
TPM 自动引导与传统的自动引导有什么差别?
传统的自动引导不会为系统提供安全性。用于加密磁盘的密钥以纯文本形式写入磁盘。TPM 自动引导使用 TPM 加密磁盘,密钥不再采用纯文本格式,如此可保障密钥的安全。
TPM 如何帮助保障密钥的安全?
仅当系统状态未发生更改时,才能通过 TPM 解密密钥。如果 TPM 确信系统状态已发生变化,或者存在新的 TPM 芯片(例如,安装新的主板后),则不会解密密钥。如果 TPM 无法解密密钥,自动引导功能将会失败,并会显示预引导身份验证。
使用 TPM 自动引导时,系统是否会继续自动引导?
会,但前提是 TPM 确信一切正常。在这种情况下,用户不会看到预引导环境,系统会引导进入 Windows。
TPM 自动引导是否有最低要求?
是。最低要求如下:
- DE 7.1 仅支持 TPM 2.0 系统上的 TPM 自动引导(所有连接待机系统将支持 TPM 2.0)。注意:包含 TPM 1.2 的旧式系统不支持此功能。
- DE 7.1 Patch 1 (7.1.1) 增加了 TPM 1.2 芯片组支持(仅限 UEFI 系统)。
- TPM 所有者密钥必须在本地管理,不能在 Active Directory 中管理。
- 系统必须在 OEM 的 UEFI 实现中包含 TPM UEFI 协议(针对连接待机系统的要求)。
TPM 自动引导的策略设置是什么?
您可以在“自动引导的用户 TPM”标题下面找到以下三个策略选项:
- 从不 - 以纯文本格式将磁盘密钥写入磁盘。这是原始的自动引导功能。
- 如果可用 - 如果系统包含可用的 TPM,将使用 TPM 来加密密钥。如果未提供 TPM 或者 TPM 不可用,则系统上的 TPM 会根据原始自动引导功能将密钥以纯文本格式写入磁盘。
- 必需 - 仅当系统包含可用的 TPM 时,自动引导才会正常工作。DE 预引导环境将显示在不包含 TPM 的系统上。
是否可将 TPM 自动引导与反应式自动引导结合使用?
可以。
TPM 自动引导和反应式自动引导是否可与新的连接待机支持以及强化系统以防范冷引导攻击的功能结合使用?
可以。
如果 TPM 无法解密密钥,会发生什么情况?
将显示预引导环境,并要求用户进行身份验证。如果 TPM 不确信一切正常,它将不会自动引导系统,而是显示预引导环境,等待用户完成身份验证。
如果我更换了主板,或者引导度量值发生更改,则用户将看到预引导身份验证屏幕。那么,用户接下来要怎么做?
如果用户遇到这种情况,他们需要执行质询/响应恢复才能访问 Windows。
如果知道有效的预引导用户凭据,用户只需进行身份验证,然后即可引导进入 Windows。但是,由于用户已经处于这种自动引导模式,因此,他们获知有效用户凭据的可能性很小。
Windows 中的用户是否需要执行任何操作?
不需要。用户、支持人员或管理员不需要执行任何操作。产品将使用新信息自动重新加密密钥,此后,将会恢复正常的引导行为。
除了要求 TPM 加密密钥以外,你们还会执行其他操作吗?
会。我们还会度量引导路径。每当系统引导时,我们都会将一些相关的数据哈希处理到 TPM 中。这意味着,只有在引导路径未经修改时,TPM 才会解密密钥。也就是说,一旦 TPM 自动引导解锁了磁盘,就无法引导进入另一个引导路径。如果启动时选择了不同的引导选项,则自动引导功能将会失败,并显示预引导。
TPM 自动引导的工作原理是什么?
TPM 提供了一个密封机制,根据该机制,只有在系统处于预定义的状态时,才能解密已加密的数据。在系统启动期间,TPM 将度量固件和所有引导组件。度量过程包括扩展 TPM 寄存器中连同即将执行的代码一起存储的哈希。度量由固件执行,不能绕过。实际上,仅当系统处于与密封时完全相同的状态时,TPM 才允许解密密钥。任何更改(无论多么微小)都会导致该过程失败。
如果在 Windows 更新期间 Microsoft 更新了 Windows 引导加载程序,会发生什么情况?
这意味着引导度量值已发生更改。因此,TPM 无法解密密钥,您必须完成整个恢复过程(呼叫服务台)才能让系统再次成功引导。
由于 DE 预引导也在引导路径中,如果我更新 DE,会发生什么情况?
如果管理员部署了新版 DE(修补程序、补丁或新版本),而该版本更新了 DE 预引导 EFI 应用程序,则引导度量值也会发生更改。
类似于 Windows 更新方案,在 DE 推送更新后,用户是否必须呼叫服务台才能访问自己的系统?
是。
是否可以使用新的智能手机功能 (Endpoint Assistant) 来帮助解决此问题,而不用呼叫服务台?
不可以。Endpoint Assistant 只能用于密码重置情况。
现在是否可以在预引导环境中处理更多的用户?
预引导环境现已得到改善,支持 5000 个以上的用户,且在预引导身份验证期间不会造成可察觉到的性能降级。预引导环境中以前限制用户数最多 250 个。现在,您可以安全地将所有用户设置为共享桌面,使任何用户都能使用任何系统。
建议为预引导身份验证分配的用户数是多少?
一般建议保持不变。只应为预引导身份验证分配最少量的用户。
如果我允许 5000 个用户在计算机上预引导时登录,是否会有不利影响?
是。激活将会花费更长的时间,因为需要下载 5000 个用户的所有相关信息。同步用户信息将会花费更长的时间,这增加了 ePO 服务器上的工作负载。另外,其他操作(包括处理用户信息)需要更长时间才能处理完。在客户端上保存计算机信息就是这样的操作,因为这些信息也包括用户信息。
这是否会影响 ePO 服务器的扩展性?
是。您的 ePO 服务器将会在代理与服务器的通信间隔 (ASCI) 执行更多的工作,以确保所有信息都是最新的。
如果在 100 个系统上各分配 5000 个用户,会发生什么情况?
让我们以最常见的情况 - 密码更改为例。对于用户而言,这种更改将在一个系统上捕获,上传到 ePO,然后在另外 99 个系统与 ePO 同步时推送到这些系统。如果您强制用户每隔 90 天更改其密码,则会有 5000 个用户更新其密码。这意味着,ePO 服务器需要在系统与 ePO 同步的各个时间处理 50 万项更新(5000 个用户 x 100 个系统)。
是否会造成更大/额外的网络流量?
是。所有这些事务都是通过网络处理。尽管单个用户的数据较小(通常 < 20 KB),但处理量将与事务数相乘。如果某个系统的链接速度缓慢,可能需要花费相当长的时间来接收所有更改。如果服务器要处理许多客户端的用户更新,网络流量也可能会相当大。在 Vaguely Unpleasant 案例中,服务器可能无法在同步时间段内接收所有更新。
DE 如何强化系统,防御冷引导攻击?
从较高层面来概括这项新 DE 功能,就是在能够支持新的“连接待机”模式的新式 Windows 平台上,可为用户提供类似于 iPad 的体验。这些系统始终处于开机状态,要求加密密钥始终保存在 RAM 中,使得这些密钥容易受到内存擦除攻击(可能会从 RAM 中擦除加密密钥)。DE 可在后台运行,为最终用户提供原生的 Windows 体验。当设备进入“连接待机”状态时,DE 将从 RAM 中擦除加密密钥,并将其移到 Intel 硬件强化系统上的安全区域,防御冷引导和内存擦除攻击。当设备转为活动状态时,在用户成功通过 Windows 的身份验证后,加密密钥将以透明方式移回到 RAM。
什么是冷引导攻击?
冷引导攻击是指当系统处于开机或待机状态时,从系统内存中提取敏感数据(即使系统受 Windows 密码的保护)的一种方式。这种攻击涉及到硬性重新启动系统,并在下一引导周期运行一个小程序,用于在系统内存中扫描敏感信息,或者从已开机的系统中删除 RAM,然后转换到另一系统进行扫描。
DE 7.1.x 如何强化这些系统来防御冷引导攻击?
当系统进入某种待机模式时,DE 7.1.x 将从内存中删除密钥。该密钥存储在处于“连接待机”模式时仍可访问的安全位置。系统将继续根据最终用户的预期正常运行;但是,系统不太容易受到冷引导形式的攻击,因为密钥不再保存在内存中。
McAfee 是否保证完全从内存中删除该密钥?
此功能可强化系统,避免其受到内存形式的攻击。尽管 McAfee 已采取各种措施来确保从内存中删除密钥,但由于 Windows 的内存管理方式方面的原因,它无法保证完全删除密钥。将来的版本会进一步实施强化工作。
什么是 AOAC?
AOAC 表示 Always On,Always Connected(始终打开,始终连接)。Microsoft 称之为“连接待机”,而 Intel 称之为“智能连接”。这些术语基本上指的是相同的高级功能。它能够将系统保持在一种低功耗休眠模式,并定期唤醒系统来检索数据(电子邮件、Facebook 更新等等),然后让系统再次休眠,整个过程无需用户知晓或干预。此功能与手机的工作方式类似。
AOAC 如何更改全盘加密?
全盘加密一贯与静态数据的保护相关(系统已关闭)。许多公司正在引入 AOAC 功能,使得用户能够更自信地预期其系统始终包含新鲜内容。
当系统休眠时,是否并不意味着数据仍保持静态?
否。使用 AOAC 模型时,数据永远不会保持静态。系统并未关闭,只是处于待机模式而已。AOAC 模型要求磁盘保持“解锁”状态,原因是:
- 系统可能定期或通过推送通知唤醒。
- 在唤醒期间,应用程序和服务可能需要访问磁盘。
使用 AOAC 模型时是否有任何问题?
使用 AOAC 模型时,系统和服务需要能够访问磁盘。这意味着,磁盘的加密密钥始终保留在内存中。这会导致支持 AOAC 的系统更容易受到冷引导形式的攻击,因为密钥始终保存在内存中。请记住,系统并未关闭,而只是处于待机模式。
DE 7.1.x 是否支持 AOAC 模型?
支持。通过“连接待机”提供支持。当系统处于这种待机模式时,将使用 Windows 登录来防止数据遭到未经授权的访问。
如果我启用此功能,所有 AOAC 和连接待机功能是否仍可正常工作?
可以。
是否可将此功能与预引导和/或自动引导功能结合使用?
不管身份验证方法是什么,此功能都可正常工作。但是,McAfee 确实建议您使用以下功能之一:
- 预引导
- 如果已选择自动引导,则通过反应式自动引导或者与 Intel Active Management Technology 的集成来启用 TPM 自动引导。
如果使用此功能,密钥何时不会保留在内存中?
发生以下任何事件时,都可以从内存中删除密钥:
- 系统关机。
- 用户注销。
- 用户锁定工作站。
- 系统等待用户根据 Windows 登录提示进行身份验证。
- 系统从待机或休眠状态中唤醒。
另一种判断方法是,如果用户已完成身份验证并在桌面上操作,则密钥会保留在内存中。如果用户尚未完成身份验证或者不在桌面上操作,则密钥不会保留在内存中。
注意:管理员可以通过策略来选择应在哪种条件下删除密钥。
在哪种条件下会将密钥放回到内存中?
仅在用户已成功完成 Windows 的身份验证之后。仅仅是让 Windows 保持运行并不会将密钥放回到内存中。
如果密钥不在内存中,它会存储在何处?
密钥将保存在内存外部的某个安全存储区域中。
你们是否提供多个驱动程序来处理内存中的密钥?
不提供。但是,这种处理将以两种模式之一运行。这两种模式为:
- 标准加密
- 提升的安全加密
- 加密密钥存储在 RAM 中。
- 无法针对基于 RAM 的攻击或冷引导形式的攻击提供防护。
- 经过高度优化以提高性能。
- 使用与以前的 EEPC 7.x 版本相同的算法实现。
- 使用 AES256-CBC 加密算法的新实现。
- 加密密钥存储在安全位置,而不是存储在 RAM 中。
- 不容易受到基于 RAM 的攻击或冷引导形式的攻击。
- 在性能方面会带来明显的弊端。
- 处于此状态时,会禁用策略实施。
AES256 加密算法使用的密钥长度是多少?
使用的密钥长度为 128 位。
驱动程序何时在两种模式之间切换?
切换时间由策略定义。例如,当系统处于以下状态时,DE 7.1 可以切换到提升的安全加密模式:
- 已锁定
- 已注销
- 已进入待机模式
何时切换回标准加密模式?
当用户在 Windows 中成功完成身份验证时,标准加密模式将会恢复。
在提升的安全加密模式下,性能会有所下降,但由于用户并未频繁使用其系统,这种影响是否明显?
否。激活提升的安全加密模式时,来自连接待机系统的更新在访问磁盘时速度会变慢。但是,由于用户当时并未频繁使用其系统,因此,一般不会察觉到这种影响。
如果我要执行一个磁盘密集程度较高的任务,但同时锁定了工作站,后来又恢复了工作站,那么,该任务的运行速度是否会更慢?
是。由于您已锁定工作站,而系统将以提升的安全加密模式运行,此时密钥不在内存中,因此,在执行该任务时,性能将会下降。
这是否也意味着,在提升的安全加密模式下引导速度更慢?
是。初始引导之后,密钥便不会存储在内存中,直到用户在 Windows 中成功完成身份验证为止。如果您使用的是平板电脑,则完全关机的可能性极低,因此不是总会遇到这种问题。
在提升的安全加密模式下,安全性与性能之间是否各有利弊?
是。安全性将大大提高,但也确实会附带性能方面的弊端。要记住的要点是,如果用户频繁使用其系统,则会像平时一样体验到最佳性能。仅当身份验证尚未发生时,用户才会感受到性能方面的影响。
当驱动程序使用提升的安全加密模式时,我们会感受到哪种性能影响?
探讨原始算法的性能:支持 AES-NI 的 64 位处理器:
- 标准加密 = 1 个 CPU 时钟周期/字节
- 提升的安全加密 = 15 个 CPU 时钟周期/字节
不支持 AES-NI 的 32 位处理器:
- 标准加密 = 35 个 CPU 时钟周期/字节
- 提升的安全加密 = 133 个 CPU 时钟周期/字节
注意:由于测试是在禁用中断的情况下执行的,因此,实际影响可能大大超过上述原始算法。探讨另一种操作方式(仅作为示例):如果系统在标准加密模式下可以实现 208Mb/秒的吞吐量,在提升的安全加密模式下,吞吐量可能会降到 20Mb/秒。使用这种提升的安全加密模式功能是否需要满足任何硬件要求?
需要。KB79291 中提供了相关信息。
注意:系统需要支持连接待机,并且必须是 Clover Trail 平板电脑或 Haswell 系统。
是否可将此功能与 TPM 自动引导结合使用?
可以。
“连接待机”与“智能连接”之间是否有任何差别?
有。智能连接是一种早期的技术/设计,在某种意义上,它使用一个驱动程序来定期唤醒系统,并接入服务器来提取通知。连接待机是一项新技术:系统的 CPU 将进入新的电源状态。连接待机要求新硬件支持它,而智能连接则没有此要求。因此,您可以在配备旧式 CPU 和硬件的 Windows 7 系统上使用智能连接。从技术上讲,智能连接使用电源状态 S3,即“休眠”。连接待机使用电源状态 RTD3,这是另一种 CPU 状态。
什么是连接待机?
连接待机实际上并不是真正的休眠模式。它在这种新的电源状态下运行,并使某些可以从服务器接收通知的服务保持运行。因此,它附带了硬件要求,并且只能在 Windows 8.x 系统上使用。
连接待机有哪些硬件要求?
如果满足以下所有硬件要求,Windows 8 将会利用连接待机:
- 有一个固件标志指出支持标准加密模式。
- 引导卷不得使用旋转式磁盘。
- 所有网络设备支持 NDIS 6.30。
- 处于连接待机模式时可进行被动冷却。
注意:还有其他特定于安全的要求。例如,内存必须焊接在主板上,以防止出现冷引导攻击向量(涉及到从计算机中删除内存),并支持安全引导。
是否可将使用 DE 加密的磁盘重新分区?
不可以。无法更改已加密磁盘的分区。需要完全解密磁盘并卸载 DE,然后才能执行磁盘重新分区。
返回目录
以前提供的适用于 DE 的 EEPC 功能常见问题
不可以。 要迁移到较大的 HDD,必须先解密该 HDD,完成克隆,然后重新加密。
如果未向某个分区分配盘符,是否可以加密该分区?
不可以。
是否可以增加使用 DE 加密的硬盘分区的大小?
不可以。当驱动器已完全加密时,您无法增加分区磁盘空间。在磁盘已加密的情况下尝试修改主引导记录 (MBR) 会导致磁盘不可用。有关更多详细信息,请参阅 KB60647。
是否可以执行已加密系统的远程清除?
不可以。 预引导没有网络功能。
统一可扩展固件接口 (UEFI) 引导过程 GPT 磁盘分区 安全启动 混合引导 Windows 8 现代用户界面 (UI) Windows 8 平板电脑
是。Windows 8 将根据您系统的配置和功能,安装使用新 UEFI 引导进程或旧 BIOS 引导进程的引导功能。
否。由于分区机制的更改,您需要彻底重新安装 Windows 8。
在 Windows 8.x 和 DE 7.1.x 版本中,现在有两个 DE 预引导环境吗?
是的,DE 7.1.x 既有处理 UEFI 引导进程的预引导,又有处理 BIOS 引导进程的预引导。DE 智能客户端会检查系统配置使用的引导进程,并确定要安装的预引导。这样,管理员便能将 DE 部署到系统,而且知道系统会自动安装适当的预引导。
将 DE 部署到 Windows 8.x 和部署到先前版本的 Windows 有什么不同吗?
没有。不管使用哪个操作系统,部署 EEPC 的过程都是相同的。
DE 7.1 是否使用现代用户界面 (UI)?
否。加载 Windows 后,Windows 8 中只有 DE UI 是任务栏状态监视器,并且只能在桌面上使用。在现代 UI 中不可用。
自动引导是一个可以有效绕过 DE 提供的保护的帐户,用户将看不到预引导身份验证屏幕。
什么是反应式自动引导?
反应式自动引导对 Windows 和 OS X 上传统的自动引导功能做了增强。与在自动引导模式下一样,系统会对驱动器进行加密,但用户看不到预引导身份验证屏幕,直接引导到操作系统。
不过,与传统自动引导不同,反应式自动引导具有一项附加功能。启用此功能时,产品会监控 Windows 身份验证请求。如果最终用户的身份验证失败次数超过指定的最大值,反应式自动引导会自动启用预引导身份验证、禁用自动引导并立即重新启动计算机。出现这种情况后,用户必须成功通过预引导身份验证才能访问驱动器上的操作系统和数据。此功能允许系统根据管理员指定的特定条件,自动将身份验证策略从自动引导(未锁定、不安全)过渡到预引导(锁定、安全)。
如何启用反应式自动引导?
默认情况下未启用反应式自动引导。要启用反应式自动引导,管理员必须选择产品策略设置“<n> (1-10) 次登录或解锁失败后禁用并重新启动系统”(仅限 Windows Vista 及之后的版本),并且必须指定允许登录或解锁失败的次数。然后,必须将策略分配给需要使用反应式自动引导功能的系统。
举例说明适合使用反应式自动引导的情况。
在某些情况下,您可能要加密组织中任何用户都需要访问的共享系统。因此,您不能指定特定用户或用户组进行预引导身份验证。在这种情况下,您不得不部署使用自动引导,而反应式自动引导可以作为一种能接受的解决方案。
反应式自动引导只对客户端有影响吗?ePO 服务器上会发生什么情况?
此功能只是一项客户端功能。审核事件会在下一次同步时上传到 ePO,但是 ePO 服务器不会与此功能交互。
反应式自动引导仅适用于 Windows 吗?还是在 OS X 上也适用?
此功能只能在 Windows 上使用。Mac OS X 目前未提供反应式自动引导。由于 Apple 已发生更改,EEMac 产品已由 Management of Native Encryption (MNE) 取代。有关详细信息,请参阅 KB79375。
哪些 Windows 版本可以使用反应式自动引导?
此功能在 Windows Vista 及之后的版本上可用,在 Windows XP 上不可用。
是否会对配置了反应式自动引导的系统上的磁盘进行加密?
会,如果在加密策略中有所定义的话。但是,因为在启用自动引导时,不会启用身份验证,所以数据不受保护。
是否可以指定使用反应式自动引导时的最大失败尝试次数?
可以,ePO 管理员可以在策略中指定此值。最小值为 1,最大值为 10。
反应式自动引导是否适用于所有 Windows 身份验证尝试?
是的,它适用于 Windows 登录和解锁尝试。
使用反应式自动引导时,如果 Windows 用户是工作组或域用户是否有关系?
否。
反应式自动引导是否可用于软件加密和 Opal?
可以。
是否可以将反应式自动引导与临时自动引导配合使用?
不可以。反应式自动引导仅在始终启用自动引导的情况下可用。
启用反应式自动引导时最终用户会有什么感受?
当最终用户打开计算机时,他们会直接引导到 Windows。自动引导意味着不会进行预引导身份验证。用户将直接进行 Windows 登录。如果他们总是能成功通过 Windows 验证身份,则他们不会感受到什么不同。
使用反应式自动引导时,如果最终用户的 Windows 身份验证失败次数超出最大限制,会发生什么情况?
用户的身份验证失败次数超出指定限制后,会出现以下情况:
自动启用预引导身份验证,并且禁用自动引导。 Windows 非正常关机,然后重新启动。 计算机重新启动后,会出现预引导身份验证屏幕,用户必须成功通过身份验证才能访问 Windows。
使用反应式自动引导时,如果用户未能通过身份验证(超出最大身份验证失败次数),那么在系统重新启动之前,是否有时间保存工作?
否。系统会假设它受到攻击,并尽快锁定。
用户看到预引导身份验证屏幕时,必须执行哪些操作才能访问 Windows?
用户必须在预引导屏幕验证身份,或执行标准恢复机制之一,才能访问 Windows。
对于反应式自动引导,用户在超过定义的最大失败尝试次数之后,是否可以使用 Windows 凭据验证身份或使用自行恢复通过预引导并访问 Windows?
不可以,如果系统始终在自动引导模式下工作(这意味着可能未指定任何 DE 用户,因此无法成功通过预引导身份验证)。
可以,如果已指定 DE 用户帐户并且用户知道 DE 登录凭据。
用户的失败尝试次数超过定义的最大限制后,我是否可以使用质询/响应恢复来允许系统访问 Windows?
可以。在这种情况下,所有用户都可以选择使用质询/响应恢复。
如何重新启用反应式自动引导并禁用预引导身份验证以恢复到先前的工作流程?
用户必须在预引导时成功通过身份验证,或执行必要的恢复过程来访问 Windows。加载 Windows 且 DE 服务启动之后,系统会自动重新启用反应式自动引导。
在由于 Windows 身份验证失败而禁用了反应式自动引导的系统上,要重新启用反应式自动引导是否要执行管理员操作?
不需要。客户端重新启动系统并访问 Windows 之后,系统会自动重新启用反应式自动引导。系统不需要与 ePO 通信即可重新启用自动引导。
反应式自动引导事件是否需要审核?ePO 管理员是否可以查看哪些系统已在此功能的作用下启用预引导身份验证?
是。系统会将事件 30070:“自动引导已停用 – 超过了最大登录失败次数”发送至 ePO 服务器,但只有在下一次成功通过 Windows 身份验证之后并且可以连接至 ePO 时才会发送。
注意:如果系统认为自己受到攻击,便会禁用自动引导并重新启动系统。此时没有时间将事件发送至 ePO,因此在实施锁定时,ePO 并不知情。
是否可以将 Intel AMT 集成中的“位置感知”用例与反应式自动引导配合使用?
理论上虽然可以,但结合使用没有任何意义,原因有两个。首先,在启用反应式自动引导后,预引导过程中并不使用 AMT 功能,因为系统直接引导到 Windows。再者,从安全和可用性的角度看,最好使用 AMT 功能和“位置感知”用例让系统以安全且经授权的方式自动引导到 Windows。从目前来看,这样做比反应式自动引导更为安全。
由反应式自动引导功能启用预引导时,是否能够使用 AMT 来避免或减少最终用户致电服务台的情况?
此功能或许可以减少/避免为通过预引导环境而致电服务台的情况,但有时仍然需要致电服务台。更重要的是,AMT 功能可以保护数据安全,因为它要求服务器提供自动预引导身份验证。相比之下,自动引导不进行预引导身份验证,因此不能保护数据的安全。
无论是使用 AMT 集成还是反应式自动引导,用户都会直接进入 Windows 并允许进行身份验证 - 如果用户身份验证失败的次数太多而我希望系统重新启动到预引导环境,该怎么办?
虽然两种方法的最终用户体验是一样的,但它们的后端操作并不相同。反应式自动引导是一种不安全的解决方案,它使用客户端上已有的加密信息引导到 Windows。Intel AMT 集成则是一种安全的解决方案,它会与 ePO 联系并请求引导到 Windows 的权限,然后它会收到引导到 Windows 所需的必要加密信息。
在使用反应式自动引导的客户端系统上,不会在预引导中使用 AMT 功能。当用户多次进行身份验证均失败时,反应式自动引导会启用预引导并重新启动系统。 预引导会使用 AMT 并与 ePO 联系,然后获得引导权限。如果 ePO 不响应或返回否定响应,用户遇到的情况将和不使用 AMT 的传统反应式自动引导相同。 用户会返回到 Windows 登录屏幕,而反应式自动引导会启用,因为系统已引导到 Windows。用户可以继续输入不正确的密码,直到被 Windows 禁用为止。 在这种情况下,用户可能不得不致电服务台寻求帮助。反应式自动引导是客户端活动,并且此功能在响应失败的登录尝试时,不会也没有时间与 ePO 服务器通信。
什么是快速初始加密(仅限已使用的扇区)?
快速初始加密能够在几分钟内(正常情况下需要数小时),在系统上安装 DE 产品并执行加密。
快速初始加密的工作原理是什么?
快速初始加密去除了电源故障保护(该功能可在电源故障或突然停机的情况下防止数据丢失),并在硬件的支持下迅速执行初始加密。它只加密当前正在使用的扇区。
相较于 DE 7.1 及更低版本,快速初始加密的工作方式有何不同?
以往,本产品会假设加密的是当前正在使用的系统。它优先考虑最终用户体验,尽量降低对最终用户日常工作的影响。这种做法的优点是允许用户在加密时继续工作,并可在电源故障或突然停机时防止数据丢失。在这种标准部署下,完成加密过程所需的时间较长,因为本产品会对加密策略中指定的卷或分区的每个扇区进行加密。甚至还会加密不包含数据的空白扇区。
使用快速初始加密时,该功能如何仅加密已使用的扇区?
本产品会查询操作系统,以了解文件系统正在使用的扇区。然后,仅加密在加密策略内指定的卷或分区中标记为使用中的那些扇区。对于新安装的系统,这通常只占磁盘总大小的很小一部分。
将新数据写入磁盘时会发生什么情况?
新扇区变成已使用扇区时,便会对它们进行加密。
什么情况下要使用快速初始加密?
初始加密新安装/新建立映像的系统时,便可以使用此功能。该系统放置在 IT 技术人员那里,最终用户不会使用。您可以参考脱机激活常见问题中的“内部设置”和“第三方设置”用例。
不是。它只在装有 DE 7.1 的 Windows 上可用。由于 Apple 已发生更改,EEMac 产品已由 MNE 取代。
哪里可以启用快速初始加密?
快速初始加密功能只能在脱机激活过程中使用。另请参阅脱机激活常见问题。
在正常激活过程中是否可以使用快速初始加密?
不可以。
不会。您必须显式启用快速初始加密。
做为脱机激活包的一部分,我如何启用快速初始加密?
在脱机激活包中添加了以下两个选项:
-
SkipUnused(默认值已禁用)
-
DisablePF(默认值已禁用)
将不会生成脱机激活包,并且进程会失败。您将需要重新生成该包并正确键入“是”,或者从包中删除“仅限已使用的扇区”选项。
当启用快速初始加密时,在使用“仅限已使用的扇区”的情况下,为何需要键入“是”?
这可确保您已阅读免责声明并了解此功能的用法。请务必仔细阅读有关仅限已使用的扇区的注意事项。
不可以。无需将快速初始加密与 Opal 驱动器搭配使用,因为该驱动器在技术上已实现时刻加密。DE 激活进程会为驱动器启用锁定机制。目前,Opal 驱动器会从“非活动”进入“活动”并在几分钟内得以完全加密。另请参阅脱机激活常见问题。
是否可以将快速初始加密与普通硬盘驱动器 (HDD) 或固态硬盘 (SSD) 搭配使用?
可以,但是请务必仔细阅读有关仅限已使用的扇区的注意事项。
由于 SSD 的工作方式,对 SSD 的影响更大。有关针对某些 SSD 报告的性能问题的更多信息,请参阅 KB66256。
加密硬盘时是否可以重新启动计算机?
要考虑两种情况:
- 使用快速初始加密并且已启用 DisablePF 功能时,不能重新启动计算机。在这种情况下重新启动系统会导致数据丢失。
- 使用全盘加密 (FDE) 时可以重新启动。 如果使用 FDE,在重新启动计算机后,加密将会继续。但请注意,如果在完成磁盘加密过程之前计算机已关闭,则您的数据可能不会完全在静态状态下受到保护。
当使用仅限已使用的扇区选项时,是否意味着磁盘上有些扇区未加密?
是。使用此选项,产品仅会加密操作系统状态为使用中的扇区。所有其他扇区(空白区域)在被使用之前都会保留为未加密状态,即使这些扇区包含先前已删除的敏感数据也不例外。任何在正常操作过程中写入的新扇区都将以已加密状态写入。
此功能可以在将任何敏感的公司数据写入磁盘之前使用。
对于在拥有先前包含的敏感公司数据的 HDD 或 SSD 上使用“仅限已使用的扇区”选项,McAfee 有何建议?
请不要在先前包含敏感的公司数据的磁盘上使用此功能。加密整个卷/分区/磁盘。
DE 支持的最大 HDD 大小是多少?
BIOS 或 UEFI 支持的任何硬盘都受 DE 的支持。在技术上,BIOS 限制为 2.2TB,而 UEFI 限制为 9.4ZB。
有关 UEFI 限制的更多详细信息,请参阅 http://www.uefi.org/sites/default/files/resources/UEFI_Drive_Partition_Limits_Fact_Sheet.pdf
当回收已使用 DE 完全加密的较旧驱动器时,McAfee 对于使用“仅限已使用的扇区”选项有何建议?
假设先前已加密包含敏感数据的所有卷,则仍然可以使用此功能。如果不满足该条件,则 McAfee 会建议您不要使用此功能。
当回收已使用其他加密产品加密的较旧驱动器时,对于使用“仅限已使用的扇区”选项,McAfee 有何建议?
McAfee 不能保证第三方产品的安全,因此,建议不要使用此功能。
McAfee 是否可以提供可表明使用快速初始加密(仅限已使用的扇区)时得到改进的数据?
可以,请参阅 KB77844。
在启用“电源故障保护”的情况下,是否仍然可以执行正常或脱机激活,并且是否仍然可以加密所有扇区,而不仅仅是使用中的扇区?
可以。您必须显式启用快速初始加密才能使用它。如果未启用它,将会使用正常的激活和初始加密流程。
是否可以禁用“电源故障保护”选项但允许“仅限已使用的扇区”加密功能?
可以。可以选择这两个选项的任意组合。但是,由于在回收驱动器(脏磁盘)上使用“仅限已使用的扇区”加密存在潜在的安全问题,所以可以禁用此选项。请务必仔细阅读有关仅限已使用的扇区的注意事项。
什么是 UEFI?
UEFI(Unified Extensible Firmware Interface)定义个人计算机的新一代固件接口。最初在程序集中编写并使用软件中断进行 I/O 的基本输入输出系统 (BIOS) 固件,从一开始就已定义了 PC 生态系统,但是计算领域的变化已经为现代固件定义铺平了道路,从而迎来全新一代的平板和设备。
UEFI 的一些要点:
UEFI 通过 UEFI 论坛进行管理,该论坛是一个芯片集、硬件、系统、固件和操作系统供应商的集合。论坛维护着在许多 UEFI 计算机中使用的规格、测试工具和参考实现。 UEFI 的目的是定义引导过程中操作系统与平台固件通信的标准方式。在 UEFI 之前,引导过程中与硬件通信的主要机制是软件中断。现代 PC 能够以更快的速度执行、更有效地阻止硬件与软件之间的 I/O,并且 UEFI 允许设计利用其硬件的全部潜能。 UEFI 允许进行模块化固件设计,使硬件和系统设计人员在设计固件时具有更大的灵活性,从而满足要求更高的现代计算环境要求。虽然 I/O 受软件中断限制,但是 UEFI 提升了基于事件、与体系结构无关的编码标准的概念。
是否所有供应商的 UEFI 实现完全一样?
否。UEFI 实现会因硬件供应商而有所不同。根据 UEFI 实现的不同,我们发现许多问题,范围从缺少支持 Opal 驱动器所需的协议到以本机 UEFI 模式操作时在 DE 使用的预引导环境中提供的 USB 支持问题。
EEPC 支持哪个版本的 UEFI?
DE 7.1 支持 UEFI 版本 2.3.1 及更高版本。
哪些 Windows 版本支持 UEFI 启动进程?
Windows 7(64 位)和 Windows 8(32 位和 64 位)系统支持 UEFI 引导进程。
具有 UEFI 引导进程的系统是否适用于 MBR 分区磁盘?
不适用。Windows 需要新的磁盘分区机制(称为 GPT)才能在 UEFI 下引导。
DE 预引导是一个应用程序吗?
是。如果您将 UEFI 视为操作系统,DE 预引导就像是一个 UEFI 本机应用程序。相比之下,BIOS 预引导版本是操作系统本身。在这两种预引导中,DE 预引导需要首先运行,以便在成功进行身份验证之后,可以加载加密密钥,并且引导进程可以继续进行。在 UEFI 世界中,当用户在 DE 预引导期间成功验证身份后,EEPC 预引导应用程序即会终止,并允许链中的下一个应用程序运行(传统上是操作系统启动加载程序)。
最终用户是否可以知道他们使用是的基于 BIOS 的预引导还是 UEFI 预引导?
不能。这两个预引导环境的外观和行为方式完全一样。最终用户不能区分 UEFI 和 BIOS 预引导环境。
在 UEFI 中,是否所有相同的令牌和识别器均受支持?
是。所有支持的令牌和识别器在 BIOS 和 UEFI 中都应有效,但具有以下例外:
所有生物识别令牌 SafeNet 的 eToken USB 令牌要查看 Drive Encryption 7.1.x 中的身份验证所支持的令牌,请参阅 KB79787。
要查看 Drive Encryption 7.1.x 中的身份验证所支持的读取器,请参阅 KB79788。
是否所有触摸屏幕设备均在 UEFI 中受支持?
如果您将 UEFI 看成更像是一个操作系统的话,则 OEM 将需要提供该设备中所包含硬件的软件驱动程序。对于 UEFI,预引导将支持 Simple Pointer Protocol 和 Absolute Pointer Protocol。预期会对遇到的所有触摸屏设备实施这两种协议或其中一种协议。如果 UEFI 实现的制造商/OEM 无法实施任何一种机制,则触摸屏设备支持将得不到保证。
注意:McAfee 在自己的内部测试中发现,并非来自 OEM 的所有 UEFI 实现实际上都实施了这些接口。在这种情况下,该系统上 UEFI 实现的创建者会遗漏 UEFI 规格的部分。
Opal 驱动器在 UEFI 中是否受支持?
UEFI 系统上的 Opal 自加密驱动器支持仅在制造时安装了 Opal 自加密驱动器的兼容 Windows 8 徽标系统上可用。如果改装 Opal 驱动器到 Windows 8 之前的系统,或到制造商未随附 Opal 驱动器的 Windows 8 系统,则将不会在 UEFI 下提供 Opal 自加密驱动器支持。这是因为仅当出厂时配备了自加密驱动器,Opal 管理所需的 UEFI 安全协议才是必需的。如果没有安全协议,则无法实现 Opal 管理。
对于具有 UEFI 引导进程的系统是否有不同的恢复工具?
是。因为它是不同的引导进程,所以需要不同的恢复工具来处理引导进程。
这是否意味着 DETech 也是一款 UEFI 应用程序?
是。这是一款用于在配备 UEFI 引导进程的系统上进行恢复的 DETech 应用程序。
注意:您不能将(旧版)BIOS DETech 工具与 UEFI 引导系统搭配使用。
GPT 驱动器均会配备 UEFI。它们是否也受支持?
是。DE 7.1 中的 UEFI 预引导将支持 GPT 驱动器。它们将以引导或辅助磁盘形式受到支持。
BIOS 预引导是否还支持 GUID 分区表 (GPT) 驱动器?
Windows 7
作为引导磁盘的话,不支持。作为辅助磁盘的话,支持。此外,操作系统决定是否支持 GPT 模式下的辅助驱动器,并且有关 BIOS 是否支持大容量磁盘以便 DETech(独立)能够恢复它们也取决于操作系统。
Windows 8 及更高版本
在具有 DE 7.1.0 及更新版本的 Windows 8 上,支持主要和辅助 GUID 分区表 (GPT) 磁盘。
注意:
- 基于 UEFI 的系统只能从主 GPT 磁盘引导。
- 基于 BIOS 的系统无法从主 GPT 磁盘引导。在具有 EEPC 7.0 及更新版本的系统上,仅支持将 GPT 磁盘用作辅助驱动器。
当 DETech 独立版本包含更多的功能(例如,可以执行紧急引导)时,为何我应该创建并使用 DETech WinPE 恢复媒体?
WinPE 版本比独立版本快的多。WinPE 版本还可让您访问加密的硬盘,修复 windows 问题,或在重映像前将用户数据复制到另一个驱动器。您还可以运行任何 Windows 工具并访问网络。
注意: DETech 独立版本无法向后兼容。这意味着,您始终应该使用匹配的 DETech 恢复媒体版本。如果客户端上安装了 DE 7.1,请创建一个 DETech 7.1 独立版本恢复媒体来执行所有恢复操作。
McAfee 为何无法为客户提供 WinPE 恢复 CD?
这需要有效的 Microsoft 许可证。
什么是安全启动?
安全启动是 UEFI 启用的一项功能,但 Microsoft 规定了 x86 (Intel) PC 的具体实现。任何带有 Windows 8 徽标不干胶标签的系统均已启用安全启动。
UEFI 有一个固件验证进程,名为“安全启动”,这已在 UEFI 2.3.1 规格的第 27 章中定义。“安全启动”定义了平台固件如何管理安全证书、固件的验证以及固件与操作系统之间接口(协议)的定义。它会创建在 UEFI 中启动的信任根,这会在加载并执行此信任根前验证该链中的下一个模块,从而确保信任根自经过数字签名以来未发生更改。借助“安全启动”体系结构及其信任链的建立,通过确保在加载操作系统自身之前,只能运行经过签名、已认证为“已知正确”的代码以及启动加载程序,保护客户免于在引导进程中执行恶意代码。
DE 7.1.x 是否支持安全引导?
支持。
这是否意味着 DE 已经签名,所以安全启动进程信任它?
是。
安全启动是否适用于 Windows 8 基于 BIOS 的系统?
不适用,它只适用于基于 UEFI 的系统。
什么是混合启动?
在之前的 Windows 版本中,传统的关机会关闭所有的用户会话、服务与设备以及内核,从而为完全关机做准备。Windows 8 会关闭用户会话,但不会未关闭内核会话,而是让它进入了休眠状态。结果是加快关机与启动速度。
DE 7.1.x 是否支持混合启动?
支持。但早期版本的 EEPC 不支持混合启动。
单点登录 (SSO) 是否可用于混合启动?
可以,与以前的 EEPC 版本不同,DE 支持从休眠恢复时进行 SSO。
从以往经验来看,EEPC 从休眠恢复需要一些时间。使用 DE 7.1.x 时仍然会减慢混合启动速度吗?
DE 7.1 包含各方面性能的增强。这些增强结合支持 AES-NI 的处理器使用时可获得优异体验。内部测试中,DE 已使用混合启动体验了可比较的加密/不加密的启动时间。
采用 Intel 处理器的平板 采用 ARM 处理器的平板
Windows RT(正式称为“Windows on ARM”)是适用于 ARM 设备的一个 Windows 8 版本。只有针对 Windows 8 Modern UI 接口编写的软件会在 Windows RT 上运行,但 Microsoft Office 2013 RT 及 Internet Explorer 10 除外。任何使用 Win32 API(绝大多数的当前应用程序)编写的应用程序都将不会在 Windows RT 上运行。
DE 7.1.x 是否支持使用 ARM 处理器及 Windows RT 的 Windows 8 平板?
不支持。
DE 7.1.x 是否支持使用 Intel 处理器的 Windows 8 平板?
支持,EEPC 7.0 会将它们视为任何其他 Windows 系统。但是,客户应该检查以下注意事项:
CPU 功能 触摸屏支持
McAfee 已注意到,制造商预告的部分 Windows 8 平板设备包含低功率处理器,其中部分不具有 AES-NI 功能。客户应该了解 CPU 的功能,以确保最终用户在系统加密后将获得最佳体验。
平板对触摸屏支持情况怎么样?
这全都关乎预引导时的最终用户身份验证。部分 Windows 8 平板配有键盘,所以不存在此问题。对于没有键盘的设备而言,它们需要最终用户在预引导中使用触摸接口进行身份验证。请仔细阅读涵盖了问题“UEFI 是否支持触摸屏设备?”的此功能部分上的注释。
基于 Intel 的平板系统可运行哪个版本的 Windows 8?
从技术上讲,他们可以运行能够在基于 Intel 的处理器上运行的任何 Windows 8 版本。具体的版本,制造商会在创建/交付系统时进行选择。
内部设置 第三方设置 从不连接到 ePO 的远程系统
什么是脱机激活的内部设置用例?
您可能有自己的内部设置流程,该流程规定系统需要安装操作系统以及经所有公司批准的应用程序,并且系统在交付给最终用户之前必须经过完全加密。在设置点,您可能没有网络连接,因为设备可能位于单独房间的机架上。
什么是脱机激活的第三方用例设置?
您可能需要外部第三方来设置您的设备。在此情况下,您不想打开防火墙以允许连接到 ePO,但您有一个要求,即交付前所有笔记本电脑必需经过加密。
什么是从不连接到 ePO 的远程系统的脱机激活用例?
您可能有一个在远程位置使用的客户端,该客户端无网络连接,但可能正在收集敏感数据并且需要加密。您可以分发带有所需的 MSI 的 CD 以安装 McAfee Agent、DE 以及脱机激活包。然后可以运行它们以安装并激活 EEPC 以及加密该系统。
什么是脱机激活的高级进程?
管理员会在 ePO 服务器上创建一个脱机包。该包将包含需要创建的第一个策略以及“脱机用户”列表。 一旦创建了此包建,便可以将它分配到必要的客户端以及安装 EEPC 所需的 MSI 中。EEPC 安装成功后,脱机包将予以运行,并且策略也会予以应用及实施。 您现可在预引导中使用“脱机用户”进行登录。
是。这是因为您无需在 ePO 中看到它们,也无法在 ePO 中管理它们。
这是否意味着脱机激活的系统中有一个独立、非托管的 DE 版本?
否。脱机激活可能会允许您创建一个根据特定策略加密的独立系统。但是,完成第一个策略实施后,您就无法更新该策略或用户。没有可更新策略或用户信息的本地控制台及方法。但是密钥恢复机制是受支持的。有关详细信息,请参阅下面的脱机用户恢复常见问题。
如果 ePO 未部署产品,则如何安装该产品?
对于脱机激活,一个重要的事实是,DE 可以在系统中安装。您使用的安装方法(例如,向最终用户提供包含用户可以运行的 MSI 的 CD/DVD,或更加自动化的方法)取决于您的特定环境。
脱机激活需要在客户端上安装哪些项目?
需要安装下列项目:
McAfee Agent McAfee Endpoint Encryption Agent DE 管理员创建的脱机包
以后您是否可以将通过脱机激活激活的系统连接到 ePO?
可以。以后您都可以将通过脱机激活激活的系统连接到 ePO 上进行管理。
脱机激活的系统连接到 ePO 后会怎样?
假设出于设置目的完成了脱机激活,则系统将在某一时刻连接到 ePO。当系统可以成功地与 ePO 通信时,客户端将进入“联机”模式。联机模式定义为 McAfee Agent 与 ePO 之间的正常连接;与正常安装无异。
此外:
它会丢弃已实施的脱机策略,还会丢弃所有脱机用户。它将接收 ePO 中的实际策略、按照正常激活列出的已分配用户的列表,并且将在 ePO 中保存其加密密钥。您可以将其视作第二次但自动进行的激活。 重要说明:切记,如果连接前 ePO 服务器不知道用户的存在,则所有脱机信息都将被丢弃。如果 ePO 服务器知道脱机用户,则将部署 ePO 策略,但不会丢弃脱机模式下存储的任何数据。
否。由于该系统从未与 ePO 通信,所以没有该系统相关的任何信息。
如果设备仅通过脱机激活予以激活,您能证明该设备有无加密吗?
如果系统从未与 ePO 通信,则发生遗失或失窃时,ePO 中将没有可用于审核的信息。一旦系统与 ePO 通信并进入联机模式,则所有常规信息都将显示在 ePO 中以证明系统处于加密状态。
什么是脱机用户?
脱机用户是指仅在特定脱机包中存在的、用于预引导身份验证的用户。
脱机用户与 DE 中的普通用户有哪些不同之处?
脱机用户仅存在于特定的脱机包中。这些用户不会在 Active Directory 中存在,并且基本上不会在此脱机包以外的任何地方存在。
“添加本地域用户 (ALDU)”是否可用于脱机激活?
不能。ALDU 只有两个步骤,需要 ePO 执行用户/系统分配。由于脱机激活对 ePO 不适用,所以无法完成也无法使用 ALDU。
激活已完成并且系统未联机已有一段时间后,我可以将更多的脱机用户添加到脱机激活的系统中吗?
不可以。
是否可以为我的脱机用户使用密码外的令牌?
支持自行初始化的密码及智能卡可以在脱机激活中使用。只有 PKI 的智能卡不可用,因为没有后端可检索验证用户身份所需的必要信息。无法支持生物识别。DE 支持令牌文章 KB79787 已经确认了自行初始化令牌。
对于脱机用户,他们还要以默认密码启动吗?
是。
如果脱机用户忘记了密码,我是否可以恢复密码?
最终用户可以使用本地恢复功能来恢复密码。
如果管理员禁用了“本地恢复”,脱机用户会出现什么情况?
用户现已被锁定。如果系统中有其他用户可以使用,则或许能够引导系统。或者,将系统连接到 ePO。但是,这需要能够引导到 Windows 中。
如果脱机最终用户已经忘记其密码和本地恢复答案,那该怎么办?
用户现已被锁定。如果系统中有其他用户,则或许能够引导系统。或者,将系统连接到 ePO。但是,这需要能够引导到 Windows 中。
当脱机系统附加到 ePO 中时,这些脱机用户会发生什么情况?
当由脱机激活成功启用的系统与生成 McAfee Agent、DE 及脱机激活包的 ePO 服务器通信时,它会丢弃所有脱机用户并要求 ePO 提供分配的用户。
如果您有一名名为 Bob 的脱机用户和一名名为 Bob 的 AD 用户,当他由脱机状态变为联机状态时,Bob 的密码会发生什么情况?
假设 AD 用户 Bob 至少已登录该系统一次,并且 ALDU 已经在 ePO 策略中处于活动状态,则脱机用户 Bob 会在被丢弃后分配到该系统中。
注意:从此时开始,AD 用户 Bob 可以有两种可能性。如果这是他第一次在预引导时登录,则密码为默认密码。如果这不是他的第一个系统,并且 ePO 已为 Bob 提供凭据,则 ePO 中的这些凭据将存在于该系统中。
脱机包创建实用工具的参数中已有定义。
脱机策略与 ePO 中定义的策略是否完全一致?
否。有些策略设置需要交互,例如,添加本地域用户 (ALDU)。这些策略设置无法用于脱机激活中。
可以在脱机策略中设置哪些策略选项?
脱机策略可以设置下列内容:
备份设备密钥 恢复密钥的路径 启用临时自动引导 启用自动引导 不显示之前的用户名 启用单点登录 启用引导管理器 PBFS 大小 Opal PBFS 大小 要求用户更改其密码 用户名必须与 Windows 登录用户名匹配 启用自行恢复 用户智能卡 PIN 在预引导中启用 USB
重要说明:如果计算机上安装了 Opal 驱动器,则脱机激活将首先使用 Opal 加密。OPAL 首选项已在脱机激活包中经过硬编码,因此不会使用自定义策略设置。
不可以。脱机激活仅实施第一个策略。应用第一个策略后将无法进行更新。
当脱机系统附加到 ePO 后,脱机策略会出现什么情况?
当由脱机激活成功启用的系统与生成 McAfee Agent、DE 及脱机激活包的 ePO 服务器通信时,它会丢弃脱机策略并要求 ePO 提供相应的策略。
脱机激活期间,加密密钥会发生什么情况?
当管理员配置脱机激活包时,可以选择指示是否保存密钥。是否保存密钥以及保存到哪里完全由管理员决定,而不由最终用户选择或控制。
如果我保存已完成脱机激活过程的系统中的加密密钥,是否可以将此密钥导入到 ePO 中以供恢复时使用?
不可以。但是,您可以将所有密钥存储到一个安全位置,然后使用 ePO 进行解密并生成必要的恢复 XML 文件。
收到加密密钥后,我如何才能使用它?
管理员可以解密该密钥并以 EEPC 恢复工具所使用的 XML 格式导出相关信息。
在内部设置用例中,系统的加密密钥会发生什么情况?
在此情况下,您可能想保存密钥也可能不想保存密钥。注意,将在第一次连接到 ePO 服务器时上传该密钥。由于此情况主要涉及新系统,所以如果发现任何将导致磁盘崩溃的物理缺陷,或使您被锁定无法进入系统的情况,都几乎不会丢失用户数据(如果有)。
注意:您可以将密钥保存到 USB 盘或特定的网络共享,以备需要恢复时使用。
如果是第三方设置的情况,系统的加密密钥会发生什么情况?
在此情况下,您可能不希望第三方能够保存该加密密钥,所以可能会指定不得将密钥保存到任何位置。如果第三方拥有贵组织中所有系统的各加密密钥的副本,则应考虑这一情况存在的安全风险。由于此情况主要涉及新系统,所以如果发现任何将导致磁盘崩溃的物理缺陷,或使您被锁定无法进入系统的情况,都几乎不会丢失用户数据(如果有)。
如果从不连接 ePO,系统的加密密钥会发生什么情况?
在此情况下,您很有可能想将加密密钥保存到 USB 盘或硬盘中。此为可选步骤,完全由管理员决定是否执行。然后将由您负责确保该加密密钥能安全地传输到 ePO 中以妥善保管。可通过任何贵组织批准的机制来传输加密密钥。一旦 ePO 管理员拥有已保存密钥的副本,便可在日后恢复时使用。
如果因其他错误而致使无法保存加密密钥,会发生什么情况?
在此情况下,需要重新格式化客户端上的硬盘并重新启动脱机激活过程。
当加密密钥写入到磁盘中的文件时,会以纯文本格式保存吗?
不会。加密密钥将始终处于加密状态,这样即便第三方拦截到该密钥也无法使用。同时他们也无法确定密钥属于哪个系统。
哪里可解密加密密钥?
用于脱机激活的加密密钥的唯一可解密位置便是创建脱机包的 ePO 服务器。其他 ePO 服务器都无法解密该密钥。
所有脱机激活使用的加密密钥都一样吗?
不一样。将在第一个策略实施期间生成加密密钥。这可确保所有脱机激活都具有不同的密钥。
如何对脱机激活执行恢复?
如果管理员已选择保存加密密钥,则该密钥将以加密方式写入到磁盘的文件中。随后由最终用户负责使用公司批准的方法将加密密钥传输给管理员。如果管理员拥有加密密钥,他们就可在必要时使用创建脱机包的 ePO 服务器对其进行解密。解密后将生成可与 DE 恢复工具配合使用的标准 XML 文件。
脱机激活可使用哪些恢复选项?
只有本地恢复和 EEPC 恢复工具这些恢复选项可用。
如果管理员禁用本地恢复该怎么办?
唯一的选择便是使用 DE 恢复工具来更正系统中的任何问题。还可以将系统连接到 ePO,此时用户及策略会被 ePO 提供的信息替换。但需要能够引导到 Windows。
如果本地恢复被禁用并且我没有已保存的加密密钥或无法解密密钥,此时可使用哪些恢复选项?
再没有其他恢复选项可用于脱机激活。
预引导文件系统 (PBFS) 中包含哪些内容?
PBFS 包含所有必要的信息来让用户进行身份验证。包含但不限于以下内容:
-
预引导环境必需的文件
-
所有受支持客户端语言的语言文件
-
用于显示所有受支持语言的字符的字体
-
分配给客户端的主题
-
分配给客户端的用户
不会。仅在创建 PBFS 时,或者在执行任何恢复过程期间重新创建 PBFS 时,才能应用 PBFS 大小设置。
需要多长时间才能使新创建的用户在 PBFS 中可用?
无法简单地回答此问题。下列应用场景尝试涵盖最常见的情况:
-
应用场景 1
如果只有一个未初始化的用户分配到系统,则只需要一次 ASCI,前提是该用户经过 ePO 中的 EE LDAP 同步任务的验证。注意:未初始化的用户是指之前未登录任何 DE 系统的用户。因此,此用户没有令牌数据。 -
应用场景 2
如果未初始化的新用户添加到已分配用户的系统中,可能需要两次 ASCI,用户在 PBFS 中才能完全可用。 -
应用场景 3
如果未初始化的用户新添加到可能已分配/未分配用户的系统中时,则需要进行两次 ASCI,用户在 PBFS 中才能完全可用,因为此用户已经初始化其令牌数据。
当用户分配到某个系统时,该系统的策略数将会增加,并且在策略实施期间,会触发请求用户数据的事件。ePO 服务器返回该事件后,会选中已分配的所有用户或者将其下载到客户端。如果在这些用户中间发现本地令牌数据和 ePO 存储的令牌数据有所不同,则会触发另一个事件以更新这些详细信息。
如果未初始化的用户没有令牌数据 PBFS,则第二个事件没有必要将所有必需的用户数据提取到客户端以及随后的 PBFS。对于其他情况,需要两个事件才能使用户在 PBFS 中完全可用。
此外,如果客户使用策略选项“添加本地域用户(ALDU)”,则会发生 2.5 ASCI 超时,该超时是在未响应 ALDU 请求的情况下触发的。如果超出该超时范围,需要实施一个新策略才能上传用户数据进行验证。
是否可以创建和自定义预引导主题?
可以。您可以轻松地创建和自定义主题 ePO。
请根据以下要求创建自定义主题:
-
尺寸为 1024 x 768 的图像
-
确保文件格式为 .PNG
-
文件大小约为 600 KB
首次在非英语操作系统上安装 DE 7.1.x 时,是否可以在预引导期间强制为英语键盘?
不可以。默认情况下,DE 安装程序将显示与产品安装到的本地化 Windows 操作系统关联的本地化键盘。
是否可以在加密的系统上使用 Windows 可引导 CD?
如果您不想要访问硬盘驱动器,可以在加密的系统上使用可引导的 CD。全盘加密的优势之一是可以防止在未经身份验证的情况下使用可引导驱动器来访问硬盘驱动器。如果 Windows 运行不正常,需要使用 Windows 安装盘进行修复,则必须先解密驱动器,然后才能使用 Windows 修复工具。要访问加密的驱动器和 DETech WinPE 恢复媒体,必须创建媒体。有关如何创建媒体的详细信息,请参阅 PD24204。
预引导智能检查 (PBSC) 是 DE 中的一项功能,该功能将执行各种预引导硬件兼容性检查,以确保 DE 预引导环境能够在系统中顺利地运行。它将对之前已确定会造成不兼容问题的区域进行测试。
预引导智能检查的目标是什么?
该检查的目标是通过检查预引导环境中的常见错误状况来帮助轻松部署 DE 全盘加密。如果不启用该检查,发生部署问题时可能会锁定用户让其无法进入系统,进而影响生产效率。如果存在问题,预引导智能检查将停用 DE,并允许系统回滚到仅限 Windows 的身份验证。
此预引导智能检查功能是否默认为启用?
否。默认情况下并非启用状态,因为在此状态下会使得一个或多个系统重新启动进入激活流程。有些客户可能会接受这一点,而另一些则可能不会接受。
预引导智能检查发现问题后会采取什么措施,工作流程是什么?
如果发现问题(无法加载预引导或转到 Windows 时出现问题),系统将自动重新启动,或者用户需要强制重新启动系统。
如此可让 PBSC 尝试使用另一套兼容性配置来解决问题。只要有任何一种配置有效且系统引导到 Windows,就会完全激活 DE 并实施加密策略。如果所有兼容性配置都已尝试过且都遇到了不可恢复的问题,系统将绕过 DE 预引导直接引导至 Windows,且 DE 会被停用。此时,系统会向 ePO 发送审核以报告此项失败,系统上的后续激活都将被阻止。
如果系统通过了预引导智能检查,会发生什么情况?
它将激活 DE 并实施加密策略。
如果系统未通过预引导智能检查,会发生什么情况?
如果系统未通过预引导智能检查,则不会激活 EEPC。因此,EEPC 激活(以及在策略中设置的加密)将不会继续,且系统将“回滚”到仅限 Windows 的身份验证。
如果系统未通过预引导智能检查,是否会在下一次实施策略时继续尝试激活 DE?
是。不过,激活将被立即放弃。所有的后续激活操作都将被立即放弃,除非出现下列任意一种情况:
您通过策略禁用 PBSC 您删除了注册表值:Software\McAfee Full Disk Encryption\MfeEpePc\SafeFailStatus\Status
在 ePO 中是否会标记未通过预引导智能检查的系统?
不会。
针对某个计算机的预引导智能检查的结果可与其他计算机共享吗?
不可以。每个系统都是单独测试的。目前没有可在不同计算机类型之间共享通用配置的功能,因此无法在验证特定硬件配置后在类似系统之间共享预引导智能检查的结果。
如何才能知道预引导智能检查是否对配置进行了任何更改,或者系统是否开机即用?
DE 7.1 中未提供此信息。此类更改对最终用户透明且会自动发生。
如果预引导智能检查未进行任何更改且系统是开机即用的,是否表示我可以在部署时禁用该检查?
该检查由客户自行决定是否执行。不过,即使型号相同的系统之间也存在差异,这一现象很常见。例如,用户可能已进入 BIOS 且更改了其 USB 设置。这可能会影响与 BIOS 的集成,此时保留 PBSC 就会发挥作用。但如果您使用 BIOS 密码来阻止用户进行此类更改,那么不使用 PBSC 也是可以的。
对于仍然在运行预引导智能检查的系统,管理员会在 ePO 中看到些什么?
管理员会发现系统未激活且未加密。他们可以查看审核日志,以了解自系统上次与 ePO 同步以来任何进度的最新信息。
管理员是否会知道系统是因未通过预引导智能检查而未激活的?
是。将对失败进行审核。
管理员将从哪里知道系统未通过预引导智能检查?
管理员可在系统审核日志中查看相关信息。
在 DE 7.1.x 中使用 Intel Active Management Technology (AMT) 和 McAfee ePO Deep Command 实施的首批 EEPC 用例是什么?
DE 7.1.0 中实施的前四个用例是:
重置密码 上下文相关安全 唤醒和修补 远程补救注意:以下常见问题将详细讨论这些用例。
作为管理员,我如何才能知道是否可在特定系统上使用 AMT 功能?
如果是在 ePO 中查看系统属性,您将可以看到针对特定系统的 AMT 信息。McAfee ePO Deep Command Discovery and Reporting(免费)也会提供并在信息显示板中显示有关 ePO 中所有托管系统的此类信息。要与 DE 兼容,Deep Command 必须将 AMT 状态报告为配置后。此外,DE 还要求 AMT 版本为 6.0 或更高版本。
有关系统的 Intel AMT 信息如何才能进入 ePO?
首先,您要安装 Deep Command 扩展(包括 Discovery and Reporting 扩展),并在 ePO 服务器上签入这些包。您需要将 Deep Command 包部署到客户端,以便客户端能够回报 AMT 是否已启用。此外,如果系统确实已激活 AMT,客户端将回报哪些 AMT 功能受支持。Deep Command 会向 ePO 添加一项计划服务器任务,以便自动标记启用 AMT 的系统。此任务计划为每日运行,也可以更改该计划。有关更多信息,请参阅 ePO Deep Command 文档。如果系统尚未激活 AMT,请参阅 Deep Command Discovery and Reporting 摘要信息显示板以获取来自客户端的 AMT 支持信息。
ePO Deep Command 和 DE 支持哪些版本的 Intel AMT?
要查看支持哪些 AMT 版本,请参阅 KB79422。
注意:AMT 版本信息包含在 ePO Deep Command 回报的信息中,管理员可在计算机上查看此信息。
与 Intel AMT 相关的 CILA 和 CIRA 是什么意思?
客户端启动的本地访问 (CILA) 指的是来自内部网络地址的 AMT 请求。客户端启动的远程访问 (CIRA) 指的是来自远程网络地址的 AMT 请求。有关“本地”和“远程”的定义在 AMT 设置过程中指定。
为何在默认情况下 CIRA 的默认策略设置为“禁用”?
这是 McAfee 有意为之,旨在保护客户避免意外曝光风险。CIRA 受支持且必须明确将其启用。通过默认禁用 CIRA,即表示一旦某家公司的代理处理程序在互联网中曝光,该公司将不会响应任何通过互联网发送的 AMT 请求。McAfee 认为客户需要决定是否要启用此功能。
哪些类型的 Intel AMT 操作可在系统中排队?
临时操作和永久操作。
是否可以提供永久操作和临时操作的示例?
临时操作是指那种在执行 x 次后从操作队列中删除的操作。以下是该类型操作的一些示例:
重置用户密码 解锁 x 次 解锁一段时间 紧急引导 还原 MBR
永久操作是指那种将一直保留在操作队列中直到被管理员删除的操作:
解锁计划 永久解锁
可为系统/用户分配的每种 Intel AMT 操作各有多少?
任何时候每个系统最多只能分配一个临时操作和一个永久操作。
为什么只能有一个 Intel AMT 临时操作和一个永久操作?
这是在首次实施与 Intel AMT 的集成时决定的设计。如果出现其他用例,此项设计也可以再议。基础架构已设计为可根据需要处理多个操作。
当我观察客户端上的“唤醒和修补(远程解锁)”或“上下文相关安全(解锁)”时,预引导在继续引导至操作系统之前似乎停留了大约 20 秒或更长时间 - 这是否正常?
决定预引导花费时间的因素有多方面。网络速度和 ePO 服务器的工作负载都是其中一种可能的因素。AMT 固件中存在一个已知问题,可能会导致在 CILA 事件离开端点之前有 20 秒钟的延迟。它对 DE 的影响是,在 CILA 环境中可能需要超过 20 秒的时间进行带外解锁。Intel 正在调查此问题。要查看其他的 DE 7.1 已知问题,请参阅 KB84502。
DE 7.1 集成需要哪些 Deep Command 策略和设置?
需要 ePO Deep Command 1.5.0 和 Intel AMT 策略。确保在策略中正确配置以下项目:
应启用远程访问。 启用客户端启动的本地访问 (CILA)。选择正确的代理处理程序。 针对连接类型选择 BIOS 和操作系统。 如果您想要启用客户端启动的远程访问 (CIRA),请确保已配置以下项目:
主域后缀 DMZ 代理处理程序 允许用户启动的隧道
最终用户启动计算机,但登录失败,然后呼叫服务台。 最终用户将进入预引导的“恢复”部分,然后向服务台用户提供自己的 ePO 用户名。 服务台用户会查找该用户在 ePO 中使用的系统。 服务台用户通过 Intel AMT 功能使用临时的一次性密码重置用户密码。 对于要接收新令牌数据的指定系统,ePO 会将项目写入工作队列,然后预引导会读取工作队列并使用 Intel AMT 提供的网络堆栈来提取密钥。 客户端将收到新令牌数据并自动离开恢复屏幕,返回密码屏幕。这就是告诉最终用户新密码已被接收。此外,最终用户还将听到“哔”的一声,表示新令牌数据已被接收。 最终用户随后使用一次性密码进行身份验证并设置新密码。
在客户端上,用户可在预引导期间进入恢复屏幕并可以查看计算机 ID 和计算机名称。他们可将此信息提供给管理员/服务台,也可以使用此信息在 ePO 中查找计算机。
如果无法确定最终用户所用的系统,我是否可以将 Intel AMT 命令发送给用户能访问的所有系统?
可以,但是 McAfee 不建议这么做。假设用户可以访问两台笔记本电脑。若他们开启 1 号笔记本电脑,并收到更改密码的指示。接着完成该流程,并启动 Windows。此时,他们打开 2 号笔记本电脑,同样收到更改密码的请求。他们的令牌数据已更新为一次性密码,但却要求他们再次更改此密码。虽然从理论上讲,这在受控制的环境或用户感知型环境中是可行的,但很可能会给最终用户造成混淆。
某个管理员刚刚使用 Intel AMT 功能更改了用户密码。最终用户如何才能知道新的恢复密码是否已发送到客户端?
如果最终用户正处于恢复屏幕(即他们告知管理员其计算机 ID 详细信息时所处的位置),他们会发现恢复屏幕消失,取而代之的是登录屏幕。这表示新密码信息已被接收。
注意:
如果最终用户离开恢复屏幕,然后等待更新的密码被接收,他们可能会发现登录屏幕消失后很快又重新出现。 此外,一旦新令牌数据被接收,最终用户会听到“哔”的一声。
管理员如何确认更改是否成功,或验证为何更改似乎无效?
此信息将出现在 AMTService.log 中。请注意,ePO 中不会生成事件,因为代理处理程序中没有生成事件的 ePO API。
管理员在哪里可以找到 AMTService.log 文件?
可以在 ePO 服务器上的 <ePO 安装文件夹>/<代理处理程序安装文件夹>\DB\Logs\AMTService.log 下找到该文件。该文件也会被收集成为服务器 MER 的一部分。
什么是“上下文相关安全”用例?
“上下文相关安全”用例(也称为“位置感知”)是一种在 DE 预引导环境中的新的身份验证功能。有了此功能,系统无需用户干预便可进行身份验证。预引导会使用 Intel AMT 来启动与 ePO 的网络连接,而不是要求用户提供凭据。接着,预引导会检索在预引导中用来进行身份验证的密钥,然后将计算机引导到操作系统。预引导环境和 ePO 可确定系统是在办公室内部还是通过互联网连接。如果系统位于办公室内,“上下文相关安全”可让管理员将系统配置为通过 ePO 和 AMT 自动进行身份验证,但如果系统在办公室之外,则会显示预引导身份验证屏幕。
以下是“上下文相关安全”适用的用例示例:
客户希望当其最终用户位于办公室内时不显示预引导环境,而当最终用户离开办公室或系统丢失/遭窃时显示预引导环境。 客户希望借助预引导概念并利用 ePO 和 AMT 自动进行身份验证,来实现对始终位于办公室内部的系统进行加密但又不会对最终用户造成影响。同时又希望当计算机被盗离办公室时会显示预引导。 客户拥有被多位用户共同使用的共享计算机。例如会议室、培训室或在医院环境中的笔记本电脑和桌面机等。 客户想以永不显示预引导的方式避免密码同步问题,同时又希望在计算机丢失/遭窃时获得预引导的保护。用户将会在 Windows 中进行首次身份验证(即使是在后台),DE 已通过 ePO 和 AMT 自动进行身份验证。
“上下文相关安全”的工作原理是什么?
当预引导启动时,它会尝试连接 ePO 并请求获得引导权限。由 ePO 主导且由其决定是否要返回解锁密钥。如果客户端无法连接到 ePO 或 ePO 无法将解锁密钥返回给客户端,则会显示预引导环境并等待最终用户成功完成身份验证。如果 ePO 发送了解锁密钥,计算机将被解锁。解锁密钥将通过受 AMT 硬件保护的安全通道发送到客户端。
“上下文相关安全”身份验证是否真正发生在客户端上,必要的信息是来自 ePO 吗?
是。
此“上下文相关安全”功能会绕过预引导吗?
不会,预引导环境始终存在且始终处于活动状态。身份验证成功完成后,预引导仍会关闭且会引导操作系统。在此用例中,身份验证由 ePO 执行。
如果我是站在计算机前面的用户,我可以看到它自动引导到 Windows 吗?
可以。只要 ePO 发回的响应是肯定的,系统就会在处理响应后自动引导操作系统。
单点登录 (SSO) 在此“上下文相关安全”用例中是否可用?
否。这是因为预引导中的身份验证是针对计算机的,而非用户。由于 DE 不知道登录的是哪个用户,所以它无法重放任何捕获的单点登录数据。
使用“上下文相关安全”功能时,最终用户仍然只需要登录一次吗?
是。在此情况下,会在出现 Windows 提示(而非 DE 预引导提示)时进行用户身份验证。
使用“上下文相关安全”功能时,是否意味着用户只能一直使用其最新的 Windows 密码登录 Windows?
是。对要继续使用此功能的用户而言,这可以避免任何与密码同步相关的问题。
对于在办公室内外均使用该功能的移动用户,会出现什么情况?
如果他们不在办公室内,则在预引导时需要提供凭据以进行身份验证。
使用“上下文相关安全”时,移动用户的密码同步会发生什么情况?
对移动用户来说,最好始终强制实施预引导身份验证,因为在此用例中,从技术上讲最终用户并非在预引导期间登录。DE 无法感知密码更新,因为它不知道用户要将密码更新应用到哪个预引导。
“上下文相关安全”的最常见实施方式是怎样的?
最常见用例是仅对桌面系统或不离开办公室网络的笔记本电脑使用此功能。
如果计算机在使用“上下文相关安全”期间遭窃,是否会显示预引导环境?
是。之所以会显示预引导环境是因为系统无法与 ePO 通信且将等待用户进行身份验证。
如果我已启用 CIRA,是否意味着位于我的网络外部的系统也可以进行自动引导?
否。PBA 显示与否不由 DE 决定。如果 DE“带外”管理已启用,那么 DE 将尝试发送呼叫进行求助。
AMT 芯片随后会检查环境,看看自身插入的是远程网络还是本地网络。如果插入的是本地网络,它会向 ePO 服务器发布一个 CILA。但如果它检测到连接的是远程网络,且 CIRA 服务器已指定,则会尝试对该服务器进行安全连接。只要有任何呼叫求助(不管是 CILA 还是 CIRA)后的结果是能够成功连接到服务器且服务器决定发送加密密钥,PBA 都将解锁并进入 Windows。否则,如果未收到任何密钥,则将停留在 PBA 中。
管理员如何启用“上下文相关安全”功能?
管理员可选择一个或多个系统,接着选择“带外 - 解锁 PBA”操作,然后指定解锁的持续时间(永久的或按计划)。
注意:管理员也可以选择操作是仅适用于本地计算机,还是同时适用于本地和远程计算机。
此“上下文相关安全”功能可设置为永久的,还是只能设置为持续一段时间?
启用此功能时,管理员可选择永久启用此功能或是在定义的时间段内启用此功能。如果选择定义的时间段内,管理员可以指定下列其中一项:
一次或多次重新启动 从开始日期/时间到结束日期/时间 安排阻止或可用时间段的周计划
使用“上下文相关安全”功能时,如果 ePO 正忙且无法响应系统,会出现什么情况?
系统将停留在预引导环境,并将每隔五分钟重试一次。
如果首次尝试连接 ePO 失败,系统会重试吗?
会。它将会每 5 分钟再尝试一次连接 ePO。CILA(本地)请求适用此情况。而如果是 CIRA(远程)请求,则计算机将只会连接 ePO 一次。如果未收到响应,系统需要重新启动以再次进行连接。
如果 ePO 服务器不可用且客户端无法连接 ePO 服务器,会发生什么情况?
这属于 Vaguely Unpleasant 案例。如果用户不知道其预引导凭据(如果用户一直在使用“上下文相关安全”功能则有可能会发生此状况),那么他们会停留在预引导环境中。他们唯一的选择就是呼叫服务台并通过质询/响应过程进行系统恢复。
如果最终用户在办公室内部使用桌面系统且使用“上下文相关安全”功能,之前从不需要登录到预引导,会发生什么情况?现在他们会看到预引导屏幕,但不知道凭据为何。他们该怎么办?他们是否可以让预引导再次连接 ePO?
有以下几种选择:
首先,他们可以等待五分钟以重新尝试连接 ePO。由于是 CILA(本地)请求,因此这是可行的。 其次,他们可以关闭系统再重新开启。这会使预引导在重新启动时立即再次连接 ePO。 最后,他们始终可以通过输入其他可在预引导时进行身份验证的已知用户的用户名/密码来进行身份验证,尽管此方法可能并非在所有情况下都可用。
可在“AMTService.log”中查看此问题。此文件会滚动更新且有大小限制(默认的大小限制由 Deep Command 设置且可进行配置)。
什么是唤醒和修补(远程解锁)用例?
此用例包含临时或定期唤醒和修补计算机的需求。这些计算机已关机,需要将其唤醒以便对其应用补丁。
唤醒和修补(远程解锁)用例与“上下文相关安全”用例十分相似。下列这些涉及到“上下文相关安全”的已解答问题也适用于“唤醒和修补(远程解锁)”:
-
此功能的工作原理是什么?
-
此功能会绕过预引导吗?
-
如果我是站在计算机前面的用户,我可以看到它自动引导到 Windows 吗?
-
单点登录 (SSO) 在此用例中是否可用?
-
如果 ePO 正忙且无法响应系统,会出现什么情况?
-
如果首次尝试连接 ePO 失败,系统会重试吗?
-
管理员如何启用此功能?
-
此功能可设置为永久的,还是只能设置为持续一段时间?
-
身份验证是否真正发生在客户端上,必要的信息是来自 ePO 吗?
是否可以交错安排唤醒和修复(远程解锁)或其连接 ePO 的时间间隔?
管理员需要交错安排 Deep Command 开启命令或与其等同的 Wake On LAN 请求。系统在 SILA(本地)环境中进行补救(当操作是由服务器启动时)时处于开启状态。在其他情况下,客户端会连接 ePO;因此,可以假设它已开机,因为它连接了 ePO 服务器。
如果 ePO 正忙且无法响应,会出现什么情况?客户端系统会执行哪些操作?
如果发出 Wake On LAN 请求之后 ePO 正忙或无法响应,那么系统将会停留在预引导环境中并将每隔五分钟重试一次。CILA(本地)请求适用此情况。而如果是 CIRA(远程)请求,则计算机将只会连接 ePO 一次。如果未收到任何响应,系统需要重新启动以再次连接 ePO 服务器。
要定期连接系统,则需要使用“闹钟”功能将系统配置为定期发送 CIRA 消息。“闹钟”功能会在某个指定的时间开启系统。
是否可以查看有多少个系统登录到了 Windows 以进行修补?
可以。管理员可使用相应的过滤器通过“DE: 产品客户端事件”查询进行查看。具体数量由与 ePO 服务器通信以向其发送审核信息的系统数量而定。
是否可以确定使用唤醒和修补功能时哪些系统未通过预引导?
不可以。如果系统未引导至 Windows,“DE: 产品客户端事件”查询中将不会存在任何条目。
什么是远程补救用例?
此用例能够让管理员执行紧急引导,或者通过 AMT 替换客户端系统上的 DE MBR,而无需实际接触计算机。此功能可让管理员能够对远在地球另一端的客户端系统上的问题进行修复。
请阅读下面的内容,以了解有关远程补救和 UEFI 的详细信息。
远程补救的工作原理是什么?
从较高的层面讲,其原理是通过 AMT 将一个小型磁盘映像(大小为 1.44MB,但实际只使用了 300k)向下推送到客户端系统。一旦客户端上收到该映像,就会重新启动并使用 IDE-R 中的引导网络进行引导。随后,该映像会执行必要的补救操作并启动引导 Windows 的过程。
远程补救的可行操作是什么?
第一项操作是执行紧急引导,第二项操作是替换 MBR。不过,远程补救仅适用于具有 BIOS 引导进程的计算机。
管理员如何使用此项远程补救功能?
管理员可选择一个或多个系统,然后选择“带外 - 补救”操作,最后指定是“紧急引导”还是“还原 Endpoint Encryption MBR”,再单击“确定”。
如果是在本地客户端上该如何启动远程补救?
当客户端系统连接到本地企业网络时,启动过程的简要说明如下:
用户引导系统但发现不可行。 用户呼叫管理员请求帮助。 管理员选择适当的补救操作,该操作将立即开始执行。此过程也被称为“SILA”(服务器启动的本地访问)。 如果找到客户端系统并能建立连接,则会启动重定向功能并自动对系统进行修复。
不过,如果本地网络中找不到客户端系统,操作将失败且其状态将保持为“排队中”。此后,只有当系统调用时才会进行处理。若此时无法进行处理则原因是预引导遭到损坏,因此也可以使用与下一个情况中所述类似的流程。
如果是在远程客户端上该如何启动远程补救?
当系统通过公共网络连接时,启动过程的简要说明如下:
用户引导系统但发现不可行。 用户呼叫管理员请求帮助。 管理员选择适当的补救操作,该操作将立即开始执行。若此时操作失败则原因是在企业网络中找不到系统。 管理员要求用户从 BIOS 启动“呼叫求助”。此选项因 OEM 而异,但一般位于引导选项下方,在某些系统中,只需按 CTRL+ALT+F1 即可。 选择后,系统会连接到 STunnel(Deep Command 网关服务),代理处理程序将检测到此情况,然后向 Deep Command 发送消息。 Deep Command 将执行与此系统关联的操作。在此例中,执行的操作为补救。
我在圣克拉拉,想对身在日本的最终用户运行紧急引导,并且需要在一次重要会议之前完成紧急恢复。我可以使用远程补救来实现此目标吗?
可以。使用此过程无需最终用户的干预。他们只需要在一旁看着您修复客户端系统就可以了。CILA(本地)适用此情况。如果是 CIRA(远程),一开始该操作会失败,但当系统通过 CIRA 建立连接后,就能成功执行。
在上例中,远程补救需要花费多长时间?
这在很大程度上取决于网络速度以及将映像下载至客户端系统所需的时间。引导至映像后,远程补救所需的时间便如同您于当天手动执行紧急引导时所需的时间一样了。在此期间实际遵循的流程相同,只是采用自动方式。
作为管理员,我会收到任何有关远程补救的进度通知吗?
管理员只会在操作开始和结束时收到通知。完成后还会被告知远程补救是否成功。审核将会在客户端上执行,并且只能在下一次代理与服务器通信 (ASCII) 时向 ePO 发回信息。管理员可以对客户端事件运行查询,以找到具有解锁事件的客户端。
作为最终用户,我会收到任何有关远程补救的进度通知吗?
映像下载完毕且补救过程开始后,屏幕上将会显示一条消息。如果是通过 AMT 将映像下载到客户端,有时屏幕右上角还会出现一个闪烁的标志符号。这表示 AMT 正在接收网络流量。同样,持续时间在很大程度上取决于网络流量和速度。如果网速很快,最终用户会发现 Windows 在瞬间加载完成。
执行远程补救时,我没有看到闪烁的标志符号。这是否意味着什么事都未发生?
存在这种可能。由于在 AMT 7 版之前的版本中并未包含该功能,如果您使用的是 AMT 6 版,则无法看到该标志符号。
执行远程补救时,如果我已没有时间完成该操作且需要离开当前位置,而在我离开时又必须断开网络电缆,会出现什么情况?我需要重新启动整个过程吗?如果需要这么做,我需要再次与管理员协作吗?
不需要,该过程将会自动重新启动。一旦管理员添加了远程补救请求,它就会一直保留在操作队列中,直到该操作完成或被管理员删除为止。这意味着在您每次开启客户端后,系统都会尝试执行补救,直到成功为止。
远程补救过程已成功完成,用户已获得 Windows 访问权。他们可以陈述情况,但最终他们无法连接到公司的 ePO 服务器。当他们重新启动客户端时,是否需要执行相同的流程?
需要。如果预引导遭到损坏,则会紧急引导客户端。在客户端能够与 ePO 服务器成功通信之前,无法修复此问题。
在另一个替换 MBR 的用例中,此问题的回答是否。
为什么我要替换 MBR?
一种情况是当加密系统时,第三方产品意外覆盖了 MBR。另一种情况是,如果系统受到 MBR 病毒的感染,您需要将系统恢复到 Windows,以便能够执行任何其他补救操作。
选择补救时,我可以选择特定的磁盘映像 - 但为什么要执行该操作?
默认的选项是“自动”,并且您应当一直使用该选项,除非另有指示。自动选项将使用从客户端接收的信息来选择正确的映像。如果此信息不可用,则不会执行补救操作。此选项可让您指定将下载到计算机的准确映像。BIOS 引导以及 Opal 和非 Opal 补救适用的映像各不相同。
如果为客户端选择了错误的磁盘映像,会发生什么情况?
如果是手动选择的映像,用户界面 (UI) 将提示您如果使用错误映像可能会对磁盘造成损坏。当加密提供程序或 BIOS 类型不可用时,会添加此选项。
远程补救功能在 UEFI 环境中可用吗?
不可用。这是因为 IDE 重定向功能在 UEFI 中不起作用,而执行远程补救时需要此功能。
管理员可以使用哪些报告来了解 AMT 操作在客户端上是否成功完成?
DE 仅包含一项服务器端操作,就是补救操作。要确定它是否已完成,管理员应通过对事件审核日志运行查询以查看客户端事件的方式来检查 ePO 服务器任务日志。
管理员可以通过查看哪些报告或日志来确定发生错误的操作及位置以及无法成功完成该操作的原因?
管理员需要查看“AMTService.log”和“DE: 产品客户端事件”查询。
管理员可以从哪里了解某个(或多个)客户端上已成功完成一项(或多项)AMT 操作?
运行“DE: 产品客户端事件”查询。
管理员可以创建有关 AMT 操作的报告吗?(例如,使用“远程解锁”功能显示当天执行了自动引导的系统数量)
使用适当的过滤器运行“DE: 产品客户端事件”查询。具体数量由与 ePO 服务器成功通信以向其发送审核信息的系统数量而定。
管理员可以对 AMT 带外问题执行哪些故障排除?应先执行哪些步骤?
管理员需要先确定问题是来自 CILA(本地)任务还是 CIRA(远程)任务。
如果是执行 CIRA(远程)任务时发生的问题,那么现在该怎么做?
让管理员引导客户端系统并访问 BIOS,或者引导到 Windows 并使用 Intel Management and Security Status(英特尔管理与安全状态)请求帮助。然后,他们需要查看“AMTService.log”以确定是否已收到请求。如果收到请求,支持呼叫将由 DE 技术支持团队受理。否则,将由 Deep Command 第 III 级团队受理。
如果 AMT 带外问题来自 CILA(本地)任务,该怎么做?
让管理员使用 Deep Command 操作将客户端引导到 BIOS。如果成功,支持呼叫将由 DE 技术支持团队受理。否则,将由 Deep Command 技术支持团队受理。
什么是 Opal?
Opal 是与自加密驱动器相关的规范的名称,该规范由名为受信任的计算组的标准机构制定。
什么是 Opal 驱动器?
Opal 驱动器是自包含的独立 HDD,它符合 TCG Opal 标准。该驱动器始终处于加密状态,但不一定会锁定。除了 HDD 标准组件外,Opal 驱动器还包含其他组件(例如板载加密处理器),用于对 HDD 自身上的数据执行所有必要的加密/解密。除了常规的旋转介质 (HDD) 外,SSD 也可以支持 TCG Opal 标准。
Opal 驱动器是否为自加密驱动器?
是。它是自加密驱动器的一种类型,但不是唯一的一种。市场上还有其他专有的自加密驱动器。
Opal 是标准还是品牌?
Opal 是一种标准或规范,详细描述了驱动器需要响应的命令以及标准行为。该标准由受信任的计算组 (TCG) 的存储工作小组创建并批准。
TCG 是一家非盈利组织,它的组建目的是针对跨越多个平台的受信任计算构建基块和软件接口开发、定义和倡导开放的、供应商中立的行业标准。
符合 TCG 规范的自加密驱动器是否与 Opal 驱动器相同?
是。
不需要。软件加密对于大多数用户而言已经足够。大多数生产员工察觉不到软件加密,也不受其影响。使用 DE 7.1 时,软件加密对使用 Intel CPU 且支持 AES-NI 的系统的影响可忽略不计,因此,软件加密的性能与使用 Opal 驱动器时相当。
Opal 驱动器能够应对哪种威胁模型?
主要用例是防止笔记本电脑/台式机的遗失或失窃。它应对的威胁范围与全盘加密软件类似,并且是专为保护静止数据而设计的。
哪些使用方案最适合使用 Opal 驱动器?
需要极高磁盘 I/O(性能敏感型应用程序)的用户非常适合使用 Opal 驱动器。示例用户包括软件开发人员、视频编辑人员和航空工程师。这些用户很有可能还会使用 SSD 而不是旋转式 HDD。
SSD Opal 驱动器是否既能保持 SSD 的性能,又不损害安全性?
是。对于大多数敏感型用户而言,以 SSD 形式实施的 Opal 驱动器既能保持 SSD 的速度和性能,又能保留 Opal 驱动器的所有安全和加密特性。但由于 Opal 驱动器始终由板载加密处理器加密,因此,难以准确地确定板载加密处理会造成何种程度的性能下降(如果存在)。
使用 Opal 驱动器时的 DE 体验大概是怎样的?
不管设备使用的是 Opal 驱动器还是普通 HDD,管理员的日常任务都完全相同。策略、部署方法和管理全都相同。恢复过程略有变化,但是,管理员在恢复方案中执行的步骤是相同的。有关在 DE 中体验 Opal 的更多详细信息,请参阅本文的 Opal 体验部分。
不管最终用户使用的是 Opal 驱动器还是普通 HDD,用户和管理员都可以使用所有的标准 DE 恢复机制。
DE 是否支持其他类型的自加密驱动器 (SED)?
不支持。目前,没有计划支持除实施 TCG Opal 标准外的其他类型的 SED。
既然 Opal 驱动器能够处理所有加密,为何还需要 DE?
Opal 驱动器需要接受管理。在对 Opal 驱动器进行管理之前,它的行为和响应方式与普通 HDD 完全相同。DE 和 ePO 的组合可以提供多样化的管理、报告和恢复功能,这对于管理员而言至关重要。DE 的价值在于可以安装安全预引导环境(解锁 Opal 驱动器)、执行 Opal 用户管理、确保持续实施组织的加密策略,并在发生数据丢失时检验设备上次与 ePO 同步时是否已加密。另外,对于混合使用 Opal 驱动器和普通 HDD 的组织而言,重要的一点是,管理员可以利用单个工具来管理和实施策略,对设备进行报告以及评估公司面临的潜在风险;DE 正好提供了这样一个工具。此外,DE 支持的用户数比非托管 Opal 驱动器要多得多,这是它的一个优势。
以下文章详述了 DE 对不同制造商生产的 Opal 驱动器的支持。此文还详细说明了当某个 Opal 驱动器不在受支持列表中时,如何自我认证该驱动器。有关详细信息,请参阅 KB81136。
DE 是否支持在所有受支持操作系统上使用 Opal 驱动器?
不支持。目前尚无在其他操作系统上支持 Opal 的计划。目前的支持详细信息如下:
- EEPC 6.2 仅支持在采用旧版 (BIOS) 模式的 Windows 7 SP1 及更高版本的系统上使用 Opal 驱动器。
- DE 7.x 支持在采用旧版 (BIOS) 与 UEFI 模式的 Windows 7 SP1 和更高版本以及 Windows 8.x 上使用 Opal 驱动器。
- DE 7.x 支持在已通过 Windows 8 认证并且其 OEM 已包含在用于安全通信的 UEFI 协议中的、采用 UEFI 模式的 Windows 8.x 系统上使用 Opal 驱动器。
- 其 OEM 未绑定安全通信协议的 UEFI 系统不受支持,因为 DE 预引导环境没有可与该驱动器通信的机制。在这种情况下,将自动使用软件加密。
某些 Opal 驱动器是 512e 驱动器,换言之,实际上它们是扇区大小为 4096 字节的驱动器,但是在模拟旧式 512 字节扇区的驱动器。Windows 7 SP1 包含重要的驱动程序修复,使这些 512e 驱动器能够正常工作。
如果用户在运行不支持的操作系统时尝试激活 Opal 驱动器上的 DE,会发生什么情况?
如果 DE 检测到不兼容或不支持的操作系统与 Opal 驱动器组合,它会继续执行激活过程,但会使用软件加密而不使用本机 Opal 功能。在 ePO 中,系统将显示为使用软件加密。
Mac OS X 上是否支持 Opal 驱动器?
不支持。在 Apple 添加对其 FileVault 加密产品的支持之前,不支持 Opal 驱动器。
返回目录
否。管理员不需要区别对待 Opal 驱动器与普通 HDD。装有 Opal 驱动器的笔记本电脑与装有普通 HDD 的笔记本电脑上可以使用完全相同的策略。
DE 策略中存在加密提供程序的优先顺序。它的作用是什么?
它能让管理员定制 DE 智能客户端如何在客户端上实施策略。如果 Opal 加密提供程序的优先级高于软件加密提供程序,则 DE 客户端首先将会搜索 Opal 驱动器。如果所有附加的驱动器都支持 Opal,客户端将使用 Opal 功能来实施加密策略。如果驱动器不符合此标准,则客户端将转到列表中的下一个加密提供程序,也就是说,将接着使用软件加密来实施加密策略。通过更改优先顺序并将软件加密设置为最高优先级,管理员可以指定所有计算机都将使用软件加密,不管计算机中安装的是 Opal 驱动器还是普通 HDD。
重要说明:如果计算机上安装了 Opal 驱动器,则脱机激活将首先使用 Opal 加密。OPAL 首选项已在脱机激活包中经过硬编码,因此不会使用自定义策略设置。
Opal 驱动器的部署是否有任何不同之处?
否。不管客户端系统使用的是 Opal 驱动器还是普通 HDD,部署过程都完全相同。
管理员如何判断客户端使用的是 Opal 功能还是软件加密?
在 ePO 中查看计算机,确定哪个加密提供程序正在实施加密策略。如果显示 Opal,则表示客户端使用的是 Opal 功能。
最终用户使用标准硬盘与 Opal 驱动器时的预引导过程是否存在差别?
否。预引导的表现形式和行为完全相同。最终用户可能完全感觉不到是哪个硬件在其所在的计算机上执行加密。
如果我的计算机中包含一块 Opal 驱动器和一块非 Opal 驱动器,那么会发生什么情况?
如果在同一台计算机中同时有 Opal 和非 Opal 驱动器,那么软件加密将是唯一的选项,并会自动选择该选项。
用户是否可以在“加密状态”仪表板中看到他们正在使用 Opal 驱动器?
不可以,他们无法直接看到,但可以从“Endpoint Encryption 状态监视器”窗口中显示的已加密卷或驱动器的列表中间接了解这些信息。
Opal 驱动器从未加密状态到加密状态需要经历多长时间?
大约一分钟。这是因为该驱动器在技术上已加密。从未加密状态转为加密状态所需的时间就是激活 Opal 驱动器的本机锁定机制并安装预引导环境所需的时间。
DE 是否知道用于加密数据的密钥?
不知道。加密密钥永远不会离开 Opal 驱动器。
恢复的工作原理是什么?
可以使用相同的 DE 恢复过程和工具来对 Opal 驱动器和普通 HDD 执行恢复。DETech 将会更新以了解如何解锁 Opal 驱动器,不过无法将其解密,因为 Opal 驱动器永远不会分发加密密钥,并且永远不会解密磁盘。DETech 解锁磁盘的唯一目的是使操作系统能够引导。
第三方公司开发的鉴证软件怎样?它们可以搭配 Opal 驱动器使用吗?
McAfee 一直在与提供鉴证软件的公司协作,我们与这些公司的交互近乎保持相同。这些应用程序不会要求 DE 提供加密密钥,而是要求 DE 提供必要的凭据来解锁驱动器。请注意,无法创建 Opal 驱动器的扇区级副本,以及使用加密密钥来解密该扇区级副本,因为加密密钥永远是不可知的。
Opal 驱动器是否始终处于加密状态?
是。不管驱动器是锁定还是解锁,它始终处于加密状态。无法获得解密的 Opal 驱动器。注意:永远无法从驱动器中读取磁盘加密密钥 (DEK)。
DE 中的 Opal 驱动器包含哪些有效状态?
已解锁和已锁定。
已锁定与已解锁之间有何差别?
从技术上讲,差别在于驱动器的板载加密处理器对加密密钥的访问。
- 如果磁盘已解锁,则板载加密处理器有权访问磁盘加密密钥,并且驱动器的行为与普通 HDD 完全相同。最终用户无法分辨 Opal 驱动器和普通 HDD 在这种状态上的差别。
- 如果磁盘已锁定,则磁盘加密密钥将受到保护,并需要使用预引导环境来解锁磁盘,然后才能访问数据以及引导操作系统。请注意,磁盘加密密钥保存在驱动器内部;无法从驱动器中读取该密钥。
Opal 驱动器的默认状态是什么?
最初收到 Opal 驱动器时,它的状态为已解锁。它的行为和响应方式与普通 HDD 完全相同。需要通过启用驱动器的本机锁定机制来显式锁定驱动器。实现此目的的方法之一是使用 DE 来管理驱动器。
如何将驱动器的解锁状态转换为锁定状态?
包含预引导环境的应用程序(例如 DE)需要执行必要的步骤来启用 Opal 驱动器的本机锁定机制,然后安装预引导环境。锁定驱动器后,需要使用预引导环境来解锁驱动器,然后操作系统才能启动其引导进程。如果没有预引导环境,则无法解锁驱动器以及引导操作系统。
解锁已锁定的驱动器后,该驱动器会保持解锁状态多长时间?
在下一个通电周期之前,Opal 驱动器将一直保持解锁状态。也就是说,在解锁 Opal 驱动器之后,关闭设备或者转移到 Opal 驱动器会断电的另一种电源状态之前,该驱动器将一直保持解锁状态。但在 DE 中,为了确保用户体验与使用 DE 软件加密时的情况相同,在重新启动时也会显式锁定驱动器。
是否有任何人或任何事物知道用于加密数据的加密密钥?
否。密钥在驱动器上创建,永远不会离开驱动器。任何应用程序或其他硬件组件都无法要求驱动器提供其密钥。
是否可以使用 EnCase 等工具创建驱动器的磁盘映像以及将它解密?
不可以。密钥在驱动器上创建,永远不会离开驱动器。任何应用程序或其他硬件组件都无法要求驱动器提供其密钥,因此,无法在 EnCase 等工具中使用密钥。
如果 Opal 驱动器已锁定,而我又忘记了密码,该怎么办?
可以借助 DE 的恢复机制来解决问题。
是否可以将 Opal 驱动器还原为默认的出厂状态?
可以使用一个经 TCG 批准的机制来执行还原过程,但必须已知驱动器主凭据。某些驱动器制造商提供一个附加的非 TCG 还原过程,可以在不知道主凭据的情况下进行还原(称为 PSID 还原)。如果驱动器不支持 PSID 还原,并且您已被锁定(同时,出于某种原因,DE 的正常恢复功能不起作用,或者驱动器无法响应),那么,该驱动器将变得毫无用处,您的数据将会丢失,此时您需要购买一个新的 Opal 驱动器。如果驱动器确实支持 PSID 还原,则可以将其还原为默认的出厂状态,在此过程中您甚至不需要先解锁驱动器,但该驱动器上的所有数据都将丢失。可以使用工具来执行此操作(这不是 DE 中的支持用例)。
如果出现物理硬件故障,并且 Opal 驱动器停止响应解锁请求,那么会发生什么情况?
在此情况下,驱动器将完全失去作用。无论采取何种方法,您都无法访问数据。考虑一下数据丢失的问题,并购买一个新的 Opal 驱动器。这是因为 DE 不知道实际的磁盘加密密钥;无法从驱动器中读取磁盘加密密钥。
是否可以在 Opal 驱动器上使用软件加密?
可以。在启用 Opal 驱动器的本机锁定机制之前,Opal 驱动器的响应和行为方式与普通 HDD 完全相同。没有什么可以阻止管理员改为使用软件加密来为驱动器加密,而不再使用 Opal 驱动器的本机功能。从技术上讲,随后数据将加密两次;第一次由软件加密执行,第二次由 Opal 驱动器执行,但由于驱动器不会锁定,Opal 加密是透明的。
Opal 的预引导与软件加密的预引导是否不同?
答案不确定。要使操作系统能够引导,预引导需要知道如何解锁 Opal 驱动器,但在其他方面,预引导的表现形式和行为与软件加密相同。事实上,许多的预引导代码是在软件和 Opal 预引导应用程序之间共享的。
Opal 标准存在多个版本吗?
是。当前实施的版本是 1.0。TCG 同时已发布 2.0。对 TCG Opal v2.0 规范的支持正在考虑中,可能会包含在将来的版本中。
Opal 驱动器是否存在用户的概念?
是。锁定驱动器后,需要使用用户名和 PIN 来解锁驱动器。
用户保留在哪个位置?
对于每个 Opal 驱动器,每个用户都是特定的,并且是该驱动器的本地用户。管理 Opal 驱动器的应用程序还必须管理 Opal 用户。
Opal 用户是否与 DE 用户或 Windows 域用户相同?
否。所有三种用户都是完全不同的实体。
DE 是否为我处理所有必要的管理任务?
是。
Opal 用户数是否有上限?
是。只能向单个 Opal 驱动器分配少量 Opal 用户。不同制造商提供的 Opal 驱动器所支持的最大用户数各不相同。
如果要将更多的 DE 用户分配到某个设备,以致超出了支持的 Opal 用户数,那么会发生什么情况?
DE 体系结构允许您将任意数量的用户分配到 Opal 驱动器,而不管设备上的 Opal 用户数存在何种技术限制。管理员看不到这种复杂性,他们可以像使用普通 HDD 时那样将用户分配到设备。不管使用何种类型的硬盘驱动器,有关可分配到设备的用户数的建议和限制都保持不变。
一个 Opal 驱动器是否可以包含多个磁盘加密密钥?
可以。Opal 规范中有一个部分介绍了逻辑块寻址 (LBA),也可以称为“本地范围”。
什么是“全局范围”?
全局范围包含磁盘中不在定义的本地范围内的所有扇区(参阅下文)。
什么是“本地范围”?
本地范围是连续的扇区范围,其中的每个扇区都有一个不同的加密密钥。可以锁定这些范围,也可以将其保持为解锁状态。例如,可以向分区应用本地范围,但是,范围不一定会准确地映射到分区。
为何需要使用本地范围?
这样可以确保磁盘的特定部分始终可用并可访问,而不管该磁盘是处于锁定状态还是解锁状态。
如果本地范围是连续的扇区范围,当我定义新范围时,会发生什么情况?
将为新范围自动生成新的加密密钥。如果 Opal 驱动器支持重新加密,则会使用旧密钥解密数据,然后使用新密钥重新加密数据。重新加密是标准的可选部分,目前我们认为没有任何驱动器支持该功能。如果驱动器不支持重新加密,则您会丢失之前在该范围中的所有数据,因为这些数据已通过加密方式清除。
如果使用分区工具并且使用了本地范围,是否可能会丢失所有数据?
是,存在这种可能性。
可以存在多少个本地范围?
Opal 标准规定至少要有五个范围(包括全局范围)。
DE 是否支持使用本地范围来指定分区是否已锁定?
不支持。
DE 是否支持装有 Opal 驱动器的 S3?
支持。
什么是 S3?
S3 是一种电源状态,通常称为“待机”、“休眠”或“RAM 挂起”。处于 S3 状态的系统看上去像是已关闭。CPU 处于断电状态,RAM 处于慢速刷新模式,电源处于节能模式。
Opal 驱动器在断电时将会锁定,这会是个问题吗?
是。当驱动器被锁定时,很难重新启动 Windows,并且 Windows 没有办法解锁。对于 S3 问题,TCG 未提供已达成共识的解决方案。
S3 适用于 DE,它是否为 S3 支持的专有实施方案?
是。
如果我在一台计算机中同时使用 Opal 和普通 HDD,会发生什么情况?DE 是否会在 Opal 驱动器上使用本机 Opal 功能,并为普通 HDD 使用软件加密?
不会。这就是所谓的混合模式环境。DE 需要决定如何在计算机上实施加密策略。
DE 是否支持混合模式?
支持。混合模式定义为这样一种情况:计算机包含多个物理 HDD 驱动器,同时还包含 Opal 驱动器和普通 HDD 的组合。但至少有一个共同点,那就是始终是软件加密。如果有疑问,将使用软件加密功能来加密 Opal 驱动器和普通 HDD。
DE 是否支持在配备 Intel CPU 的 Mac 硬件上使用 Windows 操作系统?
不支持。DE 在任何 Mac 硬件上均不受支持。要在 Macintosh 硬件上获得支持,请安装最新版本的 Management of Native Encryption。