数据库安全之审计敏感表的所有查询语句及来源IP

要审计数据库中敏感表的所有查询语句及来源IP，核心手段就是开启数据库的审计功能，把每一条对敏感表的SQL操作连同执行它的客户端IP、用户名、时间戳全部记录下来。不同数据库的实现方式不同，MySQL用general_log或企业版的Enterprise Audit，PostgreSQL靠pgAudit扩展，SQL Server用SQL Server Audit或扩展事件，Oracle用Unified Auditing或传统审计。不管你用哪种数据库，思路都一样：先定义哪些表是敏感表，再配置审计规则抓取对这些表的SELECT、UPDATE、DELETE等操作，最后把日志导出来分析IP来源。下面我把每种主流数据库的具体操作步骤、配置代码、注意事项全部讲透。

企业数据库里通常存放着用户信息、财务数据、交易记录等核心资产。一旦敏感表被非法查询或篡改，后果非常严重。很多数据泄露事件，攻击者不是直接拖库，而是通过合法账号慢慢查询敏感字段，等你发现时数据已经被搬走了。审计查询语句和来源IP，能做到三件事：第一，实时发现异常访问行为，比如某个IP在短时间内大量查询客户手机号；第二，事后追溯，出了安全事件能精准定位是谁、从哪里、什么时间干的；第三，满足合规要求，等保2.0、GDPR、个人信息保护法都明确要求对敏感数据访问留痕。

MySQL社区版本身没有细粒度的表级审计，但可以通过general_log记录所有SQL，再用脚本过滤敏感表。生产环境更推荐用MySQL Enterprise Audit或者Percona的audit_log插件。下面给出两种方案的具体操作。

-- 开启general_log
SET GLOBAL general_log = 'ON';
SET GLOBAL general_log_file = '/var/log/mysql/general.log';

-- 记录来源IP（MySQL 5.7+默认记录）
SET GLOBAL log_raw = 'ON';

-- 查询general_log中对敏感表的操作
SELECT event_time, user_host, thread_id, command_type, argument
FROM mysql.general_log
WHERE argument LIKE '%sensitive_table%'
AND command_type = 'Query'
ORDER BY event_time DESC;

这种方式会记录所有SQL，对性能影响大，日志量爆炸，只适合短期排查问题。生产环境长期使用必须上插件。

-- 安装插件
INSTALL PLUGIN audit_log SONAME 'audit_log.so';

-- 配置审计规则
SET GLOBAL audit_log_policy = 'QUERIES';
SET GLOBAL audit_log_format = 'JSON';
SET GLOBAL audit_log_file = '/var/log/mysql/audit.log';

-- 通过filter_id过滤敏感表（需要配合filter规则）
-- 在my.cnf中添加：
-- audit_log_filter_id = 1
-- audit_log_filter_1 = 'sensitive_table'

更精细的做法是在my.cnf里配置audit_log_include_accounts和audit_log_exclude_accounts，只审计特定用户对敏感表的操作，减少日志噪音。审计日志是JSON格式，可以用ELK或者Splunk直接解析分析。

PostgreSQL原生支持通过配置参数做基础审计，但要实现表级细粒度审计，必须装pgAudit扩展。这是PostgreSQL社区最主流的审计方案。

-- 安装pgAudit扩展
CREATE EXTENSION pgaudit;

-- postgresql.conf配置
shared_preload_libraries = 'pgaudit'
pgaudit.log = 'all'
pgaudit.log_catalog = 'off'
pgaudit.log_relation = 'on'
pgaudit.log_statement_once = 'off'
pgaudit.log_parameter = 'on'

-- 针对敏感表设置审计（在特定数据库中执行）
ALTER TABLE sensitive_table SET (pgaudit.log = 'read, write');

配置完成后重启PostgreSQL。所有对sensitive_table的SELECT、INSERT、UPDATE、DELETE都会被记录到PostgreSQL日志中，日志里包含用户名、数据库名、客户端IP（通过log_line_prefix配置%h获取）、完整SQL语句。在postgresql.conf里加上：

log_line_prefix = '%t [%p]: [%l-1] user=%u,db=%d,app=%a,client=%h '

这样每条日志都带客户端IP。如果想只审计特定用户对敏感表的操作，可以用pgaudit.log_role参数做过滤。

SQL Server从2008开始内置SQL Server Audit功能，配合Server Audit Specification和Database Audit Specification可以做到非常精细的表级审计。

-- 创建服务器审计对象
CREATE SERVER AUDIT SensitiveTableAudit
TO FILE (FILEPATH = 'D:\AuditLogs\')
WITH (ON_FAILURE = CONTINUE);

-- 启用审计
ALTER SERVER AUDIT SensitiveTableAudit WITH (STATE = ON);

-- 创建数据库审计规范，指定敏感表
CREATE DATABASE AUDIT SPECIFICATION AuditSensitiveTable
FOR SERVER AUDIT SensitiveTableAudit
ADD (SELECT ON dbo.sensitive_table BY public),
ADD (UPDATE ON dbo.sensitive_table BY public),
ADD (DELETE ON dbo.sensitive_table BY public)
WITH (STATE = ON);

SQL Server还支持扩展事件（Extended Events），性能比传统审计更好。如果你用的是SQL Server 2019以上，推荐用扩展事件做高性能审计：

CREATE EVENT SESSION [AuditSensitiveTable] ON SERVER
ADD EVENT sqlserver.sql_statement_completed(
    ACTION(sqlserver.client_hostname, sqlserver.username)
    WHERE ([sqlserver].[database_name] = N'YourDB'
    AND [sqlserver].[sql_text] LIKE N'%sensitive_table%'))
ADD TARGET package0.event_file(SET filename = N'D:\AuditLogs\SensitiveTable.xel')
WITH (STARTUP_STATE = ON);

扩展事件可以精确捕获包含敏感表名的SQL语句，同时记录客户端主机名和用户名，通过关联sys.dm_exec_connections还能拿到客户端IP。

Oracle从12c开始推荐使用Unified Auditing（统一审计），比传统审计更灵活。传统审计通过AUDIT语句也能实现，但管理起来麻烦。

-- 统一审计：创建审计策略
CREATE AUDIT POLICY audit_sensitive_table_policy
ACTIONS SELECT ON schema.sensitive_table,
        UPDATE ON schema.sensitive_table,
        DELETE ON schema.sensitive_table;

-- 启用策略
AUDIT POLICY audit_sensitive_table_policy;

-- 传统审计方式（兼容老版本）
AUDIT SELECT, UPDATE, DELETE ON schema.sensitive_table BY ACCESS;

Oracle的审计日志记录在SYS.AUD$或统一审计的UNIFIED_AUDIT_TRAIL视图里，查询方式：

SELECT username, userhost, action_name, obj_name, sql_text, timestamp
FROM unified_audit_trail
WHERE object_name = 'SENSITIVE_TABLE'
ORDER BY event_timestamp DESC;

userhost字段就是来源IP或主机名。Oracle还支持细粒度审计（FGA），可以审计到列级别，比如只审计谁查询了敏感表中的身份证号字段。

光把日志记下来还不够，必须有一套完整的分析和告警机制，否则日志就是摆设。具体建议如下：

第一，日志集中存储。把所有数据库的审计日志统一送到日志中心，比如用Filebeat采集后发到Elasticsearch，或者用Syslog发到专用审计服务器。千万不要让审计日志和业务日志混在一起，防止被篡改。

第二，设置告警规则。常见的告警场景包括：单个IP在5分钟内查询敏感表超过100次；非业务时间段（凌晨2点到5点）出现对敏感表的访问；同一个账号从多个不同IP登录并查询敏感表。这些规则可以在SIEM平台或者自建脚本里实现。

第三，定期审计回溯。每周至少做一次审计日志分析，看有没有异常模式。每月出一份审计报告，重点关注高频访问用户、异常IP段、批量导出行为。

第四，日志防篡改。审计日志一旦被删或被改，整个审计体系就废了。建议把日志实时同步到只读存储或者WORM（一次写入多次读取）介质，同时做哈希校验。

很多人在做数据库审计时容易犯几个错误。第一个是开启了审计但没有定义敏感表范围，结果日志量太大把磁盘撑爆。正确做法是先梳理资产，明确哪些表是敏感表，再针对性配置审计规则。

第二个错误是只审计了SELECT，忽略了UPDATE和DELETE。实际上数据篡改比数据泄露更隐蔽，必须把写操作也纳入审计。

第三个错误是没有记录客户端真实IP。有些数据库中间件或代理会掩盖真实IP，要确保数据库层面能拿到原始客户端地址，而不是代理服务器的地址。

第四个错误是审计日志和业务数据存在同一台服务器。一旦服务器被攻破，攻击者可以同时删业务数据和审计日志。必须物理隔离或逻辑隔离。

最佳实践总结：先做敏感数据分类分级，再选合适的审计工具，配置最小化审计范围，日志独立存储防篡改，配合自动化告警和定期人工分析，形成闭环。数据库安全不是一次性工程，是持续运营的过程。

小型团队用MySQL或PostgreSQL，直接上pgAudit或Percona插件就够了，成本低配置快。中型企业建议上专业数据库审计产品或者自建ELK分析平台，把多个数据库的审计日志统一管理。大型企业和金融行业，必须用商业级数据库审计系统，支持实时告警、合规报表、与堡垒机联动，满足监管审计要求。不管哪种规模，核心原则不变：知道谁在什么时候从哪里查了什么敏感数据。