无 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 日更新更多精彩内容 请关注我的个人公众号 公众号（办公 AI 智能小助手）公众号二维码

办公AI智能小助手