企业官网建设流程全解析

简介：本资源为等保测评服务方案文档，面向信息安全从业者、系统运维人员及需要开展等级保护工作的企业技术人员，帮助读者系统理解等保测评的完整流程与实施要点。压缩包内共1个doc文件，大小约1.07MB，内容涵盖定级与备案、测评依据、被测系统描述、现场测评与复测评等核心模块。文档详细梳理了信息系统定级工作流程，包括确定定级对象、专家评审、主管部门审批及公安机关备案等步骤，并列出GB/T 22239-2008、GB/T 28448-2012等主要测评依据。同时，方案对物理安全、网络安全、主机系统安全、应用安全、数据安全及备份恢复、安全管理机构与制度、人员安全管理、系统建设与运维管理、渗透测试等方面进行了安全检查说明，并给出网络拓扑、业务应用软件、关键数据类别、主机存储设备及安全相关人员等示例表格。目前已有987人学习下载，适合需要编制等保测评方案或了解测评实施细节的读者参考借鉴。

1. 等保测评服务方案拆解：从定级备案到复测评的完整落地路径

手上拿到一份《等保测评服务方案.doc》，很多人第一反应是"这不就是一份投标文档吗"。但如果你真正做过等保项目就知道，这份文档的价值不在于它的格式，而在于它把整个测评流程的骨架、测评指标的数量分布、每个层面的配合需求都列清楚了。我见过太多团队在等保测评启动会上被甲方问"你们打算怎么测、测哪些、需要我们配合什么"时答不上来，根子就在于没有把方案里的测评对象、测评指标和配合需求三张表对齐。这份方案覆盖了定级备案、现场测评四大阶段、复测评三大阶段，涉及物理安全、网络安全、主机安全、应用安全、数据安全及备份恢复、安全管理制度、安全管理机构等十个层面，二级系统合计66项指标、三级系统合计73项指标。适合正在准备等保测评的安全工程师、项目经理，以及需要配合测评的系统管理员和运维人员。

2. 定级与备案：S/A/G三属性判定和备案流程的实操拆解

2.1 定级对象确认与S/A/G矩阵填写

定级是整个等保工作的起点，也是最多人翻车的地方。方案里给出的调研表核心逻辑是：对每个信息系统，分别从保密性（S）、完整性（A）、可用性（G）三个维度判断受侵害客体和侵害程度，最终确定系统服务保护等级和业务信息保护等级，取两者较高值作为系统等级。

实际操作中，我一般会按下面这个流程走：

# 定级信息采集清单（按系统逐个填写） # 1. 系统名称与业务描述 # 2. 数据使用者/管理者及访问权限 # 3. 业务处理信息类别（管理数据/业务数据/鉴别信息） # 4. 各属性的侵害客体（公民/法人/社会秩序/公共利益/国家安全） # 5. 各属性的侵害程度（一般/严重/特别严重）

填写时最容易出问题的是"侵害客体"的判定。方案里明确写了：数据泄露是否会引起法律纠纷和导致财产损失，对应保密性S；数据篡改或丢失是否会引起法律纠纷和导致财产损失，对应完整性A；系统中断对工作职能和业务能力的影响，对应可用性G。这三个问题看起来简单，但实际定级时，业务部门往往倾向于往低了报，安全部门倾向于往高了报，最后需要一个有说服力的判定依据。

我的经验是：先让业务部门填一遍，再让安全部门复核，差异项逐条讨论。讨论时不要空对空，直接拿方案里的调研表逐项过——"这个系统存不存在公民个人身份信息？如果泄露了，是只影响当事人还是会影响一批人？"用具体场景逼出结论，比争论"重要不重要"高效得多。

2.2 备案材料准备与公安机关对接

定级报告出来后，下一步是编制定级报告和填写《信息系统安全等级保护备案表》，然后到所在地市级以上公安机关办理备案。方案里把备案流程拆成了信息系统备案、受理、审核和备案信息管理四步，但实际跑起来，材料准备才是真正耗时间的环节。

常见需要准备的材料包括：

这里有个血泪经验：网络拓扑图一定要用实际运行的拓扑，不要拿建设方案里的设计图充数。公安机关审核时会核对IP段、设备型号、安全设备部署位置，一旦发现拓扑图跟实际对不上，整个备案流程就得重来。我一般会建议客户在提交前，让网络管理员对着拓扑图逐台设备确认一遍，确认无误再提交。

注意：定级备案不是一次性工作。系统发生重大变更（如新增子系统、网络架构调整、业务范围扩展）时，需要重新定级或变更备案。

3. 现场测评四大阶段：从测评准备到报告编制的全流程操作

3.1 测评准备与方案编制

现场测评分为四个阶段：测评准备活动阶段、方案编制活动阶段、现场测评活动阶段、分析和报告编制活动阶段。前两个阶段决定了后面能不能顺利推进，但恰恰是最容易被压缩的环节。

测评准备阶段的核心任务是收集资料和确认测评对象。方案里列出的测评对象包括机房、业务软件、主机、数据库、网络及安全设备、安全管理文档六大类。我一般会在这个阶段做一张测评对象确认表，让甲方逐项确认：

测评对象确认表（示例） ├── 机房：XX集团有限公司办公楼X楼 ├── 业务软件：XX系统（版本号）、XX系统（版本号） ├── 主机：应用服务器X台（IP列表）、数据库服务器X台（IP列表） ├── 网络设备：核心交换机X台、汇聚交换机X台、接入交换机X台 ├── 安全设备：防火墙X台、IDS/IPS X台、WAF X台 └── 管理文档：制度类X份、记录类X份、证据类X份

方案编制阶段则需要根据定级结果选取测评指标。方案里给出了明确的指标数量：二级系统通用指标（GX）加上业务信息安全性指标（SX）和系统服务保证类指标（AX），合计66项；三级系统合计73项。具体分布如下：

从这张表能看出一个关键差异：三级系统在数据安全及备份恢复层面比二级多了6项指标，在系统建设管理和系统运维管理上也有增加。这意味着如果你的系统从二级升到三级，测评工作量不是线性增加，而是在特定层面有跳跃式增长。编制方案时要把这些增量指标对应的测评方法和时间预算单独列出来。

3.2 现场测评实施：访谈、检查、测试三方法配合

现场测评阶段是真正"下场干活"的环节。方案里明确了三种测评方法：访谈、检查、测试。这三种方法不是随便选的，每个安全子类都有对应的推荐方法组合。

以网络安全层面为例，方案里列出的6个工作单元中：

• 结构安全：访谈网络管理员 + 检查网络拓扑 + 核查核心交换机配置
• 访问控制：访谈安全员 + 检查防火墙策略 + 测试对外暴露漏洞
• 安全审计：访谈审计员 + 检查核心交换机/路由器审计配置
• 边界完整性检查：访谈安全员 + 检查边界设备 + 接入设备测试
• 入侵防范：访谈安全员 + 分析攻击行为识别和处理情况
• 网络设备防护：访谈网络管理员 + 检查交换机/路由器/防火墙安全配置

实际操作中，访谈和检查可以并行，但测试环节需要单独安排时间窗口。特别是漏洞扫描和渗透测试，方案里列出的工具包括铱迅漏洞扫描系统（NVS-2000-L，系统版本3.0.03.579，漏洞规则库版本1.0.0.2842）以及SQLmap、Burpsuite、RouterScan、Apache TomcatScan等渗透测试工具。这些工具的使用需要提前跟甲方确认时间窗口和影响范围。

# 漏洞扫描前的确认清单 # 1. 扫描目标IP段确认（避免扫到生产核心） # 2. 扫描时间窗口确认（避开业务高峰期） # 3. 应急回滚方案确认（扫描导致服务异常时的处理流程） # 4. 甲方配合人员确认（网络管理员现场待命）

我一般会建议把扫描时间安排在业务低峰期，比如晚上10点以后或周末。扫描前一定要让网络管理员确认目标IP段，避免扫到不该扫的地址。有一次项目里，扫描器默认配置把整个C段都扫了，结果扫到了一台不该碰的测试机，虽然没造成实际影响，但甲方那边紧张了半天。从那以后，我每次扫描前都会让甲方书面确认目标范围。

3.3 报告编制与复测评衔接

现场测评结束后进入分析和报告编制阶段。这个阶段的核心工作是把现场收集的访谈记录、检查结果、测试数据整理成测评结论，对照GB/T 22239-2008和GB/T 28448-2012的要求逐项判定符合、部分符合或不符合。

报告编制中最容易出问题的是证据链不完整。比如某个安全子类判定为"符合"，但访谈记录里没有对应的问题和回答，检查记录里没有截图或配置导出，测试记录里没有原始数据。这种"结论有、证据无"的情况在复测评时会被重点核查。

复测评分为三个阶段：安全整改活动阶段、复测评活动阶段、分析和报告编制阶段。整改阶段是甲方根据初测评报告进行安全加固，复测评阶段则是对整改结果进行验证。这里有个常见误区：很多甲方以为整改就是把不符合项改到符合就行，但实际上复测评不仅要看整改项，还要确认整改过程中没有引入新的安全问题。

提示：复测评的测评指标与初测评一致，但测评重点会向整改项倾斜。建议在整改完成后、复测评开始前，先做一轮内部自查，把整改证据整理成册，能显著缩短复测评现场时间。

4. 十个安全层面的测评指标拆解与配合需求清单

4.1 物理安全与网络安全：从机房检查到边界测试

物理安全层面涉及10个安全子类，测评对象主要是机房。方案里列出的配合需求非常具体，我把它整理成了一张可直接发给甲方的配合清单：

网络安全层面的测评实施分为三部分：网络全局测评、网络设备防护测评、工具测试。网络全局测评主要针对结构安全、边界完整性、入侵防范、恶意代码防范四个控制点；网络设备防护测评针对访问控制、安全审计、网络设备防护三个控制点；工具测试则是对网络设备和服务器进行漏洞扫描。

这里有个实操细节：方案里提到的"边界完整性检查"需要接入边界完整性检查设备进行测试，目的是发现信息系统是否存在私自联到外部网络的行为。这个测试需要网络管理员配合，在测试机上模拟非法外联，观察边界设备是否能检测到并阻断。我一般会提前跟网络管理员确认边界设备的告警方式（邮件、短信、控制台弹窗），测试时同步记录告警时间和内容，作为测评证据。

4.2 主机安全与应用安全：配置核查与功能验证

主机系统安全层面涉及7个安全子类，测评对象是管理终端和管理支撑服务器（包括审计服务器、防病毒服务器、补丁升级服务器等）。方案里列出的测评实施方式主要是访谈和查看，需要系统管理员配合上机操作。

# 主机安全配置核查清单（Windows Server示例） # 1. 身份鉴别：本地安全策略 -> 账户策略 -> 密码策略 # 2. 访问控制：查看用户组权限分配、重要文件ACL # 3. 安全审计：审核策略配置、事件日志大小和保留时间 # 4. 剩余信息保护：内存清理策略、页面文件清理 # 5. 入侵防范：系统补丁版本、开放端口和服务列表 # 6. 恶意代码防范：防病毒软件安装和病毒库版本 # 7. 资源控制：远程登录限制、会话超时设置

应用安全层面同样涉及7个工作单元，但测评方式更偏向功能验证。方案里明确要求系统管理员配合应用测评师上机查看软件是否具备鉴别信息复杂度检验、登录失败处理、访问控制、安全审计、通信完整性、通信保密性、软件容错、资源控制等功能。

这里有个容易忽略的点：通信完整性和通信保密性需要查看客户端和服务器端之间的通信保护情况。实际操作中，如果应用系统使用的是HTTPS，需要确认证书是否有效、加密套件是否符合要求；如果使用的是自定义加密协议，需要查看加密算法和密钥管理方案。我一般会建议应用开发方提前准备好通信安全的设计文档，避免现场解释不清。

4.3 数据安全与安全管理：备份验证与制度核查

数据安全及备份恢复层面在二级和三级之间有显著差异。二级只有3项指标（数据完整性、数据保密性、安全备份和恢复），三级则有9项，增加了剩余信息保护、数据有效性检验等内容。测评方式主要是访谈和检查，需要数据备份管理员出示业务数据备份文件。

安全管理层面的测评涉及安全管理制度、安全管理机构、人员安全管理、系统建设管理、系统运维管理五个方面。方案里对每个方面都列出了测评内容和配合需求，核心是访谈安全主管和检查相关文档。

安全管理层面的测评最容易被低估。很多技术出身的测评师把精力都放在技术层面，到了管理层面就随便翻翻文档。但实际上，管理层面的指标数量在二级系统里占了34项（3+5+5+9+12），超过总数66项的一半。如果管理层面准备不充分，整体测评结论会受到很大影响。

注意：安全管理文档的测评不是看有没有，而是看内容是否覆盖要求、是否经过审批、是否有执行记录。一份没有审批签字的制度文档，在测评中会被判定为"部分符合"甚至"不符合"。

5. 等保测评避坑指南：五条踩坑记录与排查方法

5.1 定级偏差导致测评指标选错

现象：系统实际应按三级测评，但定级时按二级备案，现场测评时发现部分安全要求无法覆盖。

原因：定级时对S/A/G属性的侵害客体判定偏轻，或者业务部门刻意压低等级以减少整改投入。

解决：定级阶段就要让安全部门深度参与，对每个系统的S/A/G判定逐项复核。如果已经备案但发现定级偏差，需要重新定级并变更备案，不要试图在测评阶段"将错就错"。

5.2 测评对象遗漏导致报告不完整

现象：测评报告提交后，甲方发现某个子系统或某台关键设备没有被纳入测评范围。

原因：测评准备阶段的对象确认表没有覆盖全部资产，或者甲方在测评期间新增了设备但未告知测评方。

解决：准备阶段要求甲方提供完整的资产清单，并与网络拓扑图逐项核对。测评期间如果甲方有变更，需要及时更新测评对象清单并评估是否影响测评结论。

5.3 漏洞扫描影响业务导致紧急回滚

现象：扫描过程中业务系统响应变慢甚至中断，甲方要求立即停止扫描。

原因：扫描策略过于激进，或者扫描目标包含了生产核心系统且未做限流。

解决：扫描前确认目标范围和扫描策略，对生产系统使用低速率扫描模式，避开业务高峰期。同时准备好应急回滚方案，一旦出现异常立即停止扫描并恢复。

5.4 管理层面文档准备不足导致反复整改

现象：技术层面测评顺利通过，但管理层面大量指标判定为"不符合"，需要反复补充材料。

原因：甲方把精力都放在技术加固上，忽视了管理制度的制定、发布、评审和修订流程。

解决：在测评准备阶段就把管理层面的文档清单发给甲方，要求提前整理。重点检查制度文档是否有审批签字、是否有发布记录、是否有定期评审修订记录。

5.5 复测评整改不彻底导致二次不符合

现象：初测评发现的不符合项，整改后复测评仍然不符合。

原因：整改只做了表面工作，没有从根本上解决问题。比如要求"关闭不必要的端口和服务"，整改时只是临时关闭，复测评前又因为业务需要重新开启了。

解决：整改阶段要形成整改方案，明确每个不符合项的根本原因和整改措施。复测评前先做内部自查，确认整改措施持续有效。对于确实无法整改的项，需要准备风险说明和补偿措施。

6. 测评指标数量背后的选型逻辑与报告编制技巧

很多人看等保测评方案，只关注"要测什么"，忽略了"为什么测这么多"。方案里给出的二级66项、三级73项指标，不是随便定的，而是根据GB/T 22239-2008中不同等级的安全要求推导出来的。理解这个推导逻辑，能帮你在方案编制和报告编制时做出更准确的判断。

先看二级和三级在数据安全及备份恢复层面的差异：二级3项，三级9项。多出来的6项主要涉及剩余信息保护、数据有效性检验、备份介质场外存放等要求。这意味着三级系统在数据安全上的要求不是"做多做少"的问题，而是"做不做"的问题。如果你的系统定级为三级，但数据备份还停留在本地磁盘层面，没有场外存放和定期恢复测试，这一块会直接判定为不符合。

再看系统建设管理和系统运维管理：二级分别是9项和12项，三级分别是11项和13项。增量主要在安全方案设计、产品采购和使用、工程实施、测试验收等环节。这些指标的特点是"过程性"——不是看最终结果，而是看过程记录。比如"安全方案设计"要求有安全方案设计文档，并且经过论证和审定；"产品采购和使用"要求有产品采购清单和安全产品使用配置记录。这些材料如果平时没有积累，测评前临时补是补不出来的。

报告编制时，我一般会按下面的结构组织：

测评报告结构 ├── 测评项目概述（项目背景、测评目的、测评依据） ├── 被测系统描述（系统定级、网络结构、系统构成） ├── 测评对象与指标（测评对象清单、测评指标选取） ├── 测评内容与实施（按安全层面逐项描述测评方法和结果） ├── 测评结论（整体符合性判定、不符合项汇总） └── 附件（访谈记录、检查记录、测试记录、证据截图）

其中"测评内容与实施"是报告的主体部分，需要按物理安全、网络安全、主机安全、应用安全、数据安全及备份恢复、安全管理六个层面逐项展开。每个安全子类都要写清楚测评方法（访谈/检查/测试）、测评实施过程、测评证据和测评结论。测评结论的判定要严格对照GB/T 28448-2012中的判定标准，不能凭感觉写"基本符合"这种模糊结论。

最后说一个报告编制中的实用技巧：证据截图要带时间戳和系统标识。比如检查Windows服务器密码策略，截图里要能看到服务器主机名、当前时间、密码策略配置界面。这样在复测评或专家评审时，能快速定位证据来源，避免"这张截图是哪台机器的"这种问题。

从那以后我每次做等保项目，都会在测评准备阶段就把证据采集模板发给团队，要求现场人员按模板采集证据，避免报告编制时发现证据缺失再回头补。希望帮到你。

本文还有配套的精品资源，点击获取