设计健壮的软件系统不仅需要功能性逻辑，更需要以安全为基础的架构。当架构师可视化基础设施时，会使用UML部署图来规划硬件、软件和通信路径。然而，标准的图表常常忽略了保护所必需的关键安全层。将安全考虑直接融入部署模型，可以确保在设计阶段就识别出漏洞，而不是在生产阶段才被发现。
本指南探讨如何将安全控制、信任边界和合规要求嵌入UML部署建模中。通过将安全视为架构图中的首要要素，团队可以从一开始就构建出能够抵御威胁的系统。
🏗️ 理解部署环境
UML部署图表示系统的物理架构。它展示了构件、节点以及它们之间的连接关系。如果没有安全标注，这种视图仅具有结构性。要使其具备安全性，必须理解各个组件：
- 节点： 它们代表物理或虚拟的计算资源，可能是服务器、路由器或云实例。
- 构件： 它们是物理形式的信息，例如可执行代码、数据文件或库。
- 通信路径： 允许节点之间交换数据的网络连接。
在建模这些元素时，必须为每个节点应用安全上下文。一个通用的服务器节点是不够的。模型应区分面向公众的Web服务器和内部数据库服务器。这种区分在于每种节点所需的安全策略不同。
🔒 保护节点与硬件
节点是软件执行的物理或虚拟端点。在以安全为重点的模型中，每个节点都需要具备关于加固和访问控制的具体属性。
物理节点与逻辑节点
部署模型常常将物理硬件与逻辑实例混淆。安全建模必须将二者区分开：
- 物理节点： 它们代表实际的硬件，如服务器或物联网设备。安全考虑包括物理访问控制、防篡改措施和环境控制。
- 逻辑节点： 它们代表虚拟机、容器或云函数。此处的安全考虑集中在隔离性、虚拟机监控程序安全和运行时环境上。
硬件安全模块（HSM）
关键系统通常依赖专用硬件来执行加密操作。在图中，这些应被明确建模为专用节点。这突显了密钥管理并非发生在软件内存中，而是在安全的硬件边界内进行。
服务器加固状态
每个服务器节点都应携带有关其安全配置的元数据。这包括：
- 操作系统版本和补丁级别。
- 节点上激活的防火墙规则。
- 防病毒或终端防护状态。
- 为审计追踪启用的日志功能。
通过标注这些细节，架构师可以确保最终基础设施中的每个节点都不会被遗漏补丁或监控。
💾 保护构件与数据存储
构件是部署到节点上的文件和组件。并非所有构件都具有相同的威胁风险。一些构件包含敏感数据，而另一些则是公共库。安全建模需要根据敏感性和完整性要求对这些构件进行区分。
数据分类
部署模型中的数据存储必须根据分类级别进行标记。常见类别包括：
- 公开：仅保证可用性，不设其他安全控制。
- 内部：仅限组织内部网络访问。
- 机密：需要加密和严格的访问控制。
- 受限：高度敏感的数据，受监管合规性约束。
静态加密
在建模数据存储时，图表应明确标明数据在存储期间是否被加密。这对于合规性和数据保护至关重要。如果某个节点存储受限数据，该构件存储位置应标注加密符号或备注。
考虑以下场景：
- 数据库服务器： 应标明全盘加密或对敏感字段进行列级加密。
- 文件服务器： 可能需要对特定类型的文档进行加密。
- 缓存服务器： 通常存储会话令牌；需要严格的内存隔离。
构件完整性
确保部署的代码未被篡改至关重要。部署模型应体现构件验证机制，例如数字签名或校验和。这可确保只有受信任的软件在节点上运行。
🔗 保护通信路径
节点之间的连接往往是系统中最薄弱的环节。穿越这些路径的数据容易遭受窃听、篡改或拒绝服务攻击。部署图必须明确说明通信所使用的安全协议。
协议规范
节点之间的通用连线具有歧义。每个连接都应明确指定协议和安全层：
- HTTPS/TLS： 用于网页流量和API调用。
- SSH： 用于安全的远程管理。
- IPSec： 用于站点到站点的隧道连接。
- 未加密的TCP： 应避免使用，若无法避免则应作为风险突出显示。
端口管理
节点上开放的端口定义了其攻击面。在图中，管理员应记录哪些端口暴露于外部网络，哪些暴露于内部网络。这有助于识别不必要的暴露。
关键考虑因素包括：
- 入站端口： 流量从何处进入节点？
- 出站端口： 流量从何处离开节点？
- 管理端口： 用于管理的端口绝不能暴露在公共互联网上。
带宽与速率限制
安全也涉及可用性。拒绝服务攻击针对通信路径。模型应考虑速率限制策略。尽管不总是作为图示元素呈现，但架构应考虑到负载均衡器或防火墙等可缓解流量洪水的组件。
🛡️ 定义信任边界与区域
信任边界在部署建模中至关重要。它们定义了信任的终点和验证的起点。跨越信任边界需要进行身份验证和授权。可视化这些区域有助于利益相关者理解安全检查发生的位置。
网络分段
节点应分组为逻辑安全区域：
- DMZ（非军事区）： 面向公众的服务与内部资源隔离。
- 内部网络： 用于核心业务逻辑的可信基础设施。
- 管理网络： 专用于管理任务的网络，与用户流量隔离。
- 隔离区： 用于因安全风险需要隔离的系统。
信任级别
每个区域代表不同的信任级别。从低信任区域向高信任区域移动的数据必须经过审查。部署图应展示数据跨越这些边界时的流动情况以及涉及的安全网关。
防火墙规则
防火墙是这些区域的执行点。在模型中，防火墙应表示为区域之间的节点或网关。规则应进行总结，以显示允许通过的流量。
| 区域 | 信任级别 | 访问控制 | 需要加密 |
|---|---|---|---|
| 公共互联网 | 不可信 | 仅限白名单 | 是（TLS 1.2+） |
| DMZ | 低 | 限制入站 | 是 |
| 内部网络 | 中 | 基于角色 | 可选（内部） |
| 管理区域 | 高 | 需要多因素认证 | 是（强） |
🆔 建模身份认证与授权
安全不仅仅是硬件问题；它关乎谁以及什么可以访问资源。身份认证（你是谁）和授权（你能做什么）必须与基础设施一同建模。
身份提供商
应展示集中式身份管理。如果系统使用特定的身份提供商进行认证，则此节点应与所有依赖服务相连。这突出了依赖关系和潜在的单点故障。
认证机制
每个节点或服务应标明其支持的认证方法：
- 单点登录（SSO）： 用于面向用户的应用程序。
- API密钥： 用于服务间通信。
- 证书： 用于机器间通信。
- OAuth/OIDC： 用于委托授权。
授权策略
授权逻辑应在部署模型说明中记录。例如，数据库节点可能允许应用服务器读取访问，但拒绝写入访问。这些权限定义了数据流的安全性。
⚖️ 合规性与监管映射
许多行业在严格的监管框架下运营。部署图必须反映这些要求，以确保法律合规。未能建模合规性可能导致架构债务和法律处罚。
关键法规
根据行业不同，适用特定标准：
- GDPR： 要求在基础设施中具备数据保护和删除权能力。
- HIPAA： 要求对健康数据的访问和存储实施严格控制。
- PCI-DSS： 规范支付卡数据的处理和存储方式。
- SOC 2： 重点关注安全性、可用性和处理完整性。
数据驻留
某些法规要求数据必须保留在特定地理边界内。部署模型应标明节点的物理位置，以确保数据不会违反当地法律而跨境。
审计追踪
合规性通常需要日志记录。图中应标明日志生成和存储的位置。日志存储节点必须与操作节点分离，以防止日志被篡改。
🐛 图表中的漏洞识别
结构良好的部署图可作为漏洞识别的工具。通过可视化系统，架构师可在编写代码前发现潜在弱点。
单点故障
如果关键节点没有备份或冗余，就会构成风险。图中应突出显示高可用性配置。集群和负载均衡应清晰可见，以体现系统的弹性。
暴露的管理接口
管理接口（如SSH或RDP）是攻击者常见的入口点。如果图中显示这些接口直接暴露在互联网上，这是一个红色警告。它们应通过堡垒主机或跳板机进行路由。
未加密的通道
图中任何没有加密标记的线路都可能存在风险。安全审查应重点关注这些线路，并强制要求升级加密。
🧠 集成威胁建模
部署建模是正式威胁建模的前提。基础设施映射完成后，团队可以应用STRIDE等方法论，识别与架构相关的特定威胁。
威胁类别
将以下威胁映射到图中的元素：
- 伪造：攻击者能否伪装成一个节点或用户？
- 篡改：传输中或静态存储的数据能否被修改？
- 抵赖：用户能否否认所采取的操作？
- 信息泄露：敏感数据是否在日志或内存中暴露？
- 拒绝服务：系统能否被压垮？
- 权限提升：用户能否获得高于授权的访问权限？
数据流分析
追踪图中数据的流动。敏感数据从何处产生？在何处终止？在哪些点上被转换？每个转换点都可能是潜在的漏洞。
🔄 维护安全完整性
部署图不是静态文档。基础设施会发生变化，会打补丁，也会新增服务。模型必须随之演进，以维持安全完整性。
版本控制
部署模型应与代码库一起进行版本控制。这使团队能够随时间比较架构变更，并审计安全更新。
自动化验证
现代工具可以依据安全策略验证图表。如果新增节点未加密，工具应予以标记。这可确保模型保持准确和安全。
定期审计
必须定期审查部署模型。安全团队应确认物理基础设施与逻辑模型一致。两者之间的偏差会产生安全漏洞。
📝 最佳实践总结
将安全融入UML部署建模是一项战略要务。它将安全从被动检查转变为积极的设计要素。遵循这些指南，团队可以构建出天生安全的架构。
实施的关键要点包括：
- 标注节点：为每个服务器和设备定义安全状态。
- 标记路径：在所有连接上指定协议和加密方式。
- 定义区域：明确标记信任边界和分段。
- 建模认证：展示身份和访问是如何管理的。
- 映射合规性：确保监管要求可见。
- 定期更新：保持图表与环境同步。
安全是一个持续的过程。部署图是这一旅程的地图。一张清晰、准确且以安全为重点的地图，能确保整个旅程从始至终都安全无虞。
