Name: 攻防有道：网络安全实战进阶手册
Author: gpt-5.2

安全实战方法论：从资产、风险到控制面与数据面

安全建设最常见的失败方式，不是“工具选错了”，而是团队从一开始就缺少一套可复用、可讨论、可度量的方法论：不知道要保护什么（资产不清）、不知道防谁（威胁不清）、不知道先做什么（风险不清）、不知道做得对不对（控制与信号不成闭环）。本章给出一套可以在互联网业务中直接落地的统一框架：先用资产与数据分级建立“保护对象”，再用威胁建模把攻击路径结构化，随后把风险量化为可排序的工作队列，最后用“控制面/数据面”的分层把预防、检测、响应串成闭环，并以“最小可行安全体系（MVSP）”的路线图指导实际推进。

---

1. 统一语言：资产、威胁、风险、控制、信号

在进入方法论之前，先把术语对齐。你会发现，80% 的沟通成本来自术语不一致，尤其在安全与研发、运维、合规之间协作时。

1.1 核心对象与关系

**资产（Asset）**：对业务有价值、可被攻击者利用或破坏的对象。资产不仅是“服务器”，还包括数据、身份、接口、云资源与配置状态。
**威胁（Threat）**：攻击者可能采取的行动或能力假设（例如“凭证填充”“利用公开漏洞打点”“供应链投毒”）。
**脆弱性（Vulnerability）**：资产存在的可被利用缺陷（代码漏洞、配置错误、权限过大、缺少审计等）。
**风险（Risk）**：威胁利用脆弱性作用于资产后导致损失的可能性与影响的综合。
**控制（Control）**：降低风险的措施，可分为预防性（Preventive）、检测性（Detective）、纠正性（Corrective/Responsive）。
**信号（Signal）**：证明控制有效或证明正在被攻击的数据面证据（日志、流量、事件、指标）。

你可以把安全工作抽象为一个不断循环的闭环：

1) 资产与数据：明确“要保护什么” 2) 威胁建模：明确“可能怎么被打” 3) 风险量化：明确“先做什么” 4) 控制与信号：明确“做了是否有效”

> 侧边栏：为什么“没有信号的控制”很危险 > 很多团队把“上了 WAF、开了扫描、装了 Agent”当作完成，但没有对应的数据面信号与度量（覆盖率、检测延迟、误报率、MTTR），控制会在配置漂移、权限滥用、规则过期中逐渐失效，却无人知晓。安全体系必须同时回答：我拦住了什么？我漏掉了什么？我什么时候知道的？

---

2. 资产盘点与分级：你到底在保护什么

资产盘点不是一次性的“拉清单”，而是持续性的“建立事实源”。对于中级团队，目标不是一步到位建 CMDB，而是先构建能支撑风险排序与控制落地的最小资产模型。

2.1 资产五类模型：业务、数据、身份、接口、云资源

为了让资产可用于威胁建模与风险量化，本书建议按五类建模，每类都要能关联“负责人/环境/暴露面/关键控制”。

（1）业务资产（Business）

Web 站点、API 服务、后台管理系统、定时任务、消息队列消费者、CI/CD 平台、监控平台等
关键字段：业务域、SLO、变更频率、依赖关系、外部暴露（域名/IP）、运行环境（K8s/VM/Serverless）

（2）数据资产（Data）

用户数据（PII）、认证数据（密码哈希、token、session）、交易数据、行为日志、运营数据、源代码与配置、密钥与证书、备份与快照
关键字段：数据级别、存储位置、加密状态、访问路径、保留周期、删除/脱敏策略、跨境/合规要求

（3）身份资产（Identity）

人员身份：员工账号、外包账号、紧急账号、审计账号
机器身份：服务账号、云 RAM/IAM 角色、K8s ServiceAccount、CI Runner 身份、密钥对、API Key
关键字段：认证强度（MFA/证书/短期凭证）、授权模型（RBAC/ABAC）、最小权限程度、生命周期与轮换、可审计性

（4）接口资产（Interface）

HTTP API、gRPC、WebSocket、数据库端口、管理面板、消息队列入口、对象存储访问端点、回调地址、Webhook
关键字段：鉴权方式、速率限制、输入校验、接口是否对公网、版本与弃用策略、是否存在“影子 API”

（5）云资源资产（Cloud/Infra）

VPC/子网/路由/NAT、LB、WAF、安全组、K8s 集群与节点池、镜像仓库、对象存储桶、KMS、Secrets、日志服务、DNS
关键字段：配置基线、漂移检测、标签（Owner/Env/DataClass）、与业务资产的绑定关系

2.2 资产清单模板：字段要“能用来做决策”

表 1-1 给出一个可直接复用的资产清单模板（以业务资产为核心，关联到数据/身份/接口/云资源）。很多团队失败的原因是字段太“行政化”（只有名称与负责人），无法支撑优先级排序。

表 1-1：业务资产清单模板（可直接复制到表格/CMDB）

| 字段 | 示例 | 用途 | |---|---|---| | AssetID | svc-user | 全局唯一引用 | | 资产类型 | API 服务 | 分组与策略套用 | | 负责人/值班 | user-team / oncall | 变更与响应闭环 | | 环境 | prod/staging | 风险分层 | | 暴露面 | Internet / 内网 / 私网 | 影响可能性 | | 入口 | `api.example.com` | 攻击入口定位 | | 关键依赖 | MySQL、Redis、OSS | 横向风险传播 | | 鉴权 | JWT + OAuth2 | 认证风险评估 | | 授权模型 | RBAC（role:admin） | 越权风险评估 | | 数据级别 | 机密（含 PII） | 影响评估 | | 变更方式 | GitOps + CI/CD | 供应链风险 | | 日志与审计 | access log、auth log、audit | 检测能力评估 | | 备份/灾备 | RPO=15m，RTO=1h | 业务韧性评估 | | 基线状态 | CIS 对齐 85% | 配置风险量化 | | 已知高危 | CVE-xxxx、弱口令 | 快速风险输入 |

> 实操建议：先做“能覆盖 80% 风险的 20% 字段” > 如果你无法一次性填满所有字段，优先保证：暴露面、入口、鉴权/授权、数据级别、日志、关键依赖、负责人。其余字段可以后补，但这几项决定了威胁建模与风险排序是否能跑起来。

2.3 数据分类分级：把“影响”落到可执行策略

数据分级的目的不是贴标签，而是把标签映射到控制（加密、访问控制、审计、脱敏、保留、共享审批）。推荐四级模型，既能覆盖大多数互联网业务，也方便映射到合规要求。

表 1-2：数据分类分级样表（示例）

| 级别 | 定义 | 典型数据 | 最小控制要求（示例） | |---|---|---|---| | L1 公开 | 公开发布无风险 | 营销页面内容 | 完整性保护、发布审计 | | L2 内部 | 泄露带来轻微影响 | 内部文档、非敏感日志 | SSO、访问审计、最小权限 | | L3 机密 | 泄露带来重大损失 | PII、订单、地址、手机号 | 传输/静态加密、强审计、DLP/脱敏 | | L4 受监管/高敏 | 触发法规或重大处罚 | 支付信息、身份证、密钥材料 | 强隔离、双人审批、细粒度审计、密钥托管 |

将分级映射到策略的关键在于“可操作”。例如：

**L3/L4 数据**：必须有“可追溯访问路径”（谁在何时通过哪个入口访问了哪些记录），否则事故后无法定界。
**L4 数据**：必须有“禁止直连”的网络策略（例如数据库不可从办公网直连，只能经跳板或受控代理），否则权限治理无法收敛。

2.4 自动发现与持续更新：避免清单快速腐烂

资产清单最大的敌人是“变化”。互联网业务每天都在上线、扩容、拆分服务，手工维护必然失真。建议用三类事实源对齐：

1) 云 API/IaC：用云厂商 API 与 Terraform/Helm/GitOps 作为资源事实源（VPC、SG、LB、Bucket、K8s 对象）。 2) 运行时发现：通过流量观测、服务网格遥测、API 网关路由表、Ingress 规则发现“影子接口”。 3) 代码与依赖：通过代码仓库、CI/CD pipeline、SBOM 发现组件与依赖关系。

一个实用的“持续更新”机制是：把资产字段拆成“自动字段”和“人工字段”。自动字段（入口、暴露面、依赖、镜像、端口）每天刷新；人工字段（负责人、数据级别、SLO）由变更流程驱动更新。

---

3. 威胁建模：从 STRIDE 到 ATT&CK 的可执行映射

威胁建模的价值在于：把“可能发生的坏事”从经验与直觉，变成结构化的可讨论对象，并输出可落地的控制与检测点。本章采用两层组合：

**STRIDE**：适合快速枚举系统性威胁（从属性角度覆盖全面）。
**MITRE ATT&CK**：适合映射现实世界对手行为（从战术与技术角度可对齐检测与响应）。

3.1 用 DFD 找到信任边界：威胁往往发生在边界处

威胁建模的起点是数据流图（DFD）：识别外部实体、进程、数据存储与信任边界。图 1-1 是一个典型互联网业务（Web+API+DB+K8s+对象存储）的简化 DFD。

信任边界通常包括：公网入口（用户到 Web/API 网关）、控制面入口（CI/CD 到 K8s、云控制台）、数据存储入口（服务到数据库/对象存储）。很多高危事故（越权、数据泄露、供应链投毒）都发生在边界控制薄弱处。

3.2 STRIDE 快速枚举：从“威胁类型”到“具体场景”

STRIDE 六类威胁及其在互联网业务中的典型落点：

**S（Spoofing）身份伪造**：盗用用户 token、伪造服务身份（缺少 mTLS/短期凭证）、伪造回调来源（Webhook 未校验签名）。
**T（Tampering）篡改**：参数篡改导致价格/权限变化，镜像篡改（仓库权限过大），对象存储内容被替换。
**R（Repudiation）抵赖**：缺少审计日志导致无法追责；日志可被篡改或缺少完整性保护。
**I（Information Disclosure）信息泄露**：Bucket 误公开、日志输出敏感字段、错误栈泄露、越权读数据。
**D（Denial of Service）拒绝服务**：API 无速率限制、昂贵查询未保护、队列堆积导致雪崩。
**E（Elevation of Privilege）权限提升**：RBAC 过宽、SSRF 打到云元数据、K8s 逃逸拿到节点权限。

STRIDE 的关键不是把每类都写满，而是把它落到“具体资产+具体入口+具体数据”的组合上。例如对对象存储（OSS Bucket），I 类威胁（泄露）可能来自：ACL 误配置、临时链接过期时间过长、服务端签名密钥泄露、跨账号授权过大。

3.3 STRIDE → ATT&CK：把“威胁”变成可检测的对手行为

ATT&CK 的优势是可对齐检测与响应（战术：初始访问、执行、持久化、提权、横向移动、数据窃取等）。表 1-3 给出一个“从 STRIDE 到 ATT&CK 的映射示例”，用于把建模结果直接转化为检测用例库。

表 1-3：STRIDE 与 ATT&CK 映射（示例，不同环境需调整）

| STRIDE | 场景示例 | ATT&CK 战术/技术（示例） | 可观测信号（数据面） | |---|---|---|---| | S | 凭证填充登录 | Credential Access / Valid Accounts | 登录失败率、同 IP 多账号、异常 UA | | E | SSRF 访问云元数据 | Privilege Escalation / Exploitation | 访问 `169.254.169.254` 痕迹、异常出网 | | I | 对象存储误公开 | Exfiltration / Exfiltration Over Web | Bucket ACL 变更日志、下载峰值 | | T | 镜像被替换部署 | Supply Chain / Compromise Software Supply Chain | 镜像签名验证失败、部署来源异常 | | D | API 被刷导致雪崩 | Impact / Network Denial of Service | QPS 激增、错误率上升、限流触发 |

> 数字版阅读提示：可将 ATT&CK 技术条目作为扩展阅读入口 > - MITRE ATT&CK：`https://attack.mitre.org/` > 你不需要把所有技术都覆盖，优先覆盖与你的暴露面与关键数据强相关的 20–30 条。

3.4 建模输出：威胁假设、关键控制点、关键观测点

一个可执行的威胁建模输出，至少包含三列：

1) 威胁假设：攻击者通过什么入口，对什么资产，达成什么目的。 2) 关键控制点（控制面）：要实施的策略/身份/配置控制。 3) 关键观测点（数据面）：要采集哪些日志/流量/事件，如何告警，如何关联。

例如“SSRF → 云元数据 → 盗取临时凭证 → 访问对象存储”这条链路，控制点包含：出网限制、元数据服务保护、工作负载身份最小权限；观测点包含：对元数据 IP 的请求、异常 STS AssumeRole、对象存储大规模下载。

---

4. 风险量化：让优先级可讨论、可复盘

“风险量化”不是追求精确到小数点，而是让优先级排序有共识：为什么先做 A，后做 B；做完后风险是否下降。推荐从最简单、可落地的模型开始，然后再逐步细化。

4.1 基础模型：可能性 × 影响

最常用的风险定义：

$$Risk = Likelihood \times Impact$$

为了让团队可操作，建议把 Likelihood 与 Impact 都离散为 1–5 分，并用清晰的评分锚点减少争论。

可能性（Likelihood）评分建议

5：公网暴露 + 已知可利用（公开 PoC）+ 缺少有效控制
4：公网暴露 + 控制较弱（无 MFA/无 WAF/权限大）
3：内网暴露或需要一定前置条件（需要账号/需要链路）
2：需要高成本条件（物理接触/供应链深度）
1：理论存在但几乎不可达或已被强控制

影响（Impact）评分建议（以 CIA+业务为锚点）

5：L4 数据泄露/核心交易中断/重大合规处罚
4：L3 数据泄露/关键业务长时间不可用
3：局部功能受损/少量数据泄露可控
2：轻微影响/可快速恢复
1：几乎无业务影响

量化的关键不是分数本身，而是把“评分依据”写进风险条目里，方便复盘与审计。

4.2 暴露面评分：把“攻击面”转成可优化的指标

仅用 Likelihood 仍可能过粗，尤其在资产多、接口多时。可以引入一个“暴露面评分（Exposure Score）”用于对 Likelihood 做解释与拆分。示例公式如下（可按实际权重调整）：

$$Exposure = 0.35 \cdot Internet + 0.25 \cdot AuthWeak + 0.2 \cdot PatchLag + 0.2 \cdot NoTelemetry$$

其中：

`Internet`：是否公网暴露（0/1 或 0/0.5/1）
`AuthWeak`：认证强度弱（无 MFA、长期密钥、无 mTLS、默认口令等）
`PatchLag`：补丁滞后（例如高危 CVE 超过 30 天未修）
`NoTelemetry`：缺少关键日志/审计/告警

暴露面评分的好处是：它直接指向可行动项。例如 `NoTelemetry` 高，不是让你“买工具”，而是明确缺哪类日志、缺哪条链路、缺哪种关联。

4.3 示例：API 令牌泄露风险如何计算并驱动落地

假设存在资产 `svc-order`（订单服务）：

对公网提供 `POST /api/v1/order`，通过 API 网关暴露
使用 JWT，token 有效期 30 天（较长）
服务账号可读写订单表与对象存储发票文件
访问日志不记录 `sub`（用户标识），审计无法追踪到用户

风险条目：攻击者窃取 token 后伪造用户下单/读取订单与发票（S/I/E 综合）。

Likelihood：公网入口（4）+ token 有效期长（+1）+ 缺少异常检测（+0.5）≈ 5
Impact：订单数据与发票（L3/L4 交界，含 PII/交易信息）≈ 4
Risk：20（高）

从这个分数出发，工作项不应停留在“加强安全”，而要拆成可验收的控制与信号：

控制面：
token 有效期缩短（30 天 → 1 小时）+ refresh token 绑定设备/会话
对关键操作引入 step-up auth（高风险时二次验证）
服务账号对对象存储改为“按前缀/按标签最小权限”
数据面：
access log 增加 `sub`、`jti`、token 颁发方、客户端指纹
规则：同一 `sub` 在短时间内地理位置跳变、UA 突变、异常订单频率告警
验收：
覆盖率：`sub` 字段日志覆盖率 ≥ 99%
检测延迟：异常规则 MTTD ≤ 5 分钟

---

5. 控制面与数据面：分层治理的骨架

把安全体系拆成“控制面（Control Plane）”与“数据面（Data Plane）”，是为了让团队明确两件事： 1) 控制面决定“系统应该怎样运行”（策略、身份、配置）。 2) 数据面决定“系统实际上怎样运行