无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环境保持安全可控。
2024年9月16日更新 Lenny Zeltser