4. 身份与访问治理集成

CASB如果只做流量代理和API扫描，它看到的只是“某个IP访问了某个SaaS”。真正决定“谁、在什么条件下、能对哪些数据做什么”的，是身份。因此CASB工程的第一条主线，是把企业已有的身份体系（IdP）接进来，让CASB的每一次判定都建立在可信身份之上。本章围绕IdP对接、SSO/MFA联动、用户与组映射、条件访问策略落地四个环节展开。

一、IdP对接：CASB的身份源

企业身份通常集中在Azure AD（现Entra ID）、Okta、Google Workspace或自建Keycloak中。CASB与IdP的对接方式主要有三类：

• SAML 2.0 / OIDC 联合登录：CASB作为SP（服务提供方），IdP作为IdP，用户登录SaaS时由IdP签发断言。CASB通过解析断言获得用户标识、组、MFA状态。
• SCIM 2.0 用户同步：IdP作为SCIM Server，CASB作为SCIM Client，按增量方式同步用户与组的增删改。这是“用户与组映射”的数据来源。
• IdP API 拉取：通过Microsoft Graph、Okta Users API定期拉取用户、组、设备合规状态，适合需要设备上下文的场景。

对接前必须确认三件事：IdP中用户唯一标识（如userPrincipalName或email）与CASB账号字段的对应关系；组是否包含嵌套组；MFA声明是否在断言中透出（SAML的AuthnContext或OIDC的amr）。若MFA声明缺失，CASB无法判断“本次登录是否已通过MFA”，后续条件访问就会失真。

二、SSO与MFA联动：从“登录成功”到“可信会话”

SSO解决的是“一次认证、多应用通行”，MFA解决的是“认证强度”。CASB需要把两者串成一条可信会话链：用户访问SaaS → 重定向到IdP → IdP执行MFA → 签发断言 → CASB校验断言并建立会话 → 会话中携带用户、组、MFA时间、设备信息。

关键工程点在于会话生命周期。IdP的会话有效期（如8小时）与CASB的会话缓存（如30分钟）往往不一致。若CASB缓存过长，用户已在IdP登出，CASB仍放行；若过短，用户频繁重认证。建议CASB会话TTL不超过IdP会话TTL，并在IdP登出时通过SLO（单点登出）通知CASB失效会话。

MFA联动还要处理“步进认证”：低敏感应用仅需密码，访问财务SaaS时要求MFA。CASB可在策略中引用IdP的amr声明，若断言中不含mfa，则拒绝或触发二次认证。

三、用户与组映射：让策略可维护

策略不应绑定到单个用户，而应绑定到组。映射的核心是建立“IdP组 → CASB组 → 策略”的稳定链路。常见做法：

• 在IdP中维护CASB-Finance-Users、CASB-Contractors等组，SCIM同步到CASB。
• CASB中不直接使用IdP组名，而是映射为内部角色，如role:finance、role:contractor，避免IdP改名导致策略失效。
• 对嵌套组做扁平化处理，确保成员变更在同步周期内生效。

映射表应记录：IdP组ID、CASB角色、同步方式、最后同步时间、成员数。当成员数异常（如从200骤降到5）时触发告警，防止误删组导致策略大面积失效。

四、条件访问策略在CASB中的落地

条件访问（Conditional Access）的本质是“如果满足条件，则执行控制”。在CASB中，条件通常包括：用户/组、设备合规状态、地理位置、IP信誉、应用敏感度、时间窗口；控制包括：允许、阻断、要求MFA、仅允许只读、加水印、禁止下载。

落地时建议采用“基线+例外”结构：先定义全局基线（如所有访问必须来自合规设备），再为财务、研发等敏感组叠加更严控制。策略冲突时，CASB一般按“最严格优先”或“显式拒绝优先”执行，需在策略引擎中明确优先级。

下面这张图展示从IdP到CASB策略执行的完整信号链，包括SSO/MFA、SCIM同步、条件访问判定与最终控制动作。

五、落地检查与常见问题

对接完成后，建议按以下顺序验证：

1. 用测试账号走一遍SSO，确认CASB能解析出userPrincipalName、组列表、MFA声明。
2. 在IdP中增删一个用户，观察SCIM同步延迟（通常5～30分钟），确认CASB侧成员数变化。
3. 构造条件访问用例：合规设备+财务组+非工作时间，预期阻断；同一用户合规设备+工作时间，预期只读。
4. 检查SLO：IdP登出后，CASB会话是否在TTL内失效。

身份与访问治理集成不是一次性配置，而是持续运营：IdP组结构会变、设备合规策略会变、SaaS应用会新增。CASB侧应保留映射表版本、策略变更记录和同步日志，使每一次访问判定都可追溯、可解释。