简介这份资源为计算机信息系统分级保护方案的完整设计文档面向涉密信息系统建设、安全运维及合规管理人员用于解决分级保护建设中网络架构、安全域隔离与物理防护的系统性设计问题。文档共1个doc文件压缩包约2.06MB内容涵盖系统总体部署、服务器区/安全管理区/终端区三层架构、Vlan与ACL访问控制策略、邮件系统分级防护及1-7级安全级别设置等核心模块。针对物理安全详述红外对射、红外报警、视频监控、门禁系统及线路干扰仪的部署位置、首次运行策略与设备管理细则并给出电磁泄漏防护的完整建设思路。目前已有58人学习。读者可直接参考其中组网模式与分级管控策略结合单位实际情况快速完成方案框架搭建、防护设施选型与制度配套设计。1. 计算机信息系统分级保护方案先算清密级账再谈安全建设《计算机信息系统分级保护方案》这份文档不少单位是当成“等保翻版”来做的结果常在第一次评审就翻车。分级保护面向的是承载涉密业务的信息系统按涉密程度分秘密、机密、绝密三档核心不是堆设备而是证明三件事安全域边界隔得住、账号与操作管得住、整个生命周期审得出。它能解决的是测评不通过、整改反复返工、预算无底洞这几个真问题适合正在立项编方案或已进入整改期的单位对照使用。接下来的顺序就按定级、边界、技术防护、管理测评、高频踩坑一路拆开讲。2. 定级与边界划分方案里第一张表决定后续全部预算分级保护方案的第一个环节叫定级但定级文档本身不值钱值钱的是定级之后那张安全域边界表。我一般拿到项目时会先问负责人一个问题这套系统里真正涉密的业务是哪几个应用、数据落在哪些库里、哪些终端能看到这些数据。答清楚这个后面的设备选型、安全域划分、测评整改才有依据。2.1 先分清分级保护与等级保护两条线、两套标准、一类系统先泼一盆冷水分级保护不是等级保护的涉密加强版。等级保护依据网络安全等级保护标准按业务被破坏后对公民、社会、国家的影响定一至五级面向的是不涉及国家秘密的网络分级保护依据BMB17系列技术要求、BMB20系列管理规范面向的是涉及国家秘密的信息系统按系统承载信息的密级分秘密、机密、绝密三档。这两种体系监管主体不同、测评机构不同、整改要求也不同。常见误用是把等保三级的防护清单直接平移过来测评专家一问“你的秘密级数据在哪个网段”就答不上来。原因是两个体系的对象不一样等保定的是“网络安全等级”分保定的是“信息密级”。所以方案开篇就要写清楚本系统按分级保护体系设计属于哪个密级依据是什么。如果一个系统同时承载涉密业务和非涉密业务仍然按分级保护体系整体设计并在边界上做域间控制这一点没有讨价还价的空间。2.2 定级对象怎么划把信息域、终端域和管理域拆成三张清单定级对象不能是整个机房或整张办公网而是一个个具体的业务系统。常见做法是把系统拆成三个域来做定级与防护设计信息域承载业务数据和业务服务终端域承载用户办公桌面管理域承载运维终端、审计服务器和安全管理设备。每个域出三张清单资产清单、网络关系清单、密级清单。资产清单要细化到IP、主机名、操作系统、数据库实例、责任部门网络关系清单要标出域间访问流向和端口密级清单则给每个资产打上内部或秘密或机密标签。这里不要省事测评现场专家会随机抽一台设备让管理员说出它属于哪个域、什么密级、有哪些访问入口。答不出来即视为管理缺失。为什么要把管理域单独拆出来而不是并进信息域因为分级保护的审计要求里审计员和被审计对象不能待在同一安全域。如果运维终端和生产服务器在同一个域里管理员操作时既可以改配置又能删日志审计就形同虚设。管理域独立是后续三员分离能否落地的基础这一步不要妥协。域间的默认策略只有一句话先拒绝后放行。管理域访问信息域只开放运维必需端口其余全部丢弃下面是初始基线规则# 管理域到信息域的边界基线地址按实际规划替换 # 允许运维SSH入口仅限管理域网段 iptables -A FORWARD -s 192.0.2.0/24 -d 198.51.100.0/24 -p tcp --dport 22 -j ACCEPT # 允许安全设备的控制端口注意端口按设备型号实际值调整 iptables -A FORWARD -s 192.0.2.0/24 -d 198.51.100.0/24 -p tcp --dport 8443 -j ACCEPT # 其余流向一律丢弃日志记录便于追溯违规尝试 iptables -A FORWARD -s 192.0.2.0/24 -d 198.51.100.0/24 -j LOG --log-prefix mgmt2info-DROP: iptables -A FORWARD -s 192.0.2.0/24 -d 198.51.100.0/24 -j DROP逻辑说明分两层前三行是白名单思路允许的只有两个端口后两行是兜底拦截所有没被白名单匹配的流量进入日志并丢弃。参数说明-s是源地址-d是目标地址--dport 22对应SSH运维8443是常见安全管理设备控制台端口按实际设备调整LOG规则里的--log-prefix只负责打标签不阻断紧接着的DROP规则才真正丢包。规矩是先LOG再DROP否则日志看不到被丢弃的包。在涉密环境里改动防火墙必须走变更审批流程不要直接在生产上敲。2.3 密级与防护强度对照秘密、机密、绝密各自该做到什么程度密级不是越高越好越高约束越重、建设越贵、使用越难受。分级保护体系里秘密、机密、绝密三档对应的防护强度从三个维度拉开梯度边界控制、身份鉴别、审计留存。下表是我按常见项目需求整理的基线对照实际以测评机构评审结果为准。防护维度秘密级机密级绝密级边界隔离与公共网络物理隔离内部安全域间逻辑强隔离独立物理环境禁止与其他网络共用设备身份鉴别口令USBKey双因素双因素覆盖运维与应用双因素专用认证设备审计留存至少6个月至少12个月按专项要求长期留存介质管控专用介质登记编号专用介质加密管理介质专人专柜管理选型逻辑是定级表一旦确认预算基本就定了。一个秘密级的业务系统可以共用后台存储机密级以上则要求更独立的存储与更细粒度的审计这些都会直接反映在采购清单里。所以定级这一步千万不要含糊宁可在定级评审会上多花一周把边界说清楚也不要后边被测评推翻重来。定级评审会怎么开才不白开让业务部门带着数据流图来逐条说清哪个业务模块产生哪类数据、数据流向哪里、哪些终端能接触技术侧只负责把业务语言翻译成安全域语言。业务部门说不清的数据流就是将来被测评专家抓住的漏洞。3. 技术防护落地三员分离、双因素鉴别与审计留痕怎么配定级和边界只是方案的地基真正让评审专家信服的是技术防护措施有没有配置到位。这一章按分级保护方案里出现频率最高的三个技术点展开三员分离、身份鉴别、安全审计。每个点都先说设计思路再给出可复制的落地配置。3.1 三员分离系统管理员、安全保密管理员、安全审计员的分权落地三员分离可以算是分级保护最鲜明的特征。系统管理员只管系统与网络的日常运维安全保密管理员负责账号权限分配、密级标识和安全策略安全审计员独立出来只做一件事看前两个人的操作日志。三个角色两两制衡审计员不能改系统配置系统管理员不能删审计日志。实操中最容易出问题的不是制度而是特权账号。很多单位在应用系统初始化时建了一个超级管理员三个角色全挂在同一个账号下制度里写着三员分离数据库一查就露馅。涉密环境里最常见的翻车现场就是测评专家当场要求管理员查询角色绑定表。下面的SQL适合在自查阶段跑一遍确认是否存在一人多角色-- 自查是否存在同一账号被赋予多个管理角色 SELECT a.user_name AS 账号, COUNT(DISTINCT a.role_name) AS 角色数, GROUP_CONCAT(DISTINCT a.role_name) AS 角色列表 FROM account_role a WHERE a.role_name IN (系统管理员, 安全保密管理员, 安全审计员) GROUP BY a.user_name HAVING COUNT(DISTINCT a.role_name) 2;这里HAVING过滤出角色数大于等于2的账号GROUP_CONCAT把多个角色列到同一行便于排查。参数说明表名account_role和角色名称要根据实际业务系统的权限模型调整如果权限模型是独立的角色表和用户表就改成对应的两张表做关联查询。建议每季度跑一次并把结果归档作为三员分离的持续符合性证据。3.2 身份鉴别与访问控制从口令策略到双因素认证的参数细节身份鉴别这道关分级保护强调两件事口令策略必须硬关键操作必须双因素。口令硬到什么程度秘密级基线建议长度不低于12位且数字、大小写字母、特殊字符四类都要出现。这个不能靠运维人员的自觉要靠系统配置强制。Linux环境下先调pwquality# /etc/security/pwquality.conf 口令复杂度基线 minlen 12 dcredit -1 ucredit -1 lcredit -1 ocredit -1 retry 3参数说明minlen是最小长度dcredit、ucredit、lcredit、ocredit分别要求至少一个数字、大写字母、小写字母、特殊字符负一表示至少有一个零表示不强制retry是连续输入错误次数超过后触发锁定。然后是登录失败的锁定策略# /etc/pam.d/system-auth 追加两条顺序不能反 auth required pam_faillock.so preauth silent audit deny5 unlock_time900 auth sufficient pam_unix.so nullok try_first_pass auth required pam_faillock.so authfail audit deny5 unlock_time900逻辑说明preauth行在用户输入口令前就检查是否已被锁定authfail行在认证失败后记录次数deny5表示连续错5次锁住账号unlock_time900表示锁定15分钟。常见坑是只加了一条锁定的行而没有在合适位置插入preauth导致锁定不生效。双因素认证的落地一般用USBKey、智能卡或动态令牌登录时必须同时验证口令和硬件令牌。这里不展开具体厂商配置只提醒一句密钥不能明文存本地令牌服务所在的服务器要单独划入管理域并纳入审计范围。3.3 安全审计auditd 规则、日志轮转与留存周期的统一配置安全审计是分级保护方案里被检查最严格的技术点。审计不是把日志打开让它自己写而是要有明确的监控对象、留存周期和复核机制。Linux环境里auditd是标配先定规则# /etc/audit/rules.d/security.rules -w /etc/passwd -p wa -k identity -w /etc/shadow -p wa -k identity -w /var/log/auth.log -p wa -k logins -w /etc/sudoers -p wa -k priv_esc -a always,exit -S execve -k cmd_exec参数说明-w监控文件路径-p wa表示写入和属性变更事件-k是事件标签后面查日志时按标签过滤-a always,exit -S execve监控所有命令执行代价是日志量增长很快生产环境建议配合节流。再配日志轮转# /etc/logrotate.d/audit /var/log/audit/audit.log { weekly rotate 24 compress missingok notifempty }weekly按周轮转rotate 24保留24份配合压缩后基本能满足6个月留存如果单位制度要求12个月就改成rotate 52。注意审计日志要落到独立存储或独立日志服务器不能和业务数据混在同一个磁盘否则磁盘写满时最先被清掉的可能就是审计日志。还有些单位把审计日志和业务日志共用一个文件系统结果业务日志刷屏把磁盘占满审计服务自动停止测评时一查一个准。留存的本质是回答“当时发生了什么”而不是“我们存了多长时间的日志”所以存储容量规划要和日志生成速率挂钩数据量大时把execve监控改成只监控关键目录或特定用户减少无效事件堆积。测评专家现场会做的一件事是拉取最近一周的审计事件按identity和priv_esc标签抽样问管理员这几个事件当时对应的操作是什么。所以规则只是起点事后能解释清楚才是关键。4. 管理闭环与测评整改方案模块怎么一次写不缺项技术配置做完接下来是方案文档本身。很多项目不是设备不过关而是文档缺项测评意见里全是“制度未明确”“记录缺失”。这一章讲清楚制度与测评整改怎么闭环。4.1 分级保护方案必备模块清单评审专家最先翻的六个模块方案doc不是把厂商的售前材料拼在一起就行。测评专家看得很快先翻六个模块定级报告、风险评估、安全设计、管理制度、应急预案、整改计划。下面这张表是按常见评审口径整理的模块内容与高频缺项模块核心内容高频缺项定级报告定级依据、涉密范围、边界说明没有边界拓扑图风险评估威胁源、脆弱性、风险分析风险没有量化全是定性描述安全设计分域隔离、身份鉴别、审计设备选型与实际部署不一致管理制度人员、机房、介质、运维制度与执行两张皮应急预案组织、流程、备份恢复没有演练记录整改计划问题列表、时限、责任没有闭环跟踪这里点名一个高频缺项边界拓扑图。文字写一百句都不如一张拓扑图管用图上要标清管理域、信息域、终端域的网段和边界设备测评专家会拿图和现场连线做比对。这张图建议定级完就画后续每个阶段维护别等测评前补。设备选型与实际部署不一致也很常见方案里写的是A型号防火墙现场装的是B型号测评专家一问型号对不上整个技术设计部分的可信度都会被打折扣。所以方案里的设备清单要在实施完成后做一次复核与实际资产台账对齐。4.2 介质与运维流程落地台账、备份脚本与密级标识介质管理在分级保护里地位很高涉密数据一旦通过U盘、移动硬盘流出去就是重大事故。方案里介质管理至少要包含三类内容介质台账、密级标识、借还登记。台账记录介质编号、责任人、存放位置密级标识落实到介质标签和文件命名借还登记记录时间、事由、经手人。用脚本做备份的时候也要把密级标识带进文件名并生成完整性校验值#!/bin/bash # 涉密数据备份脚本适用于秘密级数据归档 SRC_PATH/data/archive BK_DIR/mnt/secret_disk PROJECTcomprehensive DATE$(date %Y%m%d) tar czf ${BK_DIR}/${PROJECT}_${DATE}_秘密.tar.gz -C / $SRC_PATH sha256sum ${BK_DIR}/${PROJECT}_${DATE}_秘密.tar.gz ${BK_DIR}/${PROJECT}_${DATE}_秘密.sha256逻辑说明tar打包时把“秘密”密级标识直接写进文件名配合压缩节省介质空间sha256sum生成校验文件介质归还和抽查时可以用sha256sum -c核对。参数说明SRC_PATH是归档源目录BK_DIR是专用介质挂载点PROJECT是系统代号日期变量DATE保证每次备份文件名唯一。在涉密环境里备份介质不能私借私用建议脚本里再加一行mount检查介质未挂载直接退出。另外涉密介质需要定期做内容核查至少每半年一次核对备份清单与实际文件是否一致防止介质损坏导致数据归档缺失。4.3 测评整改三步走自查、现场测评、复测的常见节奏测评节奏一般分三步。第一步自查对照定级报告逐项过技术配置把三员账号、口令策略、审计规则、边界策略都导出记录形成自查表。这里常见问题是自查走形式我建议把自查当成正式测评来对待拿着自查表随机抽查三台设备在审核人不在场的情况下登录验证。第二步现场测评测评机构会做访谈和技术检测访谈主要面向系统管理员、安全保密管理员、安全审计员技术检测则直接落设备上验证配置。第三步复测针对现场测评发现的不符合项整改后再测整改要有明确的完成时间和责任人形成闭环记录不要改完就散伙下次复测还是要看的。自查阶段建议按这个清单逐项打钩定级范围是否覆盖全部涉密业务、边界设备配置是否与拓扑一致、三员角色是否存在复用、口令策略是否强制生效、审计规则是否覆盖关键文件、日志留存是否达到制度要求、介质台账是否与实际库存一致、应急预案是否有演练记录、整改计划是否有完成时间、每项整改是否有人签字确认。这十项里有任何一项答不上来都意味着正式测评时大概率会被记一条不符合项。5. 分级保护方案落地避坑五个反复返工的高频问题这一章是给已经进场的项目看的五个问题分别对应定级、边界、审计、角色、标识来回折腾人。5.1 定级拍脑袋定高预算和测评范围一起失控现象项目刚启动就把所有业务系统定成机密级涉密终端覆盖全员存储全部要求加密预算翻倍工期从半年拉到一年半。原因把“系统里存在少量敏感数据”和“系统整体属于机密级”混为一谈定级没有跟着业务的密级属性走。解决定级按业务应用维度来一个应用真正处理什么密级的信息就定什么档同网络里只有一台涉密服务器的按涉密终端做物理隔离没必要让整个办公网进入密级范围。定级评审会上多花一周搞清楚边界比后边整改一年划算。5.2 边界只做逻辑隔离却在访谈里说成物理隔离现象方案里写着“物理隔离”现场是VLAN加防火墙的逻辑隔离专家追问交换机端口配置时答不上来。原因把“涉密网与非涉密网之间要物理隔离”和“涉密系统内部安全域之间可以用逻辑隔离”两组要求搞混。解决涉密网与公共网的边界必须是物理断开或经过保密部门认可的强隔离设备而管理域、信息域、终端域之间属于系统内部边界用逻辑隔离反而更合理也便于运维。写方案时分清这两层不要一个词用到底。5.3 日志只存不审测评抓出“审计空转”现象audit.log存了大半年测评专家抽了三条约在凌晨的账号变更事件管理员无法说明当时是什么操作、谁审批的。原因只配置了日志存储没有建立审计复核机制。解决审计员按周对高风险事件标签identity、priv_esc、cmd_exec做抽样核对月度形成审计报告由保密办确认签字。技术侧把auditd的规则打上清晰的事件标签日志筛选和复核才有抓手。记住一个标准审计链路要能解释每一步而不是能倒出每一天的日志。5.4 三员分离被账号复用架空现象制度里写了三员数据库角色表一查同一个超管账号同时绑定了系统管理员和安全审计员角色。原因设备初始化时留下的维护账号没有清理后续运维为图省事继续使用。解决初始化阶段清理厂商默认账号生产环境账号由安全保密管理员统一建立系统管理员不知道审计员密码每季度跑一遍前面那类角色绑定自查SQL把结果存档。一旦查出复用账号当场禁用并走变更流程重建。这里没有后悔药测评专家对账号复用几乎是零容忍。5.5 密级标识只在红头文件里业务数据全裸奔现象方案里大篇幅写了密级标识要求数据库里的表和导出的文件却没有一个带密级标识。原因密级标识只停留在制度文本没有做技术强制。解决把密级标识做成技术动作——数据库关键表增加密级字段默认值按低密级设置导出接口自动在文件名和内容页眉写入密级打印输出加水印底纹。这里不用买很贵的系统文件服务加一层写入逻辑就能实现关键是让标识跟着数据走而不是跟着制度文档走。数据导出这个环节尤其要盯紧很多单位的泄露风险就从导出文件开始。6. 用一个自查脚本把分级保护基础项合规度量化出来正式测评前最值得做的事是把基础项自动化。下面这个脚本把审计服务、口令锁定、三员账号、日志写入四个硬指标一口气查完输出PASS/FAIL清单。它不能替代测评但能提前暴露80%的硬伤。#!/bin/bash # 分级保护基础项快速自查脚本 # 以root执行bash grading_audit.sh echo [1] 审计服务状态 systemctl is-active auditd /dev/null 21 echo PASS auditd运行中 || echo FAIL auditd未运行 echo [2] 口令失败锁定 grep -q pam_faillock /etc/pam.d/system-auth echo PASS 已启用失败锁定 || echo FAIL 未启用失败锁定 echo [3] 三员账号复用 mysql -N -e SELECT user FROM account_role WHERE role IN (系统管理员,安全保密管理员,安全审计员) GROUP BY user HAVING COUNT(DISTINCT role)1; 2/dev/null | grep -q . echo FAIL 存在多角色账号 || echo PASS 未发现多角色账号 echo [4] 审计日志持续写入 find /var/log/audit -name audit.log* -mmin -1440 | grep -q . echo PASS 日志持续写入 || echo FAIL 日志停止写入逻辑说明第一项直接看审计服务运行状态第二项查PAM配置里是否启用了失败锁定第三项查数据库角色绑定表是否存在一人多角色第四项看最近一天内审计日志文件是否有更新判断审计是否还在写入。参数说明mmin -1440表示1440分钟即24小时内的修改时间mysql表名account_role和角色名按实际系统调整auditd未安装或使用其他审计组件时第四项改成对应的日志目录。这套脚本我习惯挂在每周的定时任务里输出定向转到内网值班邮箱。它的价值不在技术难度在于把“测评前突击自查”变成“每周都有合规感”。做分级保护这些年最深的一个教训是翻车的从来不是方案写得不够漂亮而是基础项平时没人管。希望帮到你。本文还有配套的精品资源点击获取