数据库安全性：超越口令

　　加密数据和程序包

　　加密 CARD_NO 数据可以确保为机密数据再添加一层数据保护。可以使用外部进程中定义的静态密钥或数据库的列中存储的静态密钥进行加密。一个比较可取的方法是将加密组件(密钥和函数)划分到两个单独的服务器，以增加环境的复杂性和潜在的入侵者检索所有所需信息以解密受保护数据所需的工作量。

　　如果在应用程序中定义密钥，则攻击者将不但必须进入数据库服务器，而且必须进入应用服务器才能获得此密钥以解密数据。即使某个人攻破了以上各部分中描述的访问保护，他仍必须破解程序包代码(按下个部分“保护安全环境”中的描述进行编码)才能知道所应用的加密函数。攻击者还必须破解位于应用服务器中的已编译的应用程序代码才能识别所使用的密钥。如果此密钥未存储在任何明文文件(如参数文件或源代码)中，而是只存储在已编译的版本中，则通过未授权访问检索实际加密数据所需的技能和难度将随之提高。

　　但为了独立于应用程序，支持文件中演示的示例将其他表列用作加密密钥。密钥列中存储的值必须是静态的，这是因为如果该值更改，则 CARD_NO 数据将无法再被解密。在本示例中，我们为此密钥选择了 CREATED_BY 列，原因是记录创建后它将不会进行更新。

　　最大限度地减少加密所需的额外工作的最便捷的解决方案是创建一个程序包，该程序将用于从根本上隐藏对 Oracle 的加密实用程序调用。开发人员将只需生成一个函数调用而不是直接使用受保护的列，这是为获取安全保障而产生的一个很小的不便之处。本示例使用 DBMS_CRYPTO 程序包中的 ENCRYPT 和 DECRYPT 函数，该程序包提供了许多加密方法(有关其他详细信息，请参阅 Oracle 文档)。大量的选项组合(针对所选择的密钥)增加了攻破所提供解决方案的复杂度，尤其是按如下所述对定制程序包的源代码进行了打包后。(create_packages.sql 脚本为本文描述的加密/解密函数提供了示例设置。)

　　Oracle 数据库 10g 第 2 版提供了随取随用的透明数据加密，使您能够透明地加密任何常规数据库列(日期、字符串、数字)并在用户通过了必需的访问控制检查时自动将其解密。Oracle 引擎本身(不受数据库用户的控制)可以处理加密密钥，因此对表的应用程序或 SQL 访问不必再管理这些密钥。通过扩展，数据库管理员可以管理表但看不到实际的数据值，这将解决以上设置所涉及的部分问题。

　　操作加密数据

　　Oracle 应用服务器应用程序使用 Sec_Manager.Secure_Package 程序包中的例程存储加密格式的私人数据(如使用 Secure_Package.Secure_Data 存储 CARD_NO 数据)。根据 create_packages.sql(位于支持文件中)中描述的定制加密程序包的定义，对 CARD_NO 列的访问已被函数调用所取代，该函数调用的参数是要存储在列中的值以及用于数据解密的密钥。

　　例如，要将“a1b2c3d4”用作加密密钥，必须将最初如下所示的典型 INSERT 语句

　　insert into CUSTOMER (NAME, CARD_NO)

　　values ('Jane Doe', '1234123412341234');

　　转换为：

　　insert into CUSTOMER (NAME, CARD_NO)

　　values ('Jane Doe', Sec_Manager.Secure_Package.Secure_Data('1234123412341234','a1b2c3d4'));

　　同样，Oracle 应用服务器应用程序还使用 Sec_Manager.Secure_Package 中的例程读取加密格式的数据，如 CARD_NO 数据的 Secure_Package.Clear_Data。然后利用插入值时使用的加密密钥来以明文格式取回受保护信息。这种情况下，必须将最初为如下所示的典型 SELECT 语句

　　select NAME, CARD_NO

　　from CUSTOMER;

　　修改为：

　　select NAME, Sec_Manager.Secure_Package.Clear_Data(CARD_NO,'a1b2c3d4')

　　from CUSTOMER;

　　保护环境

　　当完成所有开发(希望由值得信任的人员完成)后，还可以将升级后的代码加密，以便甚至连升级脚本的数据库管理员都无法确切了解安全性的实现方法。通过 Oracle 提供的实用程序实现加密，可以使用如下所示命令

　　wrap iname=Secure_Package.sql oname=Secure_Package.sec

　　打包后，可以在 SQL*Plus 提示符后象执行任何明文脚本一样执行 Secure_Package.sec，且 Oracle 引擎还将对其进行解释。同一概念也可应用于任何其他与安全性相关的 PL*SQL 脚本。此方法不但禁止了参与代码升级的人员(数据库管理员、开发人员、支持和管理人员)查看程序包内容，而且程序包内容还以加密格式部署到数据库中，因此以后要尝试破解这些程序包内容是很难的。

　　即使具有数据库管理员权限的入侵者将 CONNECT 权限授予安全对象所有者 Sec_Manager 以查看保护和加密程序包的内容，也不会有任何明文会存储在这些对象的数据库中。由于 Oracle 未提供任何“解包”实用程序，因此入侵者将必须破解 Oracle 的加密算法才能够查看程序包内容。

　　在不区分访问的情况下审计对敏感数据的访问

　　即使所有安全措施都已经到位了，了解是否对机密数据进行了未授权访问仍很重要。最简单的方法是使用内置的数据库审计功能在表级别监视对受保护数据的访问(SELECT、INSERT、UPDATE、DELETE)，而不管请求事务的数据库连接如何，命令如下：

　　audit insert, update, select on SHIP2004.CUSTOMER;

　　但使用 Oracle Fine Grained Auditing (FGA)，您可以进一步改进访问监视以最小化处理开销并提供有意义的信息。enable_fga.sql 中提供的示例使用 DBMS_FGA 程序包启用基本的审计策略。数据库中的内置审计机制禁止用户绕过审计，从而确保了它的精确性。可以在 DBA_FGA_AUDIT_TRAIL 视图以及 DBA_COMMON_AUDIT_TRAIL 视图中查看审计记录，在策略指定 audit_trail = DBMS_FGA.DB_EXTENDED 的情况下，审计记录甚至可以包含 SQLBIND 和 SQLTEXT 信息。

　　可以使用 Oracle 提供的功能轻松地增强此处提供的示例，从而加入电子邮件或寻呼机通知和激活条件，以只生成特定事件的审计记录。有关数据库审计策略和实现的其他信息，请参阅 Oracle 文档。

　　结论

　　随着入侵尝试变得日益复杂，系统架构师和管理员必须定义更好的方法来保护他们的数据库内容。以非常的方式组合一系列常用方法可以使入侵者如同进入了迷宫，无功而返。

　　即使当 AppSvr 和 SHIP2004 模式的口令被“意外”泄露时，本文描述的方法也是行之有效的，因此可以将它用作安全环境中的组件来保护战略数据资源并增加客户对于私人数据的保密性的信心。从长远看来，这有助于改善客户关系并拓展商机。