📚 课程目录第2章 GRC平台核心数据模型

2. GRC平台核心数据模型

GRC平台能否支撑多框架控制映射，取决于底层数据模型是否把“要求—目标—控制—风险—资产—组织”拆成可独立维护、又可通过关系连接的实体。若把这些概念都塞进一张控制表，后续做跨框架映射时就会出现重复记录、口径冲突和无法追溯的问题。本节围绕实体建模、关系建模与元数据设计三部分展开，并给出可直接参考的建模示例。

一、六个核心实体的职责边界

实体建模的第一步是明确每个实体“回答什么问题”，避免职责重叠。

合规要求（Requirement）：来自外部法规、标准或内部制度的原文条款，回答“谁要求了什么”。例如 ISO 27001 A.5.15、等级保护三级“访问控制”、GDPR 第32条。它是外部输入，通常不可被组织随意改写，只能引用或解释。
控制目标（ControlObjective）：对要求意图的抽象表达，回答“要达到什么状态”。例如“确保只有授权用户可访问信息系统”。一个控制目标可被多个框架要求共享，是跨框架映射的语义枢纽。
控制项（Control）：组织实际落地执行的措施，回答“用什么手段达成目标”。例如“堡垒机统一运维入口并留存操作录像”。控制项是组织自有资产，可被多个控制目标复用。
风险（Risk）：回答“不达成目标会怎样”。包含风险场景、可能性、影响、固有风险与剩余风险。风险与控制目标之间是“威胁目标实现”的关系。
资产（Asset）：回答“保护对象是什么”。包括系统、数据库、服务器、数据资产、人员岗位等，是控制项作用的对象，也是风险影响的载体。
组织单元（OrgUnit）：回答“谁负责”。包括部门、团队、岗位，是控制项的责任主体，也是合规要求的适用范围。

这六个实体构成 GRC 数据模型的骨架。判断建模是否合理，可用一个简单标准：任意一条控制记录，都应能通过关系回答“它满足哪条要求、支撑哪个目标、降低哪个风险、保护哪个资产、由谁负责”。

二、实体间关系建模

实体本身只是节点，真正决定映射能力的是关系。建议采用带类型和方向的有向关系，而不是简单的外键字段。核心关系包括：

Requirement → ControlObjective（refines）：要求细化出控制目标，一条要求可对应多个目标。
ControlObjective → Control（implemented_by）：目标由控制项实现，多对多。
Control → Asset（applies_to）：控制项作用于资产，多对多。
Control → OrgUnit（owned_by）：控制项由组织单元负责，可区分执行方与监督方。
Risk → ControlObjective（threatens）：风险威胁目标实现。
Control → Risk（mitigates）：控制项缓解风险，需带缓解强度或覆盖度。
Requirement → OrgUnit（applicable_to）：要求适用于哪些组织单元。

关系本身也需要元数据，例如映射强度（完全满足/部分满足/不适用）、映射依据、评审人、评审日期、置信度。这些字段决定了映射结果能否被审计和复核。

三、元数据设计：让映射可审计

实体和关系确定后，元数据决定模型能否长期维护。建议按三类设计：

标识类元数据：全局唯一ID、来源系统、版本号、生效日期、失效日期。跨框架映射时，同一控制目标可能被多个框架引用，必须用稳定ID而非名称做关联。

语义类元数据：框架名称、条款编号、条款原文摘要、控制类型（预防/检测/纠正）、成熟度等级、适用范围。这些字段支撑按框架、按控制类型做筛选和统计。

治理类元数据：责任人、评审状态、评审意见、最后更新人、更新原因。多框架映射最容易出问题的地方是“谁改的、为什么改”，治理类元数据是审计追溯的关键。

四、建模示例：一条控制项的完整数据

以下示例展示一条控制项如何通过关系连接六个实体。示例数据为教学假设，非真实测评结果。

Control:
  id: CTL-0042
  name: 堡垒机统一运维入口
  type: 预防性
  status: 已实施
  owner: 信息安全部（OU-003）
  applies_to: [核心业务系统（AST-011）, 数据库集群（AST-012）]

Relations:
  - from: CTL-0042  to: CO-007   type: implements
    strength: 完全满足    basis: 运维操作全量留痕
  - from: CO-007    to: REQ-ISO-A.5.15  type: refines
  - from: CO-007    to: REQ-DJL3-8.1.4  type: refines
  - from: CTL-0042  to: RSK-005   type: mitigates
    coverage: 高          residual: 中
  - from: REQ-DJL3-8.1.4 to: OU-003 type: applicable_to

从这段数据可以看出：一条控制项同时支撑 ISO 27001 和等级保护两个框架的要求，通过共享控制目标 CO-007 实现跨框架映射，而不是为每个框架重复建控制。这正是 GRC 数据模型的核心价值。

五、建模时的常见判断点

控制目标是否要独立建实体：如果只做单框架合规，可以省略；一旦涉及两个以上框架，控制目标是必要的语义枢纽。
关系用外键还是独立关系表：多对多关系必须用独立关系表，才能承载映射强度、依据、评审人等元数据。
资产粒度：过粗（如“全部系统”）会导致控制项无法精确对应；过细（如每台服务器）会带来维护负担。建议按“可独立定级、可独立负责”的粒度划分。
组织单元是否分层：建议保留父子层级，便于按部门汇总合规覆盖率，同时支持岗位级责任到人。

建模完成后，可用一条检查规则验证：任取一条合规要求，应能沿“要求→目标→控制→资产/组织”路径走通；若某条路径断裂，说明模型存在缺口，需要补充关系或调整实体粒度。

本节给出的实体、关系与元数据设计，是后续控制映射、差距分析和合规报告的数据基础。实体边界清晰、关系带元数据、标识稳定，是 GRC 平台能够支撑多框架长期演进的三个前提。