简介：这份《等保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, key=lambda x: (WEIGHT[x.weight], SCORE[x.result]), reverse=True) with open("rectify.csv", "w", newline="", encoding="utf-8-sig") as f: w = csv.DictWriter(f, fieldnames=list(asdict(order[0]).keys())) w.writeheader() for i in order: w.writerow(asdict(i))逻辑说明：summarize先把不适用项剔除再算加权得分率，避免分母被无关项撑大导致分数虚低。参数说明：weight决定排序权重，关键项永远排在最前；result只能取四个枚举值，写错会直接抛 KeyError，这算是一种保护；encoding="utf-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 ConnectTimeout=5 -o BatchMode=yes "$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逻辑说明：BatchMode=yes让脚本在需要交互输密码时直接失败退出，避免批量执行卡死；输出「不合规」的行数就是整改工单的条数，可以直接和第 3 章生成的rectify.csv对照，看哪些条目嘴上说改完了、实际没落到机器上。参数说明：hosts.txt一行一个主机名或 IP，按安全域分组存放，抽验时按域而不是按全量跑，一台机器 5 秒、200 台的窗口期也能接受。
更进一步的一招是把正则从「精确匹配」放宽成「匹配生效值」：先用sshd -T | grep -Ei 'permitrootlogin|maxauthtries|clientaliveinterval'拿到运行时实际生效值，再和配置文件比对，能抓出「配置文件改了但没 reload」这种最隐蔽的不一致。每月 1 号跑一次audit_sweep.sh，把带时间戳的输出追加进巡检记录，测评时直接导出这份连续记录作为举证材料。
本文还有配套的精品资源，点击获取
