简介《等保测评服务方案》共1个doc文件约1.07MB面向信息安全合规负责人、等保测评实施人员及企业系统运维与安全建设团队帮助梳理等级保护定级备案、测评实施与整改复测的完整工作脉络。文档围绕信息系统定级、专家评审、主管审批、公安备案等环节展开并覆盖物理安全、网络安全、主机与应用安全、数据备份恢复、安全管理制度、人员与系统运维管理及渗透测试等检查维度。内容还给出测评依据、被测系统描述、现场测评四阶段与复测评三阶段的组织方式可作为编写项目方案、准备测评材料和开展安全整改的参考底稿。目前已有989人学习适合需要了解等保流程、搭建合规文档框架或查漏补缺的初、中级安全从业者按需查阅。1. 一份 .doc 撑起一次等保测评省掉的不是打字时间是二次上门做等保测评项目的人大多有过这种体验定级报告写完被退回理由是 S/A/G 三性赋值没有判据现场测评跑了三天回到工位整理证据才发现截图缺设备名和时间戳只能再约一次上门。这份《等保测评服务方案.doc》的价值不在文字量而在于它把定级与备案、测评指标裁剪、十类测评内容的实施步骤和每项对应的配合清单串成了一条能照着走完的链路。它不是标准原文的复述而是一份作业底稿现场谁访谈谁、上机看哪几个配置项、要甲方提前准备什么材料都写在了对应小节里。适合刚接手等保测评交付的工程师、需要自建整改台账的甲方安全岗以及要拿它改成投标技术方案的售前。下面按落地顺序拆先定级备案再裁指标再排现场最后讲复测评怎么收口。2. 定级与备案S/A/G 三性赋值怎么判、五步流程怎么走完定级是整个项目的地基地基歪了后面指标裁剪、报告口径、复测评范围全部要跟着返工。这一章把定级对象怎么圈、三性怎么赋值、备案材料怎么凑齐讲透。2.1 定级对象不是「一台服务器」圈错了后面全错定级对象指的是承载相对独立业务应用、由明确运营使用单位负责、具有确定业务边界的系统。三个条件缺一不可业务相对独立、责任主体明确、边界可描述。常见翻车是把整个机房当成一个对象或者反过来把一个系统的前台、后台、数据库拆成三个对象分别定级结果测评指标重复计、报告里对象描述对不上拓扑图。比较稳妥的切法是按业务应用切基础设施单独处理。业务系统各自定级虚拟化平台、云管平台这类承载多个业务系统的基础设施单独作为一个定级对象纯网络设备、纯机房环境不单独定级作为业务系统的组成部分被测。某集团的办公自动化、对外门户、核心业务三套系统就是三个对象等级可能各不相同测评方案里要分开列表不能合并成一张表蒙混过去。圈完对象要落一张清单字段至少包含系统名称、业务描述、运营使用单位、上线时间、承载数据类别、是否联网、是否涉及个人信息。这张清单后面会直接变成备案表、测评方案、报告里的对象描述字段口径统一了后面改一处就行不用满篇找。2.2 S/A/G 三性赋值从「受侵害客体 侵害程度」倒推不要凭感觉S 是业务信息安全性指业务信息的保密性、完整性被破坏后造成的影响A 是业务服务保证性指业务服务中断或被降级造成的影响G 是通用安全保护不针对具体业务信息和服务通常与系统等级保持一致。三个维度分别赋值取最高者作为系统等级这是标准给出的方法不是拍脑袋。赋值靠的是两步推导先确定受侵害的客体再确定客体受侵害的程度。矩阵如下受侵害客体一般损害严重损害特别严重损害公民、法人和其他组织的合法权益第一级第二级第二级社会秩序、公共利益第二级第三级第四级国家安全第三级第四级第五级实操里最容易含糊的是「程度」怎么定性。判据要写成可核查的句子而不是形容词。比如 S 维度不要写「数据泄露影响较大」要写「泄露 10 万条以上客户身份信息可能触发监管处罚并造成直接经济损失」把数据量、信息类型、后果链条写清楚。A 维度不要写「中断影响业务」要写「服务中断 2 小时以上业务受理窗口无法办理日均影响 X 笔业务」。这些句子直接抄进定级报告的赋值说明栏专家评审时没人会追问。一个高频误判是「有备份就可以降 A」。备份解决的是恢复能力不是中断影响业务中断时间段内的损失照样发生。只有在双活、异地接管这类真正缩短中断时间的架构下才谈得上把 A 往下调而且要写明接管切换的实测时间。2.3 定级报告与备案表五步流程的输入、输出和卡点定级流程是确定定级对象、确定安全保护等级、组织专家评审、主管部门审批、公安机关审核备案五步。每一步都有明确的输入输出卡在哪一环后面全停。步骤责任方产出物常见卡点确定定级对象运营使用单位系统清单对象边界重叠或拆分过细确定等级运营使用单位、测评方协助定级报告初稿S/A/G 赋值无判据专家评审专家组不少于规定人数评审意见与签字页专家名单、签字、日期缺失主管部门审批上级主管单位批复文件无主管单位的需说明归属公安备案属地公安机关备案证明系统名称与报告不一致备案材料一般包括备案表、定级报告、专家评审意见、主管部门批复、系统拓扑与说明、安全管理制度目录。材料准备阶段最耗时的不是写是对齐。四处出现的系统名称必须字字一致备案表、定级报告、测评合同、测评报告。标点、括号、全半角都算不一致复测评时会被要求回去改备案这个后悔药不好吃。2.4 备案完成不等于结束把备案信息接进资产台账拿到备案证明之后很多人就把它归档进项目文件夹了后面现场测评要核对象、复测评要核范围又得翻出来对一遍。更省事的做法是把备案信息接进资产台账作为台账的一列系统编号、备案号、定级等级、备案日期、下次复测评到期日。台账里有了这一列年度测评计划直接从台账筛不用每年重新问一遍甲方「你们有几个系统备过案」。备案信息变更也有讲究。系统扩容、迁移、业务范围变化只要不改变定级要素一般不需要重新备案但要在测评报告的对象描述里说明变更如果业务范围变化导致 S 或 A 的赋值依据变了就要重新走定级和备案。判断标准还是回到那两条受侵害客体变没变侵害程度变没变。3. 测评指标怎么裁二级 66 项、三级 73 项的对照与取舍指标裁剪是测评方案里最容易照抄出错的地方。原始方案给了两张汇总表看着规整直接抄进新项目就会出问题得先弄明白这些数字是怎么堆出来的。3.1 二级 66 项、三级 73 项数字是怎么堆出来的原始方案把指标分成通用类 G、业务信息安全性类 S、业务服务保证类 A再按技术和管理各五个安全分类展开。二级的分布是这样安全分类安全子类SAG小计安全技术物理安全11810安全技术网络安全1056安全技术主机系统安全2136安全技术数据安全及备份恢复2103安全技术应用安全4217安全管理安全管理制度0033安全管理安全管理机构0055安全管理人员安全管理0055安全管理系统建设管理0099安全管理系统运维管理001212合计1055166三级的分布安全分类安全子类SAG小计安全技术物理安全11810安全技术网络安全1067安全技术主机系统安全3137安全技术数据安全及备份恢复5229安全技术应用安全2103安全管理安全管理制度0033安全管理安全管理机构0055安全管理人员安全管理0055安全管理系统建设管理001111安全管理系统运维管理001313合计12556733.2 这张汇总表照抄之前先核一遍对不上的地方就是坑把两张表横向摆开逐行对会发现一个明显异常应用安全三级只有 3 项二级却有 7 项。高等级系统的控制项比低等级少这在逻辑上不成立大概率是原表某一行的分列数值写错了。同类问题还有数据安全及备份恢复二级 3 项、三级 9 项这个递进幅度也偏大需要回标准原文逐条核。核对方法不复杂就三步第一步横向核每个子类的 SAG 必须等于小计第二步纵向核技术五类小计相加、管理五类小计相加两者之和必须等于合计第三步跨级核同级子类的三级项数不应少于二级。三步下来任何一处数字不闭合都会暴露。这三步靠人眼看容易漏用脚本对一遍更稳。做法是把指标台账维护成 CSV一行一个控制项然后统计import csv from collections import Counter, defaultdict # 指标台账一行一个控制项 # 字段level(2/3) category(十类子类名) cls(S/A/G) control_id 控制项编号 def load(path): with open(path, newline, encodingutf-8) as f: return list(csv.DictReader(f)) rows load(controls.csv) # 1) 横向核每个 (等级, 子类) 下 S/A/G 的条数 stat defaultdict(Counter) for r in rows: stat[(r[level], r[category])][r[cls]] 1 # 2) 跨级核三级项数不应少于二级 for cat in {r[category] for r in rows}: n2 sum(stat[(2, cat)].values()) n3 sum(stat[(3, cat)].values()) flag -- 三级少于二级回查 if n3 n2 else print(f{cat}: 二级 {n2} 项 / 三级 {n3} 项{flag}) # 3) 合计核与技术小计、管理小计、总合计对账 print(L2 合计:, sum(v for k, v in stat.items() if k[0] 2)) print(L3 合计:, sum(v for k, v in stat.items() if k[0] 3))这段脚本没有任何第三方依赖level决定按二级还是三级统计category与方案里的十类安全子类名保持一致cls只接受 S、A、G 三个值。脚本跑出来的合计要跟标准原文逐项对跟方案里的表也要对两边不一致时以标准原文为准方案的表作为需要修订的对象。参数上唯一要注意的是category的命名必须和报告里的分类名完全一致中间多一个空格都会统计成两组。3.3 S/A/G 标记不只是分类它决定报告里怎么写结论通用类 G 的指标是所有同等级系统都要测的S 类和 A 类指标则跟业务强绑定。判断某个 S 类指标测不测依据是定级时 S 维度的赋值是否高于系统整体等级。举例说一个定三级的系统如果 S 赋值是二级、A 赋值是三级那么 S 类的高等级指标可以不作为符合性判定的必测项但仍要在报告里说明不适用的理由而不是直接删掉。删掉是最危险的做法复核时无法解释指标缺项。实操里我会在指标台账里加两列applicable适用/不适用和reason不适用理由。不适用的理由必须指向定级结论比如「本系统 S 赋值为二级故 S3 类指标不适用」。这样报告生成时可以直接从台账导出不用再人工回忆当初为什么跳过某一项。3.4 指标挂对象一张对照表管到底指标是抽象的测评对象是具体的中间必须有一张对照表把「哪个指标在哪个对象上用哪种方式取证」固定下来。这张表决定了现场测评的动线也决定了证据文件的命名规则。指标编号指标名称测评对象取证方式证据编号NET-03访问控制策略核心交换机检查、访谈E-NET-03-01HOST-01身份鉴别应用服务器 A检查E-HOST-01-01APP-02访问控制业务系统检查、测试E-APP-02-01DATA-01数据完整性数据库服务器访谈、检查E-DATA-01-01对照表的价值在现场测评工程师拿着表按对象走一个对象上的所有指标一次测完不用为了找一个配置项反复换机器。证据编号提前编好现场只负责按编号落文件回来整理时不会出现同一项证据三份重名文件的情况。4. 现场测评四阶段访谈、检查、测试怎么排期和取证方案里把整个实施拆成现场测评和复测评两大块现场测评又分测评准备、方案编制、现场测评、分析和报告编制四个阶段复测评分安全整改、复测评、报告编制三个阶段。这个划分不是形式每一阶段的交付物都是下一阶段的输入缺一环就要回头补。4.1 四个阶段的时间盒与交付物阶段主要动作交付物常见延期原因测评准备组建项目组、收集系统资料、发放配合清单资料回执、系统调查表甲方资料缺失、接口人变更方案编制定对象、定指标、定方法、定进度测评方案甲方确认指标范围争议、渗透测试授权未签现场测评访谈、检查、测试、取证现场记录表、证据文件设备无法登录、窗口期冲突分析报告单项判定、整体测评、风险分析测评报告证据不全需二次上门方案编制阶段最容易被压缩实际上它决定了后面所有工作量。我的习惯是把测评方案和配合清单一起发出去配合清单按测评对象分组每组写明要谁到场、要开哪个账号、要提供哪几份文档。甲方拿到清单能提前一周准备现场就不会出现「这个设备的密码只有离职的人知道」这种局面。4.2 访谈、检查、测试三种取证方式各有各的证据形态方案里对三种方法的定义很准访谈是有目的地交流以理解、澄清或取得证据检查是观察、查验、分析测试是用工具或手工验证。落到取证上三者的证据形态完全不同混着用会导致报告里证据支撑不足。方式证据形态适用控制点注意事项访谈访谈记录时间、地点、被访谈人岗位、问答摘要、签字管理制度、机构设置、人员管理、运维流程记录不能只写「已了解」要写具体回答检查配置截图、文档复印件、现场照片物理环境、设备配置、制度文档截图需同屏体现主机名、配置项、时间测试扫描报告、验证步骤与结果漏洞、访问控制有效性、边界完整性需授权、需报备源 IP、需限速访谈记录是最容易被做薄的一类证据。写「访谈安全主管确认已建立安全管理制度」等于没写。合格的记录要落到具体问答「问制度最近一次评审是什么时候答本年 3 月评审记录编号 XX修订了备份恢复章节。」这种记录在复核时能自证不用回头找甲方补材料。检查类证据的关键是「一屏原则」。一张截图里要能同时看到设备主机名或 IP、具体配置项、系统时间。分三张截图各截一部分看着很全实际上无法证明这三张图来自同一台设备的同一时刻复核时很容易被打回。4.3 十类测评内容的实施要点和配合清单方案按物理安全、网络安全、主机系统安全、应用安全、数据安全及备份恢复、安全管理制度、安全管理机构、人员安全管理、系统建设管理、系统运维管理十类展开每一类下面都列了子类、测评内容和配合需求。这个结构本身就是现场动线按类走、按子类取证。安全分类子类数二级/三级主要对象主要取证方式物理安全10 / 10机房访谈、检查网络安全6 / 7交换机、防火墙、拓扑访谈、检查、测试主机系统安全6 / 7服务器、管理终端访谈、检查应用安全7 / 3需核实业务系统访谈、检查、测试数据安全及备份恢复3 / 9数据库、备份介质访谈、检查安全管理制度3 / 3制度文档访谈、检查安全管理机构5 / 5岗位职责文件访谈、检查人员安全管理5 / 5人员档案、协议访谈、检查系统建设管理9 / 11建设过程文档访谈、检查系统运维管理12 / 13运维记录访谈、检查物理安全十项里最花时间的不是技术检查是要材料。防雷要建筑物防雷检测报告防火要消防系统检查和维护记录、机房验收文档防水防潮要建筑施工图和验收文档电力供应要 UPS 和备用电源的维护维修记录。这些材料通常在甲方基建或后勤部门手里不在信息中心现场临时要基本要不到。配合清单里必须写清楚「由哪个部门提供、什么格式、是否接受复印件」。主机和应用两类是上机操作密集区账号要提前开。我的做法是让甲方开一个只读的审计账号能看安全策略、账户列表、日志配置、服务列表不改配置。这样既满足检查需要也避免测评过程中误改生产配置引起争议。需要在命令行里看配置的由甲方运维人员操作、测评人员口述指令方案里很多配合需求写的就是「系统管理员配合上机查看」这种分工值得保持。4.4 漏洞扫描与渗透测试的边界别把测评做成攻击方案把工具测试单列出来包括漏扫设备和一批常见渗透测试工具。这一步的风险最高做之前必须把边界划清楚书面授权、时间窗口、源地址报备、速率限制、禁止写操作、禁止社会工程学和口令爆破除非单独授权。授权书要写明测试源 IP 段、目标 IP 段、时间窗口、允许的测试类型、应急联系人。时间窗口避开业务高峰一般放在夜间或周末并且提前通知值班人员避免告警触发后当成真实攻击处置。扫描速率要限全端口全插件的默认配置在老旧设备上很容易打出业务抖动这个锅最后算在测评方头上。扫描器规则库版本要记录进报告不然复测评时无法说明「上次扫出来的漏洞这次没有了是因为修了还是因为规则库没更新」。工具清单里列的具体型号和版本报告里要照录这是可追溯性的一部分。5. 避坑定级备案和现场测评里最容易翻车的五个点这一章的五条都是从返工记录里挑出来的每条按现象、原因、解决三段说。看过一遍至少能少跑两趟现场。5.1 S/A/G 三栏全填「中」专家评审第一个退回现象定级报告交上去专家评审意见写「赋值依据不足无法支撑定级结论」整份退回重写。原因填表的人把三性当成打分项觉得「中等」最保险。实际上 S/A/G 是从受侵害客体和侵害程度倒推出来的必须有推导链条没有链条的赋值在评审时无法质证。解决每个维度单独写一段判据落到数据量、业务量、时间、后果。S 写清泄露的信息类型和条数、可能触发的处罚和损失A 写清允许的最长中断时间、中断期间影响的业务笔数G 一般不单独论证跟随系统等级。三段判据写进报告赋值说明栏评审时直接指给人看。5.2 指标按三级裁系统实际定二级现象测评方案发过去甲方说我们备案是二级你怎么按三级测报告出来等级口径和备案证明对不上复测评时被要求重出。原因直接套用了上一个项目的方案模板指标范围没改。解决指标范围的唯一依据是备案证明上的等级。方案编制第一步就把备案号、备案等级、备案日期抄进方案首页。等级拿不准时按高的准备材料没关系但报告口径必须按备案等级出。如果甲方确实要按高一级做建设整改那是整改建议里的事不改变测评结论的等级口径。5.3 截图缺环境标识报告复核时无法自证现象现场测了两天回来整理证据发现一批配置截图只有中间一块看不到主机名、看不到 IP、看不到时间报告写到一半只能约二次上门。原因截图时图省事只截了配置项本身忽略了「这张图属于哪台设备的哪个时刻」这个基本问题。远程桌面全屏截图还容易把多台机器的窗口叠在一起。解决立一条硬规矩每张截图必须同屏出现三类信息设备标识主机名或 IP、配置项内容、系统时间。做不到就先打开系统信息页再截或者截两张并在记录表里注明关联关系。截图文件名按「证据编号_对象名_序号」命名当场命名不要等回来再猜。5.4 制度文档「有」但版本是上一版现象访谈时安全主管说制度去年修订过翻出来的文档签发日期还是三年前访谈记录和文档证据互相矛盾。原因制度修订后没有走发布流程或者发布了但没有收发文记录纸面版本和实际执行版本脱节。解决查制度不能只看有没有要看三样签发页的批准人和日期、收发文登记记录、宣贯或培训记录。三样齐了才算「已发布并执行」。缺任何一样就在报告里如实写不符合并在整改建议里给出补做发布流程的具体动作。帮着甲方把这三样补齐比在报告里含糊过去更有价值。5.5 漏洞扫描扫出业务中断现象白天对生产系统做全量扫描业务侧反馈页面卡顿、部分接口超时运维直接把扫描 IP 封了。原因没有约定时间窗口和速率扫描器默认并发拉满老旧中间件在高压下响应变慢甚至连接池耗尽。解决扫描前走三步——报备源 IP 和时间窗口、把并发和每秒请求数压到业务可承受范围、先对非生产镜像或测试环境试扫一轮摸清敏感插件。生产扫描安排在业务低谷全程有人值守出问题立刻停。这条血泪经验值一次项目复盘。6. 复测评与整改闭环一张三列台账把不符合项追到底整改阶段最常见的场景是报告出了三十多条不符合项甲方问「先改哪个」测评方答「都重要」然后一个月过去没人动。要破这个局靠的不是催是把不符合项变成可追踪的台账。我一般用三列结构控制项、现状证据编号、整改证据编号。第一列写指标编号和一句话描述第二列指向初次测评时的证据文件第三列留空等整改后填。复测评现场只做一件事——按第一列逐条核第三列有编号的看证据没编号的记未整改。这样复测评的工期基本取决于台账质量而不是现场重新摸一遍。控制项现状证据整改证据优先级HOST-01 身份鉴别E-HOST-01-01E-HOST-01-02高NET-03 访问控制策略E-NET-03-01E-NET-03-02高OPS-07 备份恢复演练E-OPS-07-01待补中DOC-02 制度评审记录E-DOC-02-01E-DOC-02-02低优先级按「风险 × 整改成本」分四档高风低成本的先做这类通常是配置类问题改一条策略、关一个端口、开一个审计项一两天能闭环高风险高成本的进建设规划比如缺双活、缺堡垒机当期改不完就写进整改计划并注明时间节点低风险低成本顺手做低风险高成本可以延后但要在报告里说明理由。这个分档不是学术分类是给甲方排工期用的。复测评取证有个细节值得强调整改后的证据要跟初次证据同角度、同字段重拍。上次截的是「账户策略」页面这次还截这个页面两张图放一起能直接看出改了哪一项。换个角度截等于让人重新对照一遍复核时容易起争议。证据归档用脚本统一命名比手工改名靠谱#!/usr/bin/env bash # 证据归档根目录/测评项编号/测评项编号_对象名_时间戳.png # 用法./collect.sh HOST-01 应用服务器A /tmp/shot.png set -euo pipefail item$1 # 测评项编号与台账第一列一致 host$2 # 测评对象名与方案对照表一致 src$3 # 原始截图路径 root${EVIDENCE_ROOT:-./evidence} # 归档根目录可用环境变量覆盖 dst$root/$item/${item}_${host}_$(date %Y%m%d%H%M%S).png mkdir -p $(dirname $dst) cp $src $dst printf %s\t%s\n $dst $(date -Iseconds) $root/index.txt # 追加索引报告引用时直接查三个参数分别对应台账第一列、方案对照表的对象名、原始文件路径。EVIDENCE_ROOT用环境变量传是为了让初次测评和复测评落到两个不同根目录避免覆盖。index.txt那行是后悔药——报告写完发现某张图引用错了按时间戳能在索引里倒查回原始文件。从那以后我每次开复测评启动会第一件事不是讲进度是把这张三列台账投到屏幕上逐条问「这条谁负责、什么时候能给证据」答不上来的当场标红。台账不漂亮但比任何整改承诺都管用。希望帮到你。本文还有配套的精品资源点击获取