从 AWS Security Hub 到客户化 HTML：构建私有 AI 安全报告管道
- 作者
- 姓名
- Nino
- 职业
- Senior Tech Editor
现代云安全态势管理（CSPM）每天都会产生海量的原始安全审计数据。AWS Security Hub 能够将来自 Amazon GuardDuty、Amazon Inspector 以及 IAM Access Analyzer 的发现项统一归一化为标准的 AWS 安全发现格式（ASFF）。虽然 ASFF 格式在记录审计追溯链方面表现极为出色，但在生成面向决策层或客户的安全报告时却面临巨大挑战：原始 JSON 报文充斥着复杂的 Amazon 资源名称（ARN）、账号标识符、冗长的技术细节以及未经提炼的修复建议。
如果每周依靠人工整理这些数据并撰写报告，不仅耗费大量安全工程师的高价值时间，而且直接将包含敏感网络拓扑的原始漏洞数据发送至公有云 AI 服务，会带来严重的数据合规与隐私泄露风险。对于希望借助高性价比、高稳定模型接口的团队，通过 n1n.ai 或 Amazon Bedrock 构建混合架构，能够在保障数据隐私的前提下，实现安全报告的高效智能化生成。
本文将详细讲解如何在 AWS 新加坡区域（ap-southeast-1）部署一套经过生产环境验证的“双阶段私有 AI 安全报告管道”。该方案结合了确定性数学打分引擎、有界云端 LLM 摘要提取（基于 Bedrock 或 n1n.ai 统一接口）以及无外网出口的本地 ARM64 EC2 离线推理主机，最终输出符合客户交付标准的动态 HTML 报告。
架构设计：双工件模式的必要性
在云安全自动化领域，最常见的误区是企图使用单一报告工件同时满足合规审计员与企业高管的需求。审计员要求 100% 保留原始 ASFF Telemetry、完整 ARN 路径以及未修改的评估参数；而企业高管与客户则需要清晰的视觉层级、高优先级修复建议、周度增量对比（Delta Metrics）以及流畅的交互体验。
报告工件需求对照表
| 特性 / 评估维度 | 阶段一：AWS 原始证据工件 (Evidence Artifact) | 阶段二：客户级后处理 HTML 报告 (Client-Ready HTML) |
|---|---|---|
| 主要受众 | 内部安全运维工程师、合规审计员 | 企业高管、外部客户、项目负责人 |
| 数据真实性 | 100% 原始 ASFF JSON 报文 | 提炼归纳后的摘要与结构化数据 |
| 资源标识符 | 完整 AWS ARN、账号 ID、内部 IP | 经脱敏处理的战略资源标识 |
| 增量状态对比 | 静态单点快照 | 动态追踪（新增、持续、已修复、未观察到） |
| 交互能力 | 基础静态表格 | 支持动态排序、多维度筛选、离线 CSV 导出 |
| 网络与数据边界 | AWS 账号受控边界内 | 完全物理隔离 / 离线处理边界 |
通过将生成流程拆分为两个相互独立的阶段，不仅能确保审计链路的完整性，还能彻底隔离前端渲染器对生产环境 Security Hub API 的直接访问权限。
+---------------------------------------------------------------------------------+
| 阶段一：AWS 云端受控边界 (ap-southeast-1) |
| |
| GuardDuty + Inspector + Security Hub CSPM |
| │ |
| ▼ |
| EventBridge 周定时任务 -> AWS Lambda (确定性打分引擎) |
| │ |
| 确定性算法逻辑 + 有界叙事提炼 (Bedrock / n1n.ai API) |
| │ |
| ▼ |
| S3 存储桶 (KMS 加密存储原始 Markdown 证据) |
+---------------------------------------------------------------------------------+
│
S3 只读权限 (受限 IAM Role)
│
▼
+---------------------------------------------------------------------------------+
| 阶段二：离线隔离后处理主机 (ARM64 EC2) |
| |
| EC2 (t4g.2xlarge ARM64) <- 运行模型: Qwen2.5 7B GGUF (llama-cpp-python) |
| (禁用外网出站流量 / EBS 磁盘加密 / 无公网入站访问) |
| │ |
| ▼ |
| 交付级离线 HTML 安全报告工件 |
+---------------------------------------------------------------------------------+
阶段一：AWS 确定性打分引擎与有界 AI 提炼
阶段一由部署在 AWS Lambda 上的 Python 运行时处理。定时任务每周触发一次，拉取当前活跃的安全发现，执行严格的确定性优先级计算，调用 Bedrock 或 n1n.ai 生成受限的 executive 文本，并与上周数据做 Diff 状态对比，最后将 Markdown 证据文件存入 Amazon S3。
步骤 1：配置安全的 S3 存储结构
在 ap-southeast-1 区域创建开启 KMS 加密并启用“阻塞所有公网访问”（Block Public Access）的专有 Bucket：
aws s3api create-bucket \
--bucket example-security-reporting-ap-southeast-1 \
--region ap-southeast-1 \
--create-bucket-configuration LocationConstraint=ap-southeast-1
aws s3api put-public-access-block \
--bucket example-security-reporting-ap-southeast-1 \
--public-access-block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"
建立清晰的对象存储目录规划：
s3://example-security-reporting-ap-southeast-1/
├── weekly/raw/2026-09-07/weekly-security-summary.md
├── weekly/evidence-html/2026-09-07/security-evidence.html
├── weekly/client-html/2026-09-07/client-security-report.html
└── weekly/state/2026-09-07/findings-manifest.json
步骤 2：确定性优先级打分算法实现
绝不能允许 AI 大语言模型自行决定安全漏洞的严重性或随意降级风险。所有打分逻辑必须由代码中的确定性策略决定。
以下 Python 代码展示了如何在 Lambda 中对 ASFF 数据进行标准化打分：
# scoring_engine.py
SEVERITY_BASE = \{
"CRITICAL": 100,
"HIGH": 75,
"MEDIUM": 45,
"LOW": 20,
"INFORMATIONAL": 5,
\}
def calculate_priority_score(finding: dict, asset_criticality: int = 0, exposure_modifier: int = 0) -> int:
"""
计算可审计的确定性优先级得分。
- asset_criticality: 业务资产重要性加权 (0–25)，基于 AWS 标签 (如 Environment=Production)
- exposure_modifier: 网络暴露面加权 (0–20)，基于公网可达性证据
"""
raw_severity = finding.get("Severity