![](https://i-blog.csdnimg.cn/blog_migrate/85458856c557f88674ef240850c3be7f.png)
Postgres2015全国用户大会将于11月20至21日在北京丽亭华苑酒店召开。本次大会嘉宾阵容强大,国内顶级PostgreSQL数据库专家将悉数到场,并特邀欧洲、俄罗斯、日本、美国等国家和地区的数据库方面专家助阵:
- Postgres-XC项目的发起人铃木市一(SUZUKI Koichi)
- Postgres-XL的项目发起人Mason Sharp
- pgpool的作者石井达夫(Tatsuo Ishii)
- PG-Strom的作者海外浩平(Kaigai Kohei)
- Greenplum研发总监姚延栋
- 周正中(德哥), PostgreSQL中国用户会创始人之一
- 汪洋,平安科技数据库技术部经理
- ……
|
![]() |
本文是PostgreSQL使用安全指导性的文章,涉及详细的用法或原理请参考相关链接。
如何安全的使用PostgreSQL,让用户高枕无忧呢?
可以分为如下几个方面来加固你的数据库
一、认证安全
认证前的安全,端口暴露度的把握。
认证是使用数据库的第一关,如果认证不安全,你的数据库将很容易被入侵。
1. pg_hba.conf安全
配置合理的pg_hba.conf,将权限控制到最小。
例如:
任何情况下都不允许trust认证方法;
超级用户只允许从本地连接,不允许从网络连接;
将dbname+username+ip限制到最小,"授权用户"只能从"授权IP"过来连接"授权数据库";
如果使用数据库密码认证,请务必使用md5认证方法,网络传输的密码是md5+随机字符加密后的密文。
2. 密码复杂度策略
创建用户或修改用户密码时,强制限制密码的复杂度,例如密码长度,包含数字,字母,大小写,特殊字符等,同时排除暴力破解字典中的字符串。
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 ROLEpostgres=# 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_historypg_log/xxx.csv堡垒机日志
6. 外部表密码安全
回收pg_user_mappings视图的public权限,否则mapping用户可以看到user mapping下的密码。
revoke all on view pg_user_mapings from public;
7. dblink密码安全
普通用户使用dblink时,需要提供连接用户和密码,不建议使用。如果一定要用,请限制dblink目标用户在目标数据库集群的权限到最小化。
8. 如果使用外部认证,如AD域,请加固对应的认证服务。
9. 应用程序配置文件中如果需要配置用户和密码,请确保应用程序服务器的安全。防止配置文件泄露。
二、数据传输安全
确保数据传输过程的安全,即使数据被截获,也不需要担心。
1. 数据传输加密
如果你的网络是不可靠的,请使用加密传输,例如OPENSSL。
2. 认证过程加密
认证过程加密,指认证过程中,网络上传输的密码安全,如果使用数据库认证,请使用MD5方法(配置pg_hba.conf)。确保网络中传输的是随机码和MD5加密后的MD5。
三、数据安全
你的数据安全吗?如果你存储的敏感数据在数据库中是明文的,一旦数据库暴露,用户数据可能泄露,如何尽可能的保证泄露的数据的安全呢?
1. 字段存储加密
将敏感数据加密后存储在数据库中,即使加密数据泄露,只要加解密方法没有泄露,也是相对安全的。
加解密方法建议放在应用端实现,如果加解密在数据库端实现,用户一旦入侵数据库,更容易破解。(或者加密在数据库端实现,解密在应用程序端实现)
2. 敏感数据,跟踪并记录DML,truncate操作的undo
对于非常敏感的数据,我们应该记录对这些数据操作的UNDO,在必要时刻可以快速的回滚到误操作前。
这种方法主要是对付SQL注入,人为误操作(包括delete,update,insert,truncate的回滚)。
3. 函数代码加密
如果我们将业务逻辑放在数据库函数中处理的话,肯定不想让用户看到函数的内容。对于先编译后执行的函数,例如C函数,是不需要加密的,但是,对于解释性语言函数如plpgsql,建议加密函数的内容。
目前enterprisedb有这个特性,社区版本的PostgreSQL没有这个特性。
如果不能加密,至少需要控制普通用户不能查看函数内容。
4. 使用recycle bin插件,用户在删对象时,对象会存储在recycle bin schema下,而不会被真实删除。那么表被误删除或恶意删除后,很容易找回。(使用钩子实现)
四、权限控制
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不带条件还是能删除数据的,需要用其他手段)。
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改写重写规则,普通用户只能访问满足指定条件的行。
6. 创建安全策略
与行安全策略类似,但是对表的记录权限控制更加精准细致,例如数据进入表前根据行的值判断数据是否允许插入,查询时根据已经存在的记录,判断是否允许用户查询该记录。
7. 对于只需要访问某些行,或某些列的需求,可以通过列权限或视图来限制应用账号的权限。
五、防恶意攻击
1. 视图攻击
用户利用PostgreSQL的优化器原理,创建成本极低的函数,在函数中获取视图限制外的隐藏内容。
如果用户没有创建函数的权限,用户就无法利用这个原理。
或者使用安全栅栏来弥补。
或者使用基于安全策略来管理数据可见性。
2. 防止SQL注入
应用层应该有SQL注入预防手段,例如使用简单的过滤器,使用绑定变量等手段。
3. 密码暴力破解
目前可以通过密码错误延迟认证(auth_delay)来增加暴力破解需要的时间。
4. 防止普通用户通过陷阱进行攻击
六、备份,容灾,恢复测试
再好的安全策略,也需要备份。
基于时间点的,块级别增量备份,是比较靠谱的。(你可以选择合适的文件系统,例如btrfs)
七、审计
审计功能,一般是用于排查问题的,当然也是一种举证的手段,例如你的数据库遭到暴力破坏了,证据非常重要。
这里有一些例子:
如何跟踪postgresql.conf的配置变更?
-- worker process钩子程序的妙用.
如何跟踪表中的记录被哪个用户修改或插入?
使用pg_log_userqueries插件, 审计指定用户,数据库或超级用户的所有执行的SQL.
使用hstore插件和触发器跟踪表的行记录变更.
PostgreSQL中如何跟踪表的创建时间, 表定义的修改时间
PostgreSQL 精细化审计的实施.
1. 审计指定表的INSERT, UPDATE, DELETE, TRUNCATE
2. 审计指定用户对指定表的INSERT, UPDATE, DELETE, TRUNCATE
3. 审计指定表的指定数据的INSERT, UPDATE, DELETE
4. 如何让数据库只审计成功提交的数据, 而不记录回滚事务.
PostgreSQL 审计功能配置
PostgreSQL 9.3 规则系统改进, 允许在规则的values中使用多次NEW, OLD.
-- 使用规则跟踪数据变更, 记录新老数据.
如何跟踪基于字段值为条件的行的变更,插入和删除呢?
创建触发器时when的用法, 或在触发器函数中处理. 选择效率高的.
PostgreSQL数据库在上市公司重要应用中的SOX审计
审计表的DDL行为, 以及哪个会话在什么时间点,通过什么IP干的.
审计变更的行, 以及被变更的字段内容; 新增的行, 删除的行; 以及哪个会话在什么时间点,通过什么IP干的.
pg_audit模块
八、补丁
PostgreSQL社区的更新速度很快,几乎每天都会有大大小小的更新,有些可能是FIX patch,有些可能是feature,有些可能是性能提升patch,正常情况下,我们只要跟随小版本的升级就可以了,一般社区遇到比较大的安全漏洞,提交补丁后马上就会发布小版本,如果没有发布小版本,说明没有大的安全漏洞,当然你可以通过http://git.postgresql.org实时跟踪社区的动态,自行打patch。
大版本的更新,通常情况下大版本有大量的feature,如果需要使用的话,也可以更新到大的版本,但是请注意与应用有关的修改,模块的更新等。
九、外界环境安全
1. 应用程序是否安全?
2. 中间件是否安全?
3. 数据库所在操作系统是否安全?
4. 数据库所在服务器是否安全?
5. 存储安全,存储是否在安全的地方,有没有硬盘被拔掉的风险?
6. 网络安全,如机架交换机,未插网线的端口是否禁用了,是否做了MAC地址过滤或绑定?
7. 机房安全?
十、资源控制
虽然我们前面已经控制的挺好了,但是数据库还有一种风险和网络的DDOS攻击类似,大量的用户请求可以把数据库搞慢。或者大量的运算量或者IO极大的请求,也很容易把数据库搞慢。
资源控制手段举例:
控制连接数,控制活动连接数,控制SQL执行时间,控制锁等待时间,控制事务空闲时间。
另一方面,因为PostgreSQL的并发控制用到了多版本,所以当更新或删除数据时,老的版本依旧存在于数据库中,需要vacuum进程回收这些数据,目前有一个缺陷,当有长事务存在时,事务开启后产生的垃圾被视为新的垃圾,不会被回收,所以长事务容易导致数据库膨胀,太长的事务甚至可以导致数据库的xid耗尽,必须关机做vacuum freeze。请参考,
http://blog.163.com/digoal@126/blog/static/16387704020153305256157/
十一、监控
监控是DBA的眼睛,好的监控可以提前发现问题,将问题排除在发生之前。
常用监控项请参考,
巡检参考
持续更新。