无服务器架构中的十大安全风险

无服务器架构(作为服务或FaaS的功能)是应用程序在其上构建和部署后，可以根据云工作负载流自伸缩的架构。从开发的角度来看，无服务器架构主要关注核心功能，而忽略所有底层约束，如操作系统、运行时环境、存储等。

无服务器架构允许开发人员只关注业务逻辑，而不关注复杂的服务器基础结构。

无服务器的好处

• Zero administration —在serverless中，开发人员的工作是部署代码，而不提供计算实例、操作系统等。
• Auto-scaling — 正如前面提到的，可以根据云工作负载动态扩展无服务器应用程序。
• Pay-per-use —功能即服务(functional -as-a-service, FaaS)计算和管理在使用时收费的服务，而不是预先准备的容量。

很好，那么安全呢?

当您使用无服务器时，供应商就是无服务器的提供者(例如：的AWS lambda、谷歌云等)负责保护所有云组件(如数据中心、网络、服务器、操作系统及其配置)

然而，这只是减少了开发人员所承担的安全负担，而不是否定它。从应用程序的角度来看，应用程序开发人员仍然负责应用程序逻辑、代码、数据和应用程序层配置，使其成为共享的安全职责

在服务器端引入了新的攻击向量

新的工作动态带来了新的视角和新的漏洞。我在这里列举了其中的大部分:

增加的攻击面:由于无服务器的功能消耗来自多个事件源的数据，例如HTTP api、消息队列、云存储和物联网设备通信，攻击面引入了协议和复杂的消息结构，这是典型的web应用程序防火墙难以检查的。

攻击表面的复杂性:刚开始的时候，架构的攻击表面是相当新的，因此对于开发人员来说，适应和扩展可能会有一些麻烦;错误配置的可能性非常高。

总体系统复杂性:使用无服务器架构开发的应用程序很难可视化和监控，因为它不是典型的软件环境。因此，正确记录事件和函数对于及时排除故障和响应安全事件至关重要。

安全性测试不足:与标准应用程序相比，在基于无服务器架构的应用程序上进行安全性测试要复杂得多。这就是为什么自动化扫描工具还没有适应于扫描在无服务器架构上开发的应用程序。

无服务器架构中的十大关键风险

1、函数事件数据注入

2、破碎的身份验证

3、不安全的无服务器部署配置

4、超特权的函数权限和角色

5、功能监视和日志记录不足

6、不安全的第三方依赖

7、不安全的应用程序秘密存储

8、拒绝服务和耗尽财政资源

9、无服务器的函数执行流操作

10、错误的异常处理和冗长的错误消息

函数事件数据注入

难怪注入缺陷是OWASP前10名中最具破坏性的缺陷。当不受信任的输入被直接传递给解释器并执行或计算时，就会出现注入缺陷。

大多数无服务器架构提供了大量的事件源，可以触发无服务器函数的执行。

这丰富的事件源设置增加了潜在的攻击表面和介绍复杂性当试图保护serverless函数对事件数据注入,尤其是serverless架构不是那么容易理解web环境中开发人员知道哪个消息部分不应该被信任(例如GET / POST参数、HTTP头信息,等等)。

一些例子包括:

云存储事件(如AWS S3、Azure Blob存储、谷歌云存储)

NoSQL数据库事件(如AWS DynamoDB, Azure cosmos DB)

SQL数据库事件

流处理事件(例如AWS Kinesis)

代码更改和提交新的存储库代码

HTTP API调用

物联网设备遥测信号

消息队列的事件

SMS消息通知、推送通知、电子邮件等。

无服务器架构中最常见的注入缺陷类型有:

操作系统(OS)命令注入

函数运行时代码注入(例如Node)。js/JavaScript, Python, Java, c#， Golang)

SQL注入

NoSQL注入

Pub/Sub消息数据篡改(例如MQTT数据注入)

反序列化对象的攻击

XML外部实体(XXE)

服务器端请求伪造(SSRF)

破碎的身份验证

在类似于微服务的系统设计中构建的无服务器应用程序通常包含数百种不同的无服务器功能，它们有自己的用途。一些可能公开公共web api，而另一些可能充当不同功能或流程的代理。

必须应用健壮的身份验证方案，它为每个相关的功能、事件类型和触发器提供适当的访问控制和保护。

此类攻击的一个示例是“通过具有公共访问的S3 Bucket公开未经身份验证的入口点:”

不安全的无服务器部署配置

由于无服务器体系结构是新的，并且为任何特定的需求、任务和环境提供了不同的定制和配置设置，因此错误配置关键配置设置的可能性相当高，可能导致灾难性的数据损失。在设计无服务器架构时，使功能处于无状态是非常重要的，同时还要确保敏感数据不会暴露给任何未经授权的人员。还建议正确使用云强化方法和正确的ACL配置。

超特权的函数权限和角色

遵循“最少特权”的原则总是明智的。从技术上讲，这意味着应该只给无服务器函数必要的特权来执行预期的逻辑。向无服务器功能提供特权可能最终被滥用，以执行非预期的操作，比如“执行系统功能”。

功能监视和日志记录不足

从安全的角度来看，实时记录和监视与安全相关的事件是至关重要的，因为它有助于检测入侵者的行为并有效地控制局势。它还将有助于实时防止网络入侵。无服务器架构的一个关键方面是，“监视和日志记录”驻留在组织数据中心外围的云环境中。

的确，许多无服务器架构供应商提供了功能极其强大的日志记录工具。这些日志(它们的基本/开箱即用配置)并不总是适合于提供完整的安全事件审计跟踪。

为了通过适当的审计跟踪实现充分的实时安全事件监控，需要无服务器的开发人员和他们的DevOps团队将符合他们组织需求的日志逻辑结合起来，比如:

●收集来自不同serverless实时日志功能和云服务

●将这些日志远程安全信息和事件管理(SIEM)系统。

这通常要求您将日志存储在中间的云存储服务中。SANS六类关键日志信息文件建议收集以下日志报告:

身份验证和授权的报告

修改报告

网络活动报告

资源访问报告

恶意软件活动报告

关键错误和故障报告

不安全的第三方依赖

从技术上讲，无服务器函数应该是执行单个离散任务的一小段代码。有时，为了执行此任务，需要依赖第三方软件包、开放源码库，甚至通过API调用使用第三方远程web服务。在导入它们的代码之前，最好先看看第三方的依赖关系，因为它们可能很容易受到攻击，并且可能使无服务器的应用程序容易受到网络攻击。

不安全的应用程序秘密存储

随着应用程序在规模和复杂性上的增长，存储和维护应用程序秘密的需求非常重要，例如:

API密钥

数据库证书

加密密钥

敏感的配置设置

最常见的错误之一是在配置文件、数据库配置等中以纯文本形式存储应用程序秘密。任何具有“读”权限的用户都可以访问这些秘密。

加密或不存储包含API私钥、密码、环境变量等的纯文本秘密总是明智的。环境变量是跨无服务器函数执行持久化数据的有效方法，在某些情况下，这些变量可能会将数据泄漏给未经授权的实体。

拒绝服务和耗尽财政资源

拒绝服务攻击也可以在无服务器的体系结构中作为目标，因为它们是基于按功能付费的模型。对无服务器应用程序的拒绝服务攻击可能导致财务和资源不可用灾难。为了避免这种财务灾难和服务器停机，应用程序开发人员在云中部署无服务器应用程序时必须正确定义执行限制。需要限制的资源有:

每次执行内存分配

每次执行的磁盘容量

每次执行的进程和线程数

每个函数的最大执行时间

最大有效载荷大小

每次并发执行限制

并发执行的限制则

有些攻击向量:

财务资源耗尽:攻击者可能会将没有服务器的应用程序“过度执行”很长一段时间，从而导致每月账单增加，并给目标组织造成财务损失。

函数执行流操作

操作应用程序的流将帮助攻击者绕过访问控制、提升用户权限甚至导致拒绝服务攻击，从而颠覆应用程序逻辑。

应用程序流操作在无服务器架构中并不少见。多类型软件是一个常见的问题。然而，由于无服务器应用程序是唯一的，它们通常遵循包含离散功能的微服务设计范式，以特定的顺序耦合在一起，以实现整个应用程序的逻辑。

由于函数是链接的，调用特定函数可能会调用另一个函数。调用顺序对于实现所需的逻辑至关重要。

错误的异常处理和冗长的错误消息

总之，与标准应用程序相比，执行逐行调试的无服务器应用程序更加复杂和有限。然而，上述因素迫使开发人员采用冗长的错误消息，从而启用调试环境变量，并最终在将代码移到生产环境时忘记清理代码。

冗长的错误消息，如堆栈跟踪或语法错误，暴露了无服务器函数的内部逻辑，揭示了潜在的弱点、缺陷或敏感数据。