3. SOC工单系统核心数据模型

SOC 工单系统如果只把“工单”当成一张待办表，很快就会在真实运营中失效：同一个攻击事件被拆成多张工单后无法合并，同一台主机反复告警却查不到历史处置，值班人员换班后接手人不知道前一位分析师的判断依据。这些问题的根源不是流程设计不好，而是数据模型没有把工单、事件、资产、人员四类实体及其关系定义清楚。本节围绕这四类实体展开建模，重点说明它们各自承载什么字段、通过什么关系连接、以及这些关系在工单流转中如何被实际使用。

四类实体的职责边界

事件实体（Event / Incident）描述“发生了什么”。它来自 SIEM、EDR、NDR、云审计等检测源，核心字段包括事件 ID、检测规则或告警名称、首次与末次发生时间、严重级别、攻击阶段（如初始访问、横向移动）、涉及的源/目的 IP 与账号、原始日志引用。事件是客观事实的记录，不因是否有人处理而改变。

工单实体（Ticket）描述“我们决定怎么处理”。它由事件触发或人工创建，核心字段包括工单号、标题、优先级、状态（新建/处理中/待确认/已关闭）、SLA 截止时间、处置结论、关联事件 ID。工单是人的动作载体，同一事件可以产生多张工单（例如“隔离主机”和“重置账号”分属不同执行团队），因此工单与事件是多对一关系。

资产实体（Asset）描述“被影响的对象”。核心字段包括资产 ID、主机名、IP、资产类型（服务器/终端/网络设备/云实例）、业务系统归属、责任人、重要性等级、是否暴露在互联网。资产是连接事件与业务影响的桥梁：同样一条“可疑登录”告警，落在核心数据库服务器和落在测试机上，处置优先级完全不同。

人员实体（Person）描述“谁在处理、谁负责”。核心字段包括人员 ID、姓名、角色（一线分析师/二线/应急响应/资产责任人）、技能标签、值班班次、联系方式。人员既可以是工单的处理人，也可以是资产的负责人，这两种身份在模型中必须区分。

实体之间的关系建模

四类实体不是孤立的表，而是通过明确的关系连接成一张可查询的网络。关键关系包括：

• 事件—资产（多对多）：一个事件可能涉及多台资产（如横向移动波及 5 台主机），一台资产也可能在多个事件中出现。通过中间表 event_asset 记录“事件 ID + 资产 ID + 在该事件中的角色（攻击源/受害/跳板）”。
• 工单—事件（多对一）：工单表直接持有 event_id 外键，保证任何工单都能回溯到触发它的事件。
• 工单—人员（多对多）：一张工单可能有处理人、复核人、通知对象多个角色，通过 ticket_person 表记录“工单 ID + 人员 ID + 角色”。
• 资产—人员（多对一）：资产表持有 owner_id，指向该资产的责任人，用于自动通知和升级。

这四组关系决定了工单系统能否回答三个高频问题：这张工单从哪来（事件）、影响什么（资产）、该找谁（人员）。

关系建模在工单流转中的实际作用

把关系落到具体操作上，才能看出模型的价值。假设 SIEM 在 10:02 产生一条告警：rule_name = "Suspicious PowerShell EncodedCommand"，severity = high，src_ip = 10.20.3.45，account = svc_backup。系统按以下顺序使用数据模型：

1. 通过 event_asset 关系，用 src_ip 反查资产表，命中资产 asset_id = SRV-DB-07，criticality = 核心，owner_id = P-102。
2. 根据资产重要性，工单优先级自动从“中”提升为“高”，SLA 截止时间设为 4 小时（示例规则：核心资产高危事件 4 小时，普通资产 24 小时）。
3. 创建工单 INC-20240612-0031，写入 event_id 外键，状态置为“新建”。
4. 通过 ticket_person 关系，将工单分配给当前值班的一线分析师 P-201，同时把资产责任人 P-102 加入通知列表。
5. 分析师处置后填写结论“确认恶意，已隔离主机并重置 svc_backup 凭据”，工单状态流转为“待确认”，由二线 P-305 复核后关闭。

整个过程中，工单系统不需要人工去查“这台机器是谁的”“这个账号属于谁”，因为关系已经在模型中定义好。反过来，如果缺少资产实体或人员实体，工单就只能停留在“有一条告警待处理”，无法自动定级、无法找到责任人、也无法统计“某业务系统本月被攻击多少次”。

常见建模误区

第一个误区是把事件和工单合并成一张表。这样做的直接后果是：一个事件需要两个团队分别处置时，只能复制记录，导致同一事件出现多条“事实”，统计口径混乱。正确做法是事件表只记录检测事实，工单表记录处置动作，通过外键关联。

第二个误区是资产表只存 IP。IP 会变化、会复用，仅靠 IP 关联会导致“昨天是数据库服务器，今天变成测试机”的错配。资产表应以稳定的 asset_id 为主键，IP 作为可更新的属性字段，并在事件关联时记录关联时间点。

第三个误区是人员只用姓名字符串。姓名会重复、会离职、会换班，必须用 person_id 作为外键，姓名仅作为展示字段。同时要把“处理人”和“资产责任人”两种角色分开，前者是动态的工单分配结果，后者是相对稳定的资产归属关系。

第四个误区是忽略关系表的时间维度。工单与人员的分配关系、事件与资产的关联关系都可能随时间变化，建议在关系表中增加 created_at 和 ended_at，这样既能还原“当时是谁在处理”，也能支持历史审计。

最小可用模型示例

如果从零开始搭建，可以先落地下面这组核心表结构（字段为示例，可按实际检测源调整）：

event(event_id PK, rule_name, severity, first_seen, last_seen, src_ip, dst_ip, account, raw_log_ref)
ticket(ticket_id PK, title, priority, status, sla_deadline, conclusion, event_id FK)
asset(asset_id PK, hostname, ip, asset_type, criticality, business_system, owner_id FK)
person(person_id PK, name, role, skill_tags, shift, contact)
event_asset(event_id FK, asset_id FK, role_in_event, created_at)
ticket_person(ticket_id FK, person_id FK, role_in_ticket, assigned_at, ended_at)

这六张表已经能支撑“告警触发工单、工单自动定级、按资产责任人通知、按值班表分配、处置结论回写事件”这条最小闭环。后续再根据运营需要扩展攻击链阶段、处置动作库、SLA 升级规则等字段，而不是一开始就把模型做得过重。

判断模型是否够用，可以用一个简单标准检验：给定任意一张工单，能否在不查外部表格的情况下，通过关系链回答“它由哪个事件触发、影响哪些资产、这些资产归谁负责、当前由谁处理、SLA 还剩多久”。如果这五个问题都能沿关系查到，说明四类实体及其关系已经建模到位。