4、网络隔离：VPC与安全组设计、堡垒机架构、跳板机策略

说到远程运维，我最怕什么？

怕的是运维人员直接暴露在公网上。你想想看，一个22端口挂在公网，每天被各种扫描器问候，心里能踏实吗？

所以网络隔离这件事，说白了就是给云上资产建几道墙。我习惯把这道墙分成三层：网络边界隔离、主机访问控制、运维通道收敛。今天咱们就聊聊这三层怎么落地。

4.1 VPC设计：你的云上私有领地

VPC（虚拟私有云）是云上隔离的基础。我个人习惯，每个环境至少一个VPC，生产环境绝不跟测试混在一起。

举个例子，我去年帮一家金融客户做架构评审，发现他们把生产库和开发环境放在同一个VPC里。我问为什么？答曰「方便」。嗯，方便是方便了，但一旦开发环境被攻破，生产数据就裸奔了。

一个合理的VPC设计长这样：

• 生产VPC：严格隔离，仅开放业务端口和运维通道
• 测试VPC：模拟生产环境，但数据脱敏
• 开发VPC：自由度最高，但禁止访问生产资源
• 管理VPC：专门放堡垒机、跳板机，作为运维入口

这里有个坑——VPC对等连接。我曾经见过一个团队，为了省事把十几个VPC全部对等连接起来，结果整个网络拓扑变成了一张蜘蛛网，流量路径根本理不清。后来出了安全问题，排查了三天才找到入口。

4.2 安全组：你的第一道防线

安全组，说白了就是云上的iptables。但很多人把它当摆设——直接放行0.0.0.0/0，然后说「没事，我们还有防火墙」。

我建议的安全组设计原则：

1. 最小化放行：只开放业务必须的端口，比如Web服务器只放80/443
2. 源地址限制：管理端口（SSH/RDP）只允许堡垒机IP访问
3. 分层设计：应用层、数据层、缓存层各自独立安全组
4. 拒绝所有出站：除非业务需要，否则默认禁止出站流量

我记得有一次应急响应，客户说服务器被入侵了。我上去一看，安全组里赫然写着「0.0.0.0/0:22 - 允许」。攻击者就是从公网直接SSH进来的。你说这能怪谁？

4.3 堡垒机架构：运维的唯一入口

堡垒机是什么？就是所有运维操作的唯一入口。没有堡垒机，运维人员直接SSH到服务器，你根本不知道谁在什么时候干了什么。

我参与过的一个项目，堡垒机架构是这样的：

用户 → 堡垒机（公网入口） → 跳板机（内网代理） → 目标服务器
        ↑
    身份认证（LDAP + MFA）
        ↑
    操作审计（录屏 + 命令记录）

这里有个关键点：堡垒机本身不能有公网IP。你想想看，如果堡垒机暴露在公网上，那它不就成了最大的攻击目标？

正确的做法是：

• 堡垒机部署在管理VPC中，通过弹性公网IP（EIP）+ 白名单的方式对外暴露
• 白名单只放行运维人员的办公出口IP
• 堡垒机自身开启双因素认证（密码 + 动态令牌）

4.4 跳板机策略：内网的最后一道门

跳板机和堡垒机有什么区别？

堡垒机是入口控制，跳板机是内网代理。说白了，堡垒机管「谁能进来」，跳板机管「进来后能去哪」。

我设计的跳板机策略通常包含这几层：

层级	作用	示例
第一层	公网入口	堡垒机（公网IP + 白名单）
第二层	内网代理	跳板机（仅内网IP，无公网）
第三层	目标服务器	仅允许跳板机IP访问22端口

跳板机本身要做什么安全加固？

• 禁用密码登录：只允许密钥认证
• 限制登录用户：创建专用运维账号，禁止root直接登录
• 命令白名单：只允许执行特定命令（如ssh、scp、rsync）
• 会话超时：闲置5分钟自动断开

嗯，这里要注意——跳板机的密钥管理。我见过有人把跳板机的私钥放在共享目录里，结果所有人都能拿到。正确的做法是使用密钥管理服务（KMS）或者SSH Agent Forwarding，私钥永远不落地。

4.5 整体架构图

下面这张图是我常用的网络隔离架构，你可以参考一下：

这张图里，互联网只能触达堡垒机，堡垒机再通过跳板机访问内网资源。每个VPC之间通过安全组和网络ACL做隔离。说白了，攻击者想打到数据库，得先过三关：公网白名单、堡垒机认证、跳板机代理。每一关都够他喝一壶的。

好了，网络隔离这块就聊到这儿。记住一句话：能不放公网就别放，能加一层就别省。云上的安全，很多时候就是多一道墙的事。