3. SaaS身份与访问管理基础
SaaS 环境中的身份与访问管理（IAM）不是“给员工开个账号”这么简单。它要回答四个连续的问题：这个人是谁、他如何证明自己是谁、他被允许做什么、以及当他离职或角色变化时权限如何收回。SaaS 的特殊性在于身份数据分散在多个应用、多个租户和多个协议之间，IAM 因此成为连接“人”与“资源”的控制平面。
身份生命周期：从入职到离职的闭环
身份生命周期描述一个数字身份从创建到销毁的全过程，通常包括：申请与审批、创建（Provisioning）、权限分配、变更（如转岗）、暂停、离职回收（Deprovisioning）。在 SaaS 场景中，这一周期往往由 HR 系统触发，经 IAM 或身份治理平台同步到各 SaaS 应用。
以某公司使用 Workday 作为 HR 源、Okta 作为 IdP、Salesforce 与 Slack 作为下游 SaaS 为例：新员工入职时，HR 系统生成员工记录，Okta 通过 SCIM 协议自动在 Salesforce 中创建用户，并按“销售代表”角色分配基础权限；转岗到销售经理时，角色变更触发权限增量更新；离职时，HR 状态变为“终止”，Okta 立即停用账号并撤销所有下游会话。这个闭环的关键在于权威源唯一——如果 HR、IT 和 SaaS 各自维护一份用户列表，就会出现“幽灵账号”和权限残留。
认证与授权：先证明身份，再决定能做什么
认证（Authentication）解决“你是谁”，授权（Authorization）解决“你能做什么”。两者常被混为一谈，但在 SaaS 安全中必须分开设计。
认证的强度由认证因子决定：单因素（密码）、双因素（密码 + TOTP 或推送）、多因素（密码 + 硬件密钥 + 生物特征）。SaaS 中常见的认证方式包括：本地密码、SAML/OIDC 联合登录、社交登录、API Key、OAuth 客户端凭证。对于高权限管理后台，应强制使用抗钓鱼的 FIDO2/WebAuthn 安全密钥，而不是短信验证码。
授权模型则决定权限的粒度。常见模型包括：
- RBAC（基于角色的访问控制）：用户 → 角色 → 权限。适合职责边界清晰、角色数量可控的场景，如“销售代表”“销售经理”“财务管理员”。
- ABAC（基于属性的访问控制）：根据用户属性、资源属性、环境条件动态判断。例如“仅允许在办公网络内、且设备合规时访问客户数据”。
- ReBAC（基于关系的访问控制）：根据实体间关系授权，如“文档所有者可编辑，协作者可评论”。
在 SaaS 中，授权还常涉及租户隔离：同一应用内，A 公司的用户绝不能看到 B 公司的数据。这要求授权判断中必须包含租户标识，并在数据访问层强制过滤。
IAM 在 SaaS 中的角色
IAM 在 SaaS 中扮演三个核心角色：身份权威源、访问策略执行点、审计与合规证据源。它向上对接 HR 和 IT 系统，向下通过标准协议连接各 SaaS 应用，横向为安全团队提供“谁在何时访问了什么”的日志。
一个典型的 SaaS IAM 架构包含：目录服务（如 Azure AD/Okta Universal Directory）、联合身份服务（SAML/OIDC）、Provisioning 服务（SCIM）、策略引擎（RBAC/ABAC）、会话管理、审计日志。当用户访问 Salesforce 时，请求先被重定向到 IdP 完成认证，IdP 返回 SAML 断言，Salesforce 根据断言中的属性映射角色并授权。整个过程用户只输入一次凭证，这就是 SSO 的价值。
SSO 与联邦身份的核心机制
SSO（单点登录）让用户一次认证后访问多个应用；联邦身份（Federated Identity）则让身份信息跨安全域传递。两者常一起出现，但 SSO 强调“一次登录”，联邦强调“跨域信任”。
核心机制是信任关系 + 断言传递。以 SAML 2.0 为例：
- 用户访问 SaaS 应用（SP，服务提供者）。
- SP 生成 SAML Request，将用户重定向到 IdP。
- IdP 认证用户（若未登录），生成 SAML Response，其中包含断言（Assertion）：用户标识、属性（邮箱、角色、部门）、签名。
- SP 验证签名和有效期，提取属性，建立本地会话。
OIDC 则基于 OAuth 2.0，使用 ID Token（JWT）传递身份信息，更适合移动端和 API 场景。无论 SAML 还是 OIDC，关键安全点都是：签名验证、断言有效期、受众限制（Audience）、防重放。如果 SP 不校验 Audience，攻击者可能用发给 A 应用的断言登录 B 应用。
实际落地中的关键判断
在 SaaS IAM 落地时，有几个容易被忽视但影响很大的判断点。第一，权威源选择：HR 系统通常是最合适的身份权威源，因为它掌握雇佣关系的开始与结束；但如果外包人员、合作伙伴不在 HR 系统中，就需要额外的身份源或手动流程。第二，协议选择：新应用优先选 OIDC，因为它对移动端和 API 更友好；已有 SAML 投资的企业可保留 SAML，但需确保 SP 正确校验 Audience 和签名。第三，权限回收的时效：离职后权限应在分钟级而非天级回收，这要求 SCIM 同步和会话撤销机制可靠。
一个可操作的检查清单如下：
| 检查项 | 判断标准 | 常见问题 |
|---|---|---|
| 权威源唯一性 | HR 或指定 IdP 为唯一用户创建入口 | 多系统各自建号，导致账号不一致 |
| SSO 覆盖率 | 核心 SaaS 应用 100% 接入 SSO | 部分应用仍用本地密码，形成绕过路径 |
| MFA 强制范围 | 管理员和高权限角色强制 FIDO2 | 仅短信验证，易被 SIM 交换攻击 |
| SCIM 同步时效 | 离职后 5 分钟内停用下游账号 | 仅停用 IdP，未撤销 SaaS 会话 |
| 授权最小化 | 按角色分配，定期复核 | 权限只增不减，形成权限膨胀 |
| 审计日志完整性 | 记录登录、授权、权限变更事件 | 日志分散，无法关联到具体身份 |
最后需要强调：IAM 不是一次性项目，而是持续运营的能力。身份会变、角色会变、应用会变，只有把生命周期、认证、授权和联邦机制串成闭环，SaaS 环境中的访问治理才真正可控。