企业
来自你身份提供商的 SCIM 供给
新成员、职位变动与离职人员会自动从你的 IdP 流转过来——没有手动账号管理,也没有等着变成审计发现的孤儿访问权限。
SCIM 供给把 Ciao 连接到你的身份提供商,因此用户账号会随着你的目录变化而自动创建、更新和停用。与手动账号管理不同,SCIM 消除了离职流程最容易失败的那个人工步骤:当一名用户在你的 IdP 中被停用时,这项变更会传播到 Ciao,相关的管理员操作会进入你的审核人员可以检查的只增不减审计日志。
发布日期 2026-07-03 · 最近更新 2026-07-03
孤儿账号是等着发生的审计发现
每一次访问评审都会发现它们:属于几个月前换了岗位或已经离职的人的账号,依然处于激活状态,因为撤销供给这件事,依赖着一张从来没人提交的工单。在大多数 SaaS 工具里,这是一个暴露风险的问题。而在一个已登录用户可以提示改动生产软件的平台里,这同时也是一个变更控制的问题——一个没人拥有的账号,却具备向你业务所依赖的系统提议变更的能力。
SCIM 的存在正是为了消除这个手动步骤。你的身份提供商已经是“谁在这里工作、属于哪个组”这件事的真相来源;SCIM 让 Ciao 成为这个真相的订阅者,而不是一份需要管理员记得去对账的独立清单。
审计员已经形成了共识:依赖手动对账的访问评审会积累发现问题,而生命周期自动化是公认的解决方案。如果你的组织已经为其他重要系统运行了 SCIM,把它扩展到这个构建和部署软件的平台上,是一个一致的做法——如果 Ciao 会是你的第一个 SCIM 集成,下面的推广步骤特意设计得较为保守。
SCIM 供给覆盖什么
覆盖范围涵盖你的访问评审真正会测试的生命周期事件:
- 创建账号 — 在你的 IdP 中被分配给 Ciao 的用户,会自动获得供给的账号——没有请求队列,不用手动创建。
- 属性更新 — 姓名和资料的变更会从目录中流转过来,因此账号记录会跟随这个人变化,不需要管理员介入。
- 用户组到角色的映射 — IdP 中的用户组可以映射到 Ciao 的角色,因此基于角色的访问控制是由你的团队已经在治理的目录结构驱动的。
- 停用 — 当你的 IdP 停用一名用户时,他们对 Ciao 的访问权限会作为生命周期流程的一部分被移除——这正是手动离职流程最常遗漏的那一步。
- 审计记录 — 供给相关的变更属于管理员操作,管理员操作会与提示词、合并和部署一起,被记录进只增不减的审计日志。
推广是如何进行的
1. 从 SSO 开始
SCIM 假定通过 SAML 或 OIDC 实现的 SSO 已经就位,因此身份验证和供给共享同一个身份来源。
2. 连接 IdP
在接入过程中,于你的身份提供商中配置 SCIM 集成,企业团队会与你的身份工程师一起完成这个过程。
3. 把用户组映射到角色
决定哪些 IdP 用户组对应哪些 Ciao 角色和项目范围,并把这份映射记录下来——它会成为你访问控制文档的一部分。
4. 用一个用户组做试点
分配一个小的用户组,在扩大范围之前,验证创建、更新和停用事件是否按预期发生。在试点中至少包含一次停用操作——这是最重要的事件,也是团队最常忘记测试的那一个。
5. 在审计日志中验证
确认供给事件是否作为管理员操作出现在只增不减的日志中,让你的访问评审拥有证据,而不是假设。
把 SCIM、SSO、RBAC 和审计日志当作一个系统
这四项控制措施的设计初衷,就是被放在一起审阅。SSO 回答人们是如何进行身份验证的;SCIM 回答账号是如何产生和消失的;基于角色的访问控制回答一个经过身份验证的人可以做什么;而只增不减的审计日志则记录他们实际做了什么——提示词、合并、部署与管理员操作。审核人员可以追踪一个人,从目录用户组,到 Ciao 角色,再到一次具体的、记录在案的操作,而这正是大多数访问控制框架真正想要的可追溯性叙事。
在实践中,这种组合改变了一次访问评审的质感。审核人员不再需要采访管理员他们相信发生了什么,而是直接阅读发生了什么:目录事件、由此产生的角色、以及在这个角色之下采取的行动。评审时间从收集证据转移到了做判断,而这正是它应该待的地方。
生命周期事件及其影响
把这个当作你试点的检查清单:用一个测试用户逐一运行每个事件,并验证效果。
| 生命周期事件 | 在 Ciao 中发生什么 | 在哪里验证 |
|---|---|---|
| 用户在 IdP 中被分配 | 账号被供给,并带有映射好的角色 | 审计日志中的管理员操作 |
| 属性发生变化 | 账号记录从目录中被更新 | 账号详情与审计日志 |
| 用户组成员发生变化 | 映射的角色和范围跟随目录变化 | RBAC 配置与审计日志 |
| 用户在 IdP 中被停用 | Ciao 的访问权限通过生命周期流程被移除 | 审计日志与访问评审 |
| 工作区内容 | 应用和代码依然归工作区所有 | 代码随时可导出 |
验证说明
供给是你的团队应该测试、而不是当作信念来接受的一项控制措施。在评估过程中,用一个测试用户端到端运行这个生命周期——分配、更新、停用——并在审计日志中查看结果。你所使用的 IdP 的具体集成细节会在接入过程中说明,安全资料包可通过联系页面按需索取,以书面形式为需要详细信息的审核人员记录身份架构。
如果你的推广有一些不寻常的约束——需要淘汰的共享账号、使用独立 IdP 的承包商、分阶段的迁移——请在试点之前以书面形式告知企业团队,以便配置是针对你的实际情况来设计的,而不是事后调整。
常见问题
哪些身份提供商可以驱动 SCIM 供给?
SCIM 是一项标准,企业通常运行的身份提供商——Okta、Microsoft Entra ID 及类似产品——都实现了它。请在接入过程中与企业团队确认你具体的 IdP 及配置方式。
一个人在被撤销供给后,他的工作会怎样?
他的访问权限会被移除;工作不会消失。应用和代码归工作区所有,拥有 100% 的代码所有权,并可随时导出到你自己的代码仓库——一个人的离职,永远不会让软件陷入困境。
SCIM 会取代即时创建账号吗?
它们解决的是不同的两半问题。JIT 在首次登录时创建账号;SCIM 管理持续的生命周期,包括更新和停用。许多推广方案在试点阶段使用 JIT,在全面部署时使用 SCIM。
供给和撤销供给的操作会被记录吗?
会。它们属于管理员操作,与提示词、合并和部署一起被记录进只增不减的审计日志——因此访问评审可以引用记录在案的事件,而不是截图。
在全公司推广之前,我们该如何验证 SCIM?
用一个测试用户组做试点:分配、更改属性、调整用户组、停用,并在审计日志中验证每一个事件。企业团队会支持这次试点,安全资料包会记录接受审阅的身份架构。