软件架构图是开发团队的蓝图。它们传达了系统之间的交互方式、数据流动路径以及组件的结构。然而，标准的C4模型图通常缺少一个关键维度：安全。如果没有可视化安全边界，架构师和开发人员可能会无意中创建出信任假设不明确的系统，从而导致后期修复成本高昂的漏洞。将安全边界融入C4容器图，可确保风险管理工作在设计阶段就得到嵌入，而不是作为事后补充。
本指南探讨了如何在C4模型框架内有效表示安全控制、信任区域和数据保护机制。通过遵循既定规范，团队可以创建不仅结构清晰，而且具备安全意识的图表。这种方法有助于安全工程师、开发人员和业务利益相关者之间实现更有效的沟通。
🏗️ 安全视角下的C4模型
C4模型提供了一种分层的方式来记录软件架构。它包含四个层级：系统上下文、容器、组件和代码。在安全可视化方面，容器层级通常是最重要的。该层级描绘了Web应用、移动应用、API和数据库等高层级软件构建模块。
引入安全边界的目标是明确信任的终点和不可信环境的起点。一个缺乏安全上下文的容器图可能显示系统A与系统B通信，但无法揭示该连接是否经过加密、认证，或是否穿越公共网络。添加安全边界可以填补这一信息空白。
- 层级1（系统上下文）：有助于识别外部依赖关系，以及你的系统与用户或第三方之间的高层次信任关系。
- 层级2（容器）：本指南的主要关注点。在此层级，您定义内部区域、网络段和数据分类级别。
- 层级3（组件）：可用于详细的安全逻辑，例如认证模块，但通常过于细致，不适合高层次的安全审查。
通过聚焦于容器层级，架构师可以在抽象与细节之间保持平衡。这确保了安全决策清晰可见，而不会因过多实现细节而使图表过于复杂。
🧱 定义安全边界
安全边界代表信任发生变化的边界区域。跨越边界需要特定的控制措施，例如认证、授权或加密。在图表中，这些边界将具有相同安全态势或位于同一网络段内的容器分组在一起。
边界类型
理解不同类型的边界有助于选择合适的视觉表达方式：
- 网络边界：区分内部私有网络、公共互联网访问以及隔离环境（如DMZ，即非军事区）。
- 信任区域：区分完全可信的内部服务与部分可信的外部接口。
- 数据分类：将处理敏感数据（如个人身份信息、财务记录）的容器与面向公众的服务分组隔离。
- 合规区域：根据合规要求对系统进行分离，例如需要符合GDPR的系统与一般运营工具之间的区分。
信任与数据流
安全本质上关乎信任。容器之间的每一个连接都隐含着信任关系。如果容器A向容器B发送数据，说明A信任B能够正确处理该数据。如果B被攻破，A就面临风险。
可视化这种信任至关重要。C4图中的箭头表示数据流，但也应体现信任方向。边界线表明跨越它需要进行安全检查。例如，从”公共区域到内部区域应触发身份验证步骤。
🎨 在容器图中可视化边界
视觉语言的一致性是有效文档的关键。绘制安全边界时，符号应直观易懂。虽然没有单一的通用标准，但业界已形成了一些在C4模型中行之有效的惯例。
符号标准
大多数用于创建C4图的工具都支持自定义形状和样式。为表示安全边界，建议采用以下标准做法：
- 虚线：使用虚线包围一组容器。这表示逻辑分组，而非物理隔墙。
- 阴影区域：浅色背景可表示一个区域。例如，浅红色背景可能表示高风险的公共区域，而绿色则表示受信任的内部区域。
- 图标：在边界标签旁边添加一个小锁或盾牌图标，以表明安全控制已启用。
- 标签：明确命名边界。使用诸如公共网络, 安全区域，或DMZ.
颜色编码策略
颜色是一种强有力的信号。但必须有意识地使用。避免随意使用颜色。相反，应将颜色与安全状态对应起来：
- 红色/橙色：高风险，面向公众，不可信的输入源。
- 黄色：中等风险，DMZ，或半可信接口。
- 绿色/蓝色：低风险，内部，受信任的服务。
- 灰色：遗留系统或已弃用的组件，需要谨慎处理。
确保颜色选择具有可访问性。除了颜色外，还应使用图案或标签，以确保色觉缺陷用户也能读懂图表。
🔒 在图表中实施安全控制
划定边界后，下一步是标注跨越这些边界的连接。一条线跨越安全边界即构成安全事件，需要特定的控制措施。
加密与协议
用所使用的协议标注连接。这能让读者了解传输中数据的安全状态。
- HTTPS/TLS：网页流量的标准。如果相关，请注明版本（例如 TLS 1.3）。
- mTLS：双向 TLS 在微服务架构中很常见。这表明进行了强身份验证。
- SSH： 用于管理访问或内部文件传输。
- 未加密： 明确标注任何未加密的流量。这突出了需要修复的风险。
认证与授权
用户在哪里进行认证？哪个服务验证令牌？这些问题应能从图表中得到解答。
- API 网关： 通常作为入口点。将其标记为认证发生的边界。
- OAuth/SSO： 展示用户、网关和后端服务之间令牌的流动。
- 服务账户： 标明服务是否使用机器身份而非用户令牌进行认证。
🔄 常见的架构模式
某些架构模式在现代软件系统中频繁出现。这些模式具有特定的安全边界考量。
1. DMZ 模式
非军事区位于公共互联网和内部网络之间。它托管那些必须对外可访问但不应直接访问敏感数据的组件。
- 边界： 将 Web 服务器或负载均衡器包含在 DMZ 区域内。
- 连接： DMZ 通过受限制的端口或 API 端点与内部区域通信。
- 安全目标： 如果面向公众的组件遭到破坏，限制影响范围。
2. 使用服务网格的微服务
在微服务架构中，服务之间频繁通信。服务网格负责流量管理和安全。
- 边界： 每个服务都是独立的容器。网格创建一个逻辑叠加层。
- 连接： 所有内部流量均经过加密（mTLS）。
- 安全目标： 零信任。每个服务都必须验证其他每个服务。
3. 数据库分段
并非所有数据库都应一视同仁。敏感数据存储应被隔离。
- 边界： 将敏感数据库放置在专用子网或安全区域中。
- 连接： 只有特定的应用程序容器可以连接到数据库。
- 安全目标： 防止横向移动。如果应用程序容器被攻破，攻击者无法直接访问数据库。
📊 安全审查检查清单
在最终确定图表之前，进行安全审查。使用以下检查清单，确保所有必要的边界和控制措施都已体现。
| 检查项目 | 标准 | 为何重要 |
|---|---|---|
| 信任区域已定义 | 所有容器是否都已分配到信任区域？ | 明确安全控制措施需要部署的位置。 |
| 连接标签 | 协议和加密方法是否已标注？ | 确保传输中的数据是安全的。 |
| 认证点 | 认证的入口是否清晰？ | 标识访问控制发生的地点。 |
| 数据分类 | 敏感数据存储是否已隔离？ | 保护高价值资产。 |
| 外部依赖 | 第三方服务是否已标记？ | 突出显示供应链风险。 |
| 管理员访问 | 管理员访问是否受到限制？ | 防止未经授权的系统控制。 |
此表格在代码审查或架构决策记录（ADRs）期间可作为快速参考。它确保在设计阶段不会忽视安全问题。
⚠️ 安全反模式
避免错误与遵循最佳实践同样重要。以下反模式常出现在缺乏安全边界的图示中。
- 扁平化图示：将所有容器绘制在一个框内而没有区域划分。这意味着所有组件都受到同等信任，而这很少成立。
- 缺少加密标签： 显示箭头但未说明使用 HTTPS。这会导致数据保护措施不明确。
- 过度信任： 将面向公众的容器直接连接到数据库容器，中间未设置任何中介。这是典型的漏洞攻击路径。
- 静态边界： 在基础设施发生变化时未能更新图示。一张显示旧网络拓扑的图示，比根本没有图示更糟糕。
- 忽略数据流： 只关注静态结构，而忽略数据如何跨越边界流动。安全是动态的。
📈 维护与演进
安全边界并非一成不变。随着系统演进，新服务被添加，威胁也在变化。图示必须随之更新。将图示视为动态文档对于长期安全至关重要。
版本控制
将图示与代码一起存储在版本控制系统中。这使团队能够追踪安全边界随时间的变化。当发生安全事件时，审查图示历史可揭示边界是否缺失或配置错误。
自动化生成
在可能的情况下，从代码或基础设施即代码配置生成图表。这可以缩小文档与实际系统之间的差距。如果基础设施发生变化，图表会自动更新，确保安全边界保持准确。
定期审计
安排定期审查架构图表。在这些审查过程中，提出具体的安全问题：
- 是否有新增的依赖项跨越了边界？
- 加密标准是否仍然最新？
- 信任区域是否仍然与当前的网络拓扑一致？
- 是否存在应被移除以减少攻击面的未使用容器？
🔍 结论
将安全边界融入C4容器图，可将其从简单的结构图转变为全面的安全指南。这种做法明确了信任关系，突出了数据保护要求，并促进了团队之间的更好沟通。通过遵循一致的标注规范、标签协议，并长期维护图表，组织能够构建更具韧性的系统。
安全不是一种产品，而是一个过程。图表是这一过程中的工具。它们使无形变得可见，使架构师能够在风险演变为事件之前识别它们。投入时间进行准确且以安全为重点的文档编制，将在降低漏洞和加快事件响应方面带来回报。
从审计您当前的图表开始。识别信任边界缺失的位置。添加必要的区域、标签和颜色。随着时间推移，这种习惯将变得自然而然，使安全融入您描述架构时所使用的语言之中。