不授予不必要的特权

　　开发一个应用程序时，开发人员常常很早就开始考虑安全性问题。例如，开发人员通常会用一个超级用户账户(DBADM 或 SYSADM)来开发和测试他们的应用程序，以免在运行代码时不断碰到安全错误消息。通过使用 Control Center，很容易为一个用户授予所有数据库许可和权限，如 图 1 所示。

　　图 1. 通过 Control Center 授予许可

　　通常，完成了应用程序的开发和测试阶段后，在开发过程中为解决安全错误消息而授予的许可仍然保留在那里，而实际上它们已经没有存在的必要了。

　　作为一项最佳实践，应仔细检查在安装和配置应用程序的过程中授予每个用户的特权。确保所有被授出的许可和特权都是确实有必要的。

　　对于不熟悉 DB2 安全模型的开发人员来说，他们往往因为贪图简单而通过 Control Center(见 图 1)为自己授予所有可用的特权，以避免安全错误消息。您应该确保所有被授出的许可和权限都是确实有必要的。

　　使用加密的 AUTHENTICATION 模式

　　身份验证是指使用一种安全机制对用户 ID 和密码进行验证的过程。用户和组的身份验证是在 DB2 外部的一个设施中，例如操作系统、域控制器或 Kerberos 安全系统中进行管理的。实际的身份验证位置由实例参数 AUTHENTICATION 的值来决定。有很多不同的身份验证模式，包括在 DB2 服务器上(使用服务器的安全设施)、在客户机上(允许 “单点” 访问)、在一个 Kerberos 安全设施上或者通过一个用户定义的 Generic Security Service(GSS)插件对用户进行身份验证。其他身份验证选项还包括当用户名和密码以及数据通过网络在客户机与服务器之间传输的时候，对它们进行加密。表 3 总结了各种加密的身份验证选项。

　　表 3. 加密的 AUTHENTICATION 模式总结

　　* 注意：从 DB2 9 开始，XQuery 是官方支持的查询语言。

　　作为一项最佳实践，应该使用加密的身份验证模式。

　　应该为您的环境选择什么样的身份验证模式，这是由数据的敏感级别来决定的。如果所有数据都是敏感的，那么应该选择 DATA_ENCRYPT 身份验证模式，这种身份验证模式会对客户机和服务器之间传输的很多数据进行加密。如果只有一小部分数据是敏感的，那么可以选择使用 SERVER_ENCRYPT 模式，这样可以保证密码得到加密，而敏感数据则可以通过不同的机制来得到保护。

　　要更新 AUTHENTICATION 实例参数的值(在这个例子中就是 DATA_ENCRYPT 的值)，可以使用 清单 3 中显式的命令。

　　清单 3. 更新 AUTHENTICATION 实例参数

　　UPDATE DBM CFG USING AUTHENTICATION DATA_ENCRYPT

　　db2stop

　　db2start

　　注意，AUTHENTICATION 参数是在实例级上设置的，这意味着在相同实例中创建的数据库将使用共同的身份验证模式。如果有两个数据库，每个数据库需要不同的身份验证模式，那么需要在不同的实例中创建这两个数据库。

使用独立 ID 创建和拥有对象

　　创建一个数据库对象时，此对象归执行 DDL 语句创建它的那个用户 ID 所拥有。如果那个用户 ID 后来不用了(例如这位用户离开了公司)，或者如果该用户不再需要数据库对象上的数据库访问或权限，那么 DBA 必须撤销该用户的特权。这将导致其他有依赖关系的数据库对象或包失效(或者不起作用)。

　　一旦成功创建了数据库对象或包，只要对象的创建者或包的绑定者继续持有它所引用的数据库对象上必要的特权，那么这个数据库对象或包就被认为是有效的(而不是不起作用)。因此，当对象创建者或包的绑定者的特权被撤销时，包含静态 SQL 语句的对象和包将失效。

　　作为一项最佳实践，应该像 Technote 中描述的那样，使用独立的 ID 来创建和拥有对象。 .

　　这里简要描述一下这个过程:

　　在外部安全设施中创建一个新的用户 ID，并使这个用户 ID 无效，使之不能被使用。

　　从所有操作系统组中删除这个用户 ID，并确认已将该用户所属的用户或组的 CONNECT 特权撤销，以确保该用户 ID 不具有 CONNECT 权限。

　　当需要创建新的数据库对象时，或者必须执行其他的 DDL 语句时，再通过 GRANT 语句将执行该动作所需的必要特权授给这个新的用户 ID。例如，为了创建表 T1 上的一个视图，必须将表 T1 上的 SELECT 特权授给新的授权 ID:

　　GRANT SELECT ON TABLE T1 TO USER

　　将当前会话授权 ID 暂时设置为新的用户 ID。例如:

　　SET SESSION_USER =

　　在这个授权 ID 下，创建数据库对象和绑定包。例如，为了创建表 T1 上的视图，可以执行以下语句:

　　CREATE VIEW V1 AS SELECT * FROM T1

　　创建好所有必需的数据库对象和包之后，使用组成员关系和组特权来控制对所创建的数据库对象和包的访问。

　　GRANT SELECT ON VIEW V1 TO GROUP1

　　GRANT EXECUTE ON PKG TO GROUP1

　　完成上述操作之后，执行以下两条语句，将当前会话授权 ID 重新设置成常规授权 ID:

　　SET SESSION_USER = SYSTEM_USER

　　or

　　SET SESSION_USER =

　　这种方法可以确保使用一个独立的用户 ID 与创建数据库对象、绑定包和授予特权的角色相关联。随着时间的推移，面临着用户的来来去去，这样将大大简化数据库模式和特权的管理。

　　使用视图控制数据访问

　　控制表数据访问的一种常见方法是使用视图。您不必将整个表数据都公开给应用程序用户，而是可以基于表中的部分列创建一个视图。例如，假设 清单 4 中定义的表包含保险单信息:

　　清单 4. 包含保险数据的示例表定义

　　CREATE TABLE INSURANCE (

　　CUSTID INTEGER NOT NULL PRIMARY KEY、

　　SALARY FLOAT、

　　RENEWAL_MONTH VARCHAR(3)、

　　SEX CHAR(1)、

　　MARITAL_STATUS CHAR(1)、

　　NUM_DEPENDENTS INTEGER、

　　YEAR_1ST_POLICY INTEGER、

　　NUM_CLAIMS INTEGER、

　　CYCLES INTEGER、

　　AGE FLOAT、

　　COMMUTE_DIST FLOAT

　　);

　　假设某家保险公司的姐妹公司希望访问客户数据，以便分析客户数据，为客户提供更合适的产品。然而，假设根据法律该保险公司不能泄漏个人的年龄或他们索赔的金额。为了满足这些需求，可以在这个表上按照 清单 5 所示方式定义一个视图，视图中不包括客户的年龄和索赔历史:

　　清单 5. 前面包含保险数据的表上的示例视图的定义

　　CREATE VIEW ins_v1_sis_comp_1 AS

　　SELECT custid、 salary、 sex、 marital_status、 num_dependents、 year_1st_policy、

　　cycles、 age、 commute_dist

　　FROM insurance;

　　);

　　于是，通过这个视图就可以控制对数据的访问，而不必使用基表。使用 GRANT 语句可以控制对视图的访问，以免所有用户都能查看数据。例如，您可以控制谁能对该视图执行 SELECT、INSERT、UPDATE 和 DELETE 操作。

　　作为一项最佳实践，在您想隐藏表中的部分列或行的时候，应该使用视图来控制对表的访问。底层表定义发生变化时，使用视图还有助于使应用程序不受到影响。和表一样，也可以授予视图上的特定特权。

　　此外，还可以添加谓词到视图定义中，以便进一步筛选数据，同时又使秘密信息得以隐藏。沿用前面的例子，如果只想查看 65 岁以上男性客户，则可以使用 清单 6 中的视图定义:

　　清单 6. 前面保险数据上的视图定义，进一步约束了返回行

　　CREATE VIEW ins_v1_sis_comp_1 AS

　　SELECT custid、 salary、 sex、 marital_status、 num_dependents、 year_1st_policy、

　　cycles、 age、 commute_dist

　　FROM insurance

　　WHERE age >= 65 AND sex = 'M';

　　);

　　这样仍可以满足不提供客户年龄的需求，同时又为姐妹公司提供了更多的信息，使之可进一步定制产品。

上一页  [1] [2] [3] 下一页