DB2 最佳实践: IBM 数据服务器安全

　2009-11-02 00:00:00　来源：WEB开发网　　　

核心提示：介绍考虑到广泛的威胁，数据安全需要整体和不同层次两种安全方法，DB2 最佳实践: IBM 数据服务器安全，这通常涉及到深度防护，并需要一个“设计上安全”的方法，作为更广泛安全场景的一部分，下面的图标显示了数据安全和伴随它的威胁，要把支持安全作为数据库环境的核心设计，并在这些环境上支持底层结构和商

介绍

考虑到广泛的威胁，数据安全需要整体和不同层次两种安全方法。这通常涉及到深度防护，并需要一个“设计上安全”的方法，要把支持安全作为数据库环境的核心设计，并在这些环境上支持底层结构和商业实践。多层次的安全一起工作并提供三种最终的安全对象，也就是通常称作的 CIA：保密性，完整性和可用性（confidentiality, integrity, and availability）。

IBM 了解这些数据威胁，并在数据服务器中设计了全面的安全措施：IBM DB2 9 和 IBM Informix Dynamic Server 11 (“IDS”)。数据服务器的功能包括安全和审计能力，这用来帮助保护大多数关键数据。

安全威胁和应对路线图

为了简化实施有效数据服务器安全的任务，IBM 建立了一个路线图，以帮助你在自己的企业中实施安全机制。这个路线图是基于如何确保他们的一般和特殊数据安全威胁下“受保护”的多个客户的调查。最常见的数据威胁都被他们的应对措施建议充分处理了。

应对措施是当前所有最佳实践中，被每个数据服务器以及使用 IBM 信息管理产品和功能的安全部门所推荐的，这些推荐包括：

使用授权和认证，要坚持“最小特权”原则 - 只允许用户做他们真正需要做的，并把重复最小化。

对敏感数据设置正确的权限和访问控制（像 LBAC）。

审核用户访问，尤其是对敏感数据和 DBA 的操作。

限制对 PUBLIC 赋予的权限。

记得保护中间临时表和固化查询表（MQTs）。

在多层次环境中使用受信任的上下文关系。

在操作系统层次加密数据和备份文件。

使用 SSL 在网络上进行安全的传输（当前，SSL 仅限于支持使用 IBM 数据服务器驱动，像 JDBC 和 SQLJ 4 类连接 Java 应用程序）。

使用操作系统控制来防止操作系统管理员获得太多的访问权限。

这篇文章着眼于数据库层和底层数据安全。第一章“评估你的安全需求”，讨论如何判断你的系统需要什么样的安全。“威胁”和“应对措施的建议”章节，描述了一般的安全威胁并分别对它们提出的应对措施。“产品概述”提供了一个对所有建议的增强安全产品的介绍。参考在这篇文章最后的“更多信息章节”，对 IBM 数据服务器安全配置和操作重要的附加信息。

数据库外的安全

请注意，为了完全保护你的环境，你必须要处理数据库系统本身基于安全的其他方面，这将不在本文讨论。

物理安全：实施有效的徽章访问，以此控制能物理访问这个装有数据服务器的机器。

主机安全：保护操作系统，启用病毒和恶意软件防护，试试网页浏览器，监控并记录活跃的特权用户，等等。

网络安全：使用防火墙，虚拟私有网络（VPN ’ s），路由器保护，入侵检测系统，检测网络嗅探器，等等。

应用程序安全：保护你系统上的应用程序。例如，一个我们熟知的 SQL 注入威胁，为什么一个开发不良的应用程序能被强制运行不期望的 SQL 语句。这个弱点只存在于动态 SQL 应用程序，它不需要验证在动态 SQL 语句解释中的用户输入。

一致性管理：使用可靠的系统和方法来有效识别并认证企业用户。

商业控制：实施原则、过程和控制资产访问实践以及使用和管理数据。

评估你的安全需求

要应对那些保护数据安全的挑战并不简单。不过，实施一个有效的数据安全计划，至少都应该包括下面七步：

1. 数据分类：
首先你必须了解并最终对你的数据进行分类。哪部分数据是最重要的，哪些是次要的？数据对于组织的价值是什么？危及数据安全的代价是什么

2. 用户分类：
在数据被分类后，你必须判断谁被允许访问数据。员工要完成他们工作的最低层次的权限 / 特权是什么？这些员工需要多长时间的权限 / 特权？在这个阶段有两个安全原则 —— 最少的权限和职责划分，至关重要。

3. 确认威胁：
你必须明白你所面对的威胁。已知的威胁必须被列举出来并进行逻辑分类。你必须确定哪些威胁在你的环境中存在，哪些没有。你必须对不可预知的威胁做出最好的预测，并为之做好准备。

4. 反击/预防的方法：
你应该采取一个有效的方法，来应对每一个被认为是对你系统的重要威胁。就像在你的侧门还是木门的时候，你购买钛合金的前门没什么意义。在大多数情况下处理威胁要涉及多个层面——记住要深度防御。最后，这些解决方案也应该很容易配置和管理；否则，没有人会使用它们，或更糟的是，当人们认为这些解决方案已经被正确的应用了时，事实上却没有。

5. 测试：
你应该测试并验证你的安全机制是否在适当的位置并工作正常。在大多数情形下，这可能是最难的部分。你不仅要保护你的系统，还必须要有一个方法来持续的验证它。这个测试必须在多种途径执行——包括弱点测试（用于检测当前任何弱点）和渗透测试（用于检测应对措施的有效性和被突破的影响）。

6. 审计：
你应该审计并监控你的系统以提供一个数据访问历史的跟踪，并且最终用于发现任何不正当访问数据的意图。否则，由于发生太频繁，可能没有人在发生破坏或有问题的时候发现任何东西。例如，你应该审计每一个确定的敏感数据的访问。第一步 1 数据分类。你或许也想审计某个用户、组或者角色的操作，这也是在第 2 步用户分类中确定的。你的审计策略也可以受你的业务控制，以及公司的任何其它已有审计策略的驱动。有效的数据安全是一个持续的过程，而审计则是这个过程中关键的反馈方法。

7. 维护：
这把我们带到最后也是最漫长的步骤——保持一切可维护以及安全性得到保证。有效的安全并不只是一个时间点，所有一切都应该保持在发现了新威胁的时期。新的用户被添加，你的数据环境不可避免的将会改变。应该将安全维护整合进你的一般操作实践和人们的工作中，并且作为他们每天的核心任务来保持安全维护的更新。

威胁

你应该知道你碰到了什么类型的威胁。数据服务器安全可以分为 4 大类：数据威胁、配置威胁、审计威胁和执行威胁。

数据威胁：威胁数据机制，没有授权的用户或进程，能够访问数据。这显然是最多的威胁，并且是我们头脑中第一个出现的威胁。这些威胁可以直接针对数据库中的表，或者通过更多间接手段来进行，比如查看日志文件或直接查看操作系统上的表空间文件。

配置威胁：威胁于配置的机制，数据库或者数据库管理配置文件可能被篡改。因为它们控制着你数据库的关键性质，——像在那里以及如何执行认证， ——数据库配置文件像数据库数据一样受到安全的保护是非常重要的。

升级威胁：威胁审计工具的机制，审计配置、审计日志或归档日志可能被篡改。在大多数情况下，审计记录是判断在过去发生了什么和用于判断滥用的证据的唯一办法，防止它被篡改是非常有必要的。

执行威胁：威胁执行机制，数据库管理器执行文件可能被篡改。这包括执行欺骗、拒绝服务攻击和特洛伊木马攻击。

在下面的章节中，每个威胁被一个 3 段的名字标识：类型后面跟的是一个唯一数字，以及一个确定威胁的名字，一般是这种形式：

　<category>.#.<threat　short　name>　

例如，威胁 t Data.6.OSAdminAccess是在“数据”类中的威胁 #6 并且引用了一个叫“OSAdminAccess”的短名。

数据威胁

威胁	威胁描述	解释
Data.1.Connection	利用缺少数据库连接认证与授权	一个非授权用户，能利用一个数据库上缺少授权过程连接数据库这些过程的大多数例子包括在连接时不需要服务器端认证来授权用户（例如，使用客户端授权），或者通过对 PUBLIC 组赋予连接特权。
Data.2.BaseTables	利用在表上缺少授权控制	一个未授权用户，可以在数据库中利用缺少授权的过程，访问基础表和编目表中的数据。例如，让 PUBLIC 组访问系统编目表，将允许任何用户访问编目表中的所有信息。
Data.3.OtherTables	利用在复制表、固话查询表（MQTs）、临时过渡表，、异常表和 OLAP 立方体（rolap）缺少授权控制而构成威胁	一个无授权的用户，能利用在数据库访问其他非础表时缺少授权过程。这些表包括： SQL 复制表 MQTs 异常表临时过渡表 OLAP 立方体（rolap）克隆表
Data.4.CommonUserID	由于使用通用用户 ID 而遗失非层次结构中的连接用户信息	应用程序服务器经常使用一个通用用户 ID，来连接数据库并代表所有它的应用程序。这也涉及到连接池。这个通用用户 ID 削弱了用户责任和正确审计数据库的访问。这同样导致对这个通用用户 ID 的过度赋权，并有效的绕过了大多数数据库的特权验证。
Data.5.DBAAccess	滥用数据库管理员特权	默认情况下，DBAs 可以访问在他的数据库中的任何表。一个有特权的数据库管理员——或者以一个无授权的形式得到数据库管理员特权——可能滥用这个特权去读取或更改他们本不应该看到的数据。这是“内部滥用”的一个关键部分。
Data.6.OSAdminAccess	滥用操作系统管理员特权	一个有操作系统管理员或者实例所有者特权的用户，可以直接访问表数据存放的操作系统文件。他们可以滥用这个特权通过操作系统绕过数据库中的访问控制，直接读取或者复制这些文件的内容。这是“内部滥用”的一个关键部分。
Data.7.InTransit	嗅探网络中传输的数据	数据、用户 IDs 以及密码，在网络中以明码传输能被网络嗅探器看到。
Data.8.Backups	利用在备份和归档上缺少安全性而构成威胁	一旦数据离开一个运行数据服务器环境的保护，便会很容易发生未授权访问数据。如果没有保护，就可以从备份和归档镜像中直接访问数据，而无论是出于灾难恢复的目的放在本地或其他地方。
Data.9.TxnLogs	利用事务日志缺少安全性而构成威胁	事务日志包含的数据页也能被利用——像插入数据的值。因为它们只是文件系统中的一个文件，生产系统上的事务日志，可以直接被从操作系统管理员访问。同样，如果事务日志被镜像或者被复制，那么这些副本也能被特权用户利用。
Data.10.ArchiveLogs	利用归档事务日志缺少安全性而构成威胁	归档事务日志包含的数据值也能被利用——像插入数据的值。一旦事务日志处于恢复的目的被归档，那么他们通常会离开生产系统的保护并且被放置在其他系统或者设备上。那些归档服务器或设备的特权用户就有可能滥用他们的特权，并访问在这些归档事务日志中的数据。
Data.11.Diagnostics	利用缺少权限的跟踪文件、dump 文件和监控输出以及诊断工具而构成威胁	很多诊断日志、监控输出以及 dump 文件，包含可能被攻击者利用的有价值的信息。例如，诊断日志中的数据和跟踪文件会有数据值被包含在用明文记录的日志中。同样，从表裸页面镜像直接下载到磁盘，可以很容易通过像 db2dart 或 IDS onunload 这样的工具完成。它们是从数据服务器上直接 dump 下来的。
Data.12.Extract	利用从受保护位置抽取出来的数据而造成威胁	出于分发或测试的目的，从生产环境抽取数据到一个输出文件或者到另外一个数据库是很普遍的。数据常常离开了安全的数据服务器环境，暴露给未授权访问。也就是导入数据文件在等待导入进一个数据服务器期间。这个威胁根据抽取数据的最终目的可以分为不同的情况： 1. 测试 :当数据被用于测试环境时，数据必须要有和生产系统数据相同的属性，不过可以安全的被屏蔽或更改受保护的敏感数据，像信用卡卡号或是社会保障号码。 2. 分发：当数据抽取是为了分发到其他位置时，这个数据必须与生产系统中的一样。这包括用 Extract 来抽取，和复制表进行转换以及 L 装载（ETL）处理。一个分发的场景是副本管理。

配置威胁

威胁	威胁描述	注解
Config.1.Files	利用缺少安全性的数据库配置文件而构成的威胁	如果 DBMS 配置文件是不可靠的，那么一个入侵者就可以改变系统行为，让它暴露不该暴露的信息。
Config.2.DBCreate	利用缺少在谁能创建数据库上的授权控制而产生的威胁	在一个数据库管理系统中创建一个数据库是特权操作，受到实例配置的控制。只有信任用户才应该被授权在实例中创建一个数据库。

审计威胁

威胁	威胁描述	注释
Audit.1.Config	利用缺少安全性的审计配置文件而构成的威胁	未授权人员应该不能更改系统上的审计行为。这是一个攻击者用在执行一个未授权的攻击来隐藏他们的痕迹的常见方法。未授权人员应该不能更改审计配置文件。
Audit.2.Logs	利用缺少安全性的审计日志文件而造成威胁	审计日志包含可以被利用的数据值，——从更改过去审计结果的角度和了解数据服务器访问模式都成为攻击者的目标。这是攻击者在执行了未授权的攻击后用来隐藏他们的攻击的一个普通的方式。未授权人员应该不能更改或查看审计日志或已归档审计记录。

可执行威胁

威胁	威胁描述	注释
Executable.1.Files	恶意更改数据服务器可执行文件	数据服务器可执行文件可能被恶意更改，例如添加一个相同命名版本包括一个特洛伊木马；或者可能完全删除，以执行一个拒绝服务的攻击。同样，存储过程和 UDF 使用的可执行文件和库文件也可能受到同样的恶意更改。只有安装软件的用户，才可以更改这些数据服务器使用的可执行文件。
Executable.2.Dirs	利用缺少安全性的目录里包含的可执行文件或数据而产生的威胁	如果这个目录包含可执行文件或不受保护的数据文件，那么，攻击者可以更改目录路径在数据库服务器系统进行一次拒绝服务的攻击。

应对措施建议

有效保护你的数据库原理攻击的要点在第 2 章：需要有效管理进程并控制技术组件。你的保护计划必须同时包括这两个方面。

为了处理前面提到的所有威胁，下表记录了 recommended countermeasures 技术组件。在第 4 节中应对措施建议显示在功能后面，而解决方案需要使用最新的产品版本概述及实施应对措施建议。

以下产品及其相关短名在本文中非常有用：

Linux, UNIX,和 Windows平台 :

Products Short name

DB2 for Linux, UNIX, and WindowsDB2

Informix Dynamic Server IDS

IBM Database Encryption ExpertIBM DEE

IBM Audit Management Expert IBM AME

IBM Optim Test Database ManagementIBM Optim TDM

IBM Optim Archive IBM Optim Archive

z/OS 平台:

ProductsShort name

DB2 for z/OS DB2

IBM Audit Management Expert for z/OSIBM AME

IBM Optim Test Database Management IBM Optim TDM

IBM Optim ArchiveIBM Optim Archive

z/OS Security Server (Resource Access Control Facility, RACF, or equivalent)z/OS RACF

IBM Data Encryption for IMS and DB2 Database tool z/OS Encryption

z/OS Communication Server Application Transparent Transport Layer Securityz/OS AT-TLS

IBM System Storage™ TS1120 Tape Drivez/OS Tape Drive

数据威胁

威胁	威胁描述	应对措施	产品推荐
Data.1.Connection	利用缺少数据库连接认证和授权而构成的威胁	使用认证和授权遵循最少特权原则。对于认证，你不应该使用客户端认证，因为它并不安全。可以使用 SERVER，LDAP，或者 Kerberos 认证。	DB2 或 IDS
Data.2.BaseTables	利用在基础表上缺少授权控制而构成的威胁	所有对象根据数据敏感性分类并设置正确的数据库特权和访问控制。取消那些不是绝对需要的用户的特权。给角色分配特权，而不要直接指定用户。让敏感对象被角色拥有，并限制这些角色所有的访问都来自于信任上下文的用户连接。 BASE or SYSTEM CATALOG TABLES 当创建一个新的数据库对象时，确保访问权限不赋给所有 PUBLIC。基础或者系统编目表审计所有对重要表的访问。如果可能，要确保访问系统编目的权限不赋给 PUBLIC。政府以及其他高度敏感和受管环境中的敏感信息。上表推荐使用基于标签的访问控制（LBAC）或者 z/OS MLS。请参考下面章节中提供的在什么时候使用 LBAC 的建议。	DB2 or IDS IBM AME z/OS RACF
Data.3.OtherTables	利用在复制表、固化查询表（MQTs）、中间临时表、异常表和 OLAP 立方体（rolap）缺少认证控制而构成的威胁	违例、异常和中间临时表都应该被完全的保护，使其不被未授权访问，就像它们对应的基础表一样 MQTs 为了提高查询效率而作为一个结果集的高速缓存服务提供（通过 MQT 路由）。像这样的 MQTs 应该被当作内部表，并且不应该让用户直接访问。如果直接访问 MQT 是必须的。对所有到 MQT 的 SQL 访问开启最详细的审计。	DB2 或 IDS
Data.4.CommonUserID	由于使用通用用户 ID 而遗失 N-tier 结构中的连接用户信息而造成的威胁	使用在 N-tier 环境中的信任上下文功能。信任上下文允许 middle-tier 来申明终端用户访问数据库的身份。终端用户的数据库身份和数据库特权被用于这个用户请求的任何数据库。因为用户身份是受防护的，你可以使用审计来跟踪用户访问和活动。	DB2
Data.5.DBAAccess	滥用数据库管理员特权	监控：审计所有 DBA 权限的请求。对于 DBA 权限的访问控制：给角色分配 DBA 权限，并且使用信任上下文控制到这个角色的访问。这显示访问只信任来自于信任主机的连接。防止 DBA 访问数据：使用 LBAC 或 z/OS MLS 功能。	DB2 或 IDS IBM AME
Data.6.OSAdminAccess	滥用操作系统管理员特权	通过使用磁盘加密，防止数据从操作系统层面被复制或者被直接读取。推荐 AES 加密。保护敏感文件，像表空间文件不被操作系统管理员直接更改。这需要扩展 OS 访问控制功能，这由 IBM DEE 和 z/OS RACF 提供。	IBM DEE z/OS 加密 z/OS RACF
Data.7.InTransit	嗅探网络中传输的数据	在数据传输之前进行加密。在大多数情况下，如果可能的话，建议使用 SSL 加密。现在只有 Java 应用程序使用 IBM 数据服务器驱动 4 类 JDBC 和 SQLJ 连接支持 SSL。	DB2 or IDS z/OS AT-TLS
Data.8.Backups	利用在备份和归档上缺少安全性而构成的威胁	在所有媒体类型上（磁盘、磁带、等等。）加密所有复制介质和归档镜像。恢复备份镜像必须通过加密的密钥控制访问，并需要进行审计。	IBM DEE IBM Optim Archive z/OS 磁带驱动
Data.9.TxnLogs	利用事务日志缺少安全性而构成的威胁	保护文件不被操作系统管理员或者其他用户使用扩展操作系统权限进行直接更改。	IBM DEE z/OS RACF
Data.10.ArchiveLogs	利用归档事务日志缺少安全性而构成的威胁	在操作系统层面使用磁盘加密，可以保护日志不被复制或者直接读取。	IBM DEE z/OS 磁带驱动
Data.11.Diagnostics	利用缺少权限的跟踪文件、dump 文件和监控输出以及诊断工具而构成的威胁	保护文件不被操作系统管理员或其它扩展操作系统用户直接更改。审计来自文件系统的对这些文件的直接访问。	IBM DEE z/OS RACF
Data.12.Extract	利用从受保护位置抽取出来的数据而构成威胁	针对这些抽取数据原因的应对措施： 1.测试：使用 Optim 测试数据管理员的数据抗干扰能力，可以在你抽取数据到测试环境过程中自动屏蔽掉所有敏感信息。 2.分发：用磁盘加密来防止抽取文件被读取。审计到抽取文件的所有访问。注意：一定要记住审计数据抽取，像在导出过程中。	IBM Optim TDM IBM DEE z/OS 加密

在使用基于标签的访问控制（LBAC）时的建议

下面的指南帮助你判断什么时候需要使用 LBAC 来保护数据。

使用行级别 LBAC：

管理分类信息的政府应用程序

包含下面应用的所有其他应用程序：

已知数据分类

数据分类可以通过一个或多个 LBAC 安全标签组件表现

授权规则可以映射到安全标签组件

使用列级别的 LBAC：

对表的拥有者和数据库管理员保护敏感列

表中有你既想保护又不愿拥有者和数据库管理员访问的数据。为了保护这些数据，请执行下面步骤：

为这个表的所有列分配一个安全标签。

把这个安全标签分配给一个角色。

把这个角色分配给所有需要访问这个表的用户。只有这个角色的用户才可以访问表中的数据。

配置威胁

威胁	威胁描述	应对措施	产品推荐
Config.1.Files	利用数据库配置文件缺少安全性而构成的威胁	利用扩展操作系统访问控制防止文件被操作系统管理员或者其他用户直接更改。	DB2 or IDS IBM DEE z/OS RACF
Config.2.DBCreate	利用在谁能创建数据库上缺乏授权控制而构成的威胁	取消除了授权了的 DBA 之外的所有特权。审计所有创建数据库的意图。	DB2 or IDS

审计威胁

威胁	威胁描述	应对措施	产品推荐
Audit.1.Config	利用缺少安全的审计配置文件而构成的威胁	利用扩展操作系统安全控制来防止文件被操作系统管理员或其它用户直接更改。	DB2 or IDS IBM DEE z/OS RACF
Audit.2.Logs	利用缺乏安全性的审计日志文件而构成的威胁	使用一个集中的安全审计库，像 IBMAME。使用操作系统访问控制来防止文件在文件系统上被操作系统管理员或者其他用户直接更改。在磁盘上加密审计日志记录。	DB2 or IDS IBM AME IBM DEE

可执行威胁

威胁	威胁描述	应对措施	产品建议
Executable.1.Files	恶意更改数据服务器可执行文件而造成威胁	使用可执行文件安全性功能（像 IBM DEE 的“操作控制”功能）来防止可执行文件更改。	IBM DEE z/OS RACF

产品概述

IBM DB2 9.5 for Linux, UNIX, and Windows

DB2 for Linux, UNIX, and Windows (DB2) 安全能力可以分为四大范围：认证、授权、加密和审计。

认证是一个用户在使用数据库系统时遇到的第一个安全能力。在他们被允许使用 DB2 的任何服务之前，用户必须被确认并被认证。DB2 数据库系统依赖于一个安全插件架构来认证。安全插件决定授权在哪里进行，通常是操作系统，不过它可以是 Kerberos 或者 LDAP 服务器。

授权是遇到的下一个安全能力。授权用户必须被授权才能执行他们想执行的操作。授权可以很粗略（比如在一个表或者包层面）或者很细致（比如视图）。对于一个操作，DB2 数据库系统检查用户的许可是否足够来决定允许他们执行这个操作。用户通过角色或组中的用户可以直接或者间接的获得许可。

当信息传输在数据库和数据库客户端之间时，或者它们储存在磁盘上时，为了保护信息安全，可以使用加密。对于数据传输的保密性，DB2 数据库系统提供了两个选择：自带的 DATA_ENCRYPT 能力和安全套接字层（SSL）。对于数据存储，同样，也有两个选项：自带的加密、反加密列函数和 IBM 数据库加密专家。强烈推荐使用 IBM 数据库加密专家，因为它能提供更多的安全、更高的性能，最重要的是在应用程序层面上没有任何更改。

最后，审计工具可以启用以跟踪用户操作。例如，安全管理员可以参考审计跟踪来找出一个特定用户在什么时间执行了什么操作。在 DB2 9.5 中，审计工具已经有了充分提高，以提供更好的粒度和减少审计性能开销。

基于标签访问控制（LBAC）也得到了增强，所以安全管理员可以指定或免除安全标签给角色和用户组。DB2 9.5 也提供了一个新的安全能力，可以处理在 three-tier 环境中使用单个用户 ID 访问数据库涉及的安全。这个能力就是受信任的上下文。使用信任上下文也允许安全管理员在一个特权或者一个授权对一个用户可用的时候获得更多的控制。

IBM DB2 9 for z/OS

类似于 DB2 for Linux, UNIX, and Windows，DB2 9 for z/OS 安全能力可以分成 4 大范围：认证、授权、加密和审计。因为多年来 z/OS 已经设计成可以在一个服务器上同时运行多个应用程序，这些能力已被证明是成熟的技术。

认证，是当一个用户使用 DB2 9 for z/OS 产品的时候遇到的第一个安全能力。在被允许使用任何 DB2 9 for z/O 服务之前，用户必须确认并被认证。DB2 9 for z/OS 使用 z/OS 安全服务器（RACF 或者同类产品）来认证并授权访问任何 DB2 子系统。

授权是遇到的下一个安全控制。当一个应用程序获准访问子系统时，用户已经通过认证并且访问 DB2 9 for z/OS 也经过了 RACF 的检查。然后 DB2 9 for z/OS 通过使用和这个用户相关的标识符，来控制到数据的访问。一批一个或多个 DB2 9 for z/OS identifiers 叫做授权 IDs。代表每个连或注册在 DB2 9 for z/OS 上的用户和进程。这些 IDs 组成了 SQL ID。如果 SQL ID 和角色运行在一个信任上下文中，那么它将被用于 DB2 数据库系统中的授权检查。

访问 DB2 9 for z/OS 需要使用包。在运行 SQL 语句时需要包。包有一个关联的所有者 ID 或角色。执行这个包的 SQL ID 或角色的所有者可能不同。为了运行所有绑定在这个包中的 SQL 语句，SQL ID 或相关角色，必须有对这个包的执行特权。包的所有者被用于包中所有静态 SQL 语句的特权检查。执行一个动态语句时，SQL ID 或角色必须被授权在数据库系统上执行这个操作，而不是所有者。这允许 DB2 9 for z/OS 在包创建的时候，进行授权检查，而不是在每次运行的时候。同样，这个方法不必对所有用户以及这个包中的所有对象进行授权。

信息在 DB2 9 for z/OS 子系统和 DB2 9 for z/OS 客户机之间传输或存储于磁盘。为了信息保密，可以使用加密。DB2 9 for z/OS 提供了两个选择：在数据库协议中的原始数据流加密支持和网络层的安全套接字层（SSL）支持。原始数据流加密使用 DES，使其提供的性能水平在 SSL 之上。对于 SSL DB2 9 for z/OS 利用 z/OS 通信服务器的应用程序透明传输层支持（AT-TLS）。这有利于 SSL 在 DB2 9 for z/OS 系统之间数据传输过程中加密数据。对于 data-at-rest 加密也有两个选择：DB2 9 for z/OS 提供的自然加密、解密列函数和用于加密行的 IBM Data Encryption for IMS 及 DB2 数据库工具。当下载备份和归档日志时，磁带单元提供了驱动器自带的加密来保护归档磁带，全部使用 System z™ Crypto 硬件功能，可以提供更好的性能和 z/OS 自带的工业水平的安全。

z/OS 整合的审计功能可以启用，使 DB2 数据库系统跟踪用户操作。审计员可以从审计库中搜集日志和跟踪数据，并查看、分析、使用 IBM DB2 Audit Management Expert for z/OS，在数据基础上得出一个全面的报告。你可以通过用户或者对象激活的 SELECT、INSERT、UPDATE、和 DELETE 选择过滤，并导出这些过滤器以在其他系统上使用。

你可以使用 DB2 数据库系统中的强制访问控制，来通过行上的安全标签保护表数据。当一个用户使用 SQL 语句访问一行或这行中的一部分时，DB2 9 for z/OS 调用 RACF 来验证用户是否被允许执行 SQL 语句请求的此类操作。只有用户在包含 SQL 语句访问的数据域的所在行上，有他的请求拥有访问权限的情况下，访问才被允许。对于 SQL 语句访问的所有域，DB2 9 for z/OS 可以检查包含这些域的行安上的全性标签。如果用户的安全标签不能支配包含这个域的任何一行的标签，那么访问都将被拒绝。

在 DB2 9 for z/OS 上的一个安全性的增强是引入了信任上下文，当一个连接来自于一个确定的位置或事情的时候，可以建立信任连接的功能。建立一个信任连接，他提供了切换到其他用户 IDs 的可能，因此有机会获得和 SQL 语句相关的用户身份信息。另外，它可以分配一个角色给有信任上下文的用户。这个角色可以被赋予权限，并因此可以扮演组织中的角色。在这个意义上，它能持有完成确定工作、应用、或角色的所有特权。从任何 three-tier 层应用程序（如 SAP）到一个 DBA 维护 DB2 9 for z/OS 子系统的日常职责，在很多不同场景下，这两个构造彼此提供安全增强。

IBM Informix Dynamic Server 11

类似 DB2 数据库系统，Informix Dynamic Server 11 software (IDS) 的安全能力可以分成四个范围：认证、授权、加密和审计

在用户被允许连接到 IDS 数据库之前，系统会认证他们。你可以配置另 IDS 认证用户。主要的认证机制取决于操作系统的用户身份。然而你可以配置 IDS 使用 PAM（Pluggable Authentication Modules）来使用其他系统，如用 LDAP 来认证用户。

即使被认证，一个用户仍将被拒绝访问，除非他们同样被授权执行他们打算执行的操作。这包括访问一个特定数据库的许可，而且数据库中的每个对象是分开控制的。

IDS 支持多种方式的加密。对于使用 SQLI 协议的 informix 客户机应用程序，你可以配置客户端到服务器的通信，让它们之间的所有同行使用 ENCCSM 模式，或者你可以使用 SPWDCSM 加密密码。如果你使用 DRDA 客户机，则可以配置它们使用 SSL。为了增强数据库中的数据保密性，可以使用列级的加密来加密特定的值。另外，也可以使用 IBM Database Encryption Expert 来帮你保护数据库所在的磁盘安全。根据使用的备份系统，可以加密备份数据。

IDS 中的审计工具，允许你跟踪在这个系统中谁在什么时间对数据做了什么操作。你可以控制审计什么用户和什么操作。

IDS 同样支持通过 LBAC 的强制访问控制。这个 LBAC 实现对于 DB2 for Linux, UNIX, and Windows 非常简单。你可以对列和行应用标签、以及给用户赋予标签，系统判断是否用户被允许查看或更改数据。

IBM Database Encryption Expert 1.1.1

IBM Database Encryption Expert 1.1.1 软件（IBM Database Encryption Expert ）是一个数据访问控制工具，由文件加密、主机层面访问控制和操作控制组成。它通过集中管理策略，提供了控制数据在操作系统文件上被“谁，什么，什么时候，什么地方，如何”访问的手段。这些控制可以应用到数据库应用程序、数据库容器和其他操作系统元件上。

IBM Database Encryption Expert 是由一个或多个软件安全服务器和数据安全代理组成的 two-component 解决方案。这个架构了分离了职责，所以数据库管理员没有与 Database Encryption Expert 管理员相同的数据安全特权。安全服务器被作为管理密钥、数据安全策略和审计日志收集的集中点。

IBM Database Encryption Expert 现在有两个代理：

在线数据保护代理（EE FS Agent）提供了加密服务和对在线存储数据的访问控制

备份安全代理（EE DB2 Backup Agent）对已经备份到离线存储的数据提供了加密服务 - ——包括磁盘和磁带。

前面的图标显示了 Database Encryption Expert 在 DB2 数据库系统中，安装并使用的结构。

IBM Database Encryption Expert 和提供加密其他解决方案的一个重要差别是如何进行加密。IBM Database Encryption Expert 使用的技术是被加密后的文件原数据依然是明文（未加密）。这个技术为了让文件系统提供——给文件访问控制提供了一个附加层——透明访问。出于无需加密其内容的管理更有效的目的，一个应用程序可以被赋予一个文件的访问权限。特权超级用户，可以继续管理他们的环境崩并访问文件，但是被限制以明文的方式访问文件内容。这个能够帮助减少来自内部的以私有 / 机密数据为目标的恶意活动。

IBM Database Encryption Expert Security 策略概要

安全策略是 IBM Database Encryption Expert 的核心。

他们控制以下方面的数据安全：

谁和什么，能访问数据

什么时候数据能被访问

从哪里访问数据

如何访问数据

策略同样控制密钥的使用和对什么事件做日志记录（例如：所有文件访问、策略违反，等等）。这些数据安全策略让组织把商业规则转换成数据访问控制和保护策略。

通过一个安全服务器提供的浏览器接口管理策略引擎。从一个安全服务器可以管理许多数据库服务器和 Database Encryption Expert 代理。只要一个 DB2 for Linux, UNIX, and Windows 服务器上的 Database Encryption Expert 代理和安全服务器之间是 IP 连接地理上的远近不再是限制。建立安全服务器的高可用性是有可能的（事实上，这是最佳实践）。

IBM Optim

IBM Optim 软件是一个单独的、可升级的、可共用的信息生命周期管理解决方案，它提供了一个中心来部署策略抽取、存储、传输和从创建到删除全程保护应用程序数据。

图 1. Optim 主要功能
DB2 最佳实践: IBM 数据服务器安全

IBM Optim 可以提供下面的核心功能：

测试数据管理：IBM Optim 通过精简创建和管理测试环境来协助应用程序部署。子集和迁移数据建立切合实际并有正确大小的测试数据库。减少维护多个数据库副本的费用和努力。

数据保密性：保护你的敏感数据不停留在生产系统上。这些数据一般在你组织的多个测试环境之间复制，而且就在抽取文件和临时过渡表中。IBM Optim 提供了自动数据转换功能，用来屏蔽个人信息和被认为是需要单独保护的机密信息。你可在应用程序测试中，安全的使用转换过的数据，这有助于你遵守监管要求，并保持客户忠诚。

归档：IBM Optim 提供了数据库归档能力的证明，是组织可以在保持数据正常访问的同时，把历史数据与当前的数据隔离开，并以低成本安全的存储，因此使你的生产数据库对企业应用程序的服务在一个更高的水平。

IBM DB2 Audit Management Expert 1.1

IBM DB2 Audit Management Expert 1.1 软件（IBM DB2 Audit Management Expert）是一个工具，它提供了审计员、安全管理员和数据库管理员（DBAs）的能力，他们需要统计行为正确准时的交付数据和报告。它在一个审计库中，为你的 DB2 数据服务器搜集 DB2 审计工具，提供审计记录，并且这些审计记录让审计员很容易查看、分析、生成报告。

因为这个集中的工具，审计员可以：

使用自动进程选择性审计所有 DB2 数据库中的插入、更新、删除和读取。

查看在指定数据库对象上所有报告的行为。

用从审计库中收集的数据生成有意义的报告。

IBM DB2 Audit Management Expert 把审计员和 DBA 的角色分开了，腾出了宝贵的 DBA 资源用于支持审计请求。现在审计不需要是被审计系统中的特权用户，因此也不破坏数据库安全性。对于一个怀疑的审计对象，DB2 Audit Management Expert 允许一个授权审计员，通过查看在系统中什么数据已经被更改了来研究它。这允许审计员不需要 DBA 参与情况下，就能执行数据库审计工作。并且在一个类似方式中，DBAs 和安全管理员可以使用工具来保证它们的系统是准备好审计的。

一个容易使用的图形化用户接口的好处是：审计员可以自定义数据收集能力、定义基于任何 DB2 对象组合的过滤策略、DB2 用户 IDs、连接到 DB2 数据库系统应用程序和收集的时间。

DB2 Audit Management Expert 也提供一个报告接口，它使普通审计任务更方便，比如判断是谁在一个确定的时间更新了特定的对象，或者监控对特定系统或对象的未授权访问。强大的报告选项让审计员可以从不同角度查看并汇报数据。

最后，一个单独的用户，友好的管理接口，让 DB2 Audit Management Expert 管理员很容易定义 DB2 Audit Management Expert 实体，比如连接标准、用户和组。接口简单的管理任务和易于使用的向导。

z/OS 安全服务器 : Resource Access Control Facility

Resource Access Control Facility (RACF) 软件是 z/OS System Authorization Facility (SAF) 的一个组件，用来保护在 z/OS 上的所有资源，包括你的网络和通信。SAF 是高层架构，它允许你插入任何可用的商业产品。

为了提供面向多种资源、功能、工具、程序、还有 z/OS 上的命令，RACF 已经发展了超过 30 年。RACF 的概念非常简单：在数据库中保留所有 RACF 保护的资源记录。例如它可以设置文件模式的权限，即使这个文件并不存在。当用户登录系统时，RACF 最初通过用户 ID 和密码来确定和认证用户。当用户试图访问一个资源时，RACF 将检查它的数据库，根据这些从数据库中找到的信息，它既可以允许也可以拒绝访问请求。

z/OS 通讯服务器 : Application Transparent Transport Layer Security

Transport Layer Security（TLS）软件是 Secure Sockets Layer (SSL) 技术的最新发展。通过它你可以加密并保护你最重要的电子商务事务和其他在网络上传输的数据。在主机环境中，应用程序需要大范围的程序更改才能实现并获得这个高度安全的传输路径。但是，由于有 Application Transparent Transport Layer Security (AT-TLS)，现在配置 TLS 加密不需要花费时间去重新编写你的应用程序了。

AT-TLS 支持是策略驱动，并由 Policy Agent 或 PAGENT 管理。套接字应用程序在套接字之上继续发送并接受明文，不过数据在网络间传输是被系统 SSL 保护的。需要 AT-TLS 了解状态或者控制通信安全来对应用程序提供支持。

总结

为了完全保护你的环境，你必须注意各个方面的安全，而不仅仅是数据库系统本身。如这一章节中所说的“数据库之外的安全”，这包括保护网络、你的主机和你运行的所有应用程序，还有那个控制物理访问还有时间商业控制。作为更广泛安全场景的一部分，下面的图标显示了数据安全和伴随它的威胁。