简介这是一份面向公安信息化建设与网络安全管理岗位的规划方案文档以某公安局网络的专线接入、子网划分和现有Web应用为分析起点系统梳理了内外网隔离、边界防护、IP与MAC绑定、身份认证、访问控制、数据加密、审计记录等多层次安全需求并按照网络层、应用层与安全管理三个维度展开方案设计从防火墙策略、地址翻译、黑白名单、网址过滤到身份窃取、数据篡改、非授权存取、否认抵赖等典型威胁的应对思路再到漏洞检测、审计记录、公钥体系与SSL加密等配置要点均有说明适合网络管理员、安全工程师及信息化方案编写人员参考借鉴。包内仅包含1个DOC格式文件大小为71KB属于完整建议稿文档无需解压即可直接查阅。目前已有285人学习下载。文档结构清晰从现状分析到第一期网络层安全需求、应用层安全目标、安全管理需求逐层推进既可作为网络安全项目规划的框架参考也可用于同类单位方案撰写的直接模板。1. 某公安局网络安全方案.doc 到底在讲什么一份文档背后的三级等保落地全景接到一份《某公安局网络安全方案.doc》你的第一反应可能是先翻目录看它有多少页、有没有拓扑图、预算表放在哪。但我在这类项目上跑过几个完整周期后可以负责任地说这份文档通常不是给你“看”的而是给你“拆”的。它表面是方案本质上是一张按等级保护基本要求铺开的合规落地全景图从安全域划分、边界防护、主机加固到制度台账每个章节最终都要变成一个可执行、可验证、可被测评人员追问到细节的动作。这类方案解决的不是“买几台设备”的问题而是“这个单位的信息系统一年后能不能通过复测、有没有人说得清网络里每个流量该走哪、每台服务器该开什么服务”的问题。适合读它的人有三类单位信息中心里负责项目管理的人、集成商里写实施计划和调设备的工程师、测评机构里负责核对证据的新人。读法也不一样管理员关心节奏工程师关心参数测评人员关心证据链。下面我按自己做这类方案的顺序把这份文档拆成能落地的几层。2. 从文档到拓扑安全域划分与边界防护的落地配置2.1 安全域划分为什么它是方案里最先要落地的部分几乎所有这类方案的第一个实质章节都是“网络现状”和“安全域规划”但真正动手时你会发现文档里画的分域图和现网设备的 VLAN 很多时候对不上。这里的核心原因不是画图的人偷懒而是网络在多年扩容过程中业务流量早就不按图纸走了。安全域划分这件事落地的第一步不是画图而是梳理资产清单把这个单位自建机房里每一台物理服务器、每一条业务专线、每一台终端所在网段全部列出来标清楚它属于对外服务、内部办公、数据存储还是设备管理。我一般会把资产清单按表头“IP 地址 / 设备名称 / 所属系统 / 访问方向 / 责任人”整理成表然后才开始划分安全域。公安类业务系统的分域逻辑有一个特点核心业务数据和视频图像数据通常要求更严格的隔离而且跨域访问必须经过边界防护设备不能因为“内网可信”就跳过。常见做法是划分成六个域对外服务区、核心业务区、终端接入区、数据存储区、管理区、外部交换区。每个域之间由防火墙或具备 ACL 能力的交换机衔接默认策略全部拒绝放行规则逐条申请。这里有个新手最容易忽略的细节管理区必须单独成域而且所有网络设备、服务器、安全设备的管理口只能接入管理区运维人员通过管理区跳转才能触达其他区域。理由很简单如果管理流量和业务流量在同一张网里跑攻击者一旦拿到一台业务服务器顺着管理口就能控制整个网络。这也是测评时比较关注的一个点你可以在方案里提前把这张域间访问矩阵画出来。地区域划分示例安全域承载内容边界设备互联方式默认策略对外服务区面向群众的服务系统、门户网站防火墙 入侵防御串接部署仅放行 HTTP/HTTPS其余拒绝核心业务区办案业务、审批流程应用服务器防火墙双机热备串接部署仅允许终端区指定网段访问终端接入区办公电脑、业务终端接入交换机 准入控制二层隔离按 MAC/IP 绑定准入数据存储区数据库服务器、备份存储防火墙 数据库审计串接或旁路仅核心业务区应用服务器访问数据库端口管理区运维终端、堡垒机、网管平台独立交换机物理隔离所有域访问管理区均拒绝外部交换区与上级或外部单位的数据交换前置机 网闸单向导入仅允许指定格式的数据文件通过这张表做完后续的防火墙策略、路由配置、准入策略全都有了下发依据。别急着调设备先把区域和每个区域的资产清单对应上否则调完设备第二天业务就被策略挡死了。表里的“默认拒绝”不是让你把所有流量一刀切而是每个放行动作都变成一条有申请记录、有责任人、有有效期的白名单规则这在测评时能直接当作证据提交。2.2 边界防护设备的位置与部署方式串联还是旁路要想清楚分域表定了下一步是决定每类安全设备放在哪、用什么样的接入方式。我在方案评审时最常被问到的问题是“防火墙和入侵防御是串接还是旁路”。答案是分场景防火墙必须串接在域间链路上否则它根本挡不住任何流量入侵防御可以串接也可以旁路但公安类业务通常要求串接因为只告警不拦截对合规来说不构成“防护”。网闸只放在与外部单位交互的前置区用来做数据单向导入常规的域间访问别指望用网闸替代防火墙。有个参数要特别留意防火墙部署时如果采用双机热备心跳口和对端的接口配置要在同一个 VLAN 里而且主备机的会话同步要打开。会话同步的作用是当主机宕机切换到备机时已经建立的业务连接不中断——政务和公安类系统里很多是长连接业务中断一次就可能造成审批流程卡死。我在某次模拟项目X的交付中遇到过切换后连接断了的情况查到最后是两台设备的会话同步超时时间不一致业务超时时间设的是 60 秒设备会话同步要 90 秒才完成。后来统一把会话同步间隔调到 10 秒主动探测对端健康状态问题才消除。设备位置确定后还要规划策略的下发顺序。安全域间防火墙的策略顺序有一个很基础也很重要的规则白名单靠前、黑名单靠后、默认拒绝兜底。很多工程师图省事直接把所有规则一次性导入结果出现“先放行再拒绝等于没拒绝”的问题。正确的做法是像写代码一样为每条策略加上编号和注释例如“POL-01-业务区到数据库区-放行-应用A访问Oracle 1521端口”这样后续排障时一眼能看出哪条策略在起作用。边界设备的部署参数建议设备类型部署位置接入方式关键参数建议常见误区防火墙每个安全域边界透明模式或路由模式串接开启会话同步、开启状态检测透明模式下未配置管理 VLAN设备失联入侵防御对外服务区前、核心业务区前串接攻击特征库每周更新、误报阈值调中用默认策略直接上线大量误报导致无人看网闸外部交换区单向导入只放行指定文件类型和来源 IP为了图方便配置成双向等于白装数据库审计数据存储区旁路镜像口接入镜像口带宽不小于业务口 20%镜像口被流量打满审计日志大量丢失2.3 防火墙策略的可抄作业配置命名规范与收敛方法策略规划是边界防护里最琐碎、也最能体现经验的部分。我刚做这类方案时也吃过亏——客户原来的防火墙里堆了 400 多条策略没人说得清哪些在用、哪些是历史遗留。后来养成的习惯是每接手一个项目先做一次策略收敛再谈新增策略。收敛按四步走第一步导出全量策略清单第二步通过流量日志统计每一条策略在最近 90 天内的命中次数第三步命中的保留未命中的打上“待确认”标签给业务方一个月确认期第四步确认期结束后由信息中心负责人签字删除。后面新加的策略统一按命名规范走我常用的模板是方向IN/OUT/DMZ 源区域 目的区域 用途 编号。例如IN-TERM-APP-WebAccess-014含义是“终端接入区访问核心业务区 Web 应用的第 14 条策略”。这样做有实际价值测评时审查策略每一张表都能对到具体业务排障时搜源目的 IP 就能看到相关策略组半年后做复查未命中的规则一眼就能挑出来。关于防扫描和连接数限制有两个实用的参数。一是开启防火墙上对每个源 IP 的最大连接数限制通常设为 1000 到 2000防止单台终端中了木马后对内网发起大量连接二是设置半连接超时时间默认值如果偏大SYN Flood 攻击时会占满会话表调成 30 到 60 秒比较合适。这些参数在方案里通常只有一句话但落地时一定要逐台核对设备实际配置我就遇到过文档写了但设备上没开的翻车现场最后被测评开了不符合项。提示防火墙策略收敛期间一定要有回退预案删除前导出全量配置并保存到堡垒机目录若出现业务异常可以在分钟内恢复单条规则而不是回滚全部配置。3. 计算环境加固终端、服务器与数据库的安全基线怎么设3.1 身份鉴别与访问控制基线参数不是越严越好方案里“身份鉴别”这一小节最容易写也最容易让实施翻车。很多文档直接抄了一份基准参数密码长度不少于 12 位、复杂度要求大小写字母加数字和特殊字符、每 90 天更换一次、登录失败 5 次锁定 30 分钟。参数本身没有错但它没有考虑公安类业务的一个特殊场景很多业务系统使用服务账号自动巡检、自动对账这些账号一旦被“登录失败锁定”策略命中半夜就会把业务脚本全部卡死。我处理过的一个真实情况是数据库巡检脚本配置的密码快到期了运维人员还没来得及改凌晨脚本一连库就被锁定第二天早上业务部门集体报障结果发现全是同一台数据库的服务账号被锁定。所以身份鉴别基线的设置原则是人用的账号和服务用的账号分开处理。人员账号启用强密码、定期更换、双因素认证服务账号改为密钥认证或独立密码库托管密码由堡垒机周期性自动更换不参与人员的口令策略。这个区分动作建议你在方案里单独写一节“账号分类与口令策略”测评人员看到这个细节会认为方案是经过思考的而不是在堆参数。参数建议表对象策略项建议值说明人员账号密码长度12 位及以上可适当放宽到 10 位但必须开双因素人员账号更换周期90 天与员工关系管理系统联动到期提醒人员账号登录失败锁定5 次 / 锁 15 分钟避免锁定时间过长影响紧急登录人员账号超时退出15 分钟无操作服务器操作台可放宽到 30 分钟服务账号认证方式密钥 密码托管禁止使用固定明文口令在脚本中服务账号口令更换由托管平台自动周期更换更换后同步更新业务配置双因素认证的选择也有讲究。公安类单位在办公终端上通常已部署某种身份认证介质直接把它接入堡垒机和关键业务系统的认证链路是成本最低的方式。但要注意双因素不能覆盖所有场景比如值班室凌晨的应急维护、出警期间的临时查询认证介质不在身边就不能干等。这时要有备用通道值班经理电话审批 临时一次性口令并在事后留存审批记录。这条通道的存在不是为了绕过安全而是保证安全措施不会反过来阻断业务。3.2 终端安全管控准入、补丁与外设管理一个都不能少终端是这类方案里数量最大、最难管的资产。公安类单位终端的特点是办公电脑多、业务终端多、部分终端还要连接外部设备如证件读取器、指纹仪。终端管控如果只靠杀毒软件基本等于没管。常规做法是分三层落地网络准入层、终端加固层、外设管控层。准入层的目标是“不合规的终端不让进网”。常见实现方式是在接入交换机上启用 802.1X 认证配合 MAC 地址白名单做人机识别。要点是设置一个“隔离 VLAN”终端认证失败时自动划入隔离网段只能访问补丁服务器和准入认证服务器不能访问任何业务网段。这个机制的好处是新到的设备、未装代理的电脑、中了毒乱发包的终端统统先丢到隔离区等它符合策略了再放行。终端加固层主要管三件事安装统一的终端安全代理、开启补丁自动分发、禁用未授权的软件安装。公安类项目还要额外关注“一机两用”场景——同一台电脑既处理内部业务又上互联网的情况。我处理过的方案里比较有效的做法是逻辑隔离加外设管控内部业务通过专用客户端访问互联网出口走代理并做内容过滤同时把 USB 存储设备权限禁掉只保留认证过的 U 盘。外设管控的边界要划清楚完全禁用 USB 端口不现实因为业务系统还要连读卡器、打印机、加密狗。建议按设备类型走白名单而不是按端口禁用。具体参数如下控制项策略建议备注网络准入802.1X MAC 绑定未认证终端划入隔离 VLAN补丁分发每 7 天强制更新一次隔离 VLAN 必须能访问补丁服务器软件安装白名单制未列名软件安装前需提交申请USB 存储禁止非授权 U 盘授权 U 盘做唯一标识加密外接设备读卡器、打印机按 PID/VID 白名单放行避免一刀切影响业务3.3 数据库与日志审计留什么、留多久、怎么留才不算白留计算环境加固的最后一块是数据和日志。数据库审计设备通常旁路部署在数据存储区的镜像口上作用是记录所有对数据库的访问和操作包括登录源 IP、操作账号、执行语句、影响行数、时间戳。这块有两个坑一是镜像口流量过大导致丢日志二是各设备系统时间不统一导致日志无法追溯。镜像口流量的问题在 2.2 节提过参数这里再补充一个排障技巧如果审计日志出现间隙性缺失先检查交换机镜像口是否被设置成了共享镜像而不是独占镜像。生产环境交换机通常把镜像口配成“RX/TX 都镜像”当业务口流量超过镜像口带宽时交换机只能丢包。正确的做法是把镜像口单独用一个千兆或万兆口承载并估算峰值流量后保留 20% 以上余量。关于日志留存期限等级保护里留存时间的要求常见为六个月公安类系统的审计日志建议按六个月到一年规划存储容量同时日志必须防篡改只允许审计员账号读禁止任何账号在线修改删除。日志集中存储建议这样规划日志类别来源设备采集方式留存时长关键字段网络设备日志交换机、路由器Syslog12 个月时间、源目 IP、用户、操作类型安全设备日志防火墙、IPS、堡垒机Syslog / SNMP Trap12 个月威胁事件、策略命中次数、管理员操作主机日志服务器 Windows/LinuxAgent 采集6 个月登录成功/失败、账号变更、进程启动数据库日志数据库审计设备镜像口采集12 个月SQL 语句、影响行数、登录账号应用日志业务系统接口推送6 个月用户操作行为、业务流水号日志平台上线后别急着宣布完工先做一轮“日志完整性比对”从防火墙随机挑三条全量访问记录去日志平台里按时间戳和五元组反查能查到说明链路是通的查不到说明流程有断点需要顺着采集器、转发通道、存储索引三个环节排查。这一步我几乎在每个项目上都会做一遍查出的问题包括某台交换机日志级别配成了 Informational 导致关键事件没上来、某个采集器的时间时区没统一导致显示时间差了 8 个小时。时间不同步这个问题尤其隐蔽最后统一用 NTP 服务器校正全部设备并在每台设备上配置周期自动同步才彻底解决。4. 管理与运维落地制度台账、账号权限和应急响应的配套清单4.1 制度文档清单每份文件要写什么才能过审又能执行方案里“管理体系”这一章往往是评审时被批得最多的部分原因是写的都是“应加强”“须落实”缺少可执行的表单。制度文档的落地目标不是“有文件”而是“任何一项操作都能对应到一份记录”。我一般会按管理层、操作层、记录层三层来整理文档清单。管理层文件包括网络安全管理制度、机房管理制度、账号权限管理制度、数据备份与恢复制度操作层文件包括各系统运维操作规程、设备上线变更流程、应急预案记录层包括资产清单台账、账号权限台账、变更记录表、审计日志查阅记录表、第三方人员入场记录表。每份文档的重点不一样但至少都应当包含“谁来做、多久做一次、在哪留痕”三要素。比如账号权限管理制度里要写明新员工开通账号由谁发起申请、谁来审批、权限有效期多久、离岗后何时注销账号。再比如数据备份与恢复制度里不能只写“每周备份一次”要写清楚全量备份在哪天、增量备份在哪天、备份介质保存在哪里、多久做一次恢复测试。测评人员看制度时是不会细读每一份文件的他会随机抽一条记录去溯源比如抽一个已离职员工的信息问他的账号是否已注销、终端权限是否已回收。所以制度文档的关键是能让溯源查得到。4.2 堡垒机与账号分权把“谁用了哪个账号干了什么”变成可查的记录账号权限管理和堡垒机建设是配套的。公安类系统里的账号类型多设备账号、数据库账号、应用账号、平台管理账号如果不做统一纳管就会出现一个管理员手上十几个账号密码、离职后还在用。堡垒机的作用是让所有运维人员访问所有目标设备时都先登录堡垒机由堡垒机托管目标设备的真实密码运维人员不接触真实口令只能通过会话窗口操作。部署方式上我建议在管理区单独部署一套堡垒机目标地址覆盖所有交换机、防火墙、服务器、数据库。账号分权的最小集是“三权分立”系统管理员负责设备配置安全管理员负责安全策略和安全设备审计管理员负责查看日志和会话记录三种账号相互制约。注意这里说的三权和上级管理员账号分开不是让三个人管三台设备而是不能让同一个人既配置防火墙又查看审计日志。测评时对这块查得比较细因为一旦权限不分离前面的设备和策略加固都等于摆设。运维操作的标准动作是这样的运维人员发起访问申请审批人通过后堡垒机自动打开会话并全程录屏同时记录操作指令。日常工作中要常看两个数据一是三个月以上没有登录记录的权限账号一律做“停用或降权”处理二是堡垒机会话回放里出现的异常操作比如半夜批量修改配置、连续登录三台数据库这往往是风险事件的前兆。4.3 应急响应流程事件分级与处置时限写在纸上更要练在平时方案里“应急响应”章节如果只写“发生网络安全事件后立即上报”等于没写。应急响应的落点是把事件分级、处置流程、责任岗位、报告时限对应清楚。我常用的分级方式是三级一般事件影响范围限于单台终端或单个非核心系统较大事件核心业务系统受影响但数据未泄露重大事件核心业务中断、敏感数据外泄或被勒索。分级不同上报路径和处置时限也不同。处置流程建议写成一个值班人员不用思考就能照做的卡片发现异常 - 断开受影响终端或服务器的网络连接 - 通知应急小组负责人 - 根据事件分级启动对应预案 - 完整保留现场日志和镜像 - 恢复业务 - 48 小时内提交事件报告。这里有一个在真实复盘里反复出现的坑发现事件后第一反应是“再观察一下”结果扩大了影响面。正确的做法是先断网再研判宁可误判先隔离不能因为迟疑让内网横向扩散。应急演练的频率建议每个季度做一次桌面推演、每半年做一次实战演练。桌面推演是坐在一起走流程验证应急预案里的责任人和时限是否清晰实战演练是真实断网、真实切换备份链路、真实恢复备份数据。我参加过的一次演练里备份恢复环节用了 6 个小时才把核心库存系统拉起远远超过预案里的“2 小时内恢复”目标。后来排查发现备份脚本漏掉了两个数据库文件目录之前的备份一直是不完整的。这件事之后我把“恢复结果验证”写进了数据备份制度每次备份完成后必须校验文件数量和大小每季度必须做一次真实恢复测试而不是只检查备份任务执行成功。5. 常见问题与避坑方案落地最容易翻车的五个现场5.1 安全域画好了业务流量却绕行现象拓扑图上核心业务区到数据存储区经过防火墙测评时却发现数据库服务器直接接到了核心交换机上跨区访问完全没有经过任何安全设备。原因网络扩容时新服务器上线实施人员为省事就近接入核心交换机未同步修改分域归属和访问路径。图纸只更新了 Topology没有更新端口和 VLAN 映射表。解决将安全域、VLAN、物理端口、设备归属做成一张联动清单每次新增设备必须先更新清单再跳线。现场施工完成后要做一次流量路径核查在核心交换机上用查看 MAC 表项和 ARP 表项的方式逐台核对服务器接入位置。5.2 强密码策略导致服务账号批量锁定现象部署完密码策略的第二天凌晨多个核心系统的定时任务集体失败登录日志显示服务账号被锁定。原因策略对包括服务账号在内的全部账号生效而服务账号的密码早已过期或不符合复杂度要求定时任务一执行就触发失败锁定。解决部署口令策略前先完成账号分类把服务账号纳入密码托管平台。运维人员在执行脚本前必须确认账号类型服务账号一律走密钥认证不纳入登录失败锁定策略。5.3 审计设备在线日志却查不到现象数据库审计平台显示“设备在线”但需要调取某时段操作记录时发现大量缺失关键语句只剩前后两条。原因交换机镜像口配置为共享镜像业务流量峰值超过端口带宽导致丢包部分服务器时间与审计平台相差数小时。解决把镜像口改成独占接口扩容至千兆或万兆定期做日志完整性抽样比对全网设备统一配置 NTP 时间同步每台设备的时区和时间源逐一核对。5.4 双因素认证在紧急场景下阻断登录现象凌晨应急维护时运维人员因认证介质在办公室无法登录核心设备只能找管理员重置处理时长翻了数倍。原因双因素认证策略没有预留应急通道也未设置合理的超时宽限。解决增加值班经理审批制的一次性口令通道该通道事后自动生成审批记录。在堡垒机策略中为应急账号单独设置登录时段并在安全管理员处留备用的应急操作票模板。5.5 整改完三个月漏洞又批量出现现象等保测评整改闭环后下一次漏洞扫描发现大量重复的高危漏洞整改成果未能保持。原因没有建立漏洞闭环机制整改完成后无人负责后续的常态化检查新增设备和系统未纳入复查范围。解决每月做一次自动漏扫结果自动生成工单并推送到责任人修复后再次扫描验证。每次业务系统版本升级或新设备上线必须触发一次针对该资产的漏洞扫描扫描通过才能接入生产网络。6. 验证这套方案值不值得信一个下午做完的攻防自查方案落地后你还需要一种不依赖外部测评、自己能随时执行的验证方法。我常用的是“周末攻防自查”一个下午完成专门用来回答“这套方案现在还能不能挡住东西”这个问题。自查按四个步骤走第一步花一个小时核对边界策略导出防火墙全量策略清除三个月内未命中的规则第二步抽查三台核心服务器和五台终端看补丁是否在最近一个月内更新、账号列表里有没有僵尸账号、登录日志里有没有异常时间段的失败记录第三步做一次小范围模拟攻击测试从终端区发起对数据存储区的端口扫描确认防火墙和入侵防御有告警记录第四步从备份系统里随机选一台服务器做文件级恢复验证确认备份可读且恢复流程没有断点。自查结果不要只记“正常/异常”要把证据留好这样才能反哺下一轮方案修订。最开始做这类项目时我在方案验收后就当任务结束结果半年后客户请我回去做复测支持时发现很多设备和上季度相比已经变了太多补丁停了两个多月、策略被人改过没留记录。那次之后我养成了一个习惯每次交付的方案文档里都会附一张“自查清单”模板让信息中心能按周期自己跑一遍。这份《某公安局网络安全方案.doc》也一样你最终要交付的不只是项目落地的结果而是一套这个单位自己跑得起来的常态化机制。希望帮到你。本文还有配套的精品资源点击获取