服务台面临的一个持续挑战是验证寻求帮助的来电者的身份,尤其是在通过电话、聊天或电子邮件进行远程交互时。 传统的方法(如个人身份信息(PII)和基于知识的身份验证与当今复杂的攻击者不匹配,他们使用网络钓鱼、社会工程甚至 AI 支持的语音克隆来绕过防御。 后果严重:在压力下,支持人员代理可能会无意中公开敏感数据或授权欺诈行为。
前进方向:更强和防钓鱼身份验证 为了抵御这些不断演变的威胁而不损害用户体验,组织必须采用为当今威胁格局构建的新式验证策略。 这包括:
- 防钓鱼身份验证(例如密钥)
- AI 驱动的欺诈检测以标记异常行为
- 零信任原则强制实施严格的标识检查
- 企业级标识验证 - 无需依赖于 PII。
Microsoft提供了解决方案,使管理员能够在不牺牲用户体验的情况下增强安全性。 组织可以采用两个关键模式:
- 强身份验证:用户在请求支持人员之前使用其现有公司凭据进行身份验证。 在向用户授予对资源的访问权限之前,系统会提示用户提供强防钓鱼凭据。 Microsoft平台提供了 Azure 通信服务等解决方案,这些解决方案支持向所有应用程序添加语音、视频、聊天、短信/短信、电子邮件等多通道通信 API。 Azure 通信服务(ACS) 支持安全模式,用户通过 ACS 集成的应用访问 URL 来启动与支持人员直接加密的语音/视频/聊天会话。 身份验证使用 Microsoft Entra ID 进行管理,安全 ACS 令牌可确保受控访问,防止未经授权的连接。
- 完全丢失恢复:如果用户丢失了所有身份验证凭据,则会实施安全、策略驱动的恢复过程来重新建立访问权限,而不会损害安全性。 Microsoft Entra 验证 ID 可以帮助这些企业将验证流程无缝添加到现有的服务台和服务台操作中。 验证成功后,服务台可以提供密码重置、临时访问通行证 (TAP) 预配、MFA(多重身份验证)加入、以及帐户更新等任务,从而有可能实现自助服务自动化。 本文档介绍如何对总损失恢复方案使用 Microsoft Entra 验证 ID。
何时使用此模式
- 你有一个支持 API 的服务台系统。
- 你的服务台系统允许程序集成查询 Microsoft Entra ID 或任何其他目录服务系统来对用户配置文件进行可靠的匹配和更新。
解决方案
若要部署验证流,企业必须遵循三个主要步骤:
- 在 Microsoft 365 租户中设置 Microsoft Entra 验证 ID,并启用 VerifiedEmployee 凭据以用于颁发。 另外,企业也可以通过与我们的 IDV(身份证明和验证)合作伙伴 https://aka.ms/verifiedidisv 合作,根据身份验证流来颁发验证 ID。
- 向用户颁发验证 ID。
- 将验证流添加到现有服务台解决方案。
设置 Microsoft Entra 验证 ID
若要设置 Microsoft Entra 验证 ID 服务,请按照快速配置 - 为租户设置 Microsoft Entra 验证 ID 中的说明进行操作。 另外,客户可以使用高级设置来设置验证 ID,其中,你作为管理员必须配置 Azure Key Vault、负责注册分散式 ID 并验证你的域。
颁发 VerifiedEmployee 验证 ID 入门
- 在 Microsoft Entra 租户中创建测试用户并上传你自己的照片。
- 转到 MyAccount,以测试用户身份登录,并为用户颁发 VerifiedEmployee 凭据。
首先,通过选择所有用户或特定的用户组来选择谁可以请求颁发验证 ID。 然后,登录到 https://myaccount.microsoft.com 并使用 Microsoft Authenticator 获取刷脸就绪凭据。
将验证流添加到服务台解决方案
企业可以通过以下任一方式设置 Microsoft Entra 验证 ID 集成:
- 将其添加为内联流程(例如服务台 Web 应用中的
Get Verified
按钮),请按照步骤来添加通过刷脸来验证“已验证 ID”的演示请求。 链接 https://aka.ms/verifiedidfacecheck 中提供了步骤 - 设置可以通过
VerifiedEmployee
接受 Microsoft Entra 验证 ID 的专用 Web 应用程序。 使用 GitHub 示例来部署自定义 Web 应用。 选择Deploy to Azure
以部署使用托管标识的 ARM 模板 。
企业可以添加 Webhook,以便通过刷脸 将“验证 ID”验证的响应发送到 ServiceDesk 工具。 你可以参考向 Teams 频道添加 Webhook 的示例。 此 GitHub 示例使用 Azure 应用服务在 Azure 上部署验证 Web 应用。
企业可以添加自助式自动化服务,例如,在成功验证“验证 ID”后生成临时访问通行证并获取来自“验证 ID”的声明。 GitHub 示例解释了此自助式自动化流程。
如果你是 托管服务提供商(MSP) 或 云解决方案提供商(CSP),也可以将此模式添加到现有的 Service Desk 进程。 以内联方式部署验证流或将其部署为自定义 Web 应用程序。 对于演示流,请在有效负载中添加 acceptedissuers 字段,并为你的客户指定分散式标识符 (DID),以通过刷脸验证 VerifiedEmployee。
...
"requestedCredentials": [
{
"type": "VerifiedEmployee",
"acceptedIssuers": [ "<authority1>", "<authority2>", "..." ],
"configuration": {
"validation": {
"allowRevoked": false,
"validateLinkedDomain": true,
"faceCheck": {
"sourcePhotoClaimName": "photo",
"matchConfidenceThreshold": 70
}
}
...
其他资源
- 适用于通用帐户加入的公共体系结构文档:规划 Microsoft Entra 验证 ID 验证解决方案
- Microsoft Entra 验证 ID 刷脸:将刷脸与“验证 ID”配合使用,大规模解锁高保证验证
- Microsoft Entra 验证 ID GitHub 存储库:示例