Unit 42 云身份研究揭示基于权限的安全防护局限
Unit 42 分析了逾 40,000 个云身份，揭示出一个仅靠权限审查无法解决的矛盾。Unit 42 云身份研究认为，安全团队必须理解一个身份实际在做什么，而不只是它能够做什么。
该研究于 2026 年 9 月 14 日发布，汇总了 125 个云环境在两个月观察期内的活动。其模型根据 AWS CloudTrail 中记录的操作对身份进行分组。这些分组对应于可识别的角色，包括管理员、备份代理、安全工具、DevOps 用户和持续交付系统。
关键的较量在于行为角色推断与静态身份标签之间。即使攻击者改变了某一身份的用途，一个受信任的名称、熟悉的策略或合法凭证仍可能继续存在。Unit 42 提议将观测到的行为转化为角色上下文，再利用偏离这一上下文的行为来改进自动化检测。
Unit 42 按操作而非名称映射身份
该研究将 API 活动视为身份工作角色的证据，从而改变了身份分析方式。
这项行为身份研究始于一个实际问题。如今的云资产环境包含员工、应用程序、部署流水线、安全产品和自主代理。它们的名称及分配的权限往往无法充分说明其当前职能。
一个名为“backup”的身份可能确实每天夜间读取一个存储桶。之后，同一身份也可能枚举用户、检查策略，或创建计算资源。即使其名称和权限保持不变，这些操作依然值得关注。
Unit 42 根据每个身份于研究期内调用的 AWS 操作来表征该身份。研究人员随后比较了参与环境中的这些行为画像。相似的操作组合将身份聚合到不同群组中。
最终得到的映射包含 30 个大型聚类，代表约 20,000 个身份。研究人员将这些聚类与反复出现的职能关联起来，例如管理、基础设施自动化、网络、安全、备份、FinOps 和数据服务。
管理聚类提供了最清晰的例子。它包含超过 100 个云项目中的约 5,000 个身份。其中约 94% 的身份产生了 ConsoleLogin 事件，而其他聚类中的这一比例不足 1%。
约 60% 的身份还调用了与正常控制台活动相关的操作，包括 GetCostAndUsage 和 GetCostForecast。这些操作有助于区分交互式管理员与仅使用较窄 API 集合的机器身份。
这一证据之所以重要，是因为没有单一事件可以确定意图。ConsoleLogin 表示一次交互式登录，但并不能证明用户是管理员。成本管理请求也可能在控制台加载时自动发生。
为避免依赖某一个便利信号，Unit 42 结合了四种分析形式：操作频率、区分性操作、身份属性，以及每个聚类内反复出现的命名模式。
其中一种命名模式尤其具有启发性。当通过其标准权限集分配 AdministratorAccess 时，AWS IAM Identity Center 会创建一个可识别的前缀。该前缀频繁出现在管理聚类中，支持了这一行为解释。
名称只是辅助证据，并非模型的基础。这一区别可防止该方法只是重新发现已经附加于身份的标签。当名称模糊、过时或被刻意伪装时，这种方法也更有用。
该研究并未披露新近发现的数据泄露或漏洞。它提出了一种基于真实运营遥测数据构建的检测设计。其新闻价值在于，使云身份分类更具可扩展性和可解释性。
大多数身份清单会回答：谁拥有某项凭证，以及其策略允许哪些操作。Unit 42 增加了第三个问题：身份的活动揭示了什么功能角色？这一额外维度构成了整项研究的核心张力。
静态权限让最重要的问题悬而未决
权限告诉防御者什么是可能的，而行为揭示了一个身份当下正在使用哪些能力。
身份与访问管理策略仍然至关重要。它们决定某个主体能否读取密钥、启动实例、修改日志记录或承担其他角色。最小权限原则可减少遭入侵凭证可能造成的损害。
然而，策略分析无法完整描述运营现实。组织经常授予宽泛访问权限，以免阻碍部署或紧急工作。随着项目、团队和职责变化，旧角色也会不断累积权限。
一些权限过大的身份可以多年无害运行。另一些则会在凭证被盗后成为有价值的入口点。在两种情况下，权限文档看起来都存在风险，但它无法显示哪个身份已经开始在既定职能之外行动。
行为上下文补足了这一差异。一个反复访问单一受保护目标位置的备份流程，会形成狭窄的基线。资源枚举、身份发现或管理变更，都将构成对该基线的显著偏离。
同一个 API 调用在另一种上下文中可能具有不同风险。安全资产清单产品调用 ListBuckets 可能是预期行为；而对于一个历来只向某个存储桶写入应用日志的工作负载，则值得更密切关注。
这正是 Unit 42 云身份研究对仅依赖态势的安全项目施加压力的原因。云安全态势管理能够识别过度权限和配置问题，却无法自动解释观测到的操作是否符合某个身份的真实职责。
攻击者会从这一缺口中获益。他们可以使用现有凭证、继承的策略和看似无害的资源名称。随后，其活动会显示在安全团队早已熟悉的身份之下。
伪装并不需要更改账户名称。攻击者只需通过防御者视为可信的身份执行恶意操作。即使行为已经改变，静态清单仍可能保留这种信任。
AWS 已在其托管威胁检测服务中应用行为分析。根据其异常检测文档，GuardDuty 会对 CloudTrail 事件中的字段进行画像，以识别异常或未经授权的活动。
GuardDuty 还会考虑请求身份、API 和位置等因素。其发现可识别与凭证访问、发现、持久化、权限提升、数据外泄和影响相关的活动。
这一现有能力验证了更广泛的发展方向，但并未削弱 Unit 42 的贡献。托管检测通常是在供应商的模型和规则识别出可疑活动后才呈现发现结果。客户对确切的基线或分类过程的可见性有限。
Unit 42 专注于分配防御者能够理解和复用的功能角色。该模型会判断一个身份的行为是否像管理员、部署系统、扫描器或备份服务。这一角色可为后续检测提供更丰富的上下文。
这一差异也改变了处置方式。陌生的 API 调用并不自动意味着恶意，常见的 API 调用也不自动意味着无害。分析人员需要将操作与该身份的预期职能进行比较。
这给云安全厂商、内部检测团队和身份治理平台带来了压力。每一方都必须将权限数据与运行时活动连接起来。只呈现其中一面的产品，会让分析人员不得不手动重建另一面。
随着非人类身份不断增加，这种压力也在增长。工作负载、CI/CD 系统、服务账户、自动化工具和 AI 代理都能持续执行操作。其行为量使手动分类变得不切实际。
Unit 42 的答案不是摒弃权限，而是将获准能力与实际观测到的操作相结合。两种视角回答不同的问题，在共同评估时更具价值。
Unit 42 云身份聚类如何运作
Unit 42 使用无监督聚类发现行为角色，再将这些发现提炼为更简单的分类器。
第一阶段始于云审计日志。AWS CloudTrail 会记录由用户、角色和服务生成的事件，包括涉及的身份和 API。AWS 在其 CloudTrail 事件参考中说明了这些字段。
Unit 42 将每个身份转化为布尔向量。每个位置代表一个可用操作，而 true 或 false 记录该身份是否在观察窗口内调用了该操作。
这会产生一个棘手的数据集。研究称，AWS 在约 240 项服务中提供了超过 15,000 项可能操作。大多数身份只调用其中很小的一部分，因此形成的向量规模庞大且大多为空。
该流水线使用 Uniform Manifold Approximation and Projection，即 UMAP，来缩减这些向量。UMAP 将高维观测值转换为更小的表示，同时尝试保留有意义的邻域结构。
研究人员使用余弦相似度作为距离度量。该度量比较两个向量的方向，而非其绝对大小。它强调身份之间共享哪些操作，而不是偏向于活动量更大的身份。
一次 UMAP 处理创建了包含 32 个连续值的稠密表示。另一轮处理则将身份投影到二维空间，以便可视化。这两个输出服务于不同目的，不应视为可以互换。
随后，稠密表示被输入 HDBSCAN，这是一种识别高点密度区域的聚类方法。与需要固定群组数量的算法不同，HDBSCAN 可以发现聚类，并将异常点标记为噪声。
这两种方法都拥有成熟的研究基础。原始的 UMAP 论文介绍了这一降维技术，而 HDBSCAN 论文则涵盖了层次密度聚类。
身份获得聚类分配后，分析人员仍需解释每个群组。聚类标识符不会自带“管理员”或“备份服务”之类的标签。因此，该研究采用多项测试来推断其角色。
操作频率显示哪些 API 出现在整个聚类中。基于类别的评分方法会识别在某一群组内频繁出现、但在其他地方并不常见的操作。这能够区分仅仅流行的 API 与真正具有区分度的信号。
属性映射增加了另一种视角。研究人员可以突出使用特定服务、调用特定操作或包含重复字符串的身份。集中出现的属性可为拟议的功能标签提供证据。
最后，子串挖掘可识别身份名称中重复出现的片段。这有助于发现由部署系统或身份管理产品形成的命名惯例。相比仅凭单个身份的名称断定其角色，这种方法更可靠。
这些方法结合起来，便能将视觉模式转化为可解释的行为类别。这种解释仍属于分析判断，但它建立在多种形式的证据之上。
因此，Unit 42 的云身份聚类方法并非神奇的身份解码器。它是一套用于发现重复运营模式的结构化流程。人类分析师仍需将这些模式与真实的组织职能关联起来。
这一限制同时也是优势。安全团队可以审查某个聚类为何被赋予特定标签。在将该分类投入生产环境前，他们可以先验证其中的显著操作是否符合自身环境。
这一过程类似于探索性制图。无监督学习无需预先获得角色清单，便可绘制地图。随后，分析师识别出哪些区域对应已知的运营行为。
然而，反复运行整套映射流程会带来计算和运营成本。随着数据集和参数变化，它还可能导致聚类标识符发生变动。Unit 42 在下一阶段解决了这一问题。
真正的进步在于从模型走向 SQL 的路径
最具运营意义的步骤，是将发现的聚类提炼为现有数据系统可执行的小型、可解释规则。
在识别出有用的聚类后，Unit 42 会基于原始布尔操作向量训练逻辑回归分类器。逻辑回归计算各项特征如何改变某个观测对象属于指定类别的可能性。
团队可以为管理员行为训练一个分类器，为安全工具行为训练另一个分类器。随后，无需重建完整的行为地图，即可根据相关模型评估新的身份。
Unit 42 还应用了 L1 正则化。这种惩罚会将无帮助特征的系数推向零。剩余操作由此构成一组规模更小的正向和负向指标。
这种稀疏性对安全运营十分重要。包含数千个相互作用特征的模型难以检查、解释或复现。基于数十项加权操作的分类器则更容易投入实际运营。
分析师可以看到哪些 API 调用会使某个身份更接近管理员分类，也可以看到哪些操作会使其远离该分类。这种可见性支持在逻辑影响告警前进行审查。
研究人员表示，这种加权逻辑可以通过标准 SQL 查询表达。大多数安全组织已经在数据仓库、安全数据湖或分析平台中集中存储云日志。SQL 降低了部署门槛。
这并不意味着整个机器学习工作流消失了。原始聚类阶段仍负责发现有意义的群组并提供训练标签。轻量级分类器是对早期分析的局部近似。
这种区分避免文章得出误导性结论。Unit 42 并未将所有云安全问题简化为一条 SQL 语句。它展示的是，如何将一个学习得到的分类边界转化为透明的查询逻辑。
这一设计在定制化机器学习与僵化的手写规则之间提供了务实的折中。完全人工的检测依赖分析师预先预测相关的组合；复杂模型则可能成本高昂且难以解释。
行为聚类从观测数据中发现候选模式。稀疏分类器随后以可检查的格式保留选定模式。检测团队无需持续维护探索性流程，便可获得可复用的上下文。
以备份服务为例。分类器可能识别与定期备份活动相关的操作，并赋予其相应的功能角色。检测逻辑随后可将管理性发现或策略变更视为与该角色相冲突的行为。
这种告警更有力，因为它描述的是不匹配，而不仅是一项罕见事件。“备份身份执行了管理员行为”比“观察到异常 API”能为分析师提供更多上下文。它将行为主体的基线与可疑动作联系起来。
同样的方法也可支持 CI/CD 系统。部署身份通常会在可预测的服务中执行重复性的基础设施操作。凭证滥用可能引入控制台活动、大范围发现操作或无关的数据访问。
安全产品则是另一类有用的类别。它们会定期枚举资源并检查配置。若缺少角色上下文，这些行为可能看起来像攻击者侦察，并产生本可避免的噪声。
因此，功能分类可以减少两类不同错误。当广泛访问与已知扫描器相匹配时，它能降低误报；当用途狭窄的自动化开始表现得像管理员时，它又能提高警觉。
这正是行为角色推断与静态标签竞争最直接的地方。像“security-scanner”这样的名称要求分析师信任配置；而观测到的模式则提供证据，表明该身份仍在持续执行这一职能。
该方法也补充了权限分析。安全扫描器即使行为正常，也可能保留过多权限。即便运行时检测未发现任何可疑情况，态势工具仍应报告这种暴露。
反过来，一个权限严格受限的身份也可能在其允许范围内表现异常。即使策略审查未发现违规，行为监控仍应标记这种变化。
因此，该模型创建的是额外的数据层，而非替代性控制措施。权限定义边界，聚类推断角色，检测逻辑识别值得调查的偏离行为。
Unit 42 表示，该方法可从 AWS CloudTrail 扩展至其他云服务提供商、Kubernetes 和软件服务。这种扩展是合理的，因为这些系统同样会产生与身份关联的审计事件。
不过，可移植性需要新的验证。Azure、Google Cloud、Kubernetes 和 SaaS 平台具有不同的事件词汇和身份结构。在 AWS 操作上训练的分类器无法原封不动地迁移。
这项研究尚未证明什么
该数据集展示了连贯的行为聚类，但尚未证明其在不同组织、服务提供商或不断变化的工作负载中具有普适的检测准确性。
Unit 42 报告了相当大的规模，包括超过 40,000 个身份和 125 个环境。这一广度支持了重复的行为角色会出现在多个云环境中的主张，但并不能回答所有生产问题。
该发布内容并未提供完整基准，包括所有已识别角色的精确率、召回率、误报率和性能表现。它表示逻辑回归可以准确识别选定聚类，但公开读者无法独立复现每一项结果。
这项研究还聚焦于两个月的观察窗口。这段时间能够捕捉重复性操作，但某些合法身份只会在季度恢复测试、迁移或事件响应期间活动。较短的基线可能会错误分类罕见但已获授权的工作。
布尔向量引入了另一种权衡。它们保留某项操作是否发生，却忽略了发生频率。某个身份调用 API 一次，在这一特征上与调用数千次的身份没有区别。
这种简化有助于控制维度并支持可解释性，但也可能抹去区分常规工作与滥用的数量信号。调查中，频率、时间、地理位置、请求参数和资源目标都可能十分重要。
概念漂移带来了另一个问题。当团队采用新服务、调整流水线或迁移架构时，功能行为会发生变化。依据昨日操作训练的分类器，可能会将合法的部署变更视为可疑。
攻击者也可以适应。如果他们了解预期的行为角色，就可以选择看似符合其正常活动的操作。行为分类提高了伪装的成本，但并不能消除规避行为。
这种方法依赖可靠的遥测数据。缺失的 CloudTrail 覆盖、被禁用的日志记录、不一致的保留策略或不完整的跨账户收集，都会扭曲身份向量。再好的模型也无法恢复从未记录的事件。
身份边界也可能变得模糊。承担角色、联邦会话、工作负载凭证和共享自动化路径，可能将多个行为主体合并为一个表面上的主体。角色推断的精确度取决于源日志中的标识符质量。
跨组织数据增加了另一层不确定性。共享行为可以揭示稳定的行业模式，但每家公司配置账户的方式不同。在一个环境中与管理员高度相关的操作，可能在另一个环境中自动发生。
管理员聚类说明了这一风险。在报告的数据集中，ConsoleLogin 具有很强的区分性。然而，自动控制台请求、联邦访问设计和提供商界面变更，都可能改变交互式会话所伴随的操作。
即使是“功能角色”这一表述，也可能暗示比证据实际支持的更高确定性。聚类描述的是某个观察期内的行为相似性，并不能证明组织归属、授权状态或业务目的。
因此，安全团队应将分配的角色视为上下文元数据，并将其与权限数据、资源范围、网络指标、认证信号和威胁情报结合使用。没有任何单一维度能够确立恶意意图。
商业背景同样值得审视。Unit 42 是 Palo Alto Networks 的威胁研究机构，该发布内容将此方法与 Cortex Cloud 及相关产品联系起来。其技术发现仍有价值，但产品主张需要客户侧验证。
组织应询问这些分类是否能在不同账户和不同时间保持稳定。在允许角色不匹配触发自动化遏制之前，应先衡量告警质量。错误响应可能中断备份、部署或安全监控。
试运行评估提供了更安全的采用路径。团队可以计算推断角色，将其与已知资产归属进行比较，并在不改变生产访问权限的情况下观察偏差。分析师随后可调整阈值和例外情况。
最好的检验并非可视化图表是否看起来令人信服，而是角色上下文是否能缩短调查时间，同时保留有意义的检测结果。这一结果需要研究发布内容之外的运营证据。
三个信号将表明行为身份检测是否经得起检验
下一项检验是：行为角色推断离开研究环境后，是否仍能保持准确、可移植且实用。
第一个信号是可衡量的检测性能。Unit 42 或其客户需要公布多个角色的精确率、召回率和误报结果。仅凭管理员分类无法证明其对备份代理、部署系统或自主代理的性能。
结果应包含未见过的环境，而不是从同一组织群体中抽样的身份。在外部环境中表现强劲，将支持功能模式具有泛化性的主张；若性能大幅下降，则会暴露依赖特定环境的假设。
第二个信号是跨平台验证。研究人员表示，他们的方法可扩展至 Kubernetes、SaaS 应用和其他云服务提供商。在 AWS 之外有据可查的实施将检验这一断言。
可移植性不应仅仅意味着能处理另一种日志格式。该方法必须能够发现可识别的角色，产出稳定的分类器，并改善真实的检测决策。否则，真正发挥更大作用的可能是 AWS API 的惯例，而非这一通用框架。
第三个信号是通过透明的检测工作流实现运营层面的采用。安全团队应关注那些能在告警中展示推断角色、相关操作、置信度及冲突行为的集成方案。
简单的风险评分会掩盖这项研究的主要优势。其价值在于解释：一个已知的备份身份为何开始表现得像管理员。分析师需要理解这种关系，才能判断紧急程度并选择应对措施。
最强大的实现还会持续跟踪角色随时间的变化。部署账户可能会合理地扩展到新的服务中。系统需要重新训练计划、漂移监控、版本化分类器，以及针对行为变化的审查流程。
团队不应将每一次不匹配都视为安全事件。有些偏差源于维护、迁移或新产品发布。角色信号应帮助确定调查优先级，而是否应实施遏制措施仍需由其他证据决定。
人类身份与机器身份也应分别评估。交互式管理员、定时服务和自主代理产生的活动速度不同，可能需要不同的观察窗口和阈值。
自主代理使这一问题尤为紧迫。代理可能为了完成一个获批目标，在众多服务间执行可变的操作序列。静态的任务标签难以准确描述这类行为。
但可变行为同样会使聚类更加困难。代理的合法操作空间可能与侦察、配置变更和数据访问相重叠。防御者将需要了解其目标、审批、资源以及执行历史等上下文。
Unit 42 的云身份提案提供了这类上下文的一部分。它基于实证描述身份如何在同类身份中行动，但并不能判断其底层目标是否获得授权。
对开发者而言，眼下的问题是：部署身份和服务身份是否具有清晰、可观察的行为模式。团队应审查审计事件能否在承担角色和自动化会话之间被一致地关联起来。
企业采购方应询问供应商如何推断功能角色，也应要求其提供证据，说明哪些事件推动了每项分类。对于高影响力的安全决策，“AI 驱动的异常检测”并不是充分的信息。
安全负责人应将行为发现与访问审查进行比较。一个看似职能范围狭窄、却保留广泛权限的身份，代表着可避免的暴露风险；一个突然改变角色的身份，则可能意味着正在发生的威胁。
知识工作者和 AI 产品用户同样与此息息相关。企业应用正越来越多地将助手和代理接入公司数据。每一次连接都会创建一个身份，其实际行为能力可能超出简单的用户标签所能描述的范围。
未来一到三个月将揭示 Palo Alto Networks 是否会发布更多验证结果、扩大角色覆盖范围，或在客户工作流中更直接地呈现其逻辑。独立测试将进一步增强这一论点的可信度。
读者应关注三个具体问题：这些分类器能否在未见过的环境中发挥作用？它们能否迁移到 AWS 之外？它们能否改善分析师的决策？这些答案将决定行为身份地图能否成为常规的安全上下文。
该研究的核心判断已经成立：权限文档是必要的，但无法完整说明身份风险。防御者还需要了解凭据、工作负载和代理实际上做了什么的证据。
请从这一视角审视自己的云资产清单。哪些身份拥有名称和权限，却没有经过验证的行为角色？这一问题中的缺口，正是 Unit 42 云身份研究最具价值之处。
