技术文章

无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日更新