如何保护您的 SaaS 沙箱

在创建沙盒时，人们的心态往往是沙盒被认为是一个玩耍、测试的地方，不会对生产或运营系统产生影响。因此，人们并不积极地认为他们需要担心它的安全性。这种心态不仅是错误的，而且是极其危险的。

对于软件开发人员来说，他们的沙盒版本类似于儿童游乐场——在不破坏生产流程的情况下构建和测试的地方。同时，在网络安全领域，“沙盒”一词用于描述用于运行可疑代码和其他元素的虚拟环境或机器。

许多组织为其 SaaS 应用程序使用沙盒——在不中断生产 SaaS 应用程序的情况下测试更改，甚至连接新应用程序（很像软件开发人员的沙盒）。这种常见的做法通常会导致错误的安全感，进而导致对其安全影响缺乏思考。本文将引导您了解什么是 SaaS 沙盒、它为何易受攻击以及如何保护它。

了解如何获得对 SaaS 沙盒和应用程序堆栈的可见性和控制权。

网络安全和 SaaS 沙盒基础知识

网络安全沙箱允许将受保护资产与未知代码分离，同时仍然允许程序员和应用程序所有者查看代码执行后会发生什么。创建SaaS沙盒时使用相同的安全概念——它复制 SaaS 的主要实例，包括其数据。这允许使用 SaaS 应用程序，而不会影响或破坏生产中的运营 SaaS。

开发人员可以使用沙箱来测试 API、安装插件、连接其他应用程序等等——而不必担心它会影响组织的实际用户。管理员可以更改配置、测试 SaaS 功能、更改角色等。这使用户能够更好地了解对 SaaS 的更改将如何进行，然后再将其实施到可操作的关键 SaaS 实例上。这也为创建指南、培训员工、构建工作流程等提供了时间。

总而言之，使用沙盒是所有软件和 SaaS 使用的一个很好的概念。但就像 SaaS 世界中的所有伟大事物一样，问题在于其中潜伏着重大的安全风险。

沙盒安全 现实世界的风险与现实

一家大型私立医院在构建演示站点（即沙盒）以测试新的预约设置系统时，无意中泄露了 50,000 名患者的数据。他们使用了医疗中心的真实数据库，暴露了患者的数据。

沙盒通常是使用真实数据创建的，有时甚至是生产环境的完整克隆及其自定义。其他时候，沙盒直接连接到生产数据库。如果攻击者由于安全性松懈而设法侵入沙盒，他们将获得对大量信息的访问权限。（这种信息泄露可能会带来问题，尤其是如果您是欧盟公司或因 GDPR 而处理欧盟数据。如果您在美国或为美国公司处理医疗信息，则可能违反 HIPPA。）

了解 SSPM 如何帮助您自动化 SaaS 沙箱的安全性。

即使是所有公司都推荐使用合成数据的组织，仍然可能面临攻击风险。攻击者可以使用沙盒进行侦察，以深入了解组织如何设置其安全功能及其可能的弱点。由于沙盒在一定程度上反映了操作系统的配置方式，因此攻击者可以利用这些知识来渗透生产系统。

如何保护您的 SaaS 沙箱

沙盒不安全问题的解决方案相当简单——一步一步地保护沙盒，就好像它是一个生产系统一样。

步骤 1.管理和控制对沙盒的访问，并限制用户对沙盒的访问。例如，并非每个有权访问生产的用户也应该有权访问沙盒。控制哪些用户可以创建和访问沙盒是保持 SaaS 环境安全的第一步。

步骤 2.将操作系统中配置的相同安全设置实施到沙盒版本；从要求 MFA 到实施 SSO 和 IDP。许多 SaaS 应用程序具有为特定 SaaS 应用程序量身定制的附加安全功能，应在沙盒中进行镜像。例如，Salesforce 具有独特的安全功能，例如：内容嗅探保护、默认数据敏感度级别、通过自定义域进行身份验证等。

步骤 3.删除生产数据并将其替换为合成（即组成）数据。沙盒通常用于测试配置、流程、流程（例如 APEX）等方面的更改。它们不需要真实数据来测试更改——任何具有相同格式的数据就足够了。因此，请避免复制生产数据并改用 Data Mask。

第 4 步：让您的沙盒与生产环境中的安全改进保持一致。通常，沙盒既不会每天刷新也不会同步，因此很容易受到生产中最小化的威胁的影响。为了降低风险并确保您的沙盒发挥其作用，应该每天同步一个沙盒。

自动化您的 SaaS 安全

安全团队还可以实施和利用 SSPM（SaaS 安全状态管理）解决方案，以自动化他们的 SaaS 安全流程并解决上述挑战，监控和防止威胁渗透到 SaaS 沙箱。

SSPM（如 Adaptive Shield）发挥作用，使安全团队能够识别、分析沙盒中和整个 SaaS 应用程序堆栈中的错误配置并确定其优先级，并提供对可访问核心应用程序、设备的第三方应用程序的可见性-to-SaaS 用户状态管理等。