AI安全最佳实践：AI云原生开发安全评估矩阵（下）

上篇小李哥带大家一起了解了什么是AI应用云原生开发安全评估矩阵，并且介绍了利用该矩阵如何确定我们云上AI应用的安全评估范围，接下来我们将继续本系列的下篇，基于该安全评估矩阵设计和实施我们系统应具备的安全控制。

优先考虑的安全控制

确定了生成式 AI 负载的安全范围后，接下来就需要在确保安全的前提下，加速业务推进。让我们看看有哪些关键安全事项值得优先关注。

治理与合规 + 法律与隐私

在消费级应用（Scope 1）和企业级应用（Scope 2）中，大家需要特别关注服务条款、许可证、数据主权及其他法律相关问题 。明确企业的数据管理要求，并确保与法律和采购部门密切合作，以评估这些要求如何适用于 Scope 1 或 Scope 2 的应用程序。数据治理至关重要，企业可以基于现有的数据治理策略，将其扩展到生成式 AI 负载。例如，可以制定一项政策，禁止在 Scope 1 应用中输入个人身份信息（PII）、机密数据或专有数据。

如果第三方模型 已经具备所需的数据和功能，那么 Scope 1 或 Scope 2 可能满足业务需求。但如果企业希望对自身业务数据进行总结、关联分析、生成新的洞察，或是自动化重复性任务，则可能需要选择 Scope 3、4 或 5。

Scope 3：使用预训练模型（如 Amazon Bedrock 提供的模型）构建自定义 AI 应用
Scope 4：使用企业数据对模型进行微调，生成特定于企业需求的增强模型
Scope 5：从零开始训练全新的自研模型

在 Scope 3、4 和 5 中，业务数据可能用于模型的训练、微调或作为输出的一部分 。因此，企业必须明确数据分类和数据类型。例如，Scope 3 可能利用 RAG（检索增强生成） 机制，仅在推理时查询企业数据，而不是将数据直接嵌入模型中。相比之下，Scope 4 和 Scope 5 可能会直接在训练或微调过程中使用企业数据，从而影响模型的安全性和数据治理要求。

此外，法律团队需要关注EULA（最终用户许可协议）、TOS（服务条款） ，以及其他合同要求。尤其是在 Scope 5（自研模型）场景下，企业需要制定自己的服务条款 ，明确对外提供模型时的法律约束。同时，如果企业业务涉及GDPR（欧盟通用数据保护条例） ，则需要谨慎考虑"被遗忘权"或数据删除的相关影响。目前，唯一彻底删除训练数据的方法是重新训练模型，这一过程不仅昂贵，还可能在部分训练数据较小时显得不够现实。

风险管理

虽然生成式 AI 应用看起来和传统软件相似，但其自由输入 的交互方式使其面临额外的安全挑战。企业需要识别适用于自身 AI 负载的风险，并制定合理的缓解策略。

常见的风险管理方式包括风险评估 和威胁建模 。对于 Scope 1 和 Scope 2，重点是评估第三方供应商的安全风险 ，并明确企业作为用户需要承担的安全责任。而对于 Scope 3、4 和 5，企业需要自行实施威胁建模，以识别特定的生成式 AI 安全风险。

例如，LLM 面临的一项独特安全威胁是提示词注入（Prompt Injection） ，即通过精心构造的输入，使模型生成意外或有害的响应。这种攻击可能导致数据泄露、系统访问控制失效，甚至被用于恶意操纵信息。近年来，NIST、MITRE 和 OWASP 都发布了生成式 AI 安全指南 ，其中提示词注入被列为首要安全风险。这一威胁类似于 SQL 注入、JSON/XML 注入等传统攻击方式，因此网络安全专家可以借鉴已有经验来防范。

生成式 AI 引入了全新的安全挑战，企业必须调整现有的网络安全实践 ，以适应这些新威胁。这需要安全团队与 AI 开发团队密切合作，共同分析生成式 AI 应用的威胁模型，并定义最佳安全实践。

安全控制

安全控制是实现合规、策略落地和风险缓解的关键。让我们以身份和访问管理（IAM）为例，说明如何在 Scope 3-5 级别的 AI 负载中实施安全控制。

在推理（Inference）过程中，Scope 3-5 使用的基础模型是不可变的 。API 仅接受输入，并返回模型推理结果。模型在发布后是静态的，不会存储新的数据，也无法直接调整推理结果。因此，访问控制成为关键的安全防护手段。

现代数据库通常支持表级、行级、列级甚至字段级的访问控制 ，但生成式 AI 目前无法实现同样精细的访问管理 。例如，在 LLM 中，词向量（Embedding） 是模型训练过程中形成的数学表示，用于描述数据之间的关系。但目前无法在向量数据库级别对特定的 embedding 设置访问权限 ，这意味着一旦用户获得了模型的访问权限，他们就可以访问所有训练数据的推理结果。

因此，在 Scope 4（微调）或 Scope 5（自研模型）中，企业应通过应用层安全策略 来增强访问控制。例如，使用 RAG 数据流，让模型从外部数据库检索数据，而不是直接嵌入数据到模型中，从而在不暴露敏感数据的情况下提供个性化推理结果。

如果企业使用 Amazon Bedrock 在 Scope 4 进行模型微调，或者在 Scope 5 训练自研模型，那么可以通过IAM 策略控制对推理端点的访问。例如：

html 复制代码

{
	"Version": "2012-10-17",
	"Statement": {
		"Sid": "AllowInference",
		"Effect": "Allow",
		"Action": [
			"bedrock:InvokeModel"
		],
		"Resource": "arn:aws:bedrock:*::<foundation-model>/<model-id-of-model-to-allow>
	}
}

这条 IAM 规则确保只有特定用户或应用 可以调用 AI 模型的推理 API，从而防止未经授权的访问。

在大多数场景下，应用层 会调用 Amazon Bedrock 端点 来与模型进行交互。这个前端应用可以使用身份解决方案（如 Amazon Cognito 或 AWS IAM Identity Center ）来进行用户身份验证和授权 ，并根据角色、属性和用户群体 限制特定操作和对某些数据的访问权限。例如，应用程序可以基于用户的授权选择不同的模型 。或者如果应用程序使用 RAG（检索增强生成） 机制来查询外部数据源 ，为生成式 AI 响应提供即时数据 （例如 Amazon Kendra 或 Amazon OpenSearch Serverless ），那么可以使用授权层 来过滤访问权限，以确保用户只能访问符合其角色和权限的数据。由此可见，身份和访问管理（IAM） 原则与企业开发的其他应用程序基本相同，只是需要考虑生成式 AI 负载的独特能力和架构特性，以确保安全性。

弹性架构（Resilience）

最后，可用性是信息安全 C.I.A. 三要素（机密性、完整性、可用性） 之一。构建高可用的应用 对于满足企业的业务连续性要求至关重要。对于 Scope 1 和 Scope 2 ，企业应了解供应商的可用性策略 是否符合业务需求，并慎重考虑底层模型、API 或应用层不可用时对业务的影响。此外，还要评估复杂的提示词和模型响应是否会影响使用配额 ，以及应用的计费成本。

对于 Scope 3、4 和 5 ，企业需要设置合理的超时时间 以适应复杂的提示词和推理过程。此外，还需要注意模型定义的字符输入限制 ，并采用指数回退（Backoff and Retry） 以及熔断模式（Circuit Breaker Patterns） 等容错设计，以保证良好的用户体验。在使用 向量数据库 时，建议采用高可用配置 和 灾难恢复计划，以增强系统对不同故障模式的容错能力。

在推理和训练管道中，实例灵活性（Instance Flexibility） 是另一个关键架构考虑因素，特别是对于高优先级任务 ，企业可能需要预留计算资源 或 预置实例 。如果使用 Amazon Bedrock 或 SageMaker 等托管服务，建议在多区域部署策略 中验证不同 AWS 区域的可用性和功能一致性 。同样，在 Scope 4 和 Scope 5 任务的跨区域支持 方面，企业需要考虑微调或训练数据的跨区域可用性 。例如，在 Scope 5 （自研模型）场景下，若使用 SageMaker 进行模型训练 ，可以使用检查点（Checkpoint） 保存训练进度，以便在必要时从最后的检查点恢复训练，而不必从零开始。

大家可以参考 AWS Resilience Hub 以及 Well-Architected Framework 中的 可靠性支柱（Reliability Pillar） 和 运营卓越支柱（Operational Excellence Pillar），以优化应用的弹性架构设计。