软件架构图是技术团队的主要沟通工具。它们弥合了抽象需求与具体实现之间的差距。然而，标准的架构图通常只关注功能和数据流，常常忽略了安全控制、信任边界和威胁缓解策略这一关键层面。当安全在设计阶段被视为事后补充时，漏洞会在任何代码编写之前就已嵌入系统之中。

C4模型通过图示的层级结构，为软件架构的文档化提供了一种结构化的方法。通过将安全考量融入C4层级的每一层，架构师可以创建一种视觉语言，清晰地传达风险、合规性以及保护机制。本指南探讨如何在上下文图、容器图、组件图和代码图中嵌入安全思维，而无需依赖特定工具或供应商。

🔍 为何在图示中实现安全可见性至关重要

安全往往在失效前都不可见。防火墙阻挡流量，加密扰乱数据，身份验证验证身份。这些机制至关重要，但在标准设计文档中却很少被描绘。当安全被隐藏时，审计变得困难，新成员难以理解，也难以应对不断演变的威胁。

将安全融入架构图中具有多项显著优势：

• 共同理解：安全团队和开发团队使用不同的语言。在与应用流程相同的图示中可视化安全控制，可以统一双方的理解。
• 威胁识别：图示突出显示数据流。每一条数据流都可能成为攻击向量。可视化这些路径有助于更轻松地识别数据可能被暴露或篡改的位置。
• 合规性审计：法规通常要求提供数据保护措施的证明。一份标注完善的架构图可作为设计阶段安全控制的证据。
• 事件响应：在发生安全事件时，了解数据存储位置及其流动方式至关重要。图示为遏制和修复提供了清晰的路线图。

🏗️ C4模型层级概览

C4模型是一种分层的软件架构文档方法。它从宏观视角逐步细化到实现细节。每一层服务于不同的受众，并提供不同粒度的信息。在适当的层级整合安全，可确保正确的信息传递给正确的人。

1. 上下文图（第1层）：描述系统在其环境中的情况。重点关注用户和外部系统。
2. 容器图（第2层）：描述高层次的技术结构。展示如Web应用、移动应用和数据库等软件系统。
3. 组件图（第3层）：描述单个容器的高层设计。展示控制器、服务和存储库等构建模块。
4. 代码图（第4层）：描述单个组件的实现。展示类和方法。这类图通常不会对外共享，但对于内部安全审查至关重要。

🌍 第1层：上下文图安全

上下文图是起点。它定义了系统边界。此层级的安全涉及信任边界和身份。你必须明确区分处于信任区域内部和外部的内容。

🔑 身份与访问管理

在上下文层级，最重要的安全要素是身份验证。你需要明确展示哪些人被允许与系统交互。

• 人类参与者：清晰标注用户。区分管理员用户和普通终端用户。管理员访问通常需要更严格的控制。
• 外部系统： 这些通常是薄弱环节。展示它们如何进行身份验证。它们是否使用API密钥、OAuth令牌或双向TLS？
• 信任区域： 使用视觉提示来表示信任边界。实线可能代表高信任度的内部连接，而虚线则代表低信任度的外部连接。

🔗 数据流安全

上下文图中的每一条线都代表一个数据流。并非所有数据流都同等重要。有些携带敏感信息，而另一些则携带公开的状态更新。

• 加密要求： 标记需要在传输过程中加密的数据流。使用诸如HTTPS 或 WSS.
• 个人身份信息（PII）处理： 如果数据包含个人身份信息，请标记该数据流。这可确保下游团队知道需要采取额外的保护措施。
• 身份验证机制： 标明该数据流是否需要身份验证。例如，持有者令牌 或 会话Cookie 的要求应标注在连接线上。

📦 第二层：容器图安全

系统边界确定后，容器图将其分解为可部署的单元。这就是技术安全控制变得可见的地方。容器通常是Web应用、移动应用、微服务或数据库。

🛡️ 网络安全与区域

容器通常分布在不同的网络区域中。可视化这些区域有助于理解网络分段。

• DMZ位置： 展示哪些容器暴露在公共互联网上。这些需要最高级别的审查。
• 内部服务： 展示哪些容器仅为内部使用。这些不应直接暴露在互联网上。
• 防火墙规则： 使用颜色编码或注释来标明哪些容器之间允许通信。这可在发生泄露时防止横向移动。

🔐 静态数据保护

容器通常会存储数据。无论是数据库、文件存储还是消息队列，存储介质都需要具备安全性。

• 静态加密：标明容器中存储的数据是否已加密。这对于合规性至关重要。
• 密钥管理：显示加密密钥的存储位置。这些密钥是由容器自身管理，还是由外部密钥管理服务管理？
• 数据分类：根据容器所持有的数据敏感程度对其进行标记。公开, 内部, 机密，或受限.

📡 协议安全

容器之间使用的协议决定了内部通信的安全态势。

• 内部 API：确保内部 API 不使用明文 HTTP。使用HTTPS 或 gRPC 加 mTLS.
• 服务网格：如果使用了服务网格，请标明容器之间的流量会自动加密并进行身份验证。
• 遗留协议：如果使用了 FTP 或未加密的 SMTP 等遗留协议，请将其标记为需要整改的风险区域。

⚙️ 第三级：组件图安全

组件图深入到单个容器内部，展示其逻辑构建模块。安全逻辑正是在此处实现。

🧩 认证与授权逻辑

安全逻辑通常分布在各个组件中。明确展示该逻辑所在位置至关重要。

• 认证处理程序：识别负责用户登录的组件。这些是攻击者重点关注的高价值目标。
• 授权中间件：展示访问控制检查发生的位置。是在控制器层面还是服务层面进行的？
• 令牌验证：指出验证安全令牌的组件。如果验证集中进行，可降低安全策略不一致的风险。

🛑 输入验证与净化

安全漏洞通常始于不良输入。组件图应突出显示输入被处理的位置。

• 入口点：标记接收外部数据的组件。这些是抵御注入攻击的第一道防线。
• 净化逻辑：展示负责在数据存储或处理前进行清理的组件。这可以防止SQL注入和跨站脚本攻击。
• 输出编码：指出数据在发送给用户前进行编码的位置。这可确保恶意脚本不会在浏览器中执行。

📊 日志记录与监控

安全操作依赖于日志。如果无法看到发生了什么，就无法检测到安全事件。

• 安全日志：识别生成与安全相关的日志的组件。例如：登录失败尝试、权限拒绝、配置变更等。
• 日志聚合：展示日志发送到的位置。是否发送到集中式日志服务？这可确保在组件被攻破时日志不会丢失。
• 敏感数据掩码：指出日志是否经过净化处理，以防止泄露凭据或敏感数据。

🧠 第四层：代码图安全

代码图是层级中最详细的。它展示类和方法。尽管这通常不会在开发团队之外共享，但对于深入的安全审查至关重要。

🔒 加密操作

在此层级，你可以精确看到加密是如何被使用的。

• 硬编码密钥：检查代码结构中是否存在硬编码的API密钥或密码。这些应被标记为关键漏洞。
• 算法使用： 确保使用强算法。应避免使用 MD5 或 SHA1 等弱算法。
• 随机数生成： 确保为会话 ID 和令牌使用加密随机数生成器。

🧪 安全性单元测试

安全性需求必须经过测试。代码图可以显示安全测试的定义位置。

• 安全测试用例： 识别专门用于安全测试的方法。这些测试应涵盖身份验证绕过、注入和访问控制。
• 集成测试： 展示安全控制在整体系统上下文中如何被测试。

🚧 信任区域与边界

在 C4 模型的所有层级中，信任区域都是一个反复出现的主题。信任区域是指安全控制一致且边界定义明确的区域。

区域类型	信任级别	典型控制措施	图示表示
外部互联网	零信任	防火墙、WAF、TLS	虚线红色边框
DMZ	低信任	严格过滤，有限访问	虚线橙色边框
内部网络	中等信任	网络分段、身份验证	实线蓝色边框
安全核心	高信任	加密、密钥管理、审计	实心绿色边框

可视化这些区域有助于利益相关者理解系统不同部分的风险状况。DMZ中的漏洞不应危及安全核心。这一概念被称为纵深防御。

🧩 C4 中的常见安全模式

某些安全模式在各类架构中频繁出现。明确记录这些模式可以节省时间并减少混淆。

🔑 API 网关模式

API 网关作为所有客户端请求的单一入口。它负责身份验证、速率限制和路由。

• 位置： 它位于外部用户和内部容器之间。
• 安全角色： 它将安全逻辑从各个服务中卸载，确保策略的一致性执行。
• 图示说明： 将网关标记为 认证/授权 标签。

🔒 数据加密模式

数据必须在静态和传输过程中都受到保护。这是基本模式。

• 传输中： 所有网络通信均使用 TLS。
• 静态： 加密数据库和文件存储。
• 密钥： 将密钥与数据分开存储。

👁️ 审计日志模式

每个关键操作都应被记录。这对于事后分析至关重要。

• 记录什么： 用户操作、系统变更和安全事件。
• 日志完整性： 确保攻击者无法篡改日志。
• 保留： 定义日志保留时长以满足合规要求。

🔄 维护与演进

安全不是一次性任务。系统在不断演进，威胁在不断变化，新的漏洞也会被发现。架构图必须随之演进。

📅 更新图表

当系统发生变更时，图表应随之更新。这能确保文档始终保持真实可信。

• 变更控制： 将图表更新集成到部署流水线中。
• 审查周期： 安排与安全团队定期审查架构图。
• 版本控制： 保留图表的版本，以追踪安全控制随时间的变化。

🧪 威胁建模集成

威胁建模是识别潜在安全威胁的过程。它与C4图相辅相成。

• STRIDE模型： 使用STRIDE模型（伪造、篡改、抵赖、信息泄露、拒绝服务、权限提升）来审查图表中的每个元素。
• 数据流分析： 逐一检查图表中的每条数据流。询问数据在每个环节是否都受到保护。
• 资产识别： 在图表中识别高价值资产。将安全工作重点放在保护这些资产上。

📝 安全图表检查清单

使用此检查清单，确保您的C4图具备安全准备就绪状态。

• [ ] 是否清晰标记了信任边界？
• [ ] 所有数据流是否都标明了传输中的加密？
• [ ] 存储容器是否都标明了静态加密？
• [ ] 认证点是否已标注？
• [ ] 敏感数据流是否已高亮显示？
• [ ] 外部依赖项是否已识别并评估？
• [ ] 网络段和区域是否已可视化？
• [ ] 日志记录和监控点是否已显示？
• [ ] 已知漏洞是否已记录？
• [ ] 图表是否与代码更改保持同步？

💡 关于安全可视化的最终思考

构建安全系统不仅仅需要编写安全的代码，还需要安全的设计。C4模型提供了一个强大的框架，用于可视化这种设计。通过将安全思维嵌入到每一个层级，从上下文图到代码级别，团队可以构建出默认具有韧性的系统。

安全是共同的责任。当图表清晰地传达安全控制措施时，开发人员、运维人员和安全工程师能够更有效地协作。这种共享的可见性降低了风险，并增强了对交付软件的信心。请记住，图表是一种动态文档，应像对待其所代表的代码一样认真对待。