Amazon CodeWhisperer 是一款AI驱动的编码助手,它受过各种数据的训练,包括Amazon和开源代码。随着CodeWhisperer定制的推出,客户可以创建定制资源。该定制是通过使用客户的私有代码仓库来扩充CodeWhisperer而产生的。这使得组织特定的代码建议能够针对客户自身的内部API、库和框架进行定制。
当我们开始设计CodeWhisperer定制时,我们考虑了指导原则、宗旨应该是什么。客户信任是头等重要的,但这带来了新的问题。我们如何以最好的方式赢得客户对这一依赖客户敏感信息的功能的信任?我们如何恰当地保护这些数据,以便客户能够安全地利用我们为他们推出的先进功能?
在考虑这些问题时,我们分析了几个设计原则。不组合或并行使用客户的数据是很重要的,换句话说,我们需要对每个客户的数据进行隔离存储。此外,我们还希望将数据处理限制在单租户计算中。我们的意思是,只要有可能,对数据本身的访问应该在短期和非共享计算上完成。我们考虑的另一个原则是如何防止未经授权访问客户数据。在整个亚马逊云科技中,我们构建系统的目的是避免在正常服务运营过程中混淆客户数据,并减轻未经授权的用户获得客户数据的意外访问风险。
这些设计原则指向了一组可通过亚马逊云科技本地技术提供的安全控制。我们需要提供数据和计算隔离,并在过程的每一步都减轻混淆副手风险。在本篇博客文章中,我们将考虑如何利用亚马逊云科技最佳实践来解决每一个安全考虑。我们首先将考虑数据在管理员管理定制资源时的流动。接下来,我们将概述当开发人员从他们的集成开发环境 (IDE) 向给定的定制发送运行时请求时数据的交互。
在阅读本篇博客文章时,您将了解我们如何在安全至关重要的前提下开发了CodeWhisperer定制。我们也希望您能受到启发,在您自己的应用程序中利用同样的亚马逊云科技技术。
上图描述了数据在管理员管理定制以及开发人员从其IDE使用定制时的流动情况。
组织管理员负责管理其定制。为了使CodeWhisperer能够生成这些资源,管理员需要提供对其私有代码仓库的访问权限。CodeWhisperer使用亚马逊云科技密钥管理服务(Amazon Web Services KMS)对所有定制数据进行加密,管理员还可以选择配置自己的配置文件级加密密钥。根据管理员在亚马逊云科技控制台中担任的角色,CodeWhisperer代表用户访问和引入所引用的代码数据。
在定制管理期间,数据存储有两种形式:
在以任何形式持久化数据时,要应用的最佳安全控制措施是加密。通过对数据进行加密,只有拥有访问加密密钥的实体才能查看或使用该数据。例如,当加密后的数据存储在Amazon S3中时,拥有存储桶访问权限的用户可以看到数据的存在,但除非他们还拥有访问加密密钥的权限,否则将无法查看内容。
在CodeWhisperer中,使用具有客户级加密上下文元数据的KMS密钥在Amazon S3中对长期客户数据存储进行加密隔离。加密上下文提供了进一步的保护,即使未经授权的用户获得了密钥访问权限也无法访问内容。它还可以防止意外的跨客户数据访问,因为上下文值与特定客户的身份相关联。如果只有KMS密钥但没有这个上下文,就像拥有参加私密会议的实体邀请但不知道活动的口令一样。
CodeWhisperer允许客户为亚马逊云科技在加密其数据时使用的KMS密钥进行配置。此外,我们还通过为特定内部组件分配有范围的 IAM角色来限制对Amazon S3数据的编程访问权限(即服务使用权限)。通过这样做,为每个密钥创建的KMS授权被严格限制在需要访问数据以进行服务运营的服务中。
当需要短期持久化数据时,我们也会对其进行加密。CodeWhisperer利用客户端加密和服务所有的密钥对临时磁盘进行加密。数据只在进程执行时存储在磁盘上,并且在进程终止之前,会明确删除任何磁盘上的数据存储,对任何故障进行警报。为了避免客户数据相互交叉,每个无服务器计算实例都是为特定资源的特定操作而启动的。没有两个客户资源由同一工作流或无服务器函数执行进行处理。
在创建或激活定制时,客户数据将在一系列无服务器环境中处理。大部分处理都是通过Amazon Step Functions工作流进行的 - 由Amazon Lambda、Amazon Batch(在Amazon Fargate上)和嵌套的Step Functions任务组成。这些无服务器任务都是为系统中的给定作业实例化的。换句话说,计算不会在两个操作之间共享或重用。
在这里可以观察到的一般原则是重用现有的亚马逊云科技服务。通过利用这些各种无服务器选项,我们不必花费过多的非差异化开发工作来保证计算使用的安全性。相反,我们继承了这些服务中内置的安全控制措施,将精力集中在为CodeWhisperer启用独特的定制功能上。
在构建多租户服务时,不仅要关注数据在预期情况下如何访问的问题,还要考虑意外情况和恶意情况下如何访问的问题。这就是混淆副手缓解措施的概念所在。
为了防止在数据引入期间发生跨客户数据访问,我们采取了以下两种缓解措施:
但是,一旦数据进入了CodeWhisperer服务边界,我们就不能就此止步。由于CodeWhisperer建立在基于微服务的架构之上,只有预期的内部组件才能与各自的消费者和依赖项进行交互。为了防止未经授权的用户调用处理客户数据的这些内部服务,我们利用基于账户的允许列表。每个内部服务都限制了一组有需要调用该服务API的CodeWhisperer所有服务账户。
为了进一步保护这些服务中的数据,我们对所有Amazon S3数据使用客户管理的密钥加密。如果客户没有明确提供自己的密钥,我们将使用CodeWhisperer所有的KMS密钥进行相同的加密。
使用KMS密钥需要授权。这些授权为指定的实体提供了使用密钥读取或写入数据的能力。为了降低不当使用这些授权的风险,我们采取了一些控制措施。为了限制拥有顶级授权权限的实体的数量,所有授权都由单个微服务管理。为了将授权的使用限制在预期的CodeWhisperer工作流中,授权会在CodeWhisperer操作完成后立即被撤销,其生命周期将降至最小。
在管理员创建、激活和授予对定制资源的访问权限之后,开发人员可以在他们的IDE中选择该定制。一旦调用,CodeWhisperer会捕获用户的IDE代码上下文并将其发送到CodeWhisperer。该请求还包括他们的身份验证令牌和目标定制资源的引用。在成功进行身份验证和授权之后,CodeWhisperer会响应定制的建议。
在定制调用期间不会使用任何持久数据存储。这些调用是无状态的,这意味着请求中传递的任何数据都不会在请求的生命周期之外持久化。为了减轻请求生命周期内的任何数据风险,我们通过IAM Identity Center对用户进行身份验证和授权。
由于定制与公司数据相关联,并且它的建议可能会复制此类数据,因此对资源访问进行严格授权至关重要。CodeWhisperer通过Amazon Verified Permissions策略对单个用户针对定制资源进行授权。客户管理员在亚马逊云科技控制台中将用户和组分配给特定定制时,会配置这些策略。(注意:CodeWhisperer代表我们的客户管理这些Verified Permissions策略,这就是为什么管理员在控制台中看不到这些策略的原因。)服务会内部解析策略到构成定制的对应服务所拥有的资源。
CodeWhisperer调用的主要计算是运行生成模型的实例。生成模型在单个物理主机上多租户运行,即每个模型在主机的专用计算资源上运行,而该主机有多个此类资源。将每个请求绑定到特定的计算资源,可以确保推理调用无法与任何其他正在进行的推理进行交互或通信。
所有其他运行时处理都在Amazon Elastic Container Service(Amazon ECS)容器实例上的独立线程上以Fargate技术执行。在给定的CodeWhisperer服务中,对用户数据的计算不会跨越一个线程以上。
正如我们在定制管理时讨论的那样,混淆副手缓解措施的目的是降低未经授权的实体意外和恶意访问客户数据的风险。为了在使用定制时解决这一问题,我们通过Verified Permissions权限限制客户只能访问与其所选定制相关的内部资源。我们进一步通过为每个推理请求配置会话策略来保护免受混淆副手风险。该会话策略将权限范围缩小到特定的资源名称,该名称在内部进行管理,未对外公开。
在生成式AI时代,数据是提高最终应用效率的主要区分因素。CodeWhisperer基础模型受过各种数据的训练。这使得CodeWhisperer能够从基线出发提高开发人员的生产力,并利用软件开发中通常包含的开源包。为了进一步提高开发人员的生产力,客户可以利用CodeWhisperer定制功能引入自己的私有数据,并为开发人员提供量身定制的建议。
CodeWhisperer定制从一开始就以安全性和客户信任为重点。我们内置了以下安全不变量:
我们希望您和我们一样对这一生成式AI功能感到兴奋!立即试用 CodeWhisperer定制: https://docs.aws.amazon.com/codewhisperer/latest/userguide/customizations.html