微分段 Micro-segmentation：防止横向移动

Q: 微分段和 VLAN 有什么区别？

VLAN 是二层隔离，微分段是策略隔离。VLAN 只能按地理位置或部门划分，微分段可以按应用、按标签、按身份划分。VLAN 之间的访问靠三层路由，微分段之间靠策略引擎。简单说：VLAN 是物理隔离，微分段是逻辑隔离。

Q: 微分段会影响业务性能吗？

会有轻微影响（策略检查有开销），但现代方案（eBPF、硬件卸载）几乎无感知。关键是策略设计要精简，不要搞成千上万条规则。原则：默认拒绝，只放开必要的。

Q: 微分段和零信任是什么关系？

微分段是零信任的技术实现手段之一。零信任是理念（永不信任、始终验证），微分段是落地方式（按业务域隔离、最小权限访问）。没有微分段，零信任很难落地。

微分段这个词这两年很火，但真正落地好的不多。原因很简单：策略设计太难、运维成本高、业务方抵触。这篇文章不谈概念，直接说怎么设计策略、怎么落地、怎么避免踩坑。

横向移动攻击：为什么要做微分段

横向移动是攻击者入侵后的标准路径：

攻击者入侵前端服务器
    ↓
从前段服务器扫描内网
    ↓
找到数据库服务器
    ↓
渗透数据库，窃取数据

传统安全架构的弱点：一旦攻击者突破边界，内网几乎无防御。微分段的目标是让每个业务段独立防御，即使一个段被攻陷，攻击者也无法横向移动。

真实案例：2023 年某电商数据泄露事件

攻击路径：
1. 攻击者通过供应链攻击入侵营销系统服务器
2. 营销系统服务器在内网无隔离，可访问所有段
3. 攻击者扫描发现数据库服务器
4. 直接连接数据库，窃取 500 万用户数据
5. 停留 3 个月未被发现

原因：网络无微分段，营销系统和数据库系统在同一个大平层网络。

微分段策略设计原则

原则一：按业务域分段，不按部门分段

错误：按部门分段
财务部网段、研发部网段、运维部网段

正确：按业务域分段
订单系统段、用户系统段、支付系统段、日志系统段

理由：部门的网络访问需求不一样（财务要看订单、研发要写代码），但业务域的网络访问需求一致（订单系统只需要和用户系统、支付系统通信）。

原则二：默认拒绝，按需放行

# 错误策略：默认允许
allow all from any

# 正确策略：默认拒绝
default_deny all
allow from frontend to backend on port 8443
allow from backend to database on port 5432

原则三：策略最小化

# 错误策略：过于宽松
allow from any to database

# 正确策略：精确匹配
allow from pod(label=backend) to pod(label=database) on port 5432

Kubernetes 微分段实战

Kubernetes 原生支持微分段，通过 NetworkPolicy 实现。

基础配置

# 1. 默认拒绝所有入站流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
---
# 2. 允许监控流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring
  namespace: production
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: monitoring
    ports:
    - port: 9090
  policyTypes:
  - Ingress
---
# 3. 前端只允许从 LB 接收流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: frontend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: loadbalancer
    ports:
    - port: 8080
  policyTypes:
  - Ingress
---
# 4. 后端只允许从前端接收流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - port: 8443
  policyTypes:
  - Ingress
---
# 5. 数据库只允许从后端接收流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - port: 5432
  policyTypes:
  - Ingress

策略验证

# 查看 NetworkPolicy
kubectl get networkpolicy -n production

# 查看 Pod 标签（用于策略匹配）
kubectl get pods -n production --show-labels

# 测试连通性（应该失败）
kubectl run test -it --rm --image=busybox --namespace=production -- sh
# 在 Pod 内测试
wget -qO- --timeout=2 http://backend:8443/health
# 期望：连接超时（后端只允许从前端访问）

# 测试连通性（应该成功）
kubectl run test-frontend -it --rm --image=busybox --namespace=production --labels app=frontend -- sh
# 从前端 Pod 测试
wget -qO- --timeout=2 http://backend:8443/health
# 期望：成功（前端允许访问后端）

虚拟化微分段实战（VMware NSX）

虚拟化环境用 NSX-T 或 TIGER 做微分段。

NSX-T 微分段配置

# VMware NSX-T PowerShell CLI
# 1. 创建安全组（逻辑分段）
New-NsxSecurityGroup -Name "frontend-servers" -Description "Frontend tier"
Add-NsxSecurityGroupMember -SecurityGroup "frontend-servers" -Member @(
    "vm-frontend-01",
    "vm-frontend-02"
)

New-NsxSecurityGroup -Name "backend-servers" -Description "Backend tier"
Add-NsxSecurityGroupMember -SecurityGroup "backend-servers" -Member @(
    "vm-backend-01",
    "vm-backend-02"
)

New-NsxSecurityGroup -Name "database-servers" -Description "Database tier"
Add-NsxSecurityGroupMember -SecurityGroup "database-servers" -Member @(
    "vm-db-01",
    "vm-db-02"
)

# 2. 创建安全规则（默认拒绝）
New-NsxPolicySecurityRule -DisplayName "deny-all-default" -Direction Ingress -Action DROP
New-NsxPolicySecurityRule -DisplayName "allow-monitoring" -Direction Ingress -Action ALLOW -SourceGroups @("monitoring-servers") -DestinationGroups @("*") -Protocol TCP -DestinationPorts @("9090")

# 3. 创建安全规则（按业务域）
New-NsxPolicySecurityRule -DisplayName "frontend-to-backend" -Direction Ingress -Action ALLOW -SourceGroups @("frontend-servers") -DestinationGroups @("backend-servers") -Protocol TCP -DestinationPorts @("8443")

New-NsxPolicySecurityRule -DisplayName "backend-to-database" -Direction Ingress -Action ALLOW -SourceGroups @("backend-servers") -DestinationGroups @("database-servers") -Protocol TCP -DestinationPorts @("5432")

# 4. 验证策略
Get-NsxPolicySecurityRule | Format-Table DisplayName, Action, SourceGroups, DestinationGroups

TIGER 微分段配置（阿里云）

# 阿里云 TIGER 微分段 CLI
# 1. 创建安全组
aliyun tiger CreateSecurityGroup --RegionId cn-hangzhou --SecurityGroupName frontend-sg --Description "Frontend tier"
aliyun tiger CreateSecurityGroup --RegionId cn-hangzhou --SecurityGroupName backend-sg --Description "Backend tier"
aliyun tiger CreateSecurityGroup --RegionId cn-hangzhou --SecurityGroupName database-sg --Description "Database tier"

# 2. 添加安全组成员
aliyun tiger JoinSecurityGroup --RegionId cn-hangzhou --SecurityGroupId sg-frontend --InstanceId i-frontend-01
aliyun tiger JoinSecurityGroup --RegionId cn-hangzhou --SecurityGroupId sg-frontend --InstanceId i-frontend-02
aliyun tiger JoinSecurityGroup --RegionId cn-hangzhou --SecurityGroupId sg-backend --InstanceId i-backend-01
aliyun tiger JoinSecurityGroup --RegionId cn-hangzhou --SecurityGroupId sg-database --InstanceId i-db-01

# 3. 创建安全规则（默认拒绝）
aliyun tiger CreateSecurityRule --RegionId cn-hangzhou --SecurityGroupId sg-frontend --Direction ingress --Policy deny --SourceType Any --DestType Any

# 4. 创建安全规则（按业务域）
aliyun tiger CreateSecurityRule --RegionId cn-hangzhou --SecurityGroupId sg-backend --Direction ingress --Policy allow --SourceType SecurityGroupId --SourceValue sg-frontend --DestType Port --DestValue 8443/tcp
aliyun tiger CreateSecurityRule --RegionId cn-hangzhou --SecurityGroupId sg-database --Direction ingress --Policy allow --SourceType SecurityGroupId --SourceValue sg-backend --DestType Port --DestValue 5432/tcp

# 5. 验证策略
aliyun tiger DescribeSecurityRules --RegionId cn-hangzhou --SecurityGroupId sg-backend

物理网络微分段（ACL）

物理网络用 ACL 做粗粒度微分段。

交换机 ACL 配置（Cisco IOS）

! 1. 创建 ACL（默认拒绝）
ip access-list extended FRONTEND-TO-BACKEND
 deny ip any any
 permit tcp any any eq 8443

ip access-list extended BACKEND-TO-DATABASE
 deny ip any any
 permit tcp any any eq 5432

! 2. 应用到接口
interface Vlan100
 ip access-group FRONTEND-TO-BACKEND in

interface Vlan200
 ip access-group BACKEND-TO-DATABASE in

! 3. 验证 ACL
show ip access-lists FRONTEND-TO-BACKEND
show ip access-lists BACKEND-TO-DATABASE

路由器 ACL 配置（VyOS）

# VyOS ACL 配置
set policy route FRONTEND-TO-BACKEND rule 10 description 'Allow frontend to backend on 8443'
set policy route FRONTEND-TO-BACKEND rule 10 match source address '10.0.1.0/24'
set policy route FRONTEND-TO-BACKEND rule 10 match destination address '10.0.2.0/24'
set policy route FRONTEND-TO-BACKEND rule 10 match protocol tcp
set policy route FRONTEND-TO-BACKEND rule 10 match tcp flags syn
set policy route FRONTEND-TO-BACKEND rule 10 match tcp port 8443
set policy route FRONTEND-TO-BACKEND rule 10 action accept

set policy route FRONTEND-TO-BACKEND rule 999 description 'Deny all else'
set policy route FRONTEND-TO-BACKEND rule 999 action drop

set policy route BACKEND-TO-DATABASE rule 10 description 'Allow backend to database on 5432'
set policy route BACKEND-TO-DATABASE rule 10 match source address '10.0.2.0/24'
set policy route BACKEND-TO-DATABASE rule 10 match destination address '10.0.3.0/24'
set policy route BACKEND-TO-DATABASE rule 10 match protocol tcp
set policy route BACKEND-TO-DATABASE rule 10 match tcp port 5432
set policy route BACKEND-TO-DATABASE rule 10 action accept

set policy route BACKEND-TO-DATABASE rule 999 description 'Deny all else'
set policy route BACKEND-TO-DATABASE rule 999 action drop

# 应用到接口
set interfaces ethernet eth0 policy input route 'FRONTEND-TO-BACKEND'
set interfaces ethernet eth1 policy input route 'BACKEND-TO-DATABASE'

横向移动攻击防御案例

案例一：SQL 注入后的横向移动

攻击场景：

1. 攻击者通过 SQL 注入入侵前端 Web 服务器
2. 从前段服务器扫描内网，发现数据库服务器
3. 尝试直连数据库（应该被阻止）
4. 尝试利用后端 API 访问数据库（应该被审计）

微分段防御：

# 数据库段：只允许后端访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-restrict
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - port: 5432
  policyTypes:
  - Ingress
---
# 后端段：只允许前端访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-restrict
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - port: 8443
  policyTypes:
  - Ingress
---
# 前端段：只允许 LB 访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-restrict
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: frontend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: loadbalancer
    ports:
    - port: 8080
  policyTypes:
  - Ingress

攻击结果： - 攻击者入侵前端服务器后，无法直接访问数据库（NetworkPolicy 阻止） - 攻击者尝试访问后端 API，被记录审计日志 - 安全团队通过审计日志发现异常，及时响应

案例二：勒索软件横向传播

攻击场景：

1. 攻击者通过钓鱼邮件入侵员工电脑
2. 员工电脑感染勒索软件
3. 勒索软件从员工电脑扫描内网
4. 尝试感染文件服务器、数据库服务器

微分段防御：

# 员工网络段：限制访问资源段
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: employee-to-resource
  namespace: corporate
spec:
  podSelector:
    matchLabels:
      zone: employee
  ingress:
  - from:
    - podSelector:
        matchLabels:
          zone: vpn-gateway
    ports:
    - port: 443
  policyTypes:
  - Ingress
---
# 资源网络段：拒绝员工网络访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: resource-deny-employee
  namespace: corporate
spec:
  podSelector:
    matchLabels:
      zone: resource
  ingress:
  - from:
    - podSelector:
        matchLabels:
          zone: employee
    policyTypes:
    - Ingress  # 默认拒绝

攻击结果： - 勒索软件从员工电脑无法访问文件服务器（NetworkPolicy 阻止） - 勒索软件无法横向传播到其他段 - 感染范围限制在员工网络段

运维挑战与解决方案

挑战一：策略爆炸

问题：随着业务增长，策略数量爆炸式增长，运维困难。

解决方案：

# 使用标签选择器，减少策略数量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: tier-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      tier: database  # 所有数据库 Pod
  ingress:
  - from:
    - podSelector:
        matchLabels:
          tier: backend  # 所有后端 Pod
    ports:
    - port: 5432
  policyTypes:
  - Ingress

挑战二：业务变更频繁

问题：业务频繁变更，策略需要及时调整。

解决方案：

# 使用 GitOps 管理策略
# 策略配置文件放在 Git 仓库
# CI/CD 自动应用策略变更

# 策略变更流程
1. 开发人员提交策略变更 PR
2. 安全团队审核 PR
3. CI/CD 自动应用策略到测试环境
4. 测试环境验证策略
5. 策略应用到生产环境

挑战三：排障困难

问题：策略配置错误导致业务中断，排障困难。

解决方案：

# 策略预验证
kubectl plugin verify network-policy --dry-run

# 策略变更记录
kubectl audit network-policy --since 24h

# 实时策略效果查看
kubectl exec -n production test-pod -- wget -qO- --timeout=2 http://backend:8443/health

总结与判断

微分段的核心是"默认拒绝、按需放行"，按业务域分段而不是按部门分段。Kubernetes 用 NetworkPolicy，虚拟化用 NSX/TIGER，物理网络用 ACL。横向移动攻击防御的关键是阻断攻击者的内部扫描和直连路径。

我的判断：微分段是零信任落地的关键技术，值得投入。但要注意策略设计简洁、运维自动化、变更流程规范。策略爆炸和运维困难是最大风险，要用标签选择器和 GitOps 来应对。

微分段 Micro-segmentation：防止横向移动

横向移动攻击：为什么要做微分段

微分段策略设计原则

原则一：按业务域分段，不按部门分段

原则二：默认拒绝，按需放行

原则三：策略最小化

Kubernetes 微分段实战

基础配置

策略验证

虚拟化微分段实战（VMware NSX）

NSX-T 微分段配置

TIGER 微分段配置（阿里云）

物理网络微分段（ACL）

交换机 ACL 配置（Cisco IOS）

路由器 ACL 配置（VyOS）

横向移动攻击防御案例

案例一：SQL 注入后的横向移动

案例二：勒索软件横向传播

运维挑战与解决方案

挑战一：策略爆炸

挑战二：业务变更频繁

挑战三：排障困难

总结与判断

延伸阅读