目录

切入点

确定范围

确定优先事项

治理与合规性以及法律和隐私

风险管理

控制措施

韧性

生成式人工智能（Generative AI）激发了企业的想象力，并不断推动全球各行各业各种规模企业的客户体验转型。在拥有数十亿个参数的大型语言模型（LLM）和转换器神经网络的推动下，人工智能的功能实现了飞跃，为新型工作效率提升、创意功能等打开了大门。

随着企业开始评估生成式人工智能的应用并为其员工和顾客采用这一功能，网络安全从业人员必须针对这项日新月异的技术，快速评测其风险、治理和控制措施。作为 Amazon Web Services（AWS）的安全负责部门，我们与 AWS 规模最大、最复杂的客户合作，客户经常会就生成式人工智能的趋势、最佳实践、快速演变的形势以及相关的安全和隐私影响征求我们的意见。本着这种精神，我们将介绍一些关键策略，供您用来加速自己的生成式人工智能安全之旅。

这篇博文是关于确保生成式人工智能安全的系列文章中的第一篇，文中建立了一个思维模型，帮助您根据所部署的生成式人工智能工作负载类型来应对风险和安全影响。然后，我们将面向安全领导者和从业人员，重点介绍在确保生成式人工智能工作负载安全时需要重点对待的关键注意事项。后续的博文将深入探讨开发满足客户安全要求的生成式人工智能解决方案，对生成式人工智能应用程序进行威胁建模的最佳实践，用于评估合规性和隐私注意事项的方法，并探讨使用生成式人工智能来改善网络安全运维的方法。

切入点

与任何新兴技术一样，为该技术奠定坚实的基础对于帮助您了解相关的范围、风险、安全和合规性要求至关重要。 如需了解有关生成式人工智能基础的更多信息，我们建议您首先详细了解什么是生成式人工智能、这个领域中的独有术语和细微之处，并探索企业如何使用生成式人工智能为客户进行创新的示例。

如果您刚刚开始了解或采用生成式人工智能，您可能会觉得这需要一套全新的安全规程。对于生成式人工智能工作负载，尽管存在独特的安全注意事项，但好的方面是，其核心是另一种数据驱动型计算工作负载，许多相同的安全方案可以沿袭下来。 实际上，如果您多年来一直在投资于云服务网络安全最佳实践，并采纳了 Steve 介绍的十大安全事项、Well-Architected Framework 的安全性支柱以及 Well-Architected Machine Learning Lens 等资料中介绍的规范性建议，那么您已经踏上了正轨！

与任何其它工作负载一样，对于生成式人工智能工作负载，身份和访问管理、数据保护、隐私与合规性、应用程序安全和威胁建模等核心安全规程仍然至关重要。例如，如果您的生成式人工智能应用程序正在访问数据库，那么您需要知道数据库有哪些数据分类、如何保护这些数据、如何监控威胁以及如何管理访问权限。但是，在重视长期遵循的安全实践之外，同样至关重要的是，了解生成式人工智能工作负载带来的独特风险和其它安全注意事项。这篇博文重点介绍了几个安全因素，其中既有新的主题，也有您已熟悉的内容，供您借鉴。

考虑到这一点，我们来讨论第一步：范围界定。

确定范围

在企业决定推进生成式人工智能解决方案之后，作为安全领导者或从业者，现在您应该做什么？ 与任何安全工作一样，您必须了解您肩负的确保安全的任务范围。 根据应用场景，您可以选择托管服务，让服务提供商承担更多的服务和模型管理责任，也可以选择构建自己的服务和模型。

我们来看看如何在 AWS 云中使用各种生成式人工智能解决方案。AWS 将安全性放在首要位置，我们相信为客户提供合适的工具来完成工作至关重要。例如，您可以通过由 API 驱动的无服务器 Amazon Bedrock，使用由 AI21 Labs、Anthropic、Cohere、Meta、stability.ai 提供的易于使用的预训练基础模型（FM）和 Amazon Titan。 Amazon SageMaker JumpStart 为您提供额外的灵活性，同时仍使用预训练 FM，帮助您安全地加速人工智能之旅。您还可以在 Amazon SageMaker 上构建和训练自己的模型。或许您可以计划通过 Web 界面或 API 来使用消费者生成式人工智能应用程序，例如聊天机器人，或者嵌入到企业已采购的商业企业应用程序中的生成式人工智能功能。每个这些服务产品都采用了不同的基础设施、软件、访问方法和数据模型，因此会导致不同的安全注意事项。 为保持一致性，我们将这些服务产品按照逻辑进行分类，并将这种分类称为范围。

为了帮助您简化确定安全性范围的工作，我们创建了一个矩阵，将关键安全原则汇总在一起，您可以方便地根据自己选择的生成式人工智能解决方案考虑应使用哪些准则。 我们将此矩阵称为生成式人工智能安全性范围界定矩阵，如图 1 所示。

图 1：生成式人工智能安全性范围界定矩阵

第一步是确定您的应用场景适合哪个范围。范围按照 1 到 5 编号，表示责任从最小到最大。

购买生成式人工智能：

范围 1：消费者应用程序 – 企业使用免费或付费的公共第三方生成式人工智能服务。在此范围中，您既不拥有、也无法查看训练数据或模型，并且无法对其进行修改或扩充。您按照提供商的服务条款，调用 API 或直接使用应用程序。

例如，员工与生成式人工智能聊天应用程序进行交互，为即将到来的营销活动发掘创意。范围 2：企业应用程序 – 企业使用第三方企业应用程序，其中嵌入生成式人工智能功能，并且企业与供应商建立了业务关系。

示例：您使用嵌入生成式人工智能功能的第三方企业日程安排应用程序，帮助起草会议议程。

构建生成式人工智能：

范围 3：预训练模型 – 企业使用现有的第三方生成式人工智能基础模型构建自己的应用程序。您可以通过应用程序编程接口（API），将模型直接集成到工作负载中。

示例：您通过 Amazon Bedrock API，使用 Anthropic Claude 基础模型构建了一个应用程序，用于创建客户支持聊天机器人。范围 4：微调模型 – 企业使用特定于自身业务的数据，对现有的第三方生成式人工智能基础模型进行微调，从而完善现有的模型，生成专门针对您的工作负载进行了增强的新模型。

示例：您使用 API 访问基础模型，为营销团队构建应用程序，使他们能够构建特定于您的产品和服务的营销材料。范围 5：自行训练模型 – 企业使用您拥有或获取的数据，从头开始构建和训练生成式人工智能模型。您负责模型的各个方面。

示例：企业希望创建一个模型，使用特定于行业的深度数据独家进行训练，从而创建一个全新的 LLM，可以向该行业的公司进行授权。

在生成式人工智能安全性范围界定矩阵中，我们确定了五个安全准则，涵盖不同类型的生成式人工智能解决方案。根据生成式人工智能应用程序的范围，每个安全准则的独特要求也会随之改变。 通过确定所部署的生成式人工智能应用程序的范围，安全团队可以快速确定重点优先事项，并评测每项安全准则的范围。

接下来我们将探讨各项安全准则，并考虑范围界定对安全要求有哪些影响。

治理与合规性 – 强化企业能力同时尽可能降低风险所需的政策、程序和报告。法律和隐私 – 使用或创建生成式人工智能解决方案时所需遵循的具体监管、法律和隐私要求。风险管理 – 识别生成式人工智能解决方案的潜在威胁和建议的缓解措施。控制措施 – 实施用于缓解风险的安全控制措施。韧性 – 如何设计生成式人工智能解决方案的架构，以保持可用性并满足业务 SLA。

在我们的确保生成式人工智能安全系列博客中，我们将参考生成式人工智能安全性范围界定矩阵，来帮助您了解根据人工智能部署的范围变化，各种安全要求和建议会如何随之改变。 我们建议您在自己的内部流程（例如，采购、评估和安全架构范围界定）中，采用和参考生成式人工智能安全性范围界定矩阵。

确定优先事项

确定工作负载的范围后，现在您需要能够快速而安全地推动业务向前发展。让我们来探讨一些您应该优先考虑的机会示例。

治理与合规性以及法律和隐私

图 2：治理与合规性

对于现成的消费者应用程序（范围 1）和现成的企业应用程序（范围 2），您必须特别注意服务条款、许可、数据主权和其它法律披露。 列出与企业数据管理要求相关的重要注意事项，如果企业有法律和采购部门，请务必与他们密切合作。评估这些要求如何应用到范围 1 或 2 应用程序。数据治理至关重要，现有的可靠数据治理策略可以继续使用，并扩展到生成式人工智能工作负载。列出企业的风险偏好以及您希望为范围 1 和 2 应用程序实现的安全态势，并实施策略，指定仅可使用合适的数据类型和数据分类。例如，您可以选择创建一条策略，在使用范围 1 应用程序时，禁止使用个人身份信息（PII）、机密或专有数据。

如果第三方模型具有您需要的所有数据和功能，则范围 1 和范围 2 应用程序可能符合您的要求。但是，如果您看重的是总结、关联和解析自己的业务数据，然后生成新见解或者自动执行重复性任务，则需要部署范围 3、4 或 5 中的应用程序。例如，企业可能会选择使用预训练模型（范围 3）。您也许会想更进一步，创建一个使用企业自己数据的第三方模型（例如 Amazon Titan）版本，这就是微调（范围 4）。或者您可以从头开始创建一个全新的第一方模型，用您提供的数据进行训练（范围 5）。

在范围 3、4 和 5 中，您的数据可用于模型的训练或微调，也可以用作输出的一部分。您必须明确解决方案将访问的资产的数据分类和数据类型。例如，在 Amazon Bedrock 代理的帮助下，范围 3 的解决方案可以对检索增强生成（RAG）提供的数据使用过滤机制，作为提示的输入。RAG 提供了一种替代方法，您可以将查询的数据作为提示的一部分，用来进行训练或微调。然后，这种方法将扩充 LLM 的上下文，以提供补全内容和响应，您的业务数据也可以用在响应中，而无需通过微调或训练就将数据直接嵌入到模型本身中。请参阅图 3 的示例数据流程图，其中演示了如何通过 RAG 在生成式人工智能的提示和响应中使用客户数据。

图 3：检索增强生成（RAG）

另一方面，在范围 4 和 5 中，您必须针对在微调或训练模型中使用的最敏感级别的数据分类，对修改后的模型进行分类。 然后，您的模型对训练所用的数据，复现该数据分类。例如，如果您在微调或训练模型时提供 PII，则新模型将包含 PII。当前，没有任何机制可以根据授权轻松过滤模型的输出，用户有可能检索原本无权查看的数据。 这一点要作为关键要点：您可以围绕模型构建应用程序，以便在 RAG 数据流中对业务数据实施过滤控制，这样可以提供更细粒度的数据安全，而无需将敏感数据直接放置在模型中。

图 4：法律和隐私

从法律的角度来看，务必要了解服务提供商的最终用户许可协议（EULA、End-User License Agreement）、服务条款（TOS，Terms Of Service），以及在范围 1 至 4 中使用其服务所必需的任何其它合同协议。对于范围 5，您的法律团队应针对模型在外部的任何使用，提供自己的服务合同条款。此外，对于范围 3 和范围 4，请确保验证服务提供商关于使用服务的法律条款，以及模型提供商关于在服务中使用模型的法律条款。

此外，如果欧盟的通用数据保护条例（GDPR，General Data Protection Regulation）的“删除权”或“被遗忘权”要求适用于您的企业，请考虑隐私问题。在训练或微调模型时，请谨慎考虑使用可能需要应要求删除的数据的影响。从模型中删除数据的唯一完全有效的方法是，从训练集中删除数据并训练模型的新版本。当删除的数据只占总训练数据的一小部分时，这种做法不切实际，而且根据模型的大小，成本可能非常高。

风险管理

图 5：风险管理

虽然支持人工智能的应用程序的操作、行为和感受可能会类似于非人工智能应用程序，但由于与 LLM 的交互形式没有限制，因此一定要采取额外的审查和防护机制。务必要确定您的生成式人工智能工作负载中会有哪些风险，以及如何采取措施来缓解这些风险。

确定风险的方法有很多，其中两种常见的机制是风险评测和威胁建模。对于范围 1 和 2，您需要评测第三方提供商的风险，以明确可能源自其服务的风险，以及他们如何缓解或管理应由其负责的风险。同样，您还必须明确作为该服务的使用者，您所承担的风险管理责任。

对于范围 3、4 和 5（实施威胁建模），虽然我们会在今后的博文中深入探讨特定威胁以及如何对生成式人工智能应用程序进行威胁建模，不过现在我们可以举一个 LLM 独有威胁的例子。威胁行为者可能会使用提示注入之类的技术：这是一种精心设计的输入，可导致 LLM 以意想不到或不应有的方式做出响应。这种威胁可用于提取特征（特征是用于训练机器学习（ML）模型的数据的特性或属性）、进行中伤、获取内部系统的访问权限等。近几个月，NIST、MITRE 和 OWASP 发布了确保人工智能和 LLM 解决方案安全的指南。在 MITRE 和 OWASP 发布的方法中，提示注入（模型规避）是列出的头号威胁。提示注入威胁听起来好像很新鲜，但许多网络安全专业人员都很熟悉。它本质上是注入攻击的演变，例如 SQL 注入、JSON 或 XML 注入或者命令行注入，许多从业者已经适应了处理这些攻击。

生成式人工智能工作负载中新兴的威胁向量，为威胁建模和整体风险管理实践带来了新的疆域。如前所述，您现在采用的网络安全实践也同样适用于这个领域，但您必须进行调整以应对这个领域中的独特威胁。请与开发团队以及企业中创建生成式人工智能应用程序的其他关键利益相关者深入合作，以了解细微之处，充分建模威胁并定义最佳实践。

控制措施

图 6：控制措施

控制措施帮助我们贯彻合规性、政策和安全要求，以降低风险。我们来看一个重视安全控制措施的示例：身份和访问管理。在设定的背景中，推理（模型根据输入生成输出的过程）期间，第一方或第三方基础模型（范围 3 到 5）是不可变的。连接到模型的 API 接受输入并返回输出。模型有版本控制，在发布后保持不变。 就其本身而言，模型自身无法存储新数据、随着时间的推移调整结果或直接整合外部数据来源。如果没有模型之外的数据处理功能的干预，模型将不会存储新数据，也不会发生突变。

现代化数据库和基础模型都有一个使用实体的身份进行查询的概念。传统数据库可以实施表级别、行级别、列级别甚至元素级别的安全控制。另一方面，基础模型目前不允许对其中可能包含的特定嵌入的精细访问控制。在 LLM 中，嵌入是模型在训练期间创建的数学表示形式，用于表示每个对象（例如文字、声音和图形），并帮助描述对象的上下文以及与其它对象的关系。实体要么被允许访问完整模型及其生成的推论，要么就完全不允许访问。它不能在向量数据库中的特定嵌入级别限制访问权限。换而言之，在当今的技术中，当您授予某个实体直接访问模型的权限时，您就授予了该实体对训练模型所用全部数据的权限。在访问时，信息会朝两个方向流动：提示和上下文信息从用户通过应用程序流向模型，补全内容从模型流回应用程序，向用户提供推理响应。当您授权对模型的访问时，您同时也隐式授权了这两个数据流的进行，而这两个数据流中的一个或两个可能会包含机密数据。

例如，假设您的企业在 Amazon Bedrock 之上构建了范围 4 应用程序，您在其中对基础模型进行了微调，或者构建了范围 5 应用程序，您使用自己的业务数据训练模型。AWS Identity and Access Management（IAM）策略向您的应用程序授予调用特定模型的权限。该策略无法限制对模型中数据子集的访问。对于 IAM，在直接与模型交互时，您的权限仅限于模型访问。

{

"Version": "2012-10-17",

"Statement": {

"Sid": "AllowInference",

"Effect": "Allow",

"Action": [

"bedrock:InvokeModel"

],

"Resource": "arn:aws:bedrock:*::<foundation-model>/<model-id-of-model-to-allow>

}

}

在这种情况下，您应该如何来实施最低权限？ 在大多数情况下，应用程序层将调用 Amazon Bedrock 端点与模型进行交互。此前端应用程序可以使用身份解决方案，例如 Amazon Cognito 或 AWS IAM Identity Center，对用户进行身份验证和授权，并根据角色、属性和用户社区相应地限制特定操作和对某些数据的访问。例如，应用程序可以根据用户的授权选择模型。 或者，您的应用程序可以使用 RAG，通过查询外部数据来源，使用 Amazon Kendra 或 Amazon OpenSearch 无服务器等服务，为生成式人工智能响应提供即时数据。 在这种情况下，您将使用授权层，根据用户的角色和授权过滤对特定内容的访问。如您所见，身份和访问管理原则与企业开发的任何其它应用程序相同，但您必须考虑生成式人工智能工作负载的独特功能和架构注意事项。

韧性

图 7：韧性

最后，正如 C.I.A. 三要素中所指出的，可用性是安全的关键组成部分。构建韧性应用程序对于满足企业的可用性和业务连续性要求至关重要。对于范围 1 和 2，您应该了解提供商的可用性如何与企业的需求和期望保持一致。仔细考虑如果底层模型、API 或表示层不可用，中断会对业务造成哪些影响。此外，还要考虑复杂的提示和补全内容会如何影响使用限额，或者应用程序可能对账单产生什么影响。

对于范围 3、4 和 5，请确保设置适当的超时，以应对复杂的提示和补全内容。您可能还需要查看提示输入大小，以满足模型定义的分配字符数限制。还要考虑韧性设计的现有最佳实践，例如回退和重试以及断路器模式，以实现所需的用户体验。使用向量数据库时，建议使用高可用性配置并制定灾难恢复计划，以确保面对不同故障模式时的韧性。

除了可能要为极其关键的工作负载预留或预置计算资源之外，推理和训练模型管道所用实例的灵活性也是重要的架构注意事项。如果使用 Amazon Bedrock 或 SageMaker 等托管服务，在实施多区域部署策略时，必须验证 AWS 区域的可用性和功能同等性。同样，对于范围 4 和 5 工作负载的多区域支持，您必须考虑微调或训练数据的跨区域可用性。如果您使用 SageMaker 训练范围 5 的模型，请在训练模型时使用检查点保存进度。这让您在有必要时，可以从上次保存的检查点恢复训练。