GuardDuty 调查代理预览：把威胁发现、90 天活动与资源拓扑串成一份调查报告

2026-07-28 34 预计阅读时间: 1 分钟
来源: infoq.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：10 分钟

AWS 推出了 Amazon GuardDuty investigation agent 公共预览版。它不只是复述单条 GuardDuty finding，而是把安全发现、过去 90 天的活动日志以及资源拓扑关联起来，生成带有风险评级、置信度和 MITRE ATT&CK 分类的结构化调查报告。

这项能力试图缩短安全团队最耗时的一段流程：从“收到告警”到“判断发生了什么、影响了哪些资源、下一步该做什么”。同时，它可以通过 AWS MCP Server 被代理式工具调用，因此调查流程不再局限于控制台，也可以嵌入开发工具、ChatOps 或安全自动化工作流。

它解决的不是告警数量，而是上下文缺口

GuardDuty finding 通常提供异常行为、相关主体和受影响资源，但值班工程师仍要在多个数据源之间切换：

  • 查找同一身份或资源近期发生过什么操作；
  • 判断 IAM 身份、实例、存储桶和网络资源之间的关系；
  • 区分单个误报与连续攻击活动；
  • 把行为映射到 MITRE ATT&CK 技术；
  • 给出足以支持升级、隔离或关闭事件的证据。

调查代理的核心价值在于关联。根据公开预览信息，它会综合以下三类上下文：

  1. GuardDuty findings：调查的安全信号入口；
  2. 90 天活动日志：用于还原事件时间线和相关操作；
  3. 资源拓扑：帮助识别资源、身份以及依赖关系。

最终报告不仅给出风险评级，还包含置信度。两者不能混为一谈：高风险、低置信度的事件可能需要优先补充证据；中等风险、高置信度的事件则可能适合直接进入既定处置流程。MITRE ATT&CK 分类则让团队能够使用统一语言描述攻击行为，并与检测覆盖、响应手册和审计报告对齐。

MCP 接入让调查成为工作流中的一个工具

通过 AWS MCP Server 暴露调查能力，意味着支持 MCP 的代理式工具可以发起调查。可以这样实践：让内部安全助手接收 finding ID，调用调查工具，再把结构化结果交给工单系统或值班人员审核。

一个稳妥的工作流可以设计为：

GuardDuty finding
    -> 规则筛选与去重
    -> 人工或策略批准调查
    -> 通过 AWS MCP Server 发起调查
    -> 读取风险、置信度、时间线和 MITRE 分类
    -> 创建工单
    -> 人工确认后执行隔离、吊销凭证等操作

这里应把“调查”和“处置”分开。调查报告可以辅助决策，但不应仅凭风险评级就自动终止实例、禁用生产身份或删除资源。尤其在公共预览阶段，输出格式、覆盖范围和行为都可能变化，更适合先接入只读流程。

MCP 也会扩大权限边界。承载代理的身份应只拥有调查所需的最小权限，避免为了方便而授予全账户管理权限。同时需要记录谁发起了调查、传入了哪些 finding，以及报告被发送到了哪些外部系统。

动手准备一份可复用的调查输入包

由于公开摘要没有给出调查代理的具体 MCP 工具名称和请求结构，不宜猜测一个可能失效的调用接口。下面这个脚本可以先导出 GuardDuty findings 和最近 90 天的 CloudTrail Event History，作为人工调查、测试环境验证或后续 MCP 适配器的输入。

运行前需要：

  • AWS CLI v2、jq 和 Python 3；
  • 已配置可读取 GuardDuty 与 CloudTrail Event History 的 AWS 凭证；
  • 一个有效的 GuardDuty detector ID；
  • 把 AWS_REGION 和 DETECTOR_ID 替换为目标环境的值。
#!/usr/bin/env bash
set -euo pipefail

AWS_REGION="${AWS_REGION:-us-east-1}"
DETECTOR_ID="${DETECTOR_ID:?Set DETECTOR_ID before running}"
MAX_FINDINGS="${MAX_FINDINGS:-20}"
OUTPUT_DIR="${OUTPUT_DIR:-guardduty-investigation-input}"

mkdir -p "$OUTPUT_DIR"

aws guardduty list-findings \
  --region "$AWS_REGION" \
  --detector-id "$DETECTOR_ID" \
  --max-results "$MAX_FINDINGS" \
  --query 'FindingIds' \
  --output json > "$OUTPUT_DIR/finding-ids.json"

FINDING_COUNT="$(jq 'length' "$OUTPUT_DIR/finding-ids.json")"

if [[ "$FINDING_COUNT" -gt 0 ]]; then
  mapfile -t FINDING_IDS < <(jq -r '.[]' "$OUTPUT_DIR/finding-ids.json")
  aws guardduty get-findings \
    --region "$AWS_REGION" \
    --detector-id "$DETECTOR_ID" \
    --finding-ids "${FINDING_IDS[@]}" \
    --output json > "$OUTPUT_DIR/findings.json"
else
  printf '{"Findings": []}\n' > "$OUTPUT_DIR/findings.json"
fi

read -r START_TIME END_TIME < <(
  python3 - <<'PY'
from datetime import datetime, timedelta, timezone
end = datetime.now(timezone.utc)
start = end - timedelta(days=90)
print(start.isoformat(), end.isoformat())
PY
)

aws cloudtrail lookup-events \
  --region "$AWS_REGION" \
  --start-time "$START_TIME" \
  --end-time "$END_TIME" \
  --max-results 50 \
  --output json > "$OUTPUT_DIR/cloudtrail-events.json"

jq -n \
  --arg region "$AWS_REGION" \
  --arg detector_id "$DETECTOR_ID" \
  --arg start_time "$START_TIME" \
  --arg end_time "$END_TIME" \
  --argjson finding_count "$FINDING_COUNT" \
  '{
    region: $region,
    detectorId: $detector_id,
    timeRange: {start: $start_time, end: $end_time},
    findingCount: $finding_count,
    files: ["finding-ids.json", "findings.json", "cloudtrail-events.json"]
  }' > "$OUTPUT_DIR/manifest.json"

printf 'Created %s with %s findings.\n' "$OUTPUT_DIR" "$FINDING_COUNT"

这个示例不会复刻调查代理的资源拓扑关联能力，也不等同于正式调查结果。CloudTrail Event History 的查询范围和可见事件还会受到区域、账户配置及权限影响。它的作用是建立一个可重复的输入准备流程，便于团队在正式接入 MCP 前确认数据权限、脱敏策略和事件处理边界。

每天 10 次的预览配额应该怎样分配

公共预览阶段，每个账户每天最多进行 10 次调查。这意味着不能简单地对所有 findings 自动调用代理，否则突发告警可能在几分钟内耗尽额度。

可以先建立一个调查队列，并按以下条件排序：

条件 建议优先级
涉及生产账户、管理员身份或外部暴露资源 高
同一主体在短时间内触发多个相关 findings 高
已有规则能够明确处置的重复事件 低
测试账户中的已知演练活动 低
信息不足但潜在影响很大的事件 高，优先用调查补充证据

还应在账户维度记录每日调用量。例如为队列保留一部分额度处理紧急事件，而不是让定时批处理消耗全部 10 次。多账户组织则需要明确调查在哪个账户发起，并确认跨账户上下文是否满足团队的分析要求；不要默认单次调查能够自动覆盖整个组织。

接入前的检查清单

GuardDuty 调查代理最适合从“辅助分析员”开始，而不是直接成为自动处置引擎。落地时可以检查以下事项：

  • 选择少量高价值 finding 类型进行试点；
  • 对风险评级和置信度分别设置处理规则；
  • 验证报告中的时间线、资源关系和 MITRE 分类是否符合实际环境；
  • 为 AWS MCP Server 和调用方身份配置最小权限；
  • 记录调用者、输入 finding、输出报告和后续人工决定；
  • 建立每日 10 次调查的预算、排队和紧急预留机制；
  • 防止敏感日志、资源名称和身份信息被发送到未经批准的外部工具；
  • 在自动执行隔离或凭证吊销前保留人工审批。

这次预览真正值得关注的变化，不是又增加了一种报告，而是云安全调查开始变成可被代理工作流调用的标准化能力。团队越早把权限、配额、证据验证和人工审批设计清楚，未来把它接入日常响应流程时就越不容易把“自动调查”变成“自动误判”。

# AI # AWS # InfoQ # LLM # 云平台 # 全栈 # 后端 # 数据工程

相关推荐