您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

使用 Azure Active Directory 满足 NIST 验证器保证等级 3 要求

本文将帮助你满足美国国家标准与技术研究院验证器保证等级 (NIST AAL) 3 要求。 在尝试满足 AAL3 要求之前,你可能需要查看这些资源:

允许的验证器类型

Microsoft 提供的身份验证方法有助于满足所需的 NIST 验证器类型要求。 本部分提供 Microsoft 建议。

Azure AD 身份验证方法 NIST 验证器类型
推荐的方法
FIDO2 安全密钥

智能卡(Active Directory 联合身份验证服务 [AD FS])

带硬件 TPM 的 Windows Hello 企业版
多重加密硬件
其他方法
密码

(已联接硬件 TPM 的混合 Azure AD

已联接硬件 TPM 的 Azure AD)
记住的密码

单因素加密硬件
密码

单因素一次性密码硬件(来自 OTP 制造商)

(已联接软件 TPM 的混合 Azure AD

已联接软件 TPM 的 Azure AD

兼容的托管设备)
记住的密码

单因素一次性密码硬件

单因素加密软件

我们的建议

建议使用多重加密硬件验证器来满足 AAL3 要求。 无密码身份验证消除了最大的攻击面(密码),并为用户提供了一种简化的身份验证方法。 如果你的组织完全基于云,建议使用 FIDO2 安全密钥。

请注意,Windows Hello 企业版尚未在所需的 FIPS 140 安全级别进行验证,因此,在认可其达到 AAL3 之前,联邦客户需要进行风险评估和评价。 .

有关详细指南,请参阅在 Azure Active Directory 中规划无密码身份验证部署

有关实施 Windows Hello 企业版的详细信息,请参阅 Windows Hello 企业版部署指南

FIPS 140 验证

验证程序要求

Azure AD 会使用经过验证且总体达到 Windows FIPS 140 级别 1 的加密
‎模块来执行其所有与身份验证相关的加密操作。 因此,该验证程序符合 FIPS 140 标准。

验证器要求

单因素和多重加密硬件验证器需要满足不同的验证器要求。

单因素加密硬件验证器需要满足以下要求:

  • 整体达到 FIPS 140 级别 1(或更高)。

  • 物理安全性达到 FIPS 140 级别 3(或更高)。

Azure AD 联接和混合 Azure AD 联接设备在下列情况中满足此要求:

咨询移动设备供应商,了解你的供应商是否符合 FIPS 140 要求。

多重加密硬件验证器需要满足以下要求:

  • 整体达到 FIPS 140 级别 2(或更高)。

  • 物理安全性达到 FIPS 140 级别 3(或更高)。

FIDO2 安全密钥、智能卡和 Windows Hello 企业版有助于满足这些要求。

  • FIDO2 密钥提供程序处于 FIPS 认证的不同阶段,其中包括已完成验证的一些程序。 建议查看支持的 FIDO2 密钥供应商列表,并向提供商咨询当前的 FIPS 验证状态。

  • 智能卡是已证实的技术。 多个供应商产品满足 FIPS 要求。

Windows Hello for Business

FIPS 140 要求包括软件、固件和硬件在内的整个加密边界都在评估范围之内。 Windows 操作系统是开放式计算平台,可以与数千个硬件组合配对。 Microsoft 无法为每个组合维护 FIPS 认证。 在将 Windows Hello 企业版用作 AAL3 验证器的风险评估中,应评估以下组件的各个认证:

重新身份验证

对于 AAL3 级别,NIST 要求无论用户是否处于活动状态,均需每 12 小时重新进行身份验证。 在持续 15 分钟或更长时间内处于非活动状态时也需要重新进行身份验证。 满足这两个因素,即需重新进行身份验证。

为了满足不考虑用户活动而重新进行身份验证的要求,Microsoft 建议将用户登录频率配置为 12 小时。

NIST 还允许使用补偿控制来确认订阅者的状态:

  • 可以通过在 OS 级别锁定设备,将会话非活动超时设置为 15 分钟。 可以通过使用 Microsoft Endpoint Configuration Manager、组策略对象 (GPO) 或 Intune 来执行此操作。 还需要进行本地身份验证,订阅者才能将其解锁。

  • (利用 Configuration Manager、GPO 或 Intune)运行计划任务,在 12 小时后锁定计算机(无论用户是否处于活动状态),从而实现与活动状态无关的超时。

抵御中间人攻击

请求方和 Azure AD 之间的所有通信均通过经身份验证的受保护通道进行,以抵御中间人 (MitM) 攻击。 此配置满足 AAL1、AAL2 和 AAL3 对抵御 MitM 攻击的要求。

验证程序模拟抵抗

所有满足 AAL3 的 Azure AD 身份验证方法均利用加密验证器,将验证器输出与正在进行身份验证的特定会话绑定。 这些验证器通过使用由请求方控制的私钥来执行上述操作,而其公钥已为验证程序所知。 此配置满足 AAL3 对验证程序模拟抵抗的要求。

验证程序泄露抵抗

所有满足 AAL3 的 Azure AD 身份验证方法均执行以下操作之一:

  • 使用加密验证器(要求验证程序存储与验证器所持有的私钥相对应的公钥)。
  • 使用经 FIPS 140 验证的哈希算法存储所需的验证器输出。

有关详细信息,请参阅 Azure AD 数据安全注意事项

重放抵抗

所有满足 AAL3 的 Azure AD 身份验证方法均使用 nonce 或质询。 这些方法可以抵御重放攻击,因为验证程序可轻松检测重放的身份验证事务。 此类事务不包含相应的 nonce 或及时性数据。

身份验证意向

身份验证意向旨在达成如下目标:在主体不知情的情况下,更加难以使用直接连接的物理验证器(如多重加密设备)。 例如,终结点上的恶意软件。

NIST 允许使用补偿控制以缓解恶意软件风险。 运行 Windows Defender 系统防护和 Windows Defender ATP 的所有 Intune 兼容设备都满足此风险缓解要求。

后续步骤

NIST 概述

了解 AAL

身份验证基础知识

NIST 验证器类型

使用 Azure AD 满足 NIST AAL1 要求

使用 Azure AD 满足 NIST AAL2 要求