共享 SaaS 账号:你正在承担的合规风险
共享 SaaS 账号是一种合规风险,因为一个登录对应的是多个人而不是一个人,这破坏了 SOC 2、ISO 27001 以及大多数供应商许可协议都要求的审计追踪。如果一个客服登录、一个设计工具席位或一个社交媒体账号被不止一个人使用,你就无法回答谁在何时做了什么,而这一个缺口就足以让控制测试不通过,或使按命名用户计费的许可条款失效。
- 共享账号是指任何被不止一人使用的登录,无论是设计成这样,还是逐渐演变成这样。
- 风险不在密码本身,而在于失去了审计方和许可协议都要求的登录与个人之间的一对一关联。
- SOC 2 和 ISO 27001 都包含身份与访问控制条款,共享账号会直接不符合这些要求。
- 大多数按席位计费的许可协议将一个席位定义为一个具名个人,因此共享登录可能构成违约,而不只是安全隐患。
- 找出它们只需按工具逐一导出:标记出名字是角色、团队或产品而非个人的账号。
什么算作共享 SaaS 账号?
三种模式覆盖了审计中出现的大部分情况。一种是基于角色的登录,如 support@ 或 social@,从一开始就设计为供一个团队共同使用。一种是单个具名账号,其密码存放在共享文档或整个团队都能打开的密码管理器保险库中。还有一种是承包商或代理机构的登录,合同结束后仍在使用,继续交给下一个需要它的人。第一种是有意为之,有时也难以避免。后两种则会悄悄累积,也是审计人员最先发现的,因为它们的名字仍是一个人,实际使用者却有好几个。
共享登录为何会造成合规风险?
每一个访问控制框架都建立在同一个假设上:一个登录对应一个负责人。一旦打破这个关联,三件事会同时失效。你无法证明是谁在工具中执行了某个操作,而这正是审计人员在测试访问控制时会问的问题。你无法只撤销某一个人的访问权限,而不把共用该登录的其他人一并锁在外面,这把离职处理变成了一次集体事件,而不是单独移除。你也无法呈现人员与许可证之间干净的对应关系,而这恰恰是供应商审计或续约谈判首先要检查的内容。
这个缺口在离职时暴露得最快。阅读查找闲置 SaaS 许可证的指南,了解能抓出离职后仍保留访问权的人的审计方法;共享账号是那次审计唯一无法单独解决的情况,因为移除这个人并不会移除这个登录。
哪些标准真正禁止这样做?
几乎每一次 SaaS 公司的审计都会遇到两个框架,而它们都把共享账号视为一项不合格项,而非可选做法。
| 框架 | 要求内容 | 共享账号在何处不达标 |
|---|---|---|
| SOC 2(安全标准,逻辑访问控制) | 访问权限按个人授予、审查和撤销,并能将某项操作追溯到具体个人 | 共享登录无法追溯到某一个人,撤销一名离职者的访问权会影响所有共用该账号的其他人 |
| ISO/IEC 27001:2022,附录 A.5.16(身份管理) | 每一个用于访问信息的身份都在其完整生命周期内被管理,绑定到一个人,或绑定到一个有责任人的已批准服务账号 | 未被管理的共享登录没有生命周期责任人,也没有记录当前由谁持有 |
| 按席位计费的供应商许可协议 | 一个席位被定义为一个具名个人,而非一个角色或团队 | 多人共用一个席位属于许可未覆盖的使用方式,供应商可在审计或续约时以此判定违约 |
这三者都没有一概禁止基于角色的账号。它们要求这类账号有一个具名的负责人,以及一个有记录的存在理由,而这恰恰是大多数公司会跳过的部分。
如何找出你已经拥有的共享账号?
和任何许可证审计一样,起点是按工具逐一导出:从每个管理后台拉取用户名单,标记出名字不是个人的登录。第一轮筛选是名字为团队、角色、产品或通用词的登录。第二轮更难,也能抓到更多:任何具名账号,如果其所有者离职已超过一个月而登录仍处于活跃状态,往往并未真正停用,而是被下一个需要访问权限的人继续沿用。
在 InventorIA 的演示工作区中,24 个许可证里的每一个都绑定到一个具名个人,而不是一个角色,这正是审计人员会核查的那种对应关系,也是共享登录一出现在名单中就会破坏的关系。
如何在不打断工作流程的情况下移除共享登录?
- 在许可允许的情况下改为具名席位。大多数按席位计费的供应商也支持在同一方案下设置多个具名用户;共享登录往往只是图省事的做法,而非必需。
- 用委派访问权限代替角色账号。支持 SSO 或 SCIM 的工具可以让一组人通过各自的身份访问共享收件箱或频道,而无需共用密码。
- 保留例外,但指定负责人。有些账号确实需要保持基于角色,例如状态页面的登录。为它指定一个具名负责人,在负责人变更时轮换凭证,并记录保留例外的原因。
- 把决定记录下来。相比审计人员自己发现的、没有记录的例外,他们更容易接受一个有记录在案的例外。
如果还有一个共享账号,该如何向审计人员说明?
不要等审计人员发现它。在审查开始前,列出你已知的每一个共享或基于角色的登录,说明其存在的业务理由、负责人是谁,以及凭证最近一次轮换的时间。这份清单通常足以把一项不合格项变成一个被接受的例外,因为它表明即便登录是共享的,控制措施本身依然存在。许可证使用率指南介绍了审计人员接下来会要求的席位对人员的数字,影子 IT 检测则涵盖了那些从未被登记为公司账号的工具,是同一个缺口的更上一层。一个把每个许可证都绑定到一个具名个人、并有意标记例外的登记册,能把这件事从审计前的仓促应对变成五分钟就能给出的答案。打开在线演示查看席位与具名个人的绑定关系,或从你自己的工具开始。
常见问题
共享 SaaS 账号是否总是违反合规要求?
并非自动如此。SOC 2 和 ISO 27001 等框架允许基于角色的账号,只要它有具名负责人、有记录的理由,以及轮换和审查流程。没有追踪、没有负责人的共享登录才是审计不通过的那种情况。
共享登录会违反按席位计费的许可协议吗?
通常会。大多数按席位计费的协议将一个席位定义为一个具名个人。多人共用同一席位的凭证属于许可未覆盖的使用方式,供应商审计可能将其标记为违约。
如何在我们的 SaaS 工具中找出共享账号?
从每个管理后台导出用户名单,标记出名字是角色、团队或产品而非个人的登录,再检查那些所有者已离职但登录仍处于活跃状态的具名账号。
共享账号和服务账号有什么区别?
服务账号用于对接集成或脚本进行身份验证,而非针对某个人,通常根本没有交互式登录。共享账号则是被不止一人使用的人工登录,这正是审计人员会标记的模式。
单点登录能否消除对共享登录的需求?
在大多数情况下可以。SSO 和 SCIM 让多人可以通过各自的身份访问共享收件箱、频道或工具,而不需要共用密码,从而恢复审计人员所要求的一对一对应关系。