写点什么

HubSpot 采用规则引擎架构对 JITA 授权机制进行了重新设计

作者: Leela Kumili
  • 2026-08-10
    北京
  • 本文字数:1300 字

    阅读完需:约 4 分钟

为了增强访问决策的可观测性和可解释性,HubSpot 利用规则引擎架构重新设计了其即时访问(JITA)授权系统。该系统通过独立的规则而非嵌入式的条件逻辑来评估临时访问请求,使工程师能够检查各项策略对访问决策的影响,并在授权要求发生变化时进行管理。

HubSpot 的 JITA 系统每个工作日处理约 5500 次访问请求,服务于约 10000 名员工。随着新访问场景的引入,之前的实现方案越来越依赖日益复杂的条件逻辑。虽然这种方法能够满足现有的需求,但工程师们难以确定请求被批准或拒绝的原因,也难以识别具体是哪些检查导致了处理延迟。

重新设计后的架构引入了规则引擎,其中的授权策略作为独立的规则,通过有向无环图(DAG)进行组织和评估。每条规则都会生成结构化的输出,其中包含评估结果、执行时间以及用于理解授权决策的元数据。

一个经过简化的、基于角色的分支和并行规则评估 DAG (图片来源: HubSpot 博客

在重新设计的过程中,HubSpot 工程师们将“决策透明度”定义为一项关键要求。该团队将这一挑战描述为:不仅要确认授权系统是否正常运行,更要理解单个决策背后的推理过程。

问题不仅仅在于“这能否正常运行?”

而是“我们能否随时向任何人解释该系统做出的每一个决策?”

该架构通过一个通用的上下文对象,将共享的请求数据与单个的授权规则相分离。在评估之前,系统会收集用户属性、团队信息和请求详情,并在执行过程中将这些信息传递给规则。这种方法减少了重复的数据检索,并在各项授权检查中提供了统一的数据输入。

该系统还在规则层面引入了可观测性。工程师不仅能够度量整体的授权请求,还可以检查单个规则的执行时间、失败情况和执行结果。这有助于发现评估速度较慢的情况,并了解特定策略对授权处理的影响。

HubSpot 采用隔离的规则执行机制来处理评估过程中的失败情况。如果某条规则因依赖项不可用或出现意外情况而发生错误,系统就会记录该失败,同时继续评估其他规则。访问决策仍然依赖根据授权规则定义的结果。

迁移过程涉及让旧版和新版授权系统并行运行,并在将生产环境的授权请求路由至新系统之前,对决策结果进行对比。此外,该团队还引入了由安全、产品和运维相关方参与的定期审查,以便评估规则的范围是否依然恰当,以及是否与访问请求一致。

再认证仪表盘显示了每条规则的使用指标和执行统计数据(图片来源:HubSpot 博文

行业里涌现出了类似的解决方案,尽管具体的实现方式会因所管理的访问类型而存在一些差异。Open Policy Agent(OPA)提供了一种“策略即代码”模型,通过专用的策略引擎将授权决策与应用逻辑分离。谷歌云的 Privileged Access Manager 则侧重于通过审批工作流和审计追踪来临时激活云端特权权限。微软的 Entra Privileged Identity Management 同样是管理特权角色的“即时激活”(JITA)。这些系统侧重于声明式策略或身份治理,而 HubSpot 的实现方案则专注于特定于应用程序的访问工作流,并具备规则级的执行可见性。

通过引入规则引擎、结构化决策元数据和治理流程,HubSpot 已经将 JITA 授权从嵌入式条件逻辑转变为一个能够随时间推移对访问决策进行评估、监控和审查的系统。

原文链接:https://www.infoq.com/news/2026/08/hubspot-jita-rule-engine/