阅读量:2
数据库访问安全
专栏内容：
文章目录
概述
数据库作维护着系统的全部核心数据，在黑客眼中，它就是终极大boss，需要我们精心呵护。
常常听到撞库，拖库，甚至于删库跑路等事件，我们在部署和维护数据库过程中如何防范这些风险呢？
本文介绍数据库访问安全保护的一些方式，结合postgresql 数据库中有一些安全功能，同时还需要配合操作系统，以及网络部署的一起达到数据库的安全。
安全体系
在postgresql 数据库中提供了一些安全功能，如基于主机的访问HBA，角色与权限，自主访问控制DAC等，这些远远达不到高枕无忧的程度。
对于单个数据库来讲，需要在网络层，操作系统层，数据库层，以及存储层等多个层次进行体系化的安全部署，才能有一个安全的数据库。
数据库的安全，我们从离客户最近的网络，然后到数据库服务器的操作系统，再到数据库服务，然后到数据的存储，这一路径来划分各阶段的安全策略与方法，构建一套安全体系。
- 网络层，是访问数据的通道；通过配置防火墙策略，限制对数据库服务器的访问；也可以通过代理服务器来进行复杂的过滤；
- 操作系统层，数据库服务所有在操作系统也是多用户的，数据库服务部署采用专用用户，并且配置操作系统级的审计策略；
- 数据库层，最核心的数据库服务层，通过数据库功能进行一些安全控制；如HBA，role, DAC, SSL等等；
- 存储层，对于数据，可以进行各种策略的备份，并且对备份进行安全策略控制；
当然，这一体系只是对于单节点的数据来讲，当然还可以通过主备来对服务进行冗余，达到服务级的安全，这里并没有涉及到。
网络层
一般的大型数据库都通过网络来进行访问，同时一旦经过网络就会经常受到黑客的骚扰，为了限制不安全的网络流量，可以通过以下几种方式。
- 防火墙
在部署的时候首先会部署访火墙的策略，常用的如iptables，精细化的限制访问的IP范围，以及可以访问的协议。
- 监听端口与IP
对于postgresql 的服务端口号默认为5432，一般部署时避免使用默认端口。默认端口，如80，8080，22等等，每天都会被黑客不断扫描探测，根据端口号就可以猜测到服务类型。
如果有多个网卡或者网段时，限制数据库监听的网络或者网卡设备。
- 代理
为了减少数据库服务的管理，可以采用代理服务来处理，客户端请求先由代理服务接收进行精细的过滤，记录，对于通过审查的请求转发到数据库服务。
这样数据库服务可以处在一个相对封闭的网络环境中，只与代理服务进行单一通信，更多网络压力由代理服务进行处理。
操作系统层
数据库部署的机器，一般在安装时都会新建一个操作系统用户，如mysql, oracle，postgresql用户，在此用户下启动数据库服务。
那么在操作系统层面设置安全策略，可以保护数据库服务，以及数据库文件的安全。
- 操作系统用户与权限
数据库服务所在的操作系统用户，一定是非管理员(administrate/root)权限用户，同时要限制它的登陆，使用强的用户口令并定期更新。
同时平常的客户端使用，使用其它操作用户登陆。
- 目录与文件的访问权限
数据库的存储在磁盘的目录与文件，设置合适的权限和访问用户，比如Linux下要去掉other的访问权限，不能设置为 777 这种权限，这个在postgresql 中也会进行检查，当启动服务时为root用户时，会报错，当集群目录权限默认为 0600。
- 操作系统级的审计跟踪
对于像mysql/oracle/postgresql用户的操作，都要进行严格的审计，记录操作，定期检查，当然这些操作可以借助于审计系统软件，进行自动化的运行，可视化展示与自动风险报警。
数据库层
当我们的各种应用连到数据库中时，可以进行select/insert/update/delete操作，也可以进行create/drop/alter，都可以进行这些操作时，就会乱套。
在数据库中有一些精细的控制方法，来划分不同数据库对象的访问权限，来抽象人的管理模式。
- 基于主机的访问控制
在pg_hba.conf文件可以配置不同的应用访问对应的数据库，甚至访问主机对应的数据库用户，以及不同的用户鉴权方法。
hba配置可以更加精细的化分数据库和用户的功能，与应用系统进行对应。
- 角色与权限
在postgresql中的数据库对象，它有很多权限可以设置，如创建，删除，数据的查询，数据修改，数据删除，数据插入等。
通过角色role与对角权限进行管理，将相关权限打包为角色，也就是权限的集合，再统一grant给一类用户。
- 自主访问控制策略
自主访问控制策略DAC，就是通过数据库对角上的权限，与数据库用户所拥有的权限，在用户访问数据对象时进行校验，类型似门禁一样，只有用户拥有访问权限才会执行操作，否则会失败。
权限的管理由超级用户postgres和拥有admin权限的用户进行初始创建，后面可以通过owner进行扩展和传播，当然也可以限制权限的继承传播。
- 传输层加密 TSL/SSL
在postgresql 中可以配置传输层的通信加密，在服务端和客户端配置 SSL证书，通过TSL来验证服务和加解密通信数据。
- 数据的加密
通常存储在磁盘的数据是明文，丢失很容易被解析出来。通过postgresql中内置的加密接口，对敏感的数据列进行加密存储，提供了常用的加密算法。
- 数据库的审计
以上都是静态的防护策略，在数据库服务运行过程中，需要时刻关注它的运行状态，谁访问过那些数据等，这就需要数据库审计系统的配套，记录访问路径，并对记录进行分析，及时识别风险主动报警或者阻断。
存储层
鸡蛋不能放在一个篮子里，同样数据不能只有一份。在postgresql 中提供了多种备份方式，在备份的基础上可以对备份进行安全控制。
- 备份
在postgresql 中有基于流复制备份，还有基于逻辑复制的备份，还有数据导出方式的备份。
当然也可以将这些方式组合使用，生成最新的全量数据备份，也可以是某个时间点的数据，然后定期进行备份，这样可以产生一系列的数据备份，同时定期归档很早之前的备份版本。
- WAL归档
在postgresql数据一致性最重要的一环是WAL，当然也可以通过对WAL归档来进行数据的备份，因为通过WAL可以恢复出来当前的数据。
- 备份的加密
对于敏感数据的备份，同样可以选择加密，并且口令强度检查，口令定期更新。
- 备份文件隔离与访问控制
很多时间，我们备份的数据文件与原数据在一台机器上，这其实也是不安全的，会有同时损坏的概率。
一般多份备可以放到不同的区域，这个区域是不同的机器，甚至不同的机房，地区，达到物理上的隔离。
总结
数据库处于应用的底层，因为它存储着最核心的数据，所以它安全被渐渐重视了起来。 数据库本身的安全，并不是完全靠数据库自身来独立完成，它需要从网络，操作系统，数据库，存储等多个维度采用综合的策略来防护。
同时也需要一些主动防御方式来检测和分析，如数据库审计，对数据库日志定期分析，它们也是数据库安全体系的一部分。
本文结合postgresql数据库来分享了数据库安全的体系，让大家能了解数据库自身的策略所处的位置。
结尾
非常感谢大家的支持，在浏览的同时别忘了留下您宝贵的评论，如果觉得值得鼓励，请点赞，收藏，我会更加努力！
作者邮箱：study@senllang.onaliyun.com
如有错误或者疏漏欢迎指出，互相学习。
注：未经同意，不得转载！
