集中式授权的优势：为什么要选择 Centralizing Authorization

The Case for Centralizing Authorization

Source | HN Comments

文章探讨了集中式授权的优势。集中式授权能统一标准化能力、降低成本、统一应用治理。虽然面临表达性、性能、隔离和集成等挑战，但通过使用如 Topaz 等开源或商业系统，可以克服这些阻力。集中式授权可实现组织策略和应用程序特定权限的统一管理，并提供多租户、高性能和易于集成的解决方案，是未来授权的发展趋势。

The Case for Centralizing Authorization

2025年1月9日 Omri Gazitt avatar Omri Gazitt Authorization centralizing authorization

介绍

授权是每个业务应用的关键组成部分。如果授权系统宕机，应用程序也会宕机，因此它必须以非常高的可用性运行。它还需要正确评估每个决策，否则可能会导致权限提升或信息泄露漏洞。最后，它必须以非常低的延迟运行，因为授权是每个应用程序请求的关键路径。

身份和访问管理（IAM）长期以来被认为是一种“工作负载”，因为组织必须全面考虑它，并拥有专门的团队来确保全天候运营。从传统的系统（如 Active Directory）到现代的系统（如 Okta），大多数组织都有一个专门的团队来管理集中的身份平台。

但是，授权往往是特定于应用程序的，并且对授权的延迟要求非常严格，以至于许多组织认为他们别无选择，只能将授权留给每个应用程序或微服务，而不是尝试运行共享的授权服务。换句话说，如今的授权非常分散且定制化。

在本文中，我们将描述集中式授权系统的优势，并探讨此类系统必须满足的功能、性能、隔离和集成要求。

集中化的好处

几十年来，组织内部一直存在一种紧张关系，即每个业务线都拥有自己的技术堆栈，还是拥有一个由 IT 代表多个团队管理的集中式共享平台。

集中化带来了一些明显的优势：

在整个企业中标准化能力 - 无需每个业务部门或应用程序开发重复的能力或技能。
通过建立共享平台来降低成本 - 在使用该平台的所有应用程序中分摊构建和运营平台的成本。
以统一的方式应用治理、风险和合规性 - 使企业更容易整体管理这些方面。

几十年来，集中化一直在向上发展。一些明显的例子包括：

1990 年代：共享数据中心为所有业务线提供“ping, power, pipe”。
2000 年代：共享基础设施上的虚拟机，而不是每个应用程序都采购自己的硬件。
2010 年代：共享云平台和 Kubernetes 集群，用于在同一云基础设施上运行多个应用程序。
2020 年代：平台服务团队提供日志记录、监控、源代码控制和 CI/CD 功能，这些功能在许多应用程序团队之间共享。

身份和访问中的集中化

集中式 IAM 并不是一个新概念。在 2000 年代，IT 部门负责为组织运行 LDAP 或 Active Directory。在过去的十年中，随着身份转移到云端，IT 部门将其专业知识转移到运营云身份平台，如 Okta 和 Entra ID。

同样，应用程序开发人员不会在他们的应用程序中构建自己的身份验证：相反，他们依赖于外部身份验证服务（如 Auth0 或 Clerk），与其员工或客户身份系统联合，以验证用户是否是他们所说的那个人。通过_外部化_ 身份验证，应用程序可以插入通用的组织单点登录服务（如 Okta 或 Entra ID），从而简化了在所有应用程序中配置和取消配置用户的过程。

此外，组织对其用户和组拥有单一的事实来源，并拥有一个单一的平台来管理连接到身份系统的应用程序。最后，他们拥有一个统一的日志和审计系统来记录应用程序登录，这对合规性和取证很有价值。

集中式授权的优势

集中式授权背后的想法并不新鲜。它通常与“外部化”授权的想法齐头并进 - 即将授权从应用程序代码中分解出来，并以其自己的领域特定语言表达它 - 这种做法也称为“策略即代码”。

当应用程序外部化其授权时，访问控制逻辑不再是不透明的；可以统一应用通用的组织策略；可以控制和审计授权策略的更改；并且可以在所有应用程序中统一生成和存储决策日志。

授权作为一项共同责任

与企业中的许多共享能力一样，有两个群体在授权方面拥有利益：应用程序开发人员和中心服务团队。

开发人员关心特定于应用程序的授权逻辑

如引言中所述，授权是特定于应用程序的：每个应用程序都需要定义和强制执行对其管理的资源的一组权限。例如，文档管理系统需要评估用户是否可以查看文档，而候选人跟踪系统需要评估用户是否可以更新职位描述。

如今，这些授权规则大多编码为应用程序逻辑中的“if”和“switch”语句。为了将此逻辑正确地外部化到集中式授权系统，该系统必须足够_富有表现力_以捕获该逻辑，足够_高性能_以在较小的延迟预算内强制执行访问规则，并且_易于与_应用程序_集成_。

IT 部门关心统一应用组织范围的策略

虽然每个应用程序都有特定于域的授权要求，但大多数组织都有全局策略，这些策略对于在每个应用程序中统一强制执行非常重要。中心团队通常负责这项职责。

示例包括：

用户只能从已知设备使用该应用程序
用户必须登录到公司 VPN 才能使用该应用程序
用户不得处于“暂停”状态才能使用该应用程序
承包商只能在工作日的上班时间使用该应用程序
必须持续使用信任信号来评估用户的身份是否已泄露

虽然其中一些策略可以在登录时进行评估和强制执行，但底层条件可能会在应用程序会话的生命周期内发生变化。例如，用户可能会被暂停、切换网络或跨越指定的时段。

由于这些原因，组织范围的策略需要与管理用户是否可以对资源执行操作的特定于应用程序的规则一起实时评估。

集中式授权的阻力

围绕集中式授权的四个主要挑战围绕着_表达性_、性能、隔离_和_集成。

表达性

集中式授权系统的核心是必须促进编写授权规则，以表达组织的策略以及强制执行特定于应用程序的权限。换句话说，组织策略和特定于应用程序的权限的功能要求都必须可以在授权系统中_表达_。

组织策略通常由治理、风险和合规性（GRC）专业人员以自然语言表达，他们通常不是工程师。该策略需要转录为更精确的语言，这通常涉及有关用户的属性（例如，用户的部门或管理级别）；设备（例如，管理状态、设备类型）；或环境（例如，VPN 状态、时区）。基于属性的访问控制（ABAC）语言（如 Rego 或 Cedar）是编写此类策略的最流行方式。

特定于应用程序的授权规则通常侧重于回答问题“此用户是否对此对象具有此权限”。这些规则适合使用_基于关系的访问控制（ReBAC）语言_编写，例如受 Google Zanzibar 系统启发的那些语言。使用这些语言，域模型描述了对象类型；用户可以与对象实例建立的关系（例如，所有者、编辑者、_查看者_等）；以及通过这些关系授予的权限（“can-read”、“can-write”、“can-delete”等）。

可能很明显，这两个群体有不同的要求，因此一个为这两个群体提供服务的集中式授权系统必须足够富有表现力，才能编写_ABAC 规则和 ReBAC 架构_。

性能

授权位于每个应用程序请求的关键路径中，因此必须在几毫秒内执行。这意味着集中式授权系统必须快速执行请求，并且非常靠近应用程序 - 即在同一集群或可用性区域中。

如果授权系统的 P99 延迟为 5 毫秒，但它位于供应商的云基础设施中，距离应用程序 100 毫秒，则没有任何意义。同样，即使是位于同一位置的授权系统，如果必须从外部系统收集满足授权请求所需的数据，也可能不够快，无法足够快地处理授权请求。因此，授权系统既需要_靠近应用程序运行_，又需要_在本地缓存授权状态_。

简而言之，授权是一种延迟敏感型工作负载，通常需要以低延迟为每个应用程序提供每秒 100 个或 1000 个请求。对于自制系统来说，这可能是一项艰巨的任务。

隔离

支持许多应用程序的集中式授权服务必须为它支持的每个应用程序提供策略和数据的隔离。因此，该服务必须本质上是_多租户_的。即使该服务仅用于组织的面向客户的 B2B SaaS 应用程序，也可能需要甚至要求为每个客户组织进行租户隔离。

集成

集成外部化授权系统有两个主要方面：应用程序如何调用它，以及如何将应用程序和组织数据输入到其中。

为了让应用程序开发人员采用外部化授权系统，从他们的本机语言调用它必须像调用另一个函数或模块一样容易（或更容易）。并且用领域特定语言表达授权规则需要比用他们的本机语言编写“if”或“switch”语句更容易（并且更易于维护）。

此外，当应用程序存储用户和对象之间的关系时（例如，“Alice 拥有文档 1”，“Bob 是文档 1 的查看者”），开发人员必须能够轻松地将这些关系存储在授权系统中。

最后，许多组织策略是围绕用户属性和组成员身份编写的。集中式授权系统需要轻松地从身份平台导入这些属性和成员身份，以便它可以对本地数据执行授权规则。如性能部分所述，如果不将授权数据存储在本地，授权系统将难以满足其调用应用程序的延迟和可用性要求。

克服阻力

虽然集中式授权系统的要求似乎令人生畏，但好消息是有开源和商业系统可以帮助您穿针引线并满足所有这些要求。

表达性

推出集中式授权系统的一个关键理由是能够表达和强制执行组织策略。但是，如果不让应用程序开发人员采用集中式授权系统来执行特定于应用程序的授权规则，则对组织的价值是有限的。

因此，集中式授权系统必须支持编写_ABAC 和 ReBAC 风格的授权规则_，并且能够将它们组合成一个策略。

一种方法是为每个要求选择不同的开源项目，例如 OPA 和 OpenFGA，并让 OPA 策略在策略评估期间调用 OpenFGA 端点。

一种更紧凑和高性能的方法是使用 Topaz 开源授权器来增强具有本机内置 ReBAC 功能的 OPA ABAC 风格策略，针对嵌入式数据库执行。拥有一个可以同时执行这两种操作的平台在优化性能方面起着巨大的作用，接下来将对此进行讨论。

性能

授权是一项性能关键型工作负载：授权请求必须在几毫秒内完成，并且大型 B2B SaaS 应用程序的授权吞吐量必须扩展到每秒 1000 个请求。如果许多应用程序共享该服务，则此数字可能会上升到 100K RPS 或更多。

因此，集中式授权系统必须_水平扩展_ - 添加更多授权器实例应线性扩展系统的授权吞吐量。

跨多个应用程序共享的集中式服务可能对每个应用程序有不同的性能要求。某些应用程序可能对延迟非常敏感，以至于它们无法冒险让“嘈杂的邻居”影响授权延迟。对于那些延迟敏感型应用程序，需要提供专用的授权器作为部署选项，而不会牺牲集中式服务的好处。

对于合理的策略、ReBAC 架构和数据大小，像 Topaz 这样的单租户授权器可以处理大约 1000 RPS 的请求，并且可以以线性方式水平扩展。像 Aserto 这样的商业解决方案提供了一个多租户授权器，可以用于不关心“嘈杂邻居”的应用程序，并用专用于延迟敏感型应用程序的授权器来增强它。

隔离

多租户是集中式授权服务的核心要求。虽然有许多可用于单租户授权器的开源选项，但多租户往往是商业解决方案的领域，这些解决方案构建在这些开源平台之上。

Aserto 构建了一个围绕 Topaz 开源授权器的_完整多租户解决方案_，包括多租户目录、授权器、发现服务和控制平面。每个租户的状态都位于自己的 Postgres 架构中，因此来自不同租户的数据不会混合在一起。每个租户都有自己的 ReBAC 架构和策略，支持应用程序之间的完全隔离。

这比运营每个应用程序的离散授权服务要简单得多。

集成

只有当组织的自制应用程序将其用作标准功能时，集中式授权服务才值得运营。反过来，只有当开发人员可以轻松地定位它时，才会发生这种情况。

幸运的是，大多数开源授权平台都有语言 SDK 和 API。例如，Topaz 和 Aserto 有一组用于 Typescript/Node、Python、Java、.NET、Go 和 Ruby 的语言 SDK，以及 REST 和 gRPC API。这使得 Topaz 易于集成到各种应用程序中。

此外，Topaz 易于在 API 网关级别集成，这可能是为不值得重新平台的遗留应用程序提供现代访问控制的唯一实用方法。

像 Topaz 这样的有状态授权系统还提供本机 API 和 SDK 支持，用于管理存储在系统内的对象和关系。身份和组成员身份数据对于授权系统尤其重要，Topaz 依赖于一个名为 ds-load 的开源 ETL 工具链，用于从各种身份平台（如 Okta、Entra ID、LDAP、Cognito、Google Workforce、Auth0 和 FusionAuth）导入用户、属性和组。

最后，保持用户和组成员身份与事实来源系统同步是一个至关重要的集成问题。SCIM 为此问题提供了一个成熟的解决方案，Aserto 提供了与许多支持它的源的 SCIM 集成。

结论

多年来，我们已经看到了一种不可阻挡的趋势，即集中化可以在整个组织中共享的功能。VM、云计算、Kubernetes 集群、身份平台、源代码控制、日志记录、监控和 CI/CD 都是此模式的示例。

集中式授权是下一个趋势。对组织的价值非常重要：可以通过标准方式实施跨各种应用程序的授权，从而降低建立离散系统的成本，并允许企业跨应用程序全面执行治理、风险和合规性职能。

集中式授权的阻力围绕着表达性、性能、隔离和集成。它们可能感觉很重要，但幸运的是，一组新的平台正在出现，以解决这些挑战。Aserto 提供了领先的现代授权平台之一，评估它应该在您的技术路线图上。

要了解我们如何帮助您集中授权，请在此处与我们联系，或设置通话！

Omri Gazitt avatar Omri Gazitt Aserto 的首席执行官

保持知情订阅加入讨论与工程师交谈

集中式授权的优势：为什么要选择 Centralizing Authorization

The Case for Centralizing Authorization

介绍

集中化的好处

身份和访问中的集中化

集中式授权的优势

授权作为一项共同责任

开发人员关心特定于应用程序的授权逻辑

IT 部门关心统一应用组织范围的策略

集中式授权的阻力

表达性

性能

隔离

集成

克服阻力

表达性

性能

隔离

集成

结论

相关内容

注册我们的时事通讯