文章总结： 本文从部署架构视角探讨系统安全设计，重点阐述通信加密（TLS协议版本、加密套件、数字证书）、网络层访问控制（IP白名单、最小权限原则）和应用层认证鉴权的实施要点，强调内外网均需落实安全措施以防范横向移动风险，并提醒注意DDoS防护及架构评审中的常见遗漏问题。 综合评分： 85 文章分类： 网络安全,应用安全,安全建设,解决方案,技术标准

信息安全体系之部署架构安全

原创

我是刘庆华 我是刘庆华

安全道

2026年4月12日 22:54 上海

在小说阅读器读本章

去阅读

在之前的<<信息安全体系之安全交付流程>>那篇文章中列举了整个交付流程中所涉及的主要安全实践，其中一个是部署架构安全设计，这篇文章展开讲一下如果评审/设计部署架构的安全。

部署架构也就是从部署拓扑视角审视系统安全，包含和外部系统的交互以及系统内部的服务间交互。画一张简单的示意图。

这是一个典型的有内外部交互的系统架构图，我们从部署视角看一下有哪些安全设计需要考虑，考量点包含通信加密、网络层(3层)访问控制、应用层(7层)访问控制等。

1.通信加密

先说外部通信，从架构图上看目标系统内部只有内部服务2会与外部系统/用户有交互，外部通信可能是经过公网传输，那么外部通信怎么能防止别人偷看或者篡改呢？最简单的方式就是对通信做加密。目前常用的加密方式是启用tls协议，利用通信协议本身对传输的数据进行加密保护，当tls被用于保护http访问时就是常说的https(即http over tls), tls还可以用于保护很多别的协议，例如ftp(ftps),ldap(ldaps)。

提到tls加密协议就不得不提到tls的几个重点：

1.1协议版本

自从Netscape在1995年提出SSL2.0,到变成RFC规范后的TLS1.0、1.1、1.2、1.3，协议一直在升级，目前比较安全的版本是1.2和1.3，建议首选1.3。

如果你在做安全架构设计，就可以在通信交互的线上标记tls1.2/1.3，如果你是在做架构安全评审，就可以问通信协议是否是tls1.2/1.3。

1.2Cipher Suites

加密套件集，每个加密套件会包含秘钥交换算法、批量数据加密算法、消息认证算法三部分，三个维度上不同算法及秘钥长度的组合就形成了加密套件集合。

如果你在做安全架构设计，虽然不用过问具体使用的Cipher，但至少要求一些弱的Cipher不可以使用，例如，批量数据加密算法是RC4、3DES的，消息认证算法是MD5的。不管是在做设计还是评审，可以要求tls协议所使用的Cipher必须是满足公司相关标准。不然很多项组没准儿就会用不安全的协议版本和加密套件，给系统带来风险。

1.3数字证书

既然使用TLS，就一定会用到X.509数字证书，要确保启用tls时证书是信任CA颁发的，除非是初期测试，不然不要使用自签名证书。

系统对外部的通信必须启用符合要求的加密协议，那么内部通信呢？内部通信也建议全部启用加密协议，系统内部通信也一样有被攻入截获的风险，我们应该摒弃那种认为内网就是高枕无忧没什么安全风险的思想，典型的场景就是办公网VPN，以为有VPN了，内网里的资源就不用担心了，事实上不管你是VPN还是云端的VPC都是有很多经过验证的手段可以攻入的，例如钓鱼、供应链攻击等，攻击者一旦进入了VPN/VPC，内部如果缺少必要的安全防护，攻击者就可以通过抓包工具随意窃取信息了，例如登录一些系统的用户名/密码，然后就可以进一步横向移动了。

2.网络层(3层)访问控制

还是从外部通信开始，如果你的系统会从公网访问，那么依据访问者的类型需要考虑不同的访问控制策略。

2.1访问者是机构

如果你的系统公网暴露API或者页面给某个机构访问，也就是B2B的访问，建议启用IP白名单机制，只允许机构从指定的IP地址来访问。这样就能过滤掉很多扫描和攻击。有些机构可能因为某些原因无法提供固定IP地址，那可以考虑使用mutual tls，即在tls层使用证书进行认证。也可以考虑加上时间窗口限制，也就是只有发生业务交易需要访问系统时打开公网访问，一旦业务交易结束，就关掉公网访问。

2.2访问者是toC个人用户

个人用户通常很难有固定IP地址，通常情况下不会使用IP白名单机制做3层的访问控制，但可以实现针对账户的网络层风险控制机制，这不属于架构范畴，这里就不展开了。

那对于内网，网络层访问控制要不要实现呢？和上一章节提到的加密一样，还是强烈建议内网也实现网络层访问控制，道理是一样的，最大限度防止攻击发生时的内网横向移动。

范例图上服务1和服务2是有通信的，那么针对服务1应该现限定其只能和服务2通信，且明确规定允许通信的协议和端口。同理，只有服务x会访问数据库，那么数据库侧就应该只允许服务x与其在设定的端口以允许的协议通信。架构图上每个点都应该遵循最小必要原则进行网络层访问控制。

3.应用层(7层)访问控制

暴露在系统边界给外部系统和用户使用的API或页面，需要依据业务场景在应用层做必要的认证授权，确保每个访问者只能访问被允许访问的资源。有人可能会说，暴露给外部机构的API，我做了IP白名单访问控制，还有必要在API层做认证鉴权吗？很明显是需要的，因为IP地址仅仅能说明访问是来自外部的某个机构，不代表那个机构里所有的服务或人员都有权限访问这个API，所以需要在API层做进一步的认证鉴权。

4.其它

部署架构的安全，还有些需要考虑的风险，比如DDoS攻击、外部访问者的不合理高频访问(这种不是真正的DDoS，但也会给系统造成资源开销过大，需酌情实现限速机制，系统韧性内容这里不展开)等，也需要纳入评审或设计中。

在实际的架构安全评审中，经常遇到这样的一类问题，需特备提起注意，设计者会因为各种原因遗漏掉内部或者外部的一些服务，导致其没能被安全评审所覆盖，并且多数情况下这些被遗漏的系统都有比较严重的安全问题，例如通信不加密或者没有应用层的认证鉴权。

架构的安全设计或评审并不是一件很难的事情，但需要设计者或者评审者多熟悉业务场景，细心细致，多问多思考，清晰标注，才能保证不会有遗漏。

2026年4月12日

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全道 我是刘庆华 我是刘庆华《信息安全体系之部署架构安全》