容器、无服务器、虚拟机：安全性差在哪?

就在30多年前，虚拟化仅适用于拥有大型机和大型小型计算机的用户，而安全问题仅仅存在于物理计算机中;20年前，VMware发布了其第一款产品，网络边界安全性仍处于起步阶段，依赖于防火墙;12年前，AWS推出，网络安全成为一个问题;5年前，由于Docker容器成为主流，主机安全成为焦点。今天，随着无服务器安全性的增长，应用程序级安全性终于受到计算和网络层的挑战。

[[241449]]

应用程序级安全性受到计算和网络层的挑战

随着应用程序，计算和网络安全都被审计，通过SOC类型等报告，管理层和客户端都可以更加了解安全问题。随着客户端透明度的提高，安全专业人员是确保部署资产的关键生产更加具有坚实的安全性，并且根据正在使用的部署类型，此配置文件的大小可能会增加。这就是理解不同类型即容器，无服务器计算和虚拟机之间的安全细微差别的原因。下面，我们将比较他们的安全差异。

无服务器安全性

首先，我们先讨论无服务器安全性问题，因为无服务器应用程序通常是纯粹执行单个函数的代码，因此被称为函数即服务。除了遵循安全编码最佳实践，例如仅返回处理请求绝对需要的数据，并让应用程序使用仅具有允许其完成工作所需的访问权限的服务帐户，任何发现的漏洞都将导致数据被泄露的东西远远超出了无服务器应用程序的范围。

另一个主要关注领域是应用程序中包含的任何第三方库，以提供增强功能，并节省开发团队的开发时间。第三方库的示例包括用于验证电话号码或邮政编码的库，以及连接到外部PostgreSQL数据库所需的JDBC驱动程序等客户端库。如果不使用自动更新并定期扫描构建的工件的扫描工具，那么在组织内使用的所有第三方库以及观察所有各种漏洞公告列表的过程中，这是一项巨大的手动工作。

容器的安全性

从本质上讲，无服务器应用程序通常在后台运行在容器中，因此容器将承载与无服务器相同的所有问题，以及容器为开发人员提供的附加功能的新问题。特定于容器的安全问题可以简化为两个不同的区域：基于部署的容器的源的可信度，以及容器对主机操作系统的访问级别。

在任何主机(无论是Windows还是Linux)上运行容器时，不应使用root或管理员权限运行容器。使用命名空间和卷等功能而不是原始磁盘访问允许这些容器守护程序在一个或多个容器之间共享存储以获取持久数据，而不需要容器本身具有升级的权限。甚至还有一些项目，例如谷歌的gVisor，它们更进一步，隐藏了除容器需要运行的确切系统调用之外的所有项目。

对容器的更大关注是构建容器的层的可信度。有多种方法可以解决这个问题。它们包括指向您已经测试并确定的特定版本，而不是依赖于最新的标记。您还可以扩展针对无服务器应用程序中的第三方库所进行的任何扫描范围，以便扫描整个容器以查找已知漏洞。此扫描可以在源注册表中提前执行，也可以在构建过程中执行，因为可以将它们用作构建的基础。

虚拟机安全

虚拟机是另一个需要解决的问题的集合。一种改进upis的方法是将运行服务限制为绝对需要的服务。例如，默认的HTTP服务器很适合查看日志，但是当应用程序在Java中运行时，可以看到是否需要可用的产品，哪些产品可以通过SSH连接并集中整合日志;另一种选择是在发布后尽快应用补丁，一些补丁每月发布，包括微软的“ 补丁星期二 ”，而其他更关键的补丁在有可用修复的那天发布(这些被称为带外补丁)。与容器和无服务器不同，在完整虚拟机上需要应用任何给定补丁的几率要高得多，因为需要和安装的软件包要多得多。

总结

通过了解开发团队正在部署应用程序的计算环境类型，以及最有可能应用所有安全性的最佳实践。理想情况下，安全投资中的每个应用程序都可以并且将被评估，也希望你能使用最合适和简化的部署选项。通过将更多应用程序移动到容器，并在适当的时候无服务器，它将使得类似生产的安全实践能够在开发周期的早期实施，并最终提高企业的整体安全性。