在数字化转型全面提速与《中华人民共和国网络安全法》、《数据安全法》严格落地的今天，**网络安全等级保护 2.0（GB/T 22239-2019，简称等保 2.0 / MLPS 2.0）**已经成为企业上云、政企业务准入、SaaS 软件交付乃至拟上市企业合规审查的强制性法定基准。

特别是对于运营核心业务系统、客户敏感数据、电商交易平台或金融支付网关的企业而言，“等保三级（信息系统安全保护第三级）”通常是不可逾越的底线标准。然而，在实际推进等保测评与常态化合规治理过程中，安全合规团队、基础设施团队与研发一线往往陷入以下四大管理痛点：

1. 定级备案对象边界模糊与资产台账动态脱节：随着云原生容器化、微服务架构与多云混合部署的演进，企业各类业务系统（如 ERP、CRM、核心订单中心、数据中台）的物理与逻辑边界频繁变更。若定级对象范围不清、备案表信息未与资产实际公网暴露面联动，极易在公安机关网安部门核查时面临责令整改；
2. 等保 2.0 控制项繁重（技术与管理双重核验失焦）：等保三级涵盖“安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心”五大技术层面，以及“安全管理制度、安全管理机构、安全管理人员、安全建设管理、安全运维管理”五大管理层面，总计 200 余项具体测评指标。传统依托 Excel 表格逐项打勾，不仅协同效率低下，且无法关联责任人与底层配置截图；
3. 测评机构现场抽检问题整改时限紧迫（30天/60天整改 SLA 易失控）：第三方等保测评机构进场完成现场渗透测试、脆弱性扫描与基线核查后，出具的《测评问题清单与整改建议书》往往包含数十项高危/中危缺陷。由于缺乏刚性的整改时效追踪机制，任务分散在各业务研发线，常因逾期未完成整改而导致测评综合得分低于 70 分甚至被一票否决；
4. 审计底稿与合规证据链散落断裂：等保测评不仅看当前系统防御能力，更极其重视“历史运维与审计留痕”（如 6 个月以上的堡垒机访问日志、第三方渗透测试报告、半年度应急演练记录、季度脆弱性扫描记录）。若证据材料散落在各工程师本地电脑，每次年审测评都必须重新经历痛苦的人工捞取过程。

依托 Notion 灵活的多维数据库架构规范、关系与 Rollup 多层穿透引擎与 Formula 2.0 现代函数语法，企业能够以零代码成本快速搭建起一套资产定级清晰、控制项标准映射、整改工单全链路 SLA 监控与合规证据链持续闭环的企业等保 2.0 合规运营中枢（Cybersecurity MLPS 2.0 Compliance Hub）。

---

等保 2.0 合规运营中枢四维拓扑架构

为确保等保测评“定级精准、自查透明、整改可控、年审无忧”，系统由四大核心业务数据库构成相互嵌套的数据拓扑网络：

┌─────────────────────────────────────────────────────────────┐
│    Notion 企业网络安全等级保护 2.0（等保三级）合规运营中枢   │
└─────────────────────────────────────────────────────────────┘
                                │
        ┌───────────────────────┴───────────────────────┐
        ▼                                               ▼
┌───────────────────────────────┐     ┌───────────────────────────────┐
│ 1. 定级对象与资产拓扑主库     │     │ 2. 等保 2.0 控制项基准规范库  │
│ (DB_MLPS_Target_Systems)      │◄────┤ (DB_MLPS_Security_Controls)   │
│ - 系统名称 / 拟定等级(二级/三级)│     │ - 安全层面 (技术类/管理类)     │
│ - 承载业务重要性 / 部署拓扑   │     │ - 控制大类 (区域边界/计算环境)│
│ - 公安备案号 / 备案证明附件   │     │ - 测评基准要求 / 判定准则     │
│ - Formula 2.0 测评合规总览    │     │ - 涉及责任部门 (运维/安全/HR) │
└──────────────┬────────────────┘     └───────────────┬───────────────┘
               │                                      │
        ┌──────┴──────────────────────────────────────┘
        ▼                                               
┌───────────────────────────────┐     ┌───────────────────────────────┐
│ 3. 测评机构缺陷与整改工单库   │     │ 4. 安全合规证据链与底稿库     │
│ (DB_MLPS_Remediation_Issues)  │◄────┤ (DB_MLPS_Audit_Evidence)      │
│ - 缺陷编号 / 风险等级 (高/中/低)│     │ - 证据类型 (日志/制度/演练)   │
│ - 涉及定级对象 & 控制点双向绑定│     │ - 归档生效日期 / 到期刷新预警 │
│ - 整改责任人 / 计划完成日期   │     │ - 底稿文件附件 / 验证人签署   │
│ - Formula 2.0 整改倒计时 SLA  │     │ - Formula 2.0 证据时效有效性  │
└───────────────────────────────┘     └───────────────────────────────┘

四大数据库核心职责分工：

1. 定级对象与资产拓扑主库（DB_MLPS_Target_Systems）：记录企业在网安部门备案的各个系统单元，关联网络拓扑、域名资产与服务器集群，集中展示各系统的测评综合得分与当前认证状态；
2. 等保 2.0 控制项基准规范库（DB_MLPS_Security_Controls）：将国标 GB/T 22239-2019 技术要求与管理要求解构成结构化词条，作为内部日常自查与外部测评比对的标准字典；
3. 测评机构缺陷与整改工单库（DB_MLPS_Remediation_Issues）：承接第三方测评机构现场发现的漏洞、弱口令、未开启审计、未双因子认证等缺陷，设定 30 天/60 天严格整改 SLA；
4. 安全合规证据链与底稿库（DB_MLPS_Audit_Evidence）：集中沉淀制度红头文件、6 个月日志备份抽样凭证、漏洞扫描报告、应急预案演练记录等测评材料，支持随时调阅复测。

---

核心数据库字段结构与属性配置方案

为实现数据结构的高内聚与自动化联动，根据 Notion 数据库属性规范 设计关键字段：

数据库名	属性名称（Property Name）	属性类型（Type）	业务说明与配置要点
定级对象库	System Name	Title	系统全称与备案代码（如：电商核心交易与结算系统 (Level-3)）
定级对象库	Target Level	Select	等保定级：等保二级（自主保护）、等保三级（监督保护）
定级对象库	Security Controls	Relation	双向关联 DB_MLPS_Security_Controls，统计该系统适用的控制项
定级对象库	Remediation Issues	Relation	双向关联 DB_MLPS_Remediation_Issues，穿透当前挂起的整改工单
定级对象库	Audit Evidence	Relation	双向关联 DB_MLPS_Audit_Evidence，汇总该系统已归档的合规材料
控制项基准库	Control Title	Title	控制项名称（如：8.1.4.1 身份鉴别 - 双因子认证与防暴力破解）
控制项基准库	Security Domain	Select	安全层面：安全计算环境、安全区域边界、安全管理中心 等
控制项基准库	Applicable Level	Multi-select	适用等级：Level 2、Level 3
控制项基准库	Self-Assessment Status	Select	内部自查状态：完全符合、部分符合、不符合、不适用
整改工单库	Issue Code	Title	缺陷编码与标题（如：[SEC-2026-081] 生产库未开启 180 天审计日志）
整改工单库	Risk Severity	Select	风险等级：🔴 高危（一票否决项）、🟠 中危、🟡 低危/建议项
整改工单库	Remediation Assignee	Person	研发或运维整改主负责人
整改工单库	Finding Date	Date	测评机构出具缺陷发现日期
整改工单库	Target Deadline	Date	整改截止日期（高危通常限制 15~30 天内归闭）
整改工单库	Issue Status	Select	流程状态：待分配、整改方案评审、研发修复中、机构复测验证、已归闭
证据链底稿库	Evidence Name	Title	证据材料名称（如：2026Q3 堡垒机 180 天操作日志脱敏归档凭据）
证据链底稿库	Retention Period	Select	保存期限要求：不少于 6 个月（法定要求）、常年归档
证据链底稿库	Evidence Files	Files & media	上传盖章版扫描件、系统界面截屏或报告 PDF

---

Notion Formula 2.0 深度实战：整改 SLA 预警与合规雷达

在等保现场测评结束后，测评机构通常会给予企业一个“整改宽限期”（通常为 30 个工作日，最长不超过 60 天）。若在复测时仍有高危项未闭环，测评机构将出具“差”或“不合格”评级，导致无法在网安完成测评报告终审备案。

借助 Formula 2.0 现代函数语法，我们为系统构建两大核心自动化公式：

1. 整改工单 SLA 动态倒计时与风险状态穿透公式

在 DB_MLPS_Remediation_Issues 数据库中新增公式属性 Formula_Remediation_SLA：

/* Notion Formula 2.0: 整改工单时效 SLA 动态监控与高危警示 */
let(
  status, prop("Issue Status"),
  severity, prop("Risk Severity"),
  deadline, prop("Target Deadline"),
  daysLeft, if(empty(deadline), 0, dateBetween(deadline, now(), "days")),
  
  /* 1. 若工单已闭环通过复测 */
  if(
    status == "已归闭",
    style("✅ 已通过复测归闭", "green", "bold"),
    
    /* 2. 若工单尚未闭环，计算到期情况 */
    if(
      empty(deadline),
      style("⚠️ 未设定整改截止日", "gray"),
      if(
        daysLeft < 0,
        /* 已经严重逾期 */
        style("🚨 严重逾期 " + abs(daysLeft) + " 天！阻断测评通过", "red", "bold"),
        if(
          daysLeft == 0,
          style("🔥 今日截止！必须完成复测提交", "red", "bold"),
          if(
            daysLeft <= 7,
            /* 临期冲刺 */
            style("⏳ 仅剩 " + daysLeft + " 天！" + 
                  if(severity.test("高危"), "【高危一票否决项】请立即升级处理", "请加急自测"), 
                  "yellow", "bold"),
            /* 处于正常窗口期 */
            style("🟢 剩余 " + daysLeft + " 天整改窗口", "green")
          )
        )
      )
    )
  )
)

公式运作解析：

• 通过 let 封装变量，提取状态、严重级别与截止日期；
• 使用 dateBetween(deadline, now(), "days") 动态比对服务器当前时间；
• 逾期直接标红并突出警示 🚨 严重逾期；
• 临期 7 天内针对 高危一票否决项 自动附加升级警示文案，让研发运维团队对重点漏洞一目了然。

---

2. 定级对象整改达标率与等保测评风险雷达公式

在 DB_MLPS_Target_Systems 主库中，需要实时掌握关联的所有整改工单完成度。新增公式属性 Formula_Compliance_Radar：

/* Notion Formula 2.0: 目标系统整改达标率与等保测评风险雷达 */
let(
  allIssues, prop("Remediation Issues"),
  totalCount, allIssues.length(),
  
  /* 筛选已闭环工单 */
  closedCount, allIssues.filter(current.prop("Issue Status") == "已归闭").length(),
  
  /* 筛选高危待办工单 */
  openHighRiskCount, allIssues.filter(
    current.prop("Issue Status") != "已归闭" and 
    current.prop("Risk Severity").test("高危")
  ).length(),
  
  /* 计算达标百分比 */
  progress, if(totalCount > 0, round(closedCount / totalCount * 100), 100),
  
  /* 综合风险判定 */
  if(
    totalCount == 0,
    style("🛡️ 无待整改缺陷（基线健康）", "green", "bold"),
    if(
      openHighRiskCount > 0,
      style("⛔ 阻断风险：尚有 " + openHighRiskCount + " 个高危缺陷未解决！综合进度: " + progress + "%", "red", "bold"),
      if(
        progress == 100,
        style("🎉 全部整改项已闭环（符合复测出具报告标准）", "green", "bold"),
        style("🔄 整改进度: " + progress + "% (" + closedCount + "/" + totalCount + " 已闭环)", "blue")
      )
    )
  )
)

公式运作解析：

• 直接利用 Formula 2.0 原生数组操作 filter() 对双向关联的工单进行过滤计算；
• 若存在未闭环的高危缺陷，直接触发 ⛔ 阻断风险 警示，避免盲目申请复测被退回；
• 进度百分比直观反映整改整体攻坚状态，便于向上汇报安全合规治理里程碑。

---

企业等保 2.0 测评全流程标准化落地 SOP

为确保等保三级顺利取得公安局网安支队发放的《信息系统安全等级保护备案证明》与第三方测评报告，团队应严格按照五步标准作业流程（SOP）协同流转：

┌────────────────────────────────────────────────────────────────────────┐
│             企业网络安全等级保护 2.0 全流程推进标准作业规程 (SOP)      │
└────────────────────────────────────────────────────────────────────────┘
    │
    ├─► Step 1: 系统资产梳理与定级专家评审
    │   盘点公网 IP、域名与微服务边界 ➔ 录入 DB_MLPS_Target_Systems
    │   编写《定级报告》并邀请等保专家评审 ➔ 明确等保二级/三级划分
    │
    ├─► Step 2: 公安机关备案办理与合规底稿留存
    │   向属地网安部门提交备案表与拓扑图 ➔ 取得实体备案证明
    │   扫描上传至 [Notion 附件属性](/guide/databases/database-properties.md) 关联留存
    │
    ├─► Step 3: 等保控制项内部差距自查（Gap Analysis）
    │   对照 DB_MLPS_Security_Controls 200 余项控制点逐条审查
    │   重点检查：密码复杂度策略、访问控制清单、双因子认证、离线备份
    │
    ├─► Step 4: 测评机构现场核验与整改工单敏捷闭环
    │   第三方测评机构进场（渗透、漏扫、访谈）➔ 导入 DB_MLPS_Remediation_Issues
    │   配置 [Formula 2.0 整改时效倒计时](/guide/cheatsheets/formula-reference.md) ➔ 按 [Notion 任务看板视图](/guide/databases/boards.md) 推进研发修复
    │
    └─► Step 5: 现场复测、测评报告出具与归档年审
        测评机构对修复项逐一验证 ➔ 综合得分 ≥ 70 分并出具正式报告
        将全套测评报告与 180 天日志归入 DB_MLPS_Audit_Evidence ➔ 启动下一年定期自查

步骤一：关键资产与数据流图谱定级防呆

1. 统一资产与域名池：切忌漏报边缘业务系统。根据 Notion 数据库架构规范，通过多维关系将所有对外提供服务的云服务器实例（ECS/CVM）与定级系统挂接；
2. 严防“低定高用”法律合规风险：涉及用户个人隐私、敏感财务信息或公用基础设施的关键平台，严格按等保三级申报，切忌为省事定为二级，避免监管行政处罚。

步骤二：技术控制项落地高频检查项（以安全计算环境为例）

1. 身份鉴别与防爆破：登录密码长度不低于 8 位，包含大小写、数字与特殊字符组合；连续输错 5 次锁定登录 15 分钟；管理后台全量开启短信/TOTP 双因子认证；
2. 访问控制与最小权限：遵循最小权限授权原则，停用操作系统及数据库默认账户（如 guest），严禁共享运维账号；
3. 安全审计（180天法定红线）：覆盖到每个用户的关键操作行为；审计记录至少保存 180 天以上；开启日志防篡改与异地转储机制。

---

等保 2.0 协同运维过程中的高频避坑指南

1. 严格隔离生产网络拓扑与密钥凭据权限： 等保测评过程中涉及大量敏感信息（如核心数据库连接地址、白盒审计源码片段、网络拓扑图原件）。依据 Notion 分享与权限控制指南 与 访客访问控制规则，严禁将整个工作区对外公开，只针对外部测评工程师开放限定页面的单项只读或评论权限；
2. 切忌临时抱佛脚清理审计日志： 等保三级现场测评时，测评工程师必查堡垒机和数据库“连续 6 个月历史审计日志”。切勿在测评前夕临时调整日志保留天数，日常运维团队应在 Notion 每日任务与时间线 中设置日志存储水位定期巡检提醒；
3. 测评报告生命周期与年审防脱节： 等保三级系统根据合规要求每年需开展一次测评。在 DB_MLPS_Target_Systems 中建立“下次测评到期日”字段，并结合 Formula 2.0 周期提醒 提前 90 天自动弹出筹备提醒，保障企业网络安全合规资质平稳延续。