服务器网络规划须按业务角色和数据流向划分安全区域，DMZ仅限对外服务，生产网微服务间通过服务名通信，数据区仅响应白名单服务连接，研发与生产网严格隔离，外网流量统一收敛至DMZ反向代理，容器与云环境需结合身份标签、TLS双向认证、SELinux及服务元数据实施细粒度控制，所有策略须版本化、可审计、默认拒绝。

服务器公网与私网规划不能只看IP地址段，必须紧扣业务角色和数据流向来划清访问边界。核心是让网络结构反映真实业务逻辑，而不是按物理位置或子网“一刀切”。

按业务域而非IP段划分安全区域

研发网、生产网、办公网、DMZ区这些不是网络拓扑标签，而是业务信任等级的体现。比如：

• DMZ只放API网关、Web前端、邮件中继等对外服务，禁止部署数据库代理或配置管理后台
• 生产网（backend_net）运行订单、用户、风控等微服务，彼此通过服务名通信，但默认不暴露端口给公网
• 数据区（internal_net）仅接入MySQL、Redis、Elasticsearch，且只响应白名单服务（如order-service）在指定端口的连接请求
• 研发网与生产网之间需严格隔离，CI/CD流水线触发部署时，应通过带签名的内部API调用，而非直接SSH跳转

外网流量必须收敛到统一入口，禁止直连内网

所有来自互联网的请求，只能抵达DMZ中的反向代理（如Nginx或Kong），再由它转发至后端。关键控制点包括：

• 外层防火墙只开放443/80端口，源IP范围限制为0.0.0.0/0，目标限定为DMZ服务器VIP
• DMZ服务器禁止主动发起对内网的连接；如有必要（如查用户信息），须经内层防火墙白名单放行，且目标IP、端口、协议全部精确指定
• 员工从内网访问对外系统，应走公网域名路径（内网→SNAT→外网→DNAT→DMZ），确保流量经过统一WAF和审计策略
• 运维人员SSH登录DMZ服务器，必须使用跳板机+多因素认证，并绑定固定管理终端IP

容器与云环境需叠加身份感知控制

在K8s或Docker环境中，同一IP可能承载多个服务，仅靠IP+端口无法识别真实意图。需结合上下文增强判断：

• 用cgroup或Pod标签标记流量来源：nftables规则可匹配meta cgroup /payment，只允许该组访问3306端口
• 数据库连接启用TLS双向认证，防火墙配合conntrack识别已验证会话，仅放行ct state established且证书DN字段匹配的服务
• SELinux限制进程能力，例如禁止httpd_t域进程connect到database_port_t端口，从内核层切断非法调用链
• 云上安全组策略必须与服务注册元数据联动，如region=prod且deps=redis的Pod，才被允许加入backend_net→internal_net的访问白名单

策略闭环：从定义到审计不可断链

规则上线不是终点，而是持续验证的起点：

• 所有nftables策略必须通过Git版本管理，每次变更附带业务影响说明和回滚脚本
• 启用log prefix规则捕获越权尝试，并接入SIEM做实时告警（如“BLOCKED_CROSS_ZONE”日志每小时超5次自动触发研判）
• 每月执行一次策略有效性扫描：用nmap从DMZ发起探测，验证是否真能连通非授权内网IP和端口
• 默认策略必须是drop，任何accept规则都需明确标注责任人、有效期和业务依据，过期未续则自动失效