当文件系统被访问时，如何保障MariaDB用户密码与认证安全？

1. 文件系统被入侵时，MariaDB认证机制的安全性 #

默认情况下，MariaDB的mysql.user表存储的是哈希后的密码（比如mysql_native_password采用SHA1哈希，caching_sha2_password使用更安全的SHA-256衍生算法），不会直接保存明文密码。但如果恶意用户能直接访问MariaDB的数据目录（拿到.ibd、.frm等表文件），他们可以把这些文件复制到自己搭建的MariaDB实例中，直接读取哈希值，进而通过暴力破解、彩虹表攻击尝试还原明文密码。

简言之：认证机制能避免明文泄露，但挡不住文件系统入侵者获取哈希值并发起离线破解。

2. 替换mysql表文件的已知认证数据是否可行？ #

完全可行。如果恶意用户拥有MariaDB数据目录的写权限，他们可以预先在自己的MariaDB实例中创建带恶意账号（比如拥有全局权限的账号）的mysql.user表文件，然后替换目标服务器上的对应文件。等MariaDB重启后，这个恶意账号就能正常登录并控制数据库。

MariaDB启动时直接读取本地表文件内容，只要文件格式与当前版本兼容，就会直接生效，不会做额外的完整性校验。

3. 文件系统被访问时保护MariaDB表的安全方案 #

• 启用透明数据加密（TDE）：对MariaDB的表空间文件加密，即使拿到表文件，没有加密密钥也无法解析内容。注意TDE需要MariaDB Enterprise版本或部分社区版插件支持，密钥要妥善存储在独立于数据库文件系统的位置（比如硬件安全模块HSM）。
• 严格管控文件系统权限：确保MariaDB数据目录（默认/var/lib/mysql）仅对mysql系统用户开放读写权限，其他用户无任何访问权限。这是最基础也最有效的防线，从根源上阻止恶意用户接触表文件。
• 使用加密文件系统：将MariaDB数据目录部署在加密文件系统上（比如Linux的LUKS、Windows的BitLocker），即便磁盘被物理窃取或文件系统被非法挂载，没有解密密钥也无法读取文件内容。
• 最小化数据库账号权限：所有业务账号只分配必要的数据库/表操作权限，避免授予全局权限（比如ALL PRIVILEGES）。即便恶意用户拿到账号，也能限制其破坏范围。
• 定期审计表文件完整性：用哈希校验工具（比如md5sum）定期检查mysql.user等核心系统表的文件哈希值，一旦发现哈希不符，立即告警排查，防止表文件被替换。

内容的提问来源于stack exchange，提问作者Tobia