身份鉴别
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系统的核心组件，安全问题不容忽视，需要结合应用部署的安全要求以及所在环境的安全条件，选择适合的方式对数据库进行安全加固。
