从数据库层谈安全措施

数据库是系统开发中必不可少的，也是非常重要的，所有的数据都在数据库中存储。数据库泄露或者遭到损坏，那损失是不可估量的。大家都是程序员，数据库的重要性就不必多说了。软件都是为了数据服务的，数据是核心。

接下来说说如何确保数据库安全的。

序

安全是为了什么？安全是为了应对风险。就来 看看有哪些风险，然后面对这些风险，我们可以怎么从技术角度或者其他的角度去避免风险。我说的不一定是最好的方案，也不一定是最全的方案，就想到哪说道哪吧，有大佬欢迎指正补充。

一、数据库账号密码泄露，外部人员登录数据库窃取信息

有人向我提问，在代码中明文存储，感觉不太安。全万一泄露了，可能 导致的风险。该如何应对呢？

1、数据库使用白名单，除白名单内的ip，一律禁止访问

这个方案就很大程度上限制了数据库的访问对象，只允许服务器过来的请求进行访问，这样即使用户名密码泄露，用处也不大。毕竟连不上数据库，直接给限制死了。伪造ip?不会的，在一个网络中ip是唯一的，服务器已经占用了，你在修改ip也不成。ip就是唯一的身份证明。

那如果能登录服务器呢？能够登录服务器，就说明服务器的密码泄露了。同样的，服务器也可以设置白名单，远程连接时需要认证。当然，服务端口80/443 这些是程序的，这些是对外提供程序服务的。这里所说的ip限制，是指远程登录。

2、数据库内容加密存储

这个数据库存储什么内容，完全取决于程序怎么写的。正常可以存储明文信息到数据库，也可以存储密文信息到数据库。那么程序中，完全可以采用对称加密的方式，先将数据进行加密，然后存储到数据库里。取出数据的时候，再进行解密。对于程序来讲，是完全可以掌控数据内容的，但是对于单纯的数据库来讲，是看不懂里面存储的内容的。这样也很好的防止了数据的泄露。

3、使用配置文件

数据库连接所用的用户名、密码、连接地址，这些都可以放到配置文件中。放到配置文件中去的好处就是，方便在程序外部 修改，而不用重新打包。结合上一条，这样做也起到了开发与运维分离的作用。开发人员写好的程序，将数据库脚本交给运维。运维人员创建好数据库后，修改配置文件就可以了。运维人员管理数据库，但是不知道程序中对数据的加密规则是什么，所以看到数据也没啥用。开发人员知道加密规则是什么，但是不知道正式服务连接数据库的地址和用户名密码，也连不到数据库。

4、使用一些数据库中间管理服务

有时候也不是直接进行数据库连接的，而是有数据库中间服务。数据库的信息开发人员也是接触不到的，开发中只是在程序中引入封装好的jar包，配置一下数据库服务创建数据库产生的一些名称和其他内容。开发人员全程不需要数据库连接字符串、用户名、密码。数据库都进行统一管理。

5、数据库访问权限

经过朋友一提醒，我是忘了很重要的一点。数据库是可以创建用户的，创建的用户是可以有不同权限的。连接用的账号密码不能是最高权限。可以限制对数据库的操作。不可以使用系统管理员账户进行数据库登录操作，系统管理员也不是谁都可以登录的。由数据库系统管理员创建账号，分配权限给不同的人使用。

6、其他的一些措施

可能还有一些其他的措施，等大佬补充

当然，千防万防，家贼难防。最大的安全隐患不是程序，而是人。这就是对人员如何管理了。

二、数据库损毁，数据丢失

程序届常说的一个段子叫 ”删库跑路 ”，对公司不满或者公司不干人事，出于对公司的报复就把数据库给删了（当然不建议这么搞，是要坐牢滴。最好是默默收集证据，有了证据然后法律诉讼，曝光媒体）。由于人为的或者非人为（打雷劈了，地震埋了，大火烧了）的一些原因，数据库损毁。

1、异地备份

数据库进行数据热备，而且是异地的。要是在一个机房里，一把大火全团灭。虽然我们天天的上网，写程序的也天天的使用着云服务器，但是服务器总是有个地方放着，总是有个物理的机器在那。那么防止数据丢失损毁的最好办法就是备份，而且是多地备份。一主多从，有一台挂了，切换到另一台继续使用。

2、其他方法

很遗憾，我就知道一种方法，就是备份。备份是防止数据丢失损坏的最好办法，没有之一。

以上是从数据库的角度考虑安全问题，当然，一个成熟的系统要考虑的安全问题还有很多，那就是服务端代码的事情了，这里不展开说了。

传送门：
MySQL数据库优化一、影响数据库服务的因素

MySQL数据库优化二、硬件与操作系统

MySQL数据库优化三、MySQL体系结构与存储引擎 上

MySQL数据库优化三、MySQL体系结构与存储引擎（下）

MySQL 事务隔离级别