简介这份《等保2.0——网络安全等级保护解决方案》共53页PPT面向信息安全合规、等保建设整改、安全方案设计与运维管理人员系统梳理等保2.0的政策背景、标准演进与落地方法。内容围绕“可信、可控、可管”展开覆盖定级、备案、建设整改、等级测评、监督检查五个阶段并解析“一个中心、三重防护”框架对计算环境、区域边界、通信网络实施多层防护。方案还给出总体设计流程梳理业务流程、识别主体客体与最小权限、开展风险评估、分层分域设计安全机制并从物理、网络、主机、应用、数据及安全管理等维度提出要求与产品部署思路便于直接用于方案汇报或合规建设参考。资源包为1个pptx文件约47.9MB已有164人学习。适合需要快速理解等保2.0体系并形成解决方案框架的安全从业者与项目人员。1. 53 页等保2.0解决方案里真正决定成败的是前 5 页标题里的「等保2.0」指 GB/T 22239-2019 落地后的等级保护体系这份 53 页 PPT 的骨架无非四段定级、差距评估、整改建设、测评过关。多数人只盯第 30 页以后的技术架构图和产品清单结果在评审会上被一句「你这系统凭什么定三级」问住。真正决定后面 48 页怎么写的是前 5 页系统边界划到哪、定几级、按哪个等级取控制项、现状差距有多大、预算投在哪一类问题上。这几页写歪了后面的拓扑图、防火墙策略、审计留存参数全部返工重排。它适合三类人出方案的售前、接测评的安全负责人、按条款配设备的运维。2. 等保2.0定级与备案方案里第一组不能写错的参数2.1 受侵害客体、侵害程度与 S/A/G 三个标记定级不是拍脑袋写个「三级」它由两个维度交叉决定受侵害的客体、对客体造成的侵害程度。客体分三档——公民法人和其他组织的合法权益、社会秩序和公共利益、国家安全侵害程度也分三档——一般损害、严重损害、特别严重损害。常见填写口径按下面这张矩阵落到 1 到 5 级受侵害客体一般损害严重损害特别严重损害公民、法人和其他组织的合法权益一级二级三级社会秩序、公共利益二级三级四级国家安全三级四级五级关键在于这套矩阵要跑两遍一次针对「业务信息」得到业务信息安全保护等级 S一次针对「系统服务」得到系统服务安全保护等级 A取两者中的较高值作为系统等级G 表示对应等级的通用要求。实际项目里 S 和 A 不一样非常普遍——数据泄露的后果和业务中断的后果本来就不是一回事。这两个标记决定了后面按哪一档取控制项也决定了测评时专家先翻哪几页。2.2 用一段脚本把定级结论固化下来定级讨论会开完结论往往散在会议纪要里过两个月谁也说不清当初为什么判「严重损害」。我一般写个十几行脚本把结论连同理由一起落成文件改一次记录一次。# dingji.py —— 把定级讨论的结论固化成可复核的记录 from dataclasses import dataclass, asdict # 客体 x 侵害程度 - 等级 MATRIX { (合法权益, 一般损害): 1, (合法权益, 严重损害): 2, (合法权益, 特别严重损害): 3, (公共利益, 一般损害): 2, (公共利益, 严重损害): 3, (公共利益, 特别严重损害): 4, (国家安全, 一般损害): 3, (国家安全, 严重损害): 4, (国家安全, 特别严重损害): 5, } dataclass class Target: name: str # 业务信息 / 系统服务 subject: str # 受侵害客体 damage: str # 侵害程度 reason: str # 判定理由评审时会逐条追问 def level(self) - int: return MATRIX[(self.subject, self.damage)] business Target(业务信息, 公共利益, 严重损害, 约 30 万用户实名信息泄露影响面广) service Target(系统服务, 公共利益, 一般损害, 中断 4 小时内可由备用流程承接) s, a business.level(), service.level() final max(s, a) for t in (business, service): print(asdict(t), f- {t.level()} 级) print(f系统定级建议{final} 级标记 S{s}A{a}G{final})逻辑说明S 和 A 各自独立算再取较高值避免只按数据敏感度定级而漏掉业务连续性。参数说明subject只能取矩阵里的三类客体damage取三档侵害程度换一个取值脚本就会给出不同等级。reason字段是刻意加的——方案里每个等级后面都得跟一句能站得住的话脚本不做判断题只负责把话留下来。2.3 定级备案最容易返工的三处第一处是边界划得太宽。把办公 OA、测试环境、对外门户塞进同一个系统一起定级等级会被最高那一块抬上去整改面瞬间翻倍。常见做法是按业务独立性和网络区域拆成若干系统分别定级测试环境除非承载真实数据一般不单独定级。第二处是只算业务信息不算系统服务。中断两小时和泄露十万条记录的严重程度完全不同只写一个 S 不写 A评审时通常会被打回补充。第三处是定级理由只有一句话。备案材料里常见要附定级报告、系统拓扑和安全管理文件清单定级报告的核心是「为什么是严重损害」需要用户规模、数据量级、业务中断时长的量化描述最好把测算过程也贴上去。提示定级结论一旦备案后续整改按这个等级取控制项中途改级意味着前面所有差距评估和整改清单作废宁可多花半天确认边界。3. 把 GB/T 22239 条款拆成整改工单等保2.0差距评估的落地方式3.1 通用要求与扩展要求的条款编号规律GB/T 22239-2019 把基本要求拆成安全通用要求和安全扩展要求两大部分。通用要求下再分技术和管理两条线技术上包括安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心管理上包括安全管理制度、安全管理机构、安全管理人员、安全建设管理、安全运维管理。扩展要求针对云计算、移动互联、物联网、工业控制系统、大数据等场景用的是同一套编号体系但控制点和要求项另算。做差距评估时最怕的是拿三级的控制项去套二级系统多出来的要求项全部判「不适用」清单直接废掉。技术类别典型控制点三级常见硬指标安全通信网络网络架构、通信传输、可信验证区域划分、传输加密安全区域边界边界防护、访问控制、入侵防范、恶意代码防范、安全审计边界访问控制、入侵检测与告警安全计算环境身份鉴别、访问控制、安全审计、入侵防范、数据备份恢复、剩余信息保护双因素鉴别、日志留存不少于 6 个月安全管理中心系统管理、审计管理、安全管理、集中管控日志集中收集、设备统一管控3.2 差距评估的评分口径符合、部分符合、不符合怎么算现场评估给每个要求项打四种结果符合、部分符合、不符合、不适用。常见计分口径是把部分符合按半分计不适用项从分母里剔除于是单个控制点的得分率写成得分率 (符合项权重 部分符合项权重 × 0.5) ÷ 适用项权重合计 × 100%权重一般按关键、重要、一般三档给 3、2、1。更需要注意的是高风险判定身份鉴别、访问控制、安全审计这类关键控制点只要判「不符合」整份报告会被标成高风险得分再高也过不了关。所以整改排期不能只看百分比得先把关键项里所有未达标项捞出来。下面这段脚本干的就是这件事。3.3 用 Python 把条款表转成可勾选的整改清单import csv from dataclasses import dataclass, asdict WEIGHT {关键: 3, 重要: 2, 一般: 1} SCORE {符合: 1.0, 部分符合: 0.5, 不符合: 0.0, 不适用: 0.0} dataclass class Item: clause: str # 条款号 category: str # 所属类别如 安全计算环境 point: str # 控制点如 身份鉴别 weight: str # 关键 / 重要 / 一般 result: str 不符合 owner: str # 整改责任人 due: str # 整改期限 property def applicable(self) - bool: return self.result ! 不适用 property def score(self) - float: return SCORE[self.result] * WEIGHT[self.weight] def summarize(items): app [i for i in items if i.applicable] got sum(i.score for i in app) total sum(WEIGHT[i.weight] for i in app) return len(app), got / total * 100 if total else 0.0 items [ Item(8.x.1, 安全计算环境, 身份鉴别, 关键, 部分符合, 运维组, 2025-06-30), Item(8.x.2, 安全计算环境, 安全审计, 关键, 不符合, 安全组, 2025-07-15), Item(8.x.3, 安全区域边界, 访问控制, 重要, 符合, 网络组, 2025-06-01), Item(8.x.4, 安全管理中心, 集中管控, 重要, 不符合, 安全组, 2025-08-30), ] n, rate summarize(items) print(f适用项 {n} 项加权得分率 {rate:.1f}%) # 先按权重降序、再按未达标优先排序直接当派单表用 order sorted(items, keylambda x: (WEIGHT[x.weight], SCORE[x.result]), reverseTrue) with open(rectify.csv, w, newline, encodingutf-8-sig) as f: w csv.DictWriter(f, fieldnameslist(asdict(order[0]).keys())) w.writeheader() for i in order: w.writerow(asdict(i))逻辑说明summarize先把不适用项剔除再算加权得分率避免分母被无关项撑大导致分数虚低。参数说明weight决定排序权重关键项永远排在最前result只能取四个枚举值写错会直接抛 KeyError这算是一种保护encodingutf-8-sig是为了 Excel 双击打开不乱码。输出不是给人看的报表而是按责任人分组派单的原始表——把 CSV 按owner列一筛每个人拿到自己的条目和期限比在 PPT 里画甘特图有用得多。注意部分符合事项在整改完成后要重新取证配好参数但没留配置导出和验证记录复测时通常还是判部分符合。4. 等保2.0技术架构页怎么落成配置通信网络、区域边界、计算环境、管理中心4.1 安全通信网络拓扑页对应的三条硬参数方案第 30 页往后一定是那张分层拓扑图但图上的方框和箭头本身不构成合规得能落成参数。网络架构这一项我一般收敛成三条安全域划分是否到位、关键链路和设备是否有冗余、通信传输是否用了密码技术保护完整性。要求项可落地参数常见取值网络架构业务网、办公网、管理网、测试网隔离至少划分 3 个安全域管理网禁止与业务网直通通信传输加密协议与算法TLS 1.2 及以上国密场景用 SM2/SM3/SM4带宽与冗余峰值利用率、链路冗余峰值利用率低于 70%核心链路双上联这张表最好直接贴在拓扑图右侧评审时专家不会去数你画了几个框他会问「管理网和业务网之间串了什么设备、规则在哪」。答不上来就是纸面合规。4.2 安全区域边界ACL 与入侵防范的核对命令边界访问控制的典型问题是规则写反了顺序。ACL 自上而下匹配第一条命中即生效把 permit any 写在拒绝规则前面等于整条策略形同虚设。! Cisco IOS数据库网段只允许应用服务器访问办公网段一律拒绝 ip access-list extended DB-GUARD deny tcp 192.168.20.0 0.0.0.255 192.168.30.0 0.0.0.255 eq 3306 permit tcp 192.168.10.0 0.0.0.255 192.168.30.0 0.0.0.255 eq 3306 deny ip any 192.168.30.0 0.0.0.255 permit ip any any ! interface Vlan30 ip access-group DB-GUARD in逻辑说明第一条先拒绝办公网段到数据库端口第二条只放应用服务器第三条兜底拒绝其他所有到数据库网段的流量第四条才是全局放通。参数说明eq 3306限定端口避免整段放通in表示在入方向生效写在出方向等于没拦。上线后用show ip access-lists DB-GUARD看每条规则的命中计数如果那条 deny 的计数长期为 0大概率是规则位置写错或者流量根本没经过这个接口。入侵防范这一项方案里通常会画一台 IDS/IPS验收要看的不是设备在不在而是部署方式和特征库更新。串联部署要确认旁路引流是否可回退旁路部署要确认镜像口覆盖了南北向和东西向流量特征库更新周期一般要求不高于一周抽查方式就是打开管理界面看最近一次更新时间。4.3 安全计算环境身份鉴别、访问控制、安全审计三级要求在身份鉴别上要求两种或两种以上组合的鉴别技术落地到 Linux 主机先把基础的口令与会话参数收干净。# sshd 关键参数禁用 root 直登、限制尝试次数、空闲会话超时 sudo sed -i -E s/^#?PermitRootLogin.*/PermitRootLogin no/ /etc/ssh/sshd_config sudo sed -i -E s/^#?MaxAuthTries.*/MaxAuthTries 5/ /etc/ssh/sshd_config sudo sed -i -E s/^#?ClientAliveInterval.*/ClientAliveInterval 600/ /etc/ssh/sshd_config sudo sed -i -E s/^#?ClientAliveCountMax.*/ClientAliveCountMax 0/ /etc/ssh/sshd_config sudo sshd -t sudo systemctl reload sshd # 先做语法校验再 reload逻辑说明ClientAliveInterval 600配合ClientAliveCountMax 0表示 10 分钟无操作直接断开对应会话超时要求MaxAuthTries 5要和下面的失败锁定配合才算完整闭环。参数说明sshd -t这一步必须做直接 reload 一个写坏的配置等于把远程运维通道自己关掉。口令复杂度与失败锁定# 口令长度与复杂度 sudo tee /etc/security/pwquality.conf /dev/null EOF minlen 12 # 三级常见做法是不低于 8条件允许直接上 12 dcredit -1 # 至少 1 位数字 ucredit -1 # 至少 1 位大写字母 lcredit -1 # 至少 1 位小写字母 ocredit -1 # 至少 1 位特殊字符 maxrepeat 3 # 禁止同一字符连续出现超过 3 次 EOF # 连续失败 5 次锁定 30 分钟 sudo tee /etc/security/faillock.conf /dev/null EOF deny 5 unlock_time 1800 EOF参数说明负值表示「至少几位」而不是「最多几位」写成正数是常见错误unlock_time单位为秒1800 即 30 分钟。改完用faillock --user 账号查看计数是否真的累加。数据库侧最容易被问的两句话一句是「有没有共享账号」一句是「口令会不会过期」两条 SQL 就能自证-- 核对账号状态、是否锁定、口令有效期 SELECT user, host, account_locked, password_lifetime FROM mysql.user; -- 0 表示口令永不过期通常判不符合 SHOW VARIABLES LIKE default_password_lifetime; -- 审计是否开启 SHOW VARIABLES LIKE general_log%;逻辑说明第一条查的是账号治理重点关注account_locked和应用连接账号的host范围第二条查口令策略如果策略由应用侧统一管理也要能拿出相应配置截图。参数说明不指望general_log全量开启对性能有影响通常用独立的审计插件或在代理层做审计能集中输出到日志平台即可。4.4 安全管理中心日志留存 180 天与集中管控集中管控是三级绕不开的一项落地动作就是日志集中收集加统一管理。主机侧先确认审计服务真的在跑并且容量够撑住留存周期。sudo tee -a /etc/audit/auditd.conf /dev/null EOF num_logs 20 max_log_file 512 # 单位 MB max_log_file_action keep_logs # 达上限时保留旧日志而不是覆盖 EOF sudo systemctl restart auditd sudo auditctl -s # enabled 1 才算真的开着逻辑说明实际可用容量是num_logs × max_log_file也就是约 10GB这是给自己算的账max_log_file_action设成 rotate 时最早那批审计记录会在半夜被悄悄删掉留存天数直接不达标。参数说明num_logs和max_log_file按日均日志量倒推日均 150MB 的系统20 个 512MB 文件撑不到 180 天得往上调。集中收集用 rsyslog 转发TCP 而不是 UDP# 客户端系统日志与审计日志统一转发到集中日志平台 echo *.* 10.0.30.10:514 | sudo tee /etc/rsyslog.d/90-central.conf sudo systemctl restart rsyslog logger -t audit-check central log pipeline test $$ # 打一条带 PID 的测试日志逻辑说明表示 TCP单是 UDP高峰丢包会让审计记录出现空洞抽查时一眼就能看出来。参数说明日志平台侧要按索引保留 180 天以上只收不删测试日志带上 PID 便于在平台精确检索那一行查得到才算链路打通。数据备份恢复这一项常见做法是每日增量加每周全量再配一次季度恢复演练演练报告比备份任务列表更有说服力。5. 让 53 页方案经得起测评追问证据链自查与抽验脚本方案写完真正决定测评结论的是举证材料齐不齐、时效对不对。评审专家的提问方式很固定你说配了拿什么证明你说三个月内做的时间戳在哪。下面这张表是我做内部预检时用的对照口径。控制项举证材料时效要求抽验动作身份鉴别sshd 配置导出、登录日志近 3 个月现场改一条参数看是否生效安全审计日志平台检索截图覆盖近 180 天随机取一周核对日志连续性入侵防范边界策略、告警记录近 3 个月看最近一次特征库更新时间数据备份备份任务记录、恢复演练报告近半年抽查一份备份文件的可恢复性安全运维管理变更单、巡检记录、培训签到近一年访谈一名运维是否清楚流程预检不要靠人工翻页翻配置抽一批主机跑一遍更实在#!/usr/bin/env bash # audit_sweep.sh —— 抽验一批主机的关键参数只输出不合规项 set -u while read -r host; do cfg$(ssh -o ConnectTimeout5 -o BatchModeyes $host \ grep -Ei ^(PermitRootLogin|MaxAuthTries|ClientAliveInterval) /etc/ssh/sshd_config 2/dev/null) [ -z $cfg ] { echo $host 不可达或未取到配置; continue; } echo $cfg | grep -qiE ^PermitRootLogin[[:space:]]no || echo $host PermitRootLogin 不合规 echo $cfg | grep -qiE ^MaxAuthTries[[:space:]]5 || echo $host MaxAuthTries 不合规 echo $cfg | grep -qiE ^ClientAliveInterval[[:space:]]600 || echo $host ClientAliveInterval 不合规 done hosts.txt逻辑说明BatchModeyes让脚本在需要交互输密码时直接失败退出避免批量执行卡死输出「不合规」的行数就是整改工单的条数可以直接和第 3 章生成的rectify.csv对照看哪些条目嘴上说改完了、实际没落到机器上。参数说明hosts.txt一行一个主机名或 IP按安全域分组存放抽验时按域而不是按全量跑一台机器 5 秒、200 台的窗口期也能接受。更进一步的一招是把正则从「精确匹配」放宽成「匹配生效值」先用sshd -T | grep -Ei permitrootlogin|maxauthtries|clientaliveinterval拿到运行时实际生效值再和配置文件比对能抓出「配置文件改了但没 reload」这种最隐蔽的不一致。每月 1 号跑一次audit_sweep.sh把带时间戳的输出追加进巡检记录测评时直接导出这份连续记录作为举证材料。本文还有配套的精品资源点击获取 等保2.0 53页方案：定级、差距评估与整改证据链
简介这份《等保2.0——网络安全等级保护解决方案》共53页PPT面向信息安全合规、等保建设整改、安全方案设计与运维管理人员系统梳理等保2.0的政策背景、标准演进与落地方法。内容围绕“可信、可控、可管”展开覆盖定级、备案、建设整改、等级测评、监督检查五个阶段并解析“一个中心、三重防护”框架对计算环境、区域边界、通信网络实施多层防护。方案还给出总体设计流程梳理业务流程、识别主体客体与最小权限、开展风险评估、分层分域设计安全机制并从物理、网络、主机、应用、数据及安全管理等维度提出要求与产品部署思路便于直接用于方案汇报或合规建设参考。资源包为1个pptx文件约47.9MB已有164人学习。适合需要快速理解等保2.0体系并形成解决方案框架的安全从业者与项目人员。1. 53 页等保2.0解决方案里真正决定成败的是前 5 页标题里的「等保2.0」指 GB/T 22239-2019 落地后的等级保护体系这份 53 页 PPT 的骨架无非四段定级、差距评估、整改建设、测评过关。多数人只盯第 30 页以后的技术架构图和产品清单结果在评审会上被一句「你这系统凭什么定三级」问住。真正决定后面 48 页怎么写的是前 5 页系统边界划到哪、定几级、按哪个等级取控制项、现状差距有多大、预算投在哪一类问题上。这几页写歪了后面的拓扑图、防火墙策略、审计留存参数全部返工重排。它适合三类人出方案的售前、接测评的安全负责人、按条款配设备的运维。2. 等保2.0定级与备案方案里第一组不能写错的参数2.1 受侵害客体、侵害程度与 S/A/G 三个标记定级不是拍脑袋写个「三级」它由两个维度交叉决定受侵害的客体、对客体造成的侵害程度。客体分三档——公民法人和其他组织的合法权益、社会秩序和公共利益、国家安全侵害程度也分三档——一般损害、严重损害、特别严重损害。常见填写口径按下面这张矩阵落到 1 到 5 级受侵害客体一般损害严重损害特别严重损害公民、法人和其他组织的合法权益一级二级三级社会秩序、公共利益二级三级四级国家安全三级四级五级关键在于这套矩阵要跑两遍一次针对「业务信息」得到业务信息安全保护等级 S一次针对「系统服务」得到系统服务安全保护等级 A取两者中的较高值作为系统等级G 表示对应等级的通用要求。实际项目里 S 和 A 不一样非常普遍——数据泄露的后果和业务中断的后果本来就不是一回事。这两个标记决定了后面按哪一档取控制项也决定了测评时专家先翻哪几页。2.2 用一段脚本把定级结论固化下来定级讨论会开完结论往往散在会议纪要里过两个月谁也说不清当初为什么判「严重损害」。我一般写个十几行脚本把结论连同理由一起落成文件改一次记录一次。# dingji.py —— 把定级讨论的结论固化成可复核的记录 from dataclasses import dataclass, asdict # 客体 x 侵害程度 - 等级 MATRIX { (合法权益, 一般损害): 1, (合法权益, 严重损害): 2, (合法权益, 特别严重损害): 3, (公共利益, 一般损害): 2, (公共利益, 严重损害): 3, (公共利益, 特别严重损害): 4, (国家安全, 一般损害): 3, (国家安全, 严重损害): 4, (国家安全, 特别严重损害): 5, } dataclass class Target: name: str # 业务信息 / 系统服务 subject: str # 受侵害客体 damage: str # 侵害程度 reason: str # 判定理由评审时会逐条追问 def level(self) - int: return MATRIX[(self.subject, self.damage)] business Target(业务信息, 公共利益, 严重损害, 约 30 万用户实名信息泄露影响面广) service Target(系统服务, 公共利益, 一般损害, 中断 4 小时内可由备用流程承接) s, a business.level(), service.level() final max(s, a) for t in (business, service): print(asdict(t), f- {t.level()} 级) print(f系统定级建议{final} 级标记 S{s}A{a}G{final})逻辑说明S 和 A 各自独立算再取较高值避免只按数据敏感度定级而漏掉业务连续性。参数说明subject只能取矩阵里的三类客体damage取三档侵害程度换一个取值脚本就会给出不同等级。reason字段是刻意加的——方案里每个等级后面都得跟一句能站得住的话脚本不做判断题只负责把话留下来。2.3 定级备案最容易返工的三处第一处是边界划得太宽。把办公 OA、测试环境、对外门户塞进同一个系统一起定级等级会被最高那一块抬上去整改面瞬间翻倍。常见做法是按业务独立性和网络区域拆成若干系统分别定级测试环境除非承载真实数据一般不单独定级。第二处是只算业务信息不算系统服务。中断两小时和泄露十万条记录的严重程度完全不同只写一个 S 不写 A评审时通常会被打回补充。第三处是定级理由只有一句话。备案材料里常见要附定级报告、系统拓扑和安全管理文件清单定级报告的核心是「为什么是严重损害」需要用户规模、数据量级、业务中断时长的量化描述最好把测算过程也贴上去。提示定级结论一旦备案后续整改按这个等级取控制项中途改级意味着前面所有差距评估和整改清单作废宁可多花半天确认边界。3. 把 GB/T 22239 条款拆成整改工单等保2.0差距评估的落地方式3.1 通用要求与扩展要求的条款编号规律GB/T 22239-2019 把基本要求拆成安全通用要求和安全扩展要求两大部分。通用要求下再分技术和管理两条线技术上包括安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心管理上包括安全管理制度、安全管理机构、安全管理人员、安全建设管理、安全运维管理。扩展要求针对云计算、移动互联、物联网、工业控制系统、大数据等场景用的是同一套编号体系但控制点和要求项另算。做差距评估时最怕的是拿三级的控制项去套二级系统多出来的要求项全部判「不适用」清单直接废掉。技术类别典型控制点三级常见硬指标安全通信网络网络架构、通信传输、可信验证区域划分、传输加密安全区域边界边界防护、访问控制、入侵防范、恶意代码防范、安全审计边界访问控制、入侵检测与告警安全计算环境身份鉴别、访问控制、安全审计、入侵防范、数据备份恢复、剩余信息保护双因素鉴别、日志留存不少于 6 个月安全管理中心系统管理、审计管理、安全管理、集中管控日志集中收集、设备统一管控3.2 差距评估的评分口径符合、部分符合、不符合怎么算现场评估给每个要求项打四种结果符合、部分符合、不符合、不适用。常见计分口径是把部分符合按半分计不适用项从分母里剔除于是单个控制点的得分率写成得分率 (符合项权重 部分符合项权重 × 0.5) ÷ 适用项权重合计 × 100%权重一般按关键、重要、一般三档给 3、2、1。更需要注意的是高风险判定身份鉴别、访问控制、安全审计这类关键控制点只要判「不符合」整份报告会被标成高风险得分再高也过不了关。所以整改排期不能只看百分比得先把关键项里所有未达标项捞出来。下面这段脚本干的就是这件事。3.3 用 Python 把条款表转成可勾选的整改清单import csv from dataclasses import dataclass, asdict WEIGHT {关键: 3, 重要: 2, 一般: 1} SCORE {符合: 1.0, 部分符合: 0.5, 不符合: 0.0, 不适用: 0.0} dataclass class Item: clause: str # 条款号 category: str # 所属类别如 安全计算环境 point: str # 控制点如 身份鉴别 weight: str # 关键 / 重要 / 一般 result: str 不符合 owner: str # 整改责任人 due: str # 整改期限 property def applicable(self) - bool: return self.result ! 不适用 property def score(self) - float: return SCORE[self.result] * WEIGHT[self.weight] def summarize(items): app [i for i in items if i.applicable] got sum(i.score for i in app) total sum(WEIGHT[i.weight] for i in app) return len(app), got / total * 100 if total else 0.0 items [ Item(8.x.1, 安全计算环境, 身份鉴别, 关键, 部分符合, 运维组, 2025-06-30), Item(8.x.2, 安全计算环境, 安全审计, 关键, 不符合, 安全组, 2025-07-15), Item(8.x.3, 安全区域边界, 访问控制, 重要, 符合, 网络组, 2025-06-01), Item(8.x.4, 安全管理中心, 集中管控, 重要, 不符合, 安全组, 2025-08-30), ] n, rate summarize(items) print(f适用项 {n} 项加权得分率 {rate:.1f}%) # 先按权重降序、再按未达标优先排序直接当派单表用 order sorted(items, keylambda x: (WEIGHT[x.weight], SCORE[x.result]), reverseTrue) with open(rectify.csv, w, newline, encodingutf-8-sig) as f: w csv.DictWriter(f, fieldnameslist(asdict(order[0]).keys())) w.writeheader() for i in order: w.writerow(asdict(i))逻辑说明summarize先把不适用项剔除再算加权得分率避免分母被无关项撑大导致分数虚低。参数说明weight决定排序权重关键项永远排在最前result只能取四个枚举值写错会直接抛 KeyError这算是一种保护encodingutf-8-sig是为了 Excel 双击打开不乱码。输出不是给人看的报表而是按责任人分组派单的原始表——把 CSV 按owner列一筛每个人拿到自己的条目和期限比在 PPT 里画甘特图有用得多。注意部分符合事项在整改完成后要重新取证配好参数但没留配置导出和验证记录复测时通常还是判部分符合。4. 等保2.0技术架构页怎么落成配置通信网络、区域边界、计算环境、管理中心4.1 安全通信网络拓扑页对应的三条硬参数方案第 30 页往后一定是那张分层拓扑图但图上的方框和箭头本身不构成合规得能落成参数。网络架构这一项我一般收敛成三条安全域划分是否到位、关键链路和设备是否有冗余、通信传输是否用了密码技术保护完整性。要求项可落地参数常见取值网络架构业务网、办公网、管理网、测试网隔离至少划分 3 个安全域管理网禁止与业务网直通通信传输加密协议与算法TLS 1.2 及以上国密场景用 SM2/SM3/SM4带宽与冗余峰值利用率、链路冗余峰值利用率低于 70%核心链路双上联这张表最好直接贴在拓扑图右侧评审时专家不会去数你画了几个框他会问「管理网和业务网之间串了什么设备、规则在哪」。答不上来就是纸面合规。4.2 安全区域边界ACL 与入侵防范的核对命令边界访问控制的典型问题是规则写反了顺序。ACL 自上而下匹配第一条命中即生效把 permit any 写在拒绝规则前面等于整条策略形同虚设。! Cisco IOS数据库网段只允许应用服务器访问办公网段一律拒绝 ip access-list extended DB-GUARD deny tcp 192.168.20.0 0.0.0.255 192.168.30.0 0.0.0.255 eq 3306 permit tcp 192.168.10.0 0.0.0.255 192.168.30.0 0.0.0.255 eq 3306 deny ip any 192.168.30.0 0.0.0.255 permit ip any any ! interface Vlan30 ip access-group DB-GUARD in逻辑说明第一条先拒绝办公网段到数据库端口第二条只放应用服务器第三条兜底拒绝其他所有到数据库网段的流量第四条才是全局放通。参数说明eq 3306限定端口避免整段放通in表示在入方向生效写在出方向等于没拦。上线后用show ip access-lists DB-GUARD看每条规则的命中计数如果那条 deny 的计数长期为 0大概率是规则位置写错或者流量根本没经过这个接口。入侵防范这一项方案里通常会画一台 IDS/IPS验收要看的不是设备在不在而是部署方式和特征库更新。串联部署要确认旁路引流是否可回退旁路部署要确认镜像口覆盖了南北向和东西向流量特征库更新周期一般要求不高于一周抽查方式就是打开管理界面看最近一次更新时间。4.3 安全计算环境身份鉴别、访问控制、安全审计三级要求在身份鉴别上要求两种或两种以上组合的鉴别技术落地到 Linux 主机先把基础的口令与会话参数收干净。# sshd 关键参数禁用 root 直登、限制尝试次数、空闲会话超时 sudo sed -i -E s/^#?PermitRootLogin.*/PermitRootLogin no/ /etc/ssh/sshd_config sudo sed -i -E s/^#?MaxAuthTries.*/MaxAuthTries 5/ /etc/ssh/sshd_config sudo sed -i -E s/^#?ClientAliveInterval.*/ClientAliveInterval 600/ /etc/ssh/sshd_config sudo sed -i -E s/^#?ClientAliveCountMax.*/ClientAliveCountMax 0/ /etc/ssh/sshd_config sudo sshd -t sudo systemctl reload sshd # 先做语法校验再 reload逻辑说明ClientAliveInterval 600配合ClientAliveCountMax 0表示 10 分钟无操作直接断开对应会话超时要求MaxAuthTries 5要和下面的失败锁定配合才算完整闭环。参数说明sshd -t这一步必须做直接 reload 一个写坏的配置等于把远程运维通道自己关掉。口令复杂度与失败锁定# 口令长度与复杂度 sudo tee /etc/security/pwquality.conf /dev/null EOF minlen 12 # 三级常见做法是不低于 8条件允许直接上 12 dcredit -1 # 至少 1 位数字 ucredit -1 # 至少 1 位大写字母 lcredit -1 # 至少 1 位小写字母 ocredit -1 # 至少 1 位特殊字符 maxrepeat 3 # 禁止同一字符连续出现超过 3 次 EOF # 连续失败 5 次锁定 30 分钟 sudo tee /etc/security/faillock.conf /dev/null EOF deny 5 unlock_time 1800 EOF参数说明负值表示「至少几位」而不是「最多几位」写成正数是常见错误unlock_time单位为秒1800 即 30 分钟。改完用faillock --user 账号查看计数是否真的累加。数据库侧最容易被问的两句话一句是「有没有共享账号」一句是「口令会不会过期」两条 SQL 就能自证-- 核对账号状态、是否锁定、口令有效期 SELECT user, host, account_locked, password_lifetime FROM mysql.user; -- 0 表示口令永不过期通常判不符合 SHOW VARIABLES LIKE default_password_lifetime; -- 审计是否开启 SHOW VARIABLES LIKE general_log%;逻辑说明第一条查的是账号治理重点关注account_locked和应用连接账号的host范围第二条查口令策略如果策略由应用侧统一管理也要能拿出相应配置截图。参数说明不指望general_log全量开启对性能有影响通常用独立的审计插件或在代理层做审计能集中输出到日志平台即可。4.4 安全管理中心日志留存 180 天与集中管控集中管控是三级绕不开的一项落地动作就是日志集中收集加统一管理。主机侧先确认审计服务真的在跑并且容量够撑住留存周期。sudo tee -a /etc/audit/auditd.conf /dev/null EOF num_logs 20 max_log_file 512 # 单位 MB max_log_file_action keep_logs # 达上限时保留旧日志而不是覆盖 EOF sudo systemctl restart auditd sudo auditctl -s # enabled 1 才算真的开着逻辑说明实际可用容量是num_logs × max_log_file也就是约 10GB这是给自己算的账max_log_file_action设成 rotate 时最早那批审计记录会在半夜被悄悄删掉留存天数直接不达标。参数说明num_logs和max_log_file按日均日志量倒推日均 150MB 的系统20 个 512MB 文件撑不到 180 天得往上调。集中收集用 rsyslog 转发TCP 而不是 UDP# 客户端系统日志与审计日志统一转发到集中日志平台 echo *.* 10.0.30.10:514 | sudo tee /etc/rsyslog.d/90-central.conf sudo systemctl restart rsyslog logger -t audit-check central log pipeline test $$ # 打一条带 PID 的测试日志逻辑说明表示 TCP单是 UDP高峰丢包会让审计记录出现空洞抽查时一眼就能看出来。参数说明日志平台侧要按索引保留 180 天以上只收不删测试日志带上 PID 便于在平台精确检索那一行查得到才算链路打通。数据备份恢复这一项常见做法是每日增量加每周全量再配一次季度恢复演练演练报告比备份任务列表更有说服力。5. 让 53 页方案经得起测评追问证据链自查与抽验脚本方案写完真正决定测评结论的是举证材料齐不齐、时效对不对。评审专家的提问方式很固定你说配了拿什么证明你说三个月内做的时间戳在哪。下面这张表是我做内部预检时用的对照口径。控制项举证材料时效要求抽验动作身份鉴别sshd 配置导出、登录日志近 3 个月现场改一条参数看是否生效安全审计日志平台检索截图覆盖近 180 天随机取一周核对日志连续性入侵防范边界策略、告警记录近 3 个月看最近一次特征库更新时间数据备份备份任务记录、恢复演练报告近半年抽查一份备份文件的可恢复性安全运维管理变更单、巡检记录、培训签到近一年访谈一名运维是否清楚流程预检不要靠人工翻页翻配置抽一批主机跑一遍更实在#!/usr/bin/env bash # audit_sweep.sh —— 抽验一批主机的关键参数只输出不合规项 set -u while read -r host; do cfg$(ssh -o ConnectTimeout5 -o BatchModeyes $host \ grep -Ei ^(PermitRootLogin|MaxAuthTries|ClientAliveInterval) /etc/ssh/sshd_config 2/dev/null) [ -z $cfg ] { echo $host 不可达或未取到配置; continue; } echo $cfg | grep -qiE ^PermitRootLogin[[:space:]]no || echo $host PermitRootLogin 不合规 echo $cfg | grep -qiE ^MaxAuthTries[[:space:]]5 || echo $host MaxAuthTries 不合规 echo $cfg | grep -qiE ^ClientAliveInterval[[:space:]]600 || echo $host ClientAliveInterval 不合规 done hosts.txt逻辑说明BatchModeyes让脚本在需要交互输密码时直接失败退出避免批量执行卡死输出「不合规」的行数就是整改工单的条数可以直接和第 3 章生成的rectify.csv对照看哪些条目嘴上说改完了、实际没落到机器上。参数说明hosts.txt一行一个主机名或 IP按安全域分组存放抽验时按域而不是按全量跑一台机器 5 秒、200 台的窗口期也能接受。更进一步的一招是把正则从「精确匹配」放宽成「匹配生效值」先用sshd -T | grep -Ei permitrootlogin|maxauthtries|clientaliveinterval拿到运行时实际生效值再和配置文件比对能抓出「配置文件改了但没 reload」这种最隐蔽的不一致。每月 1 号跑一次audit_sweep.sh把带时间戳的输出追加进巡检记录测评时直接导出这份连续记录作为举证材料。本文还有配套的精品资源点击获取