Credential Guard 的工作原理
Kerberos、NTLM 和凭据管理器使用基于虚拟化的安全性 (VBS) 隔离机密。 以前版本的 Windows 将机密存储在其进程内存中,本地安全机构 (LSA) 进程 lsass.exe
。 启用 Credential Guard 后,操作系统中的 LSA 进程会与名为 独立 LSA 进程的 组件通信, LSAIso.exe
该进程存储和保护这些机密。 独立 LSA 进程存储的数据使用 VBS 进行保护,操作系统的其余部分无法访问。 LSA 使用远程过程调用来与隔离的 LSA 进程进行通信。
出于安全原因,隔离的 LSA 进程不会托管任何设备驱动程序。 相反,它仅托管安全性所需的操作系统二进制文件的较小子集。 所有二进制文件都使用 VBS 信任的证书进行签名,并在受保护的环境中启动文件之前验证签名。
下面是有关如何使用基于虚拟化的安全性隔离 LSA 的高级概述:
Credential Guard 保护限制
某些存储凭据的方式不受 Credential Guard 的保护,包括:
- 在 Windows 功能保护之外管理凭据的软件
- 本地帐户和 Microsoft 帐户
- Credential Guard 不会保护在 Windows Server 域控制器上运行的 Active Directory 数据库。 它也不会保护凭据输入管道,例如运行远程桌面网关的 Windows Server。 如果将 Windows Server OS 用作客户端电脑,它将获得与运行 Windows 客户端 OS 时相同的保护
- 键记录器
- 物理攻击
- 不会阻止电脑上具有恶意软件的攻击者使用与任何凭据关联的特权。 建议将专用电脑用于高价值帐户,例如 IT 专业人员和有权访问组织中高价值资产的用户
- 非 Microsoft 安全包
- 启用 Credential Guard 后,NTLMv1、MS-CHAPv2、Digest 和 CredSSP 无法使用登录凭据。 因此,单一登录不适用于这些协议。 但是,应用程序可以提示输入凭据或使用存储在 Windows 保管库中的凭据,这些凭据不受 Credential Guard 保护,这些协议中的任何一种都不受 Credential Guard 保护
注意
建议不要将有价值的凭据(例如登录凭据)与 NTLMv1、MS-CHAPv2、Digest 或 CredSSP 协议一起使用。 如果域或Microsoft Entra用户必须使用这些协议,则应为这些用例预配辅助凭据。
- 为 NTLM 身份验证提供的凭据不受保护。 如果用户收到要进行 NTLM 身份验证的提示并输入了凭据,这些凭据很容易从 LSASS 内存中读取。 这些相同的凭据也容易受到密钥记录器攻击
- Kerberos 服务票证不受 Credential Guard 保护,但 Kerberos 票证授予票证 (TGT) 受到保护
- 启用 Credential Guard 后,Kerberos 不允许 不受约束的 Kerberos 委派 或 DES 加密,不仅允许登录凭据,还允许提示或保存的凭据
- 在 VM 上启用 Credential Guard 时,它会保护机密免受 VM 内部的攻击。 但是,它不提供保护,免受源自主机的特权系统攻击
- Windows 登录缓存的密码验证程序 (通常称为 缓存凭据) 不能作为凭据,因为它们无法提供给另一台计算机进行身份验证,并且只能用于本地验证凭据。 它们存储在本地计算机上的注册表中,并在用户登录期间已加入域的计算机无法连接到 AD DS 时提供凭据验证。 可以使用安全策略设置“交互式登录”来管理这些缓存登录,或者更具体地说,缓存帐户信息:如果域控制器不可用,则缓存的以前登录次数
后续步骤
- 了解如何配置 Credential Guard
- 在 其他缓解 措施一文中查看有关使用 Credential Guard 使环境更安全、更可靠的建议和示例代码
- 查看 使用 Credential Guard 时的注意事项和已知问题
反馈
https://aka.ms/ContentUserFeedback。
即将发布:在整个 2024 年,我们将逐步淘汰作为内容反馈机制的“GitHub 问题”,并将其取代为新的反馈系统。 有关详细信息,请参阅:提交和查看相关反馈