如何掌控人工智能智能体和非人类身份

我们经常听到这样的说法：

“我们有数百个服务账户和人工智能智能体在后台运行。其中大多数都不是我们创建的。我们也不知道它们的所有者是谁。我们该如何保护它们的安全呢？”

如今，每个企业的运转都不仅仅依赖于用户。在幕后，成千上万的非人类身份（从服务账户到API令牌再到人工智能智能体）全天候访问系统、传输数据并执行任务。

它们并非新生事物。但它们的数量正在快速增长。而且大多数在构建时都没有考虑到安全性。

传统身份工具会假定意图、上下文和所有权。非人类身份则不具备这些。它们不会登录和退出。它们不会被停用。而且随着自主智能体的兴起，它们开始自行做决定，通常拥有广泛的权限，却很少受到监督。

这已经造成了新的盲点。但我们才刚刚开始。

在这篇文章中，我们将探讨非人类身份风险的演变情况、大多数组织仍面临的风险暴露点，以及身份安全架构如何帮助安全团队在风险规模变得难以控制之前抢占先机。

非人类身份的兴起（及风险）

云优先架构增加了基础设施的复杂性，并引发了后台身份的激增。随着这些环境的扩大，后台身份的数量也随之增长，其中许多是自动创建的，没有明确的所有权或监管。在许多情况下，这些身份的数量超过人类用户，比例超过80:1。

尤其危险的是，大多数团队对它们知之甚少。非人类身份（NHIs）通常在部署或配置过程中自动创建，然后就从人们的视线中消失，无人追踪、无人负责，而且往往拥有过多权限。

服务账户尤其无处不在。它们在系统之间传输数据、运行定时任务并为无头服务进行身份验证。但它们的无序扩张鲜少可见，其权限也很少得到审查。随着时间的推移，它们成为横向移动和权限提升的完美工具。

但服务账户只是其中一部分。随着人工智能应用的普及，一类新的非人类身份带来了更难以预测的风险。

为什么人工智能智能体的行为会有所不同及其重要性

与大多数机器身份不同，人工智能智能体能够自主发起行动：与API交互、查询数据并自主做出决策。

这种自主性是有代价的。人工智能智能体通常需要访问敏感数据和应用程序接口，但很少有组织对它们能做什么或如何撤销访问权限设置约束。

更糟糕的是，大多数人工智能智能体缺乏明确的所有权归属，不遵循标准的生命周期，其在现实世界中的行为也几乎没有透明度可言。它们可能由开发者部署、嵌入到工具中，或者通过外部API被调用。一旦投入使用，它们可以无限期运行，且通常拥有持久的凭证和高级权限。

而且，由于人工智能智能体不与用户或会话绑定，因此很难使用IP、位置或设备上下文等传统身份信号对其进行监控。

不可见访问的代价

机密信息被硬编码。令牌被重复使用。孤立的身份在数月甚至数年的时间里仍然处于活跃状态。

这些风险并非新出现的，但当你只有几十个服务账户时，静态凭证和完全开放的访问权限或许还能管理。然而，当有成千上万个非人类身份（NHIs）在云服务中独立运行时，手动跟踪显然无法满足需求。

这就是为什么许多安全团队正在重新审视他们最初对身份的定义。因为如果一个人工智能智能体能够进行身份验证、访问数据并做出决策，那么它就是一个身份。而如果这个身份不受管控，它就会成为一种 liability。

常见的非人类身份（NHI）安全挑战

认识到非人类身份代表着日益增长的风险是一回事，而管理这种风险则是另一回事。核心问题在于，为人类身份管理构建的工具和流程无法适用于API、服务账户和AI智能体的世界。这种脱节带来了若干明显且危险的安全挑战，许多组织才刚刚开始面对这些挑战。

你无法保护你看不到的东西

保障非人类身份（NHIs）安全最根本的挑战在于可见性。大多数安全团队并没有掌握其环境中所有非人类身份的完整清单。这些身份通常由开发者或自动化系统动态创建，以实现特定的临时功能。它们被创建出来是为了支持新的微服务、运行部署脚本或集成第三方应用程序。

然而，一旦创建，它们很少会在中央身份管理系统中被记录或追踪。它们变成了“影子”身份，活跃且能正常运行，却完全不为安全部门和IT部门所见。如果无法全面了解存在哪些非人类身份、是谁（或什么）创建了它们以及它们在访问什么，就不可能制定出有效的安全策略。你将只能试图去保护一个规模未知的攻击面。

为什么“设置后就置之不理”是一种安全隐患

开发人员和运营团队的一个常见做法是为NHI分配广泛的权限，以确保服务或应用程序能够不间断地运行。这就好比安装一个应用程序，它会请求访问你的相机胶卷、麦克风和位置信息。你点击“允许”只是为了让它能正常运行，然后就把这件事抛之脑后了。

目前来看，这样做更快也更方便，但会带来不必要的风险。同样，为NHI分配过于宽泛的权限可能会让设置过程更简单，却会造成巨大的安全漏洞，使你的系统容易被利用。

最小权限原则常常为了速度和便利性而被牺牲。一个NHI可能只需要从一个数据库表中读取数据，但为了避免未来与权限相关的错误，它被授予了对整个数据库的写入权限。

这种方法会造成巨大的安全隐患。这些权限过高的身份成为攻击者的高价值目标。如果威胁行为者攻陷了一个拥有过多权限的非人类身份（NHI），他们就可以在系统间横向移动、提升访问权限，并在无需人类用户凭据的情况下窃取敏感数据。

由于对非人类智能体（NHIs）的审查或停用频率极低，这些权限宽松的账户可能会保持活跃且易受攻击达数月甚至数年之久，等待被利用。

没有上下文，就没有现代控制措施

现代身份安全依赖于上下文。当用户登录时，我们可以通过其位置、设备和网络等信号来验证其身份，如果发现异常，通常会提示进行多因素认证（MFA）。非人类身份（NHIs）则没有这些上下文。它们只是在服务器上运行的代码，没有可被轻松监控的设备、地理位置或行为模式。

由于它们使用静态、长期有效的凭据进行身份验证，多因素认证（MFA）并不适用。这意味着，如果凭据被盗，就没有第二个因素可以阻止攻击者使用它。缺乏上下文感知的访问控制，使得人们极难区分合法与恶意的非人类身份（NHI）活动，往往为时已晚。

孤立身份和数字幽灵

当创建服务账户的开发人员离开公司时会发生什么？或者当使用特定API令牌的应用程序退役时会发生什么？在大多数组织中，相关的非人类身份（NHIs）会被遗留下来。这些“孤儿”或“滞留”身份仍然处于活跃状态，权限保持不变，却没有所有者对其生命周期负责。

这些数字幽灵是合规性的噩梦，也是安全隐患。它们使环境变得杂乱，增加了识别合法且活跃身份的难度。更重要的是，它们代表着一个被遗弃、无人监控的系统入口。攻击者一旦发现带有有效凭证的孤立身份，就等于找到了一个完美的后门，一个无人看管的后门。

安全团队如何重新获得控制权

面对不断扩大且日益自主化的攻击面，领先的安全团队正从被动修复转向主动治理。这一转变始于将每个有凭证的系统、脚本和智能体都视为值得治理的身份。

发现并清点所有非人类身份（NHIs）

现代身份平台可以扫描AWS、GCP和本地基础设施等环境，以发现隐藏的令牌、未受管理的服务账户以及权限过高的角色。

这些工具用实时、统一的清单（涵盖人类和非人类身份）取代了电子表格和猜测。没有这一基础，治理就只能是猜测。有了它，安全团队终于可以从与服务账户打地鼠式的周旋，转变为建立真正的控制权。

先对高风险身份进行分类和处理

完成全面盘点后，下一步是缩小潜在的影响范围。并非所有非人类智能体都具有相同的风险等级。关键在于根据权限和访问情况确定补救的优先级。基于风险的权限管理有助于识别哪些身份被过度授权，存在危险。

从那里开始，团队可以系统性地调整访问权限大小，以符合最小权限原则。这还包括实施更严格的控制措施，例如对密钥和凭证进行自动轮换。对于最强大的非人类实体（如自主AI智能体），至关重要的是配备“终止开关”，以便在检测到异常行为时能够立即终止会话。

实现治理和生命周期的自动化

人类身份具有生命周期策略：入职、角色变更、离职。非人类身份也需要同样严格的管理。

领先的企业正在对这些流程进行端到端自动化。当创建新的NHI时，会为其分配所有者、赋予限定权限，并将其添加到可审计的清单中。当工具停用或开发人员离职时，相关身份会被自动取消授权，从而杜绝孤立账户的出现，并确保访问权限不会无限期保留。

为什么身份安全架构会改变现状

许多与非人类身份相关的风险，与其说是与这些身份本身有关，不如说是与试图管理它们的零散系统有关。

每个云服务提供商、CI/CD工具和人工智能平台对身份的处理方式都各不相同。有些使用静态令牌，有些在部署过程中颁发凭证，还有些完全不使访问权限过期。如果没有一个用于定义所有权、分配权限和实施防护措施的共享系统，这种混乱状况就会不受控制地蔓延。

统一的身份安全架构通过将所有身份（包括人类和非人类身份）整合到单一控制平面下，改变了这一局面。而借助Okta，这意味着：

• 通过身份安全态势管理（ISPM）自动发现身份和态势缺口
• 对敏感密钥采用最小权限访问，并进行轮换和存储
• 为每个身份（包括智能体和服务账户）定义生命周期策略
• 扩展工作负载身份模式（短期令牌、客户端凭据）以及对服务和后台作业的自适应访问
• 管理对AWS服务（如Bedrock和Amazon Q）的访问权限，而AWS IAM则负责生成并执行底层智能体/工作负载的凭证。

团队无需拼凑各种临时解决方案，只需定义一次身份控制措施，便可将其应用于所有地方。这意味着盲点更少、响应速度更快、攻击面更小，而且无需借助十种不同的工具就能实现这些目标。

别让NHI成为你最大的盲点

人工智能智能体和非人类身份已经在重塑你的攻击面。它们的数量增长速度超过了大多数团队的追踪能力，而且太多的智能体和非人类身份在运行时缺乏明确的归属、有力的控制或任何真正的可见性。

你无需从头开始重建策略。但你确实需要像对待非人类身份本身那样对待它们：它们是关键的访问点，理应获得与任何用户同等的治理。

借助统一的身份平台，安全团队可以清点正在运行的内容，应用可扩展的控制措施，并在风险访问被利用之前（而非之后）切断它。