本文描述了用于 DB2 for Linux、UNIX 和 Windows 的十二种最佳安全实践。这些最佳实践专门注重于可以通过数据库管理和编程进行控制的一些元素,但是不包括其他可应用于系统中更大范围内的安全技术或策略。本文中列出的最佳实践不分先后顺序,它们的重要性相当,都有助于提高 DB2 数据服务器的总体安全级别。
简介 在过去几年中,很多详细谈论大范围的系统安全问题的报道成为新闻的一大热点。通常,敏感的个人数据,例如社会保险号(SSN)、信用卡号和银行账号都是从不安全的系统中被窃取的,随之带来的后果是出现身份盗用、金融诈骗、未经授权地使用信息等现象。因此,系统管理员必须不断地监控他们的系统,确保系统中采取了适当的安全预防措施。
可在系统架构的不同级别上应用安全性。例如,可以通过安装防火墙来防止外部网络对服务器的未经授权的访问。可以使用一些安全网络协议技术,例如 IPSec,来保证网络上计算机间通信信道的安全性。又如,可以实行严格的密码策略,要求用户选择一个强密码,并经常更换密码。数据库级的安全措施,包括身份验证和授权,也可以用于加强应用程序的安全性。
从 PUBLIC 撤销隐式的权限和特权
DB2 在内部使用一个名为 PUBLIC 的伪组,对于 PUBLIC,可以为之授予特权,也可以撤销它的特权。PUBLIC 实际上不是在外部安全设施中定义的一个组,但通过它可以为通过 DB2 认证的用户授予特权。
当创建一个新数据库时,某些数据库权限和特权就会自动授予 PUBLIC,如 表 1 所示。
表 1. 创建数据库后被授予 PUBLIC 的权限和特权列表
作为一项最佳实践,在创建一个新的数据库之后,应立即撤销这些被授给 PUBLIC 的隐式特权。
例如,您可以执行 清单 1 中显示的语句来撤销系统编目视图上的特权和其他被授予 PUBLIC 的隐式特权。不过这个清单还不是最全的。
清单 1. 创建数据库后撤销 PUBLIC 的隐式特权
CREATE DATABASE testdb;
CONNECT TO testdb;
...
...
从 DB2 V9.1 开始,CREATE DATABASE 命令语法增加了 RESTRICTIVE 选项。如果该命令中包括了 RESTRICTIVE 选项,那么会导致 RESTRICT_ACCESS 数据库配置参数被设置为 YES,同时不自动授予 PUBLIC 任何特权。如果忽略了 RESTRICTIVE 选项,那么 RESTRICT_ACCESS 数据库配置参数被设置为 NO,前述所有特权都将自动授予 PUBLIC。
为 SYSxxx_GROUP 参数使用显式值 DB2 定义了一个超级用户权限层次结构(SYSADM、SYSCTRL、 SYSMAINT 和 SYSMON),每个权限可以执行一个子集的管理操作,例如创建数据库、强制使用户离开系统、进行数据库备份。与它们相关联的实例级参数(SYSADM_GROUP、SYSCTRL_GROUP、SYSMAIN_GROUP 和 SYSMON_GROUP)用于控制哪些用户可以继承那样的权限。
每个参数可以被设置为拥有该权限的一个用户组(在外部安全设施中定义)的名称。设置好之后,指定组中的所有用户就继承了该权限。
例如,如果有一个名为 DBAGRP1 的操作系统组,所有 DBA 用户都是这个组的成员,如果使用 清单 2 中所示的命令将 SYSADM_GROUP 实例参数的值设为 DBAGRP1,那么这个组中的所有用户都将继承 SYSADM 权限。
清单 2. 更新 SYSADM_GROUP 实例参数
UPDATE DBM CFG USING SYSADM_GROUP dbagrp1
db2stop
db2start
在 Windows 上进行缺省的 DB2 安装时,这些参数的值被缺省地设置为 NULL。这意味着超级用户权限被授给属于本地 Administrators 组的所有有效用户账户。在 Linux 和 UNIX 平台上,NULL 值被缺省地赋给实例所有者的主组,完成安装后,缺省情况下这个组只包含用户 ID 和实例所有者。
作为一项最佳实践,应该将每个实例级权限参数的缺省值改为一个显式的组名,以防止意料之外的超级用户访问。
在小型企业中,一个 DBA 扮演着多种角色,那么这些参数可以设置为相同的组名。而在大型环境中,由多个 DBA 负责一个系统,因此可以使用不同的组名。除了确保这些参数具有显式值以外,还应该尽量确保参数值所指定的组中的所有用户都确实有必要成为这个组的成员。如果没有这个必要,那么应该从这个组中删除!由于用户和组账户的管理是在 DB2 之外处理的,因此 DB2 不会仔细检查用户应不应该成为一个组的成员。
跟踪隐式的特权
如前所述,创建一个新的数据库时,PUBLIC 被隐式地授予一些特权。实际上,并不是只有此时才会授予隐式的特权。在某些情况下,当一个用户创建一个数据库对象,例如一个表或者包的时候,或者当授予 DBADM 权限级别的时候,数据库管理器会隐式地将一些特权授给用户。理解被隐式授予的特权有哪些,这些隐式特权所蕴涵的安全意义,这一点非常重要。
表 2. 授予不同动作的隐式特权小结
动作 |
授予执行该动作的用户的隐式特权 |
创建新的数据库 |
· 将 GRANT of DBADM 权限以及 BINDADD、CONNECT、CREATETAB、 CREATE_EXTERNAL_ROUTINE、CREATE_NOT_FENCED_ROUTINE、IMPLICIT_SCHEMA、LOAD 和 QUIESCE_CONNECT 权限授予创建者(SYSADM 或 SYSCTRL) · 将 GRANT of BINDADD、CREATETAB、CONNECT 和 IMPLICIT_SCHEMA 授予 PUBLIC |
授予 DBADM 权限 |
· 将 GRANT of BINDADD、CONNECT、CREATETAB、CREATE_EXTERNAL_ROUTINE、CREATE_NOT_FENCED_ROUTINE、IMPLICIT_SCHEMA、LOAD 和 QUIESCE_CONNECT 授予目标用户 |
模式 |
· 当显式地创建模式时,CREATEIN、ALTERIN、DROPIN 权限被授予创建模式的用户。 · 当隐式地创建模式时,另外还有 CREATEIN 权限被授予 PUBLIC。 |
创建对象(表、索引、包) |
· 将 GRANT of CONTROL 授予对象创建者 |
创建视图 |
· 仅当用户对视图定义中引用的所有表、视图和昵称均有 CONTROL 特权时,才为其授予 Grant of CONTROL 特权 |
作为一项最佳实践,应该仔细检查和跟踪执行某动作时所授予的隐式特权。如果以后撤销这个动作,那么应撤销任何隐式的特权。
例如,假设您一开始将 DBADM 权限授予用户 JEFF,而随后又您决定撤销此权限。为了撤销 JEFF 的 DBADM 权限,可以使用以下语句:
REVOKE DBADM ON DATABASE FROM USER jeff
执行该语句之后,JEFF 将不再拥有 DBADM 权限;然而,他仍然拥有数据库上的GRANT、BINDADD、CONNECT、CREATETAB、 CREATE_EXTERNAL_ROUTINE、CREATE_NOT_FENCED_ROUTINE、 IMPLICIT_SCHEMA、 LOAD 和 QUIESCE_CONNECT 权限,这些权限是在一开始授予 JEFF 权限时隐式地授给该用户的。这些权限需要显式地从 JEFF 撤销。