企业官网建设流程全解析

保护生成式 AI 应用安全：generative-ai-for-beginners 第 13 课威胁分析、安全测试与红队实践

【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners

本课围绕"如何为生成式 AI 应用建立安全防线"这一核心主题展开，面向正在跟随 generative-ai-for-beginners 课程构建 AI 应用的开发者。读完本课，你将掌握：AI 系统面临的核心威胁（数据投毒、提示注入等）及其原理、四类主流安全测试方法、数据保护与红队（Red Teaming）实践，以及如何结合本仓库 shared/python 中的安全工具（输入验证、环境变量管理、安全 HTTP 封装）把安全能力落到真实代码中。

生成式 AI 语境下，"安全"意味着什么？

随着 AI/ML 技术日益塑造日常生活，需要保护的不仅是客户数据，还包括 AI 系统本身。AI/ML 越来越多地被用于支撑高价值决策过程——在这些行业里，一个错误决策可能带来严重后果。以下是需要重点考虑的三点：

• AI/ML 的影响面：AI/ML 对日常生活影响显著，保护它们已成为刚需；
• 安全挑战：AI/ML 的普及要求我们保护基于 AI 的产品免受复杂攻击，无论是来自"网络喷子"还是有组织的攻击团体；
• 战略性问题：科技行业必须主动应对战略级挑战，确保客户长期安全与数据安全。

一个容易被忽视的底层事实是：机器学习模型在很大程度上无法区分恶意输入与良性异常数据。训练数据的重要来源是未经整理、未受监管的公开数据集，这些数据集开放给第三方贡献。攻击者无需"攻破"数据集——只要数据集允许自由贡献，他们就能直接参与其中。只要数据的结构与格式保持正确，低置信度的恶意数据会随时间推移演变成高置信度的"可信"数据。

因此，确保模型用于决策的数据存储的完整性与防护，是生成式 AI 安全的第一要务。

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

在 AI 及相关系统语境下，数据投毒（Data Poisoning）是当下最显著的安全威胁。数据投毒指某人故意篡改用于训练 AI 的信息，使其犯错。之所以猖獗，一方面缺乏标准化的检测与缓解方法，另一方面训练严重依赖不受信或未整理的公开数据集。要保持数据完整性、防止训练过程被污染，必须追踪数据的来源与谱系（lineage），否则"垃圾进、垃圾出"（garbage in, garbage out）的古老定律就会应验，导致模型性能受损。

以下是数据投毒影响模型的四类典型方式：

行业知识库：MITRE ATLAS 与 OWASP LLM Top 10

为帮助安全从业者系统化理解这些威胁，业内已有两个重要知识库：

• MITRE ATLAS（Adversarial Threat Landscape for Artificial-Intelligence Systems）：由 MITRE 公司创建，是记录真实世界中针对 AI 系统攻击的战术与技术的知识库。ATLAS 以 MITRE ATT&CK® 框架为蓝本建模，其战术、技术与过程（TTP）与 ATT&CK 互补。正如传统网络安全中广泛使用 ATT&CK 规划高级威胁模拟场景，ATLAS 提供了一个易于检索的 TTP 集合，帮助理解并准备防御新兴攻击。
• OWASP LLM Top 10：由开放式 Web 应用安全项目（OWASP）发布，列出了使用 LLM 的应用中最关键的十大漏洞。除了上述数据投毒，榜单还突出强调了以下威胁：
  • 提示注入（Prompt Injection）：攻击者通过精心构造的输入操纵大语言模型，使其偏离预期行为；
  • 供应链漏洞（Supply Chain Vulnerabilities）：构成 LLM 所用应用的组件与软件（如 Python 模块或外部数据集）本身可能被攻陷，导致意外结果、引入偏见，甚至在底层基础设施中产生漏洞；
  • 过度依赖（Overreliance）：LLM 会犯错并容易产生幻觉，输出不准确甚至不安全的结果。在多个有据可查的案例中，人们直接采信了模型输出，导致真实世界中意想不到的负面后果。

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

AI 在带来机会的同时也带来显著挑战与风险，如数据隐私、偏见、缺乏可解释性以及潜在滥用。因此，确保 AI 系统安全且负责任——即符合伦理与法律标准、能被用户和利益相关者信任——至关重要。

安全测试（Security Testing）就是通过识别并利用 AI 系统或 LLM 的漏洞来评估其安全性的过程。执行者可以是开发者、用户或第三方审计者，取决于测试的目的与范围。以下是 AI 系统与 LLM 最常见的四类安全测试方法：

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

作为 AI 系统领域的领先者，OpenAI 在其红队网络（Red Teaming Network）计划中建立了一系列安全评估（safety evaluations），用于测试 AI 系统的输出，为 AI 安全做出贡献。评估范围从简单的问答测试到更复杂的模拟，例如：

• 说服力（Persuasion）：MakeMeSay（AI 系统能多好地诱骗另一个 AI 系统说出秘密单词）、MakeMePay（能多好地说服另一个 AI 系统捐款）、Ballot Proposal（能多好地影响另一个 AI 系统对某政治提案的支持）；
• 隐写术（Steganography，隐藏消息）：Steganography（AI 系统能多好地传递秘密消息而不被另一个 AI 系统发现）、Text Compression（通过压缩/解压消息隐藏秘密）、Schelling Point（AI 系统能在不直接通信的情况下多好地与其他系统协调）。

AI 安全（AI Security）

保护 AI 系统免受恶意攻击、滥用或意外后果，包括采取步骤确保 AI 系统的安全、可靠与可信赖，例如：

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

AI 安全对确保 AI 系统与数据的完整性、可用性和机密性至关重要。它同时带来机会与挑战：

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

数据保护（Data Protection）

LLM 可能对其所用数据的隐私与安全构成风险。例如，LLM 可能记忆并泄露训练数据中的敏感信息，如个人姓名、地址、密码或信用卡号；也可能被想利用其漏洞或偏见的恶意行为者操纵或攻击。你可以采取以下步骤保护与 LLM 一起使用的数据：

• 限制与 LLM 共享的数据量与类型：只共享对预期目的必要且相关的数据，避免共享敏感、机密或个人数据；对共享数据进行匿名化或加密（如移除或掩蔽可识别信息），并使用安全的通信渠道；
• 验证 LLM 生成的数据：始终检查 LLM 输出的准确性与质量，确保不含不需要或不恰当的信息；
• 报告并告警数据泄露或安全事件：警惕 LLM 的任何可疑或异常行为，如生成不相关、不准确、冒犯性或有害的文本——这可能是数据泄露或安全事件的征兆。

在多云环境中，数据安全、治理与合规对任何希望发挥数据与 AI 力量的组织都至关重要。你需要跨多个云、在不同位置保护和治理不同类型的数据（结构化、非结构化以及 AI 生成的数据），并考虑现有与未来的数据安全、治理及 AI 法规。建议采纳如下最佳实践：使用提供数据保护与隐私功能的云服务或平台；使用数据质量与验证工具检查错误、不一致或异常；使用数据治理与伦理框架确保数据以负责任、透明的方式被使用。

模拟真实威胁：AI 红队（AI Red Teaming）

模拟真实世界威胁现已被视为构建弹性 AI 系统的标准实践：使用类似的工具、战术与过程来识别系统风险，并测试防御者的响应。

AI 红队实践已经演进出更广泛的含义：它不仅包括探查安全漏洞，还包括探查其他系统失效，例如潜在有害内容的生成。AI 系统带来新风险，而红队是理解这些新风险（如提示注入、产生无依据内容）的核心。—— Microsoft AI Red Team building future of safer AI

塑造 Microsoft AI Red Team 计划的三个关键洞见：

1. AI 红队范围广泛：AI 红队现在同时涵盖安全与负责任 AI（RAI，Responsible AI）两类成果。传统红队聚焦安全层面，把模型视为攻击向量（例如窃取底层模型）；而 AI 系统引入的新安全漏洞（如提示注入、投毒）需要特别关注。除安全之外，AI 红队还探查公平性问题（如刻板印象）与有害内容（如美化暴力）。尽早识别这些问题，可以优先安排防御投资。
2. 恶意与良性失效都要考虑：AI 红队同时考虑恶意与良性视角的失效。例如在为新版 Bing 做红队时，不仅探查恶意对手如何颠覆系统，也关注普通用户可能遇到问题或有害内容。不同于主要聚焦恶意行为者的传统安全红队，AI 红队涵盖更广泛的角色与潜在失效模式。
3. AI 系统的动态性：AI 应用持续演进，在 LLM 应用中开发者不断适应变化的需求。持续红队确保对不断变化的风险保持持续警觉与适应。

需要明确：AI 红队并非包罗万象，应被视为对基于角色的访问控制（RBAC）与全面数据管理方案等额外控制手段的补充。它的目的是补充一套聚焦于部署安全且负责任的 AI 解决方案的安全策略，兼顾隐私与安全，同时力求减少偏见、有害内容和可能侵蚀用户信心的错误信息。

从文档到代码：本仓库中的安全实践落地

第 13 课的概念在 generative-ai-for-beginners 仓库中并非只停留在理论层面。仓库提供了可复用的安全工具与安全基线文档，可以直接支撑本课各项原则的工程化落地。

环境变量管理：密钥绝不入代码

shared/python/env_utils.py 提供了安全获取与校验环境变量的工具：get_required_env 在缺失变量时抛出带说明的ValueError，validate_env_vars 可一次校验多个必需变量，get_env_with_default 支持带默认值读取。这与仓库安全基线 docs/SECURITY_GUIDELINES.md 的要求一致：所有 API Key 必须从环境变量加载并校验，严禁硬编码密钥。对应实现可参考各课程的示例应用，例如 06-text-generation-apps/python/githubmodels-app.py 从环境变量读取AZURE_INFERENCE_CREDENTIAL与AZURE_INFERENCE_ENDPOINT。

输入验证与清洗：提示注入的第一道防线

针对 OWASP Top 10 中的提示注入威胁，shared/python/input_validation.py 提供了专门面向 LLM 提示场景的清洗函数 sanitize_prompt_input：

• 去除 NUL 字节与控制字符；
• 通过正则移除危险模式：模板注入{{...}}、变量替换${...}、<script>标签、javascript:协议；
• 支持strict严格模式，仅保留字母数字、空格与基础标点；
• 规范化空白并限制最大长度（默认 1000 字符），超长或全为非法字符时抛出ValueError。

此外 validate_text_input 与 validate_number_input 负责长度、范围、空值等基础校验。配套测试 tests/test_input_validation.py 验证了这些函数的完整行为：普通文本原样保留、模板注入与变量替换被移除、script 标签与javascript:被清除、超长输入抛错等。这正是本课"输出验证"与"对抗测试"思想在工程上的具象化——恶意输入在进入提示模板之前就被拦截。

安全调用链：超时、重试与凭据校验

shared/python/api_utils.py 封装了安全 HTTP 调用：make_safe_request 强制要求超时（默认 30 秒）并带重试（默认 3 次）与raise_for_status错误传播；create_openai_client 与 create_azure_openai_client 在创建客户端时强制校验密钥/端点存在，缺失即抛出明确错误，并统一走 v1 端点。测试 tests/test_api_utils.py 验证了超时参数透传、失败重试 3 次、缺失密钥/端点时抛出ValueError等行为。这对应本课的"输出验证"与整体安全基线——所有对外请求必须设超时、异常必须精准处理、敏感信息不得进入日志。

知识检查

维护数据完整性并防止滥用的好方法是什么？

1. 对数据访问与数据管理实施强健的基于角色的控制
2. 实施并审计数据标注，防止数据误表示或滥用
3. 确保你的 AI 基础设施支持内容过滤

答案：1。虽然三个建议都很好，但确保为用户分配正确的数据访问权限，将在很大程度上防止 LLM 所用数据被操纵和误表示。这也呼应了本课红队部分的结论：红队只是补充手段，真正的防线是 RBAC 与全面的数据治理。

进一步探索

完成本课后，你可以：

• 深入阅读 docs/SECURITY_GUIDELINES.md，其中还覆盖了 API Key 不落入 URL、HTTP 超时、精准异常处理、防止日志泄露敏感信息、路径穿越防护、函数调用白名单等检查清单，可在部署前逐项自检；
• 运行tests/目录下的测试（如pytest tests/test_input_validation.py）验证输入清洗与客户端配置工具的行为，将安全验证固化为自动化测试；
• 进入本课程第 14 课，学习 生成式 AI 应用生命周期，把安全实践融入从设计、开发到部署、运维的完整生命周期中。

安全不是一次性动作，而是贯穿 AI 应用全生命周期的持续过程：从数据采集与训练时的完整性守护，到输入侧的清洗与验证，再到部署后的红队演练与输出监控，每一层防线都不可或缺。

【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners