亚马逊云科技-无服务器安全策略内部探秘GenAI

亚马逊云科技-无服务器安全策略内部探秘GenAI

关键字: [yt, Lambda, Serverless Security Policies, Identity Access Management, Fine-Grained Access Controls, Shared Responsibility Model, Lambda Execution Environment]

本文字数: 3200, 阅读完需: 16 分钟

导读

在此次演讲中,Sam Dangler、Becky Weiss和Mark Brooker探讨了亚马逊云科技无服务器服务(如Lambda)如何助力开发安全且可扩展的应用程序。他们阐释道,在无服务器架构中,共享责任模式将更多的安全责任转移至亚马逊云科技,从而减轻了客户的运营负担。重点内容包括:

• 无服务器架构高度依赖细粒度的IAM策略进行访问控制,而非传统的网络安全控制措施。
• Lambda函数在由Amazon Firecracker虚拟化技术驱动的隔离微型虚拟机中运行,提供了强大的安全边界。
• 亚马逊云科技提供了诸如服务控制策略和权限边界等工具,用于在整个组织范围内对无服务器权限实施保护。
• 客户应投资培训开发人员掌握IAM策略,并利用亚马逊云科技为无服务器应用程序提供的预防性和检测性安全控制措施。

演讲精华

以下是小编为您整理的本次演讲的精华，共2900字，阅读时间大约是14分钟。

在不断演进的云计算领域中,亚马逊云科技(亚马逊云科技)作为先驱,提供了一套全面的服务来满足企业和组织日益增长的需求。在这些服务中,无服务器架构引起了广泛关注,承诺将应用程序的开发、部署和管理方式带来范式转变。然而,与任何技术进步一样,安全性仍然是一个至关重要的问题,亚马逊云科技已采取积极的态度来解决这一关键问题。

在这一努力的前沿,有来自亚马逊云科技的主要工程师Becky Weiss,她拥有超过6年的经验,以及支持无服务器组织工程的主要工程师Mark Brooker,他已在亚马逊云科技工作约11年,并自2015年Lambda服务进入测试阶段后不久就加入了Lambda团队。他们的专业知识和见解揭示了亚马逊云科技在无服务器安全策略方面的复杂细节。

亚马逊云科技的安全方法的核心在于共享责任模型,这个概念明确了亚马逊云科技和客户之间的责任划分。Becky Weiss阐释了这个模型,她说:“当我们谈论在云中运行任何东西的共享责任模型时,我们将其分为两个部分。我们谈论云中的安全性和云的安全性。”亚马逊云科技负责确保云的安全性,包括底层计算基础设施、存储、网络、数据库和跨越各个行业的更多服务。“这是一项关键的工作,正如Becky所强调的:”云的安全性是我们的工作。保持这些服务的安全是我们的工作。相信我,我告诉你,这绝对是我们所有工程团队的首要重点,因为我们知道没有这一点就没有云。你必须能够信任它。

相反,客户被委托负责云中的安全性,这包括对他们在亚马逊云科技生态系统中部署和管理的资源进行适当的配置和操作实践。贝基简洁地总结了这一方面,她表示:“云中的安全是客户的责任,我可以将整个类别概括为客户在云中运行内容的适当配置和操作实践。例如,在服务器全模型中,客户在云中运行EC2实例虚拟机,这些实际上都是计算机,因此客户必须对这些属于自己的计算机应用所有的安全最佳实践,如打补丁、升级,确保EC2实例上没有运行陈旧的软件版本。”

无服务器架构的出现带来了这种共享责任模式的范式转变。贝基解释道:“无服务器在共享责任模式中真正有助于将越来越多的责任转移到云安全这一类别,因为客户拥有的专用基础设施越来越少,客户将越来越多地转向消费这些Web服务、事件驱动调用API、在Lambda为客户提供的一小块计算资源上运行函数代码,越来越多的表面积成为云安全,成为亚马逊云科技的工作,这当然是客户所期望的,因为它简化了客户在云中运行应用程序的工作。”

从传统架构向无服务器模型的过渡需要改变安全思维和实践。贝基强调了关键区别,她说:“当客户从服务器转移到无服务器时,客户需要维护、照看、保持升级和打补丁的基础设施数量可能会降至零,如果客户完全采用无服务器架构的话。”传统的安全模型围绕着保护网络、防火墙和基础设施,而在无服务器模式中,网络的作用减小了,因为访问是由API驱动的,并通过利用亚马逊云科技身份和访问管理(IAM)的身份验证和授权策略进行控制。

马克·布鲁克尔深入探讨了无服务器生态系统的基石 Amazon Lambda 的内部运作机制。他解释道:亚马逊云科技获取客户的函数代码。客户已经创建了这个 Lambda 函数,并上传了一些代码与该函数相关联,亚马逊云科技将该代码置于客户自己的 Lambda 执行环境之上。这个执行环境被封装在一个微型虚拟机 (microVM) 中,这是一种轻量级的虚拟机,提供了强大的隔离能力。亚马逊云科技开发了一种专门为无服务器工作负载设计的专有虚拟化技术,名为 Firecracker,与传统的容器解决方案相比,它提供了卓越的安全性、性能和可扩展性。

马克详细阐述了执行模型,他表示:每个 Lambda 函数都有一个入口点。这只是客户代码中的一部分,它指示先运行这部分。当那个 Invoke API 进来或者与亚马逊云科技众多集成之一的事件进来时,就会首先运行这部分代码。这种事件驱动的执行模型确保每个函数调用都在隔离的环境中运行,消除了在单个实例中进行多线程和并发执行的顾虑。马克进一步解释道:因此,客户不必担心多线程,也不必担心基准测试客户的代码在特定机器上可以并发运行多少个副本。这一切都在幕后处理。

这种方法的一个显著优势是减小了潜在安全漏洞的面积。马克解释道:在 Firecracker microVM 中,每个工作负载都获得自己的 Linux 内核,这使客户能够在内核上运行工作负载,并让亚马逊云科技做一些非常有趣的事情。所以,如果回想一下容器模型,其中事物共享内核,那么如何提高该模型的安全性呢?通过做出权衡,即亚马逊云科技想要更好的安全性,因此亚马逊云科技将减少每个工作负载被允许接触内核的部分。这意味着在容器世界中,工作负载的兼容性和安全性之间存在一个硬性权衡。在 microVM 世界中,亚马逊云科技在 Firecracker 上所做的,以及亚马逊云科技在 Lambda 生产环境中所做的,就是让代码运行在自己的内核之上。

该隔离模型确保来自不同账户或甚至同一账户内的函数无法相互交互,为系统提供了一个健壮的安全边界。Mark进一步强调:“而且该内核运行在虚拟化之上,并通过非常简单的协议与Firecracker通信,以接收网络数据包、执行块IO。因此,这些简单的协议使我们更容易推理安全性、证明安全性并围绕它建立一个非常强大的边界。”

随着客户从传统架构过渡到无服务器模型,开发人员在确保应用程序安全方面的角色呈现出新的维度。Becky建议:“如果某人是一名亚马逊云科技开发人员,或者是一个开发组织的领导者,应该鼓励员工学习相关知识。但是,如果要在亚马逊云科技投资学习一件事,那就应该是IAM,它被用于所有亚马逊云科技服务。”IAM(身份和访问管理)是亚马逊云科技安全模型的基石,能够对访问和权限进行细粒度控制。

Becky为开发人员提供了一种实用的方法来学习和实施IAM策略,她说:“我的做法是从完全没有权限的情况下开始开发Lambda函数。显然,一些事情将无法工作。所以我会遇到第一个访问被拒绝的情况。我会想,我需要这个S3获取对象的权限。然后去查看如何读取S3获取对象策略的文档。它的文档是非常统一的。所以我只需按照表格查看说明,编写相应的策略,然后再次运行我的函数,现在我就会遇到下一个访问被拒绝的情况。我需要向SNS主题发布的权限。我需要这个。这实际上是一种非常好的方式来逐步添加这些策略。这会让你达到一个很好的最小特权位置。

亚马逊云科技Organizations提供了各种预防性和检测性控制措施,可在整个组织层面、数千个亚马逊云科技账户中发挥作用。特别是在预防性控制方面,当考虑权限时,由于无服务器环境中的一切都是通过权限完成的,因此存在一种称为服务控制策略的功能,亚马逊云科技在文档中提供了许多很好的示例,但可以做出一些断言,作为整个环境的预防性控制措施。

这些预防性控制措施使组织能够在各个层面定义防护栏和边界,从整个组织层面到网络边界,再到单个账户。举例来说,最佳示例可能是组织只使用这三个亚马逊云科技区域,不使用其他亚马逊云科技区域。因此,可以拒绝任何尝试在组织不打算使用的区域中调用亚马逊云科技服务的行为。或者,如果组织知道只使用了一个特定的亚马逊云科技服务集合,那么就只允许使用这些服务。

即使在同一个应用程序中,如果开发人员构建无服务器函数并为它们分配权限,IAM也有一个先进的功能叫做权限边界,专门为这种用例而设计。该组织中有一位开发人员,他或她将编写策略并将其分配给函数。然而,需要明确这些函数的外部边界是什么,从Lambda函数执行合理的操作可能是从S3读写数据,而不合理的操作可能是删除数据。因此,可以编写一个边界权限,规定这些策略所涉及的服务范围,作为最大权限的底线。然后,当这些开发人员创建他们的策略时,无论他们写什么,都会保持在这个范围内,从而更好地编写最小特权策略。

Mark Brooker分享了与客户对话的见解,强调采用无服务器架构可以加快开发周期并提供更好的安全控制。他回忆了与一位金融行业客户的对话,该客户表示,在他们的传统架构中,存在一个庞大的生产审计流程,团队需要编写大量代码,然后经过正式的代码审查流程,再构建生产环境,之后安全团队会花费数周甚至数月的时间审计,确保其准备就绪投入生产。当时他们认为这反映了作为金融行业客户的安全关键性,这一点非常重要。但是通过转向无服务器,他们能够在自动化的过程中构建相同的控制,甚至在某些情况下构建更好的控制,比如在构建Lambda函数或构建API Gateway配置的过程中进行自动扫描步骤,完全取消了生产审计步骤。

客户体验强调了在不牺牲敏捷性的情况下实现更好控制的能力。正如Mark所言:“他们认为,通过围绕开发人员可以做什么建立这些防护栏,通过自动化扫描,并使用无服务器中可用的一套工具,他们能够获得更好的控制,而不需要数周和数月的时间。令人兴奋的是,他们表示我们的开发人员不仅行动更快,不仅为我们的业务交付更多,我们的客户也很满意,但开发人员自己也很喜欢。只是能够更快地完成工作,将东西投入生产,培养。”

Mark强调了无服务器架构所培养的以客户为中心的方法,他说:“我认为我最喜欢在无服务器领域工作的一点是,在与客户的对话中,我们更快地了解他们的客户是谁,以及他们要解决的业务问题是什么。在许多其他技术对话中,人们往往被技术及其配置和插入方式所束缚。很多时候,开发团队对业务方面和他们的客户是谁以及试图解决的问题没有很好的认识。我总是喜欢与客户的这些对话,因为我可以学到很多关于这些不同行业以及他们的客户和他们在做什么的知识。”

Becky加强了无服务器安全性是由事件、API请求和权限驱动的观念,她说:“如果你从这次讨论中没有其他收获,我希望你现在对无服务器安全性与你之前看到的有何相同和不同有了一定的认识。主要要注意的是,所有无服务器都完全由这些事件和API请求驱动,从安全角度来看,由权限驱动。因此,如果你弄清楚它是如何工作的,如果你弄清楚如何在你的架构图中每个箭头处编写良好的安全策略,你最终将拥有比以前任何时候都更可审计和最小特权的应用程序表面,这将大大优于以前。

马克也表达了相同的观点,鼓励客户探索和学习各种可用资源的丰富知识,例如 Lambda 安全白皮书和 Well-Architected 框架。他强调:“对于这种环境而言,关于安全性、架构和最佳实践的许多事情都没有改变。许多基本原理依然相同,但现在有了一个新的强大工具集,可以让您以新的方式实现这些基本原理,从而使开发人员能够更高效地工作。”

贝基分享了一个客户从本地运行数据库转向使用 Amazon DynamoDB(无服务器数据库服务)的案例。客户的安全团队最初提出疑问:“那么,我如何在我的网络中连接到我的 DynamoDB 表呢?我如何将它放在我的防火墙后面?”这个问题凸显了在转向无服务器架构时所需的思维转变,在无服务器架构中,访问是由 API 驱动的,而不是传统的基于网络的控制。

贝基解释道:“而且数据库有自己的身份验证和授权方式,有用户名和密码。而且,如果你这样做的话,你也在创建,你也在通过网络中的防火墙规则来控制访问。因此,当你转向一个完全由 API 驱动的架构时,这是一种思维转变,因为现在的模式是,当我要访问我在 DynamoDB 中的表时,我会向 DynamoDB.us-east-2.amazonaws.com 发送请求。这就是我在网络上访问的地方。所有的访问都是在非常细粒度的级别上通过 IAM 身份验证和授权完成的。

为了满足无服务器架构中网络控制的需求,亚马逊云科技 引入了 VPC Endpoints,允许客户在其虚拟私有云(VPC)与无服务器技术之间创建私有连接。Becky解释道:“这就是为什么我们为所有这些无服务器技术提供了两种选择。如果客户在 亚马逊云科技 中寻找名为 VPC Endpoints 的功能,这就是他们如何在自己的 VPC、云中的数据中心与所有这些无服务器技术之间创建私有连接,因为他们是通过 API 访问这些技术的,但我们可以将这些 API 端点投射到客户的 VPC 中。因此,客户可以获得所有可能的最佳体验。它仍然是无服务器的。客户仍然不需要升级和修补任何东西。但是,如果客户希望将网络作为访问管理策略的一个组成部分,这是许多企业客户的需求,特别是那些来自数据中心世界的客户,他们可以在其中获得这两种保护。”

总的来说,该视频深入探讨了 亚马逊云科技 中无服务器安全策略的复杂性,重点介绍了共享责任模式、Amazon Lambda 的执行模型的隔离和安全优势、IAM 策略的重要性,以及在保持或提高安全态势的同时实现更快开发周期的机会。亚马逊云科技 鼓励客户拥抱无服务器技术,学习可用资源,亲身体验其优势,同时遵守安全最佳实践,并利用 亚马逊云科技 生态系统提供的强大工具和机制。通往无服务器安全的旅程是一个变革性的过程,使组织能够同时实现敏捷性、可扩展性和强大的安全性,并解决客户从传统架构过渡时的独特需求和关注点。

总结

在亚马逊云科技中,无服务器安全模型提供了一种简化的方式来保护云应用程序,利用细粒度访问控制和最小化基础设施管理开销。通过无服务器架构,保护底层基础设施的责任更多地转移到了亚马逊云科技,允许客户专注于正确的配置和操作实践。这种转变需要改变思维模式,从传统的基于网络的安全模型转向由亚马逊云科技身份和访问管理(IAM)管理的基于API和策略的方法。

亚马逊云科技Lambda服务体现了这种无服务器安全模型,通过使用由Firecracker虚拟化技术驱动的微虚拟机提供了强大的隔离。每个Lambda函数执行都获得自己的隔离环境,确保安全高效的执行,无需担心多线程或资源争用问题。这种方法在强大的隔离和能够重用连接和缓存以优化性能之间达到了平衡。

要有效采用无服务器安全模型,组织需要提升团队的技能,特别是开发人员和安全专业人员。开发人员必须学习编写与应用程序功能相一致的细粒度IAM策略,而安全团队可以在各个层面(如服务控制策略和权限边界)利用预防性和检测性控制来实施防护和治理。

总的来说,无服务器安全模型使组织能够简化安全实践,让它们专注于核心业务目标,同时利用亚马逊云科技强大的安全能力。通过采用这种模型,组织可以加速创新,减少运营开销,并在云中保持强大的安全态势。

亚马逊云科技（Amazon Web Services）是全球云计算的开创者和引领者。提供200多类广泛而深入的云服务，服务全球245个国家和地区的数百万客户。亚马逊云科技致力于成为企业构建和应用生成式AI的首选，通过生成式AI技术栈，提供用于模型训练和推理的基础设施服务、构建生成式AI应用的大模型等工具、以及开箱即用的生成式AI应用。深耕本地、链接全球 – 在中国，亚马逊云科技通过安全、稳定、可信赖的云服务，助力中国企业加速数字化转型和创新，并深度参与全球化市场。