2023无服务器架构设计安全.docx

《2023无服务器架构设计安全.docx》由会员分享，可在线阅读，更多相关《2023无服务器架构设计安全.docx（71页珍藏版）》请在课桌文档上搜索。

1、无服务器架构设计安全2022目录1 .介绍61.1 目的和范围61.2 受众72 .什么是无服务器83 .为什么选择无服务器123.1 无服务器架构的优势和收益133.2 无服务器的共享责任模型143.3 什么时候适合无服务器144 .使用用例和举例155 .无服务器安全威胁模型185.1 无服务器一一场全新的安全博弈？185.2 无服务器威胁形势195.3 威胁模型一25项无服务器应用程序所有者面临的威胁225.4 无服务器威胁的独特性276 .安全设计、控制以及最佳实践346.1 无服务器设计注意事项366.2 针对FaaS的控制426.3 CI-CD流水线、函数代码、代码扫描以及函数和容

2、器的策略实施436.4 基于容器镜像的无服务器增量/附加控制476.5 合规和治理637 .无服务器架构安全的未来愿景667.1 无服务器架构的未来之路677.2 无服务器架构安全697.3 无服务器在数据隐私方面的进展718 .总结729 .参考文献73附录1:首字母缩略词75附录2:术语表77执行摘要无服务器平台使开发人员能够更快地开发和部署应用，用一种简单的方式将应用迁移到云原生服务上，而无需再管理容器集群或虚拟机等基础设施。随着企业努力更快地将技术价值推向市场，无服务器平台正逐渐获得开发人员的青睐。像任何解决方案一样，无服务器带来了各种各样的网络风险。本文探讨了无服务器应用的安全性，聚

3、焦于最佳实践和建议。本文全面概括了不同威胁，重点关注无服务器平台面临的应用程序所有者风险，并提供了适当的安全控制建议。从部署的角度来看，采用无服务器架构的组织可以专注于产品核心功能，而不必考虑负载平衡、监控、可用性、冗余和安全方面的工作来管理和控制平台或计算资源。无服务器方案本质上是可扩展的，并为“即用即付”范式提供了大量的最优计算资源。止匕外，从软件开发的角度来看，采用无服务器架构的组织可以获得一种全新的部署模型,在该模型下，组织不再需要管理和控制底层操作系统、应用服务器或软件运行时环境。因此，这样的组织可以在更短的时间内部署服务并交付给市场，并降低总体运营成本。本文的建议和最佳实践是通过在

4、信息安全、云运营、应用程序容器和微服务方面具有广泛知识和实践经验的多元化团队间相互协作制定的。这些信息适用于在无服务器环境中可能负有一定责任的受众。1 .介绍1.1 目的和范围本文的目的是提供实现安全无服务器方案的最佳实践和建议。无服务器服务涉及两种角色：服务/平台提供者一一无服务器平台的提供者，可在此基础上构建无服务器应用；应用程序所有者一一无服务器方案的用户，他们的应用运行在无服务器平台上。基于无服务器方案，服务提供者提供弹性自动分配的计算资源，以满足不同可执行体的需求，不需要用户控制每个可执行体所需的资源。本文的范围限于一个部门基于其他部门作为平台提供者提供的无服务器解决方案来运行他们的

5、工作负载。无服务器的实现既包括基于容器镜像的无服务器（也称为容器即服务Container-as-service）,也包括基于函数的无服务器（也称为函数即服务FaaS）0在本文中，我们将更多地关注应用程序所有者，并考虑在使用无服务器服务时对应用的威胁。然后，我们对安全最佳实践提出了具体的建议，并列出了应用程序所有者应采用的建议控制措施。由于其他材料中有很多关于保护不同云服务的细节，本文将只关注由于迁移到无服务器服务而引发的变化，避免详细阐述通用的云安全。本文的主要目标是提出并推进基于无服务器的安全云计算执行模型。其目的还在于指导应用程序所有者如何采用无服务器架构。1.2 受众本文主要适用于应用开

6、发人员、应用架构师、安全专业人员、首席信息安全官（CIS0）、风险管理专业人员、系统与安全管理员、安全项目经理、信息系统安全官以及任何对无服务器计算安全感兴趣的人。本文假设读者有一定的编码实践、安全和网络专业知识，以及应用容器、微服务、函数和敏捷应用开发知识。由于无服务器领域技术在不断变化，鼓励读者利用其他资源（包括本文中列出的资源）获取最新和详细信息。鼓励读者遵循与安全软件设计、开发和部署相关的行业标准实践2 .什么是无服务器1）无服务器定义无服务器计算是一种云计算运行模型，在该模型中，云提供者负责为应用程序所有者的工作负载分配所需的计算和基础设施资源。应用程序所有者在任何时间都不再需要确定

7、和控制分配多少计算资源（以及体量）来服务于他们的工作负载。它可以凭借大量的计算资源为工作负载提供按需服务。无服务器计算基于“即用即付”范式提出，在这种范式下，支付通常和实际的物理资源（如CPU）使用量有关。使用无服务器的应用程序所有者使用服务提供者提供的能执行（调用、触发）的“可调用单元”，以及一组可调用单元执行（调用、触发）需要的“事件”。应用程序所有者还可以提供支持的代码在可调用单元运行。支持代码可以作为库提供，又称为“层”，可以在运行函数的上下文中运行（作为同一进程的一部分）；也可以作为“扩展”或可以在同一环境中运行的支撑线程/进程（与可调用单元不同的进程）。“层”和“扩展”共享分配给函

8、数的相同资源，并在同样的上下文中运行。注意，“无服务器”这个名称只适用于使用该服务的应用程序所有者所经历的行为。在底层，执行代码的服务器仍然存在，但从应用程序所有者那里抽象出来。2）可调用单元不同的无服务器解决方案为可调用单元提供了一系列选项。一个常见的服务选项是使应用程序所有者能够在服务提供者支持的运行态（JavaScriptPythonJaVa等）中提供函数代码。这种服务在业界被称为“函数即服务”或FaaSo在FaaS下，应用程序所有者提供的函数代码通常嵌入到由服务提供者掌管的容器镜像中。FaaS的扩展包括给服务提供者镜像安装额外的库，以及在镜像启动和函数执行前向容器注入数据。第二个常见选

9、项是让应用程序所有者提供其控件的容器镜像作为可调用单元。FaaS的这种扩展与非无服务器服务有很大的区别，后者的应用程序所有者提供了容器镜像，并在托管或非托管容器服务上执行。下表强调了这一区别。在基于镜像的无服务器模式下，服务提供者负责实现正确数量的可调用单元实例，以响应任何给定时间的事件。无服务器（本文涉及）微服务非无服务器（本文未涉及）名称基于函数的无服务器基于容器的无服务器托管容器服务Kubernetes服务由应用程序所有者交付可调用单元函数是否存在依赖容器镜像依赖特定编程语言因所有二进制文件和依赖项都已打包，可独立于代码语言运行应用。控制可执行体的可扩展性、负载均衡、冗余度和监控实例服务

10、提供者应用程序所有者控制实例可用性和冗余度服务提供者控制实例的可用性和冗余度应用程序所有者底层服务器的生命周期和扩展性服务提供者控制实例的可用性和冗余度应用程序所有者执行时间通常很短（秒级或更短）。一般限制在几分钟。通常是长期和无限的。状态无状态和瞬时的一一所有状态主要在可调用单元外维护通常情况下微服务是无状态的，但可以在挂载的卷中维护状态扩展计算服务提供者负责应用程序所有者负责支付模式即用即付为已分配资源付费运行时责任服务提供者应用程序所有者例子AWSLambdaAzureFunctionGoogleCloudFunctionsIBMCloudFunctionsAWSFargateGoogl

11、eCloudRunIBMCodeEngineAWSECSRedHatOpenshift（基于AWS/Azure/.）AWSEKSGoogleGKEAzureAKSIBMIKS在基于函数的无服务器（也称为“无服务器函数“）下，镜像由服务提供者拥有和控制,这将保证镜像安全的责任留给了服务提供者。因此，服务提供者必须适当控制，以减轻镜像给应用程序所有者工作负载造成的任何风险（请参见本文5.3中的“服务提供者控制的安全风险在基于容器镜像的无服务器（也称为“无服务器容器”）下，镜像由应用程序所有者拥有和控制，这将保证镜像安全的责任留给了应用程序所有者。因此，应用程序所有者需要适当控制，以减轻从镜像到其工

12、作负载的风险（请参见本文5.3中的“应用程序所有者设置阶段威胁”）。3）事件事件是在无服务器环境中可能导致特定函数被触发的条件一一它可能包括新的附加数据、接收到的新数据包，或者只是不同周期阶段的过期终结。除了可调用单元之外，事件驱动型应用程序的所有者还可以向服务提供者者提供一组事件，从而定义何时需要执行可调用单元的实例来处理事件。服务提供者负责对事件排队，初始化充足的可调用单元的模型，并根据服务级别协议，在约定的时间内可调用单元处理完成每个事件。事件的实际处理时间被累计用于计费。事件因事件的来源和事件的类型而有所不同。如定时器事件、Web请求触发的事件、由存储器或数据库中的数据的变化触发的事件

13、、由云帐户的服务之间或用户与云帐户的服务之间的交互触发的事件、来自事件服务的事件、云帐户中的监控服务或日志服务的事件等。4）无服务器安全概述无服务器安全带来了一种新的安全范式：应用程序所有者除了保护数据之外，只负责应用的保护。所有管理服务器或其安全方面，包括启动、机器操作系统（OS）打补丁、更新和降级，都由无服务器平台提供者管理，从而使应用程序所有者能够专注于应用本身，而不用再费心于基础设施。但是，正如本文稍后在讨论应用程序所有者需要考虑的威胁时将详细介绍的那样，无服务器也引入了它自己的安全挑战。为了更好地解释平台提供者和应用程序所有者之间对不同模型的共享责任，我们绘制了下面的图。无服务器责任

14、模型详图:应用程序所有者的 安全团队基于函数的无服务器(FaaS)共享责任模型应用程序所有者的 安全团队服务提供者的安全团队基于镜像的无服务器共享责任模型由于基于函数的无服务器可以特定于操作/运行时环境，因此平台提供者承担了维护和更新不同版本和编程语言的责任。5）混合无服务器架构（私有和公有）业界存在许多无服务器架构，以下常见的基础设施示例有（部分）： 亚马逊：Lambda,Fargate,AWSBatch 谷歌：CloudFunctions,KnativezCloudRun 微软：AzureFunctions,AzureContainerInstances Nimbella：OpenWhis

15、k IBM：Kortine（代码引擎）、OpenWhisk（CloudFunctions） 红帽：KOitine（OPenShift的一部分）3 .为什么选择无服务器与传统的基于云的或以服务器为中心的基础设施相比，无服务器计算有几个优势。在无服务器计算中，应用程序所有者通常不需要关心托管其应用的基础设施，包括应用运行的操作系统的维护和补丁或基础设施扩容。这能降低大量的运营成本。ManraL2021此外，应用代码是在动态平台上承载和运行的：特定代码可能运行在许多物理机器上，但无服务器平台通常具有动态缩放功能。3.1 无服务器架构的优势和收益下表介绍了无服务器架构的几大优势，以方便读者阅读。无服务

16、器架构可提供的优势本文讨论的无服务器架构部署速度无服务器使应用程序所有者专注开发业务应用，而不用关心应用基础设施，使业务能够快速构建和部署应用。因此，它是一个很好的实验工具，可为市场更快地带来新价值。成本基础设施成本： 通常按每个事件计费，这意味着当不使用基础设施时，不需要付费 非常划算的工作负载开销一一即便不需要服务器时也不必维护它们，可以提供非常细粒度的资源使用控制。运营成本： 没有需要管理的基础设施可以减少运营成本和维护它所花费的时间。Manral,2021应用程序拥有者的体验容易部署：无服务器服务可以通过命令行工具，编程控制或简单的应用程序编程接口（API）以最少化的配置轻松部署。易于

17、监控：大多数云提供商都提供与其无服务器产品捆绑在一起的开箱即用的日志记录和监控解决方案。该平台由APl驱动，这对应用程序拥有者的生产力至关重要。无服务器管理开销：无服务器服务抽象了所有服务器管理任务，例如补丁、服务开通、容量管理、操作系统维护。规模按性质可扩展： 无服务器根据使用情况在细粒度上自动扩展，只需配置基础设施而无需设置基础设施 无需配置扩展或缩减工作负载的策略。 在本地工作时，伸缩仅限在于可用的基础设施上。3.2 无服务器的共享责任模型在共享责任模型中，开发人员负责保护他们的代码和用于向云交付应用程序的工具。在这个共享的责任模型中，每一方都完全控制他们所拥有的那些资产、过程和功能。服

18、务应用程序拥有者无服务器平台提供商平台补丁基于镜像和功能的无服务器。平台配置与应用程序相关的应用程序和平台配置。向应用程序拥有者开放最小配置。镜像补丁基于镜像的无服务器容器。基于函数的无服务器安全编码实践基于镜像和函数的无服务器。供应链安全基于应用和组件的供应链。平台供应链.网络安全监控基于镜像和函数的无服务器。应用程序安全监视基于镜像和函数的无服务器Cl/CD流水线配置基于镜像和函数的无服务器3.3 什么时候适合无服务器当存在相对较大的应用程序或应用程序集以及成熟的软件开发和运营(DeVoPS)团队、流程和产品来支持它们时，无服务器模型最合适。在这种情况下，应用程序可以分解为称为微服务的较小

19、组件(请参阅BestPracticesinImplementingaSecureMicroservicesArchitecture)。每个都支持一个或多个团队，并在无服务器环境中运行。这允许通过专注于特定功能来更有效地使用开发资源。与单体应用程序相比，该模型还允许对每个微服务进行更敏捷的开发，因为应用程序的每个部分的功能都可以转移到生产中，而无需过多关注与其他应用程序功能的完全集成和回归测试。对于相对较小的应用程序或团队，无服务器模型有时比拥有支持应用程序的传统基础架构（例如IaaS基础架构即服务或PaaS平台即服务）的成本效益要低。较小的应用程序通常具有较低的复杂性，并且失去了将应用程序分解

20、为微服务的好处。在这种情况下，微服务可以与其他服务紧密耦合，可能失去了微服务的一些长处，例如可复用性。支持微服务的资源不足可能会导致团队需要停止一个微服务以支持另一个微服务。同样重要并需要注意的是，几乎在所有情况下，无服务器架构可简化部署过程。部署包括简单地上传一个容器镜像或一组代码，而不像传统的应用程序部署那样关注资源供应和网络架构。所以企业在决定组织在决定使用无服务器体系结构时，需要执行业务影响分析和成本/效益分析，以选择技术效率最高、成本效益最高、适合其业务需求的解决方案。4 .使用用例和举例无服务器计算的关键作用是为云程序员提供必要的工具，这些工具可以通过消除对基础架构的考虑并支持直接

21、使用编程语言来降低云计算架构的复杂性。然而，许多问题需要提前解决，包括负载平衡、请求路由以有效利用资源、系统升级（例如安全补丁）、迁移到新的可用实例以及冗余副本的地理分布以便在发生灾难时保护服务。无服务器架构的一个使用用例是，在没有操作和扩展基础设施方面广泛技术专业知识的情况下，拥有超大弹性扩容的基础设施。无需维护硬件、操作系统或支持软件，即可构建、部署、管理和扩展无服务器应用程序。这使应用程序拥有者能够专注于业务逻辑，而不是非核心的能力。应用程序拥有者的成本是高度精细的，费用随着使用而线性增长，从而产生一致的经济可行性。总成本取决于运营规模。客户/用户必须根据其需求决定平台规模。无服务器架构

22、还有一些业务使用用例是:（注意:这并不是一个全面的使用用例的存储库，而只是提供一些示例来，为安全专业人员提供一些参考）。 Web应用程序:用户需要访问现有的服务并查看或进行较小更新的地方。在该活动完成之后，该功能可能会被删除一一基本上是传统的请求和响应工作负载。可以使用无服务器功能，但仍然需要解决错误的身份验证和不可抵赖性等安全威胁。 数据处理活动是事件驱动的，在数据处理请求完成后，服务可能会被删除。例如，启动触发器以通过经纪账户拉取一天内为客户购买的所有账户借方或股票的报告。 除了身份验证和授权之外，数据完整性、机密性和安全性问题也是无服务器功能需要关注的。 批量处理使用用例，通过设置一系列

23、触发器，并构建一个工作流来提取、操作和处理数据。例如，拉出一份未通过碳排放测试的汽车列表，并向车主发送一封电子邮件，其中包含州要求和标准以及满足这些要求的截止日期。安全问题主要是低权限访问、数据机密性和用户隐私。 事件采集和集成:从分析应用程序中收集所有事件，并将它们提供给数据库，用于索引和归档事件，并使用特定触发器启动报告功能或发布到仪表板/浏览器界面。在这种情况下，必须从安全角度解决访问管理和不可否认性问题，并确保使用检测所需的元数据生成日志。 无服务器已经在行业中用于安全检测和自动响应，主要用于警告错误配置和采取后续行动。 无服务器可用于图片识别和处理。例如谷歌ViSion和亚马逊Rek

24、ognitiOn服务，然后根据标识对这些图片进行索引。 或者，无服务器也用于构建应用，客户上传信用卡信息，然后提取属性来处理交易。 对于这些使用用例，数据安全性、隐私、身份和访问管理问题都需要解决。 在一些使用用例中，可以生成触发器，将事件流水线传递给SaaS提供者进行处理。 Cl-CD流水线需要快速迭代软件开发的能力。无服务器可以自动化许多这些过程。代码检查可以触发构建和自动重新部署，或者变更请求可以触发运行自动化测试，以确保在人工审查之前对代码进行了良好的测试。在任何需要自动化的地方，都有可能使用无服务器应用程序简化或加速自动化，并可以轻松地从工作流程中消除手动任务。 在物联网传感器输入消

25、息的工业环境中，需要基于可设置的触发器处理这些消息，然后使用无服务器功能响应消息并进行扩展。在某些情况下，不安全功能的影响可能非常严重。因此，除了故障之外，身份验证、数据保护和检测是这些场景中需要解决的重要控制。如果有一个应用程序需要基于业务逻辑执行特定的步骤:可以使用无服务器功能来实现执行一系列步骤的微服务工作负载的编排。从编排的角度来看，使用无服务器存在几个安全问题；从可审核性的角度来看，触发事件传递的数据/元数据、故障/可用性、以及身份验证和授权之外的不可否认性问题。 假期期间的客户服务使用用例，响应客户的查询，即聊天机器人，无服务器提供自动伸缩以满足高峰需求并在聊天结束后删除其功能。

26、从安全角度来看，用户身份验证和数据保护/隐私仍然是需要解决的问题。 行业中无服务器的其他流行使用用例是基础设施自动化任务，例如在定时备份等。从安全团队的角度来看，企业面临的一个重要的问题是，他们可能不知道在他们的平台中所有的无服务器功能都在哪里使用了一一考虑到其中一些功能可能是临时的，这就使它变得很困难。以下章节提供了构建控件的详细建议，这些控件将有助于企业中无服务器的可见性和资产跟踪。如上所述，安全团队可以使用无服务器函数来触发和使用其他无服务器函数以自动化安全任务。检测和响应的使用用例在业界已经很普遍，但安全团队还可以使用无服务器的其他任务，比如Cl-CD流水线中自动扫描发现漏洞时强制中断

27、构建。无服务器函数可以按需触发对基础架构的扫描，并报告结果或自动执行。无服务器函数也可用于加强其他安全控制。例如，每当用户上传数据元素时，函数都会检查数据是否已被标记或标签。如果没有，它会向用户生成警报或电子邮件，告知上传的文件没有被标记。然后将其进行隔离，直到标记，以确保适当的DLP或其他合规政策可以执行。无服务器函数也可用于安全策略的执行，例如在验证对服务的访问时，函数检查可以确保是否落实身份验证。或者还会需要升级身份验证，因此失败的身份验证保证级别有可能触发另一个功能请求升级身份验证。同理，可能还有其它函数用于执行安全政策。类似地，无服务器在安全领域中的应用也在逐步被探索，并在使用无服务

28、器功能去简化和自动化安全任务这一项上还具有无限潜力。同时，安全团队与开发人员也必须了解对无服务器技术至关重要的威胁概况和安全控制，这些将在后面章节中详细讨论。5.无服务器安全威胁模型在使用无服务器技术时，应用程序的开发者需要关注多种威胁。本节将讨论无服务器服务的使用是如何以及为何改变了应用程序服务的威胁形势。详细介绍无服务器独特威胁模型及表现方式；以及针对无服务器的特殊安全注意事项及工具。无服务器缓解措施、设计架构及减少安全控制在第6章中介绍。5.1 无服务器-一场全新的安全博弈？云服务提供者引入无服务器服务，给应用/服务开发商和拥有者带来了全新的安全挑战。无服务器作为事件驱动架构，将工作负载

29、分解成多个无缝隔离的执行环境。每个执行环境都承载着一个特定任务并负责处理一个单独事件，在时间与空间中各自运行，具有自己的依赖项、代码、镜像、权限要求、配置和生命周期。和传统安全威胁模型以及非无服务器的微服务环境中的云威胁模型相比有显著变化。使用无服务器的应用程序拥有者需要重新评估不断进化的威胁形势，并重新考虑所需的恰当安全控制。无服务器也许包括一些跨越信任边界的流量，例如从公共位置获得数据，将数据输入客户经营场所，调用其它位置的函数等。现有的网络边界正在逐渐消散。这种碎片化也会导致需要大幅增加收集、处理和分析以检测攻击的安全原始数据量。无服务器是将工作负载深入云中的又一步骤，同时将更多过去由工

30、作负载开发人员拥有和控制的功能转移到云服务提供者（CSP）手中。例如，在以前的传统代码中作为函数调用实现并可能成为微服务中的ReStAPI,现在转变成了由云服务提供者（CSP）来提交、排队、处理的事件。云服务提供者（CSP）会跟进直至实际数据被功能函数处理完成-一直到请求者要求处理这些数据之后的某个时候。应用程序拥有者将多项安全控制权放权给服务提供者-这个过程再次要求重构服务消费者的权限和义务，以此来保证基于无服务器的微服务/应用的安全性以及明确由谁来做。功能2我的服务功能工KUbernetes容器管理服务由Rest API功能2微服务7无服务器一一场全新的安全博弈5.2 无服务器威胁形势5.

31、2.1 主要威胁领域使用无服务器时对应用程序拥有者工作负载的威胁可以分为以下几类:1. 应用程序拥有者设置阶段威胁2. 应用程序拥有者部署阶段威胁3. 服务提供者的行为威胁在下述图表中，我们总结了无服务器下应用程序拥有者的主要威胁领域。部署阶段设置阶段易受攻击的依赖项易受攻击的弑础镜像脆弱配置云服务相关的错误配匿/漏洞针对/通过构建/部署工具进行攻击被利用的代码库和基础算像注册今个服务提供吉威胁财务及资源枯羯行为威胁。电麒威胁形势5.2.2 应用程序拥有者设置阶段的威胁我们将与应用程序所有者准备工作负载资产相关的威胁包命名为部署威胁，包括所有必要的代码、镜像、CI/CD工作、云资源的供应和配置

32、等，统称为应用程序拥有者设置阶段的威胁，。其中包括了无服务器特有的一组威胁和一组存在于系统中（如微服务）的威胁，但随着时间推移，系统中运行或启动不同的重复代码的预期数量会随着无服务器的使用而增加。对于无服务器而言，应用程序拥有者设置阶段的威胁的独特性包括由访问权限或配置错误而导致的威胁： 广泛且通用的权限 广泛且通用的事件访问 在无服务器控制上拥有广泛的用户权限 弱配置应用程序拥有者设置阶段的威胁随着向无服务器的转变而加剧，其中包括：CI/CD流水线或依赖项中与交付流程相关的威胁： 可利用的存储库和基本映像注册表 针对/通过构建/部署工具的攻击 易受攻击的依赖关系 易受攻击的基本镜像错误配置导

33、致的与服务设置相关的威胁： 相关云服务的错误配置或漏洞5.2.3应用程序所有者部署阶段威胁本文命名与应用程序所有者部署工作负载资产相关的威胁包，包括所有无服务器关联的云和云外资产、应用程序所有者部署阶段威胁。本文再次区分了无服务器特有的威胁和因使用无服务器而加剧的威胁：无服务器特有的应用程序所有者部署阶段威胁包括：可调用单元的设计和实现造成的运行时相关威胁： 数据注入 全局环境泄漏 错误和异常处理不当 认证中断或不安全与无服务器按量计费相关的威胁： 财政和资源枯竭（如果已设定资源限制） 资源丰富和意外开支。应用程序所有者部署阶段因使用无服务器而加剧的威胁包括: 密钥管理不安全 不安全的日志记录

34、/监控 日志和元数据中的敏感数据 记录/监测不足且不安全5.2.4服务提供者的行为威胁本文将与应用程序使用的服务提供者提供的服务相关的威胁集命名为服务提供者的行为威胁，包括服务提供者使用的整个堆栈，以及用于形成无服务器或相关服务的任何依赖项、个人和其他资产。这些威胁包括无服务器独有的，也包括与其他服务中相似的： 易受攻击/恶意的服务基础镜像 易受攻击的运行服务 可调用单元调用之间的漏洞 不同可调用单元之间的漏洞 无服务器服务正确性 API/门户/控制台漏洞5.3威胁模型一25项无服务器应用程序所有者面临的威胁下表列出了无服务器面临的各种威胁。序号威胁类别威胁描述缓解措施（安全控制）应用程序所有

35、者设置阶段的威胁（八）无服务器面临的特有威胁1泛化和通用权限未维持可调用单元的最小特权原则。应用程序所有者可以定义无服务器可调用单元在运行时可拥有的特权过多权限可能被攻击者利用开展网络攻击。见章节6,635,63.7.1,6.372等。2泛化和通用的事件访问未维护触发可调用单位的事件的最小特权原则。应用程序所有者可定义有权限触发可调用单元事件的用户。泛化的访问控制极大的减化了攻击的执行难度，增加了事件驱动的无服务器架构中的攻击面。见章节6,6.3.5z63.7.1,637.2等。3无服务器访问控制的泛化用户特限未维护团队的最小特权原则。应用程序所有者可定义有权设置无服务器服务、镜像存储等的用户

36、。更泛化的访问增加了潜在的攻击路径，增加了来自内部人员的风险。见章节6,6.3.5,637.1,637.2等。4不完善的配置无服务器配置不完善和配置迁移可能会使平台和所承载应用程序易遭受攻击。许多用于托管无服务器应用程序的服务的配置不安全。特定的配置参数对应用程序的整体安全状况具有重要影响，应予以关注。例如，谁可以承担执行功能的角色，以及基于这个假定的角色，能实现什么？见章节6,6.3.7.2.6.3.26.3.36.3.4等。无服务器面临的通用严重威胁5相关云服务的错误配置或漏洞其他云服务与无服务器服务协同构建的工作负载可能配置错误或易遭受攻击。通常，可调用单元的安全性取决于所使用的相关云服

37、务的安全性。例如可调用单元的安全性可能依赖于密码服务或身份和访问控制管理系统等的安全功能。可调用单元也可能依赖于供应链中第三方提供的服务。因此，对其他服务的依赖和这些服务中的错误配置作为无务器应用程序的一部分，会影响无服务器功能的完整性。见章节6,6.3.7.1,637.2,6.3.3等。6可利用的存储库和基本镜像注册表用于存储库依赖项和基础镜像的存储库和注册表中存在漏洞。攻击者可能会尝试通过识别共享（公共或私有）代码存储库和镜像注册表中的漏洞来组合应用恶意代码。由于独立可调用单元数量的潜在急剧增加，无服务架构面临的威胁也会增加。见章节6,6.3.3等。7攻击对抗/通过构建/部署工具用于构建和

38、部署可调用单元和事件的CI/CD自动化工具的漏洞和错误配置。作为CI/CD实践的一部分，自动化工具通常用于构建、部署可调用单元格（包括将触发它的事件）。这种自动化功能需要通过具有提升权限的工具来存储可调用单元和设置无服务器云服务。攻击者可能会使用提升后的权限将恶意代码合并到目标应用程序中，或者作为一种导致无服务器应用程序更新发生拒绝服务的方法。见章节6,637.1等。8脆弱性依赖（易受攻击的依赖项）任何第三方库中的漏洞或恶意代码都可能导致可调用单元发生供应链攻击。应用程序可调用单元通常使用多个第三方库依赖。此类库可能包括现有或新发现的漏洞。此外，恶意攻击者可能会在此类库中嵌入恶意软件一一这适用

39、于所有应用程序和服务，包括无服务密微服务。见章节6,6.1,6.2,6.3.7.1,637.2等。9易受攻击的基础镜像基于镜像的无服务器服务形成的基础镜像中的漏洞。应用程序所有者在基于镜像的无服务器下构建的基础镜像易遭受预安装依赖项中多种现有或新发现的漏洞的影响，并且还可能包括预安装的恶意软件。见章节6,6.3.3等。应用程序所有者部署阶段威胁（B）1数据注入无服务器可调用单元在激活期间从各种事件接收输入每个此类事件都代表数据注入相关的潜在威胁。当不受信任的输入在经过适当审行和验证前直接传递给解释器执行，就会出现注入漏洞。此类漏洞通常被攻击利用。大多数无服务器架构提供了大量事件源，可作为数据注

40、入攻击的潜在载体。数据注入事件还会破坏业务函数的执行排序并导致拒绝服务。见章节6,637.2等。2全局信息泄漏无服务器全局信息可能引发信息泄露，例如，在可调用单元的调用时会进行令牌维护（例如，无需每次调用都重新验证身份），全局信息可能会在请求时泄漏敏感数据。由于可调用单元的不同调用通常用于为其他工作负载的用户的数据使用提供服务，因此可调用单元与其他请求之间发生数据泄漏是一种威胁。敏感数据可能会留在容器中，并可能在函数的后续调用期间暴露。恶意数据可能被故意留下来攻击函数的未来调用。见章节6,637.2等。3错误和异常处理不当与标准应用程序的调试功能相比，基于无服务器应用程序的云初始调试选项有限（

41、且更复杂）。错误处理不当会产生漏洞并允许恶意操作，例如缓冲区溢出攻击和拒绝服务攻击。详细的错误消息可能会导致信息意外泄露给攻击者-这适用于所有应用程序、无服务器、元数据和资源见章节6,637.2等。4损坏或不安全的身份验证对事件源的身份和/或发起此类事件的用户/进程的身份验证不正确。通常，可调用单元需要确认所发送事件背后的实体的身份。攻击者将试图利用所使用的身份验证机制中的任何漏洞。见章节6,6.372,635等。5财务及资源枯竭攻击者利用无服务器机制恶意占用资源攻击者可能会利用无服务器的“即用即付服务机制，通过创建许多调用应用程序可调用单元的虚假事件和/或通过启动导致告警的事件（例如，通过暴

42、露代码或依赖项中的一些其他弱点来迫使应用程序所有者长时间支付大量的计划外费用。见章节6,6.3.6等。6资源冗余无服务器机制被攻击者利用作为无限计算资源池攻击者可能会利用无服务器可作为无限资源池的机制。并鉴于这些漏洞去利用可调用单元可用的大量计算资源并利用它谋取利益，例如1,利用相关资源进行挖矿或对某些第三方发起攻击。见章节6,637.1,637.2,6.3.3等。无服务器面临的通用严重威胁7不充分且不安全的审计/监测对安全事件的态势感知不足，无法监测安全漏洞。审计不足会妨碍组织对攻击/违规行为迅速做出响应的能力，并使取证分析变得困难或不可能。见章节6,637.1,6.3.7.2z6.3.3等

43、。8密钥的不安全管理可调用单元使用的密钥泄漏，可能导致对部分系统的恶意访问或权限提升。通常，可调用单元被触发的时候需要访问特定的云或外部资源。要做到这一点，可调用单位可能需要获取密钥攻击者可以利用未安全存储的密钥或使用标准凭据集等情况。像任何其他使用无服务器功能的应用程序样，凭据和密钥的泄漏可能导致虚拟身份和数据泄漏。见章节6,6.3,7.1,63.7.2,等（见#3.过度的数据暴露）9不安全的日志记录/监视向攻击者公开日志数据或允许攻击者删除日4o不安全的日志记录可能使攻击者能够隐藏其攻击行为而难以追踪，或删除其行为的痕迹来阻止发现和取证。同时，功能所有者可能检测不到任何安全问题，也可能不能

44、响应这些问题，从而影响无服务器应用程序的整体完整性见章节6,63.7.1,6.3.7.2,633,等10敏感日志记录/监视日志记录涉及安全和隐私的敏感信息可调用单元和事件可能通过日志记录和监视系统暴露敏感数据，包括密钥、个人识别信息、用户数据等。见章节6,63.7.1,637.2,6.3.3,等服务提供者行为的威胁（C）无服务器的独特威胁1有漏洞的/恶意的服务基础镜像在基于功能的无服务器下，服务提供者选择的基础镜像可能包含漏洞/恶意软件。服务提供者使用的镜像包括多个第三方依赖项。此类镜像易受现有或新发现漏洞的影响，也可能包括预装的恶意软件。考虑到服务提供者管理平台的底层基础，这可能会影响无服务

45、器应用程序的安全态势。见章节6,6.3.32有漏洞的服务运行环境在基于功能的无服务器下，运行环境是由服务提供者的代码配置和扩充的，这可能会导致运行环境存在漏洞。在基于功能的无服务器下，基础镜像通常会增加额外的代码，以形成服务并监视服务提供者。部署时，运行容器的配置由服务提供者设置一这可能会导致潜在的漏洞，如开放端口或集成到运行环境中的其他管理设施。因此，在完整上F文中评估无三务器应用程序的安全控制措施是恰当的。见章节6,6.3.6（KUbemeteS的风险和控制:深入挖掘）6.371等3可调用单元之间调用的泄漏在当前无服务器服务合约之外，可调用单元之间隔离失效的，存在的无服务器服务脆弱性。由于

46、可调用单元的不同调用通常服务于多个工作负载用户拥有的数据因此调用之间的数据泄漏是一个重大的威胁。例如，一个可调用单元被重用以服务于不同的最终用户或会话上下文，可能会泄漏先前留下的用户敏感数据。或者，先前故意留下的恶意数据/状态可能会伤害后续的用户。见章节6,63.7.2等,4不同可调用单元之间的泄漏在同样的运行环境实例上按顺序执行的可调用单元之间的隔离失效，存在的无服务器服务脆弱性。例如，函数1结束，而函数2在相同的没有进行适当清理的运行环境上的FaaS下加载。由于其他可调用单元具有不同的云和数据访问权限，维护不同的身份和密钥，具有各种可利用的漏洞，因此不同可调用单元之间的泄漏是一个重大威肋,。例如，如果重新使用无服务器执行环境来服务个可调用单元，然后服务另一个（来自相同F同应用程序所有者）可调用单元，则可能会留下敏感数据，或者故意留下恶意数据/状态来伤害后续用户，利用后续的权限、身份以及密钥或利用后续可调用单位的漏洞。见章节6,6.3.