如何绘制数据流图找风险？

本文目录导读：

1. 第一步：构建不同层次的DFD
2. 第二步：对每个元素进行“风险排查”
3. 第三步：标记“信任边界”与“高危路径”
4. 一个典型的风险分析案例（DFD视角）
5. 绘制检查清单

绘制数据流图（DFD，Data Flow Diagram）本身并不是一个直接“找风险”的工具，而是一个系统建模与沟通工具，但通过系统性地分析DFD，你可以识别出许多安全风险、合规风险和运营风险。

要利用DFD来找风险,核心思路是：跟踪数据的“生、存、传、用、销”全过程，并评估每个环节的暴露面。

以下是具体的操作步骤和排查清单：

第一步：构建不同层次的DFD

不要只画一张图,至少要画三个层次，层层聚焦：

1. 上下文图（Context Diagram，第0层）：

   • 是什么：只有一个系统主处理节点，外部实体（用户、第三方、数据库）通过数据流与系统交互。
   • 找什么风险：识别所有外部依赖和边界，任何外部的数据流入或流出，都是潜在的攻击面。
   • 风险点：第三方接口未鉴权、用户输入未验证、输出数据泄露。

2. 功能级DFD（第1层）：

   • 是什么：将主系统分解为3-7个主要功能过程（如：登录、查询、转账、日志）。
   • 找什么风险：识别功能间的数据流动，很多风险发生在功能交接处。
   • 风险点：敏感数据（如密码）在功能间明文传递、跨过程的数据篡改。

3. 微级DFD（第2层或更低）：

   • 是什么：聚焦于单个高风险功能（如“用户认证过程”），细化到数据存储和细粒度数据流。
   • 找什么风险：发现数据存储和内部逻辑缺陷。
   • 风险点：敏感数据在XML/JSON日志中明文写入、密码校验逻辑绕过。

第二步：对每个元素进行“风险排查”

在绘制好DFD后,对图中的四个基本元素逐一进行风险评估：

外部实体（External Entity）

• 风险：身份假冒与权限滥用
• 排查清单：
  • 你如何验证这个实体的身份？（如果只是用户名+密码，是弱风险；如果是MFA+证书，风险较低）
  • 此实体是否被赋予了超出其职责范围的访问权限？
  • 该实体是否为不受控的第三方（如公共API调用者）？

过程（Process）

• 风险：逻辑缺陷与注入攻击
• 排查清单：
  • 该过程是否处理了来自外部实体的输入？它是否进行了输入验证（防SQL注入/命令注入/XSS）？
  • 该过程是否以高权限运行？（比如以管理员身份运行Web服务，风险极高）
  • 该过程是否记录了敏感数据（明文密码、信用卡号）的日志？
  • 是否存在未授权的过程调用？即从低安全级别过程直接调用高安全级别过程。

数据存储（Data Store）

• 风险：数据泄露与篡改
• 排查清单：
  • 静止数据：存储中的数据是否加密？（如数据库加密、文件系统加密）
  • 权限控制：谁可以读/写该存储？是否存在默认密码或弱密码？
  • 防篡改：是否存在审计日志记录谁修改了数据？
  • 生命周期：数据是否永久保留？是否有定期的清除或归档机制？（防止数据堆积后被批量窃取）

数据流（Data Flow）

• 风险：窃听与中间人攻击
• 排查清单：
  • 传输加密：数据流是否走TLS（HTTPS）传输？尤其是包含密码、Token、PII（个人身份信息）的数据流。
  • 敏感数据暴露：数据流中传输的内容是否包含了非必要的敏感信息？（查询接口传回了用户手机号，但前端可能并不需要）
  • 箭头方向：数据流是否形成了反向流？即低安全域的数据流能影响高安全域。（这是典型的信任边界突破风险）

第三步：标记“信任边界”与“高危路径”

这是DFD找风险最精华的一步：

1. 绘制信任边界：在DFD上用红色虚线画圈，信任边界通常是：互联网 <-> 外部防火墙 <-> DMZ区 <-> 内部网络 <-> 数据库内部。
2. 识别跨越边界的数据流：每一条穿过红色虚线的数据流，都是高危风险点。
   • 从“Web服务器（内部）”流向“数据库（内部）”的数据流，风险低。
   • 从“Internet用户（外部）”流向“Web服务器（DMZ）”的数据流，风险极高。
3. 分析跨越边界的风险：
   • 是否进行了深度包检测？
   • 是否使用了API网关进行统一鉴权？
   • 是否存在已知漏洞（如Log4j、Struts2）的服务处理该数据流？

一个典型的风险分析案例（DFD视角）

场景：在线购物系统 DFD简化图： 用户 -> Web服务器 -> 订单处理 -> 支付网关API -> 银行

风险排查过程：

1. 信任边界1（Web服务器与支付网关之间）：
   • 问题：支付网关API的HTTP响应中，是否携带了支付成功标记（如 payment_status=success）？
   • 风险：中间人修改该状态码，导致未支付成功但订单完成。对策：必须使用数字签名或Hmac校验数据完整性。
2. 数据存储（用户数据库）：
   • 问题：用户密码在存储时是什么形式？
   • 风险：明文存储或简单MD5。对策：使用Bcrypt/Argon2加盐哈希。
3. 数据流（订单处理 -> 日志文件）：
   • 问题：日志中是否记录了用户的完整信用卡号？
   • 风险：日志文件一旦泄露，造成大规模PCIDSS违规。对策：日志中只记录卡号后四位或掩码。

绘制检查清单

当你画完DFD后,可以直接使用这个清单逐项核对：

1. 所有外部实体是否都经过了认证和授权？
2. 所有从外部实体流入的数据是否都经过输入验证？
3. 所有流出到外部实体的数据是否都是最小必要数据且无敏感字段？
4. 所有跨信任边界的数据流是否都使用了加密传输（TLS）？
5. 所有数据存储是否都采用了加密存储（尤其是PII/财务数据）？
6. 是否存在某个过程可以不经授权直接访问另一个数据存储或过程？（例如内部员工后台绕过OA直接查数据库——需要权限隔离）
7. 是否存在数据流中的逆向控制？比如从静态资源服务器（CDN）反向影响到管理服务器？

通过这种“按图索骥”的方式，DFD可以把抽象的安全风险（如“数据可能泄露”）转化为具体的、可视化的数据流路径上的检查点，这是它作为风险识别工具的最大价值。