无服务器架构允许组织在不运行内部服务器的情况下大规模构建和部署软件。微服务等功能即服务(FaaS)模型的广泛采用也证明了无服务器架构的流行。无服务器架构不仅节省了大量成本，而且其可扩展性为组织提供了更大的业务增长灵活性。以下概述了组织应考虑保护无服务器架构的关键领域。虽然适合组织生态系统的解决方案是独一无二的，但以下内容将为组织采用无服务器提供坚实的基础。不断变化的攻击面简而言之，软件环境的攻击面包括未经授权的用户可以输入或提取数据的所有点。了解和监控这些要点是有效提高无服务器安全性的关键。无服务器系统由数十个、数百个甚至数千个组件组成，为恶意攻击者和未经授权的用户开辟了新的切入点，所有这些人都在将每一个新工具、服务添加到生态系统或平台中。每次扩展和修改架构时，其攻击面都会发生变化。此外，由于Serverless架构的入口点众多，拓扑结构复杂，因此Serverless的攻击面是多层次、多维度的。因此，其攻击面非常复杂且多变，几乎不可能进行手动映射和监控。无服务器架构的自动映射和监控自动监控和发现系统可以使组织更好地抵御威胁。但是一个组织的安全人员只能保护它看到的东西，除非它的监控工具可以随着系统的扩展增加它的可见性范围，否则大部分无服务器架构都会受到损害。在组织的无服务器架构中，很有可能会采用自动化持续部署。这意味着组织攻击面上的弱点也在不断自动生成。如果组织的监控和发现能力跟不上不断变化的威胁，它们很容易在新的细分市场中受到攻击。幸运的是，有些平台可以实时映射和监控无服务器架构。其中许多功能还具有可扩展的安全性，并可识别未经授权的用户可以在何处恶意操纵数据。其中一些平台是专门为无服务器安全而设计的。事件数据注入是最常见的无服务器安全风险无服务器架构最常见的风险来自数据注入。自第一个无服务器系统上线以来，注入漏洞已成为无服务器安全方面讨论的主要话题。无服务器架构的每个组件和功能都需要来自多个来源的输入。这些可能是云存储事件、来自API网关的命令、消息队列事件、数据库更改、来自物联网遥测的信号，甚至是电子邮件。这个列表实际上是无限的，并且仅受模式的大小和内容的限制。可以说，规模越大，从中提取数据的资源就越丰富。这些不同的源类型中的每一种都有独特的消息格式和编码方案。其中任何一个都可能包含不受攻击者信任或控制的输入数据。预测和消除这些恶意注入对组织来说可能是一项艰巨的挑战。投资于功能监控和日志记录以实现强大的无服务器安全性在这种情况下，“投资”并不一定意味着财务投资、投入的时间和精力更为重要，尽管如果你发现你的堆栈不足，你可能会产生额外的成本.重大安全漏洞的成本影响远远超过组织的安全成本。许多云计算提供商提供了一种基本形式的日志记录功能。常见示例包括AWSCloudWatch或AzureFunctions。虽然这些功能可以为组织的环境启用基本日志记录，但它们可能成本高昂，并且一旦无服务器架构扩展到一定规模或达到一定的复杂程度，就可能无法满足组织的需求。开箱即用的解决方案并不总能满足组织的需求。尽管它们具备基本功能，但可能缺乏在应用层进行全面安全事件审计的能力。您组织的无服务器架构的大小和形状将基于您组织的独特设计，并且有许多专家构建的平台和工具可用于填补这些监控和日志记录的空白。创建独特的逻辑并利用中间云存储服务如上所述，值得在功能监视和日志记录上投入一些时间和精力。在无服务器环境中使用功能日志记录时要克服的主要障碍是监视和日志记录存在于组织数据中心的范围之外。这可以通过让组织的工程师、无服务器开发人员和DevOps团队创建其架构独有的日志记录逻辑来协调。组织将需要一种逻辑来从各种云功能和服务中收集日志，并将它们推送到远程安全信息和事件管理(SIEM)系统中。在无服务器环境中特别重要的一些日志类型包括有关身份验证和授权、严重错误和故障、更改、恶意软件活动、网络活动和资源访问的报告。无论组织使用哪种架构模型，这些报告都是关键报告。但是，在复杂且不断变化的无服务器环境中，其监控和可见性可能会很棘手。因此，创建在单个存储库中隔离、提取和组织这些报告的逻辑至关重要，以便可以实时监控整个体系结构。日志逻辑收集的日志需要存储在某个地方。这就是中介云存储服务发挥重要作用的地方。通过使用外部系统整理整个无服务器生态系统中的日志信息，组织将能够实时监控安全事件。过多的功能权限和身份验证失败如果组织不对功能和用户进行尽职调查和适当的审查，无服务器架构中可能会有一些致命弱点。首先是可靠的身份验证。Serverless通常意味着面向微服务的架构设计。微服务架构可以包含数百个独立的功能。除了充当其他进程的代理之外，许多无服务器功能还公开了公共WebAPI。这就是为什么拥有可靠的身份验证方案至关重要的原因。随着无服务器生态系统的发展，采用失败或低效的身份验证方案可能会为未经授权的用户创建无限数量的访问点。这本身就是危险的，如果组织的职能变得过于特权化，则可能是灾难性的事件。在具有数十个甚至数百个组件的无服务器环境中，管理功能权限和角色可能感觉像是一场艰苦的战斗。工程师常犯的安全错误之一是试图偷工减料并采用包罗万象的权限模型。虽然这节省了时间，但它使无服务器环境中的一切都极易受到攻击。如果由于未遵循尽职调查而存在这两种缺陷，则恶意攻击者或外部用户很容易获得对组织系统的访问权限。认证失败后会存在漏洞，一旦进入特权功能权限，就可能获取重要数据。如果组织在设计、构建和部署时考虑周全，这两种情况都可以避免。无服务器安全的更多考虑因素当然，还有其他考虑因素。例如，记得淘汰过时的功能和云计算资源。这不仅有助于简化成本，而且遗留和未使用的组件为无服务器架构的攻击面增加了不必要的维度。定期自动清理环境并删除未使用的角色、身份和依赖项。避免重复使用执行环境也很重要。云计算提供商很想在调用之间执行环境。这使得他们的云平台在处理新呼叫时更加高效。然而，随着执行环境继续运行，有价值的敏感数据可能会被遗忘，因此组织需要确保提高效率不会以牺牲安全性为代价。一个组织的无服务器环境是独一无二的，无服务器安全方法也应该如此，这始终是最重要的考虑因素。无论是部署配置、权限模型还是日志记录工具，开箱即用的解决方案将为组织提供更多保护。组织构建的无服务器环境需要一种独特的安全方法。
