简介：这是一份面向政府及企事业单位安全运维团队的市级重保期间安全服务保障技术方案，共102页Word文档，聚焦关键时期信息系统稳定运行与重大信息安全事件防范。方案按前期、中期、结束三阶段展开：前期通过资产调研表与收集表全面摸清家底，完善防火墙、WAF、数据库审计等技术措施并开展人员培训；中期建立7×24小时SIEM监控体系，落实访问管控、补丁加固、攻击溯源与取证；结束后输出服务总结与文档归档。同时给出前期实施方案，包括安全基线定义与检查标准、物理/网络/操作系统/数据库安全检查要求等，内容完整、目录结构清晰。压缩包内为单个docx文件，大小3.34MB，已有170人学习下载，适合负责重保值守、等保测评或安全服务项目的从业者参考借鉴。
1. 重保期间安全服务保障技术方案：别把 102 页当摆设直接读
重保期间的安全服务保障技术方案，我拆过不少，市级这份算是最能直接落到实处的。它最大的价值不是某个安全产品的配置手册，而是把一场重保拆成前期、中期、结束三个阶段，从资产调研、安全基线、渗透测试、应急处置到复盘，每一段都给了可填写的表单、可执行的流程和可检查的对照项。对于安全服务项目经理、企业安全运维负责人、乙方安全工程师来说，准备重保或重大活动保障前，拿它当目录框架和交付物模板都很顺手。但先说一句大实话：方案是脚手架，不能照着目录空念，你得把里面每张表落到自己的资产和业务上，不然再厚的文档也只是一摞纸。
2. 重保前准备：资产摸底、安全基线与安全检查怎么落地
重保服务前期占了整套方案大半篇幅，原因只有一个：资产不清，后面所有监测、封堵、溯源都像在盲人摸象。这个阶段要做三件事——把家底摸清楚、把安全基线立起来、把攻击面提前逮出来。我一般会严格走这三步，顺序不能乱。
2.1 资产梳理：调研表、收集表怎么落成三张清单
文档里给出了资产调研表和资产收集表。资产调研表的核心字段包括设备名称、用途、厂商、联系人、所属网络、作用域、访问地址、部署位置、运行状态、授权是否过期、规则库是否最新。资产收集表则把资产拆成网站应用、内网主机、集权类资产、安全设备、IP资产五大类，每个类别要记录的关键信息还不一样。
实际做的时候，建议不要只按一张大表去填，而是拆成三张清单：外网资产清单、内网资产清单、集权类资产清单。外网资产决定你要防多少面，集权类资产出事影响最大，内网资产则要导出 IP 段做全量比对。下面是我常用的分类方式：
| 资产分类 | 重点记录字段 | 容易漏掉的检查点 |
|---|---|---|
| 网站应用 | 应用名称、外网/内网访问地址、应用类型、开发语言、运行环境 | 测试站点是否挂在公网、开发环境是否和正式环境混跑 |
| 内网主机 | IP、操作系统、运行应用、远程方式 | 默认账号是否还在、是否装了终端管理 Agent |
| 集权类资产 | IP/域名、联系人、认证方式 | 登录是否支持双因素、管理日志是否留存 |
| 安全设备 | 登录地址、联系人、授权状态 | 授权是否过期、规则库是否最新、设备时间是否同步 |
资产梳理不能只靠人工填报。常见做法是先用网段扫描工具把内网、外网可达 IP 全量跑一遍，再把扫描结果和资产表交叉比对，凡是没登记的设备都标成“疑似新增资产”，逐一确认责任人。还有一点容易被忽略：云上资产和临时调配的服务器往往不在这张表里，重保开始前一定要把云账号下的资源也拉一次清单。
2.2 安全基线：编号规则和检查标准决定能不能审计
安全基线是重保前最容易被低估的一环。文档里把安全基线拆成“定义基线、落实基线、管理基线”三个阶段，还专门用 AIX 服务器举了个例子。以 AIX 为例，基线编号是 SR-AIX6.0-000-01，要求内容是删除或锁定与运行维护工作无关的账号，操作指南里明确要锁定 listen、gdm、webservd、nobody 这些账号，检查方法对应判断机是看 /etc/passwd 里的 shell 域是否被改成 /bin/false。
这条基线真正的价值不在命令，而在编号规则。文档给出的规则是：设备类型用 SR 表示服务器、FW 表示防火墙、SW 表示交换机、RO 表示路由器；系统类型有 WIN00、WIN03、WIN08、LIN5.0、CEN60、HPX50、SOLARIS90 等；应用类型用 ORA、MSS、MYS、IIS、APA、TOM、WLG 表示，只有操作系统没有应用时用 000。比如 SR-WIN03-000-01 就是 Windows Server 2003 操作系统安全基线第 1 项。有了这套编号，后续检查、整改、审计就有了唯一标识。
建基线时，我一般会把每条基线按下面这个结构落成表格：
| 字段 | 内容示例 |
|---|---|
| 编号 | SR-AIX6.0-000-01 |
| 项目 | 删除无关账号 |
| 要求内容 | 删除或锁定与设备运行、维护等工作无关的账号 |
| 操作指南 | 执行 userdel 删除，或将 /etc/passwd 中的 shell 域设为 /bin/false |
| 检查方法 | 人工检查 /etc/passwd，或脚本读取后与基线比对 |
安全基线不能一味求严。实际操作中要先把模板应用到非核心系统上验证一轮，再逐步推广到核心系统；每一条加固操作都要记录业务影响面，否则很容易出现第 4 章说的“业务假死”事故。基线建完之后还要纳入变更管控任何配置调整都要有申请单和回滚方案。
2.3 安全检查与渗透测试：从物理环境到应用层的测试顺序
文档里的安全检查要求覆盖了物理安全、网络安全、服务器操作系统、数据库服务器、应用系统五个层面。 做检查时我建议按这个顺序推进：先看物理环境，再看网络边界，然后查服务器和数据库，最后测应用和业务逻辑。
| 检查层面 | 重点检查内容 | 常见高风险项 |
|---|---|---|
| 物理安全 | 机房进出控制、监控覆盖、UPS、温湿度 | 门禁失效、监控盲区、设备标签不清 |
| 网络安全 | 防火墙策略、路由配置、VLAN 隔离、高危端口封堵 | 策略冗余未清理、高危端口直接暴露 |
| 服务器 OS | 账号口令、补丁级别、多余服务、日志留存 | 弱口令、默认共享、日志未开启 |
| 数据库 | 账号权限、监听地址、口令策略、审计开关 | 超级管理员共用、任意 IP 可访问 |
| 应用系统 | 身份鉴别、会话管理、输入校验、越权、敏感信息 | 验证码可绕过、未鉴权接口、报错信息泄露 |
安全检查不等于漏洞扫描。做完配置核查后，接下来才是文档里提到的渗透测试服务。方案里说“组织 3 支专业队伍，不打招呼直接进行模拟攻击”，这是很有价值的一种组织方式，但落地时需要注意边界。渗透测试流程通常是：确定测试范围、信息收集、漏洞发现、漏洞利用、后渗透验证、输出报告。测试前必须签好授权书，明确允许的手段和禁止的事项，比如禁止拒绝服务攻击、禁止批量拖库、禁止在生产环境写入后门。
另外还有两条容易被忽略的服务线：源代码安全检测和应用安全检测。源代码检测适合自研系统，用 SAST 工具跑全量扫描，再让人工重点看 SQL 注入、任意文件上传、越权、硬编码密钥。应用安全检测则更偏业务逻辑，比如登录接口能不能暴力破解、密码找回逻辑是否可绕过、支付金额能否被篡改。这一阶段的产出应该是按严重程度分级的漏洞清单，高危漏洞尽量在重保开始前完成整改或把系统下线，不能带着高危漏洞进入重保。
3. 重保中实施：过程文档、主动防御与攻击溯源的操作手册
进入重保中期，目标从“找问题”切换成“守住阵地”。这个阶段最担心的不是没有防护设备，而是事件发生后说不清情况、找不到源头、下不了决策。文档里给的解决方案是：用过程文档把每一天固定下来，用技术产品把攻击面盯住，用事件分级保证应急处置不慌不乱。
3.1 每日攻击事件汇总表：过程文档怎么设计才不流于形式
方案在中期实施里列了五份过程文档——每日攻击事件汇总表、安全漏洞隐患整改跟踪表、威胁消除报告、项目工作日报、项目工作周报。很多人觉得这是应付检查用的，实际不是，它是重保期间指挥决策的依据。
每日攻击事件汇总表，我一般要求至少包含这些字段：时间、攻击源 IP、目标 IP 和端口、攻击类型、威胁等级、处置动作、处置人、是否封堵。光有字段不够，还得定规则：同一个源 IP 发起同一类攻击，记录时合并成一条，高峰期避免刷屏；威胁等级分为高、中、低，高才交给研判组，低中事件值班人员直接处理。
安全漏洞隐患整改跟踪表则要盯到闭环：漏洞名称、发现时间、影响资产、风险等级、整改措施、责任部门、整改截止日期、复查状态。这里最容易翻车的是“发现漏洞就填表、填完表就忘了复查”，所以每天下班前要过一遍所有“整改中”状态的条目，被业务部门拖延的项要上报到项目指挥组。威胁消除报告则是针对具体安全事件的交付物，写清楚事件描述、威胁分析、影响范围、消除结果、遗留风险，别写空话。
3.2 主动防御与数据安全：产品选型、部署位置和联动策略
文档里提到的主动防御产品、态势感知、探针、数据库审计、未知威胁分析、威胁诱捕蜜罐，名字很多，但落到部署上其实是有主次的。我一般按“数据通道”来规划：在互联网出口和核心交换镜像口部署流量探针，负责发现扫描、爆破、Webshell 行为；在数据库前端部署数据库审计，记录所有 SQL 操作，重点发现批量拖库、异常权限访问；在邮件系统和外网下载区部署未知威胁分析，处理钓鱼邮件和文件沙箱；蜜罐则放在外网可达区和内网关键业务隔壁，诱导攻击者跳进陷阱，顺便把攻击手法记录下来。
| 技术手段 | 部署位置 | 主要作用 |
|---|---|---|
| 流量探针/态势感知 | 互联网出口、核心交换镜像 | 全流量分析，检测横向移动和远控连接 |
| 数据库审计 | 核心数据库前链路 | 记录 SQL 操作，定位批量拖数和越权查询 |
| 未知威胁分析 | 邮件系统、文件上传下载点 | 沙箱执行可疑文件，识别钓鱼载荷 |
| 蜜罐 | 外网 DMZ、内网关键区旁路 | 记录攻击手法，消耗攻击者时间，输出溯源线索 |
部署位置定了之后，还要做联动封堵。常见做法是安全平台把告警转成封堵指令，对高风险攻击源 IP 自动下发到边界防火墙或 WAF 上，同时抄送研判人员确认。主动防御的核心不是设备数量，而是“检测—研判—封堵—复核”这条链路要闭环。封堵策略必须有时间戳和审批人，不然重保结束后一堆临时策略没人敢删。
数据安全不能只靠数据库审计。文档里提到数据安全面临的风险、增强建议和生命周期管理，实际执行时我一般做三件事：数据库账号按人分配，禁止共用高权限账号；核心数据表开启审计，敏感操作能追溯到人；重保前做一次备份恢复验证，别等数据丢了才发现备份是坏的。数据泄漏往往是权限失控加审计缺失，这两条一定要堵住。
3.3 事件分级与应急处置：从监测发现到攻击溯源的完整动作
应急处置最怕“节奏乱”。方案里的事件分类分级和分级响应恰好解决了这个问题。事件类型至少分几类：可用性事件、数据泄露事件、网页篡改事件、病毒木马事件、钓鱼邮件事件、供应链事件，不同类型处置入口不一样。事件等级按影响范围和业务重要性分为一般、较大、重大、特别重大，定级后响应流程才清晰。
一套标准的应急处置流程应该是：监测发现事件后，值班人员先做快速判断，确认是误报还是真实攻击；然后按事件等级启动相应级别的响应，重大事件要立刻通知指挥组，同时沉淀现场证据。处置动作包括隔离受影响主机、封堵攻击源 IP、下线被篡改页面、暂停对外服务、修改受影响账号口令。恢复服务前必须做一次病毒查杀或漏洞修复，避免二次入侵。
攻击溯源是应急处置中最耗时、也最依赖日志的一步。文档提到的溯源信息包括攻击源 IP、攻击服务器 IP、邮件地址，以及攻击方法、攻击路径和工具。实战中我会先看三层日志：网络层看防火墙和入侵检测设备的会话日志，找攻击源和连接关系；主机层看登录记录、进程创建记录、文件修改记录和计划任务；情报层把攻击源 IP 和恶意样本哈希拿到威胁情报平台做关联。时间同步很重要，如果设备之间时间不一致，溯源拼起来的攻击链会错位。
4. 重保期间的避坑清单：常见问题与排查记录
这一章全是真实项目里踩过的坑，每条按“现象、原因、解决”写明白。重保方案再完美，落地时也躲不开这几类问题，提前看一眼能省不少加班时间。
4.1 资产清单与实际网络对不上
现象：重保前按表格填完了资产，结果重保开始第三天发现一台旧数据库服务器还暴露在外网，没人知道是谁的。
原因：资产摸底依赖人工填报，漏掉了未纳管的测试机、被遗忘的虚拟机、临时搭建的业务系统，还有人觉得“先报上去，回头再补”，一回头就忘了。
解决：资产梳理不能只靠填表，先用网段扫描工具全量探测内网、外网端口，识别所有可达 IP，再逐台人工确认。扫描结果与资产表交叉比对，没登记的设备标成“疑似新增资产”。重保期间每天看一遍新增 IP 记录，发现未知 IP 先隔离再确认归属。
4.2 安全基线配置过严，业务系统假死
现象：基线加固完的第二天，业务部门反馈系统登录不了，数据库连接被拒，应用接口大量报错。
原因：基线模板覆盖全量服务器后，把业务依赖的动态端口、共享服务、第三方组件都封了；所有服务器套同一套配置，属于“一锅端”。
解决：基线模板先应用到非核心系统，灰度验证没问题再推核心系统。每一项加固操作都要识别业务影响面，和业务负责人确认端口白名单和账号白名单。业务确需保留的项，放进例外清单，写明原因和复核时间，别让基线变成业务的黑匣子。
4.3 渗透测试打挂业务，告警响成一片
现象：红队同事在一个查询接口提交了超长字符串，后端应用直接崩溃，核心页面超时 20 分钟。
原因：测试人员没考虑业务容错能力，异常输入触发了后端解析崩溃；漏扫工具速率过高，产生大量请求还被 WAF 误封。
解决：测试前约法三章：禁止拒绝服务攻击、禁止批量下载数据、禁止在生产库执行删除或更新操作。测试时间窗口尽量安排在凌晨，提前把测试源 IP 告知监控值班人员，遇到异常流量先确认是不是测试团队，再决定封不封。渗透测试报告里一定要加一栏“业务影响”，方便评估是否安排复测。
4.4 告警太多，真实攻击被淹没
现象：安全平台一天告警 8000 条，值班人员只挑“高危”看，结果 WebShell 上传早就出现在中危告警里，直到三天后实际被利用才被发现。
原因：告警规则阈值设置不准，扫描和爆破被无限放大，分析人员只看评级、没有结合上下文做关联，误报高的规则把真正有价值的事件挤下去了。
解决：重保前一周就做告警降噪，统计高频源 IP 和目的端口，把扫描行为归并成一条；对每个核心应用建立访问基线，异常登录看“用户 + 时间 + 来源”组合；高危规则单独配置通知渠道。每天建立“Top 事件分析记录”，确保每一条中高危告警都有人看过一眼，或者明确确认关闭。
4.5 事件溯源时日志被攻击者清掉
现象：发现被入侵后，查看主机日志发现登录记录已经被删除，系统时间也被篡改，溯源只能看到一个国外入口 IP。
原因：日志只存在主机本地，没有做集中采集；管理员账号权限过大，攻击者拿到权限后顺手清了痕迹；日志没有异地备份。
解决：重保前必须把主机日志、网络设备日志、安全设备日志汇聚到独立日志平台，并统一做时间同步；对关键服务器设置日志只可追加权限，缩小攻击者清除日志的能力；还要定期把日志同步到外部对象存储，日志留存至少按一个重保周期来设定。
5. 重保后复盘与项目管理：用“双回归”验证重保成效
5.1 双回归：漏洞整改和临时策略复盘
重保结束不是把封堵策略全部删掉就收工。方案里提到的“安全隐患再评估、攻防手段再检查、应急处置再分析”，我一般会落地成“双回归”。第一次回归，重保前发现的高危漏洞是否全部完成整改；第二次回归，重保期间临时加的封堵策略还是否被业务依赖。如果策略仍然被业务使用，就要把它从临时策略转成正式白名单，附上责任人、变更单号和复核日期，否则下次重保你会发现策略越堆越乱，最终哪条也不敢删。
5.2 遗留风险清单与项目交付物
复盘会上，重保期间的中低危漏洞、未完成整改项、日志遗漏项，都要进入遗留风险清单。清单字段建议包含风险描述、风险等级、影响资产、整改建议、责任部门、截止时间。这份清单是下季度安全规划的重要输入，尤其重保期间暴露出的流程薄弱点，比如响应链路太长、夜班无人接管、告警处理滞后，整理出来直接变成制度和人员调整事项。
项目交付物方面，方案的项目管理模块特别强调了沟通和记录。我的习惯是每天下班前把三份文档归档完整：每日攻击事件汇总表、安全漏洞隐患整改跟踪表、威胁消除报告。每次应急处置结束后，再写一页纸的事故记录，包含事件时间线、决策人、封堵动作、恢复过程、待办事项。汇报 PPT 只是面子，过程文档才是能向管理层证明“重保没白做”的里子。
记得之前有一次重保收尾，我们因为临时策略没及时下线，导致内部端口意外暴露到公网，幸好业务监控发现得早，差点酿成事故。从那以后，我每次重保项目结束前都强制走一遍“双回归”，这个动作成本很低，但能帮你省掉后面一堆危机处理。重保这件事，细节决定生死，方法看起来琐碎，关键时刻真的能救命，希望帮到你。
本文还有配套的精品资源，点击获取
