Wazuh SCA 模块 SQLite 数据库 Schema 深度解析:策略表、检查表与状态管理机制
2026/9/14 15:24:28 网站建设 项目流程

Wazuh SCA 模块 SQLite 数据库 Schema 深度解析:策略表、检查表与状态管理机制

【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuh

Wazuh 的 SCA(Security Configuration Assessment,安全配置评估)模块依赖本地 SQLite 数据库持久化策略元数据与检查结果,这是其跨重启保持合规状态、实现扫描间变更检测的基础。本文基于 Wazuh 仓库中的 数据库 Schema 参考文档,完整梳理sca_policysca_checksca_metadata三张表的字段定义、ECS 字段映射与合规/MITRE 序列化格式,并结合src/wazuh_modules/sca/sca_impl/下的 C++ 源码,说明建表语句的真实来源、字段写入与校验逻辑,以及检查项 checksum 在同步事件中的实际用法。

一、SCA 数据库的定位与作用

SCA 模块使用 SQLite 数据库存储策略(policy)元数据与检查(check)结果。文档明确指出,该数据库承担两个核心职责:

  • 维护安全配置评估状态:作为检查结果(Passed/Failed等)的持久化存储;
  • 支持扫描间变更检测:通过保存上一次扫描结果,与新扫描结果对比,生成 create / update / delete 事件并跟踪结果迁移(如Passed → Failed)。

从源码结构看,SCA 模块的数据库访问统一通过 DBSync 抽象完成。在 sca_impl.cpp 的构造函数中,SecurityConfigurationAssessment会创建一个HostType::AGENTDbEngineType::SQLITE3DbManagement::PERSISTENT的 DBSync 实例——即 Agent 端使用 SQLite 作为持久化存储引擎,三张表的建表 DDL 正是通过GetCreateStatement()注入的。

与 Wazuh Common Schema(WCS)的关系

模块发往 Wazuh indexer 的 SCA 数据遵循 Wazuh Common Schema(WCS)标准格式。文档说明该 Schema 定义文件sca.json位于src/external/indexer-plugins,并在 Agent 构建过程中作为外部依赖下载(make deps)。需要注意:在当前仓库的源码检出中src/external目录为空,sca.json属于构建时拉取的产物,本地克隆后需先执行依赖构建才能看到该文件。

二、策略表 sca_policy:安全策略的元数据

建表语句

CREATE TABLE IF NOT EXISTS sca_policy ( id TEXT PRIMARY KEY, name TEXT, file TEXT, description TEXT, refs TEXT );

这段 DDL 与源码中的POLICY_SQL_STATEMENT常量逐字一致,见 sca_impl.cpp,可直接复制执行。

字段说明

必填类型说明ECS 映射ECS 类型
✔️idTEXT策略唯一标识policy.idkeyword
nameTEXT策略可读名称policy.namekeyword
fileTEXT策略定义文件路径policy.filekeyword
descriptionTEXT策略用途与内容描述policy.descriptiontext
refsTEXT策略外部引用(如 CIS)policy.referenceskeyword

索引id为主键,用于快速定位策略;file上有索引,用于策略文件追踪。

示例数据

INSERT INTO sca_policy VALUES ( 'cis_debian10', 'CIS Debian Linux 10 Benchmark v1.0.0', 'etc/shared/cis_debian10.yml', 'This document provides prescriptive guidance for establishing a secure configuration posture for Debian Linux 10', 'https://www.cisecurity.org/cis-benchmarks/' );

其中file指向的策略 YAML 文件即 Wazuh 随包提供的基线策略,例如仓库 ruleset/sca/ 目录下按发行版与场景组织的cis_debian10.yml等策略定义文件;自定义策略的编写方式见 custom-policies.md。

三、检查表 sca_check:核心结果存储

建表语句

CREATE TABLE IF NOT EXISTS sca_check ( checksum TEXT NOT NULL, id TEXT PRIMARY KEY, policy_id TEXT REFERENCES sca_policy(id), name TEXT, description TEXT, rationale TEXT, remediation TEXT, refs TEXT, result TEXT DEFAULT 'Not run', reason TEXT, condition TEXT, compliance TEXT, mitre TEXT, rules TEXT, regex_type TEXT DEFAULT 'pcre2', version INTEGER NOT NULL DEFAULT 1, sync INTEGER NOT NULL DEFAULT 0 );

与源码中的CHECK_SQL_STATEMENT常量完全一致(sca_impl.cpp),共 17 列。

字段说明与 ECS 映射

必填类型说明ECS 映射ECS 类型
✔️checksumTEXT检查数据的 SHA1 校验和,用于同步checksum.hash.sha1keyword
✔️idTEXT检查项唯一标识check.idkeyword
✔️policy_idTEXT关联策略 ID(外键)policy.idkeyword
nameTEXT检查项简短名称check.namekeyword
descriptionTEXT检查项评估内容的详细说明check.descriptiontext
rationaleTEXT设置该检查项的依据/理由check.rationaletext
remediationTEXT检查失败时的修复步骤check.remediationtext
refsTEXT检查项外部引用check.referenceskeyword
resultTEXT当前评估结果(Passed、Failed、Not run、Not applicable)check.resultkeyword
reasonTEXT结果的解释说明check.reasontext
conditionTEXT检查项适用的逻辑条件(all、any、none)check.conditionkeyword
complianceTEXTJSON 序列化合规对象(见下文格式)check.compliance.*keyword
mitreTEXTJSON 序列化的 MITRE ATT&CK 对象(见下文格式)check.mitre.*keyword
rulesTEXT执行实际检查所用规则的序列化逻辑check.rulestext
regex_typeTEXT内部正则引擎标识N/AN/A
✔️versionINTEGER有状态同步的单调版本号state.document_versionlong
✔️syncINTEGER内部同步标志(1 = 已同步,0 = 仅本地)N/AN/A

索引id主键用于快速查找;policy_id外键维护策略—检查关系;result上有索引以支持按状态过滤;(policy_id, result)复合索引用于策略级结果查询。

结果取值

  • Not run:检查项尚未执行(建表时默认值);
  • Passed:检查通过;
  • Failed:检查失败;
  • Not applicable:检查项不适用于当前系统。

compliance 字段的 JSON 格式

compliance列存储 JSON 序列化对象,将合规框架键映射到标识符字符串数组。文档规定只允许以下键:

cmmcfedrampgdprhipaaiso_27001nis2nist_800_171nist_800_53pci_dsstsc

这一白名单在源码中同样以常量集合ALLOWED_COMPLIANCE_KEYS定义,与文档完全对应,见 sca_policy_parser.cpp。策略解析时ValidateComplianceKeys()会遍历 compliance 对象的所有键:发现白名单之外的键会记录LOG_WARNING日志("Invalid compliance key ... ignoring")并将其从待写入的值中剔除;如果 compliance 既不是对象也不是 null,则整体丢弃并告警,逻辑见 sca_policy_parser.cpp。该函数在解析每个 check 节点后被调用(sca_policy_parser.cpp)。

mitre 字段的 JSON 格式

mitre列存储 JSON 序列化对象,将 MITRE ATT&CK 类别映射到标识符与名称。支持的键为tactictechniquesubtechnique;每个键对应一个含idname两个等长并行数组的对象,同一位置上的名称对应同一位置上的标识符,名称取自 MITRE ATT&CK 官方目录。

checksum 列的生成逻辑

sca_check.checksum并非随机值,而是由检查项的核心属性计算出的 SHA1 校验和。sca_checksum.hpp 的注释说明其基于 check 的 id、policy_id、name、description、rationale 等核心字段计算,返回十六进制字符串;sca_checksum.cpp 实现了对检查数据 JSON 的序列化哈希。写入事件时由 sca_event_handler.cpp 调用sca::calculateChecksum(checkData)生成并填回checksum字段。

示例数据

INSERT INTO sca_check (checksum, id, policy_id, name, description, rationale, remediation, refs, result, reason, condition, compliance, mitre, rules, regex_type, version, sync) VALUES ( 'f1e2d3c4b5a697887766554433221100aabbccdd', '5501', 'cis_debian10', 'Ensure permissions on /etc/ssh/sshd_config are configured', 'The /etc/ssh/sshd_config file contains configuration specifications for sshd', 'The /etc/ssh/sshd_config file needs to be protected from unauthorized changes', 'Run: chmod og-rwx /etc/ssh/sshd_config', 'https://www.cisecurity.org', 'Passed', NULL, 'all', '{"pci_dss":["5.2.1"],"nist_800_53":["14.6"]}', '{"tactic":{"id":["TA0005"],"name":["Stealth"]},"technique":{"id":["T1548"],"name":["Abuse Elevation Control Mechanism"]}}', '[{"type":"file","path":"/etc/ssh/sshd_config","permissions":"600"}]', 'pcre2', 1, 1 );

四、表关系与元数据表

策略—检查的 1:N 关系

  • 关系类型:一对多,每个策略包含多个检查项;
  • 外键sca_check.policy_id引用sca_policy.id
  • 级联:删除某个策略时,其全部关联检查项随之删除。

sca_metadata 表:模块级运行状态

CREATE TABLE IF NOT EXISTS sca_metadata ( key TEXT PRIMARY KEY, value INTEGER );

与源码中的METADATA_SQL_STATEMENT常量一致(sca_impl.cpp)。

必填类型说明
✔️keyTEXT元数据条目的唯一标识
valueINTEGER与键关联的数值

当前文档记录的键

  • last_integrity_check:上次完整性检查的 Unix 时间戳(秒)。

示例数据

INSERT INTO sca_metadata VALUES ('last_integrity_check', 1733316000);

源码中除last_integrity_check外还定义了另一个元数据键常量SCA_FIRST_SYNC_COMPLETED_METADATA_KEY("first_sync_completed",见 sca_impl.cpp),用于在重启后判断首次同步是否已完成——从源码结构看,该键同样以key/value形式落在sca_metadata表中,用于协调首次扫描完成后的同步行为。

五、状态管理与变更检测

文档将状态管理归纳为两部分:

变更检测——数据库使以下流程成为可能:

  1. 存储上一次的检查结果;
  2. 将新扫描结果与已存状态比较;
  3. 生成相应事件(create、update、delete);
  4. 跟踪结果迁移(如Passed → Failed)。

结果持久化

  • 结果在 Agent 重启后依然保留;
  • 数据库是检查状态的唯一事实来源(source of truth);
  • 支持合规状态的历史追踪。

从源码看,事件生成与同步链路集中在 sca_event_handler.cpp:该文件按列清单(checksumcheckpolicy等)构造事件,并在上报前把本地扁平的checksum字段改写为 WCS 要求的嵌套结构{"hash": {"sha1": <sha1>}}(见 sca_event_handler.cpp)——这正是sca_check.checksum列与 ECS 映射checksum.hash.sha1在落库值和上报值之间的对应关系。解析阶段的字段校验(如condition只接受any/none/all,见 ValidateConditionString)与合规键白名单过滤共同保证了写入数据库的数据在结构上是干净的。相关行为可由单元测试 sca_policy_parser_test.cpp(含fedramp/iso_27001/nist_800_171等合规键的解析用例)与 sca_test.cpp(含三张表的建表 DDL)复现验证。

六、实践建议

  • 排查检查结果异常:直接查询sca_check表中resultreason列,利用result索引可高效过滤失败项;按策略维度统计可命中(policy_id, result)复合索引;
  • 编写自定义策略时:compliance 键务必使用白名单内的十种框架键,否则解析器会告警并丢弃该键(见 sca_policy_parser.cpp);MITRE 对象需保证idname数组等长且位置对应;
  • 理解数据去向:本地 SQLite 是 Agent 端事实来源,经 DBSync 与同步协议上报后按 WCS Schema(sca.json)落入 indexer,字段一一对应check.*policy.*state.document_version等 ECS 路径。

综上,Wazuh SCA 的数据库 Schema 以三张表构成"策略—检查—元数据"的最小完备结构:sca_policy描述"评什么",sca_check记录"评到哪、结果如何",sca_metadata追踪"模块运行到哪一步";配合 checksum 同步机制与结果持久化,SCA 模块得以在多次扫描与 Agent 重启之间维持一致的合规状态。

【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuh

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询