Vibe Engines 是免费的交互式 AI 工程与系统设计课程——直接在浏览器中运行。选择一条学习路径 →

前沿部署工程师/ 企业身份

比模型质量更能阻碍成单的那一层

从来没有企业部署是因为模型在评测中低了两个百分点而失败的。失败的原因是安全审查员问“当有人离职时，访问权限会怎样？”，而诚实的回答是“你得给我们发邮件”。身份是 FDE 负责的最不起眼的工作，却也是最可靠的被卡住六周的方式——卡你的那个团队，你连负责人都没见过。

为什么这会落到 FDE 头上

在自助式产品中，身份是平台团队一次性解决的问题。而在部署中，每次都不一样，因为那是他们的身份提供商、他们的组结构，以及他们的安全团队的规则。FDE 是唯一同时身处两个组织内部的人，所以无论是否写进你的职位描述，这个集成都会落到你头上——而且前沿实验室的职位描述越来越直白地把企业集成与 AI 工作并列列出。910

认证——一个人如何证明自己是谁？账号开通——账号如何被创建，以及更重要的，如何被销毁？授权——这个人被允许做什么，并且要以他们的管理员无需打电话给你就能自行修改的方式表达？工作负载身份——你的软件如何向他们的系统证明自己的身份，而不是把一个密钥粘贴在配置文件里？

安全审查员提出的每一个异议，本质上都是这四个问题之一的变体。能够说出对方问的是哪一个，能大大缩短会议时间。

身份工作往往在安全审查时才被发现，而安全审查发生在项目后期——那时时间表早已定死。不如在范围界定阶段就提出身份问题——“用哪个 IdP、是否要求 SCIM、谁来审批应用注册？”——只需九十秒，却常常能提前暴露一个原本会在上线前一周才出现的为期四周的依赖项。

SAML 还是 OIDC——以及当你别无选择时

两者都能证明用户是谁。但在其他几乎所有方面它们都不相同，而且通常由客户替你做决定。

维度SAML 2.0OIDC（OAuth 2.0）
年代/形态2005 年，XML，浏览器 POST 重定向2014 年，JSON + JWT，为 API 和移动端而生
典型用途Web SSO 登录企业应用Web、原生应用、机器对机器、令牌交换
谁会要求它成熟企业、政府机构、任何还在用 2010 年代 IdP 的组织较新的技术栈、任何移动端场景、任何 API 优先的产品
签名模型对断言做 XML-DSig 签名——出了名地容易验证出错对紧凑令牌做 JWS 签名，有标准库支持
Session logout单点注销（Single Logout）存在，但实践中并不可靠Back-channel logout 更好，但并不通用
你的工作量元数据交换、证书轮换、属性映射应用注册、作用域（scope）、同意授权、令牌验证

实际的答案是：两者都支持，以 OIDC 为主，但也要预期 SAML。一家拥有成熟的 Active Directory Federation Services 或老旧 Okta 租户的大型受监管客户，会直接交给你 SAML，没有其他选择。争论只会消耗你的好感，也改变不了结果。

1. 验证签名

针对断言（assertion）本身，而不仅仅是响应外层

2. 检查 Audience、Recipient、NotBefore/NotOnOrAfter 以及 InResponseTo

3. 直接拒绝未签名的断言——不要留“缺失时回退”的分支

4. 固定 IdP 证书并

为它的到期时间设置日历提醒；证书轮换是上线后 12–24 个月

“今天早上谁都登录不了”事故的头号原因

5. 显式映射属性；绝不要把显示名称当作标识符

电子邮箱会变——人们会结婚，公司会改名，一次收购会重写目录里的每一个地址。请以 IdP 的不可变主体标识符（

oid

在 Entra 中，

NameID

在 SAML 中为持久化格式）作为用户记录的主键，并把邮箱当作显示属性。在客户完成域名迁移之后再补救，就是一场没人做过预算的数据修复工程。

SCIM：真正决定成单的问题

“有人离职时会发生什么？”如果你的回答里出现“email”这个词，你就没通过安全评审。

SSO 回答的是“这个人是谁”。它不回答“这个人是否还应该拥有账户”。一个从客户目录中被移除的用户虽然无法再通过 SSO 登录——但他们的账户、API 令牌、定时任务和数据导出都仍然存在于你的系统中，除非有什么东西把他们删掉。SCIM 正是填补这一空缺的标准，而有合规职能的企业买家会点名要求它。

POST /scim/v2/Users 创建

GET /scim/v2/Users?filter=... 按 userName 查找（他们一定会用 filter；要支持）

PATCH /scim/v2/Users/{id} 部分更新——

停用就是通过这个操作送达的

DELETE /scim/v2/Users/{id} 硬删除——很多 IdP 从不调用它

PATCH /scim/v2/Groups/{id} 成员变更，add/remove 操作

# 比其他所有字段都重要的字段

{"op":"replace","path":"active","value":false} ← 取消配置（deprovisioning）通常就是这个，

而不是 DELETE。如果你只实现了 DELETE，离职流程就会静默地什么也不做。

一次就做对

  • active:false 必须撤销会话和 API 令牌，而不仅仅是阻止新的登录。
  • 支持 PATCH 的 operations 语法——Entra 和 Okta 都大量使用它。
  • 保持幂等。IdP 会重试、重放并重发同一个操作。
  • 返回正确的状态码：重复的 userName 返回 409，未知的 id 返回 404。
  • 记录每一次 SCIM 操作。这是审计人员索要的证据链。

出错时耗费数周

  • 把停用当作软标记，而你的应用在 API 层又将其忽略。
  • 忽略组成员关系，导致授权在一个月内就与目录产生偏差。
  • 非幂等的创建操作——IdP 一重试，你就会得到重复用户。
  • GET /Users 没有实现分页，一旦租户达到 5,000 人就会崩溃。
  • 想当然地认为你的 SSO 提供商会替你处理 SCIM。务必验证。通常它并不会。

坦率地说明情况，并提供一个带日期的补偿性控制措施：一个定时目录对账任务，每天运行，停用任何不再存在于目录中的用户，并生成客户可查验的日志。安全审查人员接受有明确负责人和路线图日期的书面补偿性控制措施的概率，远比人们想象的高。他们不会接受的是含糊其辞的保证——而且无论如何他们都会发现真相，因为他们会实际测试。

在组织重组后依然有效的授权

他们的组每周都在变。你的角色绝不能变。

直觉做法是把他们的组直接映射到你系统中的权限。这能撑一个月。然后一次组织重组把

FIN-AP-ANALYSTS

改成了

FIN-OPS-AP-TIER1

，一切失效，而 FDE 因为一个没人告知他们的目录变更被半夜叫醒。解决方案是加一层间接层，让客户管理员无需你参与就能自行操作。

他们的目录组 FIN-AP-ANALYSTS、FIN-AP-MANAGERS、IT-PLATFORM-ADMIN

↓ 一张映射表

他们的管理员在界面中编辑

你的角色 审阅者 · 审批人 · 管理员

↓ 固定、有版本控制、属于你产品的一部分

你的权限 document:read · document:approve · settings:write · export:all

上线时三个角色通常就够了，而且客户能理解的三个角色胜过只有你能解释清楚的十二个。当有人带着具体场景提出需求时再加第四个，而不是未雨绸缪。

在设计任何东西之前，先索要组列表

不是组织架构图——而是实际的安全组及其成员数量。人们口中的组织结构与目录中实际内容的偏差是常态，而你的代码面对的是目录。

默认拒绝，并让空状态是安全的

一个成功通过身份验证但不匹配任何组映射的用户，应得不到任何访问权限，并收到一条清晰的消息，告知该找谁。未映射用户被静默赋予默认角色的失败模式，正是数据从错误的部门泄露出去的原因。

让映射自助化且可审计

一个他们的 IT 管理员可以使用的界面，每一次变更都有日志记录并可追溯到人。仅这一个界面就能让你摆脱一个反复出现的支持循环，否则这个循环会贯穿整个合作周期。

将数据级范围控制与角色分开处理

“审批人”是一个角色。“仅限 EMEA 实体的审批人”是一个数据边界，把它塞进角色名称里，两个季度内就会产生组合爆炸。从一开始就把这两个维度分开——事后补上行级权限控制就是一次数据库迁移。

工作负载身份：你的软件如何证明自己是谁

人类 SSO 只是问题的一半。另一半是那个没人轮换凭证的服务账号。

你的部署要从他们的数据仓库读取数据，写入他们的对象存储，并调用模型端点。其中每一项都是一个身份验证决策，而默认做法——把长期有效的凭证放在环境变量里——正是每一份关于企业部署的安全报告中都会出现的问题。

方案代价何时是正确选择
配置中的静态密钥轮换全靠手动，因此永远不会发生；密钥迟早会出现在日志或截图中在客户环境中，永远不要用。这是一个等着被写进报告的安全问题。
密钥管理服务（Vault、Secrets Manager、Key Vault）一个依赖项，需要协商一个访问策略现实的基线方案。问他们用的是哪一个——他们一定有一个。
云原生工作负载身份（IRSA、workload identity federation、managed identity）需要与他们的云团队做一次性设置部署到他们的云中时的正确答案。不存在可泄露的密钥。
mTLS / SPIFFE真正的基础设施工作和一场关于 CA 的对话适合成熟的平台团队和服务网格；不要向两者都没有的团队提议。

不要向他们的云团队要“数据仓库的访问权限”。把确切的清单发给他们：这三张表、只读、来自这个服务账号、来自这个子网。具体的请求几天内就能获批，因为它易于审查；宽泛的请求会被上报，然后被反复讨论，最后被一个不了解你需求的人删减——而你要到运行时才会发现他们删了什么。写一份范围明确的请求，也是最快发现你其实申请了不需要的东西的方法。

身份才是安全审查真正关注的东西

问卷和与 CISO 的通话正是检验这些决策的地方。这个严苛考验实验室会用与你类似的部署来同时检验这两者。

审查者会向你要的证据

企业安全审查在很大程度上就是索要材料。把这些材料准备好，能把三周的来回拉锯变成一通电话，而准备它们只需要一个下午。

一张身份架构图

一页纸：IdP、协议、哪些声明（claims）在流转、会话存放在哪里、令牌如何验证、谁用什么身份与谁通信。审查者只会批准他们能想象出来的东西。

一次入职/调动/离职流程走查

三段文字，描述有人入职、换团队和离职时你的系统中会发生什么。第三段是他们最关心的，而且答案必须包含一个时间上限。

一份审计日志样本

实际脱敏后的日志行，展示认证事件、权限变更和数据访问，并注明保留期限。“我们记录一切”不是证据；十行日志才是。

一套紧急访问（break-glass）流程

当客户的身份提供商（IdP）宕机而必须有人进入系统时会发生什么。每位评审者都会问这个问题，因为诚实的答案往往是一个没有记录在案的本地管理员账号，而他们对此心知肚明。

一份具名的差距清单

你目前尚不支持的功能，附上时间表。主动披露这一点看似反直觉，却非常有效——这是安全评审中可用的最强可信度信号，因为评审者的职责就是找出你没有提到的内容。

在大型企业 IdP 中注册应用不是一项技术任务，而是一条审批链——通常需要两到四周，偶尔还要经过季度评审委员会。在第一周就与需求调研同步启动，哪怕你还没有任何东西可注册。提交申请只需发一封邮件；到第八周才发现要排队，付出的代价就是上线日期。

全景图：一次离职事件需要触达哪些环节

这在生产环境和面试中的体现

  • 安全问卷其中的身份相关部分，就是本页四个问题换了名字的版本：SSO 支持、账号开通与停用、基于角色的访问控制，以及密钥或服务账号。每一项都用第 06 节的工件来回答，而不是用一句话应付，这正是把问卷变成一次电话会议的关键。
  • 访问审查与审计客户的审计师可以随机挑选已离职人员，要求你证明其每个账号都已被停用，以及停用的具体时间。带时间戳的 SCIM 操作日志就是这份证明。每日对账任务的日志同样可以作为补偿控制措施的证明。
  • 并购与域名迁移一次改写目录中所有邮箱地址的收购，对客户来说是常规操作，对任何以邮箱为主键的应用来说却是一场数据修复工程。以 IdP 不可变的 subject 标识符为主键的记录则毫发无损地安然度过。
  • 面试角度“为一个多租户 B2B 应用设计 SSO 和账号开通流程”是一道标准的系统设计题。优秀的回答会把认证与开通流程分开，明确指出 active:false 是处理离职的路径，以 subject ID 作为用户主键，在目录与权限之间放一张组到角色的映射表，并把数据范围控制放在独立的维度上。

自我检验

你实现了 SCIM DELETE 但没有实现 PATCH。客户的 IdP 停用了一名离职员工。你的系统里会发生什么？

很可能是什么都不会发生。大多数 IdP 通过 PATCH 将

active

设为 false 来停用用户，可能永远不会发送 DELETE。PATCH 请求失败或被忽略，账号保持活跃，离职员工的 API 令牌和定时任务继续运行。SSO 会阻止新的登录，这反而让问题容易被忽视，直到审计师来测试才发现。

收购完成后，某用户的邮箱从 a@old.com 变为 a@new.com。你的用户表以邮箱为主键。他们下一次 SSO 登录会发生什么？

它找不到使用新邮箱的用户，于是要么创建一个没有任何数据和权限的重复账户，要么直接拒绝该用户。旧账户成了孤儿账户，但仍保留着他们的历史记录和令牌。以 IdP 的不可变主体标识符（

oid

在 Entra 中是 immutable ID，在 SAML 中是持久 NameID）作为键，这次变更就只是一次显示名称的更新。

某人认证成功，但不属于任何已映射的组。他们应该获得什么？

无访问权限，外加一条告知他们谁能授予权限的消息。认证只能证明他们是谁，而不能证明他们可以做什么。回退到默认角色，正是导致某个未映射部门的用户读到本不属于他们的数据的原因。

客户想把你的三个角色按四个地区拆分：“仅限 EMEA 的审批人”等等。把地区编码进角色里，你要维护多少个角色？如果用独立的数据范围维度呢？

编码进角色名：3 × 4 = 12 个角色，再加第五个地区就变成 15 个。用独立维度：3 个角色加 4 个范围，第五个地区只需增加一个范围。映射表保持得足够小，客户的管理员能够管理，而且新增一个地区也不意味着要重命名角色。

快速问答

企业集成应该使用 SAML 还是 OIDC？

两者都支持，以 OIDC 为主，并预期会遇到 SAML。OIDC 基于 JSON/JWT，更适合 API、移动端和机器对机器的流程。SAML 2.0 基于 XML，而且对于拥有成熟 Active Directory 或较旧 Okta 租户的大型受监管企业来说，它仍是他们会交给你的方案——通常不提供其他选择。由客户的身份提供商决定，而不是你。

为什么 SCIM 在企业交易中如此重要？

SSO 回答的是用户是谁；它并不回答该用户是否还应保留账户。一个从客户目录中被移除的用户虽然无法再登录，但除非有东西将其删除，否则他们的账户、API 令牌和定时任务依然存在。SCIM 自动化配置以及至关重要的取消配置——后者通常以一个将 active 设为 false 的 PATCH 请求而非 DELETE 的形式到来。如果你只实现了 DELETE，离职流程就会悄无声息地毫无作用。

应该如何将客户的组映射到你产品中的角色？

永远不要把目录组直接映射到权限。在中间放一张客户管理员可以编辑的映射表：他们的组映射到你的一小组固定角色（上线时通常为三个），这些角色再映射到权限。目录组会在组织重组时被重命名；你的角色绝不能随之改变。把数据级范围限定——例如“仅限 EMEA 的审批人”——放在与角色独立的维度上，否则角色列表会呈组合式爆炸增长。

已部署的应用应如何向客户系统进行认证？

在部署到客户的云环境时，优先使用云原生的工作负载身份（IRSA、工作负载身份联合、托管身份），因为这样根本不存在可泄露的密钥。否则就使用客户现有的密钥管理服务。绝不要在配置文件或环境变量中使用长期有效的静态密钥——这是每份企业安全报告中都会出现的问题，因为轮换会变成手动操作，因而永远不会执行。

身份相关工作应该在部署的什么阶段开始？

在界定范围的阶段，第一周就开始。身份问题通常是在安全审查时才被发现，而安全审查发生在项目后期，那时时间表已经定死。问一句“你们用哪个 IdP、是否要求 SCIM、谁来审批应用注册？”只需要九十秒，却往往能提前暴露一个长达四周的审批依赖。在大型企业中，应用注册是一个需要两到四周的审批链条，有时还要受季度评审委员会的制约。

来源

本页上的每个数字都可以追溯到以下来源之一。凡是自报或众包而非第一方的数据，都会在文中就地标注。

本页引用的内容

气隙与受监管部署 → 接下来：“客户级生产”阶梯 · 第 7 级，共 11 级

探索相关主题

将本主题与同一领域的所有其他内容放在一起查看——手册、系统设计、挑战和工具，尽在一处。

更多手册