generative-ai-for-beginners 第 13 课实战解读：生成式 AI 应用的安全威胁模型与安全测试方法论

生成式 AI 应用在带来生产力的同时，也把数据中毒、提示注入、供应链攻击、模型过度依赖（幻觉）等全新风险引入了系统攻击面。本文基于《generative-ai-for-beginners》课程第 13 课「保护生成式 AI 应用」（原始文档：13-securing-ai-applications/README.md），系统梳理 AI 语境下的安全定义、威胁与风险分类、四类安全测试方法以及 AI 红队测试实践，并结合本仓库的共享安全工具模块（如 shared/python/input_validation.py、shared/python/env_utils.py、docs/SECURITY_GUIDELINES.md）给出可直接落地的防御编码方案。学完本文，你将具备对生成式 AI 系统进行威胁建模、制定数据治理与红队测试策略、以及在工程代码中实施输入净化与凭据保护的能力。

引言：本课将覆盖的主题

本节内容来自原文档的 Introduction 部分，核心主题如下：

• 在 AI 系统语境下理解「安全」的含义；
• 识别 AI 系统面临的常见风险与威胁；
• 掌握保护 AI 系统的方法与工程考量。

学习目标

完成本节学习后，你将理解：

• 针对 AI 系统的威胁与风险类型；
• 保护 AI 系统的常见方法与实践；
• 安全测试如何帮助规避意外结果、防止用户信任流失。

一句话概括：在生成式 AI 时代，安全不只是一道防线，而是决定产品能否被信任的生存底线。

生成式 AI 语境下的「安全」意味着什么？

随着人工智能（AI）与机器学习（ML）技术日益影响日常生活，我们必须保护的不仅是用（客）户数据，还包括 AI 系统本身。AI/ML 越来越多地被用于支撑高价值决策流程——在这些行业里，一个错误决策可能带来严重后果。原文档给出了三个关键观察：

• AI/ML 的影响力：AI/ML 对日常生活影响巨大，因此保障其安全性已成为刚需；
• 安全挑战：无论是恶作剧者还是组织化攻击团体，AI 产品都可能遭受复杂攻击，需要正式应对；
• 战略性问题：技术行业必须主动解决战略挑战，以确保用户安全与数据安全的长期可持续性。

需要特别强调的是原文档中的一个深层机理：机器学习模型普遍无法区分恶意输入与良性的异常数据。相当一部分训练数据来自未经策划、未经审核的公共数据集，这些数据集允许第三方自由贡献——攻击者根本不需要"攻破"数据集，他们只要合法地往里面写入内容即可。只要数据的结构与格式保持"正确"，低置信度的恶意数据会随着时间演变成高置信度的可信数据。这正是为什么必须确保模型决策所依赖的数据存储的完整性与防护性。

理解 AI 的威胁与风险：数据中毒是头号威胁

就 AI 及相关系统而言，**数据中毒（Data Poisoning）是当前最显著的安全威胁。数据中毒是指某人故意篡改用于训练 AI 的信息，使其产生错误行为。之所以如此危险，是因为业界缺乏标准化的检测与缓解手段，同时又高度依赖不可信、未经策划的公共数据集进行训练。为维护数据完整性、避免缺陷训练流程，追踪数据的来源（origin）与谱系（lineage）**至关重要——否则"垃圾进，垃圾出"（garbage in, garbage out）的定律就会应验，模型性能将受到整体性损害。

原文档给出四类典型的数据中毒手法：

1. 标签翻转（Label Flipping）：在二分类任务中，攻击者故意翻转一小部分训练数据的标签。例如把良性样本标记为恶意，使模型学到错误的关联。
   • 实例：垃圾邮件过滤器因被篡改的标签，把合法邮件误判为垃圾邮件。
2. 特征投毒（Feature Poisoning）：攻击者细微地修改训练数据的特征，以引入偏见或误导模型。
   • 实例：在商品描述中添加无关关键词，从而操纵推荐系统。
3. 数据注入（Data Injection）：向训练集中注入恶意数据以影响模型行为。
   • 实例：引入虚假的用户评价，使情感分析结果产生系统性偏差。
4. 后门攻击（Backdoor Attacks）：攻击者在训练数据中埋入隐蔽模式（后门）。模型学会识别该模式，一旦触发即表现出恶意行为。
   • 实例：用人脸识别系统训练中混入的后门图片，使系统对特定人物产生错误识别。

用 ATLAS 知识库理解真实世界的对抗战术

MITRE 公司构建了 ATLAS（Adversarial Threat Landscape for Artificial-Intelligence Systems，面向 AI 系统的对抗性威胁全景）——一个收录真实世界 AI 攻击所使用战术与技术的知识库。ATLAS 借鉴了 MITRE ATT&CK® 框架的设计，其战术、技术与过程（TTP）与 ATT&CK 互补。正如传统网络安全领域广泛使用 ATT&CK 来规划高级威胁模拟，ATLAS 提供了一套易于检索的 TTP，帮助安全团队提前理解并准备防御新兴攻击。

OWASP LLM Top 10：大语言模型应用的关键脆弱性

开放 Web 应用安全项目（OWASP）发布了针对使用 LLM 的应用程序的 Top 10 关键漏洞清单。除上述数据中毒外，清单还突出强调以下风险：

• 提示注入（Prompt Injection）：攻击者通过精心构造的输入操纵大语言模型，使其脱离预期的行为边界行事；
• 供应链漏洞（Supply Chain Vulnerabilities）：构成 LLM 应用的组件与软件（如 Python 模块、外部数据集）本身可能被攻陷，导致意外结果、引入偏见，甚至在底层基础设施中埋下漏洞；
• 过度依赖（Overreliance）：LLM 会出错并容易产生幻觉，输出不准确甚至不安全的结果。在多起记录在案的案例中，人们把模型输出直接当真，从而引发了现实世界中本可避免的负面后果。

补充阅读提示：微软云布道师 Rod Trent 著有免费电子书《Must Learn AI Security》，对上述及更多新兴 AI 威胁做了深入剖析，可作为延伸学习资料（原文档提供了对应链接，此处不展开）。

AI 系统与 LLM 的安全测试方法

AI 在重塑各行各业的同时也带来数据隐私、偏见、缺乏可解释性以及被滥用等风险。因此，保证 AI 系统"安全且负责任"至关重要——即符合伦理与法律标准，并能被用户与利益相关方信任。

安全测试就是通过识别并利用 AI 系统或 LLM 的漏洞来评估其安全性，可由开发者、用户或第三方审计者执行，取决于测试目的与范围。原文档归纳了四类最常见方法：

• 数据净化（Data Sanitization）：从 AI/LLM 的训练数据或输入中移除或匿名化敏感、隐私信息。通过降低机密或个人数据的暴露面，防止数据泄露与恶意操纵。
• 对抗性测试（Adversarial Testing）：向 AI/LLM 的输入或输出构造并施加对抗样本，评估其在对抗攻击下的鲁棒性与韧性。有助于识别并缓解可能被攻击者利用的漏洞与弱点。
• 模型验证（Model Verification）：验证模型参数或架构的正确性与完整性。通过确保模型受保护、经过认证，帮助检测并防止模型窃取。
• 输出验证（Output Validation）：验证模型输出的质量与可靠性。通过确保输出一致、准确，帮助检测并纠正恶意操纵。

OpenAI 安全评估与红队网络

OpenAI 在其红队网络（Red Teaming Network）计划中设立了一系列安全评估（safety evaluations），用于从多个角度测试 AI 系统的输出行为，以促进 AI 安全研究。评估从简单的问答测试到更复杂的模拟仿真不等，原文档给出了两类代表性样例：

• 说服（Persuasion）类：
  • MakeMeSay：一个 AI 系统能否诱骗另一个 AI 系统说出某个秘密单词？
  • MakeMePay：一个 AI 系统能否说服另一个 AI 系统捐出钱财？
  • Ballot Proposal：一个 AI 系统能否影响另一个 AI 系统对一个政治提案的支持立场？
• 隐写术（Steganography，隐藏消息）类：
  • Steganography：一个 AI 系统能否在不被另一个 AI 系统发现的情况下传递秘密消息？
  • Text Compression：一个 AI 系统能否通过压缩/解压消息来隐藏秘密内容？
  • Schelling Point：一个 AI 系统能否在无直接通信的条件下与另一个 AI 系统达成默契协调？

这类评估的本质是把"对抗意图"量化成可测的基准，为后续的防御投资提供依据。

AI 安全：定义、机遇与挑战

我们必须努力使 AI 系统免遭恶意攻击、滥用或意外后果。原文档指出，这包括采取以下措施以确保 AI 系统的安全、可靠与可信：

• 保障用于训练与运行 AI 模型的数据与算法安全；
• 防止对 AI 系统的未授权访问、篡改或破坏；
• 检测并缓解 AI 系统中的偏见、歧视或伦理问题；
• 确保 AI 决策与行动的问责性、透明度与可解释性；
• 使 AI 系统的目标与价值观和人类社会保持一致。

AI 安全对于保障 AI 系统与数据的完整性、可用性与机密性至关重要，同时也带来了机遇与挑战并存的两面性：

• 机遇：将 AI 纳入网络安全战略——AI 能在识别威胁、缩短响应时间方面发挥关键作用，可帮助自动化并增强对钓鱼、恶意软件、勒索软件等网络攻击的检测与缓解；
• 挑战：AI 也可能被对手用于发动复杂攻击，例如生成虚假或误导性内容、冒充用户、利用 AI 系统的漏洞。因此 AI 开发者负有独特责任：必须设计对滥用具有鲁棒性和韧性的系统。

数据保护：LLM 数据隐私的三道防线

LLM 对其所处理数据的隐私与安全构成风险：它可能从训练数据中记忆并泄露敏感信息（如姓名、地址、密码、信用卡号），也可能被恶意行为者利用其漏洞或偏见进行操纵。对此，原文档建议采取以下步骤：

• 限制与 LLM 共享的数据量与类型：只共享达成预期目的所必需且相关的数据，避免共享敏感、机密或个人数据；对共享数据进行匿名化或加密（例如移除或遮蔽身份信息），并使用安全的通信渠道；
• 核验 LLM 生成的数据：始终检查模型输出内容的准确性与质量，确保不含不需要或不恰当的信息；
• 报告与告警数据泄露/安全事件：对 LLM 的可疑或异常行为保持警觉（如生成无关、不准确、冒犯或有害文本），这些迹象可能意味着数据泄露或安全事件。

在多云环境中，数据安全、治理与合规对任何希望发挥数据与 AI 价值的组织都至关重要。不同类型的数据（结构化、非结构化以及 AI 生成的数据）散布在多个云的不同位置，还需考虑现有及未来的数据安全、治理与 AI 法规。最佳实践包括：选择提供数据保护与隐私能力的云服务或平台、使用数据质量与校验工具排查错误/不一致/异常、借助数据治理与伦理框架确保数据以负责任且透明的方式被使用。

模拟真实世界的威胁：AI 红队测试

模拟真实世界威胁如今被视为构建韧性 AI 系统的标准实践：通过采用类似的工具、战术与过程来识别系统风险并检验防御方的响应能力。

AI 红队测试的实践已经演变为含义更广的活动：它不仅涵盖对安全漏洞的探测，还包括对其他系统故障的探测，例如生成潜在有害内容。AI 系统会带来新风险，而红队测试是理解这些新风险（如提示注入、生成无依据内容）的核心。——微软 AI Red Team

以下三点是塑造微软 AI 红队项目的关键洞见：

1. AI 红队范围的大幅扩展：如今的 AI 红队同时覆盖安全与负责任 AI（RAI）两类产出。传统红队只关注安全维度，把模型当作一种攻击向量（如窃取底层模型）；而 AI 系统引入了全新安全漏洞（如提示注入、投毒），需要特别关注。在安全之外，AI 红队还探测公平性问题（如刻板印象）与有害内容（如美化暴力）。尽早发现这些问题，可使防御投入得到更合理的优先级分配。
2. 恶意与非恶意的故障：AI 红队同时考虑恶意与良性视角下的故障。例如在红队测试新版 Bing 时，不仅研究恶意对手如何破坏系统，也研究普通用户如何会撞上问题内容或有害内容。不同于主要聚焦恶意行为者的传统安全红队，AI 红队要考虑更广泛的角色谱系与潜在故障。
3. AI 系统的动态本质：AI 应用持续演进，开发者需要不断适配变化的需求。持续性的红队测试能够保证对演化风险保持长期警觉并随之调整。

需要强调的是，AI 红队测试并非万能，它应当被看作补充性机制，与角色基于访问控制（RBAC）以及全面的数据管理方案配合使用。它服务于这样一个安全战略：在兼顾隐私与安全的前提下采用安全且负责任的 AI 方案，同时尽量降低偏见、有害内容与误导信息，以免侵蚀用户信心。微软为此提供了系统性的红队规划指南（可参考其对 LLM 及 LLM 应用进行红队规划的方法论），OpenAI 亦运营专门的 AI 红队网络以汇集跨领域安全专家。

把安全落到代码：本仓库的安全工程实践佐证

《generative-ai-for-beginners》不仅仅讲授概念，也在仓库中沉淀了一套可直接复用的安全编码实践，可作为上文各方法论的落地印证。

凭据与配置安全：环境变量校验

原文档强调数据与模型"谁在用、谁能访问"必须受控。仓库为此提供了环境变量工具模块 shared/python/env_utils.py：

• get_required_env(var_name, description=None)：读取必需环境变量，缺失或为空时抛出带提示的 ValueError，避免硬编码密钥或裸用 os.environ[...] 抛 KeyError；
• validate_env_vars(*var_names)：批量校验多个必需变量，一次性报告所有缺失项，返回 {变量名: 值} 映射；
• get_env_with_default(var_name, default)：为可选配置提供默认值。

对应测试见 tests/test_env_utils.py，覆盖"缺失即抛错""空值即抛错""描述信息透传"等用例。完整规范（含 Python/JS 正反例）见 docs/SECURITY_GUIDELINES.md 的「Environment Variable Management」小节。

输入验证与净化：把提示注入挡在入口

提示注入位居 OWASP Top 10 前列。原文档建议通过输入验证来缓解该风险，仓库中的 shared/python/input_validation.py 正是为此设计：

• validate_number_input(value, min_val=1, max_val=100, field_name="number")：把字符串转为范围内整数，越界或非数字即抛 ValueError；
• validate_text_input(value, max_length=500, min_length=1, allow_empty=False, field_name="input")：对文本做长度与空值校验并去空白；
• sanitize_prompt_input(value, max_length=1000, strict=False)：专门针对注入模式做净化——移除空字节与控制字符、模板注入 {{...}}、变量替换 ${...}、<script> 标签及 javascript: 链接；strict=True 时仅保留字母数字、空格与基础标点；超长或全为非法字符时抛错；
• validate_email(...) / validate_url(url, require_https=True)：对邮箱与 URL 做格式校验（URL 默认强制 HTTPS）。

测试用例见 tests/test_input_validation.py，例如验证 "Hello {{system}} world" 中的 {{ 被清除、javascript:alert(1) 被剥离、超长输入抛 "too long" 等。真实课程序例 06-text-generation-apps/python/aoai-app-recipe.py 展示了完整调用链：先 get_required_env 读取 AZURE_OPENAI_API_KEY/AZURE_OPENAI_ENDPOINT，再对用户输入的菜谱数量、食材、过滤条件逐一调用 validate_number_input/validate_text_input，校验失败即中止请求——这正是"数据净化 + 输出验证"在代码层的体现。

HTTP 与 API 调用安全：超时、重试与错误处理

LLM 应用常需发起外部 HTTP 请求，无超时的请求可能永久挂起。仓库的 shared/python/api_utils.py 提供 make_safe_request(url, method="GET", timeout=30, retries=3, ...)，内置超时、raise_for_status() 与重试逻辑；create_openai_client 则以受控方式构造客户端。配套规范还强调：API Key 禁止拼入 URL 查询参数（会泄漏进日志），应使用 Authorization: Bearer 头；错误处理需针对具体异常类型（如限流错误）而非宽泛捕获，且日志中不得打印可能含密钥的完整报错。

文件操作与内容安全

安全指南 docs/SECURITY_GUIDELINES.md 同时覆盖文件操作安全：使用上下文管理器确保文件句柄正确关闭、对用户提供的文件名做路径穿越防护（解析后校验目标仍位于基准目录内）。此外，仓库中前序课程 03-using-generative-ai-responsibly/README.md 讲授的负责任 AI 内容（幻觉、有害内容、公平性），以及模型层/安全系统层/元提示层/用户体验层的分层缓解思路，与本文的 AI 安全目标互为补充——红队测试发现的公平性与有害内容问题，正是靠这些分层防御去收敛的。

上线前检查清单（来自仓库安全规范）

综合 docs/SECURITY_GUIDELINES.md 的 Summary Checklist，部署前请核验：

• [ ] 所有 API Key 均从环境变量读取，无硬编码；
• [ ] 用户输入已做验证与净化（文本、数值、URL、邮箱）；
• [ ] HTTP 请求均设置超时并带重试与错误处理；
• [ ] 文件操作使用上下文管理器，路径穿越已被阻断；
• [ ] 异常按具体类型处理，敏感信息不进入日志；
• [ ] URL 使用前经过校验（默认强制 HTTPS）；
• [ ] AI 的工具/函数调用基于允许列表（allowlist）校验。

知识检查

问题：什么是维护数据完整性、防止滥用的良好方法？

1. 为数据访问与数据管理设置强壮的基于角色的控制；
2. 实施并审计数据标注，防止数据被错误表述或滥用；
3. 确保 AI 基础设施支持内容过滤。

参考答案：A（选项 1）。虽然三个选项都是好建议，但确保为用户分配合适的数据访问权限，将非常有助于防止 LLM 所用数据被操纵与错误表述。这正呼应了前文"RBAC 是红队测试之外的重要补充控制"的论断。

动手挑战

围绕"AI 时代如何治理与保护敏感信息"这一主题展开实践：为你的 AI 应用绘制一份数据流图，标注每一处训练数据与运行时输入的来源与谱系；随后针对最敏感的一类数据，设计并落实"最小共享 + 匿名化/加密 + 访问控制"三件套，并参考本仓库 shared/python 工具族编写对应的单元测试（可对照 tests/conftest.py 中保证仓库根可导入的配置方式运行测试）。完成后可继续学习第 14 课「生成式 AI 应用生命周期」，了解安全如何贯穿 AI 应用的开发、运营与迭代全过程。

总结

生成式 AI 应用的安全不是单一工具可解决的问题，而是威胁建模、数据治理、安全测试与红队演练的组合拳：既要警惕数据中毒（标签翻转、特征投毒、数据注入、后门）这类训练期威胁，也要防御提示注入、供应链漏洞、过度依赖等运行期风险；既要在模型与数据层面做净化与验证，也要在工程代码层面落实凭据保护、输入净化和有界 HTTP 调用。MITRE ATLAS 与 OWASP LLM Top 10 提供了识别威胁的公共语言，OpenAI 与微软的红队实践提供了量化 AI 行为边界的基准，而本仓库的 docs/SECURITY_GUIDELINES.md 与 shared/python 工具族则为落地提供了经过测试验证的参考实现。把安全测试前置到开发生命周期，才能避免意外结果、守住用户信任。