SaaS 安全是什么以及如何管理风险

SaaS 安全是一个常用术语，但它究竟意味着什么？在谷歌上快速搜索 “SaaS 安全”，会查询出各类安全解决方案与平台，其中包括以下类别的产品：云访问安全代理（CASB）、SaaS 安全态势管理（SSPM）、云安全态势管理（CSPM）以及其他一些类别。

当你负责保障公司内部 SaaS 应用的使用安全时，往往会陷入 “不知从何入手、该聚焦哪些方向” 的困境。希望本文能帮助你理清思路，明确重点关注领域，并在资源有限的情况下，以可持续的方式规避 SaaS 安全风险。


什么是 SaaS 安全？

SaaS 安全的核心目标是：保障企业及其员工所使用的 SaaS 应用中存储的敏感数据，以及与这些 SaaS 应用集成过程中的敏感数据安全。

谈及 SaaS 安全所带来的风险管控，实际上主要涉及两个核心层面：

1. 供应链风险管控：你是否信任所使用 SaaS 应用的供应商？

2. SaaS 账户安全与访问控制：你是否在以安全的方式使用这些 SaaS 应用？


我们应重点聚焦哪些方向？

在 SaaS 安全领域，人们对 “供应链安全” 的讨论远多于 “账户安全”。这很可能是因为供应链攻击的 “影响范围更广”—— 此类攻击更容易被检测到，也更常被媒体曝光。

这类攻击的影响极大，可能从一个被众多企业用于业务运营的平台（例如 Salesforce）开始。一旦该 SaaS 平台遭遇攻击，所有使用该平台的企业的数据都会面临数据泄露风险。而这类风险往往是企业无法直接预防的。

与之相反，SaaS 账户安全则处于企业的可控范围内，企业完全有能力通过措施强化账户安全。


聚焦账户安全的同时，不要忽视供应链风险

作为安全负责人，你需要关注 SaaS 安全的这两个层面。在供应链层面，需调查你是否信任 SaaS 供应商，以及他们为保护你的数据所采取的安全措施是否可靠。虽然 SaaS 供应商最适合管理其自身应用的安全风险，但你仍需对供应商进行尽职调查，确保其措施足以满足企业的风险容忍度。

在账户安全层面，这是你能够直接掌控的领域，也是 SaaS 安全工作的重要发力点。你可以实施严格的访问控制，落实基础安全措施，例如要求员工使用多因素认证（MFA）、设置复杂且唯一的密码 —— 或者更优的方式，采用社交账号登录访问 SaaS 应用。

接下来，我们将拆解企业应如何构建 SaaS 安全体系。需要注意的是，SaaS 安全体系可能与企业的云安全体系紧密相关，但对于 “原生 SaaS 企业” 或 “正从集中式基础设施向云与 SaaS 应用迁移的混合模式企业” 而言，那么它们是需要特别关注的两个方面。


如何在企业内部构建 SaaS 安全体系？

英国国家网络安全中心提出了一套 “责任共担模型”，清晰地划分了 SaaS 供应商与 “客户（即你的企业）” 的安全责任 —— 前者负责保障其应用本身及客户存入应用的敏感数据安全，后者则需承担相应的次要责任。

需要再次强调的是：该模型明确表示，作为客户，你需要对 SaaS 账户层面的安全负责，同时必须确保 SaaS 应用的配置符合安全要求。然而，与大型云平台相比，SaaS 应用的配置选项通常非常基础。因此，一套成功的 SaaS 安全体系必须同时解决这两个问题：

1. 不能将所有精力都投入到供应链的风险评估与尽职调查中，而忽视账户安全；
2. 同样，也不能只关注 “确保所有账户都启用了 MFA”，却对供应商留下的 “安全后门” 视而不见。

对于企业使用的绝大多数 SaaS 应用，你的核心责任包括：

（1）账户安全：确保已启用 MFA；在条件允许的情况下，启用单点登录（SSO）。

（2）密码管理：若无法启用 MFA 或 SSO，需确保员工使用复杂密码。

（3）账户生命周期管理：及时移除不再需要的外部账户（以及离职员工的账户）。

大多数企业会将供应链层面的问题（“我们是否应该使用这款应用？”）视为 SaaS 安全的核心，甚至是首要解决的问题。但事实上，账户安全才是 SaaS 安全问题的重点。

例如，一名开发人员或技术支持工程师若使用弱密码，或未启用 MFA，很容易成为钓鱼攻击的目标 —— 而这可能引发一系列连锁攻击。

许多安全从业者常犯的一个错误是：仅将精力集中在 “保障企业已知的核心应用安全” 上。但实际上，攻击者完全可能先攻破 “非核心 SaaS 应用”，再通过该应用横向渗透到核心系统中。

幸运的是，与 “复杂的 SaaS 应用供应链风险审计” 相比，账户安全问题的解决方式更为直接。


如何管控供应链风险？

通常情况下，企业通过 “安全尽职调查” 或 “应用风险评估” 来回答 “我们是否应该使用这款应用” 这一问题。对于大多数企业而言，这些流程是软件采购环节的标准步骤。

然而，如今企业的软件采购已不再完全由安全部门掌控 —— 员工常会在未经监管的情况下，自主选用所需工具。

因此，你需要做的是：在员工开始自主使用某款应用后，尽快发现其中存在的重大安全风险。

归根结底，你对上述问题的关注程度，取决于两个核心因素：

1. 应用中存储数据的风险等级（例如，是否包含敏感客户数据）；
2. 该应用被授予的、对企业其他基础设施的访问权限级别。

因此，构建 SaaS 供应链风险管理体系的第一步，是了解该应用所存储数据的敏感度，以及它被授予的访问权限级别 —— 这将帮助你优先开展风险评估工作。


SaaS 应用与供应商风险评估要点

风险评估中与安全相关的部分，通常可拆解为 “产品风险” 与 “供应商风险” 两大维度：

1. 产品风险：产品是否具备保护数据所需的必要安全功能（如 MFA、SSO 等）？产品安全性是否经过技术验证（例如，第三方渗透测试）？

2. 供应商风险：供应商是否拥有保障产品安全的资源？供应商是否组建了安全团队，并实施了恰当的安全流程？这些安全流程是否经过独立审计（例如，SOC2 认证）？供应商是否在高风险地区运营？供应商是否有多次安全事件的历史记录？

3. 供应商的分包处理商：绝大多数 SaaS 应用都构建在其他平台之上，这些平台的供应商也属于你的供应链环节。即便你没有直接使用某款工具或应用，一旦其遭遇攻击，你的企业仍可能受到影响。

实际上，你可能无法对此类供应商进行深度调查，但当媒体报道某一安全漏洞时，你需要确认自己的主供应商是否在使用受该漏洞影响的 SaaS 应用。


如何快速评估员工自主采用的 SaaS 应用的安全风险？

对于员工自主采用的 SaaS 平台（即你和 IT 团队均未参与采购、也未正式引入企业的应用），你往往需要在应用被启用后，再补做常规的软件采购流程，包括：

1. 法律协议（条款与条件、主服务协议等）；2. 成本核算（许可费用等）；3. 可用性保障（服务级别协议 / SLA 等）。

通常，只有当员工需要升级到付费账户或更高许可等级，或是考虑需要签订长期协议时，这些问题才会被提上日程。


如何管理员工自主采用的 SaaS 应用的账户安全？

 要保障这些账户的安全，第一步也是最关键的一步，是掌握员工自主采用的所有应用。目前市场上有一些工具可帮助实现这一目标。我们虽有自身立场，但仍认为：从员工访问 SaaS 应用的 “源头”—— 浏览器中检测 SaaS 使用情况，是最合理的方式。这种方式不仅能提供精准的可见性，还能大幅减少冗余的误报。

已实现 “应用可见性” 后，下一步该怎么做？

在发现所有员工自主注册的 SaaS 账户后，你需要确保落实以下措施：

1. 为所有账户启用 MFA；

2. 鼓励员工使用复杂密码（理想情况下，通过密码管理器生成和管理）；

3. 在条件允许且切实可行的情况下，启用 SSO；

4. 审查授予第三方的访问权限。

需要注意的是，当你发现数百个此前未知的 SaaS 应用时，上述工作的规模化推进难度较大。市面上大多数 SaaS 安全解决方案，都能提供员工登录 SaaS 应用的方式、是否启用 MFA 及是否使用复杂密码等关键信息。因此，在选择解决方案时，这类 “可直接使用的功能” 是你需要重点关注的 —— 它们能帮助你切实提升 SaaS 安全水平。

员工自主采用的应用数量不断增加，导致员工在更多应用上创建账户。若缺乏安全部门的指导来落实严格的身份与访问控制，你将需要一套能提供 “全面可见性” 的 SaaS 安全解决方案，以便采取行动。

管理 SaaS 风险的关键在于：利用一款 SaaS 安全平台，不仅实现 “应用可见性”，还能获取与 SaaS 应用及供应商相关的安全信息，帮助你快速完成尽职调查，从而跟上员工自主采用应用的节奏。