OWASP CheatSheetSeries 微服务安全架构文档编制指南：收集架构安全信息的方法与实践-平芜编程栈

应用安全

【免费下载链接】CheatSheetSeries

The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics.

项目地址：https://gitcode.com/gh_mirrors/ch/CheatSheetSeries

点击查看免费下载

导读

本指南围绕 OWASP CheatSheetSeries 仓库中 Microservices based Security Arch Doc Cheat Sheet 的核心方法论展开：当应用采用微服务架构（无论是云原生还是本地部署）时，安全架构师与工程师往往缺少一份"为回答安全问题而设计"的架构文档。本文提供一套可落地的信息收集方案——识别构建块（服务、存储、消息队列、数据资产）及其关系，并以图表形式呈现，最终服务于威胁建模、最小权限、数据泄露与攻击面分析等安全实践。读完本文，你将掌握一套结构化的架构安全信息清单与关系建模方法，并能将其直接映射到 OWASP ASVS V1 架构验证要求。

为什么微服务架构需要专门的"安全架构文档"

微服务架构正越来越多地被用于云基础设施与本地基础设施中的应用系统设计与实现。与单体应用不同，微服务的数量多、边界分散、通信方式多样（同步/异步），在设计与实现阶段面临大量安全挑战。要应对这些挑战，首先必须围绕安全视角收集架构层面的信息——因为常规的业务架构文档（如系统拓扑、部署图）通常不足以回答安全问题。

本文的目标正是提供一个具体的、可操作的方案：应当收集哪些架构安全信息，以及如何用这些信息支撑应用安全实践。

需要回答的三类安全问题

在基于微服务架构的应用安全工作中，安全架构师/工程师通常要面对以下问题（这些问题主要对应 OWASP ASVS 的 V1"架构、设计与威胁建模要求"章节，本仓库中可参考 IndexASVS.md 与 IndexASVS4.md 的 V1 条目）：

威胁建模与最小权限原则的落实
- 某微服务访问其他微服务 API 时，最小需要哪些 scope 或 API Key？
- 某微服务访问数据库或消息队列时，最小需要哪些授权（grant）？
数据泄露分析
- 哪些存储或消息队列中包含敏感数据？
- 某微服务是否向特定数据库或消息队列读写数据？
- 某个微服务被哪些微服务调用？微服务之间传递了什么数据？
攻击面分析
- 安全测试时需要测试哪些微服务端点？

在大多数情况下，现有应用架构文档无法直接回答上述问题。接下来的章节将提出：收集哪些架构安全信息才能回答这些问题。

收集构建块（Building Blocks）信息

构建块是微服务架构的基本组成单元。信息收集分五类：应用功能服务、基础设施服务、数据存储、消息队列与数据资产。建议为每个构建块维护唯一 ID，供后续关系建模引用。

识别并描述应用功能服务（Application-Functionality Services）

应用功能服务实现一个或多个业务流程或功能（例如：存储客户详细信息、存储并展示商品目录）。针对每个应用功能服务，收集以下参数：

参数名	说明
服务名称（ID）	唯一的服务名称或 ID
简要描述	该微服务实现的业务流程或功能的简要描述
源码仓库链接	指定服务源码仓库的链接
开发团队	指定开发该微服务的团队
API 定义	若微服务暴露外部接口，指定接口描述的链接（例如 OpenAPI 规范）。建议定义使用的安全方案，例如为每个端点定义调用所需的 scope 或 API Key
微服务架构描述	指定微服务架构图、描述的链接（如可用）
Runbook 链接	指定微服务 runbook 的链接

实践要点：API 定义字段是整个清单中复用率最高的字段——它既是攻击面枚举的来源，也是最小权限分析中确定 scope/API Key 的依据。若服务尚未有 OpenAPI 规范，应优先补充，否则后续安全测试的端点枚举将失去权威来源。

识别并描述基础设施服务（Infrastructure Services）

基础设施服务（含远程服务）可能实现认证、授权、服务注册与发现、安全监控、日志记录等功能。针对每个基础设施服务，收集以下参数：

参数名	说明
服务名称（ID）	唯一的服务名称或 ID
简要描述	服务实现功能的简要描述（例如：认证、授权、服务注册与发现、日志、安全监控、API 网关）
源码仓库链接	服务源码仓库的链接（如适用）
服务文档链接	包含服务 API 定义、运维指南/runbook 等服务文档的链接

实践要点：基础设施服务往往是集中式安全控制的载体。例如在 Microservices Security Cheat Sheet 中介绍的 API 网关边缘层授权、集中式 PDP（Policy Decision Point）、日志收集代理等，都属于本清单中的基础设施服务。集中式安全控制验证（对应 ASVS V1 #1.1.6）直接依赖本小节的数据。

识别并描述数据存储（Data Storages）

针对每个数据存储，收集以下参数：

参数名	说明
存储名称（ID）	唯一的存储名称或 ID
软件类型	实现数据存储的软件（例如：PostgreSQL、Redis、Apache Cassandra）

识别并描述消息队列（Message Queues）

消息系统（例如 RabbitMQ 或 Apache Kafka）用于实现微服务间的异步通信机制。针对每个消息队列，收集以下参数：

参数名	说明
消息队列（ID）	唯一的消息队列名称或 ID
软件类型	实现消息队列的软件（例如：RabbitMQ、Apache Kafka）

实践要点：从安全角度，存储与消息队列需要区分对待：消息队列中的"在途数据"同样可能包含敏感资产，且异步通信绕过了同步调用链中的网关/代理控制，因此必须在关系模型中显式建模（见下文"服务到服务的异步通信"）。

识别并描述数据资产（Data Assets）

识别并描述由系统微服务/服务处理的数据资产。建议优先识别从安全角度有价值的资产（例如"用户信息""支付信息"）。针对每个资产，收集以下参数：

参数名	说明
资产名称（ID）	唯一的资产名称或 ID
保护级别	指定资产保护级别（例如：PII、机密）
附加信息	添加澄清性信息

实践要点：资产清单是数据泄露分析与敏感数据分类（对应 ASVS V1 #1.8.1）的起点。建议将资产 ID 与具体的字段/实体对应，便于在"服务到服务"通信描述中以资产口径说明"传递了什么数据"。

收集构建块之间的关系（Relations）

仅有构建块清单还不够——安全问题往往产生于构建块之间的交互关系。本阶段需要识别四类关系。

识别"服务到存储"关系

针对每个"服务到存储"关系，收集以下参数：

参数名	说明
服务名称（ID）	指定上文定义的服务名称（ID）
存储名称（ID）	指定上文定义的存储名称（ID）
访问类型	指定访问类型，例如"读"或"读/写"

实践要点：该关系是最小权限分析的核心输入：服务对存储的"读/写"访问权限应与"访问类型"列严格对齐，凡是"只读即可"的存储访问都应拒绝写权限。这也是 ASVS V1 #1.4.3 所要求的"最小权限"验证的数据基础。

识别"服务到服务"的同步通信

针对每个"服务到服务"同步通信，收集以下参数：

参数名	说明
调用方服务名称（ID）	指定上文定义的调用方服务名称（ID）
被调用服务名称（ID）	指定上文定义的被调用服务名称（ID）
使用的协议/框架	指定通信使用的协议/框架，例如 HTTP（REST、SOAP）、Apache Thrift、gRPC
简要描述	简要描述通信目的（是信息查询请求，还是状态变更业务功能的请求/命令）以及服务间传递的数据（如可能，用上文定义的资产口径描述）

识别"服务到服务"的异步通信

针对每个"服务到服务"异步通信，收集以下参数：

参数名	说明
发布方服务名称（ID）	指定上文定义的发布方服务名称（ID）
订阅方服务名称（ID）	指定上文定义的订阅方服务名称（ID）
消息队列（ID）	指定上文定义的消息队列（ID）
简要描述	简要描述通信目的（接收信息或状态变更业务功能的命令）以及服务间传递的数据（如可能，用上文定义的资产口径描述）

识别"资产到存储"关系

针对每个"资产到存储"关系，收集以下参数：

参数名	说明
资产名称（ID）	上文定义的资产名称（ID）
存储名称（ID）	指定上文定义的存储名称（ID）
存储类型	指定该资产的存储类型，例如"golden source"（黄金数据源）或"cache"（缓存）

实践要点："资产到存储"关系直接回答"哪些存储包含敏感数据"这一数据泄露分析问题，同时用于识别敏感数据的冗余副本——例如同一资产同时存在于"golden source"与"cache"中时，需要评估缓存副本是否引入了额外泄露面（缓存往往缺少与主存储同等级别的访问控制）。

创建应用架构的图形化呈现

在完成构建块与关系的收集后，建议以**服务调用图（services call graph）或数据流图（DFD）**的形式图形化呈现应用架构（上文定义的构建块与关系）。实现方式包括：

使用专用建模软件工具（例如 Enterprise Architect）；
使用 DOT 语言（Graphviz 的图描述语言），以代码形式描述节点与边，便于版本化管理。

实践要点：图形化呈现与威胁建模是相辅相成的。本仓库的 Threat Modeling Cheat Sheet 指出：数据流图（DFD）是最常见的系统建模方法，它必须以清晰的方式呈现信任边界、数据流、数据存储、进程以及可能与之交互的外部实体——这些正是上文收集的关系数据所包含的内容。也就是说，本文的清单输出天然就是 DFD 的素材：构建块对应 DFD 的进程/数据存储/外部实体节点，关系对应数据流边。同时，微服务与云原生应用的攻击面分析可参考 Attack Surface Analysis Cheat Sheet 中的相关章节（优先关注可被外部流量触达的组件，它们可能位于代理、负载均衡与 Ingress 控制器之后，并可能无预警自动扩缩容）。

将收集的信息用于安全软件开发生命周期实践

收集到的信息可用于多项应用安全实践，例如在定义安全需求、威胁建模或安全测试阶段使用。以下按实践场景给出实施建议及其与 OWASP 项目的映射。

攻击面分析

实施建议：要枚举安全测试中需要测试、威胁建模中需要分析的微服务端点，分析以下小节收集的数据：

识别并描述应用功能服务（参数"API 定义"）
识别并描述基础设施服务（参数"服务文档链接"）

OWASP 项目映射：OWASP ASVS V1 "架构、设计与威胁建模要求" #1.1.2（可参考本仓库 IndexASVS4.md）；并可与 Attack Surface Analysis Cheat Sheet 结合使用。

数据泄露分析

实施建议：要分析可能的数据泄露，分析以下小节收集的数据：

识别并描述数据资产
识别"服务到存储"关系
识别"服务到服务"同步通信
识别"服务到服务"异步通信
识别"资产到存储"关系

OWASP 项目映射：OWASP ASVS V1 #1.1.2；OWASP Top 10（2017）A3 敏感数据泄露。

应用的信任边界、组件与重要数据流论证

实施建议：要验证应用所有信任边界、组件与重要数据流的文档化与论证，分析以下小节收集的数据：

识别并描述应用功能服务
识别并描述基础设施服务
识别并描述数据存储
识别并描述消息队列
识别"服务到存储"关系
识别"服务到服务"同步通信
识别"服务到服务"异步通信

OWASP 项目映射：OWASP ASVS V1 #1.1.4。

应用高层架构分析

实施建议：要验证应用高层架构及其所有连接的远程服务的定义与安全分析，分析以下小节收集的数据：

识别并描述应用功能服务
识别并描述基础设施服务
识别并描述数据存储
识别并描述消息队列

OWASP 项目映射：OWASP ASVS V1 #1.1.5。

集中式安全控制实现验证

实施建议：要验证是否实现了集中的、简单（设计经济性）、经过审查、安全且可复用的安全控制，以避免重复、缺失、无效或不安全的控制，分析"识别并描述基础设施服务"小节收集的数据。

OWASP 项目映射：OWASP ASVS V1 #1.1.6。

实践要点：本仓库的 Microservices Security Cheat Sheet 对集中式控制的实现给出了架构层面的建议：推荐的微服务级授权模式是"带嵌入式 PDP 的集中式模式"（将授权策略集中定义、在微服务侧以库或边车形式存储与评估）；身份传播推荐采用可信签发者签名的内部实体表示结构；服务间认证可采用 mTLS 或令牌方案。这些建议可用来指导基础设施服务清单中"认证/授权服务"的设计评审。

最小权限原则的落实

实施建议：要定义微服务所需的最小权限，分析以下小节收集的数据：

识别并描述应用功能服务（参数"API 定义"）
识别"服务到存储"关系
识别"服务到服务"同步通信
识别"服务到服务"异步通信

OWASP 项目映射：OWASP ASVS V1 #1.4.3。

敏感数据识别与分类

实施建议：要验证所有敏感数据是否被识别并按保护级别分类，分析以下小节收集的数据：

识别并描述数据资产
识别"资产到存储"关系

OWASP 项目映射：OWASP ASVS V1 #1.8.1。

应用组件业务/安全功能验证

实施建议：要验证所有应用组件是否就其提供的业务或安全功能进行了定义与文档化，分析以下小节收集的数据（参数"简要描述"）：

识别并描述应用功能服务
识别并描述基础设施服务

OWASP 项目映射：OWASP ASVS V1 #1.11.1。

落地模板：一份可复用的收集表格示例

为了让方法论直接落地，可以将上文清单组织为如下 Markdown 模板（以"商品目录微服务"为例，字段仅供参考）：

构建块：应用功能服务

参数名	示例值
服务名称（ID）	catalog-service
简要描述	存储并展示商品目录，处理商品查询与库存变更
源码仓库链接	cheatsheets/Microservices_based_Security_Arch_Doc_Cheat_Sheet.md（示例仓库路径）
开发团队	Team-Catalog
API 定义	`catalog-service/openapi.yaml`（含各端点 scope 定义）
微服务架构描述	`docs/catalog-service-arch.md`
Runbook 链接	`docs/catalog-service-runbook.md`

关系：服务到服务同步通信

参数名	示例值
调用方服务名称（ID）	web-frontend
被调用服务名称（ID）	catalog-service
使用的协议/框架	HTTP (REST)
简要描述	查询商品信息（资产：商品目录）

关系：资产到存储

参数名	示例值
资产名称（ID）	Product-Catalog
存储名称（ID）	catalog-db
存储类型	golden source

总结

微服务架构的安全工作不能停留在"看部署拓扑"的层面，而应建立一套以回答安全问题为目的的架构信息清单：

构建块层：应用功能服务、基础设施服务、数据存储、消息队列、数据资产；
关系层：服务到存储、服务到服务同步/异步通信、资产到存储；
呈现层：以服务调用图或数据流图图形化呈现；
应用层：将清单数据映射到攻击面分析、数据泄露分析、信任边界论证、高层架构分析、集中式控制验证、最小权限、敏感数据分类与组件功能验证等安全实践。

这套方法论的输出与 OWASP ASVS V1"架构、设计与威胁建模要求"逐条对应，可直接作为安全评审、威胁建模与安全测试的输入基线。相关实践可进一步参考本仓库的 Microservices Security Cheat Sheet（认证授权与身份传播模式）、Attack Surface Analysis Cheat Sheet（攻击面管理）与 Threat Modeling Cheat Sheet（数据流图与威胁建模流程）。