无服务器 (Serverless) 架构基础安全指南

无服务器（Serverless）架构使组织无需内部服务器即可大规模构建和部署软件。像函数即服务（FaaS）模型这样的微服务盛行，推动了无服务器架构的普及。无服务器架构能够节省巨大的成本，并为大规模可伸缩性提供灵活性。

本文将概述确保无服务器架构的安全性应考虑的关键领域。虽然最适合的无服务器生态系统的解决方案是独一无二的，但以下内容将为建立无服务器架构安全方法提供坚实的基础。 

简而言之，软件环境的攻击面包括未经授权用户可以输入或提取数据的所有点。了解和监控这些点是有效实现无服务器安全的关键。

无服务器系统由数十个、数百个甚至数千个组件组成。每一个新的工具、服务或平台集成到无服务器系统中，都为恶意和未经授权的用户提供了新的切入点。每次扩展和修整无服务器架构时，攻击面都会发生变化。

此外，由于无服务器架构的入口点众多且拓扑复杂，无服务器攻击面是多层次、多维度的。无服务器架构的攻击面具有很高的复杂性和波动性，因此人工映射和监控这些攻击面几乎不可能。

对于无服务器系统的自动化监控和发现，使你可以领先威胁一步，找到系统的安全薄弱点。你只能保护你能看到的东西。除非监控工具可以随着系统的扩展而增加其可见性范围，否则系统的大部分可见性将很快消失。

在无服务器架构中，很有可能会采用自动连续部署。这意味着攻击面上的新弱点也在不断地自动生成。如果监控和发现能力无法跟上，无服务器架构中新的部分将很容易受到攻击。

幸运的是，有可用的平台可以实时映射和监控无服务器架构。许多平台功能扩展了安全性，能指出未经授权的用户可以恶意操纵数据的位置。其中的某些平台在设计时特别考虑了无服务器安全性。 

对于无服务器架构，数据注入是最常见安全风险。自第一个无服务器系统上线以来，注入漏洞已成为无服务器安全讨论的普遍特征。

无服务器架构的每个组件和函数都需要来自大量来源的输入。这些输入可能是云存储事件、来自API网关的命令、消息队列事件、数据库更改、来自IoT遥测的信号、甚至是电子邮件。这个输入列表实际上是无限的，仅受限于架构的规模和内容。

可以说，规模越大，函数输入数据的来源就越丰富。

这些确实是已看到的问题。每一种不同类型的来源均带有独特的消息格式和编码方案。其中的任何一种都可能包含不受信任或受攻击者控制的输入。预测和消除这些恶意注入是一个艰巨的挑战。

在这种情况下，“投资”不一定指金融投资。时间和精力更为重要，尽管已发现投入时间和精力不足，会带来额外的代价。不要拖延时间和精力的投入。重大安全漏洞造成的代价影响，远远超过保护自己免受此类侵害的相对较低的投入。

许多云供应商提供了基本形式的日志记录功能或函数，常见示例包括AWS CloudWatch或Azure函数。尽管这些函数为无服务器环境启用了非常基本的日志记录，但是代价可能很高，并且一旦无服务器架构扩展到一定规模或一定程度的复杂性时，它们就可能无法满足你的要求。

开箱即用的解决方案并不总是适合需求。尽管它们具有基本函数，但它们可能缺乏在应用程序层进行全面安全事件审计的能力。无服务器架构的规模和形态的设计越独特，这种解决方案的不适合性便越正确。有许多专家构建的平台和工具可用来弥补这些监控和日志记录的不足。

正如本文所说，函数监控和日志记录需要（但值得）投入一些时间和精力。在无服务器环境中使用函数日志记录要克服的主要障碍是，监控和日志记录存在于组织数据中心范围之外。

通过协调工程师，无服务器开发人员和DevOps团队来创建无服务器架构独有的日志记录逻辑，该逻辑可以从各种云函数和服务中收集日志，并将其推送到远程SIEM（安全信息和事件管理）系统上。

在无服务器环境中一些已知的特别重要的日志报告类型包括身份验证和授权、严重错误和故障、更改、恶意软件活动、网络活动和资源访问。

无论使用哪种无服务器架构模型，其中的许多日志报告都是关键报告。但是，在复杂且不断变化的无服务器环境中，监控和可见性可能很棘手。创建可在单个存储库中隔离，提取和整理这些日志报告的逻辑，对于实时监控整个架构至关重要。

通过日志逻辑收集的日志需要存储在某个地方。这是中间云存储服务发挥作用的地方。通过使用单个外部系统来整理整个无服务器生态系统中的日志记录信息，对安全事件进行实时监控。

在无服务器架构的拓扑中跨所有无服务器函数跟踪和遏制攻击者和恶意/未经授权的输入，而无需考虑层。

如果没有对函数和用户进行尽职调查和适当的审查，则无服务器架构中可能存在致命的弱点组合。

首先是健壮的身份验证。无服务器通常意味着面向微服务的架构设计。微服务架构可以包含数百个单独的函数。除了充当其他进程的代理外，许多无服务器函数还会使用公共Web API暴露在外。这就是为什么应用健壮的身份验证方案至关重要的原因。

随着无服务器系统的发展，身份验证方案失败或效率低下，可能会为未经授权的用户创建无限数量的访问点。这本身是危险的，但是如果函数权限过高，则可能会造成灾难性的后果。

在具有数十甚至数百个组件的无服务器环境中，管理函数权限和角色感觉就像一场艰苦的战斗。工程师犯下的最常见的安全错误之一是试图偷工减料并应用“包罗万象”的权限模型。尽管这样可以节省时间，但它使无服务器环境中的所有内容都极易受到攻击。

如果由于未遵守尽职调查而同时存在以上两个缺陷，则无服务器系统很容易被恶意外部用户访问。身份验证失败会打开大门，函数权限过高会将无服务器系统交给进入到系统的恶意外部用户。在设计，构建和部署过程中通过透彻周到的考虑，可以避免这两种情况。

当然，还有其他考虑。例如，切记要停用过时的函数和云资源。这不仅有助于节约成本，而且旧的和未使用的组件会增加不必要的架构攻击面的维度。定期自动整理无服务器环境，并删除未使用的角色，身份和依赖项。

避免重用执行环境也很重要。对于云供应商而言，在两次调用之间保留执行环境可能很诱人。它使平台在处理新的调用时效率更高。但是，当执行环境被保留下来时，有价值的敏感数据可能会被保留下来。确保别以牺牲安全性为代价来实现效率。

无服务器环境是独特的，因此实现无服务器安全性的方法也应是独特的。

这始终是最重要的考虑因素。无论是部署配置，权限模型还是日志记录工具，开箱即用的解决方案都只能提供通用的保护。独特的无服务器环境需要一种独特的无服务器安全方法。