在当今快节奏的商业环境下，开发人员被要求更快地构建和部署应用程序以跟上业务需求，同时云原生理念也被普遍接受，基于云原生的无服务器架构因此日渐受到青睐。但是像其他解决方案一样，无服务器架构也带来了各种各样的安全风险，成为一场全新的安全博弈。

CSA发布《如何设计安全的无服务器架构》，报告全面概括了无服务器平台的不同威胁，重点关注无服务器平台面临的应用程序所有者风险，聚焦于最佳实践和建议，并提供了适当的安全控制建议。其提出的基于无服务器的安全计算执行模型，对指导应用程序所有者如何采用无服务器架构具有极好的参考价值。

无服务器是一种云计算运行模型。在该模型中，云提供者负责为应用程序所有者的工作负载分配所需的计算和基础设施资源。应用程序所有者在任何时间都不再需要确定和控制分配多少计算资源服务于工作负载。无服务模型可以凭借大量的计算资源为工作负载提供按需服务。无服务器计算基于“即用即付”范式提出，在这种范式下，支付通常和实际的物理资源（如CPU）使用量有关。

与传统的基于云的或以服务器为中心的基础设施相比，无服务器计算有几个优势：

• 部署速度快：无需关心应用基础设施，业务能够快速构建和部署应用。
• 运营成本低：无需管理维护基础设施，云提供商通常按每个事件计费。
• 监控方式易：大多数云提供商都提供与无服务器产品捆绑在一起的开箱即用的日志记录和监控解决方案。
• 可扩展性佳：可根据使用情况在细粒度上自动扩展，只需配置基础设施而无需设置基础设施。

无服务器进一步将工作负载置入云上，同时更多地将过去由开发人员拥有和控制的功能转移到云服务提供者手中。例如，在以前的传统代码中作为函数调用实现并可能成为微服务中的Rest API，转变成了由云服务提供者提交、排队、处理的事件。

无服务器 — 一场全新的安全博弈

无服务器服务涉及两种角色：

• 服务/平台提供者：无服务器平台的提供者，可在此基础上构建无服务器应用。
• 应用程序所有者：无服务器方案的用户，应用运行在无服务器平台上。

云服务遵循云服务提供者和云服务客户之间的共享责任模型——对于无服务器也是如此。在共享的责任模型中，云服务提供者负责云的安全（保护服务器和操作系统），应用程序所有者则通过安全控制措施负责云内的安全，每一方都完全控制他们所拥有的那些资产、过程和功能。和传统安全威胁模型以及非无服务器的微服务环境中的云威胁模型相比，无服务器安全威胁模型有显著变化。使用无服务器时对应用程序拥有者的特有威胁可以分为以下几类：

• 应用程序拥有者设置阶段威胁：泛化的权限、不完善的配置。
• 应用程序拥有者部署阶段威胁：数据注入、全局信息泄露、错误和异常处理不当、损坏或不安全的身份验证、财务及资源枯竭、资源冗余。
• 服务提供者的行为威胁：有漏洞的/恶意的服务基础镜像、有漏洞的服务运行环境、可调用单元之间调用的泄漏、不同可调用单元之间的泄漏、无服务器服务的正确性、API/门户/控制台漏洞。

由于无服务器架构依然是个挑战，使用无服务器的应用程序拥有者需要评估不断进化的威胁形势，并重新考虑所需的恰当安全策略：

• 利用无服务器架构框架：加强对语言、持续开发和集成的支持，为部署和实际部署（本身可能需要多个步骤）过程中代码的绑定和打包，设置环境变量、管理密钥、配置终端以将无服务器架构服务作为公共API公开，采取并正确配置权限。
• 加强日志与调试：调用/事件输入、响应有效载荷、认证请求及其完整的可用性、开放集成等，都需要不断发展。
• 发展有状态和追踪：无服务器架构函数是转瞬即逝的，并且几乎总是与外部服务互动，主要是因为无服务器架构本质上无法保存数据。在跟踪无服务器函数的整个生命周期时，对于性能改进、安全监视、调试等运行时状态和追踪都是必不可少的。
• 监控性能：尽管无服务器函数在可伸缩性方面提供了几乎无限的弹性，但这并不意味着应该在不受监视的情况下运行。设置性能预期的阈值是非常重要的，例如：调用计数、运行时崩溃、应用程序失败、冷启动、重试的计数、内存利用率等。
• 统一身份识别与访问管理：无服务器功能可以与域中的服务集成，也可以跨信任域集成。这使得基于容器镜像的无服务器信任管理和访问管理变得复杂，具有跨平台和域可用的统一服务信任和用户标识至关重要
• 关注供应链安全：开发人员可能在函数中使用各种库。使用库可以通过利用和重用现有功能而不是编写库来节省开发人员的时间。需要引用相关技术，建立供应软件链依赖关系的信任机制，并保护无服务器函数免受第三方库和开源组件依赖关系中漏洞的影响。

正如我们所见，无服务器架构仍然处于起步阶段，但其带来的诸多益处与挑战已经引起相当程度的关注。随着无服务器架构的发展，实践和架构模式将不断增长，技术人员有必要持续关注相关技术的发展，更好地开发、部署、监控、交付性能与安全性更佳的应用程序。