MariaDB静态加密：应用提供密钥及相关安全需求问询

1. 应用直接提供密钥或通过WCF服务获取密钥的可行性 #

MariaDB的静态加密（数据-at-rest加密）是在服务器进程层面解密磁盘数据文件，不支持通过应用连接字符串直接传递密钥——密钥是MariaDB启动时必须加载的核心凭据，不属于应用连接协议的一部分。

如果要通过自定义服务（比如WCF）提供密钥，需要通过间接方式实现：

• 编写自定义脚本，在MariaDB启动前调用你的WCF服务获取密钥，将密钥写入加密密钥文件（需严格限制文件权限），再启动MariaDB加载该文件。
• 也可以将密钥通过环境变量传递给MariaDB进程，但同样需要在启动前通过WCF服务获取并注入环境变量。
• 注意：MariaDB本身没有内置WCF集成，所有对接逻辑需要你自行实现，且必须保证密钥获取流程在MariaDB启动完成前执行，否则服务器无法解密数据文件启动。

2. 阻止加密数据库的管理员密码重置 #

单纯依靠MariaDB的静态加密无法阻止管理员密码重置，因为密码重置操作依赖的是权限系统（而非加密密钥）——只要能物理访问服务器、或以操作系统用户身份启动MariaDB并跳过权限检查（如--skip-grant-tables参数），就可以重置root等管理员密码。

要实现阻止，需要结合操作系统和权限管控：

• 严格限制操作系统用户对MariaDB数据目录、配置文件的读写权限，防止他人修改配置或启动参数。
• 使用systemd等服务管理器的保护配置（如ProtectSystem=strict），禁止MariaDB进程绕过权限系统启动。
• 启用MariaDB审计日志，监控密码重置相关的操作（如ALTER USER、SET PASSWORD），及时发现异常。
• 禁用远程直接访问服务器的root账户，仅允许通过受信任的客户端或跳板机操作。

3. 支持同类场景的其他数据库 #

以下数据库支持全库加密（或等效的静态加密），且支持外部密钥管理/应用层面密钥传递的场景：

• SQL Server：支持透明数据加密（TDE），可集成外部密钥管理服务（KMS），同时Always Encrypted特性允许应用持有列级加密密钥，直接在应用层处理加密逻辑。
• PostgreSQL：通过pgcrypto扩展实现列级加密，第三方工具（如pg_tde）支持全库静态加密，可对接HashiCorp Vault等外部密钥管理系统，实现启动时从外部获取密钥。
• Oracle Database：内置透明数据加密（TDE），支持Oracle Key Vault或第三方KMS管理密钥，可配置启动时从外部密钥服务加载凭据。
• IBM Db2：支持数据-at-rest加密，集成多种密钥管理服务，支持启动时加载外部密钥启动数据库。

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