自2018年以来，无服务器应用取得了巨大的发展，提供了对更多数据的访问，这些数据涉及组织如何利用无服务器应用程序、其无服务器开发方法，以及与无服务器应用程序的安全性和隐私性相关的最常见的经常性错误。
此外，在过去的一年中，新的缓解方法已经出现并日益标准化，例如无服务器安全平台，以及云计算提供商提供的新功能，这有助于改善无服务器安全态势。
2019年2月，云计算安全联盟(CSA)与PureSec公司合作发布了一个名为“无服务器应用程序的“12个最严重的风险”的新指南，其中包括来自几十位无服务器行业思想领袖的建议和反馈，并且是对迄今为止在无服务器架构上构建应用程序的潜在风险进行分类的最全面的努力。该报告是针对处理无服务器应用程序的安全和开发受众编写的，并且远远超出了指出风险的范围。它提供解决措施、最佳实践以及传统应用程序与无服务器应用程序之间的比较。
以下列出了文档中描述的12个最严重的风险，每个风险都有一个简短描述：
1. 功能事件数据注入
无服务器功能可以使用来自每种类型事件源的输入(AWS公司提供47个不同的事件源，这些事件源可以触发一个AWS lambda函数)，并且此类事件输入可能包含不同的消息格式(取决于事件类型及其源)。这些事件消息的各个部分可能包含攻击者控制的或其他危险的输入。这组丰富的事件源增加了潜在的攻击面，并在试图保护无服务器功能不受事件数据注入的影响时引入了复杂性。这一点尤其正确，因为在Web环境中，无服务器架构几乎没有被理解为开发人员知道哪些消息部分不应该被信任(例如，GET/POST参数、HTTP头等)。
2.身份验证中断
由于无服务器架构促进了面向微服务的系统设计，因此为这种架构构建的应用程序可能包含数十个(甚至数百个)不同的无服务器功能，每个功能都有特定的用途。这些功能交织在一起并协调以形成整个系统逻辑。一些无服务器功能可能会公开公共Web API，而其他功能可能会充当进程或其他功能之间的“内部粘合剂”。另外，一些功能可能消耗不同源类型的事件，例如云存储事件、NoSQL数据库事件、物联网设备遥测信号，甚至是短信通知。对所有相关功能、事件类型和触发器应用提供访问控制和保护的可靠身份验证方案是一项复杂的工作，如果不小心执行，很容易出错。
3.不安全的无服务器部署配置
通用云服务(尤其是无服务器架构)提供了许多自定义选项和配置设置，以适应特定需求、任务或周围环境。某些配置参数对应用程序的整体安全性状态具有重要意义，应予以关注，无服务器架构供应商提供的设置可能不适合开发人员的需要。配置错误的身份验证/授权是影响使用基于云计算存储的应用程序的普遍弱点。由于无服务器架构的推荐最佳实践设计之一是使功能无状态，因此为无服务器架构构建的许多应用程序依赖于云计算存储基础设施在执行之间存储和保存数据。
4.超权限的功能权限和角色
无服务器功能应该只有执行其预期逻辑所必需的特权，这一原则被称为“最小特权”。由于无服务器功能通常遵循微服务概念，许多无服务器应用程序包含几十个、数百个甚至数千个功能。其是结果，管理功能权限和角色很快成为一项繁琐的任务。在这种情况下，组织可能被迫对所有繁琐使用单一的权限模型或安全角色，本质上是授予对所有其他系统组件的完全访问权限。当所有功能共享同一组超权限时，单个功能中的漏洞最终会升级为系统范围的安全灾难。
5. 功能监控和日志记录不足
无服务器架构的一个关键方面是它们位于组织数据中心外围的云计算环境中。因此，“内部部署”或基于主机的安全控制作为可行的保护解决方案变得无关紧要。反过来，这意味着为安全事件监视和日志记录而开发的任何进程，工具和过程都将过时。虽然许多无服务器架构供应商提供了极其强大的日志记录功能，但这些日志基本/开箱即用的配置并不总是适合提供完整的安全事件审计跟踪。为了通过适当的审计跟踪实现足够的实时安全事件监视，无服务器开发人员及其DevOps团队需要将适合其组织需求的日志逻辑拼接在一起。例如，他们必须从不同的无服务器功能和云计算服务收集实时日志。将这些日志推送到远程安全信息和事件管理(SIEM)系统。这通常需要组织首先将日志存储在中间云存储服务中。
6.不安全的第三方依赖
通常，无服务器功能应该是执行单个离散任务的一小段代码。功能通常依赖于第三方软件包、开源库，甚至通过API调用消耗第三方远程Web服务来执行任务。但是，从易受攻击的第三方依赖项导入代码时，即使最安全的无服务器功能也会变得容易受到攻击。
7.不安全的应用程序保密存储
与应用程序机密存储相关的最常见的错误之一是将这些机密信息简单地存储在作为软件项目一部分的纯文本配置文件中。在这种情况下，任何对项目具有“读取”权限的用户都可以访问这些秘密。如果项目存储在公共存储库中，其情况会变得更糟。另一个常见的错误是将这些秘密以纯文本形式存储为环境变量。虽然环境变量是在无服务器功能执行中保持数据的有用方法，但在某些情况下，此类环境变量可能会泄漏并落入错误的人手中。
8.拒绝服务和财务资源耗尽
虽然无服务器架构带来了自动可扩展性和高可用性的承诺，但它们也存在需要注意的限制和问题。如果应用程序不是为正确处理并发执行而设计的，则攻击者最终可能会使应用程序达到并发限制，并拒绝来自系统的其他用户或云计算账户的服务。
9.无服务器业务逻辑操作
无服务器的业务逻辑操作可以帮助攻击者破坏应用程序逻辑。使用此技术，攻击者可以绕过访问控制，提升用户权限或发起DoS攻击。业务逻辑操作是许多类型的软件和无服务器架构中的常见问题。但是，无服务器应用程序是独一无二的，因为它们通常遵循微服务设计范例，并包含许多离散功能。这些功能以特定顺序链接在一起，从而实现整个应用程序逻辑。
在存在多个功能的系统中，并且每个功能可以调用另一个功能，调用的顺序对于实现期望的逻辑可能是至关重要的。此外，设计可能假设某些功能仅在特定情况下调用，并且仅由授权的调用者调用。
无服务器应用程序中的业务逻辑操作也可能发生在单个功能中，其中攻击者可能在执行功能期间利用不良设计或注入恶意代码，例如，通过利用从不受信任的来源或受损的云计算资源加载数据的功能。
多功能调用过程可能成为攻击者目标的另一个相关场景是基于无服务器的状态。其示例包括AWS Step Functions、Azure Logic Apps、Azure Durable Functions或IBM Cloud Functions序列提供的示例。
10.异常处理不当和详细错误消息
与标准应用程序的调试功能相比，基于无服务器的应用程序的逐行调试选项受到限制(并且更复杂)。当无服务器功能利用本地调试代码不可用的基于云计算的服务时，这种情况尤其明显。因此，开发人员将经常采用详细的错误消息，启用调试环境变量，并最终忘记在将代码移动到生产环境时清理代码。
11.遗留/未使用的功能和云资源
与其他类型的现代软件应用程序类似，随着时间的推移，一些无服务器功能和相关的云计算资源可能会过时并且应该退役。应定期去除过时的应用程序组件，以减少不必要的成本，并减少可避免的攻击面。过时的无服务器应用程序组件可能包括：
•不推荐使用的无服务器功能版本
•不再相关的无服务器功能
•未使用的云计算资源(例如存储桶、数据库、消息队列等)
•不必要的无服务器事件源触发器
•未使用的用户、角色或身份
•未使用的软件依赖性
12.交叉执行数据持久性
无服务器平台为应用程序开发人员提供本地磁盘存储、环境变量和内存，以便以与任何现代软件堆栈类似的方式执行计算任务。
为了使无服务器平台能够高效地处理新的调用并避免冷启动，云计算提供商可能会将执行环境(例如容器)重新用于后续的功能调用。
在无服务器执行环境被重用于后续调用(其可能属于不同的最终用户或会话场景)的情况下，可能会留下敏感数据，并且可能会泄露。
开发人员应始终将无服务器功能的执行环境视为短暂的和无状态的环境，并且不应假设有关的可用性和完整性，最重要的是在调用之间处理本地存储的数据。
京公网安备 11010502049343号