2022
我们一起努力

技术干货|RDS PostgreSQL 安全最佳实践

内容简要:

一、PostgreSQL行业位置

二、数据安全大事件

三、数据库安全体系

四、PostgreSQL最佳实践案例

一、PostgreSQL行业位置

(一)行业位置

首先我们看一看RDS PostgreSQL在整个行业当中的位置,主要从以下4个方面去阐述,第一是整个阿里云数据库在数据库领域的位置,第二是PostgreSQL在数据库行业的位置,第三是PostgreSQL在全球数据库领域的位置,最后我们看看它应用到哪些行业。

阿里云数据库是2019年Gartner的挑战者,2019年Forrester的强劲表现者。2020年,阿里云数据库挺进全球数据库魔力象限领导者,这是阿里云数据库在数据库行业的位置。

在2020年的PG亚洲大会上,阿里云数据库专属集群MyBase被评为“PG年度最佳产品奖”。

PostgreSQL连续三年被评为最佳的数据库,在开源社区的话是排行第二,在所有的开源以及闭源产品中排名第四,并且广泛应用到计算机信息技术、金融领域以及高等教育等众多领域。

(二)RDS PG VS 自建PG

下面我们看一下RDS PG相对于传统的自建PG,或者ECS上社区的PG,它的优势在哪里?

总结起来大概有4个方面,RDS PG取得了绝对的领先。第一是可靠性,第二是安全性,第三是智能化,最后一个是支持丰富插件,这四点是远远领先于ECS自建PG。

可靠性体现在三个方面,第一个是Failover Slot能力,它保证发生HA切换时数据订阅的延续性。第二个是Standby支持多上游结点的特性,假设我们今天建立了读写分离的场景,主实例在发生HA切换的时候,那么只读实例不会有任何数据缺失,所有数据增量同步数据都会保持。第三个是RDS提供了一键大版本升级的能力,每个版本都可以直接向上升到最高版本,目前我们支持了10个版本的向上升级能力,并且用户只需要在控制台点一个按钮即可,后端的事情由我们完成,这是一个远超自建PG与友商的功能。

在安全性方面,我们支持BYOK的方式做落盘加密。其次是SSL链路加密,最后是SGX全加密的能力,我们在这三个方面的安全能力相比自建PG有很大的优势。

在智能化方面,我们借助DAS诊断优化的能力,帮助用户做问题的自发现、自诊断、自优化以及自决策。

在插件方面,我们提供了Ganos插件,做时空数据的存储、检索以及查询分析;PASE支持高效向量检索;oss_fdw既可以实现数据的冷热分离,又可以帮用户节约成本。

通过以上对比我们可以得出一个结果,就是RDS PG在可靠性、安全性、智能化、插件丰富度方面优势明显。

二、数据安全大事件

(一)安全大事件

接下来我们看一下近几年发生的安全大事件。

2017年1月、9月,黑客通过在互联网上扫描开放外部连接的MongoDB数据 库,入侵了超5万台服务器,删除数据并留下勒索信息。

2017年1月,“Gitlab误删库事件”导致300GB数据被误删,差不多6小时 的数据丢失, 影响约5000个项目,5000个评论和700个新用户账户。

2018年,国内某知名连锁酒店数据以8个比特币在暗网转卖,其中包含了1.3 亿条个人信息、2.4亿条酒店入住登记信息。

2020年2月,因公司内部员工恶意破坏线上生产环境数据,导致服务不可用超过120小时,股价暴跌22%,市值缩水超30亿港元。

(二)数据泄漏对企业的影响

下面我们看一下数据安全可能会给公司造成什么样的后果。

2020年IBM《数据泄露年度报告》显示,全球数据泄露事件达到3932起,泄露数据记录数大概是370亿条,平均单次泄露事件造成的损失大概是386万美元,涉事上市公司平均股价下跌7.27%,基本可以算是暴跌。

各个国家针对安全事件也出了一些法律法规,如欧盟的《GDPR》以及中国的《数据安全法》、《民法典》。

介绍完以上安全事故,以及给企业带来的严重后果,接下来我们看一下RDS PostgreSQL如何帮助用户保障数据安全。

三、RDS数据库安全体系

(一)功能大图

这里我们将传统/自建/线下IDC用户的数据库和RDS数据库保障安全的方式做了一个对比。首先我们看一下自建数据库的安全措施,基本上有三个维度,第一是数据库运维,第二是数据库内核,第三是备份恢复。

针对于数据库运维,是通过白名单、DBA授权以及客户端直连的方式,几乎没有安全可言。

数据库内核方面,通过账号权限、DBA巡检以及应用防范去保障安全。

数据库备份是通过备份脚本,做本地备份,备份到当前的机器;通过脚本对备份集进行校验。

以上就是传统线下自建数据库的安全措施,下面我们看看在阿里云是怎么打造云数据库安全体系的,如上图右边所示。

我们主要从两个链路来构建云数据库安全体系。第一是从控制链路,做到了事前防范、事中保护和事后的审计;第二个是数据链路,从接入层、网络层、代理层、引擎层和存储层打造数据链路安全。

事前防范有安全风险预警,可以给用户提供很多安全提醒;事中保护是由RAM鉴权与子账号的方式来控制用户的权限;事后审计是通过管理审计日志的方式来做安全的审计。

在数据链路方面,可以分为5层,分别是接入层、网络层、代理层、引擎层和存储层。

自上而下看的话,我们在接入层有云盾、堡垒机、DMS系统以及RAM授权,在管理方面有管理审计日志。

在网络层有VPC、安全组、白名单、SSL链路加密与API操作审计等。

在代理层我们做到了防暴力破解,防SQL注入,登录审计以及SQL审计。

引擎层包括账号权限控制,ACL加密和TDE日志等。

最后在存储层,我们也有非常多组合的安全保护机制,比如BYOK,备份加密,云盘加密和SGX全加密。

从对比来看的话,阿里云的数据库安全体系是全方位、多角度对,做到了滴水不漏。

(二)全链路生命周期

下面我们看一下在安全大图的基础上,怎么对全链路生命周期做安全的保护。

首先在登录数据库的时候,我们是通过身份的识别,比如白名单,必须要在白名单里的IP或者在IP段里rds云数据库,才可以登录到数据库。并且还要做权限验证/认证以及用户密码强校验。

登录到数据库进行数据传输的时候,我们通过VPC、安全组、SSL以及HTTPS做链路加密。

接着在数据处理的时候,通过数据的隔离,如权限管理,加/解密计算以及数据脱敏等操作来实现数据处理的安全性。

数据处理完以后要进行数据交换,我们通过交换的管控,如权限管理,数据清洗以及数据脱敏。

在存储层有刚才提到的BYOK,云盘加密,备份加密以及SGX全加密。

最后一环也是大家比较容易忽视的一环,就是数据删除的时候也有安全风险。我们通过文件的物理销毁,比如把数据完全抹掉,备份文件全部清除,元数据也要全部清除。

通过以上方式,就可以做到全链路生命周期的安全管控。

(三)最严格的安全合规

接下来通过一个典型的例子,看RDS如何去做事前防范,事中保护以及事后审计。

最上面Computer & Mobile Apps表示端这一层,我们可以通过手机的APP、电脑或者平板的方式连接到后台应用所在的ECS,ECS到数据库这一层我们提供了SSL的链路加密,防止客户端或服务端的中间人欺诈的风险,中间会穿过防火墙(IPFilter),然后到达RDS的Proxy。到了Proxy以后,Proxy和RDS也是一个SSL链路加密。

在RDS上有两种形态的存储,分别是本地存储和云盘存储。这两种存储我们都提供了存储层的加密,如TDE、SGX全加密以及BYOK落盘加密,以上就是访问的整个链路。

在RDS这一层,数据库备份是通过远程脱机备份到OSS中,不会备份在本地,也就是说今天的备份文件并不会因为这台物理机挂掉或者出现故障,而导致备份文件找不到,因为我们是远程脱机实时地以全量加增量的方式备份到OSS上,可以保证用户数据有一个保底的备份文件。

当然,我们所有的操作日志以及SQL审计都会存在SLS里,这样就可以做到事后审计的能力。

总结来看,RDS在事前防范有权限控制、用户名和密码、ACL、白名单以及VPC/SG。权限控制表示用户权限的管控,用户名密码的强匹配、完全匹配以及访问控制。白名单方面,我们只允许开了白名单的IP或者IP段的用户能够连接到RDS上。在网络方面,我们将用户的ECS和RDS所在的VPC/SG保持一致,才能够让用户连接到我们的RDS上面,做到了网络隔离。

事中保护方面,我们提供了SSL证书防中间人欺诈,TDE的透明数据加密,防止拖库。SGX全加密是基于可行硬件的全加密的数据库,BYOK是用户自带的密钥,基于这个密钥对数据进行落盘加密。BYOK支持直接用KMS Key的方式,备份加密可以把数据库备份文件进行加密,哪怕我们的备份文件被别人拿到,对方也无法还原出我们的数据。

事后审计是通过SQL审计以及API审计来做的。

综上来看,RDS数据库满足最严格的安全合规要求。

四、PG 安全最佳实践

(一)RDS PG SSL链路加密

第一个安全实践案例是SSL链路加密。

PG的SSL链路加密非常强大,主要有6大适用场景,可以做到防服务端伪装;防客户端伪装;还可以做到既防服务端,又防客户端伪装;当用户证书过期的时候,我们提供证书更新的能力,除此之外,还可以配置ACL。当用户客户端证书泄露rds云数据库,或者用户怀疑自己的客户端证书泄露了,我们提供吊销客户端证书的功能,拒绝有证书泄露风险客户端登录。

具体展开的话,在防服务端伪装方面,我们提供了两种类型的证书,分别是阿里云颁发的服务端证书与用户自定义服务端证书。

在防客户端伪装方面,可以用服务端去验证客户端证书的真伪,也可以通过清除客户端证书来更新证书。

防服务端、客户端伪装实际上实现的是客户端验证服务端真伪,服务端验证客户端真伪,是一种双向验证的安全保护。

证书更新原理比较简单,就是先把证书清掉,然后再重新启动,就可以实现证书更新。

ACL是控制客户端的访问,吊销证书就是针对有泄漏风险的证书,我们可以一键吊销,并拒绝这样的客户端证书登录。

(二)连接启用SSL PG Demo

下面举一个例子,假设我们今天在RDS上面启用了客户端证书和服务端证书的时候,我们该如何访问这样的RDS实例?

这个地方的话我会分三个场景来介绍,第一是用pgAdmin客户端的时候该怎么做,第二个是用PG SQL命令终端的时候该怎么配,最后是应用程序如何连接启用了SSL防伪装功能的RDS PG。

首先是第一个场景,pgAdmin配置三个地方,General tab设置连接名字,Connection是设置RDS的连接字符串、用户名密码,而SSL Tab页面里面要配置4个东西,分别是SSL mode、Client certification、Client certification Key和Root certification,如下所示。

通过这样的方式,pgAdmin客户端就可以连接到RDS实例上了。

第二个场景是psql命令终端,需要配置5个参数,分别是:

PGSSLCERT:SSL客户端证书​PGSSLKEY:客户端证书密钥PGSSLROOTCERT:SSL根证书PGSSLMODE:SSL安全连接模式

例如:

设置好这些参数以后,就可以去连接RDS实例。我们可以看到红色框里面表明已经启用 SSL的安全隧道了,会有SSL Connection的提醒,而且有protocol表示这是TLSv.1.2的版本。

下面是用户比较关心的,就是启用以后应用程序该怎么写,JDBC应该怎么样设置,这里最开始做的时候是有一点门槛的,有几个参数设置:

如下所示:

(三)SGX全加密概念

接下来我们看一下SGX全加密,它分为三个层次,第一个是端,端看到的是明文,不管是SQL语句还是最终数据都是明文。

中间链路层的话,它的SQL语句都是加密的,反馈回来的数据也是加密的。

存储这一层也是全加密的,哪怕是一个超级账号使用者,拿到了数据库所有的访问权限,进去看表的数据,看到的也都是密文,不知道它里面的信息。

第三层我们画了一个问号,表示这个人想要去看的时候,在链路这一层以及数据库存储这一层,都看不到明文的数据,只有我们授信的这些端才可以看到这个明文的数据。

赞(0)
文章名称:《技术干货|RDS PostgreSQL 安全最佳实践》
文章链接:https://www.fzvps.com/54009.html
本站文章来源于互联网,如有侵权,请联系管理删除,本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。
图片版权归属各自创作者所有,图片水印出于防止被无耻之徒盗取劳动成果的目的。

评论 抢沙发

评论前必须登录!