网络与基础设施安全
本域解决的不是“有哪些网络安全法规”，而是一个网络或信息系统从上线到持续运行时，哪些基础安全制度会触发、哪些需要并行落实、分别用什么标准建设和验证。
基础安全制度地图
网络与信息系统
│
┌─────────┴─────────┐
│ │
等级保护 是否为关基
│ │
定级 → 备案 → 建设 → 测评 └─ 是
│ │
22240 → 22239 → 28448 关基重点保护
│ │
│ 39204 → GA/T 2182
│ │
└─────────┬─────────┘
│
是否需要密码应用
│
39786 → 43206
│
关基再叠加 GM/T 0133
│
┌────────────────┼────────────────┐
│ │ │
产品/服务采购 漏洞治理 安全事件
│ │ │
网络安全审查 漏洞管理规定 事件报告制度
（适用时） （适用时） （按场景并行）
这几套制度不是互相替代关系。一个重要支付系统可能同时属于等级保护对象、关基，使用商用密码，并受到人民银行网络安全事件报告要求约束；特定采购还可能触发网络安全审查。
五套核心制度
| 制度 | 什么时候判断 | 核心问题 | 建设/验证主线 |
|---|---|---|---|
| 等级保护 | 网络和信息系统规划、上线及重大变化时 | 对象是什么、定几级、基础安全做到什么程度 | 22240定级 → 22239建设 → 28448测评 |
| 关基重点保护 | 依法认定为关基后持续适用 | 关键业务和依赖如何重点保护 | 39204保护 → GA/T 2182测评 |
| 密码与密评 | 规划设计及密码应用发生重大变化时 | 密码是否用对、密钥是否管住、是否需要密评 | 39786建设 → 43206测评；关基叠加GM/T 0133 |
| 网络安全审查 | 关基采购网络产品服务等法定场景 | 供应链是否可能影响国家安全 | 适用性判断 → 申报/审查 → 持续供应链管理 |
| 事件报告 | 发生或可能发生网络安全事件时 | 是否构成事件、向谁报、多久报 | 发现 → 判级 → 报告 → 更新 → 总结整改 |
一套系统如何判断
先判断等级保护
等级保护是基础入口。新系统、新平台和重大架构变化都应判断等级保护对象和等级，不能只沿用历史备案。
再判断是否属于关基
关基身份以保护工作部门依法组织认定并通知为基础，不由企业仅凭行业、规模或“系统很重要”自行认定。被认定后，等保仍继续适用，并叠加关基重点保护。
→ 关键信息基础设施安全保护条例
→ 关键信息基础设施安全保护体系
独立判断密码与密评
密码应用不是等保或关基的附属勾选项。应根据系统、数据和监管要求识别密码应用需求；关基还需落实专项商用密码要求。
采购和供应链判断网络安全审查
关基运营者采购网络产品和服务，预判可能影响国家安全的，应按适用规则申报网络安全审查。其他达到法定条件的平台活动也可能进入审查范围。
→ 网络安全审查办法
运行期持续做漏洞与事件治理
上线并不意味着合规工作结束。产品漏洞发现、验证、修补和披露受专项规则约束；发生事件后还可能同时触发国家、行业、数据和个人信息等多条报告义务。
支付及人民银行业务领域还应并行判断人民银行网络安全事件报告管理办法。
三套“建设—测评”关系
| 体系 | 建设基线 | 测评/验证 | 不能误解为 |
|---|---|---|---|
| 等保 | GB/T 22239 | GB/T 28448 | “拿到测评报告就完成安全建设” |
| 关基 | GB/T 39204 | GA/T 2182 | “关基替代等保” |
| 密码 | GB/T 39786 | GB/T 43206 / 密评制度 | “系统用了TLS/加密就满足密码要求” |
企业更适合维护一份统一控制矩阵，将三套体系的重复控制映射到同一安全能力和证据，专项要求再单独增强，避免分别建设三套制度、三套账号管理、三套日志和三套整改流程。
企业统一治理模型
法规 / 监管 / 标准
↓
适用性判断
↓
统一控制矩阵
↓
┌───────┼────────┬────────┐
身份权限 网络边界 数据保护 密码
日志监测 漏洞管理 供应链 应急
└───────┼────────┴────────┘
↓
配置 / 日志 / 工单 / 演练
↓
等保测评 / 关基测评 / 密评 / 监管检查
↓
统一整改闭环
这样监管制度可以变化，底层安全能力不需要按每套法规重复建设。