保护非人身份:自动吊销、OAuth 与作用域权限
原文:Securing non-human identities: automated revocation, OAuth, and scoped permissions Source: https://blog.cloudflare.com/improved-developer-security/
2026-04-14
Agent 让你前所未有地快速构建软件,但保护你的环境与代码 — 防止失误也防止恶意 — 需要实打实的努力。Open Web Application Security Project(OWASP)详细列出了 agentic AI 系统中存在的多种 风险,包括凭证泄露、用户冒充和权限提升。这些风险可能对你的环境造成极大破坏,包括拒绝服务、数据丢失或数据泄露 — 进而带来难以估量的财务与声誉损失。
这是一个身份问题。在现代开发中,“身份“不只是人 — 它们包括代表你行动的 agent、脚本和第三方工具。要保护这些非人身份,你必须管理其完整生命周期:确保其凭证(token)不泄露,看清哪些应用通过 OAuth 拥有访问权限,并通过精细 RBAC 收窄其权限。
今天,我们推出多项更新来满足这些需求:可扫描的 token 来保护你的凭证、OAuth 可见性来管理你的主体,以及资源作用域 RBAC 来微调你的策略。
理解身份:Principal、Credential 和 Policy
要在自主 agent 时代保护互联网,我们必须重新思考如何处理身份。无论请求来自人类开发者还是 AI agent,与 API 的每次交互都依赖三大支柱:
-
Principal(旅行者): 这是身份本身 — “谁”。它可能是通过 OAuth 登录的你,也可能是用 API token 部署代码的后台 agent。
-
Credential(护照): 这是身份的证明。在这个世界里,你的 API token 就是你的护照。如果它被偷或泄露,任何人都能“穿上“你的身份。
-
Policy(签证): 它定义了该身份被允许做什么。即使你有有效护照,也不意味着你有进入每个国家的签证。策略确保即便是已认证的身份,也只能访问其需要的特定资源。
当三大支柱不能协同管理时,安全就会崩溃。你可能有合法的 Principal 拿着被偷的 Credential,或合法身份配上过于宽泛的 Policy。
泄露 token 检测
Agent 与其他第三方应用使用 API token 访问 Cloudflare API。我们见到人们泄露密钥最简单的方式之一,就是不小心把它推送到公开 GitHub 仓库。GitGuardian 报告称,去年有超过 2800 万个密钥被发布到公开 GitHub 仓库,且 AI 让泄露发生的速度比以前快 5 倍。
如果说 API token 是数字护照,那么把它泄露到公开仓库就像把护照丢在公园长椅上。任何捡到它的人都能冒充该身份,直到该证件被作废。我们与 GitHub 的合作就像这些凭证的全球“失物招领“:在你意识到护照丢了之前,我们已经识别该证件、通过校验和验证其真实性,并将其作废以防滥用。
我们正在与多家领先的凭证扫描工具合作,主动找出你的泄露 token 并在被恶意使用之前吊销。我们知道这不是会不会的问题,而是何时的问题 — 你、员工或某个 agent 总会犯错把密钥推到不该推的地方。
GitHub
我们与 GitHub 合作,加入其 Secret Scanning 项目,在公共与私有仓库中查找你的 token。如果我们被通知某个 token 泄露到公共仓库,我们会自动吊销该 token 以防恶意使用。对于私有仓库,GitHub 会通知你任何泄露的 Cloudflare token,你可以自行清理。
如何工作
我们已与 GitHub 共享了新的 token 格式(见下文),他们现在会在每次提交时扫描。如果发现疑似泄露的 Cloudflare token,他们会(用校验和)验证 token 真实,通过 webhook 通知我们吊销,我们再通过邮件通知你以便在仪表盘设置中生成新 token。
也就是说,一旦发现漏洞,我们就堵上。在你意识到犯错之前,我们已经修好。
我们希望这是你不需要用到的功能,但合作伙伴会替你监视泄漏,帮你保持安全。
Cloudflare One
Cloudflare One 客户也受到这些泄漏的保护。通过配置 Credentials and Secrets DLP 配置文件,组织可以在凭证可能流经的每个地方启用防护:
-
网络流量(Cloudflare Gateway): 把这些条目应用到策略中,以检测并阻止跨网络移动的 Cloudflare API token。出现在文件上传、出站请求或下载中的 token,会在到达目的地之前被拦截。
-
出站邮件(Cloudflare Email Security): Microsoft 365 客户可以将相同防护扩展到 Outlook。DLP Assist 加载项在投递前扫描邮件,在 token 被外发前拦截它。
-
静态数据(Cloudflare CASB): Cloudflare 的云访问安全代理把同一配置文件应用到已连接的 SaaS 应用中扫描文件,捕获保存或共享在 Google Drive、OneDrive、Dropbox 等集成服务中的 token。
不过最新颖的暴露途径是 AI 流量。Cloudflare AI Gateway 与同一套 DLP 配置文件集成,实时扫描并阻止入站的 prompt 与出站的 AI 模型响应。
其他凭证扫描器
凭证扫描唯一有效的方式是迎合你所在的位置,因此我们正在与多家开源与商业凭证扫描器合作,确保无论你用哪个密钥扫描器都受到保护。
如何工作
到目前为止,Cloudflare 的 API token 看上去相当通用,凭证扫描器很难高置信度地识别。它们扫描你的代码仓库以查找暴露的 API key、token 或密码。“cf“前缀让 Cloudflare token 立刻可识别且置信度更高,而校验和让工具能静态校验它们。你已有的 token 仍然可用,但你今后生成的每个新 token 都会使用可扫描格式,以便高置信度发现。
|
凭证类型 |
用途 |
新格式 |
|
User API Key |
与你用户账户绑定的传统全局 API key(完全访问) |
cfk_[40 个字符][校验和] |
|
User API Token |
你为特定权限创建的作用域 token |
cfut_[40 个字符][校验和] |
|
Account API Token |
归账户(而非特定用户)所有的 token |
cfat_[40 个字符][校验和] |
开始使用
如果你有现有的 API token,可以滚动 token 来创建新的可扫描 API token。这是可选的,但推荐执行,以确保 token 一旦泄露能被轻松发现。
虽然 API token 通常由你自己的脚本与 agent 使用,但 OAuth 是你管理第三方平台访问的方式。两者都需要清晰的可见性,以防未授权访问,并确保你确切知道谁 — 或什么 — 拥有对你数据的访问权。
改进 OAuth 同意体验
当你用 OAuth 把 Wrangler 等第三方应用连接到你的 Cloudflare 账户时,你就在授予该应用对账户数据的访问权。久而久之,你可能忘了为什么要授权某个第三方应用访问你的账户。以前,没有一个集中位置查看与管理这些应用。从今天开始,有了。
今后,当第三方应用请求访问你的 Cloudflare 账户时,你将能审阅:
-
哪个第三方应用 在请求访问,以及该应用的相关信息,如名称、Logo 与发布者。
-
哪些 scope 是该第三方应用请求访问的。
-
哪些账户 授予该第三方应用访问。
| 之前 | 之后 |
|---|---|
![]() |
![]() ![]() |
并非所有应用都需要相同权限;有些只需读取数据,有些可能需要修改账户。授权前理解这些 scope 有助于你保持最小权限。
我们还增加了一个 Connected Applications 体验,你可以查看哪些应用拥有哪些账户的访问权,该应用关联了什么 scope/权限,并在需要时轻松吊销访问。
开始使用
OAuth 同意与吊销改进现已可用。访问 My Profile > Access Management > Connected Applications,查看哪些应用当前可访问你的账户。
对正在构建与 Cloudflare 集成的开发者,关注 Cloudflare Changelog,很快会有关于如何注册自己的 OAuth 应用的更多公告!
细粒度资源级权限
如果说 token 是护照,那么资源作用域权限就是其中的签证。手持有效护照能让你进入大门,但不应让你进入楼里所有房间。把作用域收窄到特定资源 — 比如单个 Load Balancer 资源池或某条 Gateway 策略 — 你就在确保即使身份通过验证,也只持有进入严格必要之处的“签证“。
去年我们 宣布 在 Cloudflare 的 基于角色的访问控制(RBAC) 系统中,为多款 Zero Trust 产品支持资源作用域权限。这能让你为用户和 agent 都“按尺寸“配置权限,以最小化安全风险。我们已将该能力扩展到多项新的资源级权限。资源 scope 现已支持:
-
Access Applications
-
Access Identity Providers
-
Access Policies
-
Access Service Tokens
-
Access Targets
我们还彻底重构了 API Token 创建体验,让客户更容易直接从 Cloudflare 仪表盘配置和管理 Account API Token。
如何工作
当你向 Cloudflare 账户添加成员或创建 API Token 时,通常会为该主体分配一条策略。Permission Policy 赋予主体执行某个动作的权限,无论是管理 Cloudflare One Access Applications 还是 DNS 记录。没有策略,主体可以认证,但无权在账户内执行任何动作。
策略由三部分组成:Principal、Role 与 Scope。Principal 是你授予访问的对象,无论是人类用户、像 API Token 那样的非人身份(NHI),还是越来越多代表用户行动的 Agent。Role 定义其被允许执行的动作。Scope 决定权限作用范围,而以前这一直被限制在整个账户或单个 zone。
新权限角色
我们也在账户与 zone 两个层面更广泛地扩展角色面,为多个产品引入了一些新角色。
-
账户作用域
-
CDN Management
-
MCP Portals
-
Radar
-
Request Tracer
-
SSL/TLS Management
-
-
Zone 作用域
-
Analytics
-
Logpush
-
Page Rules
-
Security Center
-
Snippets
-
Zone Settings
-
开始使用
资源作用域以及所有新的账户与 zone 级角色今天对所有 Cloudflare 客户开放。你可以通过 Cloudflare 仪表盘、API 或 Terraform 分配账户、zone 或资源作用域的策略。
完整的角色列表与作用域工作方式,请见我们的 roles 与 scope 文档。
保护你的账户
这些更新提供了真正最小权限架构所需的细粒度构建块。通过精炼对权限与凭证的管理,开发者与企业可以对覆盖访问 Cloudflare 的用户、应用、agent 与脚本的安全态势更有信心。最小权限不是新概念,对企业而言从来都不是可选项。无论是人类管理员管理一个 zone,还是 agent 程序化部署一个 Worker,期望都一样:它们应该只被授权完成被赋予的工作,而不能多做。
随着今天的发布,我们建议客户:
-
审阅你的 API token,并尽快用新的可扫描 API token 重新签发。
-
审阅你已授权的 OAuth 应用,并吊销不再使用的。
-
审阅账户中的 成员 与 API Token 权限,确保用户根据需要采用新的账户、zone 或资源作用域权限,以缩小风险面。


