本博客链接：https://security.blog.csdn.net/article/details/128705527
一、概念
Serverless的全称是Serverless computing无服务器运算，随着云原生技术的不断发展，应用的部署模式逐渐趋向于“业务逻辑实现与基础设施分离”的设计原则，而Serverless作为一种新的云计算模式，较好地履行了上述设计原则。
Serverless可在不考虑服务器的情况下构建并运行应用程序和服务，它使开发者避免了基础设施管理，如集群配置、漏洞修补、系统维护等。Serverless并非字面理解的不需要服务器，只是服务器均交由第三方管理。
Serverless目前依然处在探索和发展阶段。
二、实现方式
Serverless通常可分为两种实现方式，即BaaS（Backend as a Service，后端即服务）和FaaS（Functions as a Service，函数即服务），其中FaaS是Serverless的主要实现方式。简而言之，FaaS即开发者编写一段代码，并定义何时以及如何调用该函数，随后该函数在云厂商提供的服务端运行，在此过程中开发者只需编写并维护一段功能代码。
此外，FaaS本质上是一种事件驱动并由消息触发的服务，事件类型可能是一个HTTP请求，也可能是一次上传或保存操作，事件源与函数的关系如图所示。
FaaS的典型代表为AWS Lambda，为便于理解，下述为一个简单的Lambda Python处理函数：
import json
def lambda_handler(event, context):
return {
'statusCode': 200,
'body': json.dumps('Hello from Lambda!')
}
可以看出，以上代码导入了JSON Python库并定义了一个lambda_handler函数，该函数需接收两个参数，分别为event和context，其中event参数包含此函数收到的事件源信息，参数类型通常是Python的dict类型，也可以是list、str、int、float等类型，而context参数包含此函数相关的运行时上下文信息。
上图大致展示了传统的服务端应用部署和FaaS应用部署，当应用程序部署在物理机、虚拟机、容器中时，它实际上是一个应用进程，并且由许多不同的函数构成，这些函数之间有着相互关联的操作，一般需要长时间在操作系统中运行；而FaaS通过抽离虚拟机实例、操作系统和应用程序进程改变了传统的部署模式，使开发者只需关注单个函数操作，剩余基础设施管理均由第三方托管平台提供，当有事件触发时函数被执行，开发者为使用的资源付费。
三、Serverless的一些防护机制
1、Serverless资产业务梳理
由于云厂商通常缺乏一套自动化机制对现有Serverless应用中包含的函数、数据及可用API进行分类、追踪、评估等操作，因此开发者在不断完善应用的同时，可能疏于了对应用数据及API的管理，从而导致攻击者利用敏感数据、不安全的API发起攻击。为了避免这种情况，开发者需要在应用的设计阶段对资产业务进行详细梳理。其中包括但不限于以下几个部分：
a. 确认应用中函数间的逻辑关系。
b. 确认应用的数据类型及数据的敏感性。
c. 评估Serverless数据的价值。
d. 评估可访问数据API的安全。
有了一个较为全面的应用全景图，便可在一定程度上降低应用被攻击的风险。
2、定期清理非必要的Serverless实例
由于Serverless应用通常遵循微服务的设计模式，因此一套完整的工作流应由许多函数组成，而开发者可能部署了非常多的Serverless应用，在这些应用中，必定存在一些长时间不被调用的实例。为了避免被攻击者利用，应当定期对Serverless应用进行检测，清理非必要的实例，从而降低安全隐患。
3、限制函数策略
开发者首先应当限制函数策略，给予其适当的访问权限，删除过于宽松的权限，这样即便攻击者拿到了访问凭证也无法对所有资源进行访问。
4、Serverless被滥用的防护措施
a. 通过IDS等安全设备监测木马在本机的出口流量，诸如/pixel、/utm.gif、ga.js等URL的流量应进行重点监测。
b. 确认自己的资产中是否有云厂商提供的Serverless函数业务，如果没有可以通过浏览器禁用相关云厂商的子域名。
c. 采取断网措施，从根源上直接禁止所有网络访问。
5、其他防护机制
其他防护机制主要是云厂商提供的一些防护机制，例如存储最佳实践、资源监控、账单告警机制等，需要采购相应的服务即可使用。
除此外，还有诸如函数隔离、底层资源隔离技术来对Serverless的应用进行安全防护；以及通过采集业务数据进行分析、判断来检测业务系统异常等防护机制。