非人类身份（NHIs）解析及如何保障安全

大多数组织无法生成其环境中运行的非人类身份（NHIs）的完整清单。服务账号、API 密钥和应用凭据会在 Active Directory（AD）以及云平台中不断累积，通常缺乏清晰的责任归属、文档化用途，或明确的定期审查周期。

这种差距带来真实风险。根据 Netwrix 2025 Cybersecurity Trends Report，去年有 46% 的组织遭遇了账户被攻陷（compromise），高于 2020 年仅 16%。像服务账号和令牌这样的机器到机器（machine-to-machine）身份，正日益成为这一趋势中的重要因素，而大多数中型市场的 IT 团队缺乏足够的可视性，无法有效管理这些身份。

网络安全中的非人类身份（NHIs）是什么？为什么它们很重要？

非人类身份（NHIs）是数字凭据，使机器、应用程序和自动化流程能够在无需人工介入的情况下进行身份认证并访问资源。服务账号、API 密钥、托管身份（managed identities）、OAuth 令牌以及 AI 代理都属于 NHI 的范畴。

它们的数量正在快速增长。每一个云资源、CI/CD 管道、自动化工作流以及 AI 集成都会产生新的 NHI（非人类身份），这些身份需要凭据和权限。在大多数组织中，机器身份的数量会比人类用户多出 10:1 或更多。

当你的备份软件在凌晨 2 点连接到数据库时，它并不会输入密码。它会使用带有已存储凭据的服务帐户进行身份验证。这就是一个 NHI。你的工单系统用来拉取 CRM 数据的 API 密钥，或用于同步员工记录到 Entra ID 的 OAuth 令牌，同样适用这种情况。

正如 Netwrix 首席产品官（Chief Product Officer）Jeff Warren 在《2025 网络安全趋势报告》中所指出的那样，身份驱动型攻击很可能会进一步占据主导地位，其中“滥用类似服务帐户和令牌的机器到机器（machine-to-machine）身份”也成为新兴攻击向量之一。

人类身份 vs 非人类身份

人类身份与非人类身份在所有权、身份验证、管理和监控方式上存在差异：

• 所有权： 人类身份的所有者很明确。NHI 的所有权往往是共享的或不清晰，导致难以强制执行问责制。
• 认证： 人类使用与 MFA 结合的密码。NHI 使用密钥、令牌和证书，而 MFA 不适用。
• 生命周期： 人类身份遵循由人力资源驱动的流程（入职、角色变更、离职）。NHI 则由开发人员和管理员按需临时创建，并没有相应的生命周期管理。
• 行为： 人类的访问是交互式且多变的。NHI 的访问是程序化且重复性的，这使得异常检测既更容易建立基线，又更难在规模化环境下进行审查。

密码策略、MFA、SSO 和访问审查并不能与 NHI 完整对应。这就是为什么机器身份需要其自身的治理（governance）方式。

相关术语“machine identity（机器身份）”特指基础设施层面的身份，例如服务器、虚拟机（VM）和证书。NHI 的范围更广，除上述内容外，还涵盖 API keys、tokens（令牌）和 bots（机器人）等应用程序层面的凭据。

非人类身份认证方法

NHI 会以编程方式进行身份认证，而不是通过交互式登录，主要有四种方式：

• 基于令牌： API keys、bearer tokens 和 JWT tokens
• 基于密钥： SSH keys 和 service account keys
• 基于证书： X.509 证书和双向 TLS（mTLS）
• 工作负载身份联合： 如 AWS IAM 角色、Azure 托管标识和 GCP 服务账号等云原生机制

四种情况都存在的关键风险是 MFA 和 SSO 不适用。当凭据被泄露时，没有第二个验证因素来阻止被利用，攻击者会继承该身份所拥有的任何访问权限。

常见的非人类身份类型

了解您环境中不同类型的 NHIs，是有效管理它们的第一步。以下类别代表了您在本地和云环境中最常见的非人类身份。

1. 服务帐户与应用身份

服务帐户是专门的帐户，使应用程序能够在没有人工凭据的情况下执行任务。您的备份软件使用它来访问 SQL Server 数据库，而监控工具使用它来收集性能数据。在 AD 环境中，这些帐户可通过 ServicePrincipalName (SPN) 属性进行识别。

核心安全挑战在于密码很少更改。现代最佳实践是迁移到 Group Managed Service Accounts (gMSAs)，它通过 Active Directory 提供自动密码管理，并消除对手动管理员干预的需求。

应用身份将这一概念扩展到云原生环境：云平台会为应用程序分配专用身份，以访问 API、数据库以及其他云资源。

2. API 密钥和机密信息

API 密钥和机密信息的基本功能相同：让一个系统在无需人工参与的情况下对另一个系统进行身份验证。它们被嵌入到内部工具、SaaS 集成以及第三方服务连接中，用于授予可编程访问权限，而不需要某个人登录。

这种第三方类别的范围往往比多数团队意识到的要广。比如，打印机为了进行耗材监测与其制造商通信时，或者制造设备将遥测数据发送给 OEM 以便进行远程维护时，这些连接依赖于 API 密钥或嵌入式凭据，从而能够在组织边界之间完成身份验证。由于这类由供应商管理的 NHIs 通常由供应商进行配置，而不是由你们的 IT 团队提供，因此它们往往不在标准身份治理的覆盖范围之内。

这些情况面临的共同挑战在于它们的静态特性。与绑定到用户账户的密码不同，大多数系统中的 API 密钥默认不会过期，并且往往会被写入配置文件、代码仓库、环境变量，甚至聊天记录中。

存储在金库（vault）或配置文件中的机密信息也是同样的情况，包括密码、连接字符串和加密密钥。这些凭据与任何 API 密钥一样都存在相同的访问风险，但通常受到的审查更少。

一旦泄露，这些凭据中的任何一项都可能被立即利用，而组织往往直到它已经被使用之后才知道自己曾发生过暴露。当被攻破的凭据属于第三方集成时，影响范围会从你们的环境扩展到受 NIS2 和 DORA 等框架约束的供应商关系；两者都要求对数字服务依赖实施供应链风险控制。

3. 托管身份

托管身份体现了 Microsoft 在 Azure 中进行 NHI 身份验证的现代做法。系统分配的托管身份会直接绑定到特定的 Azure 资源，从而完全不需要存储凭据。用户分配的托管身份可以在多个资源之间共享。

不过，托管身份只能在 Azure 生态系统内解决该问题。运行混合环境的组织仍需要了解本地（on-premises）的服务账号，以及托管身份无法覆盖的跨平台凭据。

4. OAuth 令牌

OAuth 令牌 用于在应用之间启用委派访问。当你的 HR 平台将员工数据同步到身份提供方，或你的报表工具从 SaaS CRM 拉取记录时，这些连接会依赖 OAuth refresh tokens 来维持持久访问。

这些令牌的有效期往往比预期更长，并随着团队将更多工具连接在一起而在你的 SaaS 集成中不断累积。

5. 云工作负载与容器身份

工作负载身份包括分配给容器化应用、无服务器函数以及云工作负载的凭据。你的 Kubernetes 部署、Azure Container Instances 和 AWS Lambda 函数都需要凭据来访问其他服务。

云平台会为这些工作负载分配身份，包括虚拟机（VM）、容器、无服务器函数以及 Kubernetes pods，以便访问云资源、存储和 API。这些工作负载身份会被快速创建和销毁，往往会超出安全团队跟踪它们的能力。

6. 机器与设备身份

物理机和虚拟机、物联网设备以及基础设施组件都各自拥有自己的身份。证书常用于对这些机器身份进行认证，从而形成一层与应用级凭据重叠但又超出其范围的 NHI 治理。随着物联网的采用不断增长，这种身份群体也随之扩大。

7. 机器人和 AI 代理

机器人和 AI 代理 代表了最新且增长最快的非人类身份类别。例如：

• 要让 Microsoft Copilot 真正发挥作用，它需要访问你的文件和电子邮件
• 机器人流程自动化（RPA）bot 需要凭据才能与业务应用交互。
• CI/CD bot 需要访问权限来部署代码。
• 编排工具和 AI 代理以非人类身份运行，通常拥有较广泛的访问权限，以支持自动化工作流。

每一种都会创建需要与任何其他 NHI 一样接受相同治理的身份关系，但它们往往由业务团队在缺少安全审查的情况下快速开通。

额外的风险在于，AI 工具会与代码仓库和开发环境进行交互。这可能会在提示（prompts）、输出（outputs）和日志（logs）中无意间暴露凭据，从而形成传统机密扫描不一定能发现的泄露途径。

这些身份类型中的每一种都需要不同的管理方法，但它们都面临共同的治理挑战：所有权跟踪、凭据轮换，以及在不再需要时进行停用/退役。

如何在你的环境中发现非人类身份

在对 NHIs 进行治理之前，你需要先找到它们。结构化的发现流程有助于你了解问题的范围，但大多数组织很快就会意识到，手动方法只会触及表面。

从你的身份提供方开始

在 Active Directory 中查询具有服务主体名称（Service Principal Names）、独立托管服务帐户（standalone managed service accounts）以及组托管服务帐户（group managed service accounts）的账户。

对于云环境，请从您的身份提供方（identity provider）的管理控制台中拉取服务主体（service principals）、应用注册（app registrations）和托管身份（managed identities）的清单。针对每个身份重点关注四个属性：它被哪个应用使用、它持有什么凭据（credentials）、它可以访问哪些资源，以及它由谁拥有（who owns it）。

扩展到代码与自动化层

与您的 DevOps 团队合作，识别存储在 CI/CD 管道（pipeline）配置、基础设施即代码（infrastructure-as-code）模板和环境变量中的凭据（credentials）。代码库扫描工具可以标记已经提交到版本控制（version control）中的硬编码凭据和 API 密钥（API keys）。这通常也是未经跟踪的 NHIs（Non-Human Identities，非人类身份）最常存在的地方。

审计您的 SaaS 集成

检查您所有 SaaS 应用中的 OAuth 授权（OAuth grants）和 API 连接。许多组织会发现：在数月或数年前由现已离开团队或公司的人员创建的集成中，存在数十个处于激活状态的 OAuth 令牌（tokens）。

记录你所发现的内容

针对您发现的每个 NHI，记录所有者（个人，而不是团队）、业务上的合理性、凭据类型与轮换状态，以及上一次有人确认“仍然需要”的时间点。这个清单将成为后续所有工作的基础。

一个重要的注意点：手动发现只能为您提供某个时间点的快照，而不是“实时”的资产清单。环境每天都在变化，而按季度导出的结果无法捕捉到上周二有人创建的那个服务账号。

持续、自动化的发现能力，正是区分那些真正了解其 NHI 规模的组织与那些仅仅“以为”自己了解的组织的关键。

如何保护并治理非人类身份

非人类身份管理（Non-human identity management，NHIM）是发现、治理并保护机器身份的实践，而传统的 IAM 和 Privileged Access Management(PAM) 并非为处理这类身份而设计。

这意味着：在没有人类主体的情况下对访问进行治理，管理无法使用 MFA 的凭据，并追踪由开发人员和自动化创建的身份的所有权，而不是由人力资源流程创建。

一旦你识别出环境中存在的内容，治理就能确保其始终处于受控状态。有效的 NHI 安全会在身份安全计划中将机器身份视为“一级公民”，并为其生命周期的每个阶段制定明确的策略。

下面是它在实践中的样子：

• 在创建时为每个 NHI 指定所有者： 不应存在任何没有明确个人负责其访问权限和生命周期的身份（不是分发列表，也不是团队别名）。在你的配置/开通（provisioning）流程中将“所有权”设为必填字段。
• 从第一天起实施最小权限： 只授予每个 NHI 为其功能所需的特定权限，并将范围限定在尽可能细的资源级别。对于仅需要访问单个应用程序的服务账户，请避免授予涵盖整个订阅或整个域的权限。
• 尽可能实现凭据轮换自动化： gMSA 会为本地（on-premises）的 AD 工作负载自动处理这一点。对于云端的服务主体（service principals）和 API 密钥，请将轮换集成到部署流水线中，或使用机密管理（secrets management）解决方案。

合适的轮换节奏取决于凭据类型和暴露风险。因为像 NIST、CIS 以及 PCI DSS 并不要求对特权账户设置统一的轮换周期。

• 监控行为异常： 如果某个服务账户突然访问了其正常模式之外的资源，或某个 API 密钥从不熟悉的位置进行身份验证，就应触发警报。监控应聚焦于与既定基线（baseline）出现偏差，而不是试图审查每一条事件。
• 积极停用（Decommission）： 过期的 NHIs 是任何环境中最容易被利用的薄弱环节之一。把停用触发条件写入流程：如果某个身份在 90 天内没有进行身份验证，就标记为待审查；如果负责人无法说明其用途，就将其禁用；如果再过 30 天仍无人发现，就将其移除。
• 按定期计划对访问进行认证： 要求 NHI 拥有者重新验证每个 identity 是否仍然需要其当前权限。年度复审是一个起点，但对于特权 identity，按季度复审更好。

这些控制项会直接对应到已嵌入主要合规框架中的要求：

• CMMC Level 2 要求为所有 identity（包括非人类身份）提供访问控制和账户管理
• SOC 2 信任服务准则要求实施扩展到非人类身份的访问控制
• HIPAA 要求对 Protected Health Information 的所有访问保留审计追踪（audit trails），包括自动化流程和服务账户的访问
• NIS2（欧盟）要求组织管理 ICT 供应链风险，包括访问你们环境的第三方服务凭据以及由供应商管理的身份
• DORA（欧盟金融行业）要求实施 ICT 第三方风险管理，并规定了针对数字服务依赖关系的监控与治理的具体要求，包括这些服务所使用的机器身份

如果你正在构建 NHI 治理，你也在同步构建合规证据。

Netwrix 如何支持非人类身份安全

上述每一项治理实践都取决于一件事：了解你们环境中有哪些非人类身份，以及它们正在做什么。对大多数组织而言，这是一个很难自行弥补的差距，而 Netwrix 正好可以填补这一点。

Netwrix 1Secure platform 可在整个 Active Directory 和云环境中提供身份姿态的持续可视性。针对非人类身份，它会暴露非活动账号、陈旧账号以及过度宽松的访问配置——这些配置会违反组织策略，从而让安全团队获得当前态势的清晰画面，而不是仅依赖按季度的快照。

与手动查询只能为你导出“某一时点”的结果不同，1Secure 会在新身份创建、已有身份发生变化时持续保持全程视图。

针对 Active Directory，Netwrix Auditor 会跟踪服务账号的变更、监控身份验证事件，并审计组策略（Group Policy）的修改，从而弥补原生工具未能覆盖的可视性缺口。

当有人创建新的服务账号、更改其所属组成员关系，或尝试进行交互式登录（interactive logon）时，Auditor 会将其标记出来。团队可以使用易于阅读的报告开始回答有关 NHI 活动的审计问题，这些报告会与诸如 HIPAA 、SOC 2 以及 CMMC 等合规框架直接对应。

对于需要更高权限的特权非人类身份，Netwrix Privilege Secure 通过“按需（just-in-time）”自动化分配，并为审计追踪提供完整会话录制（full session recording），从根本上消除长期持有的特权。Privilege Secure 不再让服务账号全天候持有持久的管理员访问权限，而是在需要时才授予提升后的权限，并在任务完成后自动撤销。

准备好弥补非人身份（non-human identities）的可视性差距了吗？ 预约演示 了解 Netwrix 如何在您的环境中发挥作用。