PG 数据库安全

2019独角兽企业重金招聘Python工程师标准>>>

• 身份鉴别
  • pg_hba.conf的配置原则
  • 用户密码复杂度
  • 用户密码有效期
  • 用户密码存储策略
  • 应用服务器配置文件安全
• 权限安全配置
• 资源控制
• 数据传输安全
• 数据自身安全
• 外界安全因素
• 总结
• 学习链接

身份鉴别

PostgreSQL默认使用5432端口作为连接端口，如果数据库是在互联网环境中，则建议改用其他端口，默认端口容易被利用发起攻击。

pg_hba.conf的配置原则

需要配置合理的pg_hba内容，将连接数据库的权限控制到最小。
目前支持的认证方式有ident、password、LDAP、证书认证等。
在生产环境中，以下几点必须保证：

• 不使用trust认证方式
• 密码认证方式必须采用MD5加密方式，网络传输过程采用密文传输
• superuser只能通过本地socket连接，不能通过网络连接
• postgres.conf中的listen_address参数值禁止为 '*'

用户密码复杂度

在创建或修改数据库中用户的密码时，必须强制限制密码的复杂度，比如包含字母大小写、数字、特殊字符、密码长度等，防止弱密码被暴力破解。
在PostgreSQL中，可以使用passwordcheck模块来简单的对用户设置的密码进行检测，如果复杂度过低，则会返回error信息，相关语句回滚。
要启用这个模块，需要将passwordcheck添加到postgres.conf中的shared_preload_libraries参数中，并重启服务。

postgres@postgres:5432 # show shared_preload_libraries ;
     shared_preload_libraries     
----------------------------------
 pg_stat_statements,passwordcheck
(1 row

postgres@postgres:5432 # alter role  user01 with password '12345';
ERROR:  password is too short
postgres@postgres:5432 #  alter role user01 with password '12345678';
ERROR:  password must contain both letters and nonletters
postgres@postgres:5432 # alter role user01 with password 'a12345678';
ALTER ROLE

用户密码有效期

用户密码必须在一个有效期之后失效，比如三个月。在PostgreSQL中可以通过制定role的有效期来强制用户更换密码。

postgres@postgres:5432 # \d pg_roles
              View "pg_catalog.pg_roles"
     Column     |           Type           | Modifiers 
----------------+--------------------------+-----------
 rolname        | name                     | 
 rolsuper       | boolean                  | 
 rolinherit     | boolean                  | 
 rolcreaterole  | boolean                  | 
 rolcreatedb    | boolean                  | 
 rolcatupdate   | boolean                  | 
 rolcanlogin    | boolean                  | 
 rolreplication | boolean                  | 
 rolconnlimit   | integer                  | 
 rolpassword    | text                     | 
 rolvaliduntil  | timestamp with time zone | 
 rolconfig      | text[]                   | 
 oid            | oid                      | 

postgres@postgres:5432 # alter role user01 valid until '2016-09-01 18:00:00';
ALTER ROLE
postgres@postgres:5432 # \du
                             List of roles
 Role name |                   Attributes                   | Member of 
-----------+------------------------------------------------+-----------
 postgres  | Superuser, Create role, Create DB, Replication | {}
 user01    | Password valid until 2016-09-01 18:00:00+08    | {}
 user02    |  

user01在2016-09-01 18:00:00之后，密码到期，将不能使用密码登录。如果配置了trust认证，依然可以登录。由于目前postgres不能在密码到期前几天提醒用户，所以建议在数据库监控中加入此项，提前三天或者一周通过短信或者邮件的方式提醒数据库管理员延长role有效期，防止密码到期后无法登陆而对应用程序造成影响。

用户密码存储策略

用户密码在数据库中应该是以密文方式存储，否则设置用户密码的意义将不复存在。所以在创建role的时候，禁止使用unencrypted password 选项。

postgres@postgres:5432 # create role test_passwd with password 'a12345678' login;
CREATE ROLE
postgres@postgres:5432 # 
postgres@postgres:5432 # 
postgres@postgres:5432 # select * from pg_shadow;
   usename   | usesysid | usecreatedb | usesuper | usecatupd | userepl |               passwd                |        valuntil        | useconfig 
-------------+----------+-------------+----------+-----------+---------+-------------------------------------+------------------------+-----------
 postgres    |       10 | t           | t        | t         | t       |                                     |                        | 
 user02      |    90291 | f           | f        | f         | f       |                                     |                        | 
 user01      |    16395 | f           | f        | f         | f       | md58edaed86912c2230d53d43b897539ee3 | 2016-09-01 18:00:00+08 | 
 test_passwd |   229387 | f           | f        | f         | f       | md5967621c92d53e44761751667a6e9cdd5 |                        | 
(4 rows)

postgres@postgres:5432 # create role test_passwd1 unencrypted password 'a12345678' login;
CREATE ROLE
postgres@postgres:5432 #  select * from pg_shadow;
   usename    | usesysid | usecreatedb | usesuper | usecatupd | userepl |               passwd                |        valuntil        | useconfig 
--------------+----------+-------------+----------+-----------+---------+-------------------------------------+------------------------+-----------
 postgres     |       10 | t           | t        | t         | t       |                                     |                        | 
 user02       |    90291 | f           | f        | f         | f       |                                     |                        | 
 user01       |    16395 | f           | f        | f         | f       | md58edaed86912c2230d53d43b897539ee3 | 2016-09-01 18:00:00+08 | 
 test_passwd  |   229387 | f           | f        | f         | f       | md5967621c92d53e44761751667a6e9cdd5 |                        | 
 test_passwd1 |   229389 | f           | f        | f         | f       | a12345678                           |                        | 
(5 rows)

postgres@postgres:5432 # select md5('a12345678test_passwd'),usename,passwd from pg_shadow where usename='test_passwd';  
               md5                |   usename   |               passwd                
----------------------------------+-------------+-------------------------------------
 967621c92d53e44761751667a6e9cdd5 | test_passwd | md5967621c92d53e44761751667a6e9cdd5
(1 row)

应用服务器配置文件安全

有些场景下，应用服务器上需要部署脚本来连接数据库处理数据，而这些脚本中的数据库连接信息大多数情况下是明文存放，在技术可行的情况下，建议通过程序接口去加密环境中得到解密的密码，然后传值给应用程序使用，并且尽量使用加密传输。如果只能保存明文文件，则需要保证应用服务器的安全。

权限安全配置

• 在权限配置部分，需要将应用程序账号的权限做到最小，使其尽量不能做删数据库、删schema、删表、删函数等危险操作。一是可以防止应用维护人员的误操作，二是可以限制应用账号被攻击后对数据库的破坏性。

• 管理账号和应用账号分开。

• 回收数据库、schema、langugage等对象的public权限。

 revoke all on database testdb from public; 
 revoke all on schema user01 from public; 
 revoke all on language plpgsql from public; 
 revoke all on table test from public;
 revoke all on function test_func from public;

资源控制

资源控制包括但不限于：

• 每个用户可使用的最大连接数
  通过 alter user/role username connection limit 3 来控制。 如果当前数据库中username的连接达到了limit值，再次用username发起连接的时候会报错：

[postgres@dang-db ~]$psql -d testdb -U user01
psql: FATAL:  too many connections for role "user01"

• 每个session的资源使用最大值
  对资源使用的限制包括每个session使用的cpu资源，内存资源，申请锁的数量等系统资源的使用限制。 目前pg暂时无法实现。
• 数据库中连接数的最大值
  通过 postgres.conf 中的 max_connections 参数来控制。
• 锁等待的最长时间
  通过 postgres.conf 中的 lock_timeout 参数来控制。
• 事务空闲的最长时间
  可以通过连接池中的参数来控制
• 应用SQL的最长执行时间
  可以通过中间件的设置来控制，防止单个SQL执行时间过长，消耗过多资源，从而影响数据库中的其他应用SQL。

数据传输安全

数据在通过不可靠的网络传输的过程中，有可能会被恶意攻击者截获，如果数据传输不加密，则会存在数据泄露的风险。
可以在客户端和服务器端部署openssl来将数据加密传输。
参考链接：PostgreSQL hostssl auth use openssl - Encrypting Data Across A Network

数据自身安全

对于一些敏感数据，建议在数据库中加密存储，且加解密算法不能放在数据库侧，一般建议加解密在应用侧实现，这样即使密文泄露后，也降低了进一步数据泄露的风险。

外界安全因素

• 数据库所在IT环境的安全影响
• 数据库管理员的安全防范意识

总结

数据库作为IT系统的核心组件，安全问题不容忽视，需要结合应用部署的安全要求以及所在环境的安全条件，选择适合的方式对数据库进行安全加固。

学习链接

• https://www.postgresql.org/docs/9.4/static/passwordcheck.html
• https://yq.aliyun.com/articles/8949

转载于:https://my.oschina.net/yafeishi/blog/742309