身份鉴别
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 rowpostgres@postgres:5432 # alter role user01 with password '12345';ERROR: password is too shortpostgres@postgres:5432 # alter role user01 with password '12345678';ERROR: password must contain both letters and nonletterspostgres@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 ROLEpostgres@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 ROLEpostgres@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 ROLEpostgres@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 user01psql: FATAL: too many connections for role "user01"
- 每个session的资源使用最大值 对资源使用的限制包括每个session使用的cpu资源，内存资源，申请锁的数量等系统资源的使用限制。 目前pg暂时无法实现。
- 数据库中连接数的最大值 通过 postgres.conf 中的 max_connections 参数来控制。
- 锁等待的最长时间 通过 postgres.conf 中的 lock_timeout 参数来控制。
- 事务空闲的最长时间 可以通过连接池中的参数来控制
- 应用SQL的最长执行时间 可以通过中间件的设置来控制，防止单个SQL执行时间过长，消耗过多资源，从而影响数据库中的其他应用SQL。
数据传输安全
数据在通过不可靠的网络传输的过程中，有可能会被恶意攻击者截获，如果数据传输不加密，则会存在数据泄露的风险。
可以在客户端和服务器端部署openssl来将数据加密传输。 参考链接：数据自身安全
对于一些敏感数据，建议在数据库中加密存储，且加解密算法不能放在数据库侧，一般建议加解密在应用侧实现，这样即使密文泄露后，也降低了进一步数据泄露的风险。
外界安全因素
- 数据库所在IT环境的安全影响
- 数据库管理员的安全防范意识
总结
数据库作为IT系统的核心组件，安全问题不容忽视，需要结合应用部署的安全要求以及所在环境的安全条件，选择适合的方式对数据库进行安全加固。