使用存储过程控制数据访问

　　控制对表数据的访问的另一种流行方法是使用存储过程。存储过程是一组 SQL 语句，这组 SQL 语句形成一个逻辑单元，用于执行特定的任务。存储过程是在数据服务器上创建和运行的，用于封装一组经常要运行的操作或查询。例如，一个雇员数据库上的操作(雇用、解雇、升职、查找)可以编写成存储过程，由应用程序来调用，而不是直接编写在应用程序中。存储过程可以带不同的参数和结果来编译和执行，它们可以有输入、输出和输入/输出参数的任意组合。清单 7 展示了一个存储过程的例子，该存储过程根据业绩评分评定雇员新的工资和奖金。

　　清单 7. 根据业绩评分评定雇员的工资和奖金

　　CREATE PROCEDURE UPDATE_SALARY (

　　IN empNum CHAR(6)、

　　IN rating SMALLINT)

　　LANGUAGE SQL

　　BEGIN

　　IF rating = 1 THEN

　　UPDATE employee

　　SET salary = salary * 1.10、 bonus = 1500

　　WHERE empno = empNum;

　　ELSE

　　UPDATE employee

　　SET salary = salary * 1.05、 bonus = 1000

　　WHERE empno = empNum;

　　END IF;

　　END

　　该存储过程接受两个输入参数，即雇员号和一个评分，然后根据给定的评分更新该雇员的工资和奖金。对于获得评分 “1” 的雇员，为他加薪 10%，并提供 $1500 的奖金。对于所有其他评分，为雇员加薪 5%，并提供 $1000 的奖金。

　　作为一项最佳实践，应考虑使用存储过程来控制对数据的访问。通过对存储过程的调用，将直接允许对表的访问，因此，限制一个用户可以在表上执行的动作，也将同时控制什么用户可以调用存储过程。

　　如今，很多应用程序的数据库层都设计为存储过程。也就是说，所有数据库访问都是通过存储过程调用来执行的。想要执行某个事务(例如更新订单或者购买某个产品)的应用程序，只需从应用程序中调用存储过程。这种方法的一个附带的好处是，所有逻辑都集中放在一个地方，这使得管理和维护更加容易，而且也使其他应用程序可以重用其功能。这种方法与面向服务的架构(Service Oriented Architecture，SOA)非常吻合。

　　还可以通过 GRANT 和 REVOKE 语句控制对存储过程的访问。想要调用存储过程的用户需要被授予 EXECUTE 权限。根据绑定选项和 SQL 语句是静态还是动态，存储过程引用到的各对象可能需要更多的特权。

　　使用 LBAC 控制数据访问

　　DB2 9 中一个新的、令人激动的特性是基于标签的访问控制(Label Based Access Control，LBAC)。 LBAC 使您可以决定谁拥有不同行和列上的写访问权限，谁拥有读访问权限。

　　一种特殊的新的安全管理员权限(SECADM)被用于配置 LBAC，具体做法是创建安全策略，安全策略实际上定义了用于决定谁可以访问什么数据的标准。创建好安全策略后，安全管理员创建安全标签，安全标签也是安全策略的一部分。标签可以基于任何标准，例如工作名称、用户是否是管理人员或者用户是否属于某个特定的部门。创建好安全标签之后，便可以将安全标签与表中的行和列相关联，以保护其中保存的数据。安全管理员通过为用户授予安全标签来允许用户访问受保护的数据。当一个用户试图访问受保护的数据时，该用户的安全标签将与用于保护该数据的安全标签相比较。

　　安全管理员还可以为用户授予豁免权(exemption)。豁免权使用户可以访问其安全标签不允许其访问的受保护数据。如果一个用户试图访问一个受保护的列，而他们的 LBAC 凭证又不允许他们访问该列，那么这样的访问将失败，用户收到一条错误消息。

　　作为一项最佳实践，应考虑使用 LBAC 作为控制对敏感数据的访问的一种方法。LBAC 很容易配置，您可以对它进行定制，以满足特定的安全环境。仅凭 DB2 9 中这一个令人兴奋的安全新特性，就完全值得考虑移植到 DB2 9。

　　很多应用程序在本地实现类似的基于行和列的安全访问机制。为什么不让开发人员将精力集中在业务逻辑的开发上呢?现在，使用这种非常易于定制的新安全特性，可以轻松为数据服务器提供这样的功能。

　　防止应用程序中的 SQL 注入

　　随着 Web 应用程序取代传统的客户机-服务器应用程序，从一开始就必须将安全性设计到系统中。基于 Web 的应用程序中一个常见的安全漏洞就是所谓的 SQL 注入(SQL Injection)。SQL 注入这种技术使攻击者可以利用应用程序中未仔细检查的输入机会来执行未经授权的 SQL 命令，而应用程序的本意是使用该输入来构造动态 SQL 查询。SQL 注入通常发生在 Web 应用程序用未检查的输入变量组合一个查询的字符串的时候，在这种情况下，攻击者可以添加另一个查询，或者修改查询，以获得他们不该拥有的信息或访问权。

　　例如，考虑下面的 PHP 代码片段:

　　$sql = 'SELECT * FROM staff WHERE empID="'.$_GET['empid'].'"'

　　$stmt = db2_prepare($conn、 $sql);

　　$result = db2_execute($stmt、 array(10));

　　这个查询从 STAFF 表中选择雇员 ID 等于从一个表单获得的一个值的所有行。这条语句就容易受到 SQL 注入的威胁 —— $_GET['username'] 中的引号没有转义，因此将被加入到语句文本中，这样可以导致恶意的行为。

　　如果在运行时 $_GET['empid'] 的值如下所示，想想会出现什么情况:

　　" OR 1=1 OR empID = "

　　把这个值加入到原有的表达式时，查询就变为:

　　SELECT * FROM staff WHERE empID = "" OR 1=1 OR empID = ""

　　这条语句将从表中选择所有的行，从而可能暴露保密信息。虽然这个特例的后果可能并不太严重，但完全有可能添加更恶意的代码，尤其是会修改表的 DELETE 或 UPDATE 语句。

　　作为一项最佳实践，在编写应用程序时应该保持安全意识。避免检索冗余的数据，并仔细检查所有输入值。

　　SQL 注入攻击主要是利用安全意识不够的程序员编写的代码。为了防止这种攻击， PHP 手册 提出了一些建议，包括:

• 不要信任任何类型的输入，即使它来自一个选择框、隐藏的输入字段或一个 cookie。
• 不要以拥有超级权限或者数据库所有者的用户身份连接到数据库。总是使用只有有限特权的定制用户。
• 检查给定的输入是否具有预期的数据类型。PHP 之类的语言有很多输入验证函数。
• 使用特定于数据库的字符串转义函数来引用传递给数据库的用户提供的值。
• 不管使用什么手段，不要输出任何特定于数据库的信息，尤其是关于模式的信息。

　　应用最新的 DB2 修复包

　　DB2 修复包包含 bug 修复、新的特性和性能增强。DB2 修复包通常是按季度定期发布的，可以从 DB2 Technical Support 网站上免费下载。

　　修复包是累积式的。例如，FixPak 10 也包含 FixPak 9、FixPak 8、FixPak 7 等修复包中的修复，所以只需下载最新的修复包即可使用之前版本的修复包中的所有更新。

　　如果想查看当前安装的 DB2 的版本和修复包的级别，可以在命令窗口中使用 db2level 命令。该命令的输出将显示您的实例是多少位的 —— 32 位还是 64 位，另外还显示当前安装的修复包的级别和安装目录。

　　作为一项最佳实践，应该使用最新的修复包级别开发所有新的应用程序。这样一来，就可以利用所有最新的性能增强和修复。对于已有的应用程序，如果最新的修复包中包含可以解决重要安全问题的修复，那么应该考虑将应用程序移植到最新的修复包。

　　下载的修复包包含用于升级您的安装的代码和支持文档。 aparlist.txt 和 aparlist.html 文件中包含有该修复包已修复的一个 APAR 列表，也称产品缺陷。如果您在当前级别的 DB2 中遇到不正确的或意料之外的行为，那么可能是由于某项产品缺陷。您可以查看 APAR 文件，看看该修复包是否包含对这个产品缺陷的修复。修复包的 README 文件，即 FixPackReadme.txt 文件，包含关于安装的说明。在开始安装一个修复包之前，应该阅读这个文件，以便理解应该遵循的步骤的顺序。最后，release.txt 和 relnotes.pdf 文件中含有修复包的发行声明，其中包含关于 DB2 产品的最新信息，以及已知的问题和回避办法。

　　执行随机安全审计

　　最后，任何前摄性安全计划都应该包括随机的安全审计。这些审计需要记录数据库事件，例如授权检查、数据库对象维护、安全维护、系统管理和用户验证，并确保访问模式正常。

　　幸运的是，DB2 附带了一个审计工具，该工具可以生成一个 DBA，并允许 DBA 维护一系列预定义数据库事件的审计追踪。审计发生在实例级，这意味着审计一旦开始，它就会审计针对该实例中所有数据库的活动。审计功能可以监控不同类型的数据库事件，您可以指定只记录成功的事件还是只记录失败的事件，或者两种事件都记录。

　　可以使用 db2audit 命令来配置和操作审计功能。完成审计的配置并且生成了审计记录后，可以将审计记录提取到一个文本文件中，之后便可以对该文件进行分析。还可以将审计记录提取到有分隔符的 ASCII 文件中，之后可以将该文件装载到 DB2 关系表中，以便对其进行分析和查询。

　　例如，假设您从某个应用程序用户那里得到匿名举报，说有一个名为 SAM 的用户正在试图获取他原本无权访问的数据库对象和表的访问权。于是您决定随机监控 DB2 实例，以期发现失败的授权验证尝试。

　　在午餐时间的一个小时内，您首先对审计功能进行配置，使之审计 CHECKING 事件类型，只记录失败的尝试，并且使用 NORMAL 错误处理:

　　db2audit configure scope checking status failure errortype normal

　　中午 12 点，您启动了审计功能:

　　db2audit start

　　在审计期间，SAM 来到数据库服务器，并完成登录。他打开一个命令行窗口，连接到 SAMPLE 数据库，并尝试更新 EMPLOYEE 表中的雇员工资(当然这样的尝试会遭到失败)。他发出以下 SQL 语句:

　　connect to sample user sam using bad123boy

　　update tedwas.employee set salary = salary * 1.5

　　于是收到以下错误消息:

　　DB21034E The command was processed as an SQL statement because it was not a

　　valid Command Line Processor command. During SQL processing it returned:

　　SQL0551N "SAM" does not have the privilege to perform operation "UPDATE" on

　　object "TEDWAS.EMPLOYEE". SQLSTATE=42501

　　表明他没有更新那个表的许可，他快速退出服务器，并离开现场，自以为没有人注意到这一切。

　　一个小时过去了，您决定检查审计日志的内容。于是将 db2audit.log 文件中的记录提取到带分隔符的 ASCII 文件中:

　　db2audit extract delasc delimiter ;category checking database sample status failure

　　为了让之前创建的 DB2 表保存审计数据，使用以下命令将从 checking.del 文件中提取的数据装载到 CHECKING 表中:

　　LOAD FROM checking.del OF del MODIFIED BY CHARDEL; INSERT INTO audit.checking

　　您可以查询 AUDIT.CHECKING 表，以发现关于失败的授权尝试的更多信息:

　　SELECT category、 event、 appid、 appname、 userid、 authid FROM audit.checking

　　在 清单 8 中显示的查询结果中，您可以看到有一条关于失败的更新语句的审计记录。

　　清单 8. 查询 CHECKING 表的结果

　　SELECT category、 event、 appid、 appname、 userid、 authid FROM audit.checking

　　CATEGORY EVENT APPID APPNAME AUTHID

　　------------------------ ----------------------- ---------------- ------------

　　CHECKING CHECKING_OBJECT *LOCAL.DB2.060206220334 db2bp.exe SAM

　　1 record(s) selected.

　　这个输出可以证实 SAM 曾经尝试访问他无权访问的一个表。现在，您的怀疑得到了证实，您可以继续收集更多的证据提交给管理层，以便他们采取纠正措施。

　　作为一项最佳实践，应该对数据库执行随机安全审计。您也可以在得使您相信有人试图威胁系统安全的信息后，执行审计。

　　DB2 审计功能非常强大，可以为您提供审计访问尝试时所需的详细信息。虽然对未预见到的事件进行被动的监控是不可避免的，但是您应该使前摄性的审计成为安全计划中的重要组成部分，并且在一个月内抽出不同的时间来执行监控和分析。

　　结束语

　　本文介绍了十二种 DB2 的安全最佳实践 —— 从使用加密的身份验证模式一直到执行安全审计。随着越来越多系统安全问题的出现，监控系统的安全已成为越来越重要的任务。通过遵从这些最佳实践，可以帮助减少 DB2 数据服务器受到的安全威胁。您应该将这些最佳实践与系统架构中其他级别上的安全最佳实践和策略结合使用，以确保获得完善的安全解决方案。

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