等保测评服务方案落地：定级备案、指标分解与现场取证顺序

简介围绕信息系统等级保护测评全流程整理的Word方案文档面向企业安全负责人、等保测评实施人员及合规建设团队可用于定级备案、测评准备、方案编制与整改建设等场景帮助读者快速搭建等保测评服务方案框架。压缩包内共1个doc文件大小约1.07MB正文以方案说明、流程表格和检查项清单为主便于按章节查阅与二次编辑。已有989人学习下载具备一定参考热度。内容覆盖系统定级与备案、测评依据、被测系统描述、现场测评四阶段及复测评三阶段并涉及物理安全、网络安全、主机与应用安全、数据备份恢复、安全管理机构和制度、人员安全、系统建设与运维管理、渗透测试等维度可作为项目立项、投标响应、测评准备和安全整改的参考底稿。1. 先整改还是先测评等保测评服务方案到底该按什么顺序落地先整改还是先测评这个问题在项目启动会上吵过不止一次。多数人的直觉是先扫出漏洞再统一修但等保测评的结论必须建立在“基线可判定”的基础上——定级没定准、测评指标选错、对象清单漏项后面所有整改都是白做。某高校的信息管理系统项目就踩过这个坑二级系统按三级指标准备整改预算翻倍复测评时仍因为定级报告里业务信息安全性S取值缺少依据被退件。这份等保测评服务方案要解决的是从定级、备案、现场测评到复测评的完整链路谁提供什么材料、哪些指标落到哪台设备、访谈记录和配置截图怎么留证据、报告结论怎么站得住。适合准备迎接等级保护测评的甲方技术负责人、要交付完整等保方案的乙方工程师以及把它当课题拆解的学生——照着这条线搭骨架能省掉大半试错成本。2. 定级与备案S/A/G 三维赋值和定级报告的落地方法定级是整条链路的起点也是最容易被当成“填表”糊弄过去的一步。实际上后面测什么指标、配什么工具、请哪些人访谈、报告写多少条全部由定级结果决定。这一章把定级对象的切分、S/A/G 的赋值逻辑、报告和备案材料的编制顺序拆开讲清楚。2.1 定级对象怎么切一个系统一个对象还是把共享资源并进去定级对象通常是一个独立提供服务的业务系统但现实里经常遇到共享数据库、统一认证、虚拟化资源池这些“粘合剂”。判据一般看三条有没有独立的信息系统结构独立的应用、数据库、网络边界承载的业务能否独立描述是否由同一管理机构负责运行。三条都满足单独定级只是同一系统的功能模块不拆。某公司的信息管理系统把业务应用、数据库、门户拆成三个定级对象结果专家评审时被指出数据库和业务应用的安全边界根本分不开又合并回一个对象重新写报告。对象边界确定后要画一张边界图标出涉及的主机、数据库、网络设备、安全设备以及系统与外部交互的接口。这张图后面会被直接引用到备案材料和测评方案里所以画的时候就把设备名称和用途写全避免后面反复改。通常的做法是先拉一份资产清单按“应用到数据库到主机到网络边界”的路径串一遍串不通的资产就说明边界没画对。2.2 S/A/G 三维赋值从侵害客体到等级矩阵业务信息安全性S看业务信息被破坏后对客体的侵害程度系统服务保证性A看系统服务中断后对客体的侵害程度G 是通用指标不参与等级判定。赋值顺序是先列业务信息类别管理数据、业务数据、鉴别信息等再对每一类判断泄露、篡改、丢失后受侵害的客体和程度查矩阵得 S对系统服务中断同样判断得 A最终等级取 S 和 A 的高者。受侵害的客体一般损害严重损害特别严重损害公民、法人和其他组织的合法权益第一级第二级第二级社会秩序、公共利益第二级第三级第四级国家安全第三级第四级第五级# 等保定级矩阵根据受侵害客体和侵害程度给出保护等级 # 客体类型citizen 公民法人其他组织society 社会秩序公共利益state 国家安全 # 侵害程度general 一般损害serious 严重损害severe 特别严重损害 LEVEL_TABLE { (citizen, general): 1, (citizen, serious): 2, (citizen, severe): 2, (society, general): 2, (society, serious): 3, (society, severe): 4, (state, general): 3, (state, serious): 4, (state, severe): 5, } def judge_level(object_type: str, harm: str) - int: # 查矩阵输入不合法直接抛错避免报告里写出不存在的等级 key (object_type, harm) if key not in LEVEL_TABLE: raise ValueError(f未知的定级输入: {key}) return LEVEL_TABLE[key] def final_level(s_input: tuple, a_input: tuple) - int: S 和 A 分别定级系统最终等级取二者高者 s_level judge_level(*s_input) # (客体, 侵害程度) a_level judge_level(*a_input) return max(s_level, a_level) if __name__ __main__: # 例业务信息泄露影响社会秩序、严重损害 - S3系统中断影响公民权益、一般损害 - A1 print(final_level((society, serious), (citizen, general))) # 输出 3这段代码把报告里最容易写错的两个字段拆开先分别算 S 和 A再取高值。参数对应定级报告里的“受侵害客体”和“侵害程度”两栏填报告时按这两栏对照抄即可。注意 G 不参与运算——G 是通用指标等级定下来之后统一套用不要混进 S/A 的计算里。实际项目中S 通常要按业务信息类别逐条赋值取其中最高的一条作为 S 等级而不是拍脑袋给一个整体判断。2.3 定级报告、备案表与专家评审材料清单和顺序定级工作流程是确定定级对象、确定等级、组织专家评审、主管部门审批、公安机关审核。备案流程是信息系统备案、受理、审核、备案信息管理。顺序不能反——先专家评审再备案是硬要求评审意见里要有会议时间、评审专家名单和逐条意见只有签字没有过程记录的材料受理窗口通常会退回。材料用途常见缺项定级报告说明等级判定依据S/A 赋值没有逐项对应业务信息类别专家评审意见证明定级经过论证缺会议签到表或评审流程记录备案表公安备案系统名称与定级报告不一致网络拓扑图说明系统边界未标注测评对象和边界设备安全管理制度目录配合管理层面测评制度没有发布文号或版本号我一般会先做一份“系统名称与边界基准表”把系统全称、简称、包含的主机和数据库、边界设备固定下来所有材料从这张表里抄。这样能避免备案表写一个名字、定级报告写另一个名字、拓扑图上又是第三个名字的低级翻车。3. 测评指标分解与对象清单让 66 项和 73 项落到具体设备和文档上指标表看起来是一堆数字落到项目里其实是工作量估算和覆盖度核对的依据。二级系统合计 66 项三级系统合计 73 项增量主要落在数据安全及备份恢复、主机安全、系统建设管理和系统运维管理几个层面。这一章讲三件事指标类怎么分、对象清单怎么建、三种取证方法怎么配。3.1 G/S/A 三类指标的分解逻辑G 是通用指标所有系统都要满足S 是业务信息安全性指标关注业务信息的保密性、完整性、可用性A 是系统服务保证性指标关注服务的连续性和可靠性。按层面拆开看二级和三级的主要差异如下安全层面二级指标数三级指标数物理安全1010网络安全67主机系统安全67数据安全及备份恢复39应用安全73安全管理制度33安全管理机构55人员安全管理55系统建设管理911系统运维管理1213合计6673这些数字在方案里主要干两件事估算工作量每个指标按访谈、检查、测试的取证时间折算人天核对覆盖度报告里每个层面都要有对应的指标条数少一条就是漏项。实际执行时以测评要求标准文本里的条款为准方案里的统计表只作为核对基线不要拿它替代标准原文。3.2 测评对象清单设备、软件、文档、人员四张表对象清单要和指标一一对应否则现场做到一半会发现某个控制点找不到被测对象。通常按四类建表机房与物理环境、网络与安全设备、主机与数据库、业务应用与安全管理文档外加一张安全相关人员表。每个对象标注名称、型号或版本、物理位置、所属系统、重要程度。# 测评对象清单按类型归并检查每个安全层面是否被对象覆盖 from collections import defaultdict OBJECTS { 机房: {location: 某办公楼, layers: [物理安全]}, 应用服务器: {count: 3, os: Windows Server, layers: [主机安全, 数据安全]}, 数据库服务器: {count: 3, db: Oracle, layers: [主机安全, 数据安全]}, 核心交换机: {count: 1, layers: [网络安全]}, 防火墙: {count: 1, layers: [网络安全]}, 入侵防御设备: {count: 1, layers: [网络安全]}, Web应用防火墙: {count: 1, layers: [网络安全, 应用安全]}, 安全管理制度文档: {count: 3, layers: [安全管理制度, 安全管理机构]}, } def coverage(objects): 统计每个安全层面被几个对象覆盖防止漏项 result defaultdict(list) for name, meta in objects.items(): for layer in meta[layers]: result[layer].append(name) return dict(result) if __name__ __main__: for layer, items in coverage(OBJECTS).items(): print(f{layer}: {len(items)} 个对象 - {items})这段脚本的作用是在进场前做一次覆盖度自检哪个层面只有一个对象撑着哪个层面一个对象都没有一眼就能看出来。参数上只需要维护 OBJECTS 字典对象增减时同步改 layers 字段。实际项目中对象清单还要和资产清单对一遍避免出现“资产表里有、测评对象表里没有”的机器那类机器往往是风险最集中的地方。3.3 访谈、检查、测试的配比与取证形式三种方法不是平均用力。技术类指标以检查为主、访谈补充管理类指标以访谈为主、文档检查补充网络、主机、应用层面在检查基础上叠加工具测试。配比大致如下安全层面访谈对象检查内容测试手段物理安全物理安全负责人、机房值守机房现场、设备、验收文档无网络安全网络管理员、安全员设备配置、访问控制策略漏洞扫描、策略验证主机安全系统管理员账号策略、审计配置、补丁漏洞扫描应用安全应用管理员鉴别、权限、审计功能渗透测试数据安全数据库管理员、备份管理员备份文件、加密配置恢复验证安全管理安全主管、各岗位管理员制度、记录、审批文档无取证形式上截图要带主机名和系统时间配置导出保留原始文件访谈记录写清问题、回答、证据位置并由被访谈人签字。工具测试要提前确认测试范围和授权扫描策略避开业务高峰期渗透测试禁止使用可能破坏数据的 payload。4. 现场测评实施十个安全层面的取证动作和配合清单现场测评分成准备、方案编制、现场测评、分析报告四个阶段真正占时间的是现场取证和后面的证据整理。这一章按层面把每个动作和需要甲方配合的材料列出来方便进场前直接当检查表用。4.1 物理安全十项检查怎么在半天内做完物理安全涉及物理位置选择、物理访问控制、防盗窃防破坏、防雷击、防火、防水防潮、防静电、温湿度控制、电力供应、电磁防护十个控制点。现场动作可以按“看环境、看设备、看文档”三条线走看环境包括机房位置是否在顶层或地下室、出入口门禁和登记、空调和漏水检测看设备包括灭火装置、防雷接地、UPS、防静电地板看文档包括建筑验收资料、防雷检测报告、消防验收记录、温湿度记录、UPS 维护记录。控制点现场动作需要甲方提供物理位置查看机房所在楼层、墙体结构房屋建筑资料物理访问控制查看门禁、登记本、陪同记录出入登记、审批记录防盗窃防破坏查看设备固定、报警装置报警运行维护记录防雷击查看接地、配电柜建筑防雷检测报告防火查看灭火器、火灾报警消防验收、检查记录防水防潮查看空调排水、漏水检测建筑施工图、验收文档防静电查看防静电地板、接地防静电接地措施说明温湿度查看空调、温湿度计温湿度记录本文还有配套的精品资源点击获取