Generative AI for Beginners 第13课精讲如何安全地构建生成式 AI 应用威胁模型、安全测试与红队实战【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners本文基于 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 ATLASAdversarial Threat Landscape for AI SystemsMITRE 公司构建的AI 系统对抗性威胁态势知识库记录对手在真实攻击中使用的战术与技术。ATLAS 参照传统安全领域的 MITRE ATTCK® 框架构建其战术/技术/过程TTP与 ATTCK 互补可供检索、用于规划高级威胁模拟与防御准备。OWASP LLM Top 10OWASP 发布的使用 LLM 的应用中最重要的十大漏洞清单除数据投毒外还特别强调提示注入Prompt Injection攻击者通过精心构造的输入操纵 LLM使其偏离预期行为供应链漏洞Supply Chain Vulnerabilities构成 LLM 应用的组件与软件如 Python 模块、外部数据集本身可能被攻破导致意外结果、注入偏差甚至底层基础设施漏洞过度依赖OverrelianceLLM 会出错、会产生幻觉多起已记录的事件中人们把结果当作事实造成现实世界中的负面后果。此外原文档还提到了 Microsoft 云顾问 Rod Trent 撰写的免费电子书Must Learn AI Security深入讲解这些新兴威胁并给出应对指导。3.3 仓库实证本仓库如何从工程侧防御上述威胁上述威胁要落地防御必须落到代码工程上。当前仓库把第 13 课的安全理念直接实现为可运行的共享工具与安全规范这是本课最有实操价值的部分1安全编码规范docs/SECURITY_GUIDELINES.md 是仓库级的《生成式 AI 应用安全指南》针对教学代码中常见漏洞给出 Do/Dont 对照涵盖八大板块环境变量管理、输入校验与净化、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, timeout30, retries3)强制所有出站 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 系统行为。原文档给出了两类具体评估示例说服类PersuasionMakeMeSay一个 AI 系统能多有效地诱使另一个 AI 说出某个秘密词MakeMePay一个 AI 系统能多有效地说服另一个 AI 捐款Ballot Proposal一个 AI 系统能多大程度影响另一个 AI 对某项政治提案的支持隐写类Steganography隐藏信息传递SteganographyAI 系统能在不被另一 AI 发现的前提下多有效地传递秘密信息Text CompressionAI 系统压缩/解压消息以隐藏秘密信息的能力有多强Schelling PointAI 系统能否在不直接通信的情况下与另一 AI 达成协调4.1 仓库实证把数据净化与输出验证做成可测试的代码原文档讲的数据净化与输出验证两种测试方法在仓库中有直接对应的生产级实现——shared/python/input_validation.py其模块文档字符串就写着保护免受提示注入等基于输入的攻击# 数值输入校验范围检查 类型转换 validate_number_input(5, min_val1, max_val20) # - 5越界或非数字抛 ValueError # 文本输入校验长度上下限 空值策略 validate_text_input(Hello World, max_length100) # - Hello World # 提示词净化面向 LLM 提示的核心防御 safe sanitize_prompt_input(hi scriptalert(1)/script there, max_length1000, strictFalse)sanitize_prompt_input的净化流水线见 shared/python/input_validation.py去除空字节与控制字符保留换行与制表符按危险模式正则清除模板注入{{...}}、变量替换${...}、script标签、javascript:URLstrictTrue时仅保留字母数字、空格与基础标点归一化空白最后做长度上限校验全无效输入时显式抛错。该模块的其余函数同样服务于输出/输入验证validate_email格式校验并小写化、validate_urlrequire_httpsTrue时拒绝非 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 会对所使用数据的隐私与安全构成风险模型可能记住并泄漏训练数据中的敏感信息人名、地址、密码、信用卡号也可能被恶意行为者利用漏洞或偏差进行操纵攻击。原文档给出三条可执行的防护步骤限制共享给 LLM 的数据量与类型只共享达成目的所必需且相关的数据避免分享敏感/机密/个人数据对要共享的数据做匿名化或加密去除或遮蔽身份信息、使用安全通信通道核验 LLM 生成的数据始终检查 LLM 输出的准确性与质量确保不含不想要或不合适的内容报告与告警数据泄露/安全事件警惕 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 红队项目的三条关键洞察范围广泛AI 红队现在同时覆盖安全与负责任的 AIRAI结果。传统红队聚焦安全层面把模型当攻击载体例如窃取底层模型而 AI 系统引入了新型漏洞提示注入、投毒且红队还需探测公平性问题如刻板印象与有害内容如美化暴力。早期发现问题才能优先投入防御资源。恶意与非恶意失败并重AI 红队同时考虑恶意视角与无害视角的失败。例如对新一代 Bing 的红队既探索恶意攻击者如何破坏系统也探索普通用户可能遭遇的问题内容/有害内容——相比只聚焦恶意行为者的传统安全红队AI 红队覆盖更广的人物画像与潜在失败模式。AI 系统的动态性AI 应用持续演化开发者不断适配变化的需求持续红队演练确保持续警惕并适应演化中的风险。需要强调的边界AI 红队不是万能的应视为对 RBAC基于角色的访问控制、全面数据管理等其他控制手段的补充服务于一种采用安全且负责任的 AI 解决方案的整体安全战略——兼顾隐私与安全同时尽量降低侵蚀用户信任的偏差、有害内容与错误信息。8. 知识检验数据完整性与防滥用原文档的自测题维护数据完整性、防止数据被滥用的好做法是什么对数据访问与数据管理实施强角色role-based控制实施并审计数据标注防止数据被误述或滥用确保 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 测试验证行为——这三份工具模块即是本课数据净化 输出验证 数据保护三原则的最小可运行参照实现。【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考