在线业务的人都不想冒数据库受到损坏的风险。接下来，我们将介绍一些实用的办法，你可以利用这些办法来保护MySQL数据库，以便加强网站的安全性。
二 保护 *** 作系统
确保 *** 作系统的安全是保护数据库安全的前提，因为如果整个运行环境不安全，那么网站上所有的东西都脆弱，很容易暴露于攻击者。为了维护 *** 作系统和MySQL服务器，你可以使用以下方法：
2.1 主机数据库服务器和web服务器分别在不同的物理机器上，如果可能，在一个单独的服务器上运行数据库服务器，以预防由其他应用程序或服务的漏洞造成的服务器问题。
安装杀毒软件，防火墙以及所有推荐的补丁和更新，防火墙能有效地把流量过滤到MySQL服务器。为了更好的提高安全性，你还可以实行入口封锁。
禁用所有不必要的服务，而且这样的服务越少越好。
2.2 保护所有帐户和密码
攻击者侵入MySQL数据库最常见的一种方法是窃取有安全隐患的账户信息。为了降低出现这种风险的可能性，你不妨试一试下面的方法：
2.2.1. 给所有MySQL账户设置密码
客户程序并不是每次都能识别用户，因此，如果用户知道数据库名但是没有这个用户名的密码，那他可以指定任何其他用户名连接到MySQL数据库。让每个MySQL用户名都设置密码，这样一来，要想利用匿名账户建立连接将会变得很困难。
2.2.2. 不要使用根用户运行MySQL服务器
在安装MySQL的时候，默认情况下创建了一个命名为“root”的管理用户。每个人都知道这一点，所以攻击者通常试图侵入这个“root”用户来获取访问权限。为了保障这个重要帐户的安全，你需要给它重新命名，然后更改一个长并且复杂的密码。
2.2.3你可以在MySQL控制台使用mysql>RENAME USER root TO new_username
指令给根用户重命名，使用mysql>SET PASSWORD FOR 'username'@'%hostname' =
PASSWORD('newpassword')//这是很重要的一条命令
指令来修改密码。
三. 减少管理员账户
管理员账户越多，风险越大，所以你应该保持尽可能最少的帐户数量，只有为那些真正需要它的人创建账户。此外，记得要删除未使用的和匿名的账户。如果你有很多管理员账户，那你需要定期检查并清理那些不必要的账户。
四. 加强所有的密码
除了管理员帐户，你还需要加强所有其他用户的密码。你可以检查所有的用户名和密码，必要的时候你还可以重置安全强度低的账户密码。虽说这样做会有点费时，但却是有必要的。
五 限制数据库权限
每个用户都应该被授予适当的权限以便数据库能够正常运行，但这样一来也加大了数据库的安全隐患。就数据库权限而言，我们有以下几点建议：
5.1. 不要授予非管理员用户文件/高级/程序权限
文件，高级和程序权限都不应该被滥用。文件权限让用户可以在文件系统中的任何一个地方编写文件，而程序权限让用户在任何时候都能够查看服务器活动，终止客户端连接甚至更改服务器 *** 作。为了你的数据库安全，这些权限只能授予给管理员账户。
5.2. 限制或禁用显示数据库权限
显示数据库特权可以用于收集数据库信息，所以攻击者通常利用它来窃取数据并准备进一步攻击。你应该把这个权限授予那些真正需要的人，或者直接禁用这个权
限，你只需要把skip-show-database添加到MySQL数据库中的/etc/my.cnf配置文件中。对于Windows *** 作系统来说，则
需要添加到my.ini文件中。
5.3. 限制管理员和所有其他用户的权限
即使是管理员，也不要在同一账户中授予所有权限。因此我们建议你最好降低管理员账户访问数据的权限。至于其他的用户，你最好检查所有他们拥有的权限，以确保一切都是合适的。
六 删除风险组件
MySQL数据库的默认配置有一些不必要的组件，你可以考虑以下建议：
6.1. 禁用LOAD DATA LOCAL INFILE指令
这个命令允许用户读取本地文件甚至访问其他 *** 作系统上的文件，这可能帮助攻击者收集重要的信息并利用应用程序的漏洞侵入你的数据库。你需要做的是把set-variable=local-infile=0插入到MySQL数据库的my.cnf文件中，来禁用这个指令。
6.2. 删除测试数据库
有一个默认的“测试”数据库用于测试目的。由于这个数据库有安全风险，匿名用户也可以访问，你应该使用mysql>DROP database test指令尽快把它清除掉。
6.3. 删除历史文件
MySQL服务器有一个历史文件，它可以帮助你在安装出错的时候找到问题所在。历史文件包含敏感信息，比如说密码，如果这些信息被攻击者获得，那么将会给
你的数据库带来巨大的安全隐患。在安装成功后，历史文件并没有什么用，因此你可以使用cat /dev/null >
~/.mysql_history指令来删除文件当中的内容。
七 限制远程访问MySQL服务器
对于大多数用户来说，不需要通过不安全的开放网络来访问MySQL服务器。你可以通过配置防火墙或硬件，或者迫使MySQL只听从localhost来限制主机。此外，需要SSH隧道才能进行远程访问。
八 如果你想仅仅从本地主机来限制用户建立连接，你需要在在配置文件中添加bind-address=127.0.0.1。
8.1利用日志记录
启用日志记录让你可以检测服务器上的活动，这样你就可以分析失败的登录尝试和敏感文件的访问记录，以便了解是否存在向你的服务器和数据库发起的恶意活动。
你只需要把log =/var/log/mylogfile指令添加到MySQL配置文件中，就可以手动启用日志记录功能。
8.2至于日志记录，需要注意以下两点：
8.2.1日志记录仅适用于查询数量有限的数据库服务器。对于信息量大的服务器，这可能会导致高过载。
8.2.2由于“hostname.err”文件包含敏感数据表名和密码，只有“root”和“mysql”才有访问和记录这个文件的权限。
MariaDB概要介绍MariaDB是MySQL数据库的一个分支版本，该版本主要是通过开源社区进行维护，MariaDB可以完全兼容MySQL（包括API和命令），主要区别在于存储引擎使用了XtraDB代替了InnoDB。
安装MariaDB软件包
通过一下命令进行安装：
# apt install mariadb-server python-pymysql
配置mySQL服务启动参数,为后续安装openStack提前准备好数据库环境
创建启动参数配置文件：/etc/mysql/mariadb.conf.d/99-openstack.cnf
输入如下内容：
[mysqld]
default-storage-engine = innodb
innodb_file_per_table
max_connections = 2048
collation-server = utf8mb4_general_ci
character-set-server = utf8mb4
重新启动mysql数据库服务
使用一下命令重启mysql
#service mysql restart
如果没有异常情况，则不会有任何输出，这时候可以使用如下命令查看服务运行状态
#service mysql status
启动mysql异常提示无效的字符编码问题处理
在步骤3创建的配置文件由于参数的名称输错导致启动失败，提示不支持utf8_general_ci
[mysqld]
default-storage-engine = innodb
innodb_file_per_table
max_connections = 2048
collation-server = utf8_general_ci
character-set-erver = utf8
启动MySQL服务失败这时候可以通过命令以下命令查看具体原因：
systemctl status mysql.service
通过检测发现character-set-erver参数名输错了导致启动失败，将其改为
character-set-server = utf8 即可
给mysql进行安全加固
使用脚本 mysql_sercure_installation进行mysql数据库安全加固
# mysql_secure_installation
启动脚本后按提示进行安全加固 *** 作即可完成
使用mysql命令行连接mysql服务，验证mysql服务是否正常
#myslq -uroot -p
输入root密码即可连接到本机的mysql服务
使用IP地址方式连接和管理MySQL
使用如下命令进行连接MySQL发现连接异常(192.168.122.1为本机的IP地址)
#mysql -h192.168.122.1 -uroot -p
输入密码后发现连接失败，原因是因为我们配置的mysql服务参数中没有绑定IP地址，系统默认使用了local主机名进行，那么通过参数设定绑定IP地址即可
修改启动参数配置文件：/etc/mysql/mariadb.conf.d/99-openstack.cnf，增加IP地址绑定
[mysqld]
bind-address = 192.168.122.1
default-storage-engine = innodb
innodb_file_per_table
max_connections = 4096
collation-server = utf8_general_ci
character-set-server = utf8
迁移MySQL数据库通常只需要几个简单的步骤，但是由于您要转移的数据量可能比较庞大，因此一般耗时也会比较长。
下面的步骤将指导您如何从旧的服务器上导出MySQL数据库，对它进行安全加固；然后将其复制并导入到新的服务器上，以保证数据的完整。
将MySQL数据库导出至转储文件（dump file）
Oracle提供了一个名为mysqldump的工具，允许您轻松地将数据库结构和其数据导出到一个SQL的转储文件。您可以使用如下的命令：
1.mysqldump -u root -p --opt [database name] >[database name].sql
不过，请注意如下几点：
我们可以使用--single-transaction的标志，以避免数据库在导出数据的过程中被锁死。这样能够在将数据导出到转储文件的同时，您仍可继续在旧的数据库上更新数据。不过请注意，那些在导出进程已经开始之后被更新的数据，是不会被导入转储文件之中的。
在运行该命令之前，请务必将[database name]替换成您的实际数据库名称。
请输入您自己的用户名和相对应的密码，并确保该用户具有备份数据库所需的权限。
安全加固备份文件
在大多数情况下，数据是一家企业的最重要的资产。因此，我们不希望数据库的各种备份被暴露在不受保护的服务器上，因为这样有可能会造成错误地泄露，甚至会出现被黑客窃取等更为糟糕的状况。
因此，通常您可以尝试的做法是：压缩、加密文件，然后删除原文件。在Linux *** 作系统上，请使用以下的命令对已压缩文件进行加密：
1.zip --encrypt dump.zip db.sql
在压缩开始之前，系统将提示您输入密码。
传输备份文件
至此，我们已经获得了一个加密的转储文件。下面让我们通过网络使用SCP命令，将其传输到新的服务器上：
1.scp /path/to/source-file user@host：/path/to/destination-folder/
将MySQL转储导入新服务器
通过上面一步，我们已将备份文件传到了新的服务器上，下面让我们来进行解密和提取：
1.unzip -P your-password dump.zip
为了存储空间和安全方面的原因，一旦文件导入成功，请记得删除其对应的转储文件。
您可以使用以下的命令来导入文件：
1.mysql -u root -p newdatabase </path/to/newdatabase.sql
在新服务器上验证导入的数据
现在我们在新服务器上已经导入了数据库，那么我们就需要一种方法来验证数据的真实存在，并确保没有任何遗漏。
我建议您同时在旧的和新的数据库上运行如下查询，并将获得的结果进行对比。
该查询会在所有的表里计算行数，以显示出新、旧数据库中的数据量。
1.SELECT
2.TABLE_NAME,
3.TABLE_ROWS
4.FROM
`
5.information_schema`.`tables`
6.WHERE
`
7.table_schema` = 'YOUR_DB_NAME'；
此外，我建议您检查各个表中数字列的MIN和MAX记录，以确保数据本身是有效的，而不仅仅是看数据的总量（虽然这是查询所唯一能够读出的值）。另一种可供测试的选择是将数据库从新的服务器导出为SQL转储文件，并将其与旧服务器的SQL转储文件做比较。
此外，在应用程序被迁移之前，我建议您先将一个应用程序的实例重定向到新的数据库上，以确认一切运行正常。
另一种导出和导入的选项
我们之所以把该选项放在最后，是因为我们的确不建议您去使用它。
该方法实现起来非常的容易，因为它仅使用一个命令，便能一次性将转储文件导出、传输、并将其数据导入到新的数据库之中。
而它的不足之处在于，一旦其网络链接断掉，您就需要重新启动它了。
因此，我们认为它并不值得被推荐，尤其是在大型数据库中，可能会非常不适用。
当然，如果您非要尝试一下的话，可以使用如下的命令：
1.mysqldump -u root -pPassword --all-databases | ssh user@new_host.host.com 'cat - | mysql -u root -pPassword'
重要提示
请确保在新旧两处，安装有相同官方发行版本的MySQL服务器。否则，你需要按照MySQL网站上的升级说明来进行统一（请参见（https：//dev.mysql.com/doc/refman/5.7/en/upgrading.html）。
请确保您在旧的服务器上拥有足够的空间来保存转储文件和压缩文件（应该有db_size×2的空间）。
请确保您在新的服务器上拥有足够的空间来保存加密的和解密的转储文件、并能导入数据库（应该有db_size×3的空间）。
如果您曾经考虑过只是将datadir从一个数据库转移到另一个的话，我建议您最好不要这样做。否则，您会搞乱数据库的内部结构，而且会给将来可能的问题埋下隐患。
在新的服务器配置中，请不要忘了配置诸如innodb_log_file_size这样的重要标志。因为如果忘记了根据新服务器的规格而更新配置的话，很可能会导致严重的性能问题。
在许多情况下，一般升级到新的数据库服务器的初衷是为了提高查询性能。而如果此类升级没有达到预期的改善，那么您就应该考虑去优化SQL查询，而不仅仅是升级硬件那么简单了
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）