前言  

Serverless架构从根本上改变了安全性。安全性有可能因此会变得更好，有可能会更糟，有可能在两者之间。在这个对本地服务器依赖越来越低的世界里，为了保证数据和应用程序的安全，各种规模的初创公司和企业都需要了解Serverless架构的不同之处和重要性，以及应该采取哪些措施来保护Serverless中的资产和业务。

在本文中，我们将提供Serverless架构的一些背景知识，并从专业的角度分析其对安全性的影响，以及应对这种变化的较佳方法。

什么是Serverless 架构？

Serverless的全称是Serverless Computing，中文名为无服务器计算，有时候也被认为是函数即服务（Function-as-a-Service，缩写为 FaaS）。但实际上，整个Serverless架构是Faas和Baas的结合。因此，无服务器并不是说不需要服务器，而是不需要在本地部署服务器，转向以云计算为基础的应用开发概念。这意味着，企业不提供和管理自己的服务器，而是购买以下云计算服务:

软件即服务，即SaaS。SaaS是通过互联网向终端用户按需提供集中托管和管理的软件(例如Gmail、Slack、Jira、SAP、Salesforce)。这些通常是云原生应用程序。

基础设施即服务，即IaaS (Infrastructure as a Service，简称IaaS)。IaaS可以提供网络、数据存储和计算机等必须由最终用户管理的资源。

平台即服务，即PaaS，建立在IaaS之上。PaaS允许用户在托管平台上部署和运行应用程序。

函数即服务(Function as a Service，简称FaaS)，FaaS是一种特殊类型的PaaS，允许用户在托管平台(例如AWS Lambda)上开发、管理和运行应用程序功能。

企业从所有这些“服务”产品中得到了什么? 云原生极强的拓展能力，包括人工智能和机器学习、API管理、应用程序集成、AR/VR、区块链、业务应用程序、计算能力、内容交付、数据分析、数据库、云原生开发、迁移、网络、机器人技术、存储，以及无数其他领域。

领先的云服务提供商

亚马逊网络服务(Amazon Web Services，简称AWS)提供了一套庞大的工具，这些工具具有强大的、不断改进的功能。就市场份额而言，AWS是明显的佼佼者。

谷歌云平台，或GCP，提供了一个不断增长的服务列表，专长于安全性和专业技术。

微软Azure经常受到企业的青睐，因为它能够与现有的组织系统和流程集成，也是较快的云解决方案之一。

为什么转向Serverless计算?

Serverless计算带来了明显的好处: 应用部署更方便、更快捷；资源分配灵活、可伸缩；可访问性提升、延迟缩减；服务滚动更新。这些有利条件能够帮助改进协同方式并加快云原生应用开发。开发者不必再担心服务器级别的安全性，并且可以有效地将管理和保护服务器所需的所有基础设施外包出去。在Serverless的架构下，所有的服务都是“随用随付”的。如果有需要，基础设施触手可及，但如果不用，也不需要为之付费。

考虑到这些有利因素，各行业、各规模的企业都很快接受了Serverless。RightScale公司 2019年发布“云状况”报告指出，84%的企业拥有多云战略，半数企业的公共云支出达到每年120万美元。Gartner在2018年4月的报告《Serverless计算的I&O领导者指南》中预测，到2020年，全球将有超过20%的企业将部署Serverless计算技术。

何时应用Serverless能够促进安全?

在O’Reilly公司2017年大会上，安全专家兼开源安全平台Snyk的联合创始人盖伊•波德贾尼(Guy Podjarny)曾发表过题为“Serverless安全:还有什么需要保护?”的演讲，提出了一些独到的见解。我们将在接下来分析他的观点和建议。

波德贾尼说，Serverless提供的安全理念值得庆祝，用户再也不用担心以下情形:

1.对易受攻击的操作系统(OS)的依赖。当一台服务器上感染病毒后，就会传递所有其他服务器。这些严重的、普遍的漏洞让企业感到恐慌。使用Serverless，就不再需要给服务器打“补丁”了。

2.拒绝服务(DoS)。当来自客户的大量请求导致服务器瘫痪时，就会发生这种拒绝服务的情况。DoS发生后，服务器便无法再为其他客户提供服务。由于Serverless可自动伸缩，可以灵活地满足容量需求，可以避免出现这种问题。但Serverless平台其实已经实施了一些限制(例如，AWS Lambda的默认限制是每个区支持1000个并发函数)。费用也会有变化:额外的流量，就得额外付费。由于Serverless并不是没有入口，服务仍然容易受到DDoS数据流的攻击。

3.长期存在的受攻击服务器。Serverless的函数是无状态执行，即使是被入侵的服务器，也不会存在很长时间。这意味着攻击者必须在更短的时间内多次重复攻击，增加了被发现的风险，降低了成功的机会。不过，Serverless并非完全无状态。容器通常用于相同的功能，而攻击者可以修改函数上的文件，所以下一个调用该函数的用户将得到攻击者入侵的代码。(在此方面，FaaS比PaaS更好，因为PaaS的服务器寿命更长。)

 

何时应用Serverless 会效果一般?

Serverless既没有消除某些安全问题，也没有加剧安全问题。这就是波德贾尼所说的“中性”。

也就是说，“中性”在某些情况下可能意味着“更糟”。由于Serverless已经拒绝攻击者在某些领域的访问，攻击者则会将注意力转移到仍然存在的漏洞上。这包括一些理论上的“中性”的领域。

权限和授权

Serverless实际上在这方面提供了改进的功能。开发者现在可以在更小的代码单元(函数)上设置权限模型。但现在还没有弄清楚如何充分利用上述特点。此外，在部署多个函数时，简单的做法是默认给该堆栈中任何一个函数所允许的较大权限级别。因此，一般来说，函数的权限都不太安全。

现在有几个问题需要思考: 谁能够调用函数?谁可以访问代码和环境变量?当有一系列的函数，其中一个被破坏，会发生什么?被破坏的函数能否访问敏感数据或继续破坏另一个函数?

Serverless安全性的提示和技巧

让策略和权限变得细粒度化，并保持这种方式。单独考虑功能，为每个功能制定单独的策略。不过，这很难大规模实现。(自动化流程的工具正在开发中，下面会详细介绍。)

使用“最小权限”原则，给予每个函数最小的权限。但随着功能的增加，任何策略的自然状态都是不断扩展的。

保护静态数据

如今，数据是任何安全漏洞的圣杯。虽然Serverless服务器是无状态的，但应用程序不是。FaaS应用程序仍然存储数据。这些数据可能会被窃取或篡改。

波德贾尼认为，Serverless倾向于否定这种“中性”。在Serverless应用的情况下，不能将状态(例如，临时令牌、密码、会话id)存储在服务器上，这意味着状态其存储在服务器外部。

建议数据加密、减小粒度和加强控制:

加密所有敏感的持久数据；

加密所有敏感的离线数据；

最小化可以访问每个数据存储的函数；

为每个函数使用单独的数据库凭据，并控制这些凭据的作用；(例如，只允许访问特定的表或数据段)

监视什么功能正在访问什么数据(例如，使用AWS X-Ray等分析工具)。

代码中的漏洞

Serverless不保护应用层。因此，诸如SQL注入、跨站脚本、远程命令执行、伪造跨站请求等问题仍然是威胁。由于Serverless省略了其他容易入侵的步骤，反而得到了攻击者更多的关注。

Serverless安全性的提示和技巧

波德贾尼推荐了一些标准的实践:

首先关注OWASP前10种攻击类型；

使用测试来分析代码，包括动态和静态应用程序安全测试；

标准化输入和输出处理库要经过安全审计；

尽可能严格地使用API网关模型/模式；

独立保护每个功能，在其周围设置边界，这是重要的策略。

易受攻击的应用程序依赖

为了最小化代码，Serverless函数通常利用应用程序依赖关系和第三方代码库。随着时间的推移，这些依赖关系被压缩和遗忘，变得陈旧和脆弱。此时，更多的代码=更多的漏洞。

Serverless安全性的提示和技巧

记住:平台可以管理操作系统依赖关系，但开发者仍然需要负责管理应用程序依赖关系。目前，越来越多的工具可以帮助识别和修复漏洞。

何时应用Serverless会对安全不利？

需要明确的是，Serverless并没有产生任何新的安全问题。但这意味着我们需要频繁地做某些活动。这些活动本身就具有风险。在应用Serverless时，我们需要担心以下这些问题：

第三方服务和传输中的数据安全

在Serverless的情况下，我们越来越倾向于使用第三方服务。我们需要第三方服务的原因很多。但这些服务也很脆弱。所以应该慎重考虑:

正在分享的是什么数据?第三方服务对数据的保护情况如何?

传输中的数据是否安全或者加密?是否在VPC中?数据是否使用HTTPS协议?

你在和谁对话?能验证对方使用的HTTPS证书吗?

响应是否可信任？如果服务被攻击了，是否可以利用它来损害您的利益?

如何存储API密钥?尽管代码的无状态性使得人们倾向于在GitHub和其他存储库中存储凭据，但最好使用KMS和环境变量。

Serverless安全性的提示和技巧

考虑使用安全监测和性能监视工具。由于这是一个新兴的领域，新的工具正在出现，找到适合自己的工具。

同时也要担心本地服务，不安全的功能可能导致你的系统崩溃。

攻击面——又名“函数问题”

Serverless允许更大的粒度，这反过来意味着更大的灵活性。基本上，您现在可以通过无数种方式将构建模块组合在一起。虽然这种灵活性是积极的，但它也增加了风险，产生各种意想不到的后果。

Serverless安全性的提示和技巧

专注于建立边界和监控性能:

把每一个功能都看作是需要保护的边界。当查找安全性问题时，先查找函数的问题，然后再查找有关应用程序的信息；

独立测试每个功能是否存在安全缺陷；

不要依赖于限制对函数的访问，因为访问控制会随着时间的推移而变化；

搭建库模型，使用共享输入/输出处理库，从而可以更安全地处理输入；

将功能限制在实际需要的范围内。尽量确定每个函数允许的最小值，减少到“最低特权”；

监控单个函数和整个流程。虽然这很理想，但是鉴于工具短缺，需要了解数据如何在系统中运行并快速检测异常活动。

安全监视

Serverless环境使得部署函数比以往更容易、更简单。就像权限一样，函数很容易添加，但很难删除。由于函数的策略自然会扩展，并且成本不再驱动删除，所以最终会得到大量具有过度开放策略的函数——其中许多函数很少使用。虽然现在不用再考虑服务器安全，但是要更关注函数安全。

波德贾尼指出，这是他最担心的问题。没有运营成本并不等于没有拥有成本。基本上，函数越多，风险就越大。

Serverless安全性的提示和技巧

建议有条理地盘点和管理函数:

部署之前要考虑，这个函数真的是必须得吗？

为不同的功能组分别配置网络和帐户，把函数放在对象存储中(例如，定时任务)，这样您就知道什么是一次性的，什么不是一次性的。并给他们设置不同的权限；

跟踪已经部署的应用及其使用情况，不要仅仅依赖平台的能力；

优先最小化权限；

减少权限混乱；

监控已知的漏洞。

Serverless安全性的未来

如果还没有使用Serverless，可以先去尝试使用。除了高伸缩性、高效率和低成本这些优点外，Serverless还极大地消除或减少了几个主要的安全问题。

Serverless只需要调整安全优先级。过去容易的攻击现在变得更难了。但这些攻击者并没有放弃。所以，如果已经没有服务器了:

需要考虑如何控制扩大的中性风险。这包括在策略和边界中更细粒度、更少许可、加密某些数据、分析函数的数据访问，以及使用测试和工具来查找和修复漏洞。

需要关注已经变得更糟的安全风险。这包括注意如何使用第三方服务、执行函数的独立安全测试、限制功能、考虑库模型、监视函数和流、减少权限以及减少和跟踪函数的部署。

研究适合自己需求的Serverless安全扫描器和测试服务。每时每刻新产品都会涌现，但其中许多仍然是未经证实的。一定要做好研究，明智投资。