就在30多年前，虚拟化只针对拥有大型机和大型小型机的用户，安全问题只存在于物理机；20年前，VMware发布了第一款产品，网络边界安全仍处于起步阶段，依赖于防火墙；12年前，AWS推出，网络安全成为一个问题；5年前，随着Docker容器成为主流，主机安全成为焦点。今天，随着无服务器安全的发展，应用层安全终于在计算层和网络层受到挑战。应用程序级安全在计算和网络层受到挑战由于应用程序、计算和网络安全都经过审计，管理层和客户都可以通过SOC类型等报告更加了解安全问题。随着客户端透明度的提高，安全专业人员是确保部署资产更有效地安全的关键，并且根据所使用的部署类型，此配置文件的大小可能会增加。这就是了解不同类型（即容器、无服务器计算和虚拟机）之间安全细微差别的原因。下面，我们将比较它们的安全差异。无服务器安全性首先，让我们谈谈无服务器安全性，因为无服务器应用程序通常是执行单个功能的纯代码，因此称为功能即服务。除了遵循安全编码最佳实践（例如仅返回处理请求绝对必要的数据，以及让应用程序使用仅具有允许其完成其工作所需的访问权限的服务帐户）之外，发现的任何漏洞都将导致暴露的数据远远超出了无服务器应用程序的范围。另一个主要关注领域是应用程序中包含的任何第三方库，以提供增强的功能并节省开发团队的开发时间。第三方库的示例包括用于验证电话号码或邮政编码的库，以及连接到外部PostgreSQL数据库所需的客户端库，例如JDBC驱动程序。如果不使用自动更新和定期扫描构建工件的扫描工具，组织内使用的所有第3方库以及查看所有各种漏洞咨询列表的过程都是一项巨大的手动工作。容器的安全性从本质上讲，无服务器应用程序通常在后台的容器中运行，因此容器将承载与无服务器相同的所有问题，以及容器为开发人员提供的额外功能的新问题。容器特定的安全问题可以归结为两个不同的领域：基于部署的容器来源的可信度，以及容器对主机操作系统的访问级别。在任何主机（无论是Windows还是Linux）上运行容器时，它们不应以root或管理员权限运行。使用名称空间和卷等功能而不是原始磁盘访问允许这些容器守护程序在一个或多个容器之间共享存储以获取持久数据，而无需容器本身具有升级的权限。甚至还有一些项目，例如Google的gVisor，更进一步隐藏了除容器需要运行的确切系统调用之外的所有内容。容器的一个更大问题是构建它们的层的可信度。有多种方法可以解决这个问题。它们包括指向您已经测试并确定的特定版本的指针，而不是依赖于最新的标签。您还可以扩展对无服务器应用程序中的第三方库执行的任何扫描的范围，以扫描整个容器中的已知漏洞。此扫描可以在源注册表中提前执行，也可以在构建过程中执行，因为它们可以用作构建的基础。虚拟机安全虚拟机是另一个需要解决的问题集合。改进upis的一种方法是将运行的服务限制为绝对需要的服务。例如，默认的HTTP服务器可以很好地查看日志，但是当应用程序运行在Java中时，可以查看产品是否可用以及哪些产品可以通过SSH连接并集中整理日志；另一种选择是在发布补丁后尽快应用补丁，一些每月发布一次，包括微软的“补丁星期二”，而其他更关键的补丁在修复可用的当天发布（这些被称为out-of带补丁）。与容器和无服务器不同，在完整虚拟机上需要应用任何给定补丁的几率要高得多，因为需要和安装的包要多得多。通过了解开发团队部署应用程序的计算环境类型以及最有可能应用的所有安全性的最佳实践来进行总结。理想情况下，您的安全投资中的每个应用程序都可以并且将会被评估，并且希望您将使用最合适和简化的部署选项。通过将更多应用程序转移到容器中，并在适当的情况下转移到无服务器中，这将使类似生产的安全实践能够在开发周期的早期实施，并最终提高企业的整体安全性。
