TEL: 180-210-69380

Figma服务器端沙箱:简介

Nov,13,2023 << Return list


软件存在缺陷是不争的事实,安全威胁是不可避免的,并且几乎不可能防止所有漏洞。为了为用户提供服务,功能丰富的应用程序依赖于其基础设施内存在潜在风险的软件,例如图像处理、解析、压缩缩略图库。第三方经常使用内存不安全的语言来实现该软件,而该软件很少被设计来处理恶意的用户输入。像ImageTragick这样的严重漏洞在野外出现也就不足为奇了。

幸运的是,应用程序级沙箱(也称为工作负载隔离)可以在这些场景中提供强大的防御。过去,沙盒技术通常价格昂贵、不成熟且操作上变化无常,因此只有资源最丰富的安全组织才能大规模有效地利用它们。这是团队严重未充分利用沙盒的原因之一,尽管它作为分层纵深防御架构的支柱非常有效。沙盒仍然是一个活跃的研究领域,安全团队最近投资开发更可用、更稳定的解决方案。如今,虚拟化、包含和隔离处理的方法有很多。

有如此多的选项,选择正确的沙箱技术组合并为隔离工作负载做出明智的权衡可能会令人畏惧。我们必须做出同样的权衡,并尝试在 Figma 上部署不同的原语。在本文中,我们将解释什么是沙箱以及您可能想要使用它的原因。我们将简要介绍几种常见的沙箱原语,包括它们的内部工作原理和安全属性,并提供一份轻量级调查问卷,帮助您在考虑不同的沙箱方法时考虑如何评估权衡。

服务器端沙箱,解释

现代 SaaS 应用程序中的一些关键功能会带来安全团队必须减轻的固有风险。例如,在Figma,我们为产品团队创建工具来共同集思广益、创建和交付设计。在客户端,我们依靠各种浏览器沙箱技术(例如WebAssembly)以及提供安全且响应灵敏的编辑体验的技术。但在服务器端,我们依靠自己的库来提供用户所需的设计功能,例如 RenderServer,这是用 C++ 编写的 Figma 编辑器的精简服务器端版本。我们还使用第三方库来处理用户生成的图形数据,其中可能包含恶意输入。

在Figma,我们不想直接在我们的基础设施内部针对潜在的恶意输入运行作业。如果我们这样做,一个严重的错误可能会允许该作业访问其他作业的用户数据,向其他生产服务发出请求,或者横向移动并危及其他生产组件。一种解决方案是用内存安全语言重写所有不安全代码,并利用程序分析技术来证明其正确性和安全属性。但与许多其他复杂的现实系统一样,这需要从其他关键安全项目中抽出资源,进而带来许多其他权衡。(即便如此,我们仍然存在无意中引入安全漏洞的风险,因为没有任何方法是万无一失的。我们都是人类。)

完全依靠预防安全漏洞是昂贵且不现实的。相反,我们还使用沙箱来减轻这些错误出现时的影响。虽然我们可以使用许多不同的策略,但沙箱还允许我们最大限度地减少并更好地管理受损工作负载可以访问的外部接口和资源,从而有效地遏制对受影响系统的攻击。


虚拟机

Firecracker XenKVM都是常用虚拟机管理程序技术的示例。

VM 是一个来宾虚拟计算机,其行为类似于具有自己的内存、磁盘和 CPU 的真实物理计算机。虚拟机已经存在了几十年,如今,有各种类型的虚拟化和不同的实施方法。通常,来宾VM和主机系统之间的接口是管理程序,其管理来宾VM的执行并为来宾提供访问主机硬件资源的接口。在 Figma,我们主要通过使用AWS Lambdas将Firecracker作为隔离原语。


常见的沙盒方法

Seccomp是安全计算模式的缩写,可以限制程序允许进行的系统调用。

构建安全沙箱的方法有多种:虚拟机 (VM)、容器和安全计算模式 ( seccomp )。这些解决方案很快就会变得复杂,因此在更详细地探讨虚拟机容器和 seccomp的优缺点之前,我们先在这里分享一个简短的概述。


集装箱

nsjail是一个命令行工具,它利用 Linux 命名空间、功能、文件系统限制、cgroup、资源限制和 seccomp 来实现隔离。

与虚拟机不同,容器隔离发生在操作系统 (OS) 层,通常依赖于主机的操作系统功能进行隔离,例如命名空间、cgroup 或特权删除等内核功能。根据实现的不同,与虚拟机相比,容器往往需要更少的性能开销,因为它们可以直接调用主机操作系统的系统调用(syscall),而不必在完整的虚拟机管理程序的上下文中执行。在 Figma,在适合容器级安全隔离的用例中,我们主要使用nsjail

塞康普

seccomp 驱动的方法认识到许多可隔离的程序正在执行纯计算,因此根本不需要动态访问任何磁盘或网络。这种方法显着减少了实现所需隔离级别所需的功能集和相关性能开销。为了在 Figma 安全地做到这一点,我们使用内核内置的 seccomp 功能来限制允许程序进行的系统调用,从而生成底层程序允许的操作的允许列表。理想情况下,这会限制程序简单地分配内存、产生输出并退出。我们直接使用libseccomp将其构建到 Figma 代码库的部分中。

寻找最合适的

沙盒并非没有挑战。上面概述的选项都在安全性、开发和维护的简易性以及运行时性能之间进行了不同的权衡。例如,虽然 seccomp 驱动的方法通常提供强大的安全属性和最小的运行时开销,但它可能涉及大量的初始开发成本。与此同时,容器驱动的方法具有更多潜在的安全隐患,并且通常会降低运行时性能,但可能更容易交付。

下面我们概述了一些问题,这些问题将帮助您将团队的需求与正确的沙盒解决方案相匹配。一旦您了解了不同的高级权衡,我们对虚拟机容器以及 seccomp 的深入讨论将帮助您更好地理解更具体的工程考虑因素。

环境
  • 您的工作负载是否需要在特定操作系统或其他专门环境中运行?

安全性和性能
  • 您需要多强大的沙箱?

  • 您愿意接受多少攻击面?

  • 您需要什么级别的隔离?(例如,您是否需要隔离每项工作?或者仅在用户之间?或者仅在用户的项目、团队或组织之间?)

  • 您是否愿意接受隔离级别和性能以及开发复杂性之间的一些权衡?

  • 您可以容忍多少延迟?

  • 您的计算和其他基础设施成本预算是多少?

开发成本和摩擦
  • 您是否拥有修改工作负载代码以制定定制沙箱解决方案的专业知识,或者您是否需要现成的即插即用解决方案?介于这两个极端之间的东西可以接受吗?

  • 您愿意承担多少开发成本和复杂性?

维护和运营费用
  • 您的工作负载代码是否正在积极开发中?

  • 您愿意运行自己的服务吗?您有资源吗?

  • 另一个团队是否会拥有这个系统,他们是否愿意承担运营开销和额外的复杂性?

  • 工程师需要什么级别的调试访问权限?

隔离危险或不安全的工作负载是安全团队的关键工具。在Figma,沙盒使我们能够为用户构建有价值的新产品功能,同时最大限度地降低基础设施的风险和每个新功能的成本。要更深入地了解沙盒原语,请查看我们的虚拟机容器指南以及 seccomp,其中我们探索了几种常见的沙盒技术并分享了我们在生产中使用它们的经验。