从一开始，像AWS这样的公共云环境代表它们的用户减轻了安全负担。基本的共享责任模型仍然有效 – 明确表示云提供商(即供应商)可以保护云本身的硬件和软件，而客户则负责其云中资产的安全性。当然，任何新型云计算的引入都会对模型的细节产生影响，使安全和运营团队难以理解他们在这些不断变化的环境中的新职责。

工作负载，特别是云计算工作负载，是为拥有、借用和开源代码提供动力的应用程序工具。有许多不同类型的工作负载，随着数据中心的不断发展，多年来出现了新的选择。这些工作负载带来的好处通常伴随着新的安全和后勤挑战。正如我们所看到的从裸机到虚拟机(VM)的演变，然后是微服务和容器的引入，组织需要主动解决这些动态环境，以便在它们受到威胁之前有效保护这些动态环境。

这是我们在新的云原生环境出现时亲眼看到的问题。每个都为处理它们的企业带来了新的安全挑战和复杂性。 这就是为什么您需要密切监控云中新架构的安全性，如无服务器，以及开发人员，操作人员和安全团队可以保持警惕的三种方式 – 无论您的组织如何与云提供商分担安全责任。

无服务器示例

无服务器或功能即服务(FaaS)是构建，架构和开发云原生应用程序的最新方式。开发团队将应用程序代码作为一组功能提供，而云提供程序负责运行这些功能。这允许开发人员专注于编码，而提供商负责配置，扩展和计费。

过去一年中无服务器计算的采用呈指数级增长。云计算本地计算基金会(CNCF)是一个包括许多世界上最大的公共云和企业软件公司以及100多家创新初创公司的组织，最近对550多名社区成员进行了调查，以解决当前的云原生技术问题。该调查发现，受访者41%目前正在使用无服务器技术，另有28%计划在未来12-18个月内使用。

这种新的无服务器计算的迅速普及引发了新的问题，即谁拥有使用无服务器框架(客户或云提供商)部署的应用程序的安全性?正如前面提到的，在传统的共享安全模型绘制云和一个什么样的安全保障之间明确的界限在云中，在无服务器模式转变一些责任推回给云供应商管理，操作系统，让负责该应用程序的客户在他们的云环境中运行。

对于DevOps和安全团队来说，这似乎是个好消息，因为他们可以更专注于构建产品和应用程序而不是安全性，知道它正在被处理。但是，使用无服务器架构意味着组织有新的盲点，仅仅因为他们不再能够访问架构的操作系统，从而阻止他们在这些工作负载中添加防火墙，基于主机的入侵防护或工作负载保护工具。

由于无服务器是一种相对较新的架构，组织和云提供商仍在学习如何处理和保护它，而攻击者仍在学习如何利用它。这就是为什么保护无服务器基础架构超出共享责任模型概述的重要性。

合作准备整体工作负载安全性

随着无服务器等新计算方法的出现，适用于传统工作负载的共享责任模型变得不那么清晰，安全专业人员需要做好准备来保护这些新的工作负载。遵循以下指导可以帮助安全专家准备他们的服务，以安全地在无服务器云中运行。

1.不要相信谁拥有云环境中的安全性。现代数据中心本质上是复杂的，这导致了固有的盲点，导致数据中心的某些元素缺乏明确的所有权。相信谁拥有安全性可能会在漏洞出现时让公司陷入困境。在漏洞出现之前定义谁拥有安全性的规则将防止成为受害者并指责手指。

2.确保在复杂的现代数据中心内完全了解所有类型的工作负载。 缺乏对所有类型的不同工作负载的完全可见性使得保护整个云架构成为难以解决的问题。为了避免数据中心各个层面的漏洞，客户团队 – 开发人员，安全和运营团队 – 必须假设他们的云提供商只负责安全措施的最低要求。

3.与您的云提供商合作，从头开始主动为架构构建安全性。安全性是云提供商与其客户之间的共同任务。发现攻击或漏洞后，不要追溯修补或实施安全措施，而是从一开始就与云提供商合作以防止攻击。如果存在攻击从高级别利用云提供程序，启动影响整个堆栈的攻击，这一点尤为重要。

即使无服务器仍处于相对初期阶段，它仍然存在。随着新旧工作负载的出现和融合，在出现不可预测的漏洞之前，了解角色和职责并从粒度级别添加安全控制非常重要。如果没有确保所有类型的体系结构(VM，容器和/或无服务器)的安全性，现代数据中心将无法有效运行。传统的共享责任模型正在不断发展，组织需要通过了解其重新定义的云安全责任来保持同步，否则它们将不可避免地落后。