PostgreSQL 数据库安全指南

3 minute read

背景

数据库在一个企业中通常都处于非常核心的位置，数据库安全是一个非常严肃的话题。

从机房、网络、服务器、数据交换设备、操作系统、应用程序、数据库本身，数据库所处的环境非常复杂，安全隐患也非常多。

所以本文将从各个层面帮助大家理解和避免一些常见的安全隐患问题。

本文是PostgreSQL使用安全指导性的文章，涉及详细的用法或原理请参考相关链接。

如何安全的使用PostgreSQL，让用户高枕无忧呢?

可以分为如下几个方面来加固你的数据库。

一、认证安全

认证前的安全，端口暴露度的把握。

《PostgreSQL 认证安全》

认证是使用数据库的第一关，如果认证不安全，你的数据库将很容易被入侵。

1. pg_hba.conf安全

配置合理的pg_hba.conf，将权限控制到最小。

任何情况下都不允许trust认证方法；

超级用户只允许从本地连接，不允许从网络连接；

将dbname+username+ip限制到最小，”授权用户”只能从”授权IP”过来连接”授权数据库”；

如果使用数据库密码认证，请务必使用md5认证方法，网络传输的密码是md5+随机字符加密后的密文。

2. 密码复杂度策略

创建用户或修改用户密码时，强制限制密码的复杂度，例如密码长度，包含数字，字母，大小写，特殊字符等，同时排除暴力破解字典中的字符串。

《PostgreSQL 认证安全》

3. 密码更换周期

使用合理的密码更换周期，创建角色时使用VALID UNTIL ‘timestamp’，同时限制密码不能重复使用，

请注意配合监控使用，及时提醒管理员和用户密码快到期了。

4. 密码存储策略

如果使用数据库密码认证，创建角色时请使用encrypted password，这样pg_shadow.passwd存储的是密码+角色名的MD5码，否则是明文。

postgres=# create role r_test unencrypted password 'hello123' login;  
postgres=# select usename,passwd from pg_shadow where usename='r_test';  
 usename |  passwd    
---------+----------  
 r_test  | hello123  
(1 row)  
  
postgres=# alter role r_test encrypted password 'hello123';  
ALTER ROLE  
postgres=# select usename,passwd from pg_shadow where usename='r_test';  
 usename |               passwd                  
---------+-------------------------------------  
 r_test  | md5bb0d7bef45a0530ac529e7b43943a2d1  
(1 row)  
  
postgres=# select md5('hello123r_test');  
               md5                  
----------------------------------  
 bb0d7bef45a0530ac529e7b43943a2d1  
(1 row)  

5. 设置密码时防止密码被记录到数据库日志,history,审计日志,pg_stat_activity, pg_stat_statements中.

(例如使用了readline, 堡垒机, 或者开启了log_statement)

  ~/.psql_history  
  pg_log/xxx.csv  
  堡垒机日志  
  pg_stat_activity视图  
  pg_stat_statements视图与文件(与PG版本有关)  

6. 外部表密码安全

回收pg_user_mappings视图的public权限，否则mapping用户可以看到user mapping下的密码。

revoke all on view pg_user_mapings from public;

7. dblink密码安全

普通用户使用dblink时，需要提供连接用户和密码，不建议使用。如果一定要用，请限制dblink目标用户在目标数据库集群的权限到最小化。

同时开放DBLINK还有一个问题，请参考

《开放dblink , fdw带来的安全隐患》

8. 如果使用外部认证，如AD域，请加固对应的认证服务。

9. 应用程序配置文件中如果需要配置用户和密码，请确保应用程序服务器的安全。防止配置文件泄露。

10. 数据库本身的认证方式加固，但是需要客户端驱动同时来支持，修改认证协议。

参考

《PostgreSQL psql 安全设置数据库用户密码的方法之一》

二、数据传输安全

确保数据传输过程的安全，即使数据被截获，也不需要担心。

1. 数据传输加密

如果你的网络是不可靠的，请使用加密传输，例如OPENSSL。

参考，

《PostgreSQL 如何实现网络压缩传输或加密传输(openssl)》

2. 认证过程加密

认证过程加密，指认证过程中，网络上传输的密码安全，如果使用数据库认证，请使用MD5方法(配置pg_hba.conf)。确保网络中传输的是随机码和MD5加密后的MD5。

但是请注意，MD5也不能泄露，泄露是危险的，可以参考以下文档使用MD5进行认证

《PostgreSQL 对比 MySQL - 秘钥认证》

三、数据安全

你的数据安全吗？如果你存储的敏感数据在数据库中是明文的，一旦数据库暴露，用户数据可能泄露，如何尽可能的保证泄露的数据的安全呢？

1. 字段存储加密

将敏感数据加密后存储在数据库中，即使加密数据泄露，只要加解密方法没有泄露，也是相对安全的。

加解密方法建议放在应用端实现，如果加解密在数据库端实现，用户一旦入侵数据库，更容易破解。（或者加密在数据库端实现，解密在应用程序端实现）

《固若金汤 - PostgreSQL pgcrypto加密插件》

2. 敏感数据，跟踪并记录DML,truncate操作的undo

对于非常敏感的数据，我们应该记录对这些数据操作的UNDO，在必要时刻可以快速的回滚到误操作前。

这种方法主要是对付SQL注入，人为误操作（包括delete,update,insert,truncate的回滚）。

请参考，

《PostgreSQL 闪回 - flash back query emulate by trigger》

3. 函数代码加密

如果我们将业务逻辑放在数据库函数中处理的话，肯定不想让用户看到函数的内容。

对于先编译后执行的函数，例如C函数，是不需要加密的，但是，对于解释性语言函数如plpgsql，建议加密函数的内容。

目前enterprisedb有这个特性，社区版本的PostgreSQL没有这个特性。

请参考，

《PostgreSQL 函数封装 - Wrap Function code like Oracle package》

http://www.cybertec.at/en/products/plpgsql_sec-encrypt-your-stored-procedure-codes/

如果不能加密，至少需要控制普通用户不能查看函数内容。

《PostgreSQL 函数代码隐藏 - How to control who can see PostgreSQL function’s source code》

4. 使用recycle bin插件，用户在删对象时，对象会存储在recycle bin schema下，而不会被真实删除。那么表被误删除或恶意删除后，很容易找回。(使用钩子实现)

请参考，

《PostgreSQL 回收站功能 - 基于HOOK的recycle bin pgtrashcan》

5. 透明加密，防止数据文件被拖走后，泄露数据。

手段包括类型透明加密(TDE)，文件透明加密(FDE)

参考

《PostgreSQL 透明加密(TDE,FDE) - 块级加密》

四、权限控制

1. 权限管理

最危险的就是最容易暴露的数据库用户，当然是应用连接数据库的账号（以下简称应用账号）。

应用账号权限越大，应用程序被攻击后破坏性就越大。

例如用户有删数据库，删表，删索引，删表空间，删SCHEMA，删函数等等这样的权限的话，危害极大。

安全建议：

1.1 使用超级用户创建数据库，SCHEMA，应用所需的对象（如表，索引，函数）。

1.2 创建应用账号角色。

1.3 回收数据库，schema，language，应用对象的public权限。

    revoke all on database dbname from public;   
    revoke all on schema sch_name from public;   
    revoke all on language plpgsql from public;   
    revoke all on table ... from public;  
    revoke all on function ... from public;  
    ......  

1.4 将数据库，schema的使用权限赋予给应用账号。

    grant connect on database dbname to approle;  
    grant usage on schema sch_name to approle;  

1.5 将应用需要访问的对象的相关权限赋予给应用账号。

    例如表的select,insert,update,delete权限, 函数的execute权限等.

这样，应用账号只有对象的使用权限，没有对象的DROP，TRUNCATE，REPLACE权限，相对来说是更安全的。

2. 通过事件触发器禁止应用账号执行DDL，通过这种方法可以限制用户执行DDL，防止被攻击后，用户执行DROP或TRUNCATE删除对象或清空数据 (当然delete不带条件还是能删除数据的，需要用其他手段)。

请参考，

《PostgreSQL 事件触发器 - PostgreSQL 9.3 Event Trigger》

3. 防止执行不带条件的delete,update。

例如，在需要保护的表里，新增一条dummy记录，创建行触发器，当这条记录被更新或删除时，抛出异常。

对于业务上不允许执行删除操作的表，不要赋予该表的delete权限给应用账号，也就不会有这个风险。

4. 函数语言安全

建议回收函数语言的public权限，以及普通用户的权限，用户不能创建函数。执行online code。

例如：

revoke all on language plpgsql from public;  
revoke all on language plpgsql from app_role;  

5. 行级安全策略

限制普通用户只能操作表中的指定条件的记录，用于rewriter改写重写规则，普通用户只能访问满足指定条件的行。

请参考，

《PostgreSQL 行安全策略 - PostgreSQL 9.5 new feature - can define row security policy for table》

6. 对于只需要访问某些行，或某些列的需求，可以通过列权限或视图来限制应用账号的权限。

五、防恶意攻击

1. 视图攻击

用户利用PostgreSQL的优化器原理，创建成本极低的函数，在函数中获取视图限制外的隐藏内容。

如果用户没有创建函数的权限，用户就无法利用这个原理。

或者使用安全栅栏来弥补。

请参考，

《PostgreSQL views privilege attack and security with security_barrier(视图攻击)》

《PostgreSQL leakproof function in rule rewrite(“attack” security_barrier views)》

或者使用基于安全策略来管理数据可见性。

《PostgreSQL 9.4 patch : Row-Level Security》

《PostgreSQL 行安全策略 - PostgreSQL 9.5 new feature - can define row security policy for table》

2. 防止SQL注入

应用层应该有SQL注入预防手段，例如使用简单的过滤器，使用绑定变量等手段。

3. 密码暴力破解

目前可以通过密码错误延迟认证(auth_delay)来增加暴力破解需要的时间。

请参考，

《PostgreSQL 密码安全指南》

4. 防止普通用户通过函数调用陷阱进行攻击

《PostgreSQL 安全陷阱 - 利用触发器或规则，结合security invoker函数制造反噬陷阱》

5. 《Hacking PostgreSQL》

6. 防止恶意占用连接，即使攻击者没有密码，也能占用SERVER SLOT，即攻击者连接数据库时，在提示输入密码的阶段不响应，这个SOLT会被占用，相当于消耗数据库的一个连接。

通过如下参数，可以控制认证过程的时间，但是无法防止恶意的攻击，因为超时后攻击者又可以发起连接。

https://www.postgresql.org/docs/9.6/static/runtime-config-connection.html#RUNTIME-CONFIG-CONNECTION-SECURITY

authentication_timeout (integer)

Maximum time to complete client authentication, in seconds. 

If a would-be client has not completed the authentication protocol in this much time, the server closes the connection. 

This prevents hung clients from occupying a connection indefinitely. 

The default is one minute (1m). This parameter can only be set in the postgresql.conf file or on the server command line.

所以不要随机的暴露端口。

7. 通过端口尝试CANCEL用户QUERY。

《PostgreSQL cancel 安全漏洞》