简介这是一份用于网站备案或安全检查场景的网络与信息安全保障措施方案文档面向网络管理员、信息安全负责人及需要编写安全自查报告的企事业单位人员。文档以表格加正文形式整理涵盖网站安全责任人信息、安全制度签订情况、防护设备部署、域名解析与运维方式等自查项并详细展开网络安全保障措施包括IDC机房硬件设施保障、操作系统与中间件配置、防火墙与入侵检测、漏洞扫描与日志审计、网页防篡改及信息发布管理等内容。包体为一个docx文件整体大小仅39KB轻量易用可直接在Word中编辑修改按实际环境勾选填写。目前已有42人学习下载可作为快速生成合规安全方案的基础模板帮助读者节省从零起草的时间同时了解从人员管理到技术防护的完整落地要点。1. 网络与信息安全保障措施到底是什么先解决“文档一张皮”的问题凌晨一点业务群弹出告警办公区某台PC正在往财务服务器发起大量异常连接。我当时的第一个动作不是去封IP而是翻那份《网络与信息安全保障措施.docx》——结果发现文档里写着“VLAN隔离”实际交换机上一个业务VLAN都没建。这类“制度文本与技术现状两张皮”的情况才是今天多数团队真正的安全缺口。这个标题看起来像一份交给检查材料的文档但它真正要解决的是三件事让网络边界可描述、让主机基线可核对、让数据恢复可演练。适合谁读做过半年以上网络或系统运维想把自己手里那套“经验”变成体系又不想被合规审查问倒的从业者。接下来我按“框架怎么搭、网络怎么做、主机怎么加固、坑在哪里、怎么验证”这条线把整套方案讲清楚。2. 从一份docx长成可落地框架先定边界再谈技术措施很多团队拿到“写保障措施”这个任务第一反应是打开Word复制模板。我不建议这么干。docx只是制度载体里面每一段话都应该对应一个能检查的配置项。写文档之前先立框架再谈技术否则写出来的永远是漂亮话。2.1 等保2.0里的控制项是保障措施的默认参照系目前国内做网络与信息安全保障绕不开等级保护2.0标准。如果你所在行业有行业规范以行业规范为准如果没有等保2.0就是最稳的参照系。我不建议把标准原文抄进文档而是把控制项翻译成“我要做哪些配置”。我一般把《网络与信息安全保障措施.docx》的正文按四个域组织安全通信网络、安全区域边界、安全计算环境、安全管理中心。这四个域对应到日常运维动作关系如下等保2.0控制域文档里对应的措施章节落地产物安全通信网络网络架构、通信传输VLAN划分表、IP规划表、网络拓扑图安全区域边界边界防护、访问控制防火墙策略、ACL规则、入侵检测安全计算环境身份鉴别、访问控制、入侵防范主机基线、口令策略、补丁清单安全管理中心系统管理、审计管理、集中管控日志审计平台、堡垒机、账号权限表每一章写措施时末尾加一列“检查方法”比如“查看核心交换机display acl config”或“登录审计平台查最近7天日志”。这样检查人员来的时候你不用临时翻配置直接把文档翻到对应页贴命令结果就行。2.2 最小权限原则账号、端口、数据流向三处收敛保障措施的核心思想不是“建一堆防御设备”而是最小权限也就是默认拒绝、按需放行。我把它落到三个地方账号、端口、数据流向。账号层面一人一号禁止共用账号离职账号当天禁用服务账户用随机高复杂度口令并设置密码永不过期避免拼写进运维手册被人翻到。端口层面只开放业务端口管理端口不对办公网开放数据库端口不对终端网段开放。数据流向层面画一张业务流量矩阵注明哪些网段可以访问哪些网段、走哪个端口其余全拒。这三个收敛动作必须在docx里写死而不是停留在口头约定。比如“财务服务器只允许业务服务器和运维管理网段访问3306端口”这句话写进文档后交换机ACL的配置依据就有了。等保测评师问“你的访问控制依据是什么”你直接指文档这一条再把交换机配置截图贴给他。2.3 文档目录按“资产、拓扑、责任人”搭措施才有检查依据我见过最怕检查的团队是因为连资产清单都没有。问“你有多少台服务器”答不上来问“这台交换机是管哪个楼层的”也答不上来。所以《网络与信息安全保障措施.docx》的目录我建议按下面的顺序搭每章都以表格为主、文字为辅第一章适用范围与职责分工。写明这份文档管哪些设备、哪些系统、谁是网络管理员、谁是安全管理员、谁是数据备份责任人。第二章资产清单。所有服务器、交换机、防火墙、安全设备的IP、型号、位置、责任人。第三章网络拓扑与区域划分。一张网络拓扑图配上VLAN与IP规划表。第四章访问控制策略。ACL与防火墙策略清单。第五章主机基线要求。口令策略、补丁周期、加固项。第六章日志审计与集中管理。日志平台信息、留存周期。第七章备份与恢复。备份任务清单、恢复演练记录。第八章应急响应。安全问题处理流程、应急联系人表。这份目录的好处是第2章和第3章是第4章到第8章的配置依据。没有资产清单就写ACL纯属空中楼阁。新同事入职让他照着第一章到第三章读一遍就能知道公司网络长什么样不用再抓着你问。3. 网络侧措施落地VLAN、ACL与防火墙策略一个网段都不能漏框架搭完进入最耗时的网络侧落地。这一章要解决的问题是办公区、服务器区、管理区之间到底怎么做到“访问可控”。很多小团队采购完交换机设备商交付时只做了VLAN1通全网相当于没做任何隔离。下面的做法是我在H3C和华为设备上都验证过的通用做法核心命令区别不大。3.1 先出VLAN划分与IP规划表设备配置才能闭环拿一张表规划好区域再动设备。不要一边配一边想容易漏网段。我通常按业务重要性分五类网段管理网段、办公终端网段、业务服务器网段、数据库网段、访客网段。举例VLAN名称网段用途说明VLAN 10MGMT192.168.10.0/24交换机、防火墙管理地址VLAN 20OFFICE192.168.20.0/24员工办公终端VLAN 30APP192.168.30.0/24Web、应用服务器VLAN 40DB192.168.40.0/24数据库、核心业务服务器VLAN 50GUEST192.168.50.0/24访客Wi-Fi仅通外网规划时注意两点一是管理网段和业务网段必须分开否则运维跳板机和业务服务器混在一起一旦业务侧被攻破管理面也暴露了二是给未来扩容留余量每个网段按实际需求的1.5倍规划不要卡得太死。交换机上创建VLAN并划分端口的操作很直接以H3C为例# 创建VLAN 10、20、30、40、50 vlan 10 name MGMT quit vlan 20 name OFFICE quit vlan 30 name APP quit vlan 40 name DB quit vlan 50 name GUEST quit # 将端口GigabitEthernet1/0/1划入VLAN 10端口类型为access interface GigabitEthernet1/0/1 port link-type access port access vlan 10 quit逻辑说明VLAN是二层隔离手段把广播域拆开让办公终端不能直接通过二层访问服务器。端口划入对应VLAN后三层通信得靠交换机上的VLAN接口和路由策略完成这就给ACL留出了检查点。参数说明access口用于接终端设备如果接的是另一台交换机要用trunk口并允许指定VLAN通过例如port link-type trunk port trunk permit vlan 10 20 30 40 50。VLAN编号保持全局唯一不要在一台设备上重复编号。每配完一个VLAN建议立即保存配置并做一次ping测试避免攒了一批配置后出了错都集中在最后排查。3.2 在核心交换机上用ACL收紧东西向流量VLAN做完只是第一步。如果VLAN 20的办公终端可以直接访问VLAN 40的数据库服务器隔离就形同虚设。需要在三层交换机或核心防火墙上配置ACL把东西向流量按业务矩阵收紧。常见做法是办公终端网段只放行到应用服务器的80/443端口只有应用服务器可以访问数据库服务器的3306端口管理网段可以SSH到所有网络设备。其余流量一律拒绝。H3C核心交换机上的配置示例# 配置高级ACL 3001限制办公终端访问数据库网段 acl advanced 3001 rule 5 deny ip source 192.168.20.0 0.0.0.255 destination 192.168.40.0 0.0.0.255 rule 10 permit tcp source 192.168.20.0 0.0.0.255 destination 192.168.30.0 0.0.0.255 destination-port eq 80 rule 20 permit tcp source 192.168.20.0 0.0.0.255 destination 192.168.30.0 0.0.0.255 destination-port eq 443 rule 100 deny ip quit # 将ACL应用到VLAN 20的三层接口的入方向 interface Vlan-interface 20 packet-filter 3001 inbound quit逻辑说明rule 5是核心动作——明确拒绝办公终端到数据库网段的所有IP流量。rule 10和rule 20放行办公终端访问应用服务器的HTTP和HTTPS端口。rule 100 deny ip是兜底拒绝防止前面漏掉的流量。ACL匹配顺序是自上而下所以精确放行规则必须先写兜底拒绝放最后。参数说明源和目的反掩码要和VLAN网段严格对应0.0.0.255是/24网段的通配符写法写错会导致规则匹配不到流量或误伤其他网段。packet-filter应用方向建议选inbound即在流量进入VLAN 20接口前先检查减少核心交换机处理压力。配完后用display acl 3001查看规则命中计数再用办公区一台PC尝试访问数据库服务器IP的3306端口应该超时。这一条测试记录截图保存后面写措施文档时作为“访问控制措施有效”的证据。3.3 防火墙策略先拒绝、再放行变更留单号到了边界区域防火墙策略比ACL更细。小团队最常见的翻车点是策略顺序乱放行规则写在拒绝前面结果拒绝规则永远不生效。我在防火墙上的习惯是先在全局建一条“默认拒绝”规则再在其上方放行必要业务。以华为USG系列防火墙的常见配置逻辑为例# 进入安全策略视图 security-policy # 先创建一条默认拒绝规则保证未明确放行的流量都被丢弃 rule name deny_all action deny description default_deny_20240601 # 再创建业务放行规则放行办公网访问应用服务器 rule name permit_office_to_app source-zone trust destination-zone untrust source-address 192.168.20.0 24 destination-address 192.168.30.0 24 service http service https action permit description TICKET-20240528-01 quit逻辑说明默认拒绝规则放最后因为防火墙策略通常按名称或序号匹配匹配到就停止。把deny_all放在最后则所有未命中的流量都会掉进兜底规则被丢弃。我把变更单号写进description字段比如TICKET-20240528-01这样半年后查“这条策略是谁加的、为什么加”时不用翻聊天记录。参数说明source-zone和destination-zone必须和防火墙接口划分的安全区域一致。多数防火墙默认有trust、untrust、dmz三个区域把内网接口划入trust、外网接口划入untrust。如果业务分流复杂建议自建区域比如server区和office区策略更容易读懂。防火墙策略做完后要做一次可达性验证。用办公网一台PC跑iperf3测吞吐和延迟# 在应用服务器上启动服务端 iperf3 -s # 在办公区PC上测到应用服务器的TCP吞吐测试时长10秒 iperf3 -c 192.168.30.10 -t 10 -i 1逻辑说明iperf3 -s在被测目标上开启服务端监听默认端口5201客户端用-c指定目标地址-t 10表示持续测试10秒-i 1表示每1秒打印一次结果。如果吞吐数值明显低于交换机端口协商速率说明中间链路上有QoS限制或接口协商异常如果直接失败则要检查安全策略是否放行了5201端口测试完记得删除这条临时放行策略。这一层做完网络侧措施就具备“可描述、可检查”的条件了。配上网络拓扑图和VLAN表写入docx网络保障部分基本成型。4. 信息安全侧措施落地基线加固、日志审计与备份恢复网络侧解决的是“谁可以访问谁”信息安全侧解决的是“主机本身是否扛得住”。这一章覆盖三件事主机基线加固、日志集中审计、备份恢复。这三件事做得越实安全兜底能力越强。4.1 Windows与Linux基线加固口令策略、远程管理、共享服务主机基线是措施文档里最好写、也最容易骗人的部分。写好口令策略不难难在把服务器真正按策略改一遍。我先说Windows侧再说Linux侧。Windows Server的加固项我用secedit命令把安全策略导出、按基线模板修改后再导入。导出的配置是inf文件适合批量核对# 导出当前安全策略到C盘根目录文件名baseline.inf secedit /export /cfg C:\baseline.inf # 修改inf文件中的密码策略项 # PasswordHistorySize 12记住12个历史密码 # MinimumPasswordLength 12最短12位 # MaximumPasswordAge 9090天强制过期 # 配置完成后重新导入到本机安全数据库 secedit /configure /db C:\Windows\security\local.sdb /cfg C:\baseline.inf /areas SECURITYPOLICY逻辑说明secedit /export导出的是当前生效的安全策略适合先做现状摸底secedit /configure再把改好的模板导入系统。/areas SECURITYPOLICY表示只导入安全策略域避免误改其他设置。参数说明密码历史12条、最短密码长度12位、最长使用期限90天这是我用的最低标准。如果业务系统比较老旧12位密码可能在兼容性上有问题可以降为8位再逐步调。关键是用/areas限定导入范围不给生产系统造成额外风险。Linux侧的基线加固操作更频繁。我常用的命令范围锁定在SSH配置和系统口令策略上# 备份原始sshd_config防止改错后回滚不了 cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date %F) # 禁止root直接远程登录 sed -i s/^#PermitRootLogin.*/PermitRootLogin no/ /etc/ssh/sshd_config sed -i s/^PermitRootLogin.*/PermitRootLogin no/ /etc/ssh/sshd_config # 禁止空密码登录 sed -i s/^#PermitEmptyPasswords.*/PermitEmptyPasswords no/ /etc/ssh/sshd_config sed -i s/^PermitEmptyPasswords.*/PermitEmptyPasswords no/ /etc/ssh/sshd_config # 语法检查通过后重载SSH服务 sshd -t systemctl reload sshd逻辑说明sed -i直接修改文件并备份原文件防止手滑改坏配置后连不上机器。sshd -t做语法检查检查不通过不重载服务这是防止把自己锁在外面的关键一步。参数说明date %F会生成类似2025-01-01的日期后缀便于保留多天备份。修改PermitRootLogin后日常运维必须通过普通用户登录再su切换root。如果公司内部有堡垒机我建议在此基础上再限制SSH登录来源IP写入/etc/hosts.allow或防火墙规则让SSH服务只对管理网段开放。4.2 把日志集中起来审计别让日志留在失陷机器上日志审计是措施文档里容易被低估的一环。默认情况下每台Linux服务器只在本机记日志。机器被入侵后攻击者第一件事就是清日志本机日志根本留不住。所以必须做集中日志收集。我在内网部署一台日志服务器用rsyslog把所有Linux服务器的认证日志和syslog转发过去Windows则通过Winlogbeat或系统事件转发。Linux侧的配置非常简单# 在日志服务器上开启TCP 514监听并把接收到的日志写入独立文件 # 在/etc/rsyslog.conf中取消注释以下两行 # $ModLoad imtcp # $InputTCPServerRun 514 # 在被采集的服务器上追加转发配置 echo *.* 192.168.200.10:514 /etc/rsyslog.conf # 重启rsyslog使配置生效 systemctl restart rsyslog逻辑说明表示走TCP传输单个表示UDP。日志审计建议选TCPUDP在流量大时会静默丢包日志不完整等于白收。*.*表示所有facility和所有级别的日志都转发真实环境也可以按需过滤比如只转发auth和authpriv。参数说明日志服务器IP要固定端口默认514。在防火墙或安全组里只放行内网管理网段到日志服务器的TCP 514端口不要对这个端口做全网开放。日志留存周期我按法规最低要求做6个月每台设备按天切割日志文件文件名含日期索引查询时用grep或zabbix日志监控都方便。没有集中日志措施文档里的“审计”就是空话。有了日志平台后还要给个“黑匣子”可查的样子每周写一条定时任务校验日志服务器上近24小时各主机的日志数量低于阈值触发告警。这样才能知道日志链路没断。4.3 备份策略按恢复目标反推先算RPO与RTO再定频率备份是信息安全里最不该省的一块。很多团队买了NAS、挂了盘备份任务一直是绿的真到恢复那天发现备份文件是坏的。我先讲策略再讲命令。措施文档里不写“每周备份一次”而是写“RPO不超过24小时RTO不超过4小时”。这两个指标决定频率和方式系统类型RPORTO建议备份方式保留周期核心数据库≤15分钟≤2小时实时同步 每日全量全量保留30天增量保留90天应用服务器≤24小时≤4小时每日增量每周全量全量保留12周网络设备配置每次变更后≤1小时配置自动备份脚本保留最近20个版本Linux服务器用cron加tar做定时归档是稳定且便宜的做法# 每周日2点执行全量打包排除临时目录和缓存 0 2 * * 0 tar czf /backup/app_$(date \%F).tar.gz --exclude/var/cache --exclude/tmp /var/www /etc /opt # 每月第一个周日把全量备份拷贝到异地目录 0 3 1-7 * 0 rsync -av /backup/ rsync://192.168.200.10/backup/逻辑说明tar做全量打包--exclude排除缓存目录避免备份体积膨胀rsync把备份推到内网另一台存储防止本机硬盘损坏时备份一起丢失。$(date \%F)在cron里需要转义写成\%F直接手写Shell脚本就不会有这个坑。参数说明备份文件一定要在备份任务结束的当天做一次恢复抽查——不用恢复整机只要解压关键目录比对文件数即可。把恢复验证记录写进措施文档的第七章这一栏在安全检查和事故追责时是实打实的证据。5. 避坑清单设备配置与基线加固里最容易翻车的四个地方方案看着完整真正落地时翻车的概率不低。下面四条是我做过多个项目后整理的高频坑每一条都踩过写出来供你对照排查。5.1 Docker容器网络不通业务网段和Docker网桥地址冲突现象容器部署完后容器内访问宿主局域网内业务服务器IP时超时但宿主本机访问正常。看着像防火墙拦截其实问题常常出在网段冲突或转发开关上。原因Docker默认的bridge网段是172.17.0.0/16如果业务网段恰好用了172.x段容器路由就会混乱另一种常见情况是宿主机的ip_forward内核开关被关掉导致容器流量无法路由到外部。解决在/etc/docker/daemon.json里指定一个不冲突的容器网段而不是用默认值# 指定docker0网桥为10.10.0.1/24段避免与业务网段对冲 cat /etc/docker/daemon.json EOF { bip: 10.10.0.1/24 } EOF # 重启Docker使配置生效同时确认转发开关已打开 sysctl -w net.ipv4.ip_forward1 systemctl restart docker说明bip是bridge IP的简写指给docker0网桥分配的子网。配置后用ip addr show docker0确认网段变更成功再进入容器测试到业务服务器的连通性。5.2 Linux改DNS后一重启就还原被NetworkManager接管现象手动修改/etc/resolv.conf后当时生效重启网络服务或重启机器后DNS又被改回去。有些同行遇到这问题就直接把NetworkManager禁用结果无线和有线网络管理也跟着废了。原因NetworkManager管理着连接配置文件重启时会按连接配置重新生成resolv.conf手动编辑的内容被覆盖。解决把DNS写进连接配置而不是直接改resolv.conf# 查看当前活动连接的名称一般是ens33或eth0 nmcli connection show # 给连接配置两个DNS服务器auto-dns改为no防止自动获取的DNS覆盖它 nmcli connection modify ens33 ipv4.dns 223.5.5.5 114.114.114.114 ipv4.ignore-auto-dns yes # 重新激活连接生效 nmcli connection up ens33说明ipv4.ignore-auto-dns yes是关键它告诉NetworkManager不要用DHCP下发的DNS覆盖手动配置。配置后查看/etc/resolv.conf内容应该不会再被还原。5.3 基线加固把业务锁死服务账户密码过期导致集群下线现象给一批Windows服务器配置了90天密码过期策略结果第二天数据库集群的多个节点同时掉线业务侧报连接失败。原因域内或本地的服务账户没有排除在密码过期策略之外。人工账户定期改密是对的但服务账户是机器使用的不会登录去改密码到期后凭据失效整个集群就断了。解决区分人工账户和服务账户。在密码策略里单独建一条针对服务账户的例外服务账户采用随机20位以上复杂密码设置“密码永不过期”同时严格限制该账户的登录权限只允许在指定服务器上登录。这个操作应该在基线加固前就完成而不是加固后等故障暴露。5.4 备份任务显示成功恢复时却找不到可用数据现象备份系统告警一直显示正常真到数据丢失时打开备份目录发现最新一份完整备份是两周前的增量文件缺了一大段。原因备份任务只管“备份动作执行成功”不校验备份结果是否可恢复。常见是源端数据库在备份过程中有写入导致备份文件内部不一致或备份存储空间满了最新增量没写进去但任务状态没报错。解决两条路同时走。一是备份任务完成后立刻做一次文件完整性验证比如对比备份前后源目录的文件计数和总大小二是我个人的经验是每月做一次恢复演练把数据库备份恢复到临时实例执行SELECT COUNT(*)核对关键表行数再把应用目录备份解压到临时路径做文件对比。备份是安全措施里唯一的“后悔药”药不能作假。措施文档里如果只写了备份策略没有恢复演练记录我会认为这条措施不成立。6. 用演练和自查清单验证保障措施是否真能扛住事方案写完了配置也推了最后要回答的问题是“这些措施到底有没有用”。我习惯用两种方法验证一种是断网演练一种是半年度自查清单。6.1 断网应急演练把交换机断电看监控与响应流程是否成立找个周末低峰期挑一台汇聚交换机直接断电。别提前通知运维同事看监控平台是否按预期产生告警看值班人员能否在10分钟内定位到故障设备看响应手册里的联系人电话能不能打通。断电演练能暴露三类问题监控漏配、应急预案过时、交换机没有保存配置导致上电后业务异常。演练结束后写一份简要记录放进docx的第八章。6.2 半年度自查清单按“边界、主机、数据、账号”四个域逐项核对我按四个域做了一张自查表每半年对着设备逐项过一遍。表里的验证手段都是我日常会跑的命令域检查项验证方法边界VLAN和ACL是否和文档一致核心交换机执行display acl all逐一对比规则边界防火墙是否还有长期放行的临时策略登录防火墙导出策略清单查description为空或带test的策略主机服务器口令策略是否符合基线Windows执行net accountsLinux查看/etc/login.defs主机高危端口是否仍然对外开放在办公网用nmap -p 22,3389,3306扫管理网段数据备份任务最近一次恢复验证记录是否存在核对备份平台日志与恢复演练记录日期账号离职人员账号是否已禁用导出账号列表与HR离职名单比对这套自查做完把结果表更新到docx末尾的检查记录页。我自己的习惯是每个季度打开一次《网络与信息安全保障措施.docx》对着自查清单过一遍配置和文档不一致的当天修掉。指望一张文档保护网络是不可能的但它能让你在凌晨收到告警时知道该往哪台设备看。希望帮到你。本文还有配套的精品资源点击获取
简介这是一份用于网站备案或安全检查场景的网络与信息安全保障措施方案文档面向网络管理员、信息安全负责人及需要编写安全自查报告的企事业单位人员。文档以表格加正文形式整理涵盖网站安全责任人信息、安全制度签订情况、防护设备部署、域名解析与运维方式等自查项并详细展开网络安全保障措施包括IDC机房硬件设施保障、操作系统与中间件配置、防火墙与入侵检测、漏洞扫描与日志审计、网页防篡改及信息发布管理等内容。包体为一个docx文件整体大小仅39KB轻量易用可直接在Word中编辑修改按实际环境勾选填写。目前已有42人学习下载可作为快速生成合规安全方案的基础模板帮助读者节省从零起草的时间同时了解从人员管理到技术防护的完整落地要点。1. 网络与信息安全保障措施到底是什么先解决“文档一张皮”的问题凌晨一点业务群弹出告警办公区某台PC正在往财务服务器发起大量异常连接。我当时的第一个动作不是去封IP而是翻那份《网络与信息安全保障措施.docx》——结果发现文档里写着“VLAN隔离”实际交换机上一个业务VLAN都没建。这类“制度文本与技术现状两张皮”的情况才是今天多数团队真正的安全缺口。这个标题看起来像一份交给检查材料的文档但它真正要解决的是三件事让网络边界可描述、让主机基线可核对、让数据恢复可演练。适合谁读做过半年以上网络或系统运维想把自己手里那套“经验”变成体系又不想被合规审查问倒的从业者。接下来我按“框架怎么搭、网络怎么做、主机怎么加固、坑在哪里、怎么验证”这条线把整套方案讲清楚。2. 从一份docx长成可落地框架先定边界再谈技术措施很多团队拿到“写保障措施”这个任务第一反应是打开Word复制模板。我不建议这么干。docx只是制度载体里面每一段话都应该对应一个能检查的配置项。写文档之前先立框架再谈技术否则写出来的永远是漂亮话。2.1 等保2.0里的控制项是保障措施的默认参照系目前国内做网络与信息安全保障绕不开等级保护2.0标准。如果你所在行业有行业规范以行业规范为准如果没有等保2.0就是最稳的参照系。我不建议把标准原文抄进文档而是把控制项翻译成“我要做哪些配置”。我一般把《网络与信息安全保障措施.docx》的正文按四个域组织安全通信网络、安全区域边界、安全计算环境、安全管理中心。这四个域对应到日常运维动作关系如下等保2.0控制域文档里对应的措施章节落地产物安全通信网络网络架构、通信传输VLAN划分表、IP规划表、网络拓扑图安全区域边界边界防护、访问控制防火墙策略、ACL规则、入侵检测安全计算环境身份鉴别、访问控制、入侵防范主机基线、口令策略、补丁清单安全管理中心系统管理、审计管理、集中管控日志审计平台、堡垒机、账号权限表每一章写措施时末尾加一列“检查方法”比如“查看核心交换机display acl config”或“登录审计平台查最近7天日志”。这样检查人员来的时候你不用临时翻配置直接把文档翻到对应页贴命令结果就行。2.2 最小权限原则账号、端口、数据流向三处收敛保障措施的核心思想不是“建一堆防御设备”而是最小权限也就是默认拒绝、按需放行。我把它落到三个地方账号、端口、数据流向。账号层面一人一号禁止共用账号离职账号当天禁用服务账户用随机高复杂度口令并设置密码永不过期避免拼写进运维手册被人翻到。端口层面只开放业务端口管理端口不对办公网开放数据库端口不对终端网段开放。数据流向层面画一张业务流量矩阵注明哪些网段可以访问哪些网段、走哪个端口其余全拒。这三个收敛动作必须在docx里写死而不是停留在口头约定。比如“财务服务器只允许业务服务器和运维管理网段访问3306端口”这句话写进文档后交换机ACL的配置依据就有了。等保测评师问“你的访问控制依据是什么”你直接指文档这一条再把交换机配置截图贴给他。2.3 文档目录按“资产、拓扑、责任人”搭措施才有检查依据我见过最怕检查的团队是因为连资产清单都没有。问“你有多少台服务器”答不上来问“这台交换机是管哪个楼层的”也答不上来。所以《网络与信息安全保障措施.docx》的目录我建议按下面的顺序搭每章都以表格为主、文字为辅第一章适用范围与职责分工。写明这份文档管哪些设备、哪些系统、谁是网络管理员、谁是安全管理员、谁是数据备份责任人。第二章资产清单。所有服务器、交换机、防火墙、安全设备的IP、型号、位置、责任人。第三章网络拓扑与区域划分。一张网络拓扑图配上VLAN与IP规划表。第四章访问控制策略。ACL与防火墙策略清单。第五章主机基线要求。口令策略、补丁周期、加固项。第六章日志审计与集中管理。日志平台信息、留存周期。第七章备份与恢复。备份任务清单、恢复演练记录。第八章应急响应。安全问题处理流程、应急联系人表。这份目录的好处是第2章和第3章是第4章到第8章的配置依据。没有资产清单就写ACL纯属空中楼阁。新同事入职让他照着第一章到第三章读一遍就能知道公司网络长什么样不用再抓着你问。3. 网络侧措施落地VLAN、ACL与防火墙策略一个网段都不能漏框架搭完进入最耗时的网络侧落地。这一章要解决的问题是办公区、服务器区、管理区之间到底怎么做到“访问可控”。很多小团队采购完交换机设备商交付时只做了VLAN1通全网相当于没做任何隔离。下面的做法是我在H3C和华为设备上都验证过的通用做法核心命令区别不大。3.1 先出VLAN划分与IP规划表设备配置才能闭环拿一张表规划好区域再动设备。不要一边配一边想容易漏网段。我通常按业务重要性分五类网段管理网段、办公终端网段、业务服务器网段、数据库网段、访客网段。举例VLAN名称网段用途说明VLAN 10MGMT192.168.10.0/24交换机、防火墙管理地址VLAN 20OFFICE192.168.20.0/24员工办公终端VLAN 30APP192.168.30.0/24Web、应用服务器VLAN 40DB192.168.40.0/24数据库、核心业务服务器VLAN 50GUEST192.168.50.0/24访客Wi-Fi仅通外网规划时注意两点一是管理网段和业务网段必须分开否则运维跳板机和业务服务器混在一起一旦业务侧被攻破管理面也暴露了二是给未来扩容留余量每个网段按实际需求的1.5倍规划不要卡得太死。交换机上创建VLAN并划分端口的操作很直接以H3C为例# 创建VLAN 10、20、30、40、50 vlan 10 name MGMT quit vlan 20 name OFFICE quit vlan 30 name APP quit vlan 40 name DB quit vlan 50 name GUEST quit # 将端口GigabitEthernet1/0/1划入VLAN 10端口类型为access interface GigabitEthernet1/0/1 port link-type access port access vlan 10 quit逻辑说明VLAN是二层隔离手段把广播域拆开让办公终端不能直接通过二层访问服务器。端口划入对应VLAN后三层通信得靠交换机上的VLAN接口和路由策略完成这就给ACL留出了检查点。参数说明access口用于接终端设备如果接的是另一台交换机要用trunk口并允许指定VLAN通过例如port link-type trunk port trunk permit vlan 10 20 30 40 50。VLAN编号保持全局唯一不要在一台设备上重复编号。每配完一个VLAN建议立即保存配置并做一次ping测试避免攒了一批配置后出了错都集中在最后排查。3.2 在核心交换机上用ACL收紧东西向流量VLAN做完只是第一步。如果VLAN 20的办公终端可以直接访问VLAN 40的数据库服务器隔离就形同虚设。需要在三层交换机或核心防火墙上配置ACL把东西向流量按业务矩阵收紧。常见做法是办公终端网段只放行到应用服务器的80/443端口只有应用服务器可以访问数据库服务器的3306端口管理网段可以SSH到所有网络设备。其余流量一律拒绝。H3C核心交换机上的配置示例# 配置高级ACL 3001限制办公终端访问数据库网段 acl advanced 3001 rule 5 deny ip source 192.168.20.0 0.0.0.255 destination 192.168.40.0 0.0.0.255 rule 10 permit tcp source 192.168.20.0 0.0.0.255 destination 192.168.30.0 0.0.0.255 destination-port eq 80 rule 20 permit tcp source 192.168.20.0 0.0.0.255 destination 192.168.30.0 0.0.0.255 destination-port eq 443 rule 100 deny ip quit # 将ACL应用到VLAN 20的三层接口的入方向 interface Vlan-interface 20 packet-filter 3001 inbound quit逻辑说明rule 5是核心动作——明确拒绝办公终端到数据库网段的所有IP流量。rule 10和rule 20放行办公终端访问应用服务器的HTTP和HTTPS端口。rule 100 deny ip是兜底拒绝防止前面漏掉的流量。ACL匹配顺序是自上而下所以精确放行规则必须先写兜底拒绝放最后。参数说明源和目的反掩码要和VLAN网段严格对应0.0.0.255是/24网段的通配符写法写错会导致规则匹配不到流量或误伤其他网段。packet-filter应用方向建议选inbound即在流量进入VLAN 20接口前先检查减少核心交换机处理压力。配完后用display acl 3001查看规则命中计数再用办公区一台PC尝试访问数据库服务器IP的3306端口应该超时。这一条测试记录截图保存后面写措施文档时作为“访问控制措施有效”的证据。3.3 防火墙策略先拒绝、再放行变更留单号到了边界区域防火墙策略比ACL更细。小团队最常见的翻车点是策略顺序乱放行规则写在拒绝前面结果拒绝规则永远不生效。我在防火墙上的习惯是先在全局建一条“默认拒绝”规则再在其上方放行必要业务。以华为USG系列防火墙的常见配置逻辑为例# 进入安全策略视图 security-policy # 先创建一条默认拒绝规则保证未明确放行的流量都被丢弃 rule name deny_all action deny description default_deny_20240601 # 再创建业务放行规则放行办公网访问应用服务器 rule name permit_office_to_app source-zone trust destination-zone untrust source-address 192.168.20.0 24 destination-address 192.168.30.0 24 service http service https action permit description TICKET-20240528-01 quit逻辑说明默认拒绝规则放最后因为防火墙策略通常按名称或序号匹配匹配到就停止。把deny_all放在最后则所有未命中的流量都会掉进兜底规则被丢弃。我把变更单号写进description字段比如TICKET-20240528-01这样半年后查“这条策略是谁加的、为什么加”时不用翻聊天记录。参数说明source-zone和destination-zone必须和防火墙接口划分的安全区域一致。多数防火墙默认有trust、untrust、dmz三个区域把内网接口划入trust、外网接口划入untrust。如果业务分流复杂建议自建区域比如server区和office区策略更容易读懂。防火墙策略做完后要做一次可达性验证。用办公网一台PC跑iperf3测吞吐和延迟# 在应用服务器上启动服务端 iperf3 -s # 在办公区PC上测到应用服务器的TCP吞吐测试时长10秒 iperf3 -c 192.168.30.10 -t 10 -i 1逻辑说明iperf3 -s在被测目标上开启服务端监听默认端口5201客户端用-c指定目标地址-t 10表示持续测试10秒-i 1表示每1秒打印一次结果。如果吞吐数值明显低于交换机端口协商速率说明中间链路上有QoS限制或接口协商异常如果直接失败则要检查安全策略是否放行了5201端口测试完记得删除这条临时放行策略。这一层做完网络侧措施就具备“可描述、可检查”的条件了。配上网络拓扑图和VLAN表写入docx网络保障部分基本成型。4. 信息安全侧措施落地基线加固、日志审计与备份恢复网络侧解决的是“谁可以访问谁”信息安全侧解决的是“主机本身是否扛得住”。这一章覆盖三件事主机基线加固、日志集中审计、备份恢复。这三件事做得越实安全兜底能力越强。4.1 Windows与Linux基线加固口令策略、远程管理、共享服务主机基线是措施文档里最好写、也最容易骗人的部分。写好口令策略不难难在把服务器真正按策略改一遍。我先说Windows侧再说Linux侧。Windows Server的加固项我用secedit命令把安全策略导出、按基线模板修改后再导入。导出的配置是inf文件适合批量核对# 导出当前安全策略到C盘根目录文件名baseline.inf secedit /export /cfg C:\baseline.inf # 修改inf文件中的密码策略项 # PasswordHistorySize 12记住12个历史密码 # MinimumPasswordLength 12最短12位 # MaximumPasswordAge 9090天强制过期 # 配置完成后重新导入到本机安全数据库 secedit /configure /db C:\Windows\security\local.sdb /cfg C:\baseline.inf /areas SECURITYPOLICY逻辑说明secedit /export导出的是当前生效的安全策略适合先做现状摸底secedit /configure再把改好的模板导入系统。/areas SECURITYPOLICY表示只导入安全策略域避免误改其他设置。参数说明密码历史12条、最短密码长度12位、最长使用期限90天这是我用的最低标准。如果业务系统比较老旧12位密码可能在兼容性上有问题可以降为8位再逐步调。关键是用/areas限定导入范围不给生产系统造成额外风险。Linux侧的基线加固操作更频繁。我常用的命令范围锁定在SSH配置和系统口令策略上# 备份原始sshd_config防止改错后回滚不了 cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date %F) # 禁止root直接远程登录 sed -i s/^#PermitRootLogin.*/PermitRootLogin no/ /etc/ssh/sshd_config sed -i s/^PermitRootLogin.*/PermitRootLogin no/ /etc/ssh/sshd_config # 禁止空密码登录 sed -i s/^#PermitEmptyPasswords.*/PermitEmptyPasswords no/ /etc/ssh/sshd_config sed -i s/^PermitEmptyPasswords.*/PermitEmptyPasswords no/ /etc/ssh/sshd_config # 语法检查通过后重载SSH服务 sshd -t systemctl reload sshd逻辑说明sed -i直接修改文件并备份原文件防止手滑改坏配置后连不上机器。sshd -t做语法检查检查不通过不重载服务这是防止把自己锁在外面的关键一步。参数说明date %F会生成类似2025-01-01的日期后缀便于保留多天备份。修改PermitRootLogin后日常运维必须通过普通用户登录再su切换root。如果公司内部有堡垒机我建议在此基础上再限制SSH登录来源IP写入/etc/hosts.allow或防火墙规则让SSH服务只对管理网段开放。4.2 把日志集中起来审计别让日志留在失陷机器上日志审计是措施文档里容易被低估的一环。默认情况下每台Linux服务器只在本机记日志。机器被入侵后攻击者第一件事就是清日志本机日志根本留不住。所以必须做集中日志收集。我在内网部署一台日志服务器用rsyslog把所有Linux服务器的认证日志和syslog转发过去Windows则通过Winlogbeat或系统事件转发。Linux侧的配置非常简单# 在日志服务器上开启TCP 514监听并把接收到的日志写入独立文件 # 在/etc/rsyslog.conf中取消注释以下两行 # $ModLoad imtcp # $InputTCPServerRun 514 # 在被采集的服务器上追加转发配置 echo *.* 192.168.200.10:514 /etc/rsyslog.conf # 重启rsyslog使配置生效 systemctl restart rsyslog逻辑说明表示走TCP传输单个表示UDP。日志审计建议选TCPUDP在流量大时会静默丢包日志不完整等于白收。*.*表示所有facility和所有级别的日志都转发真实环境也可以按需过滤比如只转发auth和authpriv。参数说明日志服务器IP要固定端口默认514。在防火墙或安全组里只放行内网管理网段到日志服务器的TCP 514端口不要对这个端口做全网开放。日志留存周期我按法规最低要求做6个月每台设备按天切割日志文件文件名含日期索引查询时用grep或zabbix日志监控都方便。没有集中日志措施文档里的“审计”就是空话。有了日志平台后还要给个“黑匣子”可查的样子每周写一条定时任务校验日志服务器上近24小时各主机的日志数量低于阈值触发告警。这样才能知道日志链路没断。4.3 备份策略按恢复目标反推先算RPO与RTO再定频率备份是信息安全里最不该省的一块。很多团队买了NAS、挂了盘备份任务一直是绿的真到恢复那天发现备份文件是坏的。我先讲策略再讲命令。措施文档里不写“每周备份一次”而是写“RPO不超过24小时RTO不超过4小时”。这两个指标决定频率和方式系统类型RPORTO建议备份方式保留周期核心数据库≤15分钟≤2小时实时同步 每日全量全量保留30天增量保留90天应用服务器≤24小时≤4小时每日增量每周全量全量保留12周网络设备配置每次变更后≤1小时配置自动备份脚本保留最近20个版本Linux服务器用cron加tar做定时归档是稳定且便宜的做法# 每周日2点执行全量打包排除临时目录和缓存 0 2 * * 0 tar czf /backup/app_$(date \%F).tar.gz --exclude/var/cache --exclude/tmp /var/www /etc /opt # 每月第一个周日把全量备份拷贝到异地目录 0 3 1-7 * 0 rsync -av /backup/ rsync://192.168.200.10/backup/逻辑说明tar做全量打包--exclude排除缓存目录避免备份体积膨胀rsync把备份推到内网另一台存储防止本机硬盘损坏时备份一起丢失。$(date \%F)在cron里需要转义写成\%F直接手写Shell脚本就不会有这个坑。参数说明备份文件一定要在备份任务结束的当天做一次恢复抽查——不用恢复整机只要解压关键目录比对文件数即可。把恢复验证记录写进措施文档的第七章这一栏在安全检查和事故追责时是实打实的证据。5. 避坑清单设备配置与基线加固里最容易翻车的四个地方方案看着完整真正落地时翻车的概率不低。下面四条是我做过多个项目后整理的高频坑每一条都踩过写出来供你对照排查。5.1 Docker容器网络不通业务网段和Docker网桥地址冲突现象容器部署完后容器内访问宿主局域网内业务服务器IP时超时但宿主本机访问正常。看着像防火墙拦截其实问题常常出在网段冲突或转发开关上。原因Docker默认的bridge网段是172.17.0.0/16如果业务网段恰好用了172.x段容器路由就会混乱另一种常见情况是宿主机的ip_forward内核开关被关掉导致容器流量无法路由到外部。解决在/etc/docker/daemon.json里指定一个不冲突的容器网段而不是用默认值# 指定docker0网桥为10.10.0.1/24段避免与业务网段对冲 cat /etc/docker/daemon.json EOF { bip: 10.10.0.1/24 } EOF # 重启Docker使配置生效同时确认转发开关已打开 sysctl -w net.ipv4.ip_forward1 systemctl restart docker说明bip是bridge IP的简写指给docker0网桥分配的子网。配置后用ip addr show docker0确认网段变更成功再进入容器测试到业务服务器的连通性。5.2 Linux改DNS后一重启就还原被NetworkManager接管现象手动修改/etc/resolv.conf后当时生效重启网络服务或重启机器后DNS又被改回去。有些同行遇到这问题就直接把NetworkManager禁用结果无线和有线网络管理也跟着废了。原因NetworkManager管理着连接配置文件重启时会按连接配置重新生成resolv.conf手动编辑的内容被覆盖。解决把DNS写进连接配置而不是直接改resolv.conf# 查看当前活动连接的名称一般是ens33或eth0 nmcli connection show # 给连接配置两个DNS服务器auto-dns改为no防止自动获取的DNS覆盖它 nmcli connection modify ens33 ipv4.dns 223.5.5.5 114.114.114.114 ipv4.ignore-auto-dns yes # 重新激活连接生效 nmcli connection up ens33说明ipv4.ignore-auto-dns yes是关键它告诉NetworkManager不要用DHCP下发的DNS覆盖手动配置。配置后查看/etc/resolv.conf内容应该不会再被还原。5.3 基线加固把业务锁死服务账户密码过期导致集群下线现象给一批Windows服务器配置了90天密码过期策略结果第二天数据库集群的多个节点同时掉线业务侧报连接失败。原因域内或本地的服务账户没有排除在密码过期策略之外。人工账户定期改密是对的但服务账户是机器使用的不会登录去改密码到期后凭据失效整个集群就断了。解决区分人工账户和服务账户。在密码策略里单独建一条针对服务账户的例外服务账户采用随机20位以上复杂密码设置“密码永不过期”同时严格限制该账户的登录权限只允许在指定服务器上登录。这个操作应该在基线加固前就完成而不是加固后等故障暴露。5.4 备份任务显示成功恢复时却找不到可用数据现象备份系统告警一直显示正常真到数据丢失时打开备份目录发现最新一份完整备份是两周前的增量文件缺了一大段。原因备份任务只管“备份动作执行成功”不校验备份结果是否可恢复。常见是源端数据库在备份过程中有写入导致备份文件内部不一致或备份存储空间满了最新增量没写进去但任务状态没报错。解决两条路同时走。一是备份任务完成后立刻做一次文件完整性验证比如对比备份前后源目录的文件计数和总大小二是我个人的经验是每月做一次恢复演练把数据库备份恢复到临时实例执行SELECT COUNT(*)核对关键表行数再把应用目录备份解压到临时路径做文件对比。备份是安全措施里唯一的“后悔药”药不能作假。措施文档里如果只写了备份策略没有恢复演练记录我会认为这条措施不成立。6. 用演练和自查清单验证保障措施是否真能扛住事方案写完了配置也推了最后要回答的问题是“这些措施到底有没有用”。我习惯用两种方法验证一种是断网演练一种是半年度自查清单。6.1 断网应急演练把交换机断电看监控与响应流程是否成立找个周末低峰期挑一台汇聚交换机直接断电。别提前通知运维同事看监控平台是否按预期产生告警看值班人员能否在10分钟内定位到故障设备看响应手册里的联系人电话能不能打通。断电演练能暴露三类问题监控漏配、应急预案过时、交换机没有保存配置导致上电后业务异常。演练结束后写一份简要记录放进docx的第八章。6.2 半年度自查清单按“边界、主机、数据、账号”四个域逐项核对我按四个域做了一张自查表每半年对着设备逐项过一遍。表里的验证手段都是我日常会跑的命令域检查项验证方法边界VLAN和ACL是否和文档一致核心交换机执行display acl all逐一对比规则边界防火墙是否还有长期放行的临时策略登录防火墙导出策略清单查description为空或带test的策略主机服务器口令策略是否符合基线Windows执行net accountsLinux查看/etc/login.defs主机高危端口是否仍然对外开放在办公网用nmap -p 22,3389,3306扫管理网段数据备份任务最近一次恢复验证记录是否存在核对备份平台日志与恢复演练记录日期账号离职人员账号是否已禁用导出账号列表与HR离职名单比对这套自查做完把结果表更新到docx末尾的检查记录页。我自己的习惯是每个季度打开一次《网络与信息安全保障措施.docx》对着自查清单过一遍配置和文档不一致的当天修掉。指望一张文档保护网络是不可能的但它能让你在凌晨收到告警时知道该往哪台设备看。希望帮到你。本文还有配套的精品资源点击获取
