各位朋友，大家好。今天在此斗胆和大家交流一下，在生产型中大型企业中，如何更好地将企业的网络安全体系建设得更加均衡、更加完整。
当然，每个企业针对网络安全的投入是不同的：有的企业每年度可以投入百万级别，无论是安全设备的迭代更新，还是安全服务的线上防护，都是重视网络安全的表现；而有的企业由于管理层更看重销售或研发，对网络安全的投入少之又少。因此，本篇文档将着重于架构和思路的梳理，尽可能降低因设备差距而导致的方案实用性下降。
一、 知己知彼，百战不殆（基础资产收集）
对于一个企业来讲，网络安全隐患主要来自于两个方面：公网暴露的资源以及内网可以访问到的资源。因此，在开展所有防护工作之前，首要任务是做好资产梳理。
1. 公网暴露资产梳理
公网暴露的资源一般通过两个途径对外提供服务：
在出口负载均衡设备上，进行目的地址的 NAT 转换。
在 NAT 转换明细中，通过 Nginx 等反向代理服务器进行流量转发。
落地规范：
负载均衡映射规范：在负载均衡上配置目的 NAT 转换时，必须进行清晰的标签标识。推荐的命名格式为：业务系统负责人 + 业务系统名称 + 服务名称。这种命名方式能够将映射出去的业务形象化、明细化，便于在后续统计或汇总时，对暴露资产有一个明确的把控。
反向代理管控规范：通过 Nginx 转发出去的资产，应尽可能通过制度去约束。要求公网 Nginx 服务器配置文件的修改，必须提前向网络安全管理员进行报备审批。通过这种机制，确保公网暴露的资产始终在安全管理员的掌控之内。
以上资产梳理完毕后，公网暴露资产就有了明确的台账。这份明细，是后续日常防护的重中之重。
2. 内网资产梳理（日常治理的最大难点）
内网资产的治理和管控往往是最大的痛点。因为生产型企业中最末端的PC电脑终端最难管控，且中大型企业中的办公人员数量庞大。
(1) 设计理念：在网络架构设计上，要将内网逻辑化为外网。这意味着“没有真正意义上的安全内网”。在数据中心防火墙的访问控制列表（ACL）中，对所有内网源 IP 一视同仁。至于具体如何防护，我们在后面防火墙配置部分再行细说，此处对内网的逻辑结构点到为止。
(2) 跨部门协同推进技巧：内网资产的梳理必须体现“协同作战”的特性。首先需要明确：数据中心有多少台服务器？每台服务器归属于哪个项目？基础架构是什么？（例如：A项目有4台服务器，IP地址分别是什么，其中几台是应用服务器，几台是数据库，几台是负载均衡，最起码的项目架构要清晰明了）。接下来需要统计每台服务器使用了哪些中间件、运行了哪些应用、业务服务开启了哪些端口。
(3) 实战避坑指南：> 这个环节的难点在于，如果直接让运维人员去统计，由于跨部门协作且对方本职工作繁忙，他们往往会流于形式、应付了事，甚至不予理睬。这在企业中很正常。
此时应转换思路：直接对接运维负责人，提供标准化的信息统计模板，以 IT 审计的标准和要求推动运维负责人将任务下发。这样执行效率会高很多——毕竟如果运维负责人不配合，后续 IT 审计过关不了，他也难辞其咎。
(4) 阶段总结：内网服务器资产梳理明确之后，就为防火墙 ACL 策略的精细化配置打下了坚实的基础。我们要抱有极端的危机意识：必须假设内网任意一台电脑都有可能被远程控制，并以此为跳板攻击数据中心。
二、 边界防护
一般情况下，网络边界指的是内网的出口，通常由防火墙或负载均衡作为出口设备。我们此次讨论的是中大型生产企业，其网络组成部分通常包含：数据中心业务系统、生产终端、办公终端以及物联网（IoT）终端等（按设备的业务属性区分）。
因此，边界防火墙具备双重属性：
对内防护：对办公终端和生产终端进行基础上网安全防护。
对外防御：对业务系统或数据中心服务器进行基础的边界隔离。
如前文所述，在逻辑上切勿心存侥幸，没有真正的内网。相较于出口边界防火墙，真正防护核心业务系统的重中之重，其实是数据中心防火墙。我们先来讨论内网出口边界防火墙的防护思路，主要围绕以下三个核心维度展开：
1. 策略配置：由大到小，由普遍性到特殊性
由大到小（地域级防护）：如果公司的客户群体全部位于国内，应直接在防火墙上启用 Geo-IP 地域访问控制策略，仅允许中国境内 IP 访问。这样能主动屏蔽掉海量的国外恶意扫描和自动化攻击，危险系数直接降低不少。如果有国外客户，可针对性地放开特定国家区域的访问；如果客户是固定的企业，则直接使用白名单模式。
由普遍性到特殊性（已知威胁阻断）：普遍性的第一要务是防御业界公认的高危风险。例如：将勒索病毒常用的高危端口（如 445、135-139、3389等）在边界直接实施“一刀切”的封禁策略，从源头上降低内网 PC 终端和生产设备被勒索的风险。其次，积极收集近期活跃的恶意 IP 地址（如勒索软件相关、银狐木马团伙、非法代理通道等）以及涉政、违法的恶意域名，在边界防火墙全局阻断。若企业部署了安全探针（如 IDS/BPM），告警中的高危异常地址也应联动出口防火墙直接进行封禁。
特殊性（业务专属策略）：针对特殊业务需求（如 SaaS 混合云部署，一部分在公有云，一部分在公司本地数据中心），必须采用白名单模式。切记：绝不能将公有云的公网地址池直接全局加白。正确的做法是制定精细化 ACL 策略，仅允许公有云的固定源 IP 访问本地特定的服务器 IP，服务端口可以适度放行（毕竟这只是第一道边界防火墙，更细粒度的服务器明细策略应交由数据中心防火墙处理）。同理，公有云侧的策略也应反向限制，仅允许公司出口的固定公网 IP 访问其业务端口，确保双向业务运维和互通的安全。
2. 高可用性保障
在实际生产中，公司断网往往不是内部设备故障，而是由于外部绿化工程、道路施工等不可抗力挖断了运营商专线。绝大多数中大型生产型企业都会开通多条不同运营商的专线，但如何高效利用这些线路实现高可用？
假设 A 业务系统对外映射了8082端口，传统的做法通常是单一线路映射。一旦该线路中断，企业只能被动等待运营商修复，或者面临手动迁移业务出口、等待阿里云 DNS 解析生效等较长的业务中断时间（RTO）。
推荐的双活/主备配置方案：
线路一：A主域名.com+ 端口 --- 接入 A 公司的电信出口公网 IP + 自定义端口 --- 映射至 A 业务服务器 IP + 端口
线路二：A主域名.com+ 端口 --- 接入 A 公司的联通出口公网 IP + 自定义端口 --- 映射至 A 业务服务器 IP + 端口
通过在公有云 DNS 上配置智能解析（两条解析记录），同时在出口防火墙配置两条 NAT 策略。如此一来，即使其中一条专线意外中断，业务流量也会自动无缝切换，不会受到影响（除非遭遇双线同时被挖断的极端小概率事件）。
注意：公网暴露的自定义端口要避免冲突。当企业资产较多时，容易出现自定义外部端口撞车的情况，必须做好台账筛选，否则会导致业务访问异常。
3. 资产暴露面优化
在边界防火墙的暴露面优化中，我们重点针对“业务系统访问范围”这一典型场景进行收敛。许多业务在搭建之初就强制要求域名访问，这本身具备较高的灵活性（可通过前置 Nginx 解析明细自由调整）。但既然要求域名访问，是否意味着必须暴露在公网解析呢？这里需从两个属性来评估：
(1) 业务属性（用户群体分类）
内部特定/全员群体（如财务系统、HR考勤、ERP等）：这类系统完全不需要暴露在公网。可以通过两种技术方案完美解决：一是内网自建 DNS 服务器，将办公内网的首选 DNS 地址统一指向该服务器，实现域名内网解析；二是推行 VPN 机制，员工居家办公或出差时，必须先拨入公司 VPN 才能访问此类内部业务。
大客户/供应商群体（如商城系统、订单系统、供应链平台）：此类系统在理想状态下，边界应仅放行业务必需端口，且入向流量必须绑定供应商的固定公网白名单地址组。
大众开放类型：这类业务由于源地址不可控，只能配置Any to 业务端口的放行策略，具体的应用层防御思路我们放在数据中心防火墙部分详解。
(2) 服务属性（暴露端口分类）
管理类服务（如 SSH、远程桌面 RDP）：非必要严禁暴露至公网。若因极端特殊需求必须放行，必须满足三大铁律：修改默认端口号、入向流量必须限定为单一特定 IP（严禁放行地址段）、严禁不设白名单源地址。否则在高强度扫描下无异于自寻死路。
数据库类服务（如 MySQL、Oracle、SQL Server）：这类在 SaaS 混合架构中常见。同样遵循非必要严禁暴露原则，若必须对外互通，必须强制执行单一 IP 白名单策略，否则必须推动开发修改业务架构，没有商量余地。
普通标准前端服务（HTTP/HTTPS）：属于合规暴露，配合边界策略，日常重点关注此类业务的 Web 访问日志与防护告警即可。
三、 数据中心边界防护
数据中心防火墙是全公司核心资产的最后防线，既要保证业务的连续性（高可用），又要保证业务的安全性。为了同时防御内网跳板机横向攻击与互联网纵深渗透，规范运维行为，防止单点服务器被攻破后的横向移动（内网漫游），我们需要在此处实施更严厉的策略：
(1) 基本原则重申：同出口防火墙一样，遵循“由大到小、由普遍到特殊”原则。先把区域控制策略建立起来，再在数据中心防火墙上实施全局高危端口封禁（Any to Any Deny）。
(2) 严杀违规“影子软件”：特别是 Windows Server 服务器。很多第三方开发或外包运维人员喜欢滥用服务器下载资源或图方便远程。必须在应用层策略中，全局封禁百度网盘、迅雷，以及向日葵、ToDesk 等远程协助软件。如果运维人员借口需要用来传输文件或远程，一律不予通过——正规的业务部署和运维绝不允许使用此类商业远控软件，这往往是运维图省事或违规转包的隐患源头。
(3) 全面禁用 ICMP 策略（Any to Any Deny）：可能会有人质疑：“禁了 Ping，我怎么判断业务通不通？”实际上，当业务资产台账明确时，Ping 是非常低效的探测手段。因为即使网络层可达（Ping通），应用层端口服务是否异常依然无法判断。相反，允许 ICMP 意味着给内网横向扫描者提供了极大的便利。推荐替代方案：全面推行tcping工具（格式：tcping <IP> <Port>）。既能精准判断业务端口的存活性，又能最大程度隐藏数据中心服务器的存活状态。
(4) 运维双重痛点破局（Windows 与 Linux 分离管控）：
① Windows 运维痛点：传统模式下，若使用堡垒机，则必须放行3389端口，这导致横向防护和爆破防御变得极其困难；若不使用堡垒机，任由运维人员私自使用向日葵或 ToDesk，服务器就必须无限制连接互联网，存在巨大的合规与木马后门隐患。
a. 解决方案：内部私有化部署 RustDesk 远程连接系统，同时在出口防火墙阻断 RustDesk 的官方公共服务器。这样既能摆脱对外部互联网基础设施的依赖，又实现了不依赖 3389 默认端口的稳定远程运维。
b. 访问控制策略配置：严格限定仅允许合规的运维网段和 VPN 网段使用 RustDesk 连接服务器。
第一条：运维IP / VPN IP --- Any --- RustDesk端口 --- Permit
第二条：Any --- Any --- 远程端口/远控应用 --- Deny
（若存在特殊外包厂商白名单，在第一条之前加白即可）
② Linux 运维痛点：常见问题包括弱口令、默认22端口暴露、允许 root 直接登录等。这些必须作为硬性指标在服务器交付前完成加固。
访问控制策略配置：
第一条：运维IP / VPN IP --- Any --- 自定义SSH端口 --- Permit
第二条：Any --- Any --- SSH / FTP / SFTP相关运维端口 --- Deny
从而在网络层限定了运维的合法源地址与管理边界。
(5) 基于业务系统分组的精细化策略配置：在编写具体 ACL 时，必须以业务系统为分组单位，针对不同的技术架构分类规划。以下列举三种最常见的架构策略模板（注意：以下业务策略的优先级必须低于上述的全局高危阻断与运维管理策略）：
① 架构 A：普通单机架构服务器（单台服务器跑单一系统）
Any --- 业务服务器IP --- 业务服务端口 --- Permit
运维IP --- 业务服务器IP --- 中间件管理端口 --- Permit
Any --- 业务服务器IP --- Any Port --- Deny
注：业务部署完毕且无特殊外联需求时，可在边界防火墙将该服务器 IP 的外发（Egress）流量直接封禁，彻底斩断其反弹 Shell 或出向外联的能力，能极大降低安全隐患。
② 架构 B：C/S 或 传统两层架构（前端应用服务器 + 后端数据库服务器）
Any --- 应用服务器IP --- 业务服务端口 --- Permit
运维IP --- 应用服务器IP --- 中间件管理端口 --- Permit
运维IP --- 数据库服务器IP --- 数据库端口 --- Permit
Any --- 该项目服务器所有IP --- Any Port --- Deny
③ 架构 C：分布式/集群架构（Nginx 反向代理集群入口）
在此阶段只探讨网络层策略部署（Nginx 自身的应用层加固放在后续章节）。
Any --- Nginx虚拟IP --- 业务服务端口 --- Permit
运维IP --- 各节点服务器IP --- 中间件管理端口 --- Permit
Any --- 该集群服务器所有IP --- Any Port --- Deny
注：若架构中采用了虚拟 IP（VIP）结合两台硬件/软件负载均衡，必须根据 VIP 的位置进行策略补漏：若 VIP 部署在服务器侧（如 Keepalived 模式），既要放行 VIP，也要放行两台物理服务器实例的业务端口；若 VIP 部署在边界硬件负载均衡上，则 VIP 和两台物理实例的对应端口均需放行。凡事做最坏打算，切勿盲目迷信业务架构的绝对稳定性。
每一个项目都必须严格按照“用什么业务，放什么端口，限什么源地址”的标准去做策略和台账记录。这属于东西向流量的初步清洗，至此，数据中心防火墙的基线策略配置基本完成。
四、 服务器区域的横向隔离（东西向流量控制）
服务器区域的横向隔离，同样高度依赖第一阶段收集到的明确资产信息。每个项目包含哪些服务器、跑什么业务、采用什么架构，都要有清晰的标签。
1. 本地防火墙（Host-based Firewall）联动
我们首先要做好业务系统之间的互通隔离，特别是集群内部。建议在服务器本地全面启用iptables（Linux）或Windows Advanced Firewall。
隔离原则：仅放行集群内部所属 IP 之间的业务通信端口、运维管理端口及中间件同步端口。通过这种精细化隔离，基本可以实现“A集群的数据库绝不会被B集群的应用所越权访问”，达成最基础的东西向横向隔离。
2. 跨业务数据互通的破局思路
在实际生产中，业务系统之间不可能绝对孤立，往往存在数据交互需求（例如：有专门的数据中台或大数据汇聚系统需要定时抓取各个业务系统的数据）。
落地实操：当跨业务系统需要数据互通时，必须做细化到端口级的明细控制。例如：A集群的应用需要查询 B 集群和 C 集群的数据库。此时，B 和 C 的数据库服务器必须在本地防火墙（如 iptables）中，精准放行 A 集群应用服务器的源 IP 及对应的数据库监听端口。
安全人的职场情商：这种微隔离策略的制定和落地是非常考验运维和安全人员耐心的。在推进时，安全人员要充分发挥沟通技巧，多给予运维和协作人员正向的情绪价值（如在技术探讨时积极肯定对方的专业度），让运维人员在繁琐的策略配合中获得成就感。这非常有助于后续日常故障的协同排查，因为业务是动态发展的，横向隔离策略必然随着业务的变更而持续微调。
五、 高标准服务器交付规范
为了从源头管控风险，必须建立高标准的服务器上线与交付基线（以下为实践中沉淀的交付标准）：
1. Windows Server 交付标准
系统加固：根据业务需求安装对应的官方正版系统版本，全面跑完最新的安全补丁。使用合规的漏洞扫描工具进行全面扫描，原则上做到“高危、超危漏洞清零”交付。
运维配置：安装私有化 RustDesk 客户端，配置好企业专属的服务器地址与密钥。
密码策略：严禁弱口令。建议使用：项目名称简称 + 业务负责人简称 + 项目上线日期作为密码的组合元素。既有规律可循便于运维记忆，又能有效防御常见的自动化字典爆破。
会话安全：必须强制配置“1分钟无操作自动启用屏保并锁屏”。内网很多勒索事件的诱因，就是运维人员远程管理结束后忘记主动锁屏，且系统未配置自动锁屏，导致服务器大门敞开。
安全组件：在有条件的情况下，强制安装企业统一的 EDR（终端检测与响应）客户端。如果是虚拟化/私有云环境，在此节点务必制作干净的系统快照，防止后续因不规范操作导致系统崩溃。
防火墙联动：此时，数据中心防火墙 ACL 中应当同步建立该项目的专属分组，且最后一条兜底策略必须配置为Any --- 该业务系统IP --- Any Port --- Deny。
Windows 交付内容清单：服务器 IP 地址、操作系统非 root/admin 管理账户、RustDesk ID、自定义强密码、漏洞扫描“无高危”报告。
运维红线告知：签署运维规则(如严禁私自下载网盘、违规远控或任何与业务无关的绿色/盗版软件)。实际生产中曾发现有运维在服务器上安装 360 屏保，引发严重安全隐患，对此类行为必须在管理层面上严厉问责，不留面子。
2. Linux 操作系统交付标准（以 CentOS 7.9 / Rocky Linux 为例）
(注：鉴于 CentOS 7.9 已于 2024 年正式 EOL，对于存量老业务以此为例加固；对于新上线业务，强烈建议推行 Rocky Linux 或红帽系同类替代品。)
(1) 账户与权限控制：根据业务需求安装对应系统版本。严禁直接交付 root 账户。必须创建专属的普通运维账户（建议使用项目名称简写命名），其账户密码采用项目名称简写 + 乙方公司简称 + 服务器创建时间的强口令组合。不给予运维账户直接的 root 权限，敏感操作通过 sudo 审计授权。
(2) 磁盘分区核验：切记要严格按照业务需求书中的分区要求进行实操。若需求书中未明确说明，必须主动向业务方追问一句。许多外包或乙方人员在编写部署脚本时非常死板，如果由于分区不规范导致脚本执行报错，往往需要推倒重装系统，增加无谓的工作量。
(3) 协议与软件加固：系统安装完毕后，首要任务是升级 OpenSSH 和 OpenSSL 至当前稳定且无已知高危漏洞的版本。同样使用漏扫工具进行全面体检，“高危、超危漏洞清零”后方可交付。
(4) SSH 配置文件优化（/etc/ssh/sshd_config）：
PermitRootLogin no（硬性禁止 root 账户直接登录 SSH）
修改默认22端口为自定义的、避开标准扫描段的高位端口。
本地防火墙放行该自定义 SSH 端口。
开启 X11 转发（若业务确有图形化部署需求）。
(5) 安全组件与快照：同理，有条件的安装 EDR 客户端，虚拟化环境在此刻制作初始化快照备用。
(6) 防火墙联动：数据中心防火墙同步建立项目分组，配置兜底 Deny 策略。
(7) Linux 交付内容清单：
服务器 IP 地址、自定义 SSH 端口号、非 root 运维账户及强密码、漏洞扫描合规报告。
运维红线告知：严禁私自修改 SSH 配置文件、严禁私自创建未经报备的用户、严禁擅自删除或清理系统及业务日志。明确告知防火墙既定策略以及后续申请开通新端口的合规流程，流程闭环后方可正式移交。
