除非你与世隔绝。如果你从事网络安全工作，你一定听说过 Palo Alto Networks 于 2025 年 7 月底宣布收购 CyberArk 的消息。这一消息如预期般引发了激烈讨论，许多行业领军人物对这笔交易表示悲观，称“PAM已死。Palo Alto 为何要花费$250 亿收购一个日薄西山的架构？”
在这篇文章中，我将论证现实恰恰相反。在云原生发展和智能应用的时代，PAM 从未像现在这样重要。而 PANW 的这一举措正是Nikesh Arora几年前启动的“平台化”战略的逻辑延伸。让我们首先分析 PANW 的战略，以及为何这一举措对他们而言如此明智。
Palo Alto Networks 及其平台化战略
没有一家网络安全公司一开始就是平台。相反，它们是通过与环境共同演进和成长，逐步赢得这一称号的。CyberArk 和 PANW 都是各自领域的典范。
CyberArk于 2000 年代初开创了PAM类别。其首款产品是企业保险库（Enterprise Vault），到 2020 年代，CyberArk已稳居 PAM 市场领导地位，市场份额约为 40%。近期，该公司开始向“ workforce identity”（ workforce identity）安全平台转型，通过收购 Zilla Security（2025 年）拓展 IGA（身份获取与管理）领域，并通过收购 Idaptive（2020 年）强化 IAM（身份与访问管理）能力。
Palo Alto Networks则一直在推进“超级平台”战略，旨在覆盖网络安全领域的所有核心领域。身份识别是他们唯一缺失的环节。Nikesh过去曾多次强调，Palo Alto Networks 并非一家身份识别公司。但他很可能指的是，该公司并非一家“IAM”（身份访问管理）公司，因为 IAM 工具通常（尽管并非总是）销售给向首席信息官（CIO）汇报的 IAM 团队。Palo Alto Networks 的市场进入策略（GTM）目标是首席信息安全官（CISO），因此，IAM 业务从未与他们的战略相契合。
然而，PAM 和 IGA 确实属于 CISO 的预算范围，因此，为了弥补身份管理方面的缺口，PANW 收购一家 IGA 或 PAM 公司一直是更可能的选择。但为何选择一家大型成熟公司？近期，PANW 收购的都是现代顶尖初创企业（如 Talon、Dig Security、Protect.ai 等），收购金额在$2 亿至$6 亿美元之间，因此$250 亿美元的收购是否不符合其一贯风格？
PANW 每次进行小型收购的思路都很简单——收购该领域最优秀的产品，并将其整合到现有 PANW 产品线的 GTM（Go-to-Market）策略中。例如，Talon 被整合到 PANW 的 SASE 产品中，其核心策略是将客户的 SASE 架构扩展到终端（浏览器）。成功自然随之而来，因为这些产品可以与现有销售流程捆绑销售。身份识别则没那么简单。由于此前在该领域毫无布局，收购一家小型身份识别初创公司很可能不会成功。毕竟，初创公司的产品能与现有销售流程的哪个环节对接？因此，要在身份识别领域取得成功，PANW 需要一个立足点和一个品牌，而非仅仅技术。因此，大规模收购成为必然选择。
这将潜在收购目标缩小到少数几家大型身份治理（IGA）和PAM公司。鉴于这些公司倾向于追求行业顶尖解决方案，最终候选名单进一步缩小至 Sailpoint（IGA）和 CyberArk（PAM）。我推测 CyberArk 很可能胜出，因为其产品组合更为广泛，尤其在 PAM 领域具有优势，而在 IGA 领域则稍逊一筹。
这解释了为什么他们会收购 CyberArk，但并未解释他们为何愿意支付如此高昂的溢价。一个常见的观点是：“PAM 是一项传统技术，没有增长空间。为什么为一个滩头阵地支付如此高昂的代价（25 倍收入）？”要理解这一点，我们需要了解 PAM 的历史，它如何适应每一次基础设施变革，为什么它现在正在再次演变，以及为什么它将在未来几年成为一个巨大的增长领域，从而可能证明这一溢价是合理的。
但首先，PAM 究竟是什么？
本质上，PAM解决方案帮助组织控制其员工对最敏感资产的访问权限。这些资产通常是生产环境，其中运行着对业务至关重要的应用程序和工作负载，任何一次安全漏洞都可能导致业务停摆。这些资产包括服务器、核心数据库、Kubernetes 集群、公共云控制台和代码仓库。PAM确保只有经过授权的身份（无论是人类、机器还是代理）能够访问这些系统，且仅在必要时限内获得所需权限，同时全程记录审计日志。
其核心目标在过去二十多年中始终如一：所有特权访问都应是短暂的、最低权限的且可审计的。发生变化的是系统性质、涉及的身份类型以及授予和执行访问的机制。让我们来探讨这些机制。为了实现这些目标，在整个发展历程中，每一种 PAM 解决方案，无论是明示还是暗示，都必须解决三个核心工作流程：
用户配置 - 在目标系统中创建用户账户。
身份验证（authn） - 验证请求访问的用户身份。
授权（authz） - 确定用户在通过身份验证后可以执行的操作。
随着技术的不断发展，PAM 解决方案解决这些核心工作流的方式也发生了变化。
第一阶段：Vault主导的PAM（约2000-2010）
在 21 世纪初，企业工作负载运行在企业数据中心中。特权资产通常指这些数据中心中的物理服务器和数据库。特权访问的定义很简单：即对该基础设施执行“危险”任务的能力，例如重启生产服务器、修改数据库架构或迁移生产数据库。通常，这意味着访问 root、db_admin 或 sysadmin 等特权账户，这些账户通常由系统管理员、数据库管理员或高级网络工程师使用。对这些特权账户的访问权限通过密码授予。挑战在于，这些密码通常在多个用户之间共享。此外，它们经常以不安全的方式存储：共享驱动器上的 Excel 表格、明文文件，甚至贴在便签上。
风险显而易见。2002 年，萨班斯-奥克斯利法案（Sarbanes Oxley）要求企业必须控制并审计对敏感系统的访问权限。共享凭证使得分配责任、追踪访问者或更改者几乎成为不可能。显而易见的解决方案是企业级密码管理器或保险库。这些第一代PAM系统将特权凭证存储在加密保险库中。它们要求通过身份验证（通常通过 AD，并支持多因素认证）来检索密码，记录所有操作，并在许多情况下，在使用后轮换密码以防止重复使用。
CyberArk 是最成功的基于保险库的PAM解决方案。其他供应商包括 BeyondTrust 和 Thycotic（后者后来与 Centrify 合并，形成了 Delinea）。
基于保险库的PAM通常支持特权操作，例如 SSH/RDP 会话或数据库操作。随着时间的推移，保险库功能不断扩展，新增了会话录制（包括键盘输入和屏幕视频）、细粒度策略（限制哪些账户在何时、由谁以及出于何种目的访问系统）以及异常使用模式的警报（例如在维护窗口外访问 root 权限）。
为什么这种架构是正确的？要回答这个问题，让我们看看基于保险库的 PAM 如何解决了我们框架中的三个核心工作流程：
用户配置非常简单。目标机器上已经存在静态特权账户，无需进行任何额外操作。
身份验证是通过保险库凭据进行的。这些凭据会自动轮换以确保其短暂有效。
授权过程也非常简单。每个密钥都映射到一个具有固定权限的特定特权账户，从而实现了静态最小权限原则。
由于系统数量较少且相对稳定，系统部署和权限分配较为简单。身份验证是瓶颈，而基于保险库（带轮换）的策略是当时的合适解决方案。在云计算时代之前，基于保险库的PAM非常成功，但随着虚拟化和云计算的加速采用，特权资产开始激增，这一模型开始出现问题。
第二阶段：堡垒主导的PAM（约2010-2020）
到 2010 年代初，公有云（AWS、Azure 和 GCP）已开始普及并进入生产环境。此外，VMware 和 Hyper-V 使按需快速部署和释放服务器变得轻而易举。一段时间内，组织试图将基于保险库的PAM强行应用于这些新环境。然而，云环境与传统环境存在显著差异——服务器和数据库的数量远超静态物理数据中心。因此，需要管理的 SSH 密钥、数据库凭证和根密码数量呈指数级增长。
保险库模型无法应对凭证数量的激增，导致运营和安全问题层出不穷。由于该模型并未针对开发工作流程设计，开发人员和 DevOps 团队可以随意创建新的密钥和凭证，且缺乏有效管理。这导致密钥在整个系统中无序扩散，例如 SSH 密钥出现在 Ansible playbook 中、密码存储在 Terraform 变量中，以及数据库凭证被直接写入 Jenkins 管道等。
该问题的解决方案是采用堡垒主机（bastion）驱动的PAM。DevOps 团队开始在网络边缘部署经过强化处理的网关（称为跳板主机、堡垒主机或代理服务器），作为特权会话的唯一入口点。工程师无需为每个目标系统单独获取凭证，只需向堡垒主机进行一次身份验证，堡垒主机再代理其访问目标系统。保险库只需存储堡垒主机的凭证。从运营角度来看，这带来了重大改进。工程师可通过 SSH 连接到堡垒主机（通常使用存储在保险库中的密钥），然后执行命令访问目标系统。堡垒主机将代表用户注入目标系统的凭证，并记录会话以供审计。所有流量均通过安全团队可监控的单一控制点流转。
在工作流术语中：
用户配置 - 在跳板机上创建的账户，通常映射到身份提供商（IdP）的身份；目标系统仍依赖于共享服务账户。
身份验证 - 堡垒主机使用加密存储的 SSH 密钥；目标系统上的共享账户使用静态密钥或密码。
授权 - 通常范围广泛且长期有效；一旦进入堡垒，对目标的访问权限将持续有效，无时间限制。
在此期间，与身份提供商（IdP）的集成得到了改进。部分供应商开始将产品称为“身份感知代理”，因为它们能够将堡垒登录与身份提供商中的个人关联，但这些系统并非真正意义上的身份原生：底层目标仍使用共享或临时账户。堡垒本身成为另一个需要治理的控制平面，拥有独立的账户、角色分配及审核周期。知名供应商包括 ScaleFT（被 Okta 收购）、StrongDM 和 Teleport。
到 2010 年代末，另一场变革正在酝酿。应用程序越来越倾向于云原生，而最关键的操作不再是通过网络访问机器或数据库。相反，特权访问的核心在于保护 API 调用，例如更改 IAM 角色、销毁数据库、修改存储策略以及删除 Kubernetes 容器——这些操作是传统堡垒无法有效代理的。瓶颈转移到了授权环节：在特权操作已迁移至 API 层而非网络层的世界中，如何在恰当的时间内授予恰当的权限。
第三阶段：API优先、身份原生的PAM（约2020至今）
到 2020 年，技术栈中正在发生几项重要变革。首先，如前所述，所有主要云服务提供商的IAM API 已足够成熟，大多数特权操作可通过这些 API 而非网络连接直接执行。其次，特权操作本身（如连接到生产集群或数据库）不再仅限于人类用户。非人类身份（包括工作负载和 CI/CD 管道）通过使用 AWS IAM 角色、Azure AD 服务主体或 GCP 服务账户等构造，能够删除数据库、授予管理员权限或修改存储策略。这些非人类身份的数量往往远超人类用户，且在现代PAM计划中需要同等水平的治理。
身份验证已趋成熟。对于人类用户，单点登录（SSO，如 Okta、Azure AD）配合多因素认证（MFA）已成为标配。工作负载和机器则采用短效凭证：AWS STS 会话令牌、Azure 托管身份、GCP 工作负载身份联合。静态密钥正被云服务商原生提供的无密码、短效认证方案取代。授权才是难点。特权访问意味着控制权限：谁能做什么、在哪里做以及做多长时间。长期存在的权限，如 IAM 角色中的长期管理员权限、Kubernetes 中的集群管理员角色以及过于宽松的 GitHub 访问令牌，成为了最大的攻击面。安全事件反复表明，攻击者正是利用这些漏洞获取特权环境的访问权限。
基于身份的PAM将用户配置和身份验证完全委托给身份提供商（IdP）或单点登录（SSO）系统。权限通过原生云服务提供商（CSP）API 进行分配：
1.工程师请求为特定任务授予特权角色，例如以 sudo 权限进入虚拟机。
2.PAM 检查策略和上下文，可选地要求人工审批。
3.PAM 调用平台 API 以授予角色、范围和时间限制。
4.当时间到期时，PAM 将自动撤销该权限。
在工作流术语中：
用户配置 - 账户与身份提供商（IdP）中的身份绑定；不存在预先创建的本地或共享账户。
身份验证 - 针对人类的单点登录（SSO）；针对机器的短寿命令牌或受管身份；在可能的情况下使用无密码方法。
授权 - 细粒度且临时性；以原生 IAM 语言定义；根据需要通过自动化方式授予或撤销。
需要特别注意的是，身份原生 PAM 与之前版本的 PAM 完全向后兼容。堡垒主机驱动的 PAM 的所有用例均可由身份原生 PAM 完全覆盖，但反之则不成立。例如，如果工程师需要通过 SSH 登录到 EC2（这是堡垒模式的典型用例），身份原生 PAM 可以通过在云提供商的原生身份访问平台（如 AWS SSM、GCP IaP、Azure Bastions）中分配角色来实现。然而，如果工程师需要读取 S3 存储桶的权限（身份原生 PAM 的典型用例），堡垒节点无法轻松支持此需求。
简而言之，现代基于身份的访问管理（Identity-native PAM）是一个编排层，它：
将身份验证委托给身份提供商（IdPs）。
通过原生 IAM API 授予和撤销权限。
在必要时经批准后实施。
确保每项操作均被记录并可追溯。
涵盖通过 API 执行特权操作的任何身份，包括人类、工作负载和代理。
然而，仅靠编排是不够的。在混合云和多云环境中，特权访问跨越数十个控制平面，包括 AWS IAM、Azure RBAC、GCP IAM、Kubernetes RBAC 和 GitHub RBAC；其中许多控制平面超出了单一工具的直接管理范围。为了成功部署PAM平台，组织必须首先明确特权访问的具体位置（毕竟，只有看到并了解的资源才能被有效管理）。
基于身份的PAM通过一个可见性层实现这一点，该层展示了每个身份、每个权限、每个凭证以及通往特权的每条路径。这使得以下功能成为可能：
查看当前管理员权限或静态凭据。
突出显示风险，例如横向移动风险或过度特权账户。
最重要的是，识别出必须最终通过 PAM 进行管理的受限访问权限。
PAM、PANW 和 CyberArk 的下一步是什么？
如我们所见，PAM 远未消亡。
当人们善意地表示“PAM 已过时”时，他们真正指的是基于保险库的 PAM 已过时。在当今网络边界日益消融的时代，说“身份是新的边界”已成陈词滥调，而“原生身份 PAM”将长期存在。
然而，这并未回答一个关键问题：这个市场究竟有多大（且增长速度有多快）？为何 PANW 会觉得有必要支付溢价？正如 PANW 在收购后的声明中所暗示的，增长将来自于代理身份。过去二十多年来指导 PAM 发展的核心原则（短暂访问权限、最小权限原则和可审计性）如今同样适用于 AI 代理。这些原则与基于身份的 PAM 模型天然契合，因为 AI 代理同样通过目标系统的 API 执行特权操作，例如在敏感的 GitHub 仓库中创建拉取请求。此类操作需要临时凭证、严格限定的权限范围以及完整的日志记录。例如，集成到 CI/CD 管道中的开发者助手 LLM 可能需要在 AWS 中请求一个短暂的部署者角色以推送构建。现代 PAM 会验证该请求，在构建期间授予角色，并在构建完成后自动撤销，同时将整个事件记录在审计日志中。
回到 PANW 与 CyberArk 的争论，CyberArk 的核心产品，也是其收入的主要来源，是其以保险库为中心的 PAM 解决方案。尽管他们已投资于提升该产品在现代技术栈中的能力，但与企业软件领域的其他情况类似，可以合理推测 PANW 需要持续升级核心产品以跟上新技术的发展。而回归其经过验证的战略——收购$200-$600M 的初创公司，并将其整合到其（新的）战略据点——将要容易得多。
PAM 并未消亡，它正在演进。
在这一新篇章中，无论是 PANW 还是其他领域，领先者都将把身份视为控制平面，深度集成原生 IAM API，并为所有身份（包括人类、工作负载或代理）应用最小权限原则。
原文链接：
https://ventureinsecurity.net/p/pam-is-not-dead-its-evolving
声明：本文来自安全喵喵站，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
