核心是精准配置auditd规则监控数据库敏感文件读取行为，需确认服务运行、用sudo操作、查真实inode路径、组合文件与用户级规则、用ausearch高效查询、规则写入rules.d并augenrules加载。
直接监控数据库敏感文件的读取行为，核心不是查日志，而是先让审计系统知道你要盯谁、盯什么、怎么标记。新手最容易卡在规则写错、路径不对、查不到结果这三步。下面用最贴近实际操作的方式讲清楚。
确认 auditd 已就绪且能生效
规则加进去没反应？大概率是服务没跑或权限没到位：
- 运行
systemctl status auditd，看到 active (running) 才算真正启动 - 非 root 用户执行
auditctl -w /path -k test会被静默忽略，必须用sudo - 某些云镜像启用了
ProtectSystem=strict，会导致/etc/audit/rules.d/下的规则不加载；可临时用auditctl -w加一条测试规则，再auditctl -l | grep test确认是否列出
精准定位数据库敏感文件的真实路径
别写 /var/lib/mysql/mydb/users.sql 这类看起来对、其实错的路径：
- 数据库配置文件、数据文件、备份SQL常被软链接指向真实位置，auditd 只认 inode 层级路径
- 用
ls -i /var/lib/mysql/mydb/users.sql查真实 inode 和路径，规则里必须写这个输出的绝对路径 - 如果是 MySQL 的 ibdata1 或 InnoDB 表空间文件，它们通常无扩展名、权限严格，也要用
ls -l确认属主和可访问性
给特定用户 + 特定文件组合加监控规则
只监控文件不够，要锁定“谁在读”：
- 单纯
-w /path -p r -k db_read只能知道有读操作，但不知道是哪个用户触发的 - 更实用的是双管齐下：
✓ 先加文件监控：sudo auditctl -w /var/lib/mysql/mydb/users.sql -p r -k db_users_read
✓ 再加用户级 execve 监控（捕获调用命令）：sudo auditctl -a always,exit -F arch=b64 -S execve -F uid=1001 -k user1001_actions -
-F uid=1001中的 1001 是目标用户的 UID（用id -u username查），这样所有该用户执行的命令都会打上user1001_actions标签，后续可关联分析
快速查出“谁在什么时候读了这个文件”
加完规则别干等，用 ausearch 组合查，比翻 /var/log/audit/audit.log 高效得多：
- 查最近 15 分钟对该文件的所有读操作，并还原成易读格式：
sudo ausearch -k db_users_read -m SYSCALL -i --start 15 minutes ago | aureport -f -i - 如果想确认是不是目标用户触发的，加一层过滤：
sudo ausearch -k db_users_read -m SYSCALL -i --start now | grep "uid=1001" - 若返回为空，先运行
sudo auditctl -l看规则是否在列表里，再检查sudo ausearch -m CONFIG_CHANGE -ts recent是否有规则加载失败记录
规则永久生效只需两步：把上面 auditctl 命令中的参数（去掉 sudo auditctl）写进 /etc/audit/rules.d/db-monitor.rules，例如：
-w /var/lib/mysql/mydb/users.sql -p r -k db_users_read -a always,exit -F arch=b64 -S execve -F uid=1001 -k user1001_actions
保存后执行 sudo augenrules --load，不是 systemctl restart auditd。
不复杂但容易忽略。
