简介针对计算机信息系统分级保护需求方案文档从总体部署与物理安全两条主线展开适合涉密信息系统建设、分保测评及安全加固相关工程师参考。文档明确以核心交换机为中心划分服务器区、安全管理区与终端区通过VLAN隔离、ACL策略、防火墙/访问控制中间件桥接等方式控制流向同时说明邮件系统分级权限与17级密级流向规则。物理安全部分覆盖红外对射、红外报警、视频监控、门禁系统、线路干扰仪等防护手段并给出部署位置、运行策略及管理维护建议能够与实际工程落地直接对应。资源共1个doc文件大小2.06MB内容结构完整、表格数据详实便于直接复用为方案编写模板。已有58人学习对于正在编制分级保护方案或准备分保评审的技术人员具有较高参考价值。1. 拿到“计算机信息系统分级保护方案”任务后别急着打开等保模板做了多年保密相关信息化项目我见过不少团队拿到“计算机信息系统分级保护方案”任务后第一反应是去模板库套等级保护等保的文档。这个动作通常会把项目拖进连续返工的泥潭分级保护面向的是涉密信息系统按秘密、机密、绝密三个密级展开与面向非涉密系统的等级保护不是同一套评价体系。分级保护方案要解决的是三个问题这台系统涉及的国家秘密怎么定级不同密级的业务放在哪些安全域以及相应的技术与管理措施怎么落到文档并被评审认可。它最适合两类人读一类是涉密单位保密办与信息化人员需要独立理解方案编制逻辑另一类是系统集成商和咨询顾问要把业主的保密需求翻译成可实施、可过审的文档。如果你也是第一次承担这类方案先放下“填空式模板”的思路从定级逻辑入手。下面这份拆解来自我处理过的多个同类项目经验不追求讲全理论只讲一套能落地的写法。2. 计算机信息系统分级保护的定级逻辑先定密再分域最后落控制项很多同事在刚开始接触分级保护时习惯把三言两语的安全域、身份鉴别、审计当成全部内容。实际上这些只是输出层。真正决定方案质量的是上游两个字“定级”。定级定了密级密级决定安全域划分粒度安全域又决定控制项的强度。这部分先把这条因果链讲透后续编写才不会写偏。2.1 分级保护与等级保护的标准体系不是一回事两个体系这么像为什么会混淆从名称上看都有“分级”或“等级”从内容上看都强调身份鉴别、访问控制、审计甚至很多网络设备的配置模板都能复用。但适用对象不在一个层面分级保护针对涉密信息系统等级保护针对非涉密系统。写方案时若套用等保的“第一级、第二级、第三级”表述评审专家会在第一个评审会上就提出异议。| 对比维度 | 分级保护 | 等级保护 | | 适用对象 | 涉密信息系统 | 非涉密信息系统 | | 定级维度 | 按信息密级秘密级、机密级、绝密级 | 按受破坏后危害程度第一级至第五级 | | 归口管理 | 保密行政管理部门指导 | 网络安全等级保护制度统筹指导 | | 主要依据 | 国家保密行政管理部门发布的分级保护技术与管理规范 | 网络安全等级保护系列标准与网络安全相关要求 | | 测评单位 | 具备涉密信息系统测评资质的保密测评机构 | 具备网络安全等级保护测评资质的测评机构 |这张表不是用来背的是用来校准措辞。方案里只要出现“等级保护”或“第三级”这类词都会被认定术语体系混用。我在出审前检查文档时会专门搜索“等级”“第三级”字样逐一改成“秘密级、机密级、绝密级”和对应表述。这并不是单纯的文字洁癖而是因为评审专家默认你懂体系术语不对说明逻辑基础不牢。另外注意一个单位可能同时有两类系统用于日常办公的非涉密系统和用于业务处理的涉密系统。方案标题写的是“计算机信息系统分级保护”就只覆盖涉密信息系统不要把非涉密的办公系统也卷进来。若单位确实有混合场景你可以在附录里说明两套制度分别适用但不要让分级保护方案替等保背书。2.2 定级流程与安全域划分步骤定级不是靠拍脑袋也不是领导说了算。通常有一套五步走的规程我按做过的项目归纳如下第一步确认系统的涉密属性判断系统是否产生、处理、存储、传递国家秘密若完全不含秘密它就不该出现在分级保护方案里。 第二步识别业务事项与密级把系统承载的业务逐条列出对照所在行业的保密事项范围给每条业务标注秘密级、机密级或绝密级。 第三步确定系统最高密级按“就高不就低”原则取所有业务中最高密级作为整个系统的密级。 第四步划分安全域把相同或相近密级、相同管理边界的组件放进一个安全域域与域之间设计明确边界。 第五步形成定级说明记录每步判断依据附上支撑材料。| 系统密级 | 核心目标 | 常见设计重点 | | 秘密级 | 防止秘密信息被非授权扩散 | 角色访问控制、口令管理、合规审计 | | 机密级 | 在秘密级基础上强化区域与设备防护 | 双因子鉴别、安全域边界防护、介质管控、密码保护措施 | | 绝密级 | 按国家专项规定执行最严格管控 | 单独场所与专人管理严格控制知悉范围不展开常规配置 |绝密级在实践中很少写进普通方案因为其建设模式往往由专门机构另走流程。你只要在方案中留出“按专项规定执行”的说明不要用通用技术章节去硬套。安全域划分是定级结果的落地。常见做法是按“业务密级 管理边界”两个维度划分同一个部门、同一套设备、同一密级的业务优先合域不同密级之间必须分域涉密域与支撑区、管理区之间要用边界防护设备隔离。不要把全单位网络画成一个“大内网”就算完也不要在两个安全域之间不做任何隔离就直接互联。2.3 分级保护控制项如何映射到方案章节定级和安全域确定后下一步是把等级要求翻译成控制项。分级保护方案的正文通常围绕这几个控制项展开身份鉴别、访问控制、安全审计、边界防护、介质管控、密码保护、信息保密。每个控制项在不同密级下的强度不同。比如身份鉴别秘密级可以只要求用户名口令加必要的口令策略机密级通常要求双因子鉴别访问控制则要落实三员分立把系统管理员、安全保密管理员、审计员的权限分开。控制项不要散落在文档各处最好建一张映射表把控制项、方案章节、当前状态和责任人对应起来。格式如下| 控制项 | 方案章节位置 | 方案中要写清的内容 | 责任部门 | | 身份鉴别 | 第5.1节 | 口令策略、鉴别方式、登录失败处理 | 信息化部门 | | 访问控制 | 第5.2节 | 权限矩阵、三员分立、最小授权原则 | 信息化部门 | | 安全审计 | 第5.3节 | 审计范围、日志留存、审计员职责 | 保密办 | | 边界防护 | 第5.4节 | 安全域间访问策略、违规外联控制 | 信息化部门 | | 介质管控 | 第5.5节 | 涉密介质标识、登记、借用流程 | 保密办 | | 密码保护 | 第5.6节 | 密码设备选型原则、密钥管理要求 | 信息化部门 | | 信息保密 | 第5.7节 | 输出控制、密级标识、涉密信息外发审批 | 保密办 |这张表放在方案前面位置或附录里评审专家可以快速定位。他们会做一次反向阅读随便挑一个控制项看是否在对应章节有完整回答再挑一个章节看它是否回答了某个控制项。表里有而正文没有是内容缺失正文有而表里没有是清单失控。用映射表统一索引能减少这类低级问题。到这里定级、分域、控制项这条主线已经打通。下一部分把这些内容整理成一份能被直接拿去编辑的分级保护方案doc重点放到目录结构和写作顺序上。3. 编写一份分级保护方案.doc目录结构、写作顺序与三张必出图定级逻辑立住后真正花时间的部分是把思路转成文档。很多人的方案被退回不是因为内容不够多而是因为结构混乱、评审找不到关键信息。一份好的分级保护方案.doc不是把控制项抄一遍而是让一个不了解项目的专家靠目录和图表就能在半小时内判断方案是否可行。3.1 一份可套用的方案目录模板下面这份目录结构是我在多个项目中反复调整后留下来的通用版本适合大多数涉密信息系统建设或改造场景。你可以直接以它为底再按单位实际情况增删。| 章节 | 名称 | 编写要点 | | 1 | 概述 | 编写依据、项目背景、系统职责、适用范围 | | 2 | 信息系统基本情况 | 系统组成、网络结构、设备与用户清单、现有安全措施 | | 3 | 定级与安全域划分 | 定级依据、判定过程、系统密级、安全域清单 | | 4 | 差距与风险分析 | 现状与控制项要求比对、风险排序、影响分析 | | 5 | 技术防护措施 | 按控制项逐项描述设计方案与配置要求 | | 6 | 安全管理与制度 | 组织架构、人员职责、运维管理、应急响应 | | 7 | 建设实施计划 | 阶段划分、任务清单、里程碑、责任人 | | 8 | 测评与整改 | 测评准备、测评节点、整改流程、复测安排 | | 附录A | 控制项映射表 | 控制项、章节位置、现状与责任人 | | 附录B | 定级依据摘录 | 支撑定级的文件、事项范围摘录 |目录不必完全照抄可结合单位实际增删但至少要保证“定级与安全域划分”和“技术防护措施”独立成章。原因很简单评审专家先看定级是否合理再看防护措施是否兜得住保密要求两个环节混在一起写会给专家留下“边界不清”的印象。注意章号的写法附录要单独编。还有同事习惯在目录里加入“方案目标”放在概述章里这么写也可以但要简短目标写三到五条即可不要写成作文。目标一多评审关注点就被稀释了。3.2 写作顺序先拓扑再定级最后写控制项写目录可以按顺序但实际编写不能按顺序。若没拿到系统现状就直接写“技术防护措施”很容易出现两类问题一是默认现状一片空白写出整套新建设二是默认现状已满足写成评估报告。两种都不叫方案因为缺少了“从现状到目标”的桥梁。推荐按下面六步推进第一步收集信息系统基本信息。包括系统名称、业务用途、所在物理位置、主要设备、用户规模、当前网络结构、是否已有安全设备、处理信息的最高密级。信息越全后续差距分析越实。第二步画出网络拓扑图。在图上标注每个网络节点所属的安全域和密级圈出域间边界标清边界防护设备的位置。这一步相当于给整个计划打基础。第三步写定级与安全域划分。根据第一步收集的涉密属性和安全域原则输出系统的最高密级、安全域清单及各域密级。第四步写差距与风险分析。把现状对照控制项清单逐项比对明确哪些达标、哪些缺失、哪些部分达标。这一步输出的问题清单是技术防护措施的直接输入。第五步写技术防护措施。按前文映射表的顺序逐项描述如何补差距措施要与问题一一对应不要写“建议部署下一代防火墙”这类空话要落到部署位置、管控对象和主要策略。第六步补齐管理章节和实施计划。管理章节写机构职责和运维流程实施计划按阶段排期测评与整改放到第八部分。这样的顺序能让文档内部形成闭环现状产生差距差距产生措施措施支撑密级保护。评审专家读起来会明显感觉到章节之间有逻辑联系而不是看一页翻一页都没有印象。3.3 评审专家必看的三个输出物专家时间有限通常不会逐字读完。他们拿到一份分级保护方案重点就是三件套一张网络拓扑及密级分布图一张定级结果与安全域对照表一张控制项映射表。三件套齐全且互相能对上方案就成功了一大半。定级结果与安全域对照表可以按下面字段设计| 安全域名称 | 包含范围 | 处理信息最高密级 | 边界与防护措施 | 责任部门 | | 涉密业务区 | 服务器区-涉密段 | 机密级 | 边界防火墙、认证准入 | 信息化部门 | | 涉密终端区 | 涉密室终端网段 | 机密级 | VLAN隔离、终端管控 | 信息化部门 | | 支撑管理区 | 运维管理网段 | 内部支撑数据 | 严格的双因子鉴别和审计 | 保密办 |这张表要和拓扑图完全一致图上圈出来的域表里都要有表里的每个域图上都要画得到。两张图对不上是评审里最容易被当场指出的问题。编制时最好先画图再根据图写表而不是反过来。控制项映射表则放在附录A正文的“技术防护措施”章节按它的顺序展开做到“开头有索引正文有呼应”。三件套齐全了方案的可读性和可信度都会上一个台阶。4. 分级保护方案避坑与常见问题5种改了八遍还被退回的写法下面这五个问题是我在评审和复审中反复看到的现象。每一条都按“现象—原因—解决”梳理可以作为你写完方案后的自查清单也可以作为评审前最后一项核对表。4.1 术语体系混用把“分级保护”写成“等级保护”现象方案封面写的“等级保护”正文里出现“第三级”“等保要求”等字样。评审会上专家第一句话就是“这份文档写错了对象”。原因写方案的人往往同时接触多个体系复制粘贴时没有把术语统一。标题里明明白白写着“分级保护”结果正文却用等保语言描述属于最基础的错误。解决写完后用全文搜索功能逐条排查“等保”“等级保护”“三级”等词。把涉密系统定级统一改成“秘密级、机密级、绝密级”把防护方向从“合规检查”表述为“围绕密级和知悉范围控制”。这不是吹毛求疵而是两个体系面对完全不同的监管口径。4.2 只写“定为什么”不写“为什么这么定”现象定级说明只有一句话“本系统涉及秘密级信息因此定为秘密级。”专家问谁定的、依据是什么、包含哪些业务方案里答不上来。原因定级工作需要业务部门和保密办共同参与方案编制方只拿到结论没有收集判定依据。写定级章时自然没有支撑材料。解决在定级章里补充三段式写法先用一段说明系统承载的业务和数据再引用所在行业保密事项范围中对应的条款最后写明判定过程。把不能公开或不便附上的依据以“附件B定级依据摘录”的形式归档供评审时查证。这样即使结论不变文档立场也会完全不同。4.3 安全域划分粗糙全单位就是一个“大涉密网”现象拓扑图上只画了一个方框“涉密内网”里面服务器、终端、管理设备全部混在一起没有安全域边界也没有密级标注。原因想省事或者担心把拓扑画细了反而暴露问题。现实中涉密系统往往和支撑系统有交叉不通过分域把边界说清楚后续控制项根本无法精准落地。解决按“业务密级管理边界”拆至少分出涉密业务区、涉密终端区、支撑管理区三类。在每个域之间写明隔离方式和访问方向比如涉密业务区只允许涉密终端区访问支撑管理区仅保留运维通道并受审计覆盖。4.4 只写产品不写参数措施章节满是设备名没有控制策略现象技术防护措施写了“部署防火墙”“部署加密认证网关”“启用审计系统”却没有写防火墙的访问策略、加密认证的鉴别方式、审计日志的留存要求。原因把方案当成了采购清单默认写清楚设备品牌型号就算完成。但涉密系统要的是“保护强度”评审人员关心的是设备在系统中扮演什么角色而不是名字叫什么。解决为每个控制项补上策略参数。身份鉴别至少写明鉴别方式、口令长度与更换周期、双因子组合方式审计要写明覆盖范围与日志留存时间边界防护写明按安全域间访问方向配置策略不默认放通。不要怕写具体数值越具体越好评审越容易暴露差距。4.5 没有测评与整改的闭环现象方案写到“实施计划”就结束没有测评、整改、复测安排。专家常问“系统建完谁来评不评怎么确认保护达到质量目标”原因编制方默认测评是检测机构的事不在方案范围内或者为了压缩篇幅省略了。解决第八部分专门写“测评与整改”内容包括测评前准备文档、拓扑、现场环境、测评节点选择建设完成后、试运行后、整改流程问题汇总、责任分解、回归验证、复测安排。把测评作为方案的一个阶段来写而不是把它当成文件尾部的“合订说明”。注意这五条坑看起来零散背后其实是同一个教训方案不是写给自己的是写给评审专家和后续实施者的。写的时候想着“专家会怎么质疑”下笔就会谨慎得多。5. 用一张自查表把分级保护方案落到可复查状态写完初稿不代表工作结束。我的习惯是每次提交前用一张自查表逐项核对把方案当成“别人写的文档”从头过一遍。下面这张表可以直接复制到自己的检查清单里。| 检查点 | 核对内容 | 通过标准 | | 术语检查 | 全文中“等级保护、等保”等词是否清除 | 涉密系统统称“分级保护” | | 定级一致性 | 系统最高密级、各安全域密级与定级说明是否一致 | 三处密级能对应上 | | 拓扑图 | 是否标出安全域边界、节点密级、边界防护位置 | 图形与安全域表一致 | | 控制项覆盖 | 附录A的每个控制项在正文中是否有对应章节 | 无遗漏、无空项 | | 差距闭环 | 差距分析列出的每个问题是否都被后续措施覆盖 | 问题与措施一一对应 | | 责任人 | 实施计划每项任务是否有责任人与完成时限 | 无“待定”字样 | | 测评安排 | 是否包含测评准备、测评、整改、复测四个阶段 | 四个阶段齐全 |用表复查时顺序固定为“先术语、后内容、再闭环”。原因在于术语问题最高发也最好改放在最前面扫一遍内容一致性检查最耗时放在中间慢慢过闭环检查要结合差距分析和措施两个方向来回对照放在最后。实际执行中我发现最容易被表里漏掉的是“差距闭环”一项经常出现差距分析写了七个问题技术措施只覆盖五个的情况这种遗漏靠通读难以发现靠对照表逐项匹配才能查出来。另外不要把自查表当作评审前置的唯一依据。我会在自查之后再找一位不太熟悉业务背景的同事帮忙翻一遍看他能否靠目录和三张图把方案大意讲出来。若他讲得清楚说明文档结构过关若他找不到落脚点说明需要重新调整章节组织。这套方法在最近几年帮我省了不少返工尤其在“涉密系统定级说明”与“技术控制项映射表”的对应检查上特别管用。祝你也能少走几轮评审期。本文还有配套的精品资源点击获取