前言
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安全扫描器和测试服务。每时每刻新产品都会涌现，但其中许多仍然是未经证实的。一定要做好研究，明智投资。
声明：本文来自小佑科技，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
