3. SOC总体架构设计
SOC总体架构设计不是把设备堆在一起，而是把“谁来看、看什么、怎么判、怎么处置、数据怎么留”这五件事拆成五个相互咬合的架构层，再逐层收敛到可落地的建设清单。技术架构决定能力边界，组织架构决定责任归属，流程架构决定事件如何流转，数据架构决定证据链是否完整，平台架构决定前四者能否被统一承载。五者缺一，SOC就会退化成“告警转发台”或“日志仓库”。
一、五层架构的定位与依赖关系
分层设计的关键是明确每层的输入、输出和约束。技术架构回答“用什么采集、检测、响应”，输出的是探针清单、检测规则集和响应动作库；组织架构回答“谁在什么时段负责哪一类事件”，输出的是角色矩阵与值班表；流程架构回答“事件从产生到关闭经过哪些状态”，输出的是SOP与升级路径；数据架构回答“原始日志如何变成可检索、可关联、可取证的数据资产”，输出的是数据模型、保留策略与质量规则；平台架构回答“上述能力运行在什么底座上”，输出的是计算、存储、编排与接口规范。
依赖方向是：平台架构支撑数据架构，数据架构喂养技术架构的检测能力，技术架构产生的事件进入流程架构，流程架构的每一步动作必须落到组织架构的角色上。因此设计顺序通常不是从平台开始，而是从“业务风险与合规要求”反推：先确定必须监测的资产与威胁场景，再决定数据采集范围，最后才选平台规模。
二、技术架构：从资产覆盖到检测能力
技术架构的落地方式是“资产—场景—探针—规则”四步映射。先梳理资产台账，按重要性分级；再针对每类资产列出必须监测的威胁场景；然后为每个场景选择探针类型（主机EDR、网络NDR、流量镜像、应用日志、云审计、身份认证日志等）；最后为每个探针定义检测规则和响应动作。
例如，针对“域控服务器”这一关键资产，威胁场景包括暴力破解、票据攻击、异常登录、权限提升。对应探针为Windows安全事件日志、EDR、域控审计日志；检测规则可设为：同一源IP在5分钟内失败登录超过10次触发“暴力破解”告警，优先级P2；域管账号在非维护时段登录触发“异常登录”告警，优先级P1。响应动作库中，P1事件自动触发账号临时锁定并通知二线，P2事件仅生成工单由一线核实。这样技术架构就不是设备清单，而是可执行的检测能力矩阵。
三、组织架构：角色矩阵与值班模型
组织架构的核心是“事件分级—角色匹配—响应时限”三者对齐。常见角色包括：一线监控员（7×24小时值守，负责告警初筛、工单创建、已知事件处置）、二线分析员（负责深度分析、关联研判、升级决策）、三线专家（负责复杂攻击溯源、取证、规则优化）、SOC经理（负责运营指标、资源协调、跨部门沟通）。
值班模型需明确：一线每班至少2人，覆盖三班倒；二线在工作时段在线，非工作时段On-Call，响应时限P1不超过15分钟、P2不超过30分钟、P3不超过4小时。角色矩阵应写成表格，明确每个角色对每类事件的“负责/参与/知会”关系，避免出现“告警来了没人认领”或“所有人都能关单”的失控状态。
四、流程架构：事件状态机与升级路径
流程架构建议用状态机描述，而不是线性步骤。事件状态包括：新建、已分派、分析中、已遏制、已恢复、已关闭、误报关闭。每个状态之间的迁移条件必须明确，例如“分析中→已遏制”的条件是确认恶意行为并执行了隔离动作；“已恢复→已关闭”的条件是业务验证正常且证据已归档。
升级路径要写清触发条件：当一线在30分钟内无法判定事件性质时，自动升级二线；当确认涉及核心数据泄露或勒索软件时，立即升级三线并启动应急响应。流程架构的输出物是SOP文档和工单字段定义，工单中必须包含事件ID、来源探针、资产、优先级、当前状态、处置动作、证据链接和关闭原因。
五、数据架构：从原始日志到可取证数据资产
数据架构要解决四个问题：采什么、怎么标准化、存多久、怎么关联。采集范围应覆盖网络流量、终端日志、应用日志、身份认证、云平台审计、威胁情报六类。标准化采用统一字段模型，例如将不同来源的登录日志统一映射为：时间戳、源IP、目标资产、账号、动作、结果、原始日志ID。
保留策略按合规和取证需求分层：热数据（近30天）保留在高速存储供实时检索；温数据（31～180天）保留在低成本存储供关联分析；冷数据（181天～1年或更长）归档供取证。质量规则包括：日志延迟不超过5分钟、字段完整率不低于98%、时间戳统一为UTC+8、重复日志去重率不低于99%。这些指标应作为数据架构的验收标准。
六、平台架构：承载与编排
平台架构通常包括采集层、传输层、存储层、计算层、编排层和展示层。采集层部署探针和日志代理；传输层使用消息队列缓冲峰值；存储层区分热、温、冷；计算层运行关联规则、机器学习检测和富化任务；编排层通过SOAR执行响应动作；展示层提供统一工作台。平台选型时，先按日均日志量（EPS）和峰值倍数估算资源，例如日均50亿条日志、峰值3倍，则消息队列和计算层需按峰值容量设计，避免告警延迟。
最后需要强调，五层架构不是一次性设计完成的，而是随运营数据持续迭代。每月复盘告警准确率、平均响应时间、数据完整率，反推哪一层需要调整。技术架构的规则要随攻击手法更新，组织架构的值班模型要随事件量调整，流程架构的升级阈值要随误报率优化，数据架构的保留策略要随合规要求变化，平台架构的容量要随日志增长扩容。只有把架构设计当成持续运营动作，SOC才能真正从“建成”走向“用好”。