4.7 身份与访问管理

概述与动机

每一个到达你系统的请求，都隐含地宣称：“我被允许这样做。” 身份与访问管理（IAM）就是判定这一宣称是否为真的学问。它回答两个经常被人们混为一谈的独立问题。身份验证（Authentication）证明你是谁。授权（Authorization）在你证明了自己是谁之后，决定你可以做什么。把这两个概念在头脑中分清楚，这个领域一半的困惑就会消失。

对于大型团队而言，身份已经悄然成为你所拥有的最重要的控制手段。第 4.3 章指出身份就是新的边界，第 4.1 章则在此基础上构建零信任：当你不再信任网络时，唯一剩下可以信任的，就是一个经过验证的身份和一条明确的策略。这意味着一个薄弱的密码重置流程，或一个被遗忘的服务账户，不再是一个小缺陷。它就是前门。大多数真实的数据泄露事件，并不是对内存安全缺陷的巧妙利用，而是被盗的凭证、过度宽泛的权限，以及几个月前就该被关闭却仍然存在的账户。

在企业和政府环境中，风险更高。一家全球性企业要同时应对数十个相互重叠的目录、每月数以千计的入职与离职人员，以及需要有限访问你部分系统的合作伙伴。一家政府机构还要叠加智能卡凭证、强制性的身份保障等级，以及会用书面形式追问”某一天究竟是谁能够接触某条记录”的审计人员。本章旗帜鲜明地讲述如何构建一个能很好地回答这些问题、同时又不会让你的人员寸步难行的身份层。

关键原则

身份验证与授权是不同的问题。 证明身份和授予权限需要各自独立的设计和评审。
一个身份，多个系统。 每个身份群体都应整合到单一的真实来源；目录蔓延本身就是一个安全缺陷。
默认最小权限。 从零访问权限开始，有意识地逐步添加，对人和机器都是如此。
每一份凭证都是临时的。 优先选择短期有效、自动签发的凭证，而不是长期有效的密钥。
撤销权限（deprovisioning）与授予权限一样重要。 超出实际需要而继续存在的访问权限，就是纯粹的风险。
抗钓鱼胜过易记。 把身份验证方式推向通行密钥（passkey）和基于硬件的验证因子。
机器也是身份。 工作负载、流水线和服务需要托管身份，而不是共享的静态密钥。
访问是一个生命周期，而不是一次性事件。 按计划授予、审查和撤销权限，并证明你确实这样做了。

建议

将身份验证与授权分离，并将两者都集中管理

通过一个身份提供商（IdP）进行身份验证，这是一个验证身份并签发令牌、供其他系统信任的系统。然后让每个应用程序根据该令牌所携带的身份和属性，自行做出授权决策。这种拆分让你可以一次性、为所有人加强身份验证，同时把细粒度的权限逻辑保留在它所保护的数据附近。采用单点登录（SSO），即一次身份验证就能获得对多个应用程序的访问权限，这样你的员工拥有的是一次强登录，而不是四十次弱登录。联合身份（federation）把同样的信任跨越组织边界延伸出去，让合作伙伴的身份能够访问你的系统，而你不必管理他们的密码。

用现代协议做它们真正该做的事

三套标准承担了大部分工作，每一套都有自己的职责。OpenID Connect（OIDC） 是构建在 OAuth 2.0 之上的身份层；用它来回答网页和移动端登录中的”这个用户是谁”这个问题。OAuth 2.0 是一个用于委托访问的授权框架；用它来让一个应用程序代表用户调用 API，而始终不接触用户的密码（第 2.3 章）。安全断言标记语言（SAML） 是较早出现的基于 XML 的联合身份标准；它仍然是企业单点登录进入成熟商业应用程序的主力工具。一个常见的错误是直接用 OAuth 来做身份验证。OAuth 授予的是对资源的访问权限；OIDC 建立在它之上，用来确立身份。对于新的面向用户的登录，选择 OIDC；在企业目录要求的地方保留 SAML；不要自创令牌格式。

让身份验证具备抗钓鱼能力

单靠密码在规模化场景下是站不住脚的。要求每一个人类账户都无一例外地启用多因素身份验证（MFA），结合你知道的东西、你拥有的东西和你本身的特征这三类因素。然后要超越那些薄弱的因素：短信一次性验证码既可能被钓鱼，也可能被 SIM 卡劫持。更强的方向是通行密钥（passkey）和底层的 WebAuthn 标准（一个用于公钥身份验证的浏览器 API），它们把登录绑定到一个由硬件持有的私钥，也绑定到真实网站的来源（origin），因此一个仿冒页面无法窃取任何有价值的东西。通行密钥也是无密码的，你的用户会因此感谢你。把账户恢复和密码重置也当作身份验证面的一部分来对待，因为一个无法攻破你的 MFA 的攻击者，会转而直接攻击重置流程。

管理入职（转岗）离职生命周期，并快速撤销权限

身份是一个生命周期。入职者（joiner） 需要在第一天就拥有正确的访问权限。转岗者（mover） 换了角色后需要新的访问权限，而且至关重要的是，需要移除旧的访问权限，否则他们会逐渐积累起打开整栋大楼的所有钥匙。离职者（leaver） 必须在所有系统中迅速失去全部访问权限，理想情况下应在其最后一个工作日的几分钟内完成。让这一切由一个权威来源驱动，通常是人力资源系统，这样那里的状态变更就能自动触发下游的授权和撤销。把它自动化。手动的离职清单总会遗漏点什么，而被遗漏的那个账户，正是会出现在事件报告中的那个。

选择一种授权模型，并将其表达为代码化策略

通过基于角色的访问控制（RBAC）来授予权限，即把权限分配给工作职能角色，再把人分配到角色，因为这种方式易于推理，也易于审计。当你需要基于部门、数据分类、位置或时间等属性做出情境感知的决策时，就采用基于属性的访问控制（ABAC）。大多数成熟的组织采用混合模式：用 RBAC 做粗粒度的授权，用 ABAC 处理精细的条件。无论你选择哪一种，都要把授权表达为代码化策略（policy-as-code）：以受版本控制、可测试、可评审的形式编写规则，而不是在控制台里点出来的。代码化策略让访问决策变得可审计、可比对差异，并在各个环境中保持一致，还能让你在权限变更上线之前先进行测试。

用即时访问和 PAM 落实最小权限

应用最小权限原则：每个身份都只获得它所需要的最小访问权限，不多不少。常驻权限是敌人，因为一个被永久授予的权限，会在任何时刻都可供任何登陆该账户的攻击者使用。优先采用即时访问（just-in-time，JIT），即一个人为一个有限的时间窗口申请提升的权限，经批准后获得，并在窗口关闭时自动失去这些权限。对于你最危险的那些账户，采用特权访问管理（privileged access management，PAM）：一个将管理凭证保管在保险库中、对特权会话进行代理和记录、并按需签发权限提升的系统。目标是实现零常驻管理员权限，这样即使一台笔记本电脑被完全攻破，也不会产生任何持久的收获。

让机器和工作负载拥有真正的身份

人只是你身份的一半。服务、流水线、容器和函数都要向某个东西进行身份验证，而它们太常见的做法是用一个粘贴在配置文件中的长期有效密钥。用托管的工作负载身份（workload identity）来取代静态密钥：根据工作负载运行的位置和其自身属性，自动为其签发短期有效的凭证。对服务间的身份验证使用双向 TLS（mTLS），即连接的双方都出示证书。任何仍然需要的密钥都应保存在一个具备轮换能力的专用密钥管理系统中，绝不能放在源代码或镜像里（第 4.2 章）。短期有效、自动轮换的工作负载凭证，消除了云凭证泄露最常见的那个成因。

让身份成为控制平面，并持续审查访问权限

在零信任架构（第 4.1 章）中，身份是策略被决定和执行的地方，因此要相应地在此投入。然后用访问审查（access review），也叫重新认证（recertification），来闭合这个循环：按计划，每个系统的负责人确认每个拥有访问权限的人和机器是否仍然需要它，并撤销无法说明理由的权限。把每一次身份验证和授权事件都输入到一条审计轨迹中，用以回答”谁在什么时间、依据什么策略访问了什么”（第 4.6 章）。访问审查是你对抗权限蔓延（privilege creep）的方式（）那种单次授权看起来都不算离谱，但累积起来却让一个账户拥有过大权力的缓慢过程。

权衡：优点与缺点

决策	优点	缺点
带 SSO 的集中式身份提供商	一次强登录、策略一致、易于审计	单点故障；一旦中断，所有人都被锁在外面
RBAC	简单、可审计、为人熟悉	角色爆炸；对情境敏感的需求过于粗放
ABAC	细粒度、情境感知、随属性扩展	设计、测试和推理都更困难
通行密钥 / WebAuthn	抗钓鱼、无密码、安全性强	恢复流程和设备丢失流程需要精心设计
即时访问	常驻权限几乎为零	带来摩擦；需要快速、可靠的审批路径
与合作伙伴的联合身份	无需管理外部密码；信任范围受限	信任程度取决于合作伙伴自身的安全卫生水平
长期有效的服务密钥	设置起来极其简单	极易泄露；是凭证泄露事件的头号成因

核心张力在于安全与摩擦之间。每一项收窄攻击面的控制措施（处处启用 MFA、即时权限提升、短生命周期凭证）都会给某个人的日常工作增加一个步骤，而人们会绕开那些让人痛苦到难以忍受的控制措施。解决之道是让安全路径成为便捷路径：用 SSO 让强身份验证只需轻点一下，用通行密钥让密码无需输入，用自动化配置让正确的访问权限直接出现。把你的”摩擦预算”花在爆炸半径最大的地方（）特权和生产环境访问（）而让日常访问几乎不受阻碍。

与团队讨论的问题

对于今天离职的人，你实际上能有多快撤销其全部访问权限，你又如何知道确实生效了？ 撤销权限的速度直接反映了你的身份成熟度，因为一个访问权限尚未失效的离职者，就是一个拥有真实权限却无人监控的账户。在一个拥有数十个彼此独立系统的大型组织中，诚实的答案往往是”我们也不确定”，而缺口通常出现在那些从未接入中央身份提供商的应用程序上。拿一个最近真实发生的离职案例，追踪此人能够接触到的每一个系统，核对每个系统实际终止访问的时间戳。设定一个目标，例如在人力资源状态变更后一小时内完成全部撤销，并将其纳入监测，以便你能证明而不是寄望于它成立。如果任何系统依赖于有人记得执行一个手动步骤，那个账户就是未来某次数据泄露会被利用的账户。
你们在哪些地方仍然存在常驻特权访问和长期有效的静态凭证，要消除它们需要付出什么？ 常驻管理员权限和永久有效的服务密钥，是攻击者最觊觎的两类资产，因为它们持久且强大。清点每一个拥有永久生产或管理访问权限的人，以及每一个用静态密钥进行身份验证的服务，然后诚实地问，其中哪些可以转为即时权限提升或短期有效的工作负载身份。与之相抗衡的考量是运营上的恐惧：团队保留常驻访问权限，是因为在紧急破窗（break-glass）时刻感觉更安全，所以你必须先让紧急权限提升变得快速可靠，才能取消常驻权限。把清单带到讨论中，按爆炸半径排序，优先处理生产和管理访问权限。要努力达成的最终状态是零常驻管理员权限，也没有任何静态密钥的生命周期长于一次部署。
每个人和每个工作负载是否只有一个权威身份，还是有多个，蔓延带来的成本又是多少？ 目录蔓延（）同一个人在五个系统中存在五个属性各自漂移的账户（）正是权限撤销缺口和孤儿访问权限的产生之地。把每个身份群体整合到单一的真实来源，是一个大型团队所能做出的最高杠杆投资之一，因为下游的每一项控制，都依赖于确知两条记录是同一个人。带上你的身份存储清单，标出哪些是权威来源，哪些是无人治理的便利副本。这里的权衡在于，整合是一项庞大而缺乏吸引力的迁移工程，会与功能开发争夺注意力。要决定的是，蔓延带来的持续成本（）审计的痛苦和被攻破的风险（）是否足以证明现在就为这项迁移投入资金，而不是等到下一次事件发生之后。
你们最强的身份验证因子是否真正具备抗钓鱼能力，是什么阻止了你们彻底淘汰密码？ 攻击者无法钓鱼的那个因子，正是终结凭证盗窃作为你主要数据泄露路径的因子，而绑定 WebAuthn 的通行密钥是唯一能广泛部署、达到这一标准的方案。在一个大型组织中，真实情况通常是混杂的：一部分人使用通行密钥，一部分人还在用短信一次性验证码，还有一长串遗留应用程序仍然只接受密码。与之相抗衡的考量是真实存在的，因为通行密钥把难题转移到了账户恢复和设备丢失上，一个笨拙的恢复流程会成为攻击者直接转而攻击的新的软目标。带上按因子类型划分的覆盖率数据、仍然会回退到密码的应用程序清单，以及一个你会信任能抵御一次坚定社会工程攻击的、经过精心设计的账户恢复路径。在企业和政府环境中，把目标与任何强制性的保障等级挂钩，因为一个高保障系统若仍然允许可被钓鱼的因子，那既是一个合规缺口，也是一个安全缺口。
你们如何决定每个身份获得什么访问权限，能否在这个决策上线之前对其进行比对差异、测试和验证？ “有人在控制台里点出了权限”与”一份经过评审、受版本控制的策略”之间的差距，正是一个可审计的访问模型与一个你只能事后道歉的访问模型之间的差别。对于大型团队而言，压力在于放任每个应用程序自行发展出各自的定制规则，这会在 RBAC 一侧悄悄导致角色爆炸，在 ABAC 一侧导致无法测试的条件，直到没有人能说清一项授权究竟允许什么。与之相抗衡的考量是交付速度，因为把授权表达为代码化策略，会比控制台里的一次点击多出一道评审环节，处于截止日期压力下的团队会为此感到不满，直到第一次审计失败或过度宽泛的授权替它们证明了这一点的价值。带上一个真实的权限变更，追踪它将如何被提出、测试、评审和回滚，再加上你们一共有多少个角色、其中有多少个没人能解释清楚。在企业和政府环境中，审计人员会要求你准确展示某一天究竟是谁能够访问某条记录，依据什么规则，只有可比对差异、可测试的策略才能不慌不忙地回答这个问题。
上一次访问审查真正撤销了什么实质性的东西是在什么时候，当权限蔓延失控时，谁来负责？ 访问审查是对抗那种单次授权都不显得离谱、但缓慢累积的权限蔓延的控制手段，而一次从不撤销任何东西的审查，就是产生纸面文件而非真正安全的审查表演。在大型组织中，常见的失效模式是橡皮图章：系统负责人一次性重新认证数百个条目，全部批准，因为真正逐一评估太过繁琐，而让权限持续流动的动力，比削减权限的动力更强。与之相抗衡的考量是，真正有意义的审查会占用负责人的时间，偶尔还会在某人悄悄依赖的访问权限消失时打断他们的工作流程，所以你必须让审查是有针对性、由风险驱动的，而不是一份不加区分的清单。带上上一周期的撤销比率、人均权限项数量，以及每个系统重新认证由谁负责的证据。在企业和政府环境中，为每一次审查指定一名负责的官员，并明确他们所遵循的周期，因为无人负责捕捉的权限蔓延，正是审计人员和攻击者都会加以利用的那种状态。

分行业视角

初创公司。 购买身份服务，不要自己构建。一个带有 SSO、强制通行密钥和一键离职的单一托管身份提供商，能以按席位收费的方式，让为数不多的几名工程师拥有企业级的安全态势。依靠提供商内置的工作负载身份，这样你的流水线中就不会存在任何一个长期有效的云密钥，直接使用现成的 OIDC 和 OAuth 2.0，而不是发明一套你负担不起维护成本的令牌处理机制。

小型企业。 没有身份专家在职时，优先使用你已经付费的工具中内置的 SSO 和 MFA 功能，直接启用它们，而不是另外去采购一个平台。把入职（转岗）离职问题当作一份简短的书面清单，绑定给负责招聘的人；优先选用通行密钥，因为它能消除你抽不出人手来处理的密码重置支持工单负担。避免共享登录账户，因为这是一个廉价的习惯，日后会让责任追溯和权限撤销都变得不可能。

企业。 工作的重点在于跨众多目录和团队的整合与治理：一个由人力资源系统驱动的权威身份提供商、自动化的入职（转岗）离职流程、针对工作职能的 RBAC 结合情境化的 ABAC，以及带会话记录的特权访问管理。把授权表达为代码化策略，使变更可比对差异、可测试；定期运行确实会撤销权限的访问审查；把接口标准化，让应用程序接入中央身份系统，而不是各自发展自己的登录方式。

政府。 采购规则、透明度和公众问责推动着设计。把身份验证绑定到 PIV 或 CAC 等硬件凭证智能卡，按 NIST SP 800-63 设定身份保障等级，使高风险系统要求更高保障的因子，并保留能准确回答谁在何时访问了什么的不可篡改审计日志。以通俗语言公布面向公民的身份处理方式，将客户身份和员工身份体系分开保管，确保敏感系统上的每一次特权操作都经过代理和记录，以备审计人员查询。

示例

初创公司。 一家二十人规模的初创公司无法配备身份团队，于是选择购买一个。每位员工都通过一个单一的托管身份提供商登录邮件、代码托管、云控制台和内部应用，并强制要求使用通行密钥，因此没有密码可供钓鱼。离职流程只需一次点击：在身份提供商中禁用此人，就能同时切断所有系统的访问权限。对于他们自己的产品，他们使用 OIDC 处理用户登录，用 OAuth 2.0 让集成方能够用受限范围的令牌调用他们的 API。服务到云端的身份验证使用提供商内置的工作负载身份，因此他们的流水线中不存在任何一个长期有效的云密钥。这只需要一笔不高的按席位费用，却换来了比许多大企业更强的身份安全态势。

企业。 一家跨国银行花了十年时间积累出四个目录和数百个应用程序，其中一些通过 SAML 联合身份接入，另一些则有自己本地的登录方式。它出资推动一个整合项目：一个由人力资源系统驱动的权威身份提供商，配以自动化的入职（转岗）离职流程，在入职时授予权限、在离职后几分钟内撤销权限。RBAC 覆盖标准工作职能，而 ABAC 则针对跨境访问执行数据驻留和安全许可规则。管理员不持有任何常驻生产访问权限；他们通过一个记录每一次会话的特权访问管理系统申请即时权限提升。季度访问审查强制系统负责人重新认证或撤销权限，每一项决策都表达为代码化策略，以便审计人员能精确比对差异，看清改了什么、何时改的。

政府。 一家联邦机构向其员工发放个人身份验证（PIV）智能卡，以及军方对应的通用访问卡（CAC），因此身份验证绑定的是一份硬件凭证，而不是密码。其身份项目遵循联邦身份、凭证与访问管理（FICAM）方法，并依据美国国家标准与技术研究院的 NIST SP 800-63 指南设定身份保障等级，使高风险系统要求更高保障级别的凭证。面向公民的服务使用一套单独的、保障等级较低但配有强 MFA 的客户身份体系。访问审查和不可篡改的审计日志直接输入该机构的持续授权证据体系（第 4.6 章），涉密系统上的每一次特权操作都会经过代理和记录。

商业论证：动机、投资回报率与总拥有成本

身份投资的回报，来自把你最主要的数据泄露途径从危险区移开。被盗凭证和权限过度的账户驱动了很大一部分真实事件，每一起都带着沉重的后续代价：事件响应、监管罚款、泄露通知，以及持久的声誉损害。仅仅是抗钓鱼的 MFA，就能消除最常见的入侵路径，而自动化的权限撤销则能堵上那个把常规离职变成风险敞口的孤儿账户缺口。就每一美元的投入而言，这些是可获得的最廉价的风险削减手段之一。

总拥有成本是真实存在的，但也是有边界的。它包括身份提供商的许可费用、一个特权访问管理与密钥管理平台、把每个应用程序接入中央身份体系所需的工程投入，以及持续进行访问审查的工作量。更大的成本在于组织层面：整合目录、为遗留应用程序改造上 SSO，是一项缓慢、缺乏吸引力、要与功能开发争夺资源的工作。要把它与替代方案权衡。碎片化的身份体系会以手动离职处理、审计中的手忙脚乱、以及帮助台密码重置的形式，永远花掉同样多的钱，再加上碎片化最终导致的那次数据泄露的代价。在向领导层论证时，把身份定位为零信任的控制平面：整合与自动化是一次性投资，能同时降低数据泄露风险，以及审计、离职处理和访问支持的持续成本。

反模式与陷阱

孤儿账户。 超出人员或用途实际存在期限的访问权限，尤其是无人监控的服务账户和被遗忘的承包商账户。
处处常驻管理员权限。 常驻特权访问而非即时权限提升，让任何一个被攻破的管理员账户都拥有持久的权力。
长期有效的静态密钥。 粘贴在配置文件或 CI 中、永不过期、最终必然泄露的服务凭证。
目录蔓延。 同一个人拥有许多无人治理的账户，导致任何变更都无法完全传播到位。
共享账户。 由多人共用的凭证，摧毁了责任归属，使权限撤销变得不可能。
把短信当作强因子。 把可被钓鱼、可被 SIM 卡劫持的一次性验证码，当作足够的 MFA 来对待。
角色爆炸。 RBAC 角色数量过多、过于狭窄，导致模型变得无法审计，没人知道一个角色究竟授予了什么。
把权限撤销做成手动清单。 人工离职步骤总会遗漏那个真正重要的账户。
用 OAuth 做身份验证。 把访问令牌当作身份证明，而不是使用 OIDC。
审查表演。 访问重新认证被橡皮图章式地批准，无人真正评估其必要性。

成熟度模型

第 1 级，启动（Initiate）： 每个应用程序都有自己的登录方式。使用密码，没有一致的 MFA。配置和离职流程都是手动的、被动的、缓慢的；孤儿账户不断积累。服务凭证是长期有效的静态密钥。没有访问审查；权限一旦授予就再也不会被重新审视。
第 2 级，发展（Develop）： SSO 覆盖了主要应用程序，通过一个中央身份提供商实现，但各团队的覆盖情况并不均衡。大多数人类访问要求 MFA。存在基本的 RBAC。入职（转岗）离职流程部分实现了从人力资源系统的自动化。一些特权账户已被纳入保险库。访问审查偶尔发生，且不够一致。
第 3 级，标准化（Standardize）： 一个整合后的身份提供商是员工身份的权威来源，自动化配置和及时的权限撤销在全组织范围内被强制执行。抗钓鱼的 MFA 是标准配置并有文档记录。RBAC 加 ABAC 被表达为代码化策略。已建立带会话记录的特权访问管理。工作负载身份取代了大多数静态密钥。定期的访问审查被强制执行，并依据一份每个团队都遵循的书面政策接受审计。
第 4 级，管理（Manage）： 身份项目对照基线进行度量，并以数据加以控制。你跟踪从人力资源状态变更到完全撤销权限所需的时间、按人群划分的 MFA 和通行密钥覆盖率、拥有常驻特权访问权限的账户数量、仍在使用的长期有效静态密钥数量、孤儿账户数量，以及访问审查的撤销比率。各项指标都设有目标，例如一小时内完成全部撤销、常驻管理员授权净新增为零，超出阈值即触发调查，而不是被一笑置之。授权变更在流水线中接受测试，每一次访问授权的通过或拒绝都由证据驱动，而不是习惯驱动。
第 5 级，编排（Orchestrate）： 身份是零信任持续改进的控制平面，与整个组织的安全、风险和入职（转岗）离职规划相集成。通行密钥是默认方式，密码正在被淘汰。通过即时权限提升实现零常驻权限，所有工作负载都使用短期有效、自动轮换的凭证和 mTLS。授权完全实现代码化策略。访问审查是持续的、由风险驱动的，权限撤销近乎即时，每一项决策都自动产生审计证据。该模型会随着风险信号的变化而自适应，动态收紧或放宽访问权限，而不是按固定周期执行。

讨论思路

要达到零常驻管理访问权限，需要付出什么，怎样的紧急破窗路径才能让这一点安全可行？
在你们的环境中，ABAC 的复杂度在哪些地方值得投入，相对于继续使用简单的 RBAC？
你们应该以多大的力度用通行密钥淘汰密码，什么样的恢复流程能够取代它们？
哪些应用程序仍然在你们的中央身份提供商之外，是什么让它们停留在那里？
你们如何在不继承合作伙伴和客户自身安全卫生水平的情况下，给予他们有限的访问权限？
哪一个单一指标最能体现你们撤销权限的速度，你们今天有在衡量它吗？

关键要点

身份验证证明你是谁；授权决定你可以做什么。要分开设计和评审这两者。
整合到一个带 SSO 的权威身份提供商；目录蔓延是一个安全缺陷，而不是一种便利。
自动化入职（转岗）离职生命周期，让权限撤销变得快速且可证明。
用户登录使用 OIDC，委托式 API 访问使用 OAuth 2.0，在企业目录需要的地方使用 SAML；不要把 OAuth 当作身份验证来使用。
把身份验证推向抗钓鱼的通行密钥和 WebAuthn；处处要求 MFA，把薄弱的因子当作权宜之计对待。
用即时访问和特权访问管理落实最小权限；以零常驻管理员权限为目标。
用短期有效的工作负载凭证和 mTLS 给机器赋予真正的身份；消除长期有效的静态密钥。
让身份成为零信任的控制平面（第 4.1 章），并用持续的访问审查和审计证据闭合这个循环（第 4.6 章）。

参考资料与延伸阅读

National Institute of Standards and Technology, SP 800-63: Digital Identity Guidelines (identity assurance, authentication, and federation levels)
National Institute of Standards and Technology, SP 800-207: Zero Trust Architecture
National Institute of Standards and Technology, SP 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations
National Institute of Standards and Technology, SP 800-53: Security and Privacy Controls, Access Control (AC) and Identification and Authentication (IA) families
The OAuth 2.0 Authorization Framework, IETF RFC 6749, and the OAuth 2.0 Security Best Current Practice
OpenID Connect Core 1.0 specification, OpenID Foundation
Security Assertion Markup Language (SAML) 2.0 specification, OASIS
Web Authentication (WebAuthn) Level 2, W3C Recommendation, and FIDO2 / FIDO Alliance passkey specifications
Federal Identity, Credential, and Access Management (FICAM) architecture and playbooks, U.S. General Services Administration
FIPS 201, Personal Identity Verification (PIV) of Federal Employees and Contractors
Open Policy Agent (OPA) documentation, Cloud Native Computing Foundation (policy-as-code for authorization)