# 8.1 纵深防御原则

纵深防御（Defense in Depth）是安全领域的核心原则，在 LLM 安全中同样适用。

## 8.1.1 纵深防御概念

纵深防御通过多层独立的安全措施，确保单一防护失效时整体安全不被突破。

**层级示意**

```mermaid
flowchart TB
    subgraph "防御层级"
    A["网络层防护"] --> B["应用层防护"]
    B --> C["输入验证层"]
    C --> D["模型层防护"]
    D --> E["输出审核层"]
    E --> F["监控响应层"]
    end
```

图 8-1：纵深防御概念流程图

**核心理念**

| 原则   | 描述           |
| ---- | ------------ |
| 多层防护 | 每层都提供独立的安全保障 |
| 独立失效 | 一层失效不影响其他层   |
| 互补机制 | 不同层使用不同检测技术  |
| 假设失败 | 假设任何一层可能被突破  |

> **为什么必须“纵深”**：安全不是可以单独装进系统的某个功能模块——它和**可靠性、可维护性、可扩展性**一样，是系统的**非功能属性（non-functional property）**，由架构、流程、运维多方面共同决定。这意味着无法靠“加一个安全组件”来一次性解决，只能通过分层、冗余、持续验证逐步累积。这也是把“安全开发生命周期”（8.4）与“纵深防御”放在同一章的原因：前者保证过程证据，后者保证运行时容错。

## 8.1.2 LLM 安全防御层次

针对 LLM 应用的纵深防御架构：

```mermaid
flowchart TB
    subgraph "LLM 纵深防御"
    L1["第一层：边界防护<br/>WAF、API 网关、速率限制"]
    L2["第二层：输入安全<br/>注入检测、格式验证、内容过滤"]
    L3["第三层：上下文安全<br/>系统提示加固、来源标记"]
    L4["第四层：模型安全<br/>安全对齐、能力限制"]
    L5["第五层：工具安全<br/>权限控制、参数验证"]
    L6["第六层：输出安全<br/>内容审核、敏感过滤"]
    L7["第七层：运营安全<br/>监控、审计、响应"]

    L1 --> L2 --> L3 --> L4 --> L5 --> L6 --> L7
    end
```

图 8-2：LLM 安全防御层次架构图

## 8.1.3 各层防护详解

**边界防护层**

```
防护措施：
- Web 应用防火墙（WAF）
- API 网关安全策略
- DDoS 防护
- IP 白名单/黑名单
- 速率限制
```

**输入安全层**

```
防护措施：
- 提示注入检测
- 格式验证
- 长度限制
- 编码规范化
- 恶意内容过滤
```

> \[!TIP] 开源工具参考：[LLM Guard](https://github.com/protectai/llm-guard) 提供开箱即用的输入扫描器（注入检测、有害内容、PII、越狱等）；[NeMo Guardrails](https://github.com/NVIDIA/NeMo-Guardrails) 支持通过可编程“护栏”对输入进行话题控制与安全过滤。

**上下文安全层**

```
防护措施：
- 系统提示强化
- 用户/数据来源标记
- 上下文隔离
- 会话安全管理
```

**模型安全层**

```
防护措施：
- 安全对齐的模型
- 能力限制
- 行为监控
- 模型版本控制
```

> \[!TIP] 开源工具参考：[Llama Guard](https://github.com/meta-llama/PurpleLlama) 是 Meta 开源的安全分类模型系列。当前官方公开的最新主线模型已到 **Llama Guard 4**；较早的 Llama Guard 3 / 3.2 仍可作为多语言与轻量化部署的参考。可对输入提示和输出响应进行安全判定，适合作为模型层的独立安全检查组件。

**工具安全层**

```
防护措施：
- 最小权限
- 参数验证
- 操作确认
- 返回值检查
```

**输出安全层**

```
防护措施：
- 有害内容检测
- 敏感信息过滤
- 格式验证
- 幻觉检测
```

> \[!TIP] 开源工具参考：[Microsoft Presidio](https://github.com/microsoft/presidio) 提供 PII 识别与脱敏能力，可部署在输出侧对模型响应进行敏感信息过滤；LLM Guard 同样提供输出扫描模块（有害内容、PII、相关性验证等）。

**运营安全层**

```
防护措施：
- 实时监控
- 日志审计
- 异常告警
- 事件响应
```

## 8.1.4 防御组合策略

不同威胁需要多层协同防护：

**提示注入防护**

| 层级   | 措施     |
| ---- | ------ |
| 输入层  | 注入模式检测 |
| 上下文层 | 来源标记区分 |
| 模型层  | 安全对齐抵抗 |
| 输出层  | 异常行为过滤 |

**数据泄露防护**

| 层级  | 措施        |
| --- | --------- |
| 输入层 | 过滤信息提取请求  |
| 模型层 | 限制敏感信息复现  |
| 输出层 | PII 检测和脱敏 |
| 运营层 | 泄露事件监控    |

## 8.1.5 层间冗余设计

关键防护应在多层实施，避免单点失效：

```mermaid
flowchart LR
    A["恶意输入"] --> B["输入层过滤"]
    B --> |绕过| C["模型层拒绝"]
    C --> |绕过| D["输出层过滤"]
    D --> |绕过| E["监控告警"]

    B -.-> |"80% 拦截"| X["安全"]
    C -.-> |"15% 拦截"| X
    D -.-> |"4% 拦截"| X
    E -.-> |"1% 响应"| X
```

图 8-3：层间冗余设计流程图

即使每层只有部分有效，多层组合可以大幅提高整体安全性。

## 8.1.6 动态防御

纵深防御不是静态的，需要持续演进：

```mermaid
flowchart TB
    A["威胁情报"] --> B["防御策略更新"]
    B --> C["规则库更新"]
    C --> D["系统加固"]
    D --> E["效果评估"]
    E --> A
```

图 8-4：动态防御流程图

**动态调整原则**

* 根据新威胁调整防护策略
* 基于监控数据优化规则
* 定期进行安全评估
* 持续改进防御能力

## 8.1.7 攻击-防线快速对照表

下表从工程视角总结典型攻击与对应防线，便于快速定位防护措施：

| 攻击类别          | 主要目标               | 典型入口         | 关键防线（优先级由高到低）                  |
| ------------- | ------------------ | ------------ | ------------------------------ |
| **直接提示注入/越狱** | 改写行为/绕过规则          | 用户输入         | 输入检测（分类器/规则）→ 输出验证 → 权限收敛      |
| **系统提示泄露**    | 套出系统提示、策略、工具链信息    | 多轮追问/复述/总结   | 机密不入上下文 → 输出脱敏/拦截 → 日志/错误处理不回显 |
| **间接提示注入**    | 借外部内容注入指令          | RAG 文档/网页/邮件 | 外部内容视为不可信数据 → 文档注入检测 → 上下文最小化  |
| **RAG 检索投毒**  | 控制检索结果与回答          | 向量库/网络内容     | 来源白名单/信誉 → 检索过滤 → 异常检测         |
| **工具/智能体注入**  | 诱导调用工具越权、外泄数据      | 工具调用、工作流     | 工具最小权限/参数约束 → 沙箱执行 → 审批/审计     |
| **不安全输出处理**   | 触发 SQL/XSS/模板/命令注入 | 下游执行器        | 参数化/转义/静态检查/沙箱；**不要执行自由文本**    |
| **训练数据投毒**    | 植入后门/系统性偏差         | 预训练/微调数据     | 数据审核 → 供应链安全 → 行为监控            |
| **资源消耗/DoS**  | 拉高成本/拖垮服务          | 超长输入/复杂推理    | 速率限制 → 输入长度限制 → 成本告警           |

> \[!TIP] 此表可作为安全设计评审的检查清单。对于每种攻击类别，确保至少有一层有效防线。

## 8.1.8 防御成本与收益权衡

**为什么需要成本效益分析**

“安全第一”的原则在实践中往往面临一个现实难题：资源有限，而防御措施无限。一个企业不可能同时部署“多模型交叉验证、TEE 隔离、差分隐私”等所有高端防护技术——这样不仅成本爆炸，而且会严重拖累用户体验（延迟、成本）。

合理的安全架构设计应该是\*\*“有所为，有所不为”\*\*：

* **有所为**：对高风险、高收益的场景投入高成本的防护
* **有所不为**：对低风险或已接受风险的场景，采用轻量级防护甚至接受风险

这个权衡决策应该由三个因素驱动：

1. **业务风险等级**：数据敏感性、用户规模、合规要求
2. **攻击可能性**：根据历史事件和威胁模型评估
3. **防护成本**：实施复杂度、性能开销、运维负担、计算成本

防御措施不可能全面覆盖，企业应根据业务风险等级与资源预算进行选择性部署。以下表格总结了常见防御措施的成本与效能，帮助团队做出理性决策：

| 防御措施          | 实施成本 | 延迟影响          | 防御效果   | 适用场景                       |
| ------------- | ---- | ------------- | ------ | -------------------------- |
| **输入关键词过滤**   | 低    | <1ms          | 低（易绕过） | 所有场景的基础层，最低成本快速拦截          |
| **LLM 分类器检测** | 中    | 50-200ms      | 中-高    | 高安全要求场景，如代码执行、金融建议         |
| **多模型交叉验证**   | 高    | 200-500ms     | 高      | 金融、医疗、法律等关键场景，对准确度要求极高     |
| **差分隐私训练**    | 高    | 训练时间增加 2-5x   | 中      | 涉及敏感个人数据的模型训练，长期合规需求       |
| **TEE 隔离推理**  | 高    | 推理延迟增加 10-30% | 高      | 高合规要求场景（如医疗数据、财务系统）、硬件成本可控 |
| **实时监控与日志**   | 中    | 10-50ms       | 中      | 所有场景，用于事后分析与改进             |

**成本与收益的权衡原则**

1. **分层递进策略**
   * 从“最小可行安全集”开始部署：输入关键词过滤 + 实时监控。
   * 根据实际风险事件的发生情况，逐步增加 LLM 分类器等更强的防御手段。
   * 避免过度投资低风险场景，浪费资源。
2. **业务风险等级驱动**
   * **低风险场景**（如通用信息查询、创意写作）：仅需关键词过滤 + 基本监控。
   * **中等风险场景**（如代码生成、数据分析建议）：加入 LLM 分类器与敏感信息过滤。
   * **高风险场景**（如医疗诊断、金融交易、法律建议）：考虑多模型交叉验证、TEE 隔离、人工审核环节。
3. **延迟与用户体验权衡**
   * 关键词过滤的 <1ms 延迟对用户体验无感。
   * LLM 分类器的 50-200ms 延迟可以接受，但在实时对话场景需要异步处理或流式反馈。
   * 多模型交叉验证的 200-500ms 延迟适合非实时场景（如批量审核、定时检查）。
4. **组织能力与技术成熟度**
   * 如果团队 ML 工程化能力薄弱，直接跳到“多模型交叉验证”会导致高昂的维护成本与频繁失效。
   * 建议先在关键词过滤与 LLM 分类器阶段积累经验，再考虑更复杂的方案。
5. **定期复盘与优化**
   * 每个季度复盘实际发生的安全事件，评估现有防御的有效性。
   * 如果某类攻击频繁突破，主动升级该类防御的强度，而不是盲目增加所有防御。
   * 如果某类防御长期无事件触发，考虑适度削减成本。

**企业部署建议清单**

* [ ] 第 1 阶段（第 1-2 个月）：部署输入关键词过滤 + 结构化监控日志
* [ ] 第 2 阶段（第 2-3 个月）：加入 LLM 分类器或 Llama Guard 进行更精细的检测
* [ ] 第 3 阶段（第 3-6 个月）：根据监控数据，对高风险路径加入输出侧敏感信息过滤
* [ ] 第 4 阶段（长期）：评估多模型交叉验证、差分隐私等高投入防御的必要性

纵深防御是 LLM 安全的核心框架，但不是“大而全”的堆砌。后续各节将详细介绍各层的具体实现。

## 8.1.9 选型建议小结

在完成前一节的成本、收益和部署阶段分析后，这里只保留一个高层结论：**防御措施的选择应由业务风险、延迟预算、组织能力和实际监控数据共同驱动**，而不是机械追求“最强防御”。如果团队已经掌握了 `8.1.8` 的评估维度与分层部署原则，就可以据此形成自己的内部决策树，无需在本章再重复一套近似内容。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/ai_security_guide/di-san-bu-fen-fang-yu-pian/08_architecture/8.1_defense_depth.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.