从一次误删事件说起
上周同事小李差点酿成大祸。他在远程连接公司MySQL数据库时，用的是默认的3306端口，密码还是123456改的变体。某天早上刚上班，发现数据库里的用户表被清空了，日志显示是从一个陌生IP发起的操作。事后查证，是有人通过扫描工具找到了开放端口，暴力破解登录进来的。
这事之后，我们整个团队重新梳理了数据库相关的网络安全防护措施。不是写在纸上的流程，而是真正能挡住攻击的实际做法。
关闭不必要的端口暴露
数据库服务默认监听在公网IP上等于把家门钥匙挂在门口。现在我们的做法是：数据库服务器只对内网开放，前端应用服务器和数据库之间走内网通信。如果必须远程访问，通过SSH隧道连接。
比如连接MySQL，不再直接用客户端连公网IP，而是用下面这种方式：
ssh -L 3307:localhost:3306 user@db-server-ip这条命令把本地的3307端口映射到数据库服务器的3306端口。之后用localhost:3307就能安全访问，数据全程加密传输。
最小权限原则落地到每个账号
以前大家共用一个root账号，谁出问题都难说清。现在每个应用都有独立数据库账号，权限精确到库甚至表级别。
例如给订单系统创建专用账号：
CREATE USER 'order_app'@'10.0.1.%' IDENTIFIED BY 'StrongPass!2024';
GRANT SELECT, INSERT, UPDATE ON shop.orders TO 'order_app'@'10.0.1.%';
FLUSH PRIVILEGES;这样即使这个账号泄露，攻击者也只能操作订单表，无法查看用户密码或其他敏感数据。
强制启用TLS加密连接
公司内部网络也不绝对安全。中间人攻击可能发生在同一局域网内。MySQL 5.7以上版本支持原生SSL连接，配置后所有客户端必须加密通信。
检查当前连接是否加密：
status;看到"SSL: Cipher in use is TLS_AES_256_GCM_SHA384"才算达标。没开启的话，客户端连接会失败，倒逼所有人升级配置。
定期审计与异常行为监控
启用了数据库审计插件后，每天早上会收到一份操作摘要邮件。里面列出前一日所有DROP、DELETE、GRANT类高危操作。
有次发现凌晨两点有个DELETE FROM users但没有WHERE条件的语句，立即回滚了备份，并追查到是某个测试脚本写错了。如果没有监控，这种错误可能要等到用户投诉才被发现。
备份策略本身就是防护一环
再严密的防线也可能被突破。每周日凌晨自动执行全量备份，每小时增量binlog归档。所有备份文件上传到异地对象存储，并设置多版本保护。
曾经遭遇勒索软件加密文件，但因为备份系统独立且不可删除，两天内就恢复了全部服务。这比纠结解密方案现实多了。
别忽视物理与人员管理
数据库服务器所在的机房需要刷卡进入，运维操作必须通过跳板机记录全过程。新员工入职开通权限时，审批流程要经过直属主管和技术负责人双重确认。
前阵子实习生想快速验证功能，申请临时DBA权限被驳回。最终给了带时限的只读账户——看似麻烦，但避免了误操作风险。