简介这份《计算机信息系统分级保护方案》文档面向涉密信息系统建设与合规管理人员、安全集成工程师及等保测评从业者围绕分级保护要求给出可落地的整体设计思路。内容涵盖系统总体部署、物理安全防护、电磁泄漏防护等模块具体包括核心交换机VLAN划分与ACL访问控制策略、服务器安全访问控制中间件与防火墙的桥接部署、入侵检测与网络安全审计的镜像接入以及邮件系统按1至7级安全级别控制信息流向的机制物理层面则细化到红外对射、红外报警、视频监控、门禁系统、线路干扰仪、视频干扰仪与红黑电源隔离插座等设备的部署位置、运行策略与运维管理要求。资源包共1个doc文件约2.06MB结构完整、表格与图示齐全适合作为方案模板或技术参考直接借鉴。目前已有58人学习可帮助读者快速理解分级保护的设计逻辑与防护要点。1. 计算机信息系统分级保护方案从定级到落地的完整拆解很多团队第一次接触等保测评时最容易翻车的地方不是技术不会做而是定级定错了。我见过一个内部管理系统业务方觉得“就几十个人用定个一级得了”结果测评机构一看数据涉及员工薪酬和身份信息直接要求按三级整改前面三个月做的安全加固几乎全部推倒重来。计算机信息系统分级保护方案的核心就是先回答“这套系统该按什么级别保护”再回答“这个级别具体要做什么”。它解决的不是单点安全问题而是一套从定级、备案、建设整改到测评的闭环流程。适合谁看正在做等保合规的运维负责人、安全工程师、项目经理以及需要给系统写定级报告但不知道从哪下笔的开发者。这篇笔记按实际落地顺序拆不按标准目录抄。2. 定级之前先把边界划清楚系统拆分与等级判定定级是整个分级保护方案的地基。地基歪了后面所有整改动作都是白费。很多团队一上来就翻《定级指南》对照表但真正该先做的是把“一个系统”拆成“几个定级对象”。2.1 什么算一个定级对象什么必须拆开常见做法是一个独立部署、独立运行、承载特定业务的信息系统算一个定级对象。但下面三种情况必须拆同一套硬件上跑了两个业务一个对外一个对内安全需求差异大拆。一个系统跨了两个不同安全域比如生产区和办公区拆。一个系统里既有普通业务数据又有大量敏感个人信息且能独立管理拆。拆完之后每个对象单独定级。我一般会画一张表把系统名称、承载业务、数据敏感度、服务对象范围、一旦被破坏的影响面列出来再对照定级要素打分。定级要素说明常见取值受侵害的客体公民/法人/其他组织、社会秩序、公共利益、国家安全按实际影响选对客体的侵害程度一般损害、严重损害、特别严重损害结合业务中断时长、数据泄露量业务信息安全数据保密性、完整性被破坏的影响独立打分系统服务安全系统可用性被破坏的影响独立打分两个维度分别定级取较高者。比如业务信息安全定二级系统服务安全定三级最终按三级走。2.2 定级报告里必须写死的四个参数定级报告不是散文评审专家会盯着几个关键参数看。下面这四个必须明确系统服务范围是面向本单位、面向社会、还是面向全国。范围越大级别越高。用户规模注册用户数、日活、并发。别写“若干”写具体数字或量级。数据规模与敏感度数据总量、是否含个人信息、是否含敏感个人信息。这里最容易低估。业务中断容忍时间能停1小时、1天、还是完全不能停。直接决定可用性等级。注意定级不是越高越好。定高了整改成本翻倍定低了测评不通过还得重新定级。拿不准的时候找有资质的测评机构做一次预评估比事后返工便宜得多。2.3 备案材料清单与提交节奏定级完成后需要准备备案材料。常见清单如下系统定级报告含专家评审意见系统备案表系统拓扑图与说明安全管理制度清单测评报告首次备案可后补但整改期限要写清楚提交节奏上我一般建议定级报告内部评审通过后先提交备案同时启动整改。不要等备案完全通过再动手否则时间线拉太长。备案受理后通常会给一个整改期限三级系统一般要求一年内完成测评。3. 三级系统整改实操从技术到管理的落地清单定级定到三级整改就是硬骨头了。三级要求覆盖物理、网络、主机、应用、数据、管理六个层面。下面按实际动手顺序拆每个层面给可抄的配置或检查项。3.1 网络层访问控制与入侵防范的最小配置网络层最容易被测评扣分的是“访问控制粒度不够”和“没有入侵防范”。以常见防火墙为例下面是一段策略配置示例# 定义地址组内部服务器区 object-group network SRV_ZONE network-object 10.10.20.0 255.255.255.0 # 定义地址组运维管理区 object-group network OPS_ZONE network-object 10.10.30.0 255.255.255.0 # 只允许运维区访问服务器区的特定端口 access-list ACL_SRV_IN extended permit tcp object-group OPS_ZONE object-group SRV_ZONE eq 22 access-list ACL_SRV_IN extended permit tcp object-group OPS_ZONE object-group SRV_ZONE eq 443 access-list ACL_SRV_IN extended deny ip any any log # 应用策略到接口 interface GigabitEthernet0/1 access-group ACL_SRV_IN in逻辑说明先定义源和目的地址组再写允许规则最后显式拒绝并记录日志。参数说明eq 22和eq 443按实际开放端口改不要图省事写permit ip any any。测评时看到 any any 基本直接判不符合。入侵防范方面三级要求“应在关键网络节点处检测、防止或限制从外部发起的网络攻击行为”。常见做法是在互联网边界部署 IPS 或 WAF并开启告警。如果预算有限至少要在防火墙上开启入侵检测特征库并定期更新。3.2 主机层身份鉴别与安全审计的必调项主机层三级要求里身份鉴别和安全审计是必查项。以 Linux 为例下面几个配置必须做# 1. 密码复杂度修改 /etc/security/pwquality.conf minlen 8 minclass 3 maxrepeat 3 # 2. 登录失败处理修改 /etc/pam.d/sshd auth required pam_tally2.so deny5 unlock_time300 # 3. 开启审计确认 auditd 运行 systemctl enable auditd systemctl start auditd # 4. 审计规则示例监控关键文件变更 auditctl -w /etc/passwd -p wa -k passwd_change auditctl -w /etc/shadow -p wa -k shadow_change逻辑说明密码复杂度防止弱口令登录失败处理防止暴力破解auditd 记录关键操作。参数说明deny5表示连续失败5次锁定unlock_time300表示300秒后解锁按实际安全策略调整。-p wa表示监控写入和属性变更。注意很多团队开了 auditd 但没配规则等于没开。测评时会检查审计记录是否覆盖重要用户行为和重要安全事件。3.3 应用层身份鉴别、访问控制与数据完整性应用层是三级整改里最花时间的。常见检查项包括登录失败处理连续失败N次锁定账户或IP。会话超时无操作15分钟自动退出。访问控制不同角色只能访问授权资源不能靠前端隐藏。数据完整性重要数据传输和存储要有校验机制。数据保密性敏感字段加密存储传输用TLS。下面是一个会话超时和登录失败锁定的伪代码示例# 登录失败计数与锁定 MAX_FAIL 5 LOCK_TIME 300 # 秒 def login(username, password): if is_locked(username): return 账户已锁定请稍后再试 if verify(username, password): reset_fail_count(username) create_session(username, timeout900) # 15分钟超时 return 登录成功 else: incr_fail_count(username) if get_fail_count(username) MAX_FAIL: lock_account(username, LOCK_TIME) return 用户名或密码错误逻辑说明先检查锁定状态再验证密码失败累加达到阈值锁定。参数说明MAX_FAIL和LOCK_TIME按安全策略调整timeout900对应15分钟无操作超时。注意不要把“用户名不存在”和“密码错误”分开提示防止用户名枚举。3.4 管理层面制度、人员、建设、运维四件套技术整改做完管理层面缺材料照样扣分。三级要求的管理制度至少包括安全管理制度总则、人员管理、系统建设、系统运维。人员安全录用审查、离职流程、安全培训记录。建设管理定级备案、安全方案设计、产品采购、测试验收。运维管理环境管理、资产管理、介质管理、设备维护、漏洞管理、备份恢复、应急预案。我一般会建一个文件夹按这四类分好每份制度配上发布记录和培训签到表。测评时直接按目录抽省得现场翻。4. 测评前自查五个最容易翻车的检查点整改做完不等于能过。正式测评前我通常会带团队做一轮自查下面五个点翻车率最高。4.1 漏洞扫描报告里的高危没闭环现象测评机构扫出一堆高危漏洞整改报告里只写了“已修复”但没有复测截图或闭环记录。 原因很多团队修完不验证或者验证了不留痕。 解决每个高危漏洞都要有“发现-修复-复测”三段记录复测用同款工具或更严格工具截图带时间戳。4.2 日志留存时间不够现象安全审计要求日志留存不少于6个月实际只留了1个月。 原因磁盘空间不够或者没配日志轮转。 解决先算日志量再扩磁盘或配远程日志服务器。用 logrotate 配保留策略# /etc/logrotate.d/syslog /var/log/messages { rotate 26 weekly missingok notifempty compress }rotate 26表示保留26周约6个月。按实际日志量调整。4.3 备份数据没做恢复演练现象有备份策略但从来没恢复过。测评时要求提供恢复演练记录拿不出来。 原因只备份不演练等于没备份。 解决每季度做一次恢复演练记录恢复时间、数据完整性校验结果。三级系统要求备份数据完整性和可用性都要验证。4.4 安全管理制度没有发布记录现象制度文档写得很全但没有发布日期、发布文号、培训记录。 原因制度是补的不是实际执行的。 解决补发布记录和培训签到制度内容要和实际运维动作对得上。测评专家会交叉验证。4.5 定级报告和实际系统对不上现象定级报告写的是二级实际系统承载了大量敏感数据测评时被要求重新定级。 原因定级时低估了数据敏感度。 解决定级前把数据分类分级做一遍敏感数据单独标识。拿不准就按高标准定。5. 把分级保护做成持续动作三个可复用的工程习惯分级保护不是一次测评就结束的事。三级系统每年要测评二级系统也要定期自查。与其每次临时抱佛脚不如把几个动作变成日常习惯。5.1 用配置基线代替临时加固我一般会维护一份配置基线文档按操作系统、数据库、中间件、网络设备分类每项写清楚“检查命令、期望值、整改命令”。新系统上线前先过一遍基线比事后整改省事得多。下面是一个基线检查表的片段检查项检查命令期望值整改命令密码最长有效期chage -l root≤90天chage -M 90 rootSSH 空口令登录grep PermitEmptyPasswords /etc/ssh/sshd_configno改为 no 并重启 sshd审计服务状态systemctl is-active auditdactivesystemctl enable --now auditd这张表可以直接交给运维执行也可以写成 Ansible playbook 批量跑。5.2 把测评项拆进日常巡检测评项不是测评前才看的。我会把三级要求里的检查项拆成日常巡检清单比如每周检查一次日志留存、每月检查一次备份恢复、每季度检查一次账户权限。巡检记录本身就是测评时的证据材料。5.3 变更时同步更新定级和备案系统做重大变更时比如新增对外服务、数据量翻倍、架构调整要重新评估定级是否需要调整。我见过一个系统从内部使用改成对外服务定级没变测评时被直接判不符合。变更流程里加一个“安全影响评估”节点能避免很多返工。最后说一个血泪教训我早期做等保的时候总想着先把技术整改做完再补管理文档结果技术做完了管理文档对不上实际配置又回头改技术。后来我改成“制度先行、技术跟进、同步留痕”测评前一周基本不用熬夜。希望帮到你。本文还有配套的精品资源点击获取
简介这份《计算机信息系统分级保护方案》文档面向涉密信息系统建设与合规管理人员、安全集成工程师及等保测评从业者围绕分级保护要求给出可落地的整体设计思路。内容涵盖系统总体部署、物理安全防护、电磁泄漏防护等模块具体包括核心交换机VLAN划分与ACL访问控制策略、服务器安全访问控制中间件与防火墙的桥接部署、入侵检测与网络安全审计的镜像接入以及邮件系统按1至7级安全级别控制信息流向的机制物理层面则细化到红外对射、红外报警、视频监控、门禁系统、线路干扰仪、视频干扰仪与红黑电源隔离插座等设备的部署位置、运行策略与运维管理要求。资源包共1个doc文件约2.06MB结构完整、表格与图示齐全适合作为方案模板或技术参考直接借鉴。目前已有58人学习可帮助读者快速理解分级保护的设计逻辑与防护要点。1. 计算机信息系统分级保护方案从定级到落地的完整拆解很多团队第一次接触等保测评时最容易翻车的地方不是技术不会做而是定级定错了。我见过一个内部管理系统业务方觉得“就几十个人用定个一级得了”结果测评机构一看数据涉及员工薪酬和身份信息直接要求按三级整改前面三个月做的安全加固几乎全部推倒重来。计算机信息系统分级保护方案的核心就是先回答“这套系统该按什么级别保护”再回答“这个级别具体要做什么”。它解决的不是单点安全问题而是一套从定级、备案、建设整改到测评的闭环流程。适合谁看正在做等保合规的运维负责人、安全工程师、项目经理以及需要给系统写定级报告但不知道从哪下笔的开发者。这篇笔记按实际落地顺序拆不按标准目录抄。2. 定级之前先把边界划清楚系统拆分与等级判定定级是整个分级保护方案的地基。地基歪了后面所有整改动作都是白费。很多团队一上来就翻《定级指南》对照表但真正该先做的是把“一个系统”拆成“几个定级对象”。2.1 什么算一个定级对象什么必须拆开常见做法是一个独立部署、独立运行、承载特定业务的信息系统算一个定级对象。但下面三种情况必须拆同一套硬件上跑了两个业务一个对外一个对内安全需求差异大拆。一个系统跨了两个不同安全域比如生产区和办公区拆。一个系统里既有普通业务数据又有大量敏感个人信息且能独立管理拆。拆完之后每个对象单独定级。我一般会画一张表把系统名称、承载业务、数据敏感度、服务对象范围、一旦被破坏的影响面列出来再对照定级要素打分。定级要素说明常见取值受侵害的客体公民/法人/其他组织、社会秩序、公共利益、国家安全按实际影响选对客体的侵害程度一般损害、严重损害、特别严重损害结合业务中断时长、数据泄露量业务信息安全数据保密性、完整性被破坏的影响独立打分系统服务安全系统可用性被破坏的影响独立打分两个维度分别定级取较高者。比如业务信息安全定二级系统服务安全定三级最终按三级走。2.2 定级报告里必须写死的四个参数定级报告不是散文评审专家会盯着几个关键参数看。下面这四个必须明确系统服务范围是面向本单位、面向社会、还是面向全国。范围越大级别越高。用户规模注册用户数、日活、并发。别写“若干”写具体数字或量级。数据规模与敏感度数据总量、是否含个人信息、是否含敏感个人信息。这里最容易低估。业务中断容忍时间能停1小时、1天、还是完全不能停。直接决定可用性等级。注意定级不是越高越好。定高了整改成本翻倍定低了测评不通过还得重新定级。拿不准的时候找有资质的测评机构做一次预评估比事后返工便宜得多。2.3 备案材料清单与提交节奏定级完成后需要准备备案材料。常见清单如下系统定级报告含专家评审意见系统备案表系统拓扑图与说明安全管理制度清单测评报告首次备案可后补但整改期限要写清楚提交节奏上我一般建议定级报告内部评审通过后先提交备案同时启动整改。不要等备案完全通过再动手否则时间线拉太长。备案受理后通常会给一个整改期限三级系统一般要求一年内完成测评。3. 三级系统整改实操从技术到管理的落地清单定级定到三级整改就是硬骨头了。三级要求覆盖物理、网络、主机、应用、数据、管理六个层面。下面按实际动手顺序拆每个层面给可抄的配置或检查项。3.1 网络层访问控制与入侵防范的最小配置网络层最容易被测评扣分的是“访问控制粒度不够”和“没有入侵防范”。以常见防火墙为例下面是一段策略配置示例# 定义地址组内部服务器区 object-group network SRV_ZONE network-object 10.10.20.0 255.255.255.0 # 定义地址组运维管理区 object-group network OPS_ZONE network-object 10.10.30.0 255.255.255.0 # 只允许运维区访问服务器区的特定端口 access-list ACL_SRV_IN extended permit tcp object-group OPS_ZONE object-group SRV_ZONE eq 22 access-list ACL_SRV_IN extended permit tcp object-group OPS_ZONE object-group SRV_ZONE eq 443 access-list ACL_SRV_IN extended deny ip any any log # 应用策略到接口 interface GigabitEthernet0/1 access-group ACL_SRV_IN in逻辑说明先定义源和目的地址组再写允许规则最后显式拒绝并记录日志。参数说明eq 22和eq 443按实际开放端口改不要图省事写permit ip any any。测评时看到 any any 基本直接判不符合。入侵防范方面三级要求“应在关键网络节点处检测、防止或限制从外部发起的网络攻击行为”。常见做法是在互联网边界部署 IPS 或 WAF并开启告警。如果预算有限至少要在防火墙上开启入侵检测特征库并定期更新。3.2 主机层身份鉴别与安全审计的必调项主机层三级要求里身份鉴别和安全审计是必查项。以 Linux 为例下面几个配置必须做# 1. 密码复杂度修改 /etc/security/pwquality.conf minlen 8 minclass 3 maxrepeat 3 # 2. 登录失败处理修改 /etc/pam.d/sshd auth required pam_tally2.so deny5 unlock_time300 # 3. 开启审计确认 auditd 运行 systemctl enable auditd systemctl start auditd # 4. 审计规则示例监控关键文件变更 auditctl -w /etc/passwd -p wa -k passwd_change auditctl -w /etc/shadow -p wa -k shadow_change逻辑说明密码复杂度防止弱口令登录失败处理防止暴力破解auditd 记录关键操作。参数说明deny5表示连续失败5次锁定unlock_time300表示300秒后解锁按实际安全策略调整。-p wa表示监控写入和属性变更。注意很多团队开了 auditd 但没配规则等于没开。测评时会检查审计记录是否覆盖重要用户行为和重要安全事件。3.3 应用层身份鉴别、访问控制与数据完整性应用层是三级整改里最花时间的。常见检查项包括登录失败处理连续失败N次锁定账户或IP。会话超时无操作15分钟自动退出。访问控制不同角色只能访问授权资源不能靠前端隐藏。数据完整性重要数据传输和存储要有校验机制。数据保密性敏感字段加密存储传输用TLS。下面是一个会话超时和登录失败锁定的伪代码示例# 登录失败计数与锁定 MAX_FAIL 5 LOCK_TIME 300 # 秒 def login(username, password): if is_locked(username): return 账户已锁定请稍后再试 if verify(username, password): reset_fail_count(username) create_session(username, timeout900) # 15分钟超时 return 登录成功 else: incr_fail_count(username) if get_fail_count(username) MAX_FAIL: lock_account(username, LOCK_TIME) return 用户名或密码错误逻辑说明先检查锁定状态再验证密码失败累加达到阈值锁定。参数说明MAX_FAIL和LOCK_TIME按安全策略调整timeout900对应15分钟无操作超时。注意不要把“用户名不存在”和“密码错误”分开提示防止用户名枚举。3.4 管理层面制度、人员、建设、运维四件套技术整改做完管理层面缺材料照样扣分。三级要求的管理制度至少包括安全管理制度总则、人员管理、系统建设、系统运维。人员安全录用审查、离职流程、安全培训记录。建设管理定级备案、安全方案设计、产品采购、测试验收。运维管理环境管理、资产管理、介质管理、设备维护、漏洞管理、备份恢复、应急预案。我一般会建一个文件夹按这四类分好每份制度配上发布记录和培训签到表。测评时直接按目录抽省得现场翻。4. 测评前自查五个最容易翻车的检查点整改做完不等于能过。正式测评前我通常会带团队做一轮自查下面五个点翻车率最高。4.1 漏洞扫描报告里的高危没闭环现象测评机构扫出一堆高危漏洞整改报告里只写了“已修复”但没有复测截图或闭环记录。 原因很多团队修完不验证或者验证了不留痕。 解决每个高危漏洞都要有“发现-修复-复测”三段记录复测用同款工具或更严格工具截图带时间戳。4.2 日志留存时间不够现象安全审计要求日志留存不少于6个月实际只留了1个月。 原因磁盘空间不够或者没配日志轮转。 解决先算日志量再扩磁盘或配远程日志服务器。用 logrotate 配保留策略# /etc/logrotate.d/syslog /var/log/messages { rotate 26 weekly missingok notifempty compress }rotate 26表示保留26周约6个月。按实际日志量调整。4.3 备份数据没做恢复演练现象有备份策略但从来没恢复过。测评时要求提供恢复演练记录拿不出来。 原因只备份不演练等于没备份。 解决每季度做一次恢复演练记录恢复时间、数据完整性校验结果。三级系统要求备份数据完整性和可用性都要验证。4.4 安全管理制度没有发布记录现象制度文档写得很全但没有发布日期、发布文号、培训记录。 原因制度是补的不是实际执行的。 解决补发布记录和培训签到制度内容要和实际运维动作对得上。测评专家会交叉验证。4.5 定级报告和实际系统对不上现象定级报告写的是二级实际系统承载了大量敏感数据测评时被要求重新定级。 原因定级时低估了数据敏感度。 解决定级前把数据分类分级做一遍敏感数据单独标识。拿不准就按高标准定。5. 把分级保护做成持续动作三个可复用的工程习惯分级保护不是一次测评就结束的事。三级系统每年要测评二级系统也要定期自查。与其每次临时抱佛脚不如把几个动作变成日常习惯。5.1 用配置基线代替临时加固我一般会维护一份配置基线文档按操作系统、数据库、中间件、网络设备分类每项写清楚“检查命令、期望值、整改命令”。新系统上线前先过一遍基线比事后整改省事得多。下面是一个基线检查表的片段检查项检查命令期望值整改命令密码最长有效期chage -l root≤90天chage -M 90 rootSSH 空口令登录grep PermitEmptyPasswords /etc/ssh/sshd_configno改为 no 并重启 sshd审计服务状态systemctl is-active auditdactivesystemctl enable --now auditd这张表可以直接交给运维执行也可以写成 Ansible playbook 批量跑。5.2 把测评项拆进日常巡检测评项不是测评前才看的。我会把三级要求里的检查项拆成日常巡检清单比如每周检查一次日志留存、每月检查一次备份恢复、每季度检查一次账户权限。巡检记录本身就是测评时的证据材料。5.3 变更时同步更新定级和备案系统做重大变更时比如新增对外服务、数据量翻倍、架构调整要重新评估定级是否需要调整。我见过一个系统从内部使用改成对外服务定级没变测评时被直接判不符合。变更流程里加一个“安全影响评估”节点能避免很多返工。最后说一个血泪教训我早期做等保的时候总想着先把技术整改做完再补管理文档结果技术做完了管理文档对不上实际配置又回头改技术。后来我改成“制度先行、技术跟进、同步留痕”测评前一周基本不用熬夜。希望帮到你。本文还有配套的精品资源点击获取
