在现代环境中管理非人类身份的生命周期

导言：为什么非人类身份的生命周期值得关注

非人类身份（Non-human identities，NHIs）涵盖所有凭据或身份构造，使系统、应用程序或自动化流程能够在不直接涉及人工账户的情况下完成身份验证并与其他资源交互。NHIs包括：为应用程序或服务专用的服务账户（service accounts）、用于访问外部服务的静态令牌（API keys）、OAuth令牌或JWT令牌等生命周期较短的令牌（short-lived tokens），以及用于CI/CD流水线、配置管理工具或RPA工作流的自动化凭据（automation credentials）。在基础设施多样且自动化流程复杂的组织中，NHIs的数量往往比人类用户多出十倍或更多。即使是中型组织也可能拥有数百个NHIs，而大型企业则可能拥有数千个。欲了解更多关于NHIs类型和安全挑战的信息，请参阅我们的文章：non-human identity security。

人的身份生命周期管理已建立且成熟：由人力资源驱动的工作流使 IT 能够以 RBAC 角色和定期访问审查为基础，管理员工在入职（joiner）、调岗（mover）和离职（leaver）阶段的账号开通（provisioning）与回收（deprovisioning）。另一方面，NHI 没有明确定义的管理结构。它们往往由开发人员或 DevOps 团队以临时方式按需创建，为了方便授予过度或过宽的权限，缺少文档化的归属负责人，并配置为很少轮换的静态凭据（static credentials）。

缺少正式的 NHI 生命周期管理，组织将面临三项挑战：

• 身份蔓延（Identity sprawl）： NHI 在基础设施中无法控制地不断增加，导致治理极其困难——因为你无法审查和保护你找不到的内容。
• 孤立凭据（Orphaned credentials）： 已失去合法所有者或用途，但仍处于活跃状态的 NHI。由于没有团队在实际使用它们，它们会作为攻击者可利用的隐藏风险长期存在。
• 安全盲区（Security blind spots）： NHI 通常会超出 SIEM 或 SOAR 等安全工具的监控范围。这类工具的调优重点是检测由人类账号发起的可疑活动。身份治理平台同样以人类账号为中心，通常不包含 NHI，从而使重要的攻击面长期处于敞开状态。

本文聚焦 NHI 生命周期的五个阶段：从发现和创建开始，直至监控、风险管理以及安全退役（decommissioning）。

在当今的 IT 生态系统中定义非人类身份（non-human identities）

非人类身份（Non-human identities，NHIs）是分配给能够自主运行的机器、应用程序、服务、容器、脚本以及自动化流程的数字身份。无需人工交互，它们会进行身份验证、获得对特定权限的授权、访问资源，并在 IT 系统中以编程方式执行操作。例如，托管在 AWS 上的应用可能会使用 IAM 角色来访问存储文件；或者在 Kubernetes 中运行的微服务可能会使用服务账号与其他服务进行通信。

NHIs 会使用面向机器的机制进行身份验证，例如 API 密钥、共享密钥（shared secrets）、证书、JWT 或 OAuth 令牌，以及工作负载身份。与人的账户不同，它们不会以交互方式登录，也不以传统意义上的密码进行认证，并且往往依赖于已存储的凭据。由于它们自动运行，NHIs 可能以极快的速度执行数百甚至数千次操作，因此必须以与人的身份相同的安全控制和标准来进行治理（governance）。

NHI 在当今复杂的 IT 基础设施中至关重要。现代组织必须采用云原生的部署架构，而微服务与 DevOps 实践要求以机器到机器的通信作为基础。

• API 交互： 现代应用程序高度依赖 API。应用程序使用 API 与数据库、支付网关、存储服务、监控工具以及第三方 SaaS 平台进行通信。上述每一种交互都由 NHI 提供支持，并且都需要身份验证。
• DevOps 和 CI/CD 管道： 持续集成与持续部署管道会自动化软件构建、测试和部署。这些管道使用 NHI 代理来对源代码仓库、制品（artifact）注册表、容器平台、用于部署的云环境以及通知工具进行身份验证。每一次交互都需要使用不同的 NHI 进行身份验证，而这些身份往往具有更高的权限。
• 云工作负载： 云原生环境会动态创建并销毁诸如虚拟机、容器、无服务器函数以及 Kubernetes Pod 之类的工作负载。这些工作负载会被分配 NHI，用于访问存储、查询数据库以及访问消息服务。所有这些 NHI 在创建、变更和停用过程中，都需要具备适当可视性的生命周期管理。
• 计划任务与自动化： 除了云和 DevOps 之外，传统 IT 环境也依赖 NHI 来处理批处理作业、定时脚本、数据同步任务、备份服务以及监控代理。这些自动化任务通常在具有更高权限的服务帐户下运行，而且并不经常轮换、监控或得到恰当限制。

组织管理的常见非人类身份类型

服务账户和应用身份： 这些身份是为应用程序、服务和流程专门创建的专用非交互账号，用于进行身份验证并安全访问资源。例如，薪资应用程序使用服务账户连接到 SQL 数据库以访问员工数据，可以在人员变动时确保业务连续性。这类身份通常是固定的凭据或密钥，变更频率低；随着时间推移往往会累积过多的权限，并且经常在多个应用程序和环境之间共享。

API 密钥、令牌和证书： 这些身份用于机器到机器（machine-to-machine）的交互。应用程序和服务不再通过用户名和密码登录，而是使用这些身份来安全地标识自身。API 密钥通常是由服务（如 AWS、Entra ID 或 Stripe）签发的静态密钥字符串，用于识别并授权发起调用的应用程序。OAuth 或 JSON Web Tokens（JWT）是在身份验证事件之后签发的短生命周期令牌，可在不进行额外验证的情况下向持有者授予访问权限。基于 PKI 的证书用于双向 TLS 身份验证、代码签名以及服务网格通信。尽管这些证书带有到期日期，但未管理的证书是导致服务中断的主要原因之一。

云工作负载与容器身份： NHIs 会动态分配给虚拟机、容器、无服务器函数以及 Kubernetes Pod。这些工作负载既会彼此交互，也会与云外的其他云平台或本地（on-premises）基础设施进行交互。虽然托管身份减少了对硬编码密钥的需求，但与这些工作负载所使用的 IAM 角色相关的权限配置错误，往往是攻击者的首要目标。

DevOps、CI/CD 和自动化身份： DevOps 环境高度依赖自动化身份。诸如 Jenkins、GitHub Actions、GitLab CI 和 CircleCI 这样的 CI/CD 流水线工具，需要凭据来检出代码、推送制品、部署到云环境以及更新基础设施。Terraform 和 Ansible 等基础设施即代码（Infrastructure-as-Code）工具，需要具备广泛权限的云服务商凭据。若这些自动化身份遭到入侵，攻击者可能会立即获得对生产环境的控制权。

AI 代理与自主系统身份： 随着组织以更快的速度采用由 AI 驱动的自动化，一类新的 NHI 正在出现。 这些 AI 代理与自主系统身份代表了与企业系统交互的 AI 共同助手、执行运营任务的智能机器人、访问数据管道的机器学习模型，以及用于填写表单并转换数据的机器人流程自动化（RPA）机器人。组织在部署这些 AI 代理时必须谨慎，并且需要定义一个身份生命周期管理系统：对访问范围进行控制与监控，并保留审计追踪（audit trail）。

人与非人身份：生命周期对比

人类与非人身份都需要治理；然而，它们的生命周期在结构、所有权、风险画像与运营行为方面存在本质差异。传统 IAM 流程主要为人类用户设计，而当将其直接套用于 NHI 时，往往无法提供足够的控制。

传统 IAM 工作流是围绕人的雇佣生命周期来设计的。它们假设账号所有权清晰，并且 HR 状态会触发事件。NHI 不遵循这些模式，因此需要专门构建的生命周期管理：它们没有 HR 记录、没有管理者、没有交互式登录事件，也没有自然的离岗/下线时间表。

非人身份的生命周期究竟包含哪些内容

NHI 需要像人类用户一样进行结构化的生命周期管理，但管理方式必须适应自动化、机器到机器通信以及高速可扩展性等场景。以下是 NHI 生命周期的五个关键阶段：

采用生命周期方法来治理 NHI，可确保不存在任何安全盲区。每个阶段都相当于一种安全控制：缺少发现会导致“影子身份”，预置过于薄弱会导致特权不断攀升（privilege creep），缺少监控意味着泄露与入侵仍会保持未被发现，没有凭据轮换则意味着一把泄露的密钥就能获得持续访问权限，而不进行退役会留下孤立的凭据，从而创建未被发现的持久化后门。

阶段 1：非人类身份的发现与盘点

发现（Discovery）是管理非人类身份的关键第一步，因为安全领域的第一条规则是“你无法保护看不见的东西”。在应用任何治理（governance）、策略（policy）或安全控制之前，组织必须建立覆盖其环境中每个 NHI 的全面、准确且持续更新的清单。

发现（discovery）需要什么

持续扫描： NHIs 并非静态。开发人员会按需预配服务账户，CI/CD 流水线会生成短生命周期令牌，而云原生工作负载会动态创建新的身份。基于某一时间点的审计只能捕获很快就会过时的快照。有效的发现（discovery）需要持续、自动化的扫描，并可按计划或事件触发运行，以便在身份出现的同时检测到新创建的身份。

跨环境覆盖： 现代组织在混合与多云环境中运行。发现（discovery）必须持续扫描本地目录，例如 Active Directory；以及 AWS、Azure 和 GCP 中的云 IAM 系统、SaaS 平台、容器编排系统和密钥保管库（secrets vault）。如果发现仅限于一两个环境，NHI 的攻击面将有很大一部分仍然无法被看见。

属性映射： 发现（discovery）不仅仅是列出身份；还必须捕获每个身份的完整上下文，以便实施安全与治理控制。这包括为每个 NHI 映射关键属性，例如：该身份由哪个团队或个人拥有、它服务于什么业务功能、哪些系统或服务依赖它，以及凭据上次何时轮换。

常见的发现（discovery）挑战

1. 与集中存储在 HR 系统或主要身份提供方中的人类身份不同，NHI 通常并不会存在于单一位置。它们可能分散在云平台的 IAM 控制台、服务器上的本地服务账户配置、存放在保管库（vault）中的密钥，以及嵌入在配置文件或代码仓库中的 API 密钥中。身份的分散会导致在没有专门的 NHI 管理工具的情况下，难以获得准确的清单。
2. 与从 HR 系统同步到集中式目录（directory）的人类身份不同，NHI 通常没有权威的源系统（authoritative origin system）。多 个身份可能承担相同的功能；在应用程序退役（retired）之后，即使身份变为孤儿（orphaned），仍可能保持激活状态；而且在不同环境中可能存在重复的凭据。安全团队必须汇总并关联来自多个来源的数据，才能构建统一的清单平台。
3. 在进行 NHI 发现时，最具挑战性的情况之一是“影子身份”（shadow identities）。开发人员和 DevOps 工程师经常在正式的配置（provisioning）流程之外，为快速修复、测试以及加速部署创建身份。这些身份缺乏适当的文档和权限范围（scope），因此风险很高，而且也很难被发现。

阶段 2：安全的配置（provisioning）与访问权限分配

第一道防线是配置（provisioning）阶段。NHIs 的创建方式会决定其在整个生命周期中的风险画像（risk profile）。如果某个身份拥有过多权限、且没有文档说明并且没有明确的责任归属，那么它就会成为一种可能在多年内未被发现、持续存在的风险。

预配最佳实践

标准化创建流程： 每个 NHI 都必须通过预先定义且可重复的流程创建，并且访问权限应与基于角色的访问控制（RBAC）或基于属性的访问控制（ABAC）模型相一致。这意味着需要为诸如服务账户、API 密钥以及 CI/CD 管道令牌等常见身份类型建立获批准的模板，以确保不会有任何 NHI 在超出治理策略的情况下进入环境。

从一开始就实施最小权限原则： 在 NHI 预配中，最大的风险之一是：在开发阶段授予了过宽的访问权限，而这些权限在上线到生产环境后就变成了永久权限。 最小权限原则 必须在创建身份时就应用：明确具体的系统与 API 需求，仔细评估应授予哪些权限，避免在云端 IAM 策略中使用通配符权限，并从最小访问权限开始。

指定负责人： 每个 NHI 都必须绑定到个人、角色或团队，以建立明确的负责人/所有者。必须在变更管理数据库（Change Management Database，CMDB）和 IAM 平台中定期更新负责人信息，以确保任何需要进行的修改都要与所有者沟通并获得其批准。如果所有者离开组织，必须立即重新分配所有权。

设置到期日期： 许多 NHI 是为临时项目、迁移、测试环境、供应商集成以及短期自动化任务而创建的，但在需求到期后，它们很少会被停用。为每个 NHI 指定生存时间（Time to Live，TTL）。当 TTL 到期时，所有者必须重新评估是否仍有必要；如果未获批准，该 NHI 必须自动从系统中移除。

应避免的配置（Provisioning）陷阱

• 过度权限： 在交付压力下，团队往往会“为了让事情能运转”而直接授予过度权限。通常在系统开始正常工作后，这些过度权限很少会被收回或削减，从而形成隐蔽的权限升级路径；这些路径可能成为横向移动（lateral movement）的机会，或导致严重的合规性违规。
• 从现有 NHI 复制权限： 创建新身份时，假设复制权限是被批准的做法，那么从现有身份复制权限会更容易。然而，这会带来诸如继承过时或过度权限等问题，而这些权限从未经过正式批准。
• 在缺少文档和责任归属的情况下创建 NHI： 当在没有文档的情况下创建 NHI，且未更新资产清单（inventory）时，安全团队无法将其纳入范围，风险评估会变得过时，并且也没有事故响应或退役（decommissioning）的计划。

第 3 阶段：持续监控与行为监督

一旦为 NHI 完成配置，安全工作就不会停止。它会转向持续监控：不仅是定期进行静态访问审查，还要监控权限是如何被使用的，以及角色和权限如何随时间演变。持续监控能够确保 NHI 正在做的事情与它应该做的事情保持一致；如果发现偏离，就可以通过调查和修复来阻止偏离发展为事件。

需要监控什么

使用模式：理解并监控 NHI 的运行频率以及其运行所处的上下文，有助于建立对相关风险的认知基础。NHI 是每天都在运行，还是仅在一周或一个月的最后几天才运行？如果它原本每小时处理 100 个请求，那么突然激增到 10,000 个请求的原因是什么？如果在通常的运行窗口之外出现使用频率或调用量的激增，可能表明已遭到入侵或被误用。若某个 NHI 长期不处于活动状态，也可能意味着它所属的服务已被退役，但其凭据从未被撤销。

访问范围：监控 NHI 访问的内容（例如资源、API、数据存储或服务）对于实现可视性以及确保实际运行时的行为与预期的访问设计一致至关重要。即使 NHI 运行正常，过度的访问仍可能构成潜在风险。对访问范围的可视性必须包括定期访问审查、角色分配，以及基于访问关键性进行的风险评分。

异常变更：任何访问变更，尤其是意外或未经授权的变更，都应作为安全团队的红色预警信号。这包括新的角色分配、策略绑定、组成员变更，或未纳入变更管理流程的密钥/机密访问授权。由于 NHI 无法自行发起请求，意外的访问变更应被视为可能的恶意活动、内部人员滥用或自动化配置错误，并且必须立即展开调查。

权限漂移： 随着时间的推移，NHI 往往会为不同任务或临时项目累积权限，并获得超出最初预期的更多访问权限。常见原因包括项目扩展、为故障排除而添加但从未移除的临时访问，以及由于复杂的组嵌套导致的角色继承变化。必须通过将当前权限与基线权限模板进行对比，严格监控权限漂移。

日志记录与合规

NHI 活动日志并非可选项；它们与人类活动日志同样关键，用于 合规要求、审计就绪以及事件响应。诸如 PCI DSS、HIPAA、SOC 2 和 GDPR 等框架都要求对系统访问进行可追溯性、责任追究以及审计追踪，无论是人类账户还是非人类身份。

• 可追溯性： 每一个自动化操作都必须能够归因到特定身份，以便确定其所有者。
• 审计证据： 组织必须能够证明谁访问了敏感系统、访问发生在何时、执行了哪些操作，以及该访问是否获得授权。
• 事件调查： 在对安全漏洞进行取证调查时，身份日志有助于判断凭据是否已被泄露，追踪横向移动的路径，确定数据外传的范围，并建立清晰的时间线以重建攻击事件。

第 4 阶段：凭据风险管理

长期有效的密钥（Long-lived secrets）是非人身份安全中最危险的方面之一，并且代表一种系统性风险。与通过策略强制要求密码更换、且 MFA 叠加了额外安全层的人类凭据不同，NHI 凭据往往会在数月甚至数年内保持不变。如果这些凭据发生泄露，它们会一直处于可被主动利用的状态，直到权限被明确撤销或身份被删除。

为何轮换（rotation）至关重要

未被发现的暴露： 凭据可能会通过日志、开发者环境或复杂技术泄露，而不会触发任何告警。如果某个密钥（secret）不小心提交到 Git、通过配置错误的云存储桶（cloud storage bucket）暴露，或从内存或日志中被提取，攻击者就会获得持久访问权限，而组织却完全不知道已经发生了入侵。

轮换可限制爆炸半径： 轮换相当于对潜在被攻破的“时间上限”。通过频繁更换凭据，具备静默访问能力的攻击者会被自动撤销权限。比如，如果每 24 小时轮换一次密钥，被盗的密钥到了第二天就会失效。有效期仅 15 分钟的短生命周期令牌，只能将暴露时间限制在 15 分钟内。其核心原则很简单：秘密存在的时间越长，就越可能已经通过某种未被检测到的攻击途径而暴露。

合规与治理： 现代的安全与合规框架明确要求凭据管理控制，并不再将凭据轮换视为“可有可无”，而是将其作为必须的控制措施。审计人员需要证明服务账号凭据轮换的频率、轮换是否自动化，以及当密钥（机密）暴露时会发生什么。

轮换最佳实践

制定轮换策略： 按设计而言，手动轮换凭据并不可靠，因为团队可能会忘记或缺乏明确的责任归属。正式的轮换策略应当明确：哪些凭据必须轮换、每种凭据类型的最大生命周期、轮换的责任归属与负责人是谁，以及应当使用哪些工具。通过策略驱动的轮换，可确保在不同环境中的一致性，并形成清晰的审计追踪记录。

设置轮换计划： 并非所有凭据的风险都相同，因此应相应调整轮换频率。高权限的服务账号应每日或每周轮换；具有广泛权限的云 API 密钥应每周或每月轮换；用户访问令牌应保持短生命周期（有效期以分钟计，而不是按天）。目标是让轮换成为后台流程，而不是按周期触发的应急控制措施。

对暴露情况立即响应： 轮换（Rotation）不应仅基于时间；必须基于持续监控实现事件驱动。当怀疑或确认发生泄露（compromise）时，组织需要制定明确的凭据（credential）事件响应流程，并在发现情况的第一时间触发。检测到暴露后，应由自动化流程撤销已受损的凭据，生成新的密钥（secret），更新所有依赖的服务，并记录相关信息且通知相关干系人。

第 5 阶段：停用并离场（offboarding）非人类身份

停用（Decommissioning）往往是非人类身份生命周期中最容易被忽视的阶段。尽管组织将重点放在创建（provisioning）和监控（monitoring）上，NHI 退役（retirement）通常发生在非正式的活动期间，或者根本不发生。因此，大量孤儿 NHI 会以“幽灵账号”（ghost accounts）的形式留在系统中，形成隐藏的攻击面。

识别需要停用（decommissioning）的 NHI

有效的停用（decommissioning）始于可见性（visibility）。组织必须主动发现那些不应再存在的 NHI。

未使用的身份： 许多 NHIs 是为短期项目、临时集成、测试环境或迁移计划创建的。项目结束后，这些 NHIs 会继续保留在系统中，并仍然拥有有效的凭据（credentials）。应制定一项策略，用于评估何时某个 NHI 不再被使用，例如在定义的时间范围内（30、60 或 90 天）没有任何身份验证事件。

孤立的身份： 当 NHIs 的所有者或负责团队离开组织、被重新分配到其他项目，或在未进行 NHI 清理（cleanup）的情况下，NHI 创建时所对应的应用被下线时，NHIs 就会变成孤立状态。缺少所有权（ownership）意味着没有人来审查访问权限、轮换凭据（rotate credentials）或监控异常活动。孤立的身份尤其危险，因为它们在系统中看起来是合法的，但却没有任何监督。

重复的身份： 在分散式 DevOps 环境中，多个团队可能会为相同的任务创建独立的身份，从而导致冗余的服务帐户、重叠的 API 密钥，或拥有相似访问权限的多个凭据。重复身份会增加复杂性和风险，因为审计追踪（audit trails）更难维护，而且撤销其中一个身份的访问权限，并不能消除访问风险。

安全的退役（下线）流程

未经过仔细验证就移除 NHI 本身就存在风险。它可能会导致生产环境中的应用或依赖服务中断。退役流程应以系统化的方式执行。

1. 识别与画像： 使用自动化发现工具，根据身份是否处于不活跃状态或缺少有效负责人，关联的应用或服务是否已退役，或确认该 NHI 为重复身份等情况进行标记。识别到的 NHIs 应提交给应用负责人、安全团队和 DevOps 团队进行审查。
2. 依赖关系验证： 在禁用或删除某个 NHI 之前，请确认它并未在实际运行中支持任何后台任务、计划的自动化任务、第三方集成、灾难恢复流程或遗留系统。依赖关系检查需要审阅认证日志、检查 CI/CD 配置、扫描基础设施即代码（infrastructure-as-code）模板，并咨询应用负责人。
3. 先禁用再删除： 切勿立即删除。最佳实践是分阶段移除：先禁用认证能力，监控是否出现失败或系统错误，设置并保留定义好的宽限期（7 到 30 天），如果确认没有影响则再永久删除。这样可以让团队验证任何潜在影响，并支持快速回滚。
4. 为审计目的记录移除操作： 在完成退役（decommissioning）的所有阶段后，执行“硬删除（hard delete）”，并确保该操作已记录在 SIEM 平台日志中，以便形成审计追踪。请记录必要信息，包括带有唯一标识符的身份名称、关联系统与权限、移除原因、审查与审批工作流细节以及删除日期。

NHI 生命周期管理中的常见易错点

Netwrix 如何支持 NHI 生命周期管理

Netwrix Identity Manager 提供全面的身份治理与管理（IGA）框架，可在一个平台上通过自动化的生命周期流程管理人类账户和非人类身份。Netwrix Identity Manager 构建集中式身份存储库，包含所有身份类型，以创建统一的资产清单（inventory），作为身份生命周期管理的基础。

发现与盘点： 包括 NHIs 在内的所有身份类型都会同步到集中式 Identity manager 存储库中，从而提供可视性并减少身份蔓延。连接器会从不同目录（Active Directory、Microsoft Entra ID）以及业务应用程序中拉取身份和权限数据，将 NHIs 纳入与人类身份并行的治理范围。

受控配置： 为每个身份定义了标准化的配置工作流，减少了具有过多权限的临时配置。当请求创建身份时，会触发基于策略的工作流，执行最小权限原则，仅配置身份角色所需的访问权限。基于角色的访问控制确保身份仅获得其职能所需的权限。

持续监控与审查： Netwrix Identity Manager 会跟踪其所管辖的所有身份的权限（entitlements）、变更事件以及合规状态。它提供内置的访问认证活动（access certification campaign）能力，并结合风险分析来识别 NHIs 何时累积了过多权限，同时监控访问模式和资源使用情况。它有助于发现处于休眠状态或孤立的身份、权限不断膨胀（privilege creep），以及针对人类与非人类身份的职责分离（segregation of duties）违规。

访问修复与清理： Netwrix Identity Manager 允许组织将每个身份的权限与策略规则进行对照分析。对于不再需要访问权限的 NHIs，或拥有超出策略允许范围的权限的 NHIs，都可以标记为需要进行修复（remediation）。还可以定义规则，用于识别在设定时间内未登录的未使用账户（例如 90 天）、其所有者不在场的孤立 NHIs，或在访问认证过程中发现的过多权限。

生命周期收尾： Netwrix Identity Manager 会使用全面的工作流自动化执行入职（joiner）、调岗（mover）、离职（leaver）的处理（joiner-mover-leaver，JML）。当应用或服务退役、项目结束，或人类所有者离开/转入下一个项目时，Netwrix Identity Manager 会确保相关的 NHIs 撤销权限，并最终将其删除。

结论：从身份膨胀到生命周期管控

在现代 IT 基础设施中，非人类身份（non-human identities）已成为占主导地位的身份类型，而且不会消失。它们正在以指数级增长。每一种新的自动化机制、每个云工作负载以及每个 AI 代理都会不断扩大日益增长的 NHI（NHI）足迹。随着从单体应用设计转向微服务，这意味着每个与其他服务通信的子服务都需要多个身份。像虚拟机、无服务器函数、容器和托管服务这样的云工作负载，都需要更多的 NHIs。DevOps 流水线在很大程度上依赖服务主体（service principals）、部署令牌（deployment tokens）、Git 集成、API 凭据以及构建代理（build agents）。目前，NHIs 的数量已按 10:1 的比例超过人类身份，而且这一比例仍在继续上升。

NHI 生命周期管理将 NHIs 从不断增长的风险转变为一种受治理的资产类别，使组织能够以更有效的控制来管理 NHIs，并满足其所带来的规模与影响所必需的要求。通过覆盖每个阶段（发现、配置/部署（provisioning）、监控、轮换（rotation）以及退役/停用（decommissioning）），组织可以减少身份蔓延（identity sprawl），强制执行最小权限，并弥补传统 IAM 无法针对 NHIs 解决的安全漏洞。