通过开发人员最佳做法实现复原能力
在本文中,我们将根据与大客户合作的经验来开展学习。 你可以在服务的设计和实现中考虑这些建议。
Microsoft 身份验证库
Microsoft 身份验证库 (MSAL) 和适用于 ASP.NET 的 Microsoft 标识 Web 身份验证库简化了应用程序所需令牌的获取、管理、缓存和刷新。 这些库经过优化,可支持 Microsoft 标识,其中包括可改进应用程序复原能力的功能。
开发人员可以采用最新版本的 MSAL 并了解最新信息。 请参阅如何提高应用程序中身份验证和授权的复原能力。 如果可能,请避免实现自己的身份验证堆栈。 请改用完善的库。
优化目录读取和写入
Azure AD B2C 目录服务支持一天进行数十亿次身份验证,每秒读取率很高。 优化写入以最大程度地减少依赖关系并提高复原能力。
如何优化目录读取和写入
避免在登录时将函数写入目录:避免在自定义策略中没有先决条件(if 子句)的情况下在登录时执行写入操作。 需要进行登录时写入的一个用例是用户密码的实时迁移。 无需在每次执行时都执行写入操作。 用户旅程中的先决条件包括:
<Precondition Type="ClaimEquals" ExecuteActionsIf="true"> <Value>requiresMigration</Value> ... <Precondition/>
了解限制:目录实现应用程序和租户级限制规则。 对于读取 (/GET)、写入 (/POST)、更新 (/PUT) 和删除 (/DELETE) 操作,存在更多速率限制。 每个操作都有不同的限制。
- 如要在登录期间执行写入,对于新用户,此操作属于 POST,对于当前用户,此操作属于 PUT。
- 在每次登录时创建或更新用户的自定义策略会达到应用程序级别 PUT 或 POST 速率限制。 通过 Microsoft Entra ID 或 Microsoft Graph 更新目录对象时,会应用相同的限制。 同样,检查读取以使每次登录时的读取次数保持最少。
- 估计峰值负载以预测目录写入速率并避免限制。 峰值流量估计应包括对诸如注册、登录和多重身份验证 (MFA) 等操作的估计。 针对峰值流量测试 Azure AD B2C 系统和应用程序。 Azure AD B2C 可以不受限制地处理负载,而下游应用程序或服务无法这样做。
- 了解并规划迁移时间线。 当计划使用 Microsoft Graph 将用户迁移到 Azure AD B2C 时,请考虑应用程序和租户限制以计算完成用户迁移所需的时间。 如果使用两个应用程序拆分用户创建作业或脚本,则可以使用每个应用程序限制。 确保其保持在每个租户的阈值以下。
- 了解迁移作业对其他应用程序的影响。 考虑由其他依赖应用程序提供的实时流量,以确保不会在租户级别造成限制,并且不会导致实时应用程序资源不足。 有关详细信息,请参阅 Microsoft Graph 限制指导。
- 使用负载测试示例模拟注册和登录。
- 详细了解 Azure Active Directory B2C 服务限制和局限性。
令牌生存期
如果 Azure AD B2C 身份验证服务无法完成新的注册和登录,请为已登录的用户提供缓解措施。 根据配置,已登录的用户可以不间断地使用该应用程序,直到他们从应用程序中注销或会话因不活动而超时。
业务要求和最终用户体验决定了 Web 和单页应用程序 (SPA) 的令牌刷新频率。
延长令牌生存期
- Web 应用程序:对于在登录时验证身份验证令牌的 Web 应用程序,应用程序依赖于会话 Cookie 来继续扩展会话有效性。 通过实现基于用户活动更新的滚动会话时间,使用户保持登录状态。 如果存在长期令牌颁发中断,则这些会话时间可以作为应用程序中的一次性配置而增加。 使会话的生存期保持为允许的最大值。
- SPA:SPA 可能依赖于访问令牌来调用 API。 对于 SPA,我们建议结合使用授权代码流以及用于代码交换的证明密钥 (PKCE) 流作为选项,以允许用户继续使用应用程序。 如果 SPA 当前正在使用隐式流,请考虑迁移到使用 PKCE 的授权代码流。 将应用程序从 MSAL.js 1.x 迁移到 MSAL.js 2.x 以实现 Web 应用程序的复原能力。 隐式流不会导致系统刷新令牌。 如果浏览器与 Azure AD B2C 有活动会话,则 SPA 可以使用隐藏
iframe
对授权端点执行新的令牌请求。 对于 SPA,有几个选项可以允许用户继续使用该应用程序。- 延长访问令牌的有效时长。
- 构建应用程序,以使用 API 网关作为身份验证代理。 在此配置中,SPA 加载时不进行身份验证,会对 API 网关进行 API 调用。 API 网关使用基于策略的授权代码授予,通过登录过程发送用户,并对用户进行身份验证。 使用身份验证 Cookie 维护 API 网关与客户端之间的身份验证会话。 API 网关使用通过 API 网关获取的令牌或其他直接身份验证方法(例如证书、客户端凭据或 API 密钥)为 API 提供服务。
- 切换到建议的选项。 借助用于代码交换的证明密钥 (PKCE) 和跨域资源共享 (CORS) 支持,将 SPA 从隐式授予迁移到授权代码授予流。
- 对于移动应用程序,请延长刷新和访问令牌生存期。
- 后端或微服务应用程序:后端(守护程序)应用程序是非交互式的,并且不在用户环境中,因此令牌被盗的可能性较小。 建议在安全性与生存期之间取得平衡,并设置较长的令牌生存期。
单一登录
使用单一登录 (SSO),用户只需用帐户登录一次,就能访问应用程序:无论是 Web、移动应用还是单页应用程序 (SPA),不受平台或域名的限制。 当用户登录到应用程序时,Azure AD B2C 会保留一个基于 Cookie 的会话。
收到后续的身份验证请求后,Azure AD B2C 会读取并验证该基于 Cookie 的会话,然后颁发访问令牌,且不提示用户登录。 如果在策略或应用程序中将 SSO 配置为有限的范围,那么以后访问其他策略和应用程序时将需要全新的身份验证。
配置 SSO
将 SSO 配置为租户范围(默认),以允许租户中的多个应用程序和用户流共享相同的用户会话。 租户范围的配置为全新身份验证提供最大的复原能力。
安全部署实践
最常见的服务中断是代码和配置更改。 采用持续集成和持续交付 (CICD) 流程和工具可以实现大规模部署并减少测试和部署过程中的人为错误。 采用 CICD 来减少错误,提高效率和一致性。 Azure Pipelines 是 CICD 的一个示例。
防范机器人攻击
保护应用程序免受已知漏洞的侵害,例如分布式拒绝服务 (DDoS) 攻击、SQL 注入、跨站点脚本、远程代码执行以及 OWASP Top-10 中记录的其他漏洞。 部署 Web 应用程序防火墙 (WAF) 来防御常见的漏洞和弱点。
- 使用 Azure WAF,它提供集中式保护来防范攻击。
- 在使用 Azure AD B2C 时,将 WAF 与 Microsoft Entra 的可提供多层保护的标识保护和条件访问配合使用。
- 通过与 CAPTCHA 系统集成来抵御机器人驱动的注册。
机密
Azure AD B2C 对应用程序、API、策略和加密使用机密。 机密可保护身份验证、外部交互和存储。 国家标准与技术研究所 (NIST) 将合法实体使用的密钥授权的时间范围称为加密周期。 选择所需的加密周期长度。 设置过期时间,并在机密过期前进行轮换。
实现机密轮换
- 使用受支持资源的托管标识向支持 Microsoft Entra 身份验证的任何服务进行身份验证。 使用托管标识时,可以自动管理资源,包括凭据轮换。
- 清点 Azure AD B2C 中配置的密钥和证书。 此列表可以包括自定义策略、API、签名 ID 令牌和安全断言标记语言 (SAML) 证书中使用的密钥。
- 使用 CICD,可轮换将在预期峰值期两个月内到期的机密。 与证书关联的私钥的建议最大加密期为一年。
- 监视和轮换 API 访问凭据,如密码和证书。
REST API 测试
为了确保复原能力,REST API 测试需要包括 HTTP 代码、响应负载、标头和性能的验证。 不要只使用顺畅路径测试,并确认 API 能够从容地处理问题场景。
测试计划
建议测试计划包括综合 API 测试。 对于促销或节假日流量导致的激增,请使用新的估算值修改负载测试。 在开发人员环境(而不是生产环境)中进行 API 负载测试和内容分发网络 (CDN)。