上周朋友公司刚上线的新电商后台，突然全站变慢，排查半天发现是测试环境的一台数据库服务器中了挖矿木马——它没被隔离，直接连着生产网段，CPU跑满后把核心交换机带宽也占了一半。
隔离不是画圈，是分层设防
很多人以为‘网络隔离’就是给不同部门拉几条独立网线，或者在防火墙上加几条 deny 规则。实际在数据中心里，光靠物理断开或粗粒度 ACL 已经扛不住现在的攻击节奏。真正的隔离得像医院的手术室：洁净区、缓冲区、污染区，层层过滤，权限最小化。
常见但容易踩坑的三种做法
1. VLAN 隔离当万能药
把开发、测试、生产全塞进不同 VLAN，再配个三层交换机做路由。听起来干净利落？问题来了：VLAN 本身不加密、不认证，一旦出现配置错误（比如 trunk 口误放通）、ARP 欺骗或 VLAN hopping，跨区访问就形同虚设。
2. 全靠防火墙策略兜底
某金融客户曾用一台万兆防火墙拦所有东西南北向流量，结果某次策略更新漏掉一条规则，财务系统的 API 接口意外暴露在 DMZ 区，三天后才发现。
3. 微服务一上云就放弃隔离
K8s 集群里 Pod 默认能互相 ping 通，很多团队直接跳过 NetworkPolicy，等出了横向移动事件才补救——这时候攻击者可能已经在 etcd 里逛完一圈了。
实用策略，从今天就能改的三件事
① 东西向流量必须上微隔离
别只盯着进出数据中心的流量（南北向），内部服务器之间的通信（东西向）才是重灾区。K8s 环境下，至少启用基础 NetworkPolicy：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
namespace: default
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress再按业务模块逐个放开，比如只允许订单服务访问支付服务的 8080 端口，其他一律拒绝。
② 生产环境禁用默认路由和 ICMP
运维登录跳板机后，习惯性 ping 一下目标 IP 看通不通。但这个动作本身就在暴露拓扑结构。建议：生产网段关闭 ICMP 回应，所有管理通道走带身份校验的 JumpServer，并开启操作审计日志。
③ 数据库绝不直连应用服务器
哪怕都在一个 VPC 内，也别让 Web 服务器直接连 MySQL 的 3306。中间加一层数据库代理（如 ProxySQL 或 Cloud SQL Auth Proxy），既能做连接池复用，又能统一拦截非法语句、记录慢查询来源。
某游戏公司把 Redis 实例从‘所有内网可连’改成‘仅限游戏逻辑 Pod 访问 + 密码+ TLS’后，黑产批量爆破失败率从 92% 降到 3%。
最后提醒一句
隔离策略不是写完就扔进 Git 的配置文件。每季度至少做一次‘越权探测’：挑一台低权限测试机，尝试访问不该访问的服务端口；用 nmap 扫一遍非业务端口；翻翻防火墙日志里有没有被反复拒绝的异常源 IP。真正的安全，藏在你愿意动手验证的细节里。