在Ubuntu服务器环境下如何加固SQL数据库的系统级防护？-SQL-PHP中文网

MySQL安全加固需先确认数据库类型，禁用默认空密码、运行mysql_secure_installation、改auth_socket为mysql_native_password、限制bind-address与ufw协同、创建最小权限专用账号、强制SSL/TLS并客户端验证。

在ubuntu服务器环境下如何加固sql数据库的系统级防护？

SQL Server 和 MySQL 的加固不能混用同一套命令

Ubuntu 上跑的 SQL 数据库可能是 SQL Server（Linux 版）或 MySQL，两者底层机制、配置路径、权限模型完全不同。直接套用 mysql_secure_installation 去加固 SQL Server 会报错；反过来用 sqlcmd 去连 MySQL 也连不上。先确认你实际在用哪个：

SQL Server：检查是否安装了 mssql-server 包，端口默认是 1433，配置文件在 /etc/sqlserver/mssql.conf
MySQL：检查是否安装了 mysql-server，端口默认是 3306，主配置在 /etc/mysql/mysql.conf.d/mysqld.cnf

混淆这两者会导致防火墙规则开错、加密配置无效、甚至误删用户。

bind-address 和 ufw 必须协同生效

只改 bind-address 不够，只配 ufw 也不保险。比如把 MySQL 的 bind-address 设成 127.0.0.1，但 ufw 却放行了所有 IP 的 3306 端口——此时本地服务虽不监听外网，但若后续有人误改配置或启用其他监听服务（如代理），攻击面就重新暴露。

MySQL 正确做法：bind-address = 127.0.0.1 + sudo ufw deny 3306（完全屏蔽），或仅对可信内网段放行：sudo ufw allow from 192.168.1.50 to any port 3306
SQL Server 类似：tcp-port = 27777（非默认端口）+ sudo ufw allow from 192.168.1.0/24 to any port 27777
切忌写 sudo ufw allow 3306 或 sudo ufw allow 1433 ——这是全量开放，等同于没设防

root / SA 账户必须降权或隔离使用

Ubuntu 系统 root 和数据库 root / SA 是两层权限，但常被当成一回事处理。典型错误是：用系统 root 执行 sqlcmd -U SA，再用 SA 创建应用账号——这等于把最高权限链条裸露在运维流程里。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

创建专用低权限数据库账号时，不要用 SA 或 MySQL 的 root@'%'，而应先用 root@localhost 或 SA@localhost 登录，再执行：CREATE LOGIN app_user WITH PASSWORD='...';（SQL Server）或 CREATE USER 'app_user'@'192.168.1.50' IDENTIFIED BY '...';（MySQL）
禁止远程 SA 或 root@'%'：SQL Server 可通过 ALTER LOGIN SA DISABLE;；MySQL 执行 UPDATE mysql.user SET Host='localhost' WHERE User='root' AND Host='%'; FLUSH PRIVILEGES;
系统级：确保运行 mssql-server 或 mysql 服务的系统用户（如 mssql、mysql）不在 sudo 组，且家目录权限为 700

TLS/SSL 加密不是“开了就行”，客户端必须强制校验

很多教程停在“生成证书 + 配置 ssl-cert”就结束，但只要客户端不验证证书，中间人仍可伪造响应。MySQL 的 REQUIRE SSL 和 SQL Server 的 force encryption = true 只是服务端声明，不等于连接自动加密。

MySQL：客户端连接必须显式加参数，例如 mysql -u app_user -p --ssl-mode=VERIFY_IDENTITY -h db.example.com；应用代码里也要设置 ssl={'ca': '/path/to/ca.pem'}
SQL Server：Linux 客户端需用 sqlcmd -S server -U user -P pass -N（-N 启用加密），且服务器端 mssql.conf 中 force-encryption = true 必须与证书路径匹配
验证是否真加密：抓包看 TCP 流是否为乱码（如用 tcpdump -i any port 1433 -w sql.pcap），明文协议（如 TDS、MySQL protocol）在加密后不应出现可读字段

最易被忽略的是证书信任链——自签名证书必须同步分发到所有客户端，否则连接会静默回退到未加密模式，而日志里可能只报 WARNING 不报 ERROR。