Postgres2015全国用户大会将于11月20至21日在北京丽亭华苑酒店召开。 报名链接：http://postgres2015.eventdove.com/

本期热点嘉宾：周正中(网名德哥) PostgreSQL 中国社区发起人之一，社区CTO。 PostgreSQL中国社区杭州分会会长。 PostgreSQL中国社区大学发起人之一。 DBA+社群联合发起人之一。 曾就职于斯凯网络，负责数据库部门，在上市前使用PostgreSQL完成去IOE任务，同时通过SOX审计，成功在纳斯达克上市。 现就职于阿里巴巴RDS PostgreSQL内核组。 本次大会的演讲话题是《一位PGer的安全修养》。

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

如何安全的使用PostgreSQL，让用户高枕无忧呢? 可以分为如下几个方面来加固你的数据库:

1. 一、认证安全:
   认证前的安全，端口暴露度的把握。请参考：http://blog.163.com/digoal@126/blog/static/163877040201582993130518/ 认证是使用数据库的第一关，如果认证不安全，你的数据库将很容易被入侵。
   1. pg_hba.conf安全: 配置合理的pg_hba.conf，将权限控制到最小。
      例如：
      任何情况下都不允许trust认证方法；
      超级用户只允许从本地连接，不允许从网络连接；
      将dbname+username+ip限制到最小，"授权用户"只能从"授权IP"过来连接"授权数据库"；
      如果使用数据库密码认证，请务必使用md5认证方法，网络传输的密码是md5+随机字符加密后的密文。
      
   2. 密码复杂度策略
      创建用户或修改用户密码时，强制限制密码的复杂度，例如密码长度，包含数字，字母，大小写，特殊字符等，同时排除暴力破解字典中的字符串。
      请参考, http://blog.163.com/digoal@126/blog/static/16387704020149852941586
   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,或审计日志中.
      (例如使用了readline, 堡垒机, 或者开启了log_statement)
      ~/.psql_history
      pg_log/xxx.csv
      堡垒机日志
      请参考, http://blog.163.com/digoal@126/blog/static/16387704020149852941586
      
   6. 外部表密码安全
      回收pg_user_mappings视图的public权限，否则mapping用户可以看到user mapping下的密码。
      revoke all on view pg_user_mapings from public;
      
   7. dblink密码安全
      普通用户使用dblink时，需要提供连接用户和密码，不建议使用。如果一定要用，请限制dblink目标用户在目标数据库集群的权限到最小化。
      
   8. 如果使用外部认证，如AD域，请加固对应的认证服务。
      
   9. 应用程序配置文件中如果需要配置用户和密码，请确保应用程序服务器的安全。防止配置文件泄露。
2. 二、数据传输安全
   确保数据传输过程的安全，即使数据被截获，也不需要担心。
   
   1. 数据传输加密
      如果你的网络是不可靠的，请使用加密传输，例如OPENSSL。
      请参考，http://blog.163.com/digoal@126/blog/static/163877040201342233131835
      
   2. 认证过程加密
      认证过程加密，指认证过程中，网络上传输的密码安全，如果使用数据库认证，请使用MD5方法(配置pg_hba.conf)。
      确保网络中传输的是随机码和MD5加密后的MD5。
      
3. 三、数据安全
   你的数据安全吗？如果你存储的敏感数据在数据库中是明文的，一旦数据库暴露，用户数据可能泄露，如何尽可能的保证泄露的数据的安全呢？
   
   1. 字段存储加密
      将敏感数据加密后存储在数据库中，即使加密数据泄露，只要加解密方法没有泄露，也是相对安全的。
      加解密方法建议放在应用端实现，如果加解密在数据库端实现，用户一旦入侵数据库，更容易破解（或者加密在数据库端实现，解密在应用程序端实现）。
      请参考：http://blog.163.com/digoal@126/blog/static/1638770402013423101455507/
      
   2. 敏感数据，跟踪并记录DML,truncate操作的undo
      对于非常敏感的数据，我们应该记录对这些数据操作的UNDO，在必要时刻可以快速的回滚到误操作前。
      这种方法主要是对付SQL注入，人为误操作（包括delete,update,insert,truncate的回滚）。
      请参考，http://blog.163.com/digoal@126/blog/static/1638770402014728105442434/
   3. 函数代码加密
      如果我们将业务逻辑放在数据库函数中处理的话，肯定不想让用户看到函数的内容。对于先编译后执行的函数，例如C函数，是不需要加密的，但是，对于解释性语言函数如plpgsql，建议加密函数的内容。
      目前enterprisedb有这个特性，社区版本的PostgreSQL没有这个特性。
      请参考，http://blog.163.com/digoal@126/blog/static/163877040201256056352
      http://www.cybertec.at/en/products/plpgsql_sec-encrypt-your-stored-procedure-codes/
      如果不能加密，至少需要控制普通用户不能查看函数内容。
      http://blog.163.com/digoal@126/blog/static/16387704020151993632304/
      
   4. 使用recycle bin插件，用户在删对象时，对象会存储在recycle bin schema下，而不会被真实删除。那么表被误删除或恶意删除后，很容易找回。(使用钩子实现)
      请参考，http://blog.163.com/digoal@126/blog/static/1638770402014339374747
      
4. 四、权限控制
   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不带条件还是能删除数据的，需要用其他手段)。
      请参考，http://blog.163.com/digoal@126/blog/static/16387704020132131361949/
      
   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改写重写规则，普通用户只能访问满足指定条件的行。
      请参考，http://blog.163.com/digoal@126/blog/static/163877040201362402650341/
      
   6. 创建安全策略
      与行安全策略类似，但是对表的记录权限控制更加精准细致，例如数据进入表前根据行的值判断数据是否允许插入，查询时根据已经存在的记录，判断是否允许用户查询该记录。
      请参考，http://blog.163.com/digoal@126/blog/static/16387704020153984016177/
      
   7. 对于只需要访问某些行，或某些列的需求，可以通过列权限或视图来限制应用账号的权限。
5. 五、防恶意攻击
   1. 视图攻击
      用户利用PostgreSQL的优化器原理，创建成本极低的函数，在函数中获取视图限制外的隐藏内容。
      如果用户没有创建函数的权限，用户就无法利用这个原理。
      或者使用安全栅栏来弥补。
      请参考，http://blog.163.com/digoal@126/blog/static/163877040201361031431669/
      http://blog.163.com/digoal@126/blog/static/163877040201431410032638
      或者使用基于安全策略来管理数据可见性。
      http://blog.163.com/digoal@126/blog/static/163877040201362402650341/
      http://blog.163.com/digoal@126/blog/static/16387704020153984016177/
      
   2. 防止SQL注入
      应用层应该有SQL注入预防手段，例如使用简单的过滤器，使用绑定变量等手段。
      
   3. 密码暴力破解
      目前可以通过密码错误延迟认证(auth_delay)来增加暴力破解需要的时间。
      请参考，http://blog.163.com/digoal@126/blog/static/16387704020149852941586/
      
   4. 防止普通用户通过陷阱进行攻击
      http://blog.163.com/digoal@126/blog/static/163877040201582971654972/
      
6. 六、备份，容灾，恢复测试
   再好的安全策略，也需要备份。
   基于时间点的，块级别增量备份，是比较靠谱的。(你可以选择合适的文件系统，例如btrfs)
   请参考，http://blog.163.com/digoal@126/blog/static/163877040201451894734122/
   http://blog.163.com/digoal@126/blog/static/16387704020141110105858171/
   
7. 七、审计
   审计功能，一般是用于排查问题的，当然也是一种举证的手段，例如你的数据库遭到暴力破坏了，证据非常重要。
   这里有一些例子：
   如何跟踪postgresql.conf的配置变更?
   -- worker process钩子程序的妙用.
   http://blog.163.com/digoal@126/blog/static/16387704020137624414708/
   如何跟踪表中的记录被哪个用户修改或插入?
   http://blog.163.com/digoal@126/blog/static/163877040201201333830383/
   使用pg_log_userqueries插件, 审计指定用户,数据库或超级用户的所有执行的SQL.
   http://blog.163.com/digoal@126/blog/static/1638770402012019112218804/
   使用hstore插件和触发器跟踪表的行记录变更.
   http://blog.163.com/digoal@126/blog/static/163877040201252575529358/
   PostgreSQL中如何跟踪表的创建时间, 表定义的修改时间
   http://blog.163.com/digoal@126/blog/static/1638770402012526105017774/
   PostgreSQL 精细化审计的实施.
   
   1. 审计指定表的INSERT, UPDATE, DELETE, TRUNCATE
   2. 审计指定用户对指定表的INSERT, UPDATE, DELETE, TRUNCATE
   3. 审计指定表的指定数据的INSERT, UPDATE, DELETE
   4. 如何让数据库只审计成功提交的数据, 而不记录回滚事务.
   http://blog.163.com/digoal@126/blog/static/16387704020132209854525/
   PostgreSQL 审计功能配置
   http://blog.163.com/digoal@126/blog/static/16387704020132208241607/
   PostgreSQL 9.3 规则系统改进, 允许在规则的values中使用多次NEW, OLD.
   -- 使用规则跟踪数据变更, 记录新老数据.
   http://blog.163.com/digoal@126/blog/static/16387704020134915429197/
   如何跟踪基于字段值为条件的行的变更,插入和删除呢?
   创建触发器时when的用法, 或在触发器函数中处理. 选择效率高的.
   http://blog.163.com/digoal@126/blog/static/16387704020148178320844/
   PostgreSQL数据库在上市公司重要应用中的SOX审计
   http://blog.163.com/digoal@126/blog/static/16387704020148304551659/
   审计表的DDL行为, 以及哪个会话在什么时间点,通过什么IP干的.
   http://blog.163.com/digoal@126/blog/static/1638770402014111194225536/
   审计变更的行, 以及被变更的字段内容; 新增的行, 删除的行; 以及哪个会话在什么时间点,通过什么IP干的.
   http://blog.163.com/digoal@126/blog/static/1638770402014111473644127/
   pg_audit模块
   http://blog.163.com/digoal@126/blog/static/163877040201541595510867/
   
8. 八、补丁
   PostgreSQL社区的更新速度很快，几乎每天都会有大大小小的更新，有些可能是FIX
   patch，有些可能是feature，有些可能是性能提升patch，正常情况下，我们只要跟随小版本的升级就可以了，一般社区遇到比较大的安全漏洞，提交补丁后马上就会发布小版本，如果没有发布小版本，说明没有大的安全漏洞，当然你可以通过http://git.postgresql.org实时跟踪社区的动态，自行打patch。 大版本的更新，通常情况下大版本有大量的feature，如果需要使用的话，也可以更新到大的版本，但是请注意与应用有关的修改，模块的更新等。
9. 九、外界环境安全
   1. 应用程序是否安全？
   2. 中间件是否安全？
   3. 数据库所在操作系统是否安全？
   4. 数据库所在服务器是否安全？
   5. 存储安全，存储是否在安全的地方，有没有硬盘被拔掉的风险？
   6. 网络安全，如机架交换机，未插网线的端口是否禁用了，是否做了MAC地址过滤或绑定？
   7. 机房安全？
10. 十、资源控制
    虽然我们前面已经控制的挺好了，但是数据库还有一种风险和网络的DDOS攻击类似，大量的用户请求可以把数据库搞慢。或者大量的运算量或者IO极大的请求，也很容易把数据库搞慢。
    资源控制手段举例：
    控制连接数，控制活动连接数，控制SQL执行时间，控制锁等待时间，控制事务空闲时间。
    另一方面，因为PostgreSQL的并发控制用到了多版本，所以当更新或删除数据时，老的版本依旧存在于数据库中，需要vacuum进程回收这些数据，目前有一个缺陷，当有长事务存在时，事务开启后产生的垃圾被视为新的垃圾，不会被回收，所以长事务容易导致数据库膨胀，太长的事务甚至可以导致数据库的xid耗尽，必须关机做vacuum freeze。请参考，http://blog.163.com/digoal@126/blog/static/16387704020153305256157/
11. 十一、监控
    监控是DBA的眼睛，好的监控可以提前发现问题，将问题排除在发生之前。
    常用监控项请参考，http://blog.163.com/digoal@126/blog/static/163877040201412763135184/
    巡检参考，http://blog.163.com/digoal@126/blog/static/1638770402014252816497/
    持续更新。

    ---

    2015Postgres全国大会官方报名地址：http://postgres2015.eventdove.com/ 官方网站：http://www.postgres.cn 报名地址：http://postgres2015.eventdove.com/ 官方QQ群： PostgreSQL专业1群: 3336901（已满） PostgreSQL专业2群: 100910388 PostgreSQL专业3群: 150657323 官方微信公众号：PostgresChina 官方认证新浪微博：PostgreSQL用户会