关键信息基础设施网络安全保护基本要求：五环节闭环与工程化落地指南

简介：这份资源是《信息安全技术 关键信息基础设施网络安全保护基本要求》的国家标准征求意见稿文档，面向网络安全从业者、等保测评人员及合规管理人员，用于理解关键信息基础设施安全保护的规范框架与落地要求。文档围绕识别认定、安全防护、检测评估、监测预警、应急处置等环节展开，并附有安全保密协议模板与参考文献，可帮助读者梳理CII保护的整体流程与条款依据。资源包共1个doc文件，约865KB，内容为完整标准正文，便于离线查阅与引用。目前已有1937人学习下载，适合需要对照标准开展合规自查、方案编写或培训备课的读者参考使用。

1. 一份被低估的基线文档：关键信息基础设施网络安全保护基本要求

很多做等保合规的同行，手里都攥着 GB/T 22239 的测评项，却对关键信息基础设施（CII）这条线缺乏体感。这份《信息安全技术 关键信息基础设施网络安全保护基本要求》征求意见稿，恰恰是把《网络安全法》里那句"在网络安全等级保护制度的基础上，实行重点保护"落成可执行动作的基线类标准。它不讲空泛原则，而是把运营者的义务拆成识别认定、安全防护、检测评估、监测预警、应急处置五个环节，每个环节都给了能对照检查的条款。适合谁看？一是正在做 CII 认定的运营单位安全负责人，二是给金融、能源、交通类客户做合规咨询的乙方工程师，三是想把等保和关基两条线打通的技术管理者。它解决的核心问题是：等保过了，关基的额外要求到底加在哪、加多少、怎么留证据。

2. 五个环节的闭环逻辑：从识别认定到应急处置怎么串起来

2.1 为什么是这五个环节而不是照搬等保

等保的思路是定级、备案、建设整改、等级测评、监督检查，偏重"系统上线前后的合规动作"。而这份标准把视角切到"持续运营"，五个环节构成一个动态循环：识别认定是起点，安全防护是常态，检测评估是体检，监测预警是哨兵，应急处置是兜底。原文 4.1 节明确说，识别认定是开展后续四个环节工作的基础。这意味着如果你连关键业务链和资产清单都没梳理清楚，后面的防护措施就是无根之木。

我一般会建议客户先画一张业务链映射图：从对外提供的公共服务出发，倒推支撑它的应用系统、数据库、网络设备、工控组件，一直落到机房和供应链。这张图就是识别认定的产出物，也是后面所有环节的索引。标准 4.2.1 要求"梳理关键业务链，建立关键业务链相关的网络、系统和资产清单"，4.2.2 要求"识别关键业务链各环节的主要安全风险点，明确安全防护优先级"。注意"优先级"三个字，它意味着资源有限时你得知道先保什么。

2.2 识别认定的落地动作与资产清单模板

识别认定不是填一张表就完事。标准 4.2.3 特别提到，新建、停运、改建、扩建等重大变化时要重新开展自识别并更新清单、报告工作部门。这条在实际执行中最容易被忽略——很多单位做完一次认定就锁进柜子，系统改了也不更新，等到抽查时清单和实际对不上，直接暴露管理缺陷。

下面这张表是我在项目里常用的资产清单字段，比标准原文更细，但每一项都能对应到后续条款：

填这张表时有个血泪经验：不要只让 IT 部门填，业务部门必须参与。关键业务链的起点是业务，不是服务器。我见过一个案例，运维把一台对外提供查询服务的服务器标成"低优先级"，因为 CPU 占用低、流量小，但业务部门说这是面向公众的核心查询入口，一旦中断会引发投诉。优先级判断必须业务和技术一起定。

2.3 安全防护条款的工程化拆解

安全防护是条款最密集的一章，从 4.3.1 到 4.3.15 共十五条。我把它归成四类：组织人员类（4.3.2 到 4.3.7）、数据安全类（4.3.8）、系统与通信类（4.3.9 到 4.3.12）、供应链类（4.3.13 到 4.3.15）。

组织人员类里，4.3.4 要求安全管理机构负责人由运营者主要负责人担任，并对关键岗位人员进行安全背景审查。这条在落地时经常卡住，因为"主要负责人"的定义模糊。常见做法是让分管安全的副总或 CTO 挂名，但审查记录要留痕，包括审查时间、审查内容、结论。4.3.7 给了培训时长的硬指标：关键信息基础设施从业人员年度培训不少于 1 个工作日，关键岗位不少于 3 个工作日。这个数字是可以直接写进年度安全计划的。

数据安全类只有 4.3.8 一条，但分量极重：境内运营收集和产生的个人信息和重要数据存储在境内，出境要走安全评估。工程上对应的是数据分类分级、重要数据备份、加密认证三项技术措施。我一般会建议客户先做数据资产盘点，把数据库、文件服务器、对象存储里的数据按敏感程度打标，再决定哪些加密、哪些备份、备份频率多少。

系统与通信类里，4.3.9 的分区分域和 4.3.11 的日志留存是测评必查项。日志留存不少于 6 个月，内容至少包括事件日期时间、类型、主体、客体、结果。很多单位的日志只记了时间戳和 IP，缺少"主体"和"结果"，这在检查时会被判不符合。远程运维行为的控制和审计是重点，建议单独建一条运维审计通道，所有操作录屏加命令日志。

供应链类容易被当成采购部门的事，但 4.3.13 到 4.3.15 明确要求运营者承担检测和报告责任。采购的网络产品上线前要做安全检测，发现漏洞要及时消除，重大风险要报告。合同里要明确提供者的安全责任，参考附录 A 签安全保密协议。附录 A 的模板可以直接用，里面把技术信息、业务信息、安全信息都列进了保密范围，违约责任也写得比较硬。

2.4 检测评估、监测预警、应急处置的衔接点

检测评估（4.4）的核心数字是"每年至少一次"，新建改建扩建后要委托工作部门认可的机构检测，整改后才能上线。4.4.4 要求配合抽查，提供网络拓扑图、重要资产清单、关键业务介绍、网络日志等资料。这里有个坑：很多单位平时不整理拓扑图，抽查时临时画，画出来的和实际不一致，反而扣分。建议把拓扑图纳入变更管理，网络一改就更新。

监测预警（4.5）的监测内容列了六项：漏洞利用攻击、间谍软件、病毒蠕虫、木马后门、异常流量、敏感信息泄露。这六项基本覆盖了主流威胁类型，可以作为安全设备选型的对照表。4.5.5 要求与工作部门、研究机构、安全服务机构共享漏洞、威胁、最佳实践、前沿技术信息。共享机制不是单向汇报，而是双向的，运营者也要主动获取外部情报。

应急处置（4.6）里有两个硬指标：每年至少组织 1 次应急演练，重要系统和数据按 GB/T 20988-2007 三级及以上要求处置。三级要求的核心是远程备份加可接受的时间窗口恢复。4.6.4 规定事件处置完成后要书面报告，内容至少包括事件描述、原因和影响分析、处置方式。这份报告就是复盘和改进的输入，4.6.7 要求据此重新开展风险识别、更新安全策略，闭环回到识别认定。

3. 把条款变成可执行脚本：日志留存与备份的自动化检查

3.1 日志留存 6 个月的自动化巡检脚本

4.3.11 要求系统、网络设备日志留存不少于 6 个月。人工翻设备不现实，我一般写个巡检脚本，通过 SSH 登录网络设备拉取日志配置和存储状态，输出不符合项。下面是一个基于 Python 的示例，用 paramiko 连接设备执行命令：

import paramiko import re from datetime import datetime # 设备清单：实际项目从 CMDB 或资产表读取 devices = [ {"ip": "10.0.0.1", "user": "audit", "pass": "******", "type": "switch"}, {"ip": "10.0.0.2", "user": "audit", "pass": "******", "type": "firewall"}, ] # 不同设备查看日志配置的命令不同，这里以常见命令为例 CMD_MAP = { "switch": "display logbuffer", "firewall": "display logbuffer", } def check_log_retention(dev): ssh = paramiko.SSHClient() ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()) try: ssh.connect(dev["ip"], username=dev["user"], password=dev["pass"], timeout=10) stdin, stdout, stderr = ssh.exec_command(CMD_MAP[dev["type"]]) output = stdout.read().decode("utf-8", errors="ignore") # 检查日志缓冲区大小或最早日志时间，判断是否覆盖 6 个月 # 实际判断逻辑需根据设备型号调整，这里仅示意 if "logbuffer" in output.lower(): print(f"[OK] {dev['ip']} 日志缓冲区存在") else: print(f"[WARN] {dev['ip']} 未发现日志缓冲区配置") except Exception as e: print(f"[FAIL] {dev['ip']} 连接失败: {e}") finally: ssh.close() if __name__ == "__main__": print(f"巡检时间: {datetime.now()}") for d in devices: check_log_retention(d)

逻辑说明：脚本遍历设备清单，通过 SSH 执行日志查看命令，判断日志缓冲区是否存在。参数说明：devices列表里的 IP、账号、密码应从配置中心读取，不要硬编码；CMD_MAP按设备类型映射命令，华为、H3C、思科的查看命令不同，需要按实际环境改。这个脚本只能做初步筛查，真正的留存时长要看日志服务器上的存储周期，建议结合 SIEM 或日志平台的保留策略一起检查。

3.2 备份策略的验证方法与参数

4.3.12 要求对重要系统和数据库进行容灾备份，制定策略、规定频率、定期执行。4.6.5 进一步要求重要系统和数据按 GB/T 20988-2007 三级及以上处置。三级的关键参数是 RTO（恢复时间目标）和 RPO（恢复点目标）。我一般会建议客户在备份策略文档里明确写：核心数据库 RPO 不超过 15 分钟，RTO 不超过 2 小时；一般重要系统 RPO 不超过 24 小时，RTO 不超过 8 小时。这些数字不是标准原文规定的，而是根据业务容忍度定的，但写进文档后就有了检查依据。

验证备份是否可用，不能只看备份任务成功日志。常见做法是每季度做一次恢复演练，从备份介质恢复一个测试库，跑一遍业务查询。下面是一个 MySQL 逻辑备份加恢复验证的命令序列：

# 备份：每天凌晨 2 点全量，保留 30 天 mysqldump -u backup_user -p'******' --single-transaction --routines --triggers \ --databases critical_db > /backup/critical_db_$(date +%F).sql # 压缩并计算校验值，便于验证完整性 gzip /backup/critical_db_$(date +%F).sql md5sum /backup/critical_db_$(date +%F).sql.gz >> /backup/checksum.log # 恢复验证：在测试实例上导入 gunzip -c /backup/critical_db_2025-01-01.sql.gz | mysql -u test_user -p'******' test_db # 验证行数和关键表 mysql -u test_user -p'******' -e "SELECT COUNT(*) FROM test_db.orders; SELECT COUNT(*) FROM test_db.users;"

参数说明：--single-transaction保证 InnoDB 表一致性快照，不锁表；--routines --triggers导出存储过程和触发器；--databases指定库名。恢复验证时要在隔离环境做，避免影响生产。校验值记录到checksum.log，恢复前先比对，防止备份文件损坏。这套流程写进运维手册，检查时直接拿记录。

4. 避坑与排查：条款落地时最容易翻车的五个点

4.1 资产清单和实际不一致

现象：抽查时提供的资产清单里有一台服务器，但实际已经下线半年；或者清单里没有某台新上的数据库，但它在承载关键业务。原因：识别认定做完后没有建立变更触发机制，4.2.3 要求的"重大变化时重新识别"没有落地。解决：把资产清单纳入变更管理流程，任何新建、停运、改建、扩建都要触发清单更新，每季度做一次清单和 CMDB、监控系统的对账。

4.2 日志留存时间够但内容不全

现象：日志服务器上确实存了 6 个月，但抽查时发现日志里只有时间戳和源 IP，没有操作主体和结果。原因：设备日志级别设置过低，或者只开了流量日志没开操作日志。解决：对照 4.3.11 的日志内容要求，逐项检查设备配置，确保日期时间、类型、主体、客体、结果五个字段都有。远程运维日志要单独确认，建议在堡垒机上开全量命令记录。

4.3 培训时长凑不够

现象：年度培训记录显示关键岗位人员只培训了 1 天，不满足 3 个工作日。原因：把全员安全意识和关键岗位技能培训混在一起算。解决：分开做计划，全员培训至少 1 个工作日，关键岗位（系统管理、网络管理、安全管理）单独安排 3 个工作日的技能培训和考核，保留签到表、课件、考核成绩。

4.4 供应链安全协议签了但没核实

现象：合同里附了安全保密协议，但提供者有没有实际遵守没有检查记录。原因：4.3.14 要求"对提供者履约情况进行核实"，很多单位只签不查。解决：建立供应商安全核查表，每年至少核查一次，内容包括漏洞修复响应时间、安全事件报告记录、人员变动情况。核查记录留档，作为履约证据。

4.5 应急演练变成桌面推演

现象：每年做了应急演练，但只是开会讨论流程，没有实际切换或恢复操作。原因：4.6.1 要求"每年至少组织 1 次应急演练"，没有规定形式，容易走形式。解决：至少每两年做一次实操演练，比如实际切换到备用节点、从备份恢复一个系统。演练后按 4.6.4 写报告，按 4.6.7 更新安全策略。实操演练的风险要提前评估，选非核心业务或测试环境做。

5. 从合规到实战：用检测评估结果反哺防护优先级

检测评估不是终点，而是下一轮识别认定的输入。4.6.7 说得很清楚：根据检测评估、监测预警中发现的安全问题及处置结果开展综合评估，重新开展风险识别，并更新安全策略。我一般会建议客户把每次检测评估的发现项按风险等级和修复成本排个序，形成一张改进路线图。高风险低成本的立即修，高风险高成本的立项修，低风险低成本的顺手修，低风险高成本的接受或补偿控制。

具体操作上，可以建一张改进跟踪表，字段包括：发现项、对应条款、风险等级、修复措施、责任人、计划完成时间、实际完成时间、验证方式。这张表每季度过一遍，和年度安全计划对齐。验证方式要写清楚，比如"重新扫描确认漏洞关闭""恢复演练通过""日志抽查连续 7 天完整"。

还有一个容易被忽略的点：4.4.2 要求检测评估结果和整改情况及时上报安全保护工作部门。上报不是交一份报告就完事，而是建立常态化沟通渠道。我习惯在每次检测评估后主动和对接人沟通一次，说明发现了什么、打算怎么改、需要什么支持。这样等到抽查时，对方对你的情况有底，沟通成本低很多。

从那以后我每次做关基项目，都会先把五个环节的闭环图贴在工位上，每完成一个环节就问一句：这个环节的产出物能不能作为下一个环节的输入？识别认定的清单能不能支撑防护优先级？检测评估的发现能不能驱动策略更新？如果哪一环断了，合规就是纸面的。希望帮到你。

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