管理安全信息是最难于有效实施和维护的任务之一。在当前以网络为中心的业务模型中，验证个人身份、控制访问和维护数据的完整性与保密性变得越来越难。安全是一个涉及多方面的问题，需要对业务基础设施中所有容易受到危害的因素加以分析。在进行认证的时候，单纯的加密并不能涵盖信息管理的所有方面，安全信息管理涉及三个主要领域，本文将对这些领域进行探讨。
认证
认证方法试图保证系统用户的身份。如今，对于大型的基础设施来说，安全是需要重点考虑的一个问题，传统的使用用户 ID 和密码进行验证的方法不再有效，或者说这种方法不再能包办一切。新的挑战是，应用程序常常需要能将安全策略与应用程序分离开来的认证模型，例如 Lightweight Directory Access Protocol (LDAP) 或 Kerberos。
企业要求认证框架易于维护和更新。由于发现了认证算法中存在的缺点，或者由于系统认证需求的变化，有时候需要更改认证框架的组件。对这一问题的解决方案必须考虑应用程序如何以通用方式使用新的认证框架，还应考虑认证框架如何以通用方式对用户进行认证。
目前有两个主要框架支持应用程序插入不同的认证模型，它们是 Generic Security Services Application Programming Interface (GSS-API) 和 Pluggable Authentication Module (PAM)。DB2 UDB 支持 GSS-API，而 IBM IDS 则支持 PAM。
允许应用程序控制安全。使用 GSS-API 的程序员编写的应用程序可以不知道关于保护网络数据的细节。GSS-API 还提供了一个框架，该框架允许以一种通用的方式调用安全服务，它支持各种不同的技术，例如 Kerberos 或 Public Key Mechanism。
是一种认证机制，它允许根据应用程序要求的变化定制一些系统入口服务，例如 login、rlogin 和 telnet。通过使用 PAM 框架，可以添加多种认证技术，而不必更改任何登录服务，从而可以保留已有的系统环境。PAM 可用于将登录服务与不同的认证技术，例如 RSA、DCE、Kerberos、S/Key 和基于智能卡（smart card）的认证系统进行集成。因此，PAM 使联网的计算机可以和平相处在一个异构的环境中，同时在这个环境中还可以使用多种安全机制。
受信任上下文
在多层环境中，例如在事务处理环境中，有时候需要通过保留各层上每个终端用户的身份和特权，并且对动作进行审计，以此来控制中间层应用程序的安全。在这种情况下可能出现很多问题，例如终端用户身份丢失，终端用户责任性减弱，过度为中间层认证 ID 授予特权，以及由于中间层认证 ID 必须获得可能建立连接的终端用户的所有特权而导致安全性降低。
引入了受信任上下文（trusted context）认证，以允许中间层进行这种类型的认证。受信任上下文是一个对象，它为用户提供一组特定的特权，当用户通过一个受信任的连接连接到数据库时，便可以使用它。例如，在 Web 应用程序环境中，中间层应用程序通过一个受信任上下文建立受信任的连接，从而使终端用户的身份得以传递到数据库服务器。
受信任上下文允许定义 DB2 与外部实体之间的一组惟一的交互。例如，一个外部实体，比如说一个中间件服务器，可以使用不同用户名下已有的数据库连接，而不需要对新的连接用户进行认证的能力。受信任上下文还使 DB2 授权 ID 可以获得特定受信任上下文中一组特殊的特权，而在这个受信任上下文之外，通过定义角色是无法获得这些特权的。Websphere Application Server、PeopleSoft V7、Domino 和 SAP R/3 就属于支持这种三层应用程序模型的软件产品。当中间层建立一个与 DB2 的连接时，可使用中间层的用户 ID 和密码进行认证。而且，对于任何数据库访问，包括由中间层代表终端用户执行的访问所需的所有授权检查，都可以使用与中间层授权 ID 相关的数据库特权来解决。在应用程序已经建立与 DB2 服务器的连接之后，应用程序可以在后端切换与受信任上下文相关联的用户。
当在应用程序环境中介绍受信任上下文时，有一些隐含的意思要注意：
应用程序可以通过将用户的凭证直接传递给数据库服务器来验证用户的凭证。还可以在后端服务器上认证每个用户。这使得对每个用户的动作进行审计以及提高责任性都变得更加容易。
数据库管理员可以监控哪些终端用户被允许通过中间层应用程序访问数据库服务器。
数据库管理员可以对中间层应用程序代表给定一组用户执行的动作进行审计。由于每个中间层都可以受委托而获得认证的能力，可以代表一组特定的用户，拥有一组特定的角色，因此受信任上下文支持中间层应用程序的一种受限制的信任模型，从而避免在中间层出现拥有所有特权的超级用户。
由于不必为每个终端用户建立新的物理连接，因此可以显著降低性能上的开销。中间层只需建立一个受信任连接，就可以获得通过受信任上下文切换终端用户的能力。
授权
除了认证问题外，能够对数据库服务器的安全形成威胁的还包括对敏感信息未经授权的访问。在一个用户通过认证之后，数据库服务器为那个用户授权，使之可以执行不同类型的操作。为了确保每个用户拥有适当级别的访问特权，必须进行授权。例如，一家公司的 CFO 可能需要访问全公司的财务记录，而一个部门经理的访问权限就要受到更多的限制，也许他/她只能看到其管辖的员工的工资表记录。细粒度的、基于特权的授权方式使公司可以根据访问需求为用户定制特定的特权和许可，从而有效地管理访问控制。
和 IDS 已经实现了 Role-Based Access Control (RBAC)，这是用于只允许经过授权的用户进行系统访问的一种解决方案。它将 Mandatory Access Control (MAC) 和 Discretionary Access Control (DAC) 的方法相结合。在公司中，角色是根据用户所履行的职务职能来创建的。每个角色被赋予执行某些操作的许可。而系统用户则被赋予特定的角色，通过这些角色的赋予，用户可以获得适当的许可来执行系统功能。然而，有些环境需要多种级别的安全性，例如国防部（DoD）。在这种环境中，系统数据是根据用户安全许可的级别而向用户开放的。根据用户可以看到的数据的敏感性级别，每个用户都应该可以访问某个安全级别。为解决这一需求，DB2 实现了 Label Based Access Control (LBAC)。每一行或列都可以贴上一个安全标签，标签中存储着关于数据的类别或敏感性的信息。类似地，每个数据库用户也都被赋予一个安全标签，这个标签将决定他/她可以访问哪些贴了标签的数据行或列。
的中心思想是，用户没有对企业对象的自主访问权。相反，角色与访问许可是相关联的，用户只能成为适当角色的一个成员。RBAC 大大简化了对授权的管理，同时也使系统管理员可以在一个抽象层次上控制对企业对象的访问，这种抽象与企业的结构非常近似。RBAC 很快就被很多软件产品采用，尤其是那些关系数据库管理系统（Relational Database Management Systems，RDBMS）。
通过基于标签的访问控制（Label-Based Access Control）这种手段，数据库系统可以根据对象中包含的安全标签和为试图访问那个对象的用户授予的安全标签，控制对这个数据库对象的访问。DB2 LBAC 方法是允许用户定义一组组件，以构成一个安全标签，并允许用户指定访问规则。它允许用户定义要使用的安全标签的结构。LBAC 让用户定义确切地定义哪些人有对某行和列的写访问权，哪些人又有读访问权。安全标签组件是一个新的数据库实体，可以被创建、删除和修改。它被引入作为安全标签的一个构件。一个安全标签由一个或多个安全标签组件组成。一共有三种类型的安全标签组件：数组、集合和树。在定义了安全标签组件后，用户就可以定义安全标签，并将安全标签与一个用户或一个（或多个）安全行相关联。
加密
加密与认证和授权没有直接的关系，但是，在保护传输中的或静止的数据不受未经授权用户访问的时候，它也是一个重要的方面。网络协议，例如 HTTP、SMTP 和 FTP，并没有为通过网络传输的敏感数据提供足够的保护。在网络上传输的数据容易受到各种网络攻击，例如嗅探网络传输、不可抵赖性、篡改数据、欺骗、拦截和捕捉回复。安全套接字层（Secure Socket Layer，SSL）大大改进了传统协议。SSL 可以确保在网络上传输的数据的秘密性和完整性。IDS 通过 openSSL 库为无线传输的加密提供了支持。
对于某些应用程序，可以将数据加密作为安全性的一种附加措施。通过适当地认证和访问控制，确保只有具有适当身份和经过授权的用户可以访问数据，可以处理大多数数据安全问题。但是，数据库中的数据在数据库管理员面前通常会暴露无遗，因为 DBA 拥有无限的特权。同样，公司可能关心离线存储的敏感数据的安全，例如存储在第三方的备份数据。为了保护静止的数据，DB2 和 IDS 都支持列级加密（CLE）。数据库服务器可以使用 CLE 来以加密的格式存储数据，并提供基于密码的访问。
管理安全信息是最难于有效地实施和维护的任务之一。在本教程中，我们试图为业务基础设施中可能存在的安全问题提供解决方案。我们为认证、授权和通过加密保护数据这些方面的安全问题提供了解决方案。
对静止数据的加密
和 DB2 都支持 CLE。CLE 用于为包含敏感数据（例如信用卡号）的列设置加密密码。有 ENCRYPT_TDES() 一些内置的加密函数，例如 ENCRYPT_AES() 和可用于对包含以下字符数据类型或智能大型对象数据类型的列中的数据进行加密：CHAR、NCHAR、VARCHAR、NVARCHAR、LVARCHAR、 BLOB、CLOB。数据经过加密后，只有能提供密码的用户可以解密数据。一个数据库表中某个特定列中的所有值都以用户提供的相同密码、相同的加密算法和相同的加密方式进行加密。用户还可以使用 SET ENCRYPTION PASSWORD 语句为一个会话设置一个加密密码。只有能提供密码的用户可以查看、复制或修改被加密的数据。
传输中的数据
由 Netscape 公司开发的 SSL 是为业界所接受的一个标准，用于确保在一条安全通道上对数据进行网络传输。SSL 受到当前可用的所有 Web 服务器和 Web 浏览器的支持。SSL 协议在一个公共密钥基础设施中提供认证、数据加密和数据完整性。在三层系统中，SSL 可以解决保护各层之间交换的用户数据的问题。通过提供强大的、基于标准的加密和完整性算法，SSL 向系统开发人员和用户保证数据在 Internet 上不会受到危害。基于密码的认证只能进行客户机到服务器的认证，而 SSL 则不同，它既可以进行客户机到服务器的认证，也可以进行服务器到客户机的认证。当构建一个基于 Web 的三层系统时，这是一个有用的特性，因为用户常常坚持要在为服务器提供敏感信息（例如信用卡号）之前，对 Web 服务器的身份进行认证。IDS 通过使用加密通信支持模块（ENCCSM），允许对在网络上传输的数据进行加密。
安全方面的挑战和解决方案矩阵
类别问题解决方案安全技术IBM DB2IBM IDSOracle
认证认证基础设施的可维护性通过通用的认证机制将安全策略分离开来PAMGSS-API 可以解决应用程序如何以一种通用方式使用新的认证机制的问题PAM 可以解决如何以一种通用方式使用这些机制来对用户进行认证的问题强认证：支持 Kerberos、DCE 和 RADIUS
上下文敏感的认证与服务器和应用程序建立信任关系信任关系受信任的上下文 代理认证
授权未经授权的对数据的访问限制对数据行和列的访问LBACDB2 9 中的 LBAC 可以限制对表中行和列的访问 Oracle Label Security 可以基于安全标签限制对表中行的访问
限制用户能获得的特权RBACRBAC for DB2 9IDS 实现了角色Oracle 实现了角色
加密对通信的窃听保护网络SSL目前不支持。DB2 支持通过 Distributed Relational Database Architecture (DRDA) 加密和密码加密方法进行加密通过 OpenSSL 的实现提供了支持Oracle 实现了 SSL 协议
对物理数据的未经授权的访问保护静止的数据数据加密DB2 通过内置函数 ENCRYPT、 DECRYPT_BIN、DECRYPT_CHAR 和 GETHINTNo 提供了对数据加密的支持列级加密Oracle 提供了一个 PL/SQL 包来加密和解密用 Obfuscation Toolkit 存储的数据
【编辑推荐】
