等保2.0涉及的PostgreSQL

等保2.0涉及的PostgreSQL

一、数据完整性

1.应采用校验技术或密码技术保证重要数据在传输过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等

针对于传输过程中数据的完整性具体概念这里就不多阐述了，网上一些资料已经写得比较清楚了，大致意思就是数据发送前后要有一个检测机制，确保数据发送前和接收后的一致性。

针对数据库系统来说，需要考虑的数据有：

鉴别数据、重要配置数据、重要业务数据、重要审计数据、重要个人信息等

然后，传输过程中的完整性一般是通过通信协议来实现的，一般常见的包括TLS、SSH等协议，具体到数据库这个测评对象来说，就是去查看它是否启用了SSL进行了数据通信，当然最好询问下管理人员，确认是否还有其他保证数据传输过程中的完整性措施。

具体的配置就略过了（后期待补充），这里介绍了如何开启SSL管理。

针对这个测评项，我们先去查看$PGDATA目录下的postgresql.conf文件，确认是否已经启用SSL：

然后再去确认pg_hba.conf文件中，是否规定了ssl连接的认证规则：

确保配置的连接地址没有漏网之鱼（可不采用ssl连接的地址）就可以了。

2.应采用校验技术或密码技术保证重要数据在存储过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等

针对存储过程中的完整性保护，用简单的方式来说就是你如何去判断一个重要文件是否为初始的可信状态，没有被恶意篡改、删除或新增等，要有这种完整性检测机制。一般通过对比文件前后的哈希值来判断重要文件、数据是否被篡改。

针对数据库系统来说，需要考虑的数据有：

鉴别数据、重要配置数据、重要业务数据、重要审计数据、重要个人信息等

譬如我们需要对数据库配置文件进行一个完整性检测，我们就需要配置文件初始可信状态时的哈希值，然后再根据目前的文件生成一个哈希值，对比前后的一致性，确认数据是否被篡改过。

下面是一个客户的实例，他对服务器上的一些重要文件进行了完整性校验，具有期望和当前的比对机制。

这个一般数据库自身不带这种机制，得询问管理人员是否使用了第三方软件对数据库重要数据进行了完整性校验。

二、数据保密性

1.应采用密码技术保证重要数据在传输过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等

这个条款的意思就比较清楚了，就是让你对重要数据进行加密传输。

一般针对数据库需要考虑

鉴别数据、重要业务数据、重要个人信息等

1.1 鉴别信息

首先我们要去看pg_hba.conf文件中METHOD的配置信息

传输相关的参数大致有下类三个：

SCRAM-SHA-256

这是一种挑战-响应架构， 可防止密码在不可信连接上嗅探，并支持以密码散列的形式将密码存储在服务器上， 这种形式被认为是安全的。

MD5

方法md5使用自定义安全性较低的质询-响应机制。 它可以防止密码嗅探，并避免以纯文本形式将密码存储在服务器上， 但如果攻击者设法从服务器窃取密码哈希，则不提供保护。而且， MD5哈希算法现在不再被认为对于确定的攻击是安全的。

password

是以明文密码传送给数据库，建议不要在生产环境中使用。

这里举例一个以MD5传输的例子：

未开启SSL时，我通过Wireshare对数据库认证过程的数据包进行抓取，发现传输的密码字段信息

官方文档的说明为质询-响应机制。

尝试密码使用‘123456’，传输的并不是123456的MD5值，具有一定的保密性。

当开启SSL时，我们再抓包，发现啥都看不懂了

1.2 重要业务数据、重要个人信息

未开启SSL时，我这里进行执行一条查询语句 select * from pg_shadow;

通过wireshark抓包，一些重要数据将会被窃听

在包里我们能找到执行的SQL语句，和语句执行后的输出结果显示，所以这并不安全

开启SSL后，执行上面相同的操作，发现也是啥也看不懂了

总结：

1.查看postgresql.conf、pg_hba.conf文件确认是否开启SSL管理，如果开启均符合。

2.未开启SSL情况下，去查看pg_hba.conf文件METHOD字段的配置信息

鉴别数据：METHOD值为SCRAM-SHA-256、MD5时鉴别数据传输过程中具有保密性，当值为password时，为不符合

重要业务数据、重要个人信息：未开启SSL，不符合。

当然不排除有其它可实现的手段，具体的可以找系统管理人员确认。

2.应采用密码技术保证重要数据在存储过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等

2.1 鉴别数据

我们可以使用password_encryption命令可以查看存储密码使用的算法，默认为MD5。

然后去查看用户口令存储的表：select * from pg_shadow;

口令存储对应为passwd字段值

● 该算法的保密性

在网上搜索了一下，都是说pgSQL口令存的是用户名+口令的MD5值，但具体是一个怎样的存储规律并没有明说，这里经过自己测试，终于知道它是如何存储用户口令的。

为口令+角色名的MD5码，口令在前，角色名再后。

首先，我们创建两个用户，进行测试：
create role est password ‘12345678t’;
create role st password ‘1234567te’;

然后去表中查询它们的MD5值

可以看出passwd字段相同，未加salt，通过解密可以得到明文

2.2 重要业务数据、重要个人信息

这个一般去询问数据库管理员，是否对相关信息进行加密存储。

如果加密了，叫他帮你打开下对应表截图取证即可。

三、数据备份恢复

1. 应提供重要数据的本地数据备份与恢复功能

1.1 自带命令

一般就类似于mysqldump，用这种方式，客户很有可能就是将他写进脚本里面，然后通过计划任务定时执行备份脚本。

1）pg_dump
SQL 转储方法的思想是创建一个由SQL命令组成的文件，当把这个文件回馈给服务器时，服务器将利用其中的SQL命令重建与转储时状态一样的数据库。 PostgreSQL为此提供了工具pg_dump。这个工具的基本用法是：
pg_dump [connection-option…] [option…] [dbname]

dbname
指定要被转储的数据库名。如果没有指定，将使用环境变量PGDATABASE。如果环境变量也没有设置，则使用指定给该连接的用户名。

语法：pg_dump dbname > outfile

恢复：

pg_dump生成的文本文件可以由psql程序读取，常用命令：

psql dbname < infile

pg_dump和psql读写管道的能力使得直接从一个服务器转储一个数据库到另一个服务器成为可能，例如：

pg_dump -h host1 dbname | psql -h host2 dbname

2）pg_dumpall

pg_dump每次只转储一个数据库，而且它不会转储关于角色或表空间（因为它们是集簇范围的）的信息。为了支持方便地转储一个数据库集簇的全部内容，提供了pg_dumpall程序。pg_dumpall备份一个给定集簇中的每一个数据库，并且也保留了集簇范围的数据，如角色和表空间定义。该命令的基本用法是：

pg_dumpall > outfile

恢复：

直接使用pg_dump下来的文件会发现无法恢复角色等相关信息

通过pg_dumpall 转储的结果可以使用psql恢复：

psql -f infile postgres

也可使用

psql < file

1.2 第三方软件

在实际测评中，我们还能碰到许多客户是用第三方软件来对数据库系统进行数据备份的。

这里我们就要去查看备份软件中设置的策略是如何的。

总结：

至少需要确认备份的时间（如几点执行备份）、频率（如每日执行还是每周）、备份内容（如全库备份还是增量，或者有些是对服务器整机进行备份，同时包含了数据库）、备份文件存储（如本地存储还是定时存储在哪）、是否具有恢复功能（当然如果这个功能都没的话，这软件还是别卖了。。）等。

确认完这些后，还要去查看备份的地方是否真的生成了备份文件，同时还需对备份文件进行恢复测试，确认备份数据的有效性。

2. 应提供异地实时备份功能，利用通信网络将重要数据实时备份至备份场地

这个就去询问管理人员是否将数据进行了异地备份。不同行业对异地的标准也是不同，具体的需要依据行业的指导文件进行判断。

这里我个人好像在哪里看到过异地至少30公里，不知道脑子里为啥有30公里这个印象，主要这个条款的目的也是避免一些重大灾害的，比如地震、火灾之类的。

3. 应提供重要数据处理系统的热冗余，保证系统的高可用性

这条也没啥好说的，热冗余一般就是看是否采用热备、集群等方式部署，一般至少两台部署，去找管理人员询问、取证。
咱也不可能每种数据库、服务器之类怎么热冗余部署的都搞清楚，那也不会做等保了是吧，得干运维去了（滑稽），所以一般我还是去询问管理人员这个是什么方式部署的。