如何应对不支持SSO的产品？
当组织不得不采购不支持单点登录（SSO）的SaaS产品时，应该采取什么措施？首先需要明确：将SSO功能限制在企业版方案的供应商是对客户的不负责任。无怪乎美国政府的"安全设计承诺"要求供应商在基础产品版本中就提供SSO功能。
但本文并非抱怨SSO收费的供应商——而是更注重实用主义。让我们从SSO在现代防御架构中的作用开始，然后探讨如何在没有这种集中式机制的情况下实施类似的安全措施。
受控入口点作为防御策略
首先，为什么SSO对安全和IT专业人员如此重要？它充当了瓶颈点。防御者历来使用瓶颈点来控制攻击者。历史案例包括：
- 温泉关战役（公元前480年）：希腊小部队在狭窄的温泉关通道抵御了规模大得多的波斯军队，地理位置使希腊人能够造成重大损失
- 斯特灵桥战役（1297年）：苏格兰人在狭窄的斯特灵桥附近设防，使他们在英军小规模过桥时能够以优势兵力压倒对方
- 莫加顿战役（1315年）：瑞士联邦军队在湖泊和山脉之间的狭窄通道伏击奥地利军队，有利地形使瑞士人取得了决定性胜利
正如历史上的防御者利用瓶颈点集中资源和控制攻击者流量一样，SSO通过集中身份验证，为访问多个系统创建了单一、受控的入口点。
SSO作为控制漏斗
通过SSO提供商集中身份验证可以实现安全措施的有效执行、账户管理、访问监控和攻击面减少：
执行安全措施：
- 启用多因素认证（MFA）以防止类似2024年5月影响Snowflake客户的攻击
- 控制可用的认证因素，强制执行密码复杂性要求
- 配置会话持续时间，管理凭据重置
管理用户账户：
- 通过SSO提供的SCIM功能自动化用户配置和取消配置
- 根据人员需求自动分配角色
- 获取产品使用情况的可见性以满足许可要求
监控访问：
- 使用SSO提供商的异常检测标记可疑登录尝试（如来自意外位置或恶意基础设施的登录）
- 将日志定向到集中位置（SIEM）进行分析、关联和取证
减少攻击面：
- 暴露由SSO供应商提供的单一强化登录机制
- 减少对单个SaaS供应商安全实践的依赖
这些好处不适用于没有基于标准SSO集成的SaaS产品，使防御者处于显著劣势。
补偿缺乏SSO的安全措施
为了定义基线SSO期望，组织应该：
- 正式要求所有SaaS采购都必须支持SSO（和SCIM）
- 向内部采购者和供应商传达该政策
- 教育采购者在购买和续订产品时协商SSO功能
- 创建在SSO不可用时的例外批准流程
当批准采购不支持SSO的SaaS产品例外时，组织必须通过分配责任给IT、网络安全团队或业务部门来补偿安全措施的缺失。需要明确以下期望：
用户账户设置：
- 可接受的2FA因素、密码要求、会话持续时间期望等
配置和取消配置：
- 创建具有适当权限的用户账户的步骤
- 在员工离职或不再需要产品时禁用账户的流程
安全监控：
- 检测攻击和配置弱点
- 审查应用内安全日志或将事件定向到组织的SIEM
集中监督：
- 确定是否遵循了保护产品的适当安全责任
组织应该认识到，在采购不支持SSO的SaaS产品时，他们承担了这些负担。如果无法承诺这些安全措施，他们就接受了SaaS产品可能被入侵的更高风险，或者应该寻找提供SSO的替代产品。
总结
SaaS产品中缺乏SSO会带来重大的安全挑战。组织可以通过强制执行SSO政策、协商SSO功能以及实施补偿性安全措施来应对这些挑战。通过采取这些步骤，即使没有集中式访问控制，也能保持强大的安全性，确保SaaS环境保持安全可控。