Generative AI for Beginners 第13课精讲：如何安全地构建生成式 AI 应用（威胁模型、安全测试与红队实战）

本文基于 generative-ai-for-beginners 课程的第 13 课《Securing Your Generative AI Applications》（含阿拉伯语译本 translations/ar/13-securing-ai-applications/README.md）展开，系统讲解生成式 AI 应用的安全威胁模型（数据投毒、提示注入、供应链漏洞）、四类安全测试方法、AI 红队实践，并结合当前仓库中 docs/SECURITY_GUIDELINES.md 与 shared/python/ 下的真实安全工具代码，给出可复制落地的防护实现。读完后，你将能够识别面向 LLM 应用的主要攻击面，并掌握输入净化、密钥管理、安全请求封装等可直接用于自己项目的工程化防御手段。

1. 课程导读与学习目标

本课属于 "21 Lessons, Get Started Building with Generative AI" 课程体系中的安全专题（英文原文 13-securing-ai-applications/README.md），覆盖三大主题：

• AI 系统语境下的"安全"到底意味着什么；
• 面向 AI 系统的常见风险与威胁（数据投毒、提示注入、供应链漏洞等）；
• 保护 AI 系统的方法与工程考量（安全测试、数据保护、红队演练）。

学习完成后，应能回答三个问题：AI 系统面临哪些威胁和风险？业界通行的 AI 安全防护方法有哪些？如何通过安全测试防止意外输出、避免用户信任流失？

2. 什么是生成式 AI 语境下的"安全"

随着 AI 与机器学习技术日益深入日常生活，保护对象不再只是客户数据，AI 系统本身也成了保护对象。AI/ML 越来越多地支撑高价值决策流程（金融、医疗、工业等），错误决策可能带来严重后果。原文档归纳了三个必须考虑的关键点：

• AI/ML 的影响面：AI/ML 对日常生活影响巨大，保护它们已属刚需；
• 安全挑战：必须认真防护基于 AI 的产品，抵御来自个人攻击者乃至有组织团伙的精细化攻击；
• 战略问题：技术行业必须主动应对战略层面的挑战，才能确保客户与数据的长期安全。

原文档还指出了一个 LLM 特有的结构性弱点：机器学习模型基本无法区分"恶意输入"和"无害的异常数据"。大量训练数据来自未经策划、无人审核的公开数据集，且允许第三方自由贡献——攻击者根本不需要"攻破"数据集，直接向其中贡献恶意内容即可。只要数据的结构与格式正确，低可信度的恶意数据会随时间推移逐渐变成高可信度的"信任数据"。这正是为什么模型用于决策的数据存储（data store）的完整性与保护至关重要。

延伸阅读：本课程第 3 课 03-using-generative-ai-responsibly/README.md 从"负责任的 AI"角度讨论了幻觉、有害内容与公平性，与本课的安全视角互为补充。

3. 理解 AI 的威胁与风险：以数据投毒为核心

3.1 数据投毒（Data Poisoning）的四种典型手法

原文档指出，数据投毒是当前 AI 领域最显著的安全威胁：有人刻意篡改用于训练 AI 的信息，使模型产生错误行为。其根源在于缺乏标准化的检测与缓解手段，同时我们又依赖不可信、未策划的公开数据集进行训练。要保持数据完整性、防止训练过程被污染，必须追踪数据的来源与血缘（origin 与 lineage），否则"垃圾进、垃圾出"（garbage in, garbage out）的旧话将应验，模型性能必然受损。

原文档列举了四种数据投毒对模型的具体影响方式：

攻击类型	手法描述	典型例子
标签翻转（Label Flipping）	在二分类任务中，对手刻意翻转一小部分训练数据的标签，使模型学到错误关联	垃圾邮件过滤器因被篡改的标签把合法邮件判为垃圾邮件
特征投毒（Feature Poisoning）	攻击者对训练数据中的特征做微小修改，注入偏差或误导模型	在商品描述中加入无关关键词，操纵推荐系统
数据注入（Data Injection）	向训练集注入恶意数据以影响模型行为	引入虚假用户评论，扭曲情感分析结果
后门攻击（Backdoor Attacks）	对手在训练数据中植入隐藏模式（后门），模型学会识别该模式，被触发时行为恶化为攻击性	用带后门的图片训练的人脸识别系统，对特定人物误识别

3.2 威胁知识库：MITRE ATLAS 与 OWASP LLM Top 10

原文档推荐了两个权威知识资源用于威胁认知与防御规划（此处按规范仅列名称，不附外部链接）：

• MITRE ATLAS（Adversarial Threat Landscape for AI Systems）：MITRE 公司构建的"AI 系统对抗性威胁态势"知识库，记录对手在真实攻击中使用的战术与技术。ATLAS 参照传统安全领域的 MITRE ATT&CK® 框架构建，其战术/技术/过程（TTP）与 ATT&CK 互补，可供检索、用于规划高级威胁模拟与防御准备。
• OWASP LLM Top 10：OWASP 发布的"使用 LLM 的应用中最重要的十大漏洞"清单，除数据投毒外还特别强调：
  • 提示注入（Prompt Injection）：攻击者通过精心构造的输入操纵 LLM，使其偏离预期行为；
  • 供应链漏洞（Supply Chain Vulnerabilities）：构成 LLM 应用的组件与软件（如 Python 模块、外部数据集）本身可能被攻破，导致意外结果、注入偏差甚至底层基础设施漏洞；
  • 过度依赖（Overreliance）：LLM 会出错、会产生幻觉，多起已记录的事件中人们把结果当作事实，造成现实世界中的负面后果。

此外，原文档还提到了 Microsoft 云顾问 Rod Trent 撰写的免费电子书 Must Learn AI Security，深入讲解这些新兴威胁并给出应对指导。

3.3 仓库实证：本仓库如何从"工程侧"防御上述威胁

上述威胁要落地防御，必须落到代码工程上。当前仓库把第 13 课的安全理念直接实现为可运行的共享工具与安全规范，这是本课最有实操价值的部分：

（1）安全编码规范：docs/SECURITY_GUIDELINES.md 是仓库级的《生成式 AI 应用安全指南》，针对教学代码中常见漏洞给出 Do/Don't 对照，涵盖八大板块：环境变量管理、输入校验与净化、API 安全、提示注入防护、HTTP 请求安全、错误处理、文件操作、代码质量工具，并附有部署前检查清单（API 密钥全部来自环境变量、用户输入已校验净化、HTTP 请求带超时、防止路径穿越、异常精确处理、不记录敏感数据、AI 发起的函数调用需过白名单等）。

（2）环境变量管理：docs/SECURITY_GUIDELINES.md 明确指出"用 os.environ[] 直接取值且不做校验"和"硬编码密钥"是反面做法；正确姿势是用 getenv 加校验。仓库的 shared/python/env_utils.py 将其实现为三个函数：

• get_required_env(var_name, description)：读取必填环境变量，缺失时抛出带提示信息的 ValueError，引导用户检查 .env 文件；
• validate_env_vars(*var_names)：批量校验多个环境变量（如 AZURE_OPENAI_ENDPOINT、AZURE_OPENAI_API_KEY），一次性报告所有缺失项；
• get_env_with_default(var_name, default)：带默认值读取（如模型名）。

（3）安全请求封装：shared/python/api_utils.py 中的 make_safe_request(url, method, timeout=30, retries=3) 强制所有出站 HTTP 请求携带超时与重试逻辑，避免"无超时挂死"这一 docs/SECURITY_GUIDELINES.md 中点名的反模式；create_azure_openai_client() 则演示了"先校验 AZURE_OPENAI_ENDPOINT / AZURE_OPENAI_API_KEY 存在，再构造指向 <endpoint>/openai/v1/ 的客户端"的规范流程——密钥只从环境变量读取、绝不出现在 URL 查询参数中（指南中专门警示 ?key=${apiKey} 写法会让密钥泄漏进日志）。

（4）静态检查兜底：pyproject.toml 中 Ruff 的 lint 规则启用了 "S" 类别（flake8-bandit 安全规则），即把安全静态检查纳入了日常 lint 流程；dev 依赖（black、isort、mypy、ruff、pytest）在 pyproject.toml 的 [project.optional-dependencies] 与 requirements.txt 中均有对应。安全改进的推进过程记录在 docs/ENHANCED_FEATURES_ROADMAP.md：已修复硬编码 SECRET_KEY、缺失的环境变量校验、不安全的函数调用、文件句柄泄漏、缺失的请求超时等问题，并规划了限流示例、API 密钥轮换、内容安全集成等后续增强——这与原文档"持续防御"的思路完全一致。

4. AI 系统与 LLM 的安全测试

原文档指出：AI 在带来新可能的同时，也带来数据隐私、偏差、缺乏可解释性、被滥用等风险，因此必须确保 AI 系统"安全且负责任"——遵守伦理与法律标准，可被用户与利益相关方信任。安全测试就是识别并利用系统漏洞来评估其安全性的过程，可由开发者、用户或第三方审计人员执行。原文档列出了四种最常见的安全测试方法：

• 数据净化（Data Sanitization）：移除或匿名化训练数据/输入中的敏感与私人信息，通过降低机密或人身数据的暴露面，防止数据泄漏与恶意操纵；
• 对抗测试（Adversarial Testing）：生成并施加对抗样本到 AI 系统或 LLM 的输入/输出上，评估其鲁棒性，帮助发现可被攻击者利用的弱点；
• 模型验证（Model Verification）：校验模型参数或架构的正确性与完整性，确保模型受到保护与身份认证，防止模型被盗（model stealing）；
• 输出验证（Output Validation）：校验输出的质量与可靠性，确保输出一致、准确，从而发现并纠正恶意操纵。

OpenAI 在其"红队网络"（red teaming network）计划中设置了一系列安全评估（safety evaluations），用于从不同角度测试 AI 系统行为。原文档给出了两类具体评估示例：

说服类（Persuasion）

• MakeMeSay：一个 AI 系统能多有效地诱使另一个 AI 说出某个秘密词？
• MakeMePay：一个 AI 系统能多有效地说服另一个 AI 捐款？
• Ballot Proposal：一个 AI 系统能多大程度影响另一个 AI 对某项政治提案的支持？

隐写类（Steganography，隐藏信息传递）

• Steganography：AI 系统能在不被另一 AI 发现的前提下多有效地传递秘密信息？
• Text Compression：AI 系统压缩/解压消息以隐藏秘密信息的能力有多强？
• Schelling Point：AI 系统能否在不直接通信的情况下与另一 AI 达成协调？

4.1 仓库实证：把"数据净化"与"输出验证"做成可测试的代码

原文档讲的"数据净化"与"输出验证"两种测试方法，在仓库中有直接对应的生产级实现——shared/python/input_validation.py，其模块文档字符串就写着"保护免受提示注入等基于输入的攻击"：

# 数值输入校验：范围检查 + 类型转换
validate_number_input("5", min_val=1, max_val=20)   # -> 5；越界或非数字抛 ValueError

# 文本输入校验：长度上下限 + 空值策略
validate_text_input("Hello World", max_length=100)   # -> "Hello World"

# 提示词净化：面向 LLM 提示的核心防御
safe = sanitize_prompt_input("hi <script>alert(1)</script> there", max_length=1000, strict=False)

sanitize_prompt_input 的净化流水线（见 shared/python/input_validation.py）：

1. 去除空字节与控制字符（保留换行与制表符）；
2. 按危险模式正则清除模板注入（{{...}}）、变量替换（${...}）、<script> 标签、javascript: URL；
3. strict=True 时仅保留字母数字、空格与基础标点；
4. 归一化空白，最后做长度上限校验，全无效输入时显式抛错。

该模块的其余函数同样服务于"输出/输入验证"：validate_email（格式校验并小写化）、validate_url（require_https=True 时拒绝非 HTTPS 地址，防止中间人风险）。这些行为均有自动化测试佐证：tests/test_input_validation.py 用 pytest 覆盖了模板注入剥离、<script> 标签剥离、javascript: URL 剥离、超长输入拒绝、非法 URL 拒绝等场景——例如 test_removes_template_injection 断言 sanitize_prompt_input("Hello {{system}} world") 的结果中不再含 {{/}}。测试运行方式由 pyproject.toml 的 [tool.pytest.ini_options] 配置（testpaths = ["tests"]），pip install -e ".[dev]" 后执行 pytest 即可复现。

对照 docs/SECURITY_GUIDELINES.md 中"提示注入防护"一节的完整方案，防御是分层组合拳：输入净化（sanitize_prompt_input）+ 结构化消息（system 与 user 角色分离，明确限定"只回答烹饪相关问题"这类边界）+ 服务商内置内容过滤。

5. AI 安全：目标、机会与挑战

原文档强调：保护 AI 系统免受恶意攻击、滥用与意外后果至关重要，具体措施包括：

• 保护用于训练和运行 AI 模型的数据与算法；
• 防止对 AI 系统的未授权访问、操纵或破坏；
• 检测并缓解 AI 系统中的偏差、歧视与伦理问题；
• 确保 AI 决策与行为可追责、透明、可解释；
• 使 AI 系统的目标与价值观同人类和社会对齐。

AI 安全直接关系到 AI 系统及其数据的完整性、可用性与机密性。原文档归纳了一对"机会与挑战"：

• 机会：把 AI 纳入网络安全战略，可显著提升威胁识别与响应速度——AI 能帮助自动化检测和缓解钓鱼、恶意软件、勒索软件等网络攻击；
• 挑战：AI 也可能被对手用于发起高级攻击，如生成虚假/误导性内容、冒充用户、利用 AI 系统自身漏洞。因此 AI 开发者负有特殊责任：设计强健、抗滥用的系统。

6. 数据保护：面向 LLM 的三条准则与多云治理

LLM 会对所使用数据的隐私与安全构成风险：模型可能记住并泄漏训练数据中的敏感信息（人名、地址、密码、信用卡号），也可能被恶意行为者利用漏洞或偏差进行操纵攻击。原文档给出三条可执行的防护步骤：

1. 限制共享给 LLM 的数据量与类型：只共享达成目的所必需且相关的数据，避免分享敏感/机密/个人数据；对要共享的数据做匿名化或加密（去除或遮蔽身份信息、使用安全通信通道）；
2. 核验 LLM 生成的数据：始终检查 LLM 输出的准确性与质量，确保不含不想要或不合适的内容；
3. 报告与告警数据泄露/安全事件：警惕 LLM 的任何可疑或异常行为（生成无关、不准确、冒犯性或有害文本），这可能是数据泄露或安全事件的信号。

在组织层面，数据的安全、治理与合规在多云环境中尤为关键：需要跨云、跨位置治理结构化、非结构化与 AI 生成数据，并兼顾现行与未来的监管要求。原文档建议的最佳实践：

• 使用提供数据保护与隐私特性的云服务/平台；
• 使用数据质量与校验工具检查错误、不一致与异常；
• 采用数据治理与伦理框架，确保数据被负责任、透明地使用。

对应到仓库工程实践：第 6 节的"匿名化输入"与第 4 节的输入净化同源于 shared/python/input_validation.py；"报告与告警"则对应 docs/SECURITY_GUIDELINES.md 中"错误处理"一节的日志规范——只记录安全信息（如状态码），绝不把可能包含 API 密钥/令牌的完整异常写入日志。

7. 模拟真实威胁：AI 红队

模拟真实威胁已成为构建强健 AI 系统的标准实践：采用与对手相似的工具、战术与流程（TTP）来识别系统风险、检验防御方的响应。原文档引用了 Microsoft AI Red Team 的观点——AI 红队的含义已经扩展：不仅探测安全漏洞，还探测其他系统失败模式（如生成潜在有害内容）；提示注入、生成无依据（ungrounded）内容等新型风险，正是红队要理解的核心。

原文档总结了塑造 Microsoft AI 红队项目的三条关键洞察：

1. 范围广泛：AI 红队现在同时覆盖安全与"负责任的 AI（RAI）"结果。传统红队聚焦安全层面（把模型当攻击载体，例如窃取底层模型），而 AI 系统引入了新型漏洞（提示注入、投毒），且红队还需探测公平性问题（如刻板印象）与有害内容（如美化暴力）。早期发现问题才能优先投入防御资源。
2. 恶意与非恶意失败并重：AI 红队同时考虑恶意视角与无害视角的失败。例如对新一代 Bing 的红队，既探索恶意攻击者如何破坏系统，也探索普通用户可能遭遇的问题内容/有害内容——相比只聚焦恶意行为者的传统安全红队，AI 红队覆盖更广的人物画像与潜在失败模式。
3. AI 系统的动态性：AI 应用持续演化，开发者不断适配变化的需求；持续红队演练确保持续警惕并适应演化中的风险。

需要强调的边界：AI 红队不是万能的，应视为对 RBAC（基于角色的访问控制）、全面数据管理等其他控制手段的补充，服务于一种"采用安全且负责任的 AI 解决方案"的整体安全战略——兼顾隐私与安全，同时尽量降低侵蚀用户信任的偏差、有害内容与错误信息。

8. 知识检验：数据完整性与防滥用

原文档的自测题：维护数据完整性、防止数据被滥用的好做法是什么？

1. 对数据访问与数据管理实施强角色（role-based）控制；
2. 实施并审计数据标注，防止数据被误述或滥用；
3. 确保 AI 基础设施支持内容过滤。

答案：1。三条建议都优秀，但确保给用户分配合适的数据访问权限，对防止 LLM 所用数据被操纵与误述最立竿见影——这也呼应了第 6 节的数据治理与仓库 docs/SECURITY_GUIDELINES.md 中"密钥与环境配置最小化暴露"的原则。

9. 进阶挑战与后续学习

• 挑战题：深入研究 AI 时代如何治理与保护敏感信息（原文档推荐 Microsoft 官方训练路径 "Purview: Protect and Govern Information for AI" 作为延伸阅读方向）。
• 下一课：第 14 课 14-the-generative-ai-application-lifecycle/README.md 将讲解生成式 AI 应用的生命周期（LLMOps），安全是其中的常驻环节。
• 仓库内动手路线：先通读 docs/SECURITY_GUIDELINES.md 的部署前检查清单，再对照 shared/python/input_validation.py、shared/python/api_utils.py、shared/python/env_utils.py 的实现，最后运行 tests/ 目录下的 pytest 测试验证行为——这三份工具模块即是本课"数据净化 + 输出验证 + 数据保护"三原则的最小可运行参照实现。