mysql安全规范

[TOC]

架构安全

架构层面

• 不同环境的网段隔离

针对办公及研发、测试、UAT、生产等环境，划分不同的网段隔离，以防研发代码连错数据库环境；
如要数据流转，请联系网络和安全同事评估后，再开放特定的端口用于传输；

• 双网段的管理使用，主要针对生产环境

每台服务器建议双网段，分为业务网段+管理网段；
1.业务网段：10.1.72.x，用于业务访问；
2.管理网段：10.1.73.x，用于备份、高可用等；

代码层面

• 禁止在数据库中存储明文密码

采用加密字符串存储密码，并保证密码不可解密，同时采用随机字符串加盐保证密码安全。
防止数据库数据被公司内部人员或黑客获取后，采用字典攻击等方式暴力破解用户密码；

• 读写分离的合理使用

针对一主二从的高可用架构，规划如下：
1.第一台主库用来读写;
2.第一台从库用来只读查询或数据仓库抽取;
3.第二台从库用来数据库备份;

• 防止SQL注入式攻击

1.业务禁止使用root账号，业务账号也禁止super权限；
2.业务账号与管理员账号的权限严格区分，并遵从最小化原则；
3.强迫使用参数化的语句来传递用户输入的变量，而不是将用户输入变量嵌入到SQL语句中；
4.加强对用户输入内容的检查与验证，字符串变量的内容，只接受所需的值。拒绝包含二进制数据、转义序列和注释字符的输入内容；

服务器安全

版本与补丁

• 操作系统版本的选择

Windows    统一选择 Windows Server 2019 Datacenter x64
Linux    统一选择 Centos 7.9 x64

• 数据库版本的选择

MSSQL    统一选择 SQL Server 2016 Enterprise + SP2
MySQL    统一选择 MySQL 5.7.34

• 及时安装最新的操作系统补丁；

windows：http://windows.microsoft.com/zh-cn/windows/service-packs-download
linux:

• 及时安装最新的数据库补丁；

sqlserver：http://support.microsoft.com/kb/321185/zh-cn
mysql：

账号与权限

• 更改或禁用默认的管理员帐号名；

防止服务器被入侵，最基本的安全措施之一就是禁用或更改默认的管理员用户名；
比如，将windows默认的adinistrator改为admindb，禁用windows默认的guest账号，更改或禁用linux默认的root账号；

• 创建本地数据库专用帐户，并赋予该账户除运行各种数据库服务之外的最低权限；
• 禁止在生产数据库服务器开通服务器个人登录帐号；
• 对数据库系统安装目录及相应文件访问权限进行控制；

比如：禁止除专用账户外的其它账户修改、删除、创建子目录或文件；

防火墙与端口

• 配置并启用防火墙

确认Windows已启动防火墙，Linux已开启iptables，且已添加数据库端口的入站策略；

• 数据库服务端口的防护

MSSQL 统一用2433作为数据库端口号； 
MySQL 统一用3406作为数据库端口号；

• 远程端口的防护

防止服务器被入侵，另外一个手段就是修改默认的远端桌面或ssh端口；
比如，将远端桌面默认的3389端口改为13149，将ssh默认的22端口改为23245；

• 禁止使用共享，关闭445敏感端口

从端口的攻击流量来看，最容易引起攻击的为445端口，针对其所产生的攻击流量占所有攻击总量的42%。

windows如何关闭：
1.找到 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\netBT\Parameters
2.新建 "DWORD值"值名为 "SMBDeviceEnabled" 数据为默认值"0"

应用软件

• 数据库服务器不得提供其它网络服务，如：WWW、FTP、DNS等

数据库安全

备份与恢复

• 制定合理的备份计划

备份是一种保障机制，一般用不到，用到就是大事；

• 定期做数据恢复性测试

除了验证备份集的完整性，还要进行真实的恢复性测试，并保证一定周期的全覆盖；

• 配置数据库高可用
• 搭建异地容灾环境

账号与权限

• 禁止将sa或root作为业务帐号（权限太大存在安全风险），易被攻击建议禁用或仅限本机访问；
• 禁止有sa或root权限的应用程序账号存在

root权限会导致read only失效，导致较多诡异问题而且很难追踪；

• 禁止账号混用，请根据业务线或部门来创建账号；

比如，支付部门网关业务 user_pay_gateway；

• 开发/测试/压测/UAT/生产环境的账号要做好区分

比如，开发环境user_dev_xxx，测试环境user_test_xxx，压测环境user_perf_xxx，UAT环境user_uat_xxx

• 禁止在生产环境申请开通个人帐号，也不允许在代码中使用个人账号连接数据库；
• 禁止使用空口令、弱口令；
• 业务账号与管理员账号的权限严格区分，并遵从最小化原则

  比如：业务账号只开放dml权限(即SELECT、INSERT、UPDATE、DELETE)，不给ddl权限；

• 数据库用户的创建、删除和更改工作，并做好记录；
• 对DBA离职或转岗的同事要及时进行权限回收及账号注销；

业务代码

• 禁止无where条件的全表删除

口令安全

复杂度要求

• 服务器必须采用高质量口令，口令中包含大小写字母、数字与特殊字符，并且长度在12字符以上。
• 不得将容易记忆的电话号码、生日、单词等设置为服务器的口令；

更改口令的周期

• 在一般情况下，更改口令的周期为三个月，并且应避免循环使用旧口令；
• 重要的和使用次数多的口令需要缩短更改口令的周期；
• 口令设置不得使用最近3次以内重复的口令，口令重复尝试10次以后应暂停该帐号登录；

口令的管控

• 各级口令保管落实到人，口令所有人须妥善保存，不得以任何形式明文存放于可公共访问的设备中；
• 若发生员工离职或服务器归属变化，应及时更改离职员工所掌握的所有服务器口令；

敏感数据保护

• 无业务场景下，严禁私自查询与工作无关的用户或业务数据；
• 禁止在内部群发邮件、群聊、Github、技术分享时泄露敏感数据，比如密码等；
• 线下环境的数据脱敏

在未脱敏的情况下，禁止将生产敏感数据用于线下测试；
敏感数据包括但不限于：真实姓名、手机号码、邮箱地址、家庭住址、身份证号、银行卡号、交易记录、账号密码等；

• 敏感数据的加密拉取

针对 >1000条 敏感数据的线下拉取，必须经由研发总监、安全、内审等同事的邮件确认之后，再由DBA对数据进行openssl加密之后，将压缩文件和密码单独发送给需求方；

• 硬盘保修及数据销毁

发生故障的硬盘设备，建议物理销毁。若必须交还厂商更换，务必做好数据销毁。
比如，先用0x00覆盖剩余空间，再用0xFF覆盖剩余空间，最后再使用随机数字进行擦写；