WuTongDB 审计功能指南：配置与性能优化详解

引言

背景

在数据驱动的商业环境中，数据库安全性与合规性管理正变得越来越重要。随着企业对数据的依赖不断增强，如何有效追踪、记录并分析数据库中的操作行为，成为保障数据安全和满足行业合规需求的核心课题。数据库审计功能不仅是企业防范内部威胁、满足外部法规要求的重要手段，还能够通过分析操作模式，为系统优化和性能调优提供重要参考。

问题

然而，传统数据库审计方案在面对现代分布式、高并发场景时，往往会遇到以下挑战：

1. 性能瓶颈：审计日志的实时写入和检索可能导致系统性能下降，尤其是在大规模并发操作下。
2. 日志管理复杂性：分布式架构中，如何集中存储和管理跨节点的审计日志是一个技术难点。
3. 配置灵活性不足：部分数据库审计功能的策略配置不够灵活，难以满足多样化的审计需求。

目标

作为一款云原生分布式（OLAP）数据库，WuTongDB 针对上述问题提供了高效的解决方案。其审计功能不仅支持灵活的策略配置和分布式日志管理，还能够在多活环境中实现实时记录与分析，从而为企业在高并发和复杂环境下的数据库安全管理提供了有力支持。本文的目标是：

1. 解析 WuTongDB 审计功能的核心机制：帮助读者了解其日志管理流程与技术架构。
2. 提供配置与优化方法：通过详细的参数设置与优化策略指导，确保审计功能高效运行。
3. 探索高级应用场景：介绍审计功能在多集群环境和实时响应中的使用建议。

内容简介

本文将分为以下几部分展开：

• 第1章：审计功能的基础机制与日志管理流程。
• 第2章：WuTongDB 审计功能的配置方法，包括日志存储与策略设置。
• 第3章：性能优化策略，涵盖异步写入、压缩存储与分层管理等技术手段。
• 第4章：高级使用指南，聚焦多集群审计管理与第三方工具集成。
• 第5章：总结与未来展望，讨论 WuTongDB 审计功能的潜在扩展方向。

---

第1章 审计功能与机制

1.1 审计功能概述

数据库审计是保障数据安全和满足合规要求的重要功能。通过记录用户行为、系统事件和操作结果，数据库审计为企业提供了行为追踪、事件回溯和安全监控的能力。WuTongDB 的审计功能基于云原生分布式数据库架构设计，提供高效、灵活的操作记录，同时最大限度降低对系统性能的影响。

1.1.1 数据库审计的目标

数据库审计的核心目标包括以下几个方面：

1. 行为追踪

   • 实时记录数据库用户的操作行为，包括 SQL 查询、数据修改和系统登录退出等，以便在必要时回溯操作细节。

2. 合规支持

   • 满足行业法规（如 GDPR、SOX 法案）的要求，生成详细的审计日志，为合规检查提供依据。

3. 安全监控

   • 识别异常操作，如频繁的登录失败、未经授权的敏感数据访问，并及时告警。

4. 性能优化

   • 通过分析审计日志中的操作模式，为数据库优化（如索引、分区策略）提供数据支持。

1.1.2 WuTongDB 审计功能的特点

WuTongDB 的审计功能兼顾全面性和高性能，主要具有以下特点：

1. 多种事件类型全面覆盖
   WuTongDB 支持记录以下类型的事件：

   • 数据操作（DML）：记录 SELECT、INSERT、UPDATE、DELETE 等操作。
   • 数据定义（DDL）：记录 CREATE TABLE、ALTER TABLE、DROP TABLE 等数据库结构操作。
   • 数据控制（DCL）：记录权限变更、角色分配等操作。

   • 系统事件：

     • 包括用户登录、退出、服务启动/停止等。
     • 系统配置变更，如审计策略和参数调整。
   • 高级操作：记录存储过程调用、函数执行等复杂操作。

2. 灵活的审计策略配置

   • 范围选择：支持只记录特定表、特定用户的操作。
   • 类型选择：允许用户选择特定操作类型进行记录，例如仅记录 DDL 操作。
   • 动态调整：通过审计中心，用户可以随时修改审计策略，实时生效。

3. 分布式架构支持

   • 日志一致性：多活架构下，审计模块保证分布式节点日志的一致性和完整性。
   • 滚动日志机制：日志按大小（默认 6MB）或时间自动分割，适配高并发写入。

4. 实时性与可扩展性

   • 实时记录并生成审计日志，用于实时监控和分析。
   • 支持与 Elasticsearch 集成，通过 Kibana 实现日志的可视化分析。

1.1.3 审计功能的典型应用场景

1. 安全事件追踪

   • 记录对敏感数据表的访问行为，例如财务数据查询，定位潜在内部威胁。

2. 合规性审计

   • 满足金融、医疗等行业合规要求，生成定期操作记录报告，提供外部审计依据。

3. 异常行为监控

   • 捕获并记录异常行为（如频繁登录失败或超权限操作），结合告警系统及时响应。

4. 操作分析与优化

   • 通过日志分析，发现高频查询或热点表，优化索引与分区策略。

5. 跨节点安全审查

   • 在分布式环境中，通过集中化存储的审计日志，分析跨节点的操作行为一致性。

1.2 审计机制的核心原理

WuTongDB 审计机制基于分布式架构设计，通过高效的数据记录和灵活的日志管理实现操作行为的追踪与分析。

1.2.1 审计机制的总体工作流程

1. 事件捕获

   • 审计模块拦截数据库操作事件，捕获用户身份、操作类型、目标对象和操作结果等信息。
   • 支持针对敏感表、字段的精准事件捕获。

2. 事件分类与过滤

   • 审计模块根据配置的策略分类和过滤事件，减少日志冗余：

     • 按用户角色过滤。
     • 按操作类型过滤（如仅记录 WRITE 操作）。

3. 日志格式化与存储

   • 标准化日志条目，包含以下字段：

     • 时间戳、用户、IP 地址、操作类型、目标对象、操作结果（如错误代码）。
   • 支持本地存储和分布式存储（如 HDFS）。

4. 日志管理

   • 日志轮转：单个日志文件限制为 6MB，超过后自动生成新文件。
   • 日志压缩：历史日志支持 gzip 压缩，节省存储空间。
   • 自动清理：定期清理历史日志，避免磁盘空间不足。

1.2.2 审计日志的存储与格式

1. 存储位置

   • 默认路径为数据库节点的 /audit 目录，可通过审计中心修改路径。

2. 日志格式

   • 日志以标准字段记录，格式如下：

     TIMESTAMP | USERNAME | IP_ADDRESS | OPERATION | OBJECT | RESULT

3. 分区存储

   • 按日期或事件类型分区存储日志，提高检索效率。

1.2.3 审计性能优化机制

1. 异步日志写入

   • 避免同步写入的性能瓶颈，支持日志批量处理。

2. 分区存储与检索优化

   • 按事件类型或时间分区存储，提升日志查询效率。

3. 轻量级事件捕获

   • 直接过滤无关事件，降低系统负载。

1.2.4 分布式环境下的审计一致性保障

1. 本地记录

   • 每个节点独立记录本地事件，防止网络故障导致数据丢失。

2. 日志同步与集中管理

   • 支持通过分布式存储系统（如 HDFS）实现集中管理。

3. 故障恢复与重试

   • 节点故障后，审计模块会自动恢复并补充丢失的日志。

---

第2章 审计功能的基础配置

2.1 启用与关闭审计功能

WuTongDB 的审计功能默认处于关闭状态，用户需要通过配置参数启用审计模块，并根据需求指定记录的操作类型。启用或关闭审计功能后，需重启数据库主节点。以下是详细的操作步骤。

2.1.1 启用审计功能

1. 加载审计模块

   配置 session_preload_libraries 参数以启用审计模块：

   oushudb config -c session_preload_libraries -v pgaudit

2. 设置审计操作类型

   使用 pgaudit.log 参数指定需要记录的操作类型，支持以下取值（可用逗号分隔多个值）：

   • DDL：记录表定义操作（如 CREATE TABLE、DROP TABLE）。
   • FUNCTION：记录存储过程调用。
   • MISC：记录其他操作（如 FETCH、SET）。
   • READ：记录读取操作（如 SELECT）。
   • WRITE：记录写入和修改操作（如 INSERT、UPDATE）。
   • ALL：记录所有操作类型。
   • NONE：禁用审计。

   示例：启用对读取、写入和表定义操作的审计：

   oushudb config -c pgaudit.log -v 'READ,WRITE,DDL'

3. 重启数据库服务

   修改配置后需要重启数据库主节点使配置生效：

   oushudb restart allmains

2.1.2 关闭审计功能

1. 禁用审计模块

   清空 session_preload_libraries 参数：

   oushudb config -c session_preload_libraries -v ''

2. 禁用所有审计记录

   将 pgaudit.log 参数设置为 NONE：

   oushudb config -c pgaudit.log -v 'NONE'

3. 重启数据库服务

   同样需要重启服务以应用更改：

   oushudb restart allmains

2.1.3 配置注意事项

1. 支持的审计类型

   类型	说明
   DDL	记录表定义操作（如 CREATE、DROP）。
   FUNCTION	记录存储过程调用操作。
   MISC	包括 FETCH、CHECKPOINT 等。
   READ	数据读取操作，如 SELECT。
   WRITE	数据写入与修改操作，如 INSERT。
   ALL	记录所有操作类型。
   NONE	禁用审计功能。

2. 动态加载支持

   WuTongDB 当前不支持动态加载审计模块，每次修改审计参数后都需重启主节点。

3. 性能影响

   启用审计功能可能增加数据库的磁盘 IO 开销，建议按需配置审计类型，避免记录过多不必要的操作。

4. 日志存储规划

   确保存储路径有足够空间，特别是高并发场景下生成的日志文件可能较多。建议结合日志轮转和清理策略（详见 2.3）进行管理。

2.2 审计策略的配置与优化

WuTongDB 提供了灵活的审计策略配置功能，支持按表、按用户、按操作类型等多维度定义审计规则。以下是详细的策略配置说明。

---

2.2.1 配置审计类型

通过参数 pgaudit.log 定义需要记录的操作类型。支持以下取值：

类型	说明
DDL	表定义操作，如 CREATE、DROP、ALTER。
FUNCTION	存储过程调用。
MISC	包括 FETCH、CHECKPOINT、SET 等操作。
MISC_SET	设置角色的操作（如 SET ROLE）。
READ	数据读取操作，如 SELECT 和 COPY。
ROLE	权限相关操作，如 GRANT、REVOKE。
WRITE	数据写入与修改操作，如 INSERT、UPDATE。
NONE	禁用审计记录。
ALL	记录所有类型的操作。

配置示例：

oushudb config -c pgaudit.log -v 'READ,WRITE,DDL'

2.2.2 配置表级别审计

通过参数 pgaudit.log_relation 控制是否开启表级别审计：

• 取值：TRUE（开启），FALSE（关闭），默认值为 FALSE。

• 示例：开启表级别审计：

  oushudb config -c pgaudit.log_relation -v TRUE

2.2.3 针对用户的审计配置

使用 ALTER ROLE 为特定用户设置审计策略：

• 示例：为用户 user1 配置审计 DDL 和 READ 操作：

  ALTER ROLE user1 SET pgaudit.log = 'DDL,READ';

2.2.4 策略优化建议

1. 减少冗余记录

   • 按需选择审计类型，避免启用无关的记录。例如，只记录写操作：

     oushudb config -c pgaudit.log -v 'WRITE'

2. 动态调整策略

   • 根据业务高峰期和低峰期动态调整审计策略。在高峰期仅记录关键事件，低峰期恢复全面审计。

3. 分布式场景优化

   • 对不同节点或用户设置独立的审计策略，均衡系统开销。

2.2.5 SQL 审计服务

WuTongDB 提供了通过 审计中心 新增 SQL 审计服务的功能，用户可以通过以下步骤完成配置：

1. 进入审计中心

   • 登录 WuTongDB 管理平台，进入 审计中心 模块。

2. 配置审计项

   • 在审计中心界面，选择需要审计的操作类型（如 READ、WRITE、DDL）。

3. 选择集群

   • 从可用集群列表中选择目标集群，以启用审计服务。

4. 配置采集与存储

   • 设置日志存储路径和采集规则：

     • 支持存储在本地或分布式存储。
     • 可选择 Elasticsearch 集成进行日志存储与分析。

5. 确认基础信息

   • 核对配置项后保存，完成服务新增。

2.3 日志管理与存储优化

WuTongDB 提供了完善的日志管理功能，包括日志存储路径设置、保存时长配置、日志导出等多种操作，帮助用户高效维护审计日志文件，避免存储瓶颈并提升分析效率。部分操作需要通过 审计中心 完成。

2.3.1 日志存储路径与命名规则

1. 默认存储路径：

   • 审计日志存储在系统默认路径下，路径可通过环境变量 ${OUSHUDB_LOG_PATH} 查看：

     source /usr/local/oushu/oushudb/oushudb_path.sh
     echo ${OUSHUDB_LOG_PATH}

   • 审计日志文件存放在子目录 /audit 下。

2. 日志文件命名规则：

   • 默认命名格式为：audit-${timestamp}.csv，其中 timestamp 是日志文件创建的时间戳。

3. 存储路径修改：

   • 用户可以通过 审计中心 配置日志存储路径，以适应特定的存储需求。

2.3.2 日志保存时长设置

1. 功能描述：

   • 日志保存时长决定了系统保留日志文件的时间，超过时长的日志将自动删除，以避免占用过多存储空间。

2. 默认设置：

   • 系统默认保存最近 30 天的日志记录。

3. 修改保存时长：

   • 通过 审计中心 界面调整日志的保存周期：

     • 进入审计中心模块，选择“日志设置”。
     • 指定所需的日志保存时长（如 90 天）。

   • 也可通过命令行修改：

     oushudb config -c log_retention_period -v 90

2.3.3 日志导出

1. 功能描述：

   • 为满足外部分析或存档需求，WuTongDB 支持将审计日志导出为 CSV 或 JSON 格式文件。

2. 导出操作：

   • 在 审计中心 中，选择需要导出的日志记录：

     • 筛选日志范围（如按时间段、操作类型等）。
     • 点击“导出”按钮，生成文件并下载。

   • 导出的文件命名示例：

     audit-2024-01-01.csv

3. 导出用途：

   • 外部日志分析工具（如 ELK）。
   • 长期存档以满足审计和合规需求。

2.3.4 与 Elasticsearch 集成

1. 功能描述：

   • WuTongDB 支持通过 Elasticsearch 存储和分析审计日志，为用户提供高效的日志管理和检索能力。

2. 配置方法：

   • 在 审计中心 配置审计日志的存储为 Elasticsearch 索引。
   • 使用 Kibana 工具可视化日志数据，包括时间分布、操作类型统计和用户行为分析。

2.3.5 日志管理优化建议

1. 定期清理历史日志：

   • 为避免存储空间耗尽，建议定期清理不再需要的历史日志。

   • 清理命令示例：

     find ${OUSHUDB_LOG_PATH}/audit -type f -mtime +30 -exec rm {} \;

2. 压缩存储：

   • 对于长期保存的日志，启用压缩功能减少磁盘占用。

   • 示例：

     gzip ${OUSHUDB_LOG_PATH}/audit/*.csv

---

第3章 审计性能优化策略

3.1 审计性能挑战与常见问题

WuTongDB 的审计功能为数据库操作提供了强大的记录和追踪能力，但在高并发和大规模操作场景下，也可能对系统性能产生一定的影响。以下是审计功能在实际使用中的性能挑战及其常见问题：

3.1.1 高并发场景下的性能影响

1. 日志写入的磁盘 I/O 压力

   • 审计功能需要实时记录操作日志，尤其是在高并发的读写场景中，频繁的磁盘写入可能对数据库性能产生额外开销。
   • 表现：操作延迟增加，磁盘使用率显著上升。

2. 大批量操作的日志处理

   • 批量操作（如 COPY 导入数据或批量更新）会生成大量日志记录。
   • 表现：日志文件增长迅速，可能导致存储空间不足。

3.1.2 审计日志存储管理的复杂性

1. 日志文件过多导致检索困难

   • 当日志文件数量增多，检索和分析日志可能变得缓慢。
   • 表现：在日志文件中查找特定记录耗时增加。

2. 存储空间占用

   • 如果没有配置日志轮转或清理策略，长期保存的审计日志可能占用大量磁盘空间。
   • 表现：磁盘空间耗尽，影响正常数据库操作。

3.1.3 配置不当导致的资源消耗

1. 不必要的审计内容记录

   • 记录所有操作（如 ALL）可能导致不必要的日志生成。
   • 表现：生成的日志大多是无关操作，导致系统资源浪费。

2. 审计规则配置过细

   • 表级别审计（pgaudit.log_relation = TRUE）若应用于高频访问的表，可能显著增加日志生成量。
   • 表现：数据库性能下降，日志文件过多。

3.1.4 多节点环境中的一致性问题

1. 分布式日志记录

   • 在多节点分布式架构中，审计日志分散存储可能导致操作记录不完整或管理复杂。
   • 表现：跨节点的审计日志无法轻松合并或查询。

2. 日志同步延迟

   • 如果采用集中式存储，节点与中央日志服务器之间的同步可能出现延迟。
   • 表现：实时日志分析滞后。

3.2 核心优化策略

为了降低 WuTongDB 审计功能对性能的影响，并提升日志管理效率，以下是针对常见性能挑战的优化策略。这些策略涵盖日志写入优化、存储管理改进以及分布式场景的审计配置。

3.2.1 异步写入日志

在高并发场景下，实时写入审计日志可能导致磁盘 I/O 压力增加。采用异步写入可以缓解这一问题。

1. 原理：

   • 将日志写入操作从数据库主线程中分离，通过后台线程异步写入，降低对业务操作的阻塞。

2. 配置方法：

   • 启用异步写入：

     log_statement = 'all'
     logging_collector = on
     log_destination = 'csvlog'
     log_directory = '/path/to/audit_logs'
     log_rotation_size = '6MB'
     log_rotation_age = '1d'

3. 适用场景：

   • 高并发的业务查询场景。
   • 日志文件写入频繁但不要求实时分析的场景。

3.2.2 日志压缩与分区存储

日志压缩和分区存储可以减少磁盘空间使用并提高检索效率。

1. 日志压缩：

   • 启用日志文件压缩：

     log_compression = on
     log_archive_command = 'gzip %p'

   • 将历史日志文件压缩后存储，可减少磁盘使用量。

2. 分区存储：

   • 按事件类别或时间对日志文件进行分区存储。

     • 按时间分区：每日生成一个日志文件：

       log_filename = 'audit_log_%Y-%m-%d.csv'

     • 按事件类型分区：单独记录 DML 和 DDL：

       CREATE TABLE dml_logs PARTITION OF audit_logs FOR VALUES IN ('INSERT', 'UPDATE', 'DELETE');

3. 适用场景：

   • 大规模数据记录的审计场景。
   • 需要长期保存日志以供分析的场景。

3.2.3 多层日志存储策略

通过冷热分层存储，优化日志的存储效率和访问性能。

1. 热存储与冷存储分离：

   • 热存储：将最近 30 天的日志保存在高性能存储介质（如 SSD）。
   • 冷存储：将超过 30 天的历史日志归档到低成本存储介质（如 HDD 或云存储）。

2. 实现方式：

   • 配置日志路径：

     log_directory = '/ssd/audit_logs'
     archive_command = 'mv %p /hdd/archive_logs/%f'

3. 适用场景：

   • 大量日志数据需要长期保存的场景。
   • 读写访问频率差异较大的审计数据。

3.2.4 优化审计规则配置

通过合理配置审计策略，减少不必要的日志记录。

1. 减少冗余记录：

   • 避免启用全局审计（如 ALL），只记录关键操作：

     pgaudit.log = 'DDL,WRITE'

2. 精确配置表级审计：

   • 仅对敏感表开启表级别审计：

     ALTER TABLE sensitive_table SET (audit.enabled = true);

3. 动态调整审计级别：

   • 根据业务高峰期和低峰期调整审计策略：

     • 高峰期记录关键操作：

       pgaudit.log = 'NONE'

     • 低峰期恢复详细审计：

       pgaudit.log = 'ALL'

3.2.5 分布式环境下的日志管理优化

在分布式部署中，通过集中管理和分布式同步机制优化日志管理。

1. 集中日志存储：

   • 使用中央存储系统（如 HDFS）统一存储多个节点的日志：

     archive_command = 'hdfs dfs -put %p hdfs://central/logs/%f'

2. 节点级别分布式策略：

   • 为每个节点设置独立的审计策略：

     • 记录全部日志的节点：

       pgaudit.log = 'ALL'

     • 仅记录重要操作的节点：

       pgaudit.log = 'DDL'

3. 适用场景：

   • 多节点的分布式审计场景。
   • 跨节点的集中分析需求。

3.3 审计与实时告警结合

WuTongDB 的审计功能不仅用于记录用户操作，还能结合实时告警机制，帮助用户快速识别并响应异常行为。这种实时监控和自动告警的能力，可以显著提升系统的安全性和运维效率。

3.3.1 实时告警的实现机制

1. 触发条件

   实时告警通常基于以下审计日志中的异常事件：

   • 频繁失败登录：多次错误尝试登录数据库。
   • 敏感数据访问：用户未授权访问敏感表或字段。
   • 权限变更：关键角色或用户权限被意外修改。
   • 异常操作：高频执行资源密集型 SQL 查询或删除重要表数据。

2. 告警触发方式

   • 事件流分析：

     • 使用外部工具（如 Kafka 或 ELK）实时处理审计日志数据，识别异常事件。

   • 内置规则引擎：

     • 在数据库中预定义触发条件，发现异常时生成事件并写入告警日志。

3.3.2 实时告警的配置方法

1. 配置审计规则

   定义需要监控的异常事件范围，例如记录频繁登录失败的用户：

   CREATE OR REPLACE FUNCTION log_failed_login()
   RETURNS EVENT_TRIGGER AS $$
   BEGIN
      IF (SELECT COUNT(*) FROM pg_stat_activity WHERE state = 'failed') > 5 THEN
         RAISE NOTICE 'Multiple failed logins detected!';
      END IF;
   END;
   $$ LANGUAGE plpgsql;
   
   CREATE EVENT TRIGGER failed_login_monitor
   ON FAILED_LOGIN
   EXECUTE FUNCTION log_failed_login();

2. 集成外部告警工具

   使用日志分析工具（如 ELK 或 Splunk）实时分析审计日志，并生成告警：

   • 配置日志输出为 JSON 格式：

     log_destination = 'jsonlog'

   • 将 JSON 数据流推送至日志分析工具：

     filebeat -input /path/to/audit_logs -output elasticsearch

3. 配置数据库通知

   数据库通过邮件或短信发送告警：

   • 示例：配置邮件通知服务

     CREATE OR REPLACE FUNCTION send_alert(email TEXT, message TEXT)
     RETURNS VOID AS $$
     BEGIN
         PERFORM pg_notify(email, message);
     END;
     $$ LANGUAGE plpgsql;
     
     SELECT send_alert('[e-mail]', 'Unauthorized access detected');

3.3.3 实时告警的优化

1. 优先级划分

   不同事件根据重要性设置不同的告警优先级：

   • 高优先级：敏感数据访问、权限变更。
   • 低优先级：普通的查询高频操作。

2. 降低告警噪声

   • 设置时间阈值或次数阈值，避免因正常操作产生过多告警。

   • 示例：限制告警频率：

     CREATE EVENT TRIGGER limit_alert_frequency
     ON ALL
     WHEN (event_trigger_executed_recently('failed_login_monitor') < interval '10 minutes')
     EXECUTE FUNCTION skip_alert();

3. 性能优化

   • 避免对所有日志实时扫描，改为基于预定义规则过滤数据。

   • 示例：仅分析特定表的操作：

     ALTER TABLE sensitive_table SET (audit.enabled = true);

3.3.4 典型应用场景

1. 敏感数据的实时访问监控

   • 场景：金融机构监控用户访问账户信息表，发现异常访问后立即告警。

   • 配置：

     ALTER TABLE account_data SET (audit.enabled = true);

2. 频繁登录失败的防护

   • 场景：阻止恶意用户通过暴力破解登录密码。

   • 配置：

     • 定义失败登录次数的触发条件，发送邮件告警。

3. 关键权限变更的通知

   • 场景：管理员权限被撤销或赋予新角色时触发通知。

   • 配置：

     CREATE EVENT TRIGGER monitor_role_change
     ON ROLE_ALTERATION
     EXECUTE FUNCTION notify_admin();

---

第4章 审计中心功能与应用

4.1 审计中心概述

审计中心是 WuTongDB 管理平台的重要模块，为用户提供全面的审计功能管理与操作支持。它通过系统化的界面和灵活的配置选项，简化了审计操作的实施和维护，适用于企业数据合规、操作追踪以及安全监控等场景。

4.1.1 功能定位

1. 集中管理

   审计中心将分散的系统审计与 SQL 审计功能整合到统一的平台，用户可以通过单一入口完成配置、查看和导出审计日志等操作。

2. 灵活配置

   • 支持按操作类型、对象范围和时间范围的审计策略设置。
   • 提供不同集群的独立审计服务管理。

3. 增强扩展性

   审计中心支持与外部工具（如 Elasticsearch、Kibana）集成，扩展了日志分析和可视化能力。

4.1.2 核心特点

1. 全局日志管理

   • 支持系统审计和 SQL 审计的统一管理。
   • 提供日志的保存时长设置、筛选和导出功能，便于用户高效管理日志文件。

2. 可视化与查询优化

   • 审计日志支持按多维条件筛选（如时间、操作类型、用户）。
   • 提供详细的日志视图，便于分析操作行为。

3. 高效日志存储

   • 默认支持本地存储和导出功能。
   • 可选集成 Elasticsearch 提供高性能存储与检索支持。

4.1.3 适用场景

1. 合规性审计

   • 满足金融、医疗等行业的合规性要求，记录敏感操作日志并定期生成审计报告。

2. 敏感操作监控

   • 实时记录用户对敏感数据的访问行为，如查询客户数据或修改财务信息。

3. 异常行为溯源

   • 快速查找系统中发生的异常行为（如频繁登录失败），定位问题来源并进行安全响应。

4.1.4 限制与约束

主要涉及前端 UI 对浏览器版本的支持限制。以下是具体说明：

1. 支持的浏览器版本：

   • 推荐版本：

     • Chrome：100 及以上
     • Edge：100 及以上
     • Firefox：100 及以上
     • Safari：14 及以上
     • Opera：70 及以上

   • 最低支持版本：

     • Chrome：61
     • Edge：79
     • Firefox：60
     • Safari：11
     • Opera：48

   • 不支持的浏览器：

     • Internet Explorer (IE)：不支持。

2. 注意事项：

   • 为了获得最佳的用户体验和功能支持，建议用户使用推荐版本的浏览器访问管理平台。
   • 使用低于最低版本的浏览器可能会导致功能不可用或界面显示异常。

4.2 系统审计功能

系统审计功能是 WuTongDB 审计中心的核心模块之一，用于记录和管理数据库的系统级操作事件。通过系统审计，用户可以追踪关键操作的执行情况，满足数据安全与合规需求。

4.2.1 功能描述

系统审计专注于记录与数据库整体运行相关的操作事件，例如：

• 用户登录与退出。
• 用户权限的变更（如角色分配、权限调整）。
• 系统配置的修改与管理。
• 审计策略的设置与更新。

这些事件的记录为安全分析和系统审计提供了基础数据支持。

4.2.2 核心功能

1. 日志管理

   • 查看日志：通过审计中心查看系统级事件的日志记录，包括操作时间、用户、目标对象和结果状态等信息。
   • 导出日志：支持将日志导出为 CSV 或 JSON 文件，用于外部分析和存档。
   • 日志筛选：按时间范围、操作类型或用户进行筛选，快速定位感兴趣的记录。

2. 日志保存时长设置

   • 默认保留最近 30 天的日志记录。

   • 可通过审计中心调整日志保存时间，以适应存储需求：

     • 示例：将日志保存时长设置为 90 天：

       oushudb config -c log_retention_period -v 90

3. 策略配置

   • 灵活设置需要记录的系统事件类型，如登录操作、权限变更或系统配置修改。
   • 可动态调整策略范围，记录特定用户或角色的操作。

   • 用户可以通过设置”是否审计”的开关，开启或关闭某个资源类型的操作审计。

     

4.2.3 操作流程

以下为通过审计中心管理系统审计的基本流程：

1. 进入审计中心

   • 登录 WuTongDB 管理平台，导航到“审计中心”模块。

2. 查看日志

   • 选择“系统审计”，设置时间范围、操作类型或用户进行日志筛选。

     

3. 导出日志

   • 筛选目标日志后，点击“导出”按钮，选择导出格式（如 CSV 或 JSON)。

4.2.4 优化建议

1. 定期清理历史日志

   • 设置合理的日志保存时长，避免存储资源浪费。

2. 限制不必要的日志记录

   • 针对低频或无关的系统事件，禁用审计功能，减少系统开销。

3. 结合外部工具进行分析

   • 将系统审计日志导出后，使用 ELK 或其他工具进行深入分析，挖掘异常行为模式。

4.3 SQL 审计功能

SQL 审计功能是 WuTongDB 审计中心的重要组成部分，用于记录用户在数据库中执行的 SQL 操作日志。它支持多维度的日志筛选、可视化展示与外部工具集成，为数据合规性和安全性管理提供了强有力的支持。

4.3.1 前提条件

1. 日志存储依赖

   • SQL 审计日志默认存储在 Elasticsearch 中。
   • Elasticsearch 集群需要提前部署或在系统中注册，确保服务与 SQL 审计功能正常连接。

   

2. 开启 SQL 审计服务

   • 用户必须在审计中心启用 SQL 审计服务，并关联目标集群。

3. 操作要求

   • 当日志存储未指定 Elasticsearch 集群时，进入审计页面会提示用户完成相关配置。

4.3.2 核心功能

SQL 审计日志模块为用户提供了强大的日志管理能力，涵盖日志筛选、字段定制、详情查看、导出等功能。

1. 集群选择

   • 通过审计中心的集群选择器切换目标集群。
   • 系统会记住用户上次访问的集群，首次使用时会按字母顺序默认选择第一个集群。

2. 自定义日志展示字段

   • 用户可以根据需要调整日志展示的字段：

     • 点击页面右上角的 齿轮图标 进入字段配置窗口。
     • 在配置窗口中勾选需要展示的字段，例如用户名称、SQL 语句、目标对象等。
     • 支持通过拖动调整字段的显示顺序，优化日志视图。

   

3. 多条件日志筛选

   • 时间范围筛选：

     • 快捷时间选项：【近 5 分钟】、【近 1 小时】、【近 1 天】、【近 7 天】。
     • 自定义时间范围：通过日历选择起止时间。

   • 操作类型筛选：

     • 按 SQL 操作类型进行筛选，例如 SELECT、INSERT、DELETE。

   • 对象类型筛选：

     • 按数据库对象的类型（如 TABLE、VIEW）筛选日志。

   • 用户筛选：

     • 查看特定用户的 SQL 操作记录。

   • 审计类型筛选：

     • 支持按 SQL 语句、事务操作等类型分类。

   

   • 高级搜索

   

4. 日志详情

   • 点击日志列表中的某条记录，可进入详情视图，查看完整的操作信息：

     • SQL 语句内容。
     • 操作的目标对象（如表、视图、索引）。
     • 用户名称与客户端 IP 地址。
     • 执行时间与结果状态。

   

5. 日志导出

   • 用户可以选择符合筛选条件的日志记录，导出为 XLSX 文件。
   • 导出的文件包括所有选定字段，便于外部存档与分析。

4.3.3 SQL 审计服务管理

SQL 审计服务支持新增与管理审计策略，帮助用户灵活配置日志采集和存储。

1. 新增 SQL 审计服务

   • 在审计中心点击 新增 SQL 审计服务 按钮，完成以下步骤：

     1. 配置审计项：

        • 勾选需要审计的操作类型，如 READ、WRITE、DDL。
        • 例如，选择 READ 表示记录所有数据读取操作。

        

     2. 选择集群：

        • 从集群列表中选择需要开启审计服务的目标集群。

        

     3. 采集设置：

        • 配置日志采集的频率和日志格式（如 JSON 或 CSV）。
        • 关联采集工具（如 Filebeat）以优化采集性能。

        

     4. 确认基础信息：

        • 核对配置后保存并部署审计服务。

        

2. 采集节点与索引管理

   • 审计中心显示当前启用的采集节点列表及其运行状态。
   • 滚动索引机制支持基于生命周期策略自动创建和清理日志索引。

4.3.4 日志分析与优化建议

1. 精细化审计配置

   • 为敏感数据表启用详细审计，避免记录无关日志，减少存储和计算开销：

     ALTER TABLE sensitive_table SET (audit.enabled = true);

2. 定期维护日志索引

   • 使用 Elasticsearch 的生命周期管理功能，定期删除过期的日志索引。

3. 结合 Kibana 可视化

   • 将 SQL 审计日志集成到 Kibana 仪表盘，生成操作行为的时间分布图、用户操作趋势等可视化报表。

4.4 审计中心的常见问题

1. 问题列表

   • 问题 1：审计服务未启动：

     • 检查审计服务配置是否完成。

     • 通过管理平台或命令行重新启动服务：

       oushudb restart audit_service

   • 问题 2：日志存储不足：

     • 检查存储路径的磁盘使用情况。

     • 启用日志清理策略，释放空间：

       find ${OUSHUDB_LOG_PATH}/audit -type f -mtime +30 -exec rm {} \;

   • 问题 3：日志导出失败：

     • 确保目标路径有写入权限。
     • 检查导出的时间范围是否合理。

   • 问题 4：有的模块的访问，并没有被审计下来。

     • 最常见的原因是该模块并没有对接审计中心，需要相应模块的开发根据审计对接的标准要求，对接一下审计中心。

2. 解决建议

   • 定期检查日志存储空间。
   • 优化审计服务配置，避免过多日志生成。