机器学习用于审计日志异常检测的核心是发现偏离正常行为模式的信号，而非简单找错误；需先结构化日志、再特征工程，选用无监督/半监督算法，并强调可解释性与高价值场景优先落地。
审计日志分析用机器学习识别异常，核心不是“找错误”，而是“发现偏离正常行为模式的信号”。传统规则（比如“单日登录失败超5次就告警”）容易漏掉隐蔽攻击或误报周期性业务操作；机器学习则通过学习历史审计日志中的真实行为分布，自动建模什么是“常态”，再定位那些统计上显著偏离的点——比如某账号在非工作时间批量导出敏感表、某个服务账户突然执行大量DDL语句，哪怕每条单独看都符合语法规范。
审计日志要先结构化，再喂给模型
原始审计日志（如Oracle Unified Audit Trail、MySQL general_log、PostgreSQL pgaudit输出）多为文本，含时间戳、用户、操作类型、对象、SQL语句等字段，但格式不统一、含动态值（如IP、ID、时间）。直接扔给模型效果差。必须做两件事：
-
解析与标准化：用正则或专用工具（如Logstash、Drain算法）提取结构化字段。例如将
"2026-07-08T14:22:05Z user=admin op=SELECT obj=salaries WHERE id=123"拆成{"timestamp": "2026-07-08T14:22:05Z", "user": "admin", "op": "SELECT", "obj": "salaries", "where_clause": "id=123"}； -
特征工程：不能只用原始字符串。需构造高信息量特征，例如：
– 用户行为画像：该用户过去7天平均SELECT次数、DDL占比、跨时段操作频次；
– 对象热度：表salaries被访问的频次排名、是否属敏感分类；
– SQL语义特征：使用关键词（EXPORT、UNION SELECT）、嵌套深度、参数化程度（硬编码值越多越可疑）。
选对算法比调参更重要
审计场景通常缺乏标注好的“异常样本”，所以无监督或半监督方法更实用：
- Isolation Forest 或 One-Class SVM：适合检测单点异常，比如某个用户某次操作在多维特征空间中明显孤立（高权限+深夜+大范围DELETE+无审批标记）；
-
Autoencoder（自编码器）：把用户-操作-对象组合序列编码为低维向量，重建误差大的即为异常。对SQL语义漂移（如正常用户突然执行大量
SHOW VARIABLES）敏感； - LSTM/Transformer时序模型：当关注行为序列时有效，例如识别“登录→切换角色→查询薪资表→导出CSV→登出”这一连贯攻击链，单看每步都不违规，但整体模式罕见。
别只看模型输出，要能回溯到业务语义
模型给出“异常分数=0.92”没用，运维和安全人员需要知道“为什么异常”。因此必须配套可解释机制：
- 用SHAP或LIME解释单条预测：显示是
user_role权重最高（从普通员工突变为DBA），还是obj_sensitivity贡献最大（访问了标记为“PII”的表）； - 关联上下文：自动拉取该用户近3次同类操作、该表最近变更记录、对应主机当前CPU/网络状态，辅助判断是真实攻击还是配置失误；
- 支持人工反馈闭环：点击“误报”后，模型应将该样本加入正常类更新边界，避免重复告警。
落地时优先跑通一个高价值小场景
别一上来就想覆盖全部审计日志。从ROI最高的点切入：
- 聚焦
DDL操作（CREATE/DROP/ALTER）：发生频次低、影响大、误报容忍度高； - 监控
特权账号（如DBA、root）的所有操作，而非全员； - 限定
敏感对象范围，例如只分析含salary、ssn、credit_card字段的表访问行为。
用Kibana ML或Python+Scikit-learn两周内就能上线第一个可用模型，比写几十条SQL规则更快见效。
