从证据到响应：LLM安全事件调查

在之前的文章中，我们通过Prometheus查找异常区间，利用Tempo的Trace缩小请求路径，然后在Loki中确认了相同TraceId的详细证据。然而，找到痕迹并不意味着事件响应的结束。我们必须保存调查结果，确定影响范围，阻断危险路径，并安全地恢复服务。

本文将从头到尾处理一个假想事件：“输入Guardrail记录了阻止，但之后Tool调用被执行了”。目标不是重新执行攻击字符串。这是一次防御性演练，旨在利用已收集的日志、跟踪、指标和部署信息来重构事件，并创建可重现的证据包和响应记录。

事件调查比日志搜索更重要

NIST SP 800-61 Rev.3指出，事件响应不应是独立的、一次性的任务，而应整合到组织整体的网络安全风险管理活动中。充分的准备可以加速检测、响应和恢复，而从恢复中吸取的教训反过来又能提高保护和检测能力。

在LLM服务中，这个循环尤为重要。仅调查模型调用是不够的。用户认证、租户边界、系统提示版本、RAG搜索结果、Guardrail决策、工具权限、下游变更和输出处理，所有这些都必须作为一个事件整体进行关联。

준비 → 탐지·분석 → 범위 확정 → 증거 보존
  ↑                              ↓
개선 ← 사후 분석 ← 복구·검증 ← 차단·근절

首先，明确角色和决策权

观测工具展示事实，但不能代替响应决策。事件指挥官协调优先级和决策，调查人员创建证据和时间线。服务负责人执行功能限制和恢复，IAM负责人检查账户、令牌和权限。如果涉及个人信息或受监管数据，法务和隐私负责人判断保留期限和通知要求。

角色	主要职责	不应单独做的事情
—	—	—
事件指挥官	严重性、范围、决策记录	无证据确认入侵
调查负责人	时间线、查询、证据哈希	直接修改原始证据
服务·平台负责人	功能限制、部署、恢复	在获取证据前删除日志
IAM·数据负责人	令牌作废、权限·租户确认	将最终授权判断委托给LLM
个人信息·法务负责人	判断保留·通知要求	无限期保留所有遥测数据

初始严重性是根据实际影响而非“是否看到了攻击字符串”来确定的。如果只有被阻止的输入，那可能只是一个检测事件。如果确认阻止后工具执行、查询其他租户数据、秘密泄露或外部系统变更，则应提高优先级。

实践案例：阻止后工具仍被执行

以下是实践假设：

• input_guard Span记录了security.decision=block。
• 在同一Trace中，tool_policy和tool_call Span紧随其后。
• 尚不清楚工具的结果是否实际造成了外部变更。
• 原始提示和响应未存储在观测存储中。

在这种情况下，不应断定“数据因绕过Guardrail而泄露”。首先，分离三个假设：

1. 测量错误：仅Span顺序或属性记录错误。
2. 控制流缺陷：阻止决策后缺少执行中断。
3. 权限侵犯：工具实际执行了未经授权的读写操作。

调查的目的不是选择最耸人听闻的解释，而是用证据逐一排除假设。

第一步：固定事件编号和调查时间范围

首先，记录事件编号、调查员、基准时区和首次警报。使用UTC绝对时间，而不是屏幕上显示的相对时间“10分钟前”。

incident_id: INC-LLM-2026-0007
detected_at: 2026-09-03T01:10:00Z
window_start: 2026-09-03T00:55:00Z
window_end: 2026-09-03T01:25:00Z
initial_signal: block 이후 tool_call Span 발견

在Prometheus中检查事件前后阻止率和工具调用量。

sum(rate(llm_security_requests_total{decision="block"}[5m]))
/
sum(rate(llm_security_requests_total[5m]))

sum by (tool, result) (
  increase(llm_tool_calls_total[30m])
)

指标可以告知异常的时间点和规模，但不会将单个TraceId作为标签。这是因为为每个请求使用不同的值作为标签会导致时间序列数量激增。

第二步：在Trace中确认执行边界

在Tempo中查找被阻止的输入Trace。属性名称是本次实践的示例，应根据实际的度量方案进行调整。

{ name = "input_guard" && span.security.decision = "block" }

打开Trace并确认以下顺序：

request
 ├─ authenticate
 ├─ input_guard        decision=block
 ├─ tool_policy        ← 존재하면 제어 흐름 의심
 └─ tool_call          ← 실제 실행·결과 확인 필요

记录Span的开始/结束时间、Status、service.name、部署版本、工具名称和授权决策ID。不要将原始提示、访问令牌或工具的敏感参数复制到证据备忘录中。如有必要，记录其存在性、长度、分类和单独的存储位置，而不是值本身。

第三步：通过Loki和下游审计日志验证实际影响

查找具有相同TraceId的应用程序日志。将TraceId放在结构化元数据或日志字段中比作为Loki中的高基数索引标签更合适。

{service_name="llm-security-app"}
| trace_id="조사할_TraceId"

不要仅凭应用程序日志就确认工具执行成功。通过目标API、数据库和云审计日志交叉验证相同的request_id、操作ID或授权决策ID。

检查点	应保留的最小证据	要回答的问题
—	—	—
应用程序	TraceId, RequestId, 部署版本	阻止后代码路径是否继续？
Guardrail	规则ID、决策、策略版本	哪个策略决定了什么？
IAM·策略引擎	主体、租户、决策ID	谁以何种权限获得授权？
工具网关	工具名称、结果代码、目标分类	调用是否实际传输？
下游系统	审计事件ID、变更前后状态	读写是否实际反映？
RAG	文档ID·版本、租户过滤结果	是否包含其他租户的数据？

LLM或Guardrail的判断不是业务授权的证据。最终访问权限由可信的应用程序/API层和下游系统强制执行，调查人员必须验证这些授权记录。

第四步：创建不修改原始数据的证据包

调查结果必须能够在以后重新审查以得出相同的结论。在不修改原始存储的情况下，将查询、查询时间范围、导出结果、配置/部署版本和哈希保存在单独的事件目录中。

mkdir -p incident-INC-LLM-2026-0007/{queries,exports,config,notes}

cp prometheus-query.txt incident-INC-LLM-2026-0007/queries/
cp trace-summary.json incident-INC-LLM-2026-0007/exports/
cp redacted-events.jsonl incident-INC-LLM-2026-0007/exports/
cp deployment-version.txt incident-INC-LLM-2026-0007/config/

find incident-INC-LLM-2026-0007 -type f ! -name SHA256SUMS 
  -print0 | sort -z | xargs -0 sha256sum 
  > incident-INC-LLM-2026-0007/SHA256SUMS

tar --sort=name --mtime='UTC 1970-01-01' 
  --owner=0 --group=0 --numeric-owner 
  -czf INC-LLM-2026-0007-evidence.tar.gz 
  incident-INC-LLM-2026-0007

sha256sum INC-LLM-2026-0007-evidence.tar.gz

在macOS上，可以使用shasum -a 256代替GNU sha256sum。tar选项也因实现而异，因此请在操作环境中确认支持情况。

在notes/timeline.md中，将观察到的事实与解释分开。

[사실] 01:03:14Z input_guard가 block 기록
[사실] 01:03:14Z 같은 Trace에 tool_call Span 존재
[사실] Downstream 감사 로그에 write 이벤트 없음
[해석] 호출 준비 단계까지 진행됐으나 외부 변경 증거는 확인되지 않음
[미확인] 응답이 사용자에게 반환됐는지 Gateway 로그 확인 필요

哈希是验证文件是否更改的手段，但不能自动保证收集过程的可靠性。收集者、收集时间、原始位置、转换/掩码过程和访问记录也应一并保留。

确保遥测数据本身不会成为新的泄露路径

OpenTelemetry的官方安全指南警告称，遥测数据可能会无意中包含PII、应用程序数据和网络模式。由于OpenTelemetry无法自动判断哪些是敏感数据，因此实施者必须制定最小化收集、删除、哈希和匿名化策略。

基本证据应优先考虑以下内容：

• TraceId、规则ID、决策和处理步骤，而非原文
• 经批准的版本或哈希，而非系统提示内容
• RAG文档ID·版本和租户过滤结果，而非RAG原文
• 操作类型、目标分类和结果代码，而非工具参数原文
• 事件调查所需的有限假名标识符，而非用户标识符

如果确实需要原文，则需要与通用观测存储分离的加密存储、受限角色、短保留期和访问审计。法律、合同和监管要求必须由组织相关负责人判断。

第五步：获取证据后限制损害

遏制，即限制损害，并非“关闭所有服务器”这样单一的行动。应根据影响和业务连续性，首先采取最窄的安全措施。

已确认情况	优先措施示例	需确认的副作用
—	—	—
阻止后仅调用特定工具	禁用相关工具路由	核心业务是否中断
特定策略版本缺陷	回滚到之前批准的版本	新策略阻止的风险重新暴露
令牌泄露可能性	作废/轮换令牌，终止会话	自动化·批处理作业失败
租户过滤缺失	检索API故障关闭	搜索功能的整体可用性
确认外部写入	移除写入权限，恢复目标状态	证据与正常变更的区分

如果可能，与其关闭整个LLM，不如将工具写入改为只读，或阻断危险路由，或要求人工批准来缩减功能。但是，如果怀疑存在秘密泄露或广泛的租户边界崩溃，则需要更强的隔离。

所有紧急变更都应记录执行者、批准者、时间、变更内容、回滚条件和相关事件编号。

第六步：根除并验证恢复

如果原因是返回阻止后函数未终止的控制流缺陷，则不能仅仅通过添加策略来解决。应在代码中强制执行故障关闭（Fail-closed）并添加自动化测试。

decision = input_guard.check(request)
if decision.blocked:
    audit(decision)
    return blocked_response()

# 此行以下只应到达被允许的请求。
result = tool_gateway.execute(authorized_request)

恢复前，至少测试四项内容：

1. 阻止请求不会生成tool_policy和tool_call Span。
2. 允许的请求正常运行并再次通过下游授权。
3. 无法访问其他租户的RAG文档和工具目标。
4. 指标、跟踪、日志和警报在新版本中仍然连接。

最初，部署到金丝雀或受限租户，并观察错误率、阻止率和工具调用量。“补丁部署成功”并非恢复完成。当正常功能、安全边界和观测功能全部恢复时，才算结束。

第七步：将事后分析反馈到检测和设计改进中

事后报告不是指责他人的文件，而是减少下一次事件检测和响应时间的输入。

• 最初的信号和实际影响是什么？
• 哪些证据改变了结论？
• 发现和阻止分别花费了多长时间？
• 遥测数据中哪些字段不足或过多？
• Runbook、测试、警报和权限边界将如何改变？

对于本次事件，以下改进是自然的：

예방: block 이후 즉시 종료하는 공통 Middleware
탐지: blocked Trace에 tool_call이 존재하면 Critical Alert
제한: Tool Gateway에서 사용자·Tenant 권한을 다시 검사
검증: CI에 차단 후 Side Effect 부재 테스트 추가
운영: 사건 Query와 증거 Manifest 템플릿 표준화

实践完成检查清单

• 记录了事件编号、负责人、UTC时间范围和初始假设。
• 通过指标确认了异常时间点和规模。
• 在Trace中确认了阻止后的执行路径。
• 交叉验证了应用程序和下游审计日志。
• 分离了观察到的事实、解释和未确认项。
• 在不修改原始数据的情况下保存了导出和查询。
• 生成了文件哈希和证据包哈希。
• 将提示、响应、令牌和PII排除在基本证据之外。
• 记录了最窄的遏制措施和回滚条件。
• 补丁后执行了阻止、授权、租户和观测回归测试。
• 将经验教训反映到警报、测试、Runbook和权限设计中。

总结

LLM安全事件响应的核心不在于猜测模型为何生成了这样的语句。它在于通过证据连接，确定是哪个主体在何种策略和部署版本下发出了请求，Guardrail和应用程序做出了什么决定，以及工具和下游系统实际产生了哪些副作用。

Prometheus展示事件的时间点和规模，Tempo展示请求的执行路径，Loki和审计日志展示决策的依据和实际影响。在此基础上，加上变更记录、哈希、访问控制和恢复验证，观测数据就成为了可操作的证据。最后一步总是同一个问题：“下一次我们能否更快地发现、更窄地遏制、更可靠地恢复？”

官方资料

• NIST SP 800-61 Rev.3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST AI 600-1: Generative Artificial Intelligence Profile
• NIST AI Risk Management Framework
• OpenTelemetry Security
• OpenTelemetry: Handling Sensitive Data
• OpenTelemetry Context Propagation
• Grafana Tempo TraceQL
• Grafana Loki LogQL
• Prometheus Querying Basics

※ 事件响应、证据保存和通知义务因组织的行业、地区、合同和法律要求而异。本文中的命令和保存项目为教育示例，在实际事件中，应优先遵循组织批准的事件响应程序以及法务和隐私负责人的指导。

类别: 一般IT/IT安全

标签: LLM Security, Incident Response, Digital Forensics, OpenTelemetry, Loki, Tempo, Prometheus, NIST