如何防止服务器 SQLite 数据库文件被非法拷贝读取

防止 SQLite 文件被非法拷贝读取，最稳妥的方案是“访问控制 + 文件权限 + 数据加密”组合拳，单纯靠隐藏文件名或修改后缀无法根本解决问题。

先说结论：SQLite 本质是单文件数据库，一旦攻击者拿到文件且未加密，数据即泄露，必须多层防护。

命令速用版

以下是 Linux 环境下快速加固的常用命令与配置片段，可直接参考使用：

1. 修改文件权限（仅限所有者读写）：
chmod 600 /path/to/your/database.db

2. Apache 禁止访问 SQLite 后缀：
在.htaccess 中加入：
<FilesMatch "\.sqlite$"> Deny from all </FilesMatch>

3. 以只读模式打开数据库（代码层）：
sqlite3_open_v2("mydb.db", &db, SQLITE_OPEN_READONLY, NULL);

SQLite 与其他数据库不同，它不需要独立的服务器进程，整个数据库就是一个普通文件。这意味着任何能读取该文件权限的用户或进程，理论上都可以将其拷贝走。

如果文件未加密，攻击者只需拿到文件副本，用任何 SQLite 客户端工具即可直接查看明文数据。即使你在代码里设置了只读模式，那只能防止数据被篡改，无法防止文件被拷贝。因此，防护的核心在于“让文件拿不到”或者“拿到了也打不开”。

第一步：切断 Web 直接下载路径

很多泄露是因为数据库文件放在了 Web 根目录下。应将数据库文件移至 Web 无法访问的目录。如果必须放在 Web 目录，需配置服务器禁止访问特定后缀。

对于 Apache，可使用.htaccess 限制；对于 Nginx，可在配置中 deny 特定文件类型。公开资料中提到，将 SQLite 放在 WEB 不能访问到的地方是最基本的安全措施。

第二步：操作系统文件权限管控

利用操作系统的权限管理功能，限制只有运行数据库的应用进程所属用户才能读取该文件。在 Linux 上，建议使用 chmod 600 或 0600 权限，确保其他用户无法读取。

在 Windows 服务器上，可通过 NTFS 权限设置，限制特定用户组对文件的读、写、复制权限，防止非授权用户操作。

第三步：实施数据加密

SQLite 本身不提供内置加密功能。如果数据敏感，必须使用第三方加密扩展，如 SQLCipher，或者在应用层对敏感字段加密后存储。

加密后，即使文件被拷贝，没有密钥也无法解密内容。这是防止文件拷贝后泄露的最后一道防线。

第四步：服务器访问与拷贝控制

针对服务器层面的非法拷贝，需限制网络共享和物理接口。例如关闭不必要的共享端口（如 113 和 445），禁用远程桌面剪贴板共享（如删除 rdpclip.exe 进程），以及通过组策略禁用 USB 存储设备，防止数据通过物理介质流出。

1. 下载测试：在浏览器地址栏直接输入数据库文件 URL，确认返回 403 Forbidden 或 404 Not Found，而不是开始下载。

2. 权限测试：使用非 root 用户或非应用所属用户尝试读取文件，确认系统提示 Permission denied。

3. 拷贝可用性测试：在拥有权限的环境下拷贝一份文件到外部机器，尝试用 SQLite 客户端打开。若已加密，应提示错误或直接无法识别；若未加密但权限控制得当，外部机器应无法获取该文件。

1. 备份文件未加密：很多团队加密了主数据库，但自动备份生成的副本文件未加密，且权限设置宽松，成为泄露缺口。

2. 密钥硬编码：使用了 SQLCipher 等加密方案，但将密钥硬编码在代码库中。一旦代码泄露，加密形同虚设。

3. 只读模式误解：开发者误以为设置了数据库连接为只读模式（Read Only）就能防止文件被拷贝。实际上这只限制写操作，不影响文件本身的读取和复制。

4. 临时文件泄露：某些 SQLite 操作会生成临时文件（如 WAL 模式下的 wal 文件），这些临时文件可能未继承主文件的权限设置，需一并检查。