在三十多年前，虚拟化仅适用于拥有大型机和众多小型计算机的用户，而安全问题仅仅是物理上的。 二十年前，VMware发布了其第一款产品，网络边界安全性仍处于起步阶段，依赖于防火墙。 十二年前，AWS推出，网络安全成为一个问题。 五年前，由于Docker，容器成为主流，主机安全成为焦点。 今天，随着无服务器安全性的增长，应用程序级安全性终于受到已经存在多年的计算和网络层全面审查。
随着应用程序，计算和网络安全都被审计，通过SOC type 2等报告，管理层和客户端都可以更加了解安全问题。随着客户端透明度的提高，安全专业人员是确保部署资产和使生产具有坚实安全性的关键。 根据正在使用的部署类型，相应的配置规模大小可能会急剧增加。
以上就是理解不同类型的新兴部署技术（即容器，无服务器计算和虚拟机）之间的安全细微差别的原因。 下面，我们对比一下他们的安全方面。
首先，让我们解决无服务器安全问题，因为无服务器应用程序通常是纯粹执行单个函数的代码——因此叫做function-as-a-service。 你实际部署平台可能对无服务器应用程序中发生的最常见安全问题无动于衷。
除了遵循安全编码最佳实践，例如仅返回处理请求绝对需要的数据并让应用程序使用仅具有允许其执行其工作所需的访问权限的服务帐户，发现的任何漏洞都将导致数据被泄露， 这远远超出了无服务器应用程序的范围——这可能导致公关噩梦。
另一个主要关注领域是应用程序中包含的任何第三方库，这些第三方库主要是为了提供增强功能，并节省开发团队的开发时间。 比如用于验证电话号码或邮政编码的库，以及连接到外部PostgreSQL数据库所需的JDBC驱动程序等客户端库。 如果不使用自动更新并定期扫描构建的工件的扫描工具，那么在组织内针对所有第三方库的监控所有各种漏洞公告列表的过程，将是一项巨大的手动工作。
实际上，由于无服务器应用程序通常在后台运行在容器中，因此容器将承载与无服务器相同的所有问题，以及容器为开发人员提供的附加功能的新问题。
针对容器的特定安全问题可以简化为两个不同的区域：您基于部署的容器源的可信度，以及容器对主机操作系统的访问级别。
在任何主机（无论是Windows还是Linux）上运行容器时，不应使用root或管理员权限运行容器。 使用命名空间和卷等功能而不是原始磁盘访问，允许这些容器守护程序在一个或多个容器之间共享存储以获取持久数据，而不需要容器本身具有升级的权限。 甚至还有一些项目，例如谷歌的gVisor，它们更进一步，隐藏了除容器需要运行的确切系统调用之外的所有项目。
对容器的更大关注是构建容器的层的可信度。 有多种方法可以解决这个问题。 它们包括指向您已经测试并确定的特定版本，而不是依赖于最新的tag。 您还可以扩展针对无服务器应用程序中的第三方库所进行的任何扫描范围，以便扫描整个容器以查找已知漏洞。 此扫描可以在容器源中提前执行，也可以在构建过程中执行，因为您将它们用作构建的基础。
虚拟机是另一个需要解决的大问题。 有不少关于如何保护操作系统的书籍和最佳实践指南。 甚至美国政府也有一个团体在NIST网站上发布一些清单。 最近推出的操作系统提供了开箱即用的合理安全配置文件，但它们总需要进行改进。
一种改进upis的方法是将运行服务限制为绝对需要的服务。 例如，默认的HTTP服务器很适合查看日志，但是当您的应用程序在Java中运行时，有不少可用的产品，哪些产品可以通过SSH连接并集中整合日志？
另一种选择是在发布后尽快应用补丁。 一些补丁每月发布。 还有微软的“Patch Tuesday”，而其他更关键的补丁在有可用修复的那天发布（这些被称为out-of-band patch）。 与容器和无服务器不同，在完整虚拟机上需要应用任何指定补丁的几率要高得多，因为需要和安装的软件包要多得多。
只有了解您和您的开发团队正在部署应用程序的计算环境类型，您才可能应用所有安全性最佳实践。 理想情况下，您的每个应用程序都可以被评估，并且我们鼓励您使用最合适和简化的部署选项。 通过将更多应用程序迁移到容器，并在适当的时候使用无服务器，它将使得类似生产的安全实践能够在开发周期的早期实施，并最终提高您的整体安全性。
原文链接：https://thenewstack.io/security-differences-containers-vs-serverless-vs-virtual-machines/
306
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
