Concept-第20章翻译

20 数据库安全

这篇文章对数据库安全提供了一个概述。

这章包含下面的内容：

*数据库安全的概述

*透明数据加密概述

*身份验证方法概述

*授权概述

*对表，视图，同义词或者行记录的访问概述

*安全策略概述

*数据库审计概述

 

数据库安全概述

数据库安全控制用户是否允许对数据库或者数据库中的对象进行操作。Oracle使用模式和安全域来控制对数据的访问和限制读一各种数据库资源的使用。

Oracle提供了全面的随需定义的访问控制，随需定义访问控制是通过权限来对所有用户控制对指定的对象进行访问。一个权限是以规则的形式来表示对一个指定对象的访问的许可，例如：对张表查询的许可。管理可以为每个用户授予权限，任凭该权限授予其他用户，相互不受影响。

 

数据库用户和模式

每个数据库有一个用户名列表。为了访问一个数据库，一个用户必须使用一个数据库应用程序并且试图使用有效的用户名与数据库进行连接。每个用户的名字有一个相关的密码来阻止未经授权的使用。

 

安全域

每个用户有一个安全域---一个属性集合，这些属性决定了：

*对于用户可以执行的操作（权限和角色）；

*用户的表空间限额（即可用的磁盘空间）；

*用户对系统资源使用的限制（例如：CPU处理时间）；

 

对于用户的安全域有贡献的每个属性将下面的部分讨论：

权限

一个权限是能够执行特定的SQL语句类型的一个权利。下面是一些权限的例子包括的权利是：

*连接到数据库

*在用户方案下创建一张表；

*查询其他用户表的数据记录；

*执行其他用户的存储过程；

 

角色

Oracle通过角色来提供更简单以及更可控的权限管理。角色是指定的相关的权限组，角色你可以授予给其他用户或者其他角色。

 

存储设置和限额

你能够指导和限制每个数据库用户对分配的磁盘空间的使用，限制对象包括默认表空间和临时表空间以及表空间限额。

默认表空间

每个用户都与默认表空间有关。当一个用户创建表，索引，或者簇并且没有指定表空间用来在物理上包含该方案对象时，如果用户有创建方案对象以及在指定的表默认表空间中有一个限额的话用户的默认表空间将可以被使用。默认的表空间使用信息提供给oracle在对象的位置还没有指定的情况下来指导空间使用。

临时表空间

每个用户都有一个临时表空间。当用户运行一个需要创建临时段（比如：创建一个索引）的SQL语句时，用户的临时表空间将被使用。通过指导将所有用户的临时段存储到临时表空间中，临时表空间能够减少在临时段以及在其他类型的段之间的I/O竞争。

表空间限额

Oracle能够限制在方案内对象被分配的总的磁盘空间的大小。管理员可以为用户所使用的每个表空间设置限额（空间限制）。这样就允许有选择性的控制特定的方案中的对象所消耗的磁盘空间的总量。

 

配置模板和资源限制

每个用户都有一个配置模板，配置模板中指定了用户对一些系统资源的限制，包括下面的限制：

*用户能够建立的并发会话的数量

*对于每个用户会话的CPU处理时间以及一个单独的SQL语句对oracle的调用所需要的处理时间；

*为每个用户会话以及为一个单独的SQL  语句对oracle的调用时可用的逻辑I/O量；

*用户会话可用的最大空闲时间量；

*用户会话可用的最大连接时间；

*密码限制：

   **对次尝试登陆失败之后帐号加锁；

   **密码过期时间和宽限期；

   **密码重用以及复杂度限制；

 

透明数据加密概述

oracle数据库以身份验证，授权，以及审计的形式来提供安全性。身份验证确保只有合法的用户能够获取对系统的访问。授权确保用户只能访问他们被允许访问的资源。审计确保当用户访问被保护的资源有访问帐目。尽管这些安全机制在数据库中有效地保护数据，但是这些安全机制不会保护对存储数据的操作系统文件的访问。当数据存储在操作系统文件中时，透明数据加密对数据库中的列上敏感数据进行加密。除此之外，安全机制也提供了在数据库外部的安全模式中对密匙的安全存储和管理。

使用外部的安全模式将用于安全管理的程序函数（比如：加密）和其他常规的数据库功能分开。因此，将数据库管理工作划分为DBAs和安全管理员，任何一个管理员都不能拥有对数据的完全访问，这样就增强了数据库的安全性。外部的安全模块产生密匙，执行加密以及解密，以及早数据库外部安全存储密匙。

透明数据加密是一个基于钥匙的访问控制系统，通过密匙对数据加密加强授权管理。对于每个包含加密的列的数据库表不管在该表中加密的列的数量有多少，只有一个密匙。每张表的列的密匙是对数据库的主密匙加密。密匙不存储在数据库中。而是存储在oracle的外部安全组件中的部分中。

在你能够给数据库列加密时，你必须产生或者设置一个主密匙。在当你在数据库列上使用ENCRYPT短语时发出一个SQL命令时自动地产生列密匙，主密匙是用来给列密匙加密。

 

身份验证方法的概述

身份验证意味着对那些想访问数据，资源或者应用程序的用户进行身份检查。验证身份是为将来交互作用时建立一个可信的关系。授权也能够通过将资源访问和执行行为与特定的身份相联系，确保了数据库的可审计性。在身份验证之后，授权过程能够允许或者限制对实体的允许的访问和执行行为。

为了简单化，对于所有数据库用户都是使用相同的身份验证方法，但是oracle允许一个单独的数据库实例使用任何一个或者所有的方法。数据库管理员需要Oracle特定的身份验证过程，因为数据库管理员执行特定的数据库操作。Oracle也在传输过程中加密来确保网络的身份验证的安全。

为了检查数据库用户的身份以及防止一个数据库用户未授权的使用，你可以使用在下面部分描述的方法的任意组合来验证身份：

*通过操作系统验证

*通过网络验证

*通过oracle数据库验证

*多层验证和授权

*通过SSL协议身份验证

*数据库管理员的身份验证

 

操作系统的验证

一些操作系统让oracle使用操作系统维护的信息来验证用户身份，有下面的好处：

*一旦通过使用操作系统进行身份验证，用户能够更加方便地连接到oracle数据库中去，不需要指定用户或者密码。例如：一个操作系统身份验证过的用户能够调用SQL*Plus和通过回车来跳过输入用户名和密码提示：

SQLPLUS /

*在操作系统中集中地控制用户身份验证，oracle不需要存储或者管理用户密码，尽管oracle也会在数据库中维护用户的名字。

*在数据库和操作系统中记录审计信息使用相同的用户名字；

当一个操作系统被用来验证数据库用户身份时，管理分布式数据库环境以及数据库连接需要特别的注意。

 

通过网络验证

Oracle支持下面的身份验证方法：

*基于第三方的身份验证技术

*基于PKI的身份验证

*远程身份验证

注意：这些方法需要使用oracle 高级安全管理的选项的数据库企业版

 

基于第三方的身份验证技术

如果网络验证服务（比如：DCE，Kerberos, 或者 SESAME）是可用的，然后oracle可以接受来自网络服务的身份验证。如果你使用一个网络验证服务，然后对于网络角色和数据库连接需要一些特殊的考虑。

 

基于PKI的身份验证

基于公共密钥加密（PKI）的身份验证系统对用户客户端生成数字证书，这个数字证书是用来在业务服务器上直接验证，而不需要在验证服务器上直接验证。Oracle为使用公共密匙和数字证书提供了一个公共密钥加密功能，公共密钥加密功能是由下面组件组成的：

*使用SSL来进行身份验证和安全会话密匙管理；

*Oracle Call Interface (OCI)和 PL/SQL函数是用来通过私有密匙和数字证书来给用户指定的数据标记，并且使用可信数字证书来对数据进行验证签名；

*可信的数字证书，当一个身份是被确认为一个要求的实体时用来验证被信任为用户数字证书的签名人的第三方的实体身份；

*Oracle wallet，包含一个用户私有密匙，用户数字证书，以及用户的信任点（可信的人证机构）的集合的数据结构；

*Oracle Wallet Manager，用来在Oracle Wallet中管理和编辑安全信任状的一个单独的Java应用程序；

*X.509v3 证书是由oracle之外的认证机构签署和发布的一个证书；

*oracle网络目录是用来为用户管理安全属性以及权限，包括通过 X.509 证书进行用户身份验证。oracle网络目录能够加强对属性级别的访问控制并且控制对指定属性的读，写，或者更新的特权被限制在指定的用户，比如：管理员；

*Oracle Enterprise Security Manager，提供了集中管理权限的功能来使管理员的管理更简单并且增强了安全级别。这种功能让用户能够在Oracle Internet Directory中存储和提取角色信息；

*Oracle Enterprise Login Assistant,是一个基于java的工具，打开和关闭一个用户的wallet，来控制一个应用程序使用SSL和不使用SSL通信。

 

远程身份验证

Oralce通过Remote Dial-In User Service (RADIUS)来支持远程的身份验证，Remote Dial-In User Service (RADIUS)是一个用来身份验证，授权以及审计的标准的轻量级协议。

 

Oracle数据库身份验证

Oracle数据库能够使用存储在数据库中的信息来验证试图连接数据库用户的身份。

为了安装oralce使用数据库身份验证，为每个用户创建一个相关的密码，这个密码是用来在当用户试图建立一个连接时所必须提供的。如果用户提供了一个不正确的密码连接被否决了，这样就会防止未授权的数据库使用。Oracle在数据字典中以加密的格式存储一个用户的密码，来防止未授权的变更，但是一个用户能够在任何时候变更密码。

数据库授权包括下面的功能：

*密码加密

*帐号锁定

*密码有效期和截止日期

*密码复杂度验证

 

密码加密

为了保护密码的机密性，oracle总是在通过网络传输密码之前必须对密码加密。Oracle使用被修改的AES算法来对密码加密。

 

帐号锁定

当一个用户连续试图登陆失败的次数超过指定的数量时，oracle会锁住该用户的帐号。你可以配置在指定的时间间隔之后自动地锁住帐号或者让数据库管理员干涉来为帐号解锁。数据库管理员也能够手动锁住帐号，以便他们必须通过管理员来显式的解锁。

 

密码的有效期和截止日期

数据库管理员能够指定密码的有效期，在密码过期之后并且需要在帐号再次被允许登陆之前必须改变。DBA可以设置密码宽限期，在宽限期内每个试图登陆数据库的帐号都会接受一个警告提示用户修改密码。如果密码到宽限期结束时还没有被修改，然后这个帐号就会被锁住。这个被锁住的帐号在下次登陆时如果没有数据库管理员的帮助是不能登陆系统的。

数据库管理员也可以设置密码的状态为过期状态，这样引起了用户的帐号状态变更为过期状态。数据库管理员或者必须在登陆数据库之前改变密码。

密码历史对比选项能够检查每个新定义的密码来确保与之前一定时间内的密码重复或者与之前一定时间内的密码相似。

密码复杂度验证

密码复杂度验证是检查每个密码是否足够复杂来提供对密码的合理保护，避免有入侵者试图通过猜密码而能够进入系统。

Oracle默然的密码复杂度验证程序是检查每个密码满足下面的条件：

*在密码长度上要求最少有4位

*密码不等于用户ID号

*包括至少一个字母，一个数字以及一个标点符号

*不能于数据库内部的简单词汇相匹配，像welcome, account，database，user等词汇就不行；

*与之前的密码相比至少有三个密码不相同；

 

多层验证和授权

在多层环境中，oracle通过限制他们的权限，通过等级来保护客户的身份，以及审计客户所操作的活动的方式来控制中间层应用程序的安全性。在采用重量级的中间层的应用程序（比如：事务处理监控器）中，连接中间层的客户身份的验证必须被保护。中间层的一个优势是有一个连接池，这个连接池会允许多用户不需要每个用户使用单独的连接的方式来访问数据服务器。在这样的环境下，你必须能够快速地建立和结束用于身份验证的连接。

对于这些环境，oracle数据库管理员能够使用Oracle Call Interface (OCI)创建轻量级的会话，来对每个用户进行数据库密码身份验证。这样通过中间层保护了用户的真实身份，不需要为每个用户建立单独的数据库连接。

你能够使用密码或者不使用密码来创建轻量级的会话。但是，如果一个中间层在外部或者在防火墙上，当每个轻量级的会话都有属于它自己的密码时，安全性是很好的。对于一个内部的应用服务器，没有密码的轻量级会话可能是适当的。

 

SSL协议的身份验证

安全套接字层（SSL）是一种应用层协议。外部用户或者全局用户可以通过SSL协议来进行数据库身份验证。

 

数据库管理员的身份验证

数据库管理员执行特别的操作（比如：关闭数据库或者重新启动数据库），这些特别的操作是一般的数据库用户不应该执行的。Oracle为数据库管理员用户的名字提供了一个更加安全的身份验证模式。

用户可以使用操作系统身份验证，也可以使用密码文件对数据库管理员进行身份验证。图20-1说明了对于数据库管理员身份验证模式用户所拥有的选择。对于管理本地数据库（数据库所安装的机器）以及对于通过一个单独的远程客户管理许多不同的数据库机器，应用不同的选择。

图20-1 数据库管理员身份验证方法

 

对于数据库管理员进行操作系统身份验证包括将操作系统用户名存放在一个特定的组中或者授予该用户特殊的处理权利。（在UNIX系统中，该组是DBA组）

数据库使用密码文件来来跟踪已经授予SYSDBA和SYSOPER权限的数据库用户名，使该用户能够有下面的操作：

*SYSOPER能够让数据库管理执行startup,shutdown,alter database open/mount, alter database backup,archive log以及recover，以及包括restricted  session特权；

*SYSDBA包含所有的带有ADMIN OPTION的系统权限，以及SYSOPER系统权限。允许CREATE  DATABASE以及基于时间的恢复。

 

授权的概述

授权主要包括两个过程：

*只允许一定的用户来访问，处理，或者变更数据；

*对用户的访问或者活动应用了各种限制。对于用户的这些限制能够应用到对象中，比如：方案，表，或者行，或者资源比如时间（CPU，连接，或者空闲时间）

这部分介绍了对于用户（单一用户或者一组用户）添加或者删除这些限制的基本的概念和机制。

 

用户资源限制和配置模板

数据库管理员可以对每个用户设置可用的各种系统资源的数量作为用户安全管理的一部分。通过这样设置，数据库管理员可以防止重要的系统资源比如CPU时间被没有控制的消耗。

在大的多用户的系统中这个是非常有用的，因为在大的多用户系统中系统资源成本是很高的。资源被一个或者多个用户过多的消耗会严重影响到数据库的其他用户对数据库的使用。

可以使用数据库配置文件来管理用户的资源限制已经一密码管理，数据库配置文件是分配给该用户的资源限制的指定集合。每个数据库能够有无数的配置文件。安全管理员可以全局地对系统是否采用配置模板来对用户进行资源限制。

如如果你设置了资源限制，当用户创建了会话时，在性能上会有一点下降。这是因为当用户连接到数据库时oracle会加载用户的所有资源限制数据。

 

资源限制和配置文件在下面的部分讨论：

*系统资源的类型和资源限制的类型

*配置文件

 

系统资源的类型和资源限制的类型

Oracle能够限制系统资源一些类型的使用。包括CPU时间，以及逻辑读。一般地，数据库管理员可以在会话级，调用级或者同时在这两个级别上控制每个资源。

 

会话级

每个用户连接数据库时，一个会话就被创建。每个会话会消耗运行oracle的机器的CPU时间和内存。你能够在会话级别上对一些资源进行限制。

如果用户超过了一个会话级别的资源限制，oracle会终止（回滚）当前的语句执行并且会返回一个消息说明该会话的限制已经达到了。在这个点上，所有在当前事务中的先前执行的语句是完整的，并且用户能够执行的仅有操作是commit,rollbackm或者断开连接（在当前这个情况下，事务是被提交的）。所有其他的操作会产生一个错误。在该事务被提交或者回滚之后，用户在当前的会话中不能再继续工作。

 

调用级

每个SQL语句被执行的时候，处理该语句有几个步骤。在这个处理过程中，一些对数据库的调用作为不同执行阶段的一部分。为了防止在系统中任何一个调用过度，oracle会在调用级别上设置一些资源的限制。

如果用户超过了调用级别的资源限制，oracle会停止语句的处理，回滚该语句，并且返回一个错误。但是，在当前事务中的所有先前执行的语句保持完整，并且用户的会话保持连接状态。

 

CPU时间

当执行SQL语句和执行其他类型的调用时，处理调用的过程需要消耗一定的CPU时间。一般的调用需要消耗少量的CPU时间。但是，一个需要处理大量的数据量或者失控的查询语句能够潜在地消耗大量的CPU时间，这样就减少了其他处理可用的CPU时间。

为了防止CPU无控制的使用，限制每个调用的CPU时间以及在一个会话中oracle调用所使用的CPU时间的总量。限制在一个调用和一个会话中所使用的CPU时间的实质和衡量是以百分之一秒为单位的。

 

逻辑读

输入/输出 在数据库系统中是成本比较高的一个操作。I/O操作密集的SQL语句会占用内存和磁盘的使用，导致与其他需要这些资源的数据库操作产生竞争。

为了防止I/O被独占，oracle需要为每个调用和每个会话限制逻辑数据块读。逻辑数据块读包括来自内存和磁盘的数据块读。为每个调用和没个会话设置和衡量逻辑读的限制是以数据块的数量为单位的。

 

其他资源

Oracle也为其他一些资源在会话级别上设置了一些限制：

*你可以为concurrent sessions for each user设置数量。每个用户所创建的并发会话的数量只能达到预定的数量；

*你能够为会话设置idle time。如果会话内两次oracle调用之间的时间间隔达到了空闲时间的限制，那么当前的事务就会被回滚，会话也会被终止，并且会话的资源被释放给系统。下一个调用接受到错误的信息说明该用户不再连接到数据库实例。该限制的设置单位为分钟。

当一个会话超过了空闲时间的设置而该会话被终止之后 ，PMON进程在终止会话之后进行清理。在PMON完成了该进程之前，统计用户及会话资源使用时仍将包含被终止的会话。

*管理员可以为每个会话设置持续的连接时间。如果一个会话的持续连接时间超过了该限制值，那么当前的事务就会被回滚，会话就会被删除。并且会话的资源返回给系统。这个限制的设置单位是分钟。

Oracle不会不间断地监控空闲时间和持续时间。因为这样做降低系统性能。Oracle而是每几分钟检查一次。因此，在oracle执行这个限制并且终止这个会话之前该会话能够稍微地超过这个限制（比如：几分钟）；

*数据库管理员可以限制一个会话的私有的SGA空间（私有的SQL区域）的数量。这个限制只有在那些使用共享服务配置的系统中才是非常重要的。在专有的服务配置中私有SQL区域是存在PGA中。在一个实例的SGA中该限制的设置是以内存的字节数为单位的。使用字母K或者M来定义千字节和兆字节。

 

配置文件

在系统资源的上下文中，一个配置文件是一个命名的资源限制的集合，这个配置文件可以分配给数据库中一个有效的用户。配置文件对资源限制的管理提供了方便。配置文件也可以用来管理密码策略的一种方式。

管理员可以创建不同的配置文件并且将这些配置文件分配给数据库中的每个用户。一个默认的配置文件分配给那些没有显式分配配置文件的所有用户。资源限制特性防止了全局数据库系统资源的过多消耗。

 

什么时候使用配置文件

如果资源限制是数据库安全策略的一个需要的话，就需要创建和管理用户的配置文件。为了使用配置文件，首先要对数据库内有关的用户类型分类。就象角色是被用来管理相关用户的权限，配置文件是用来管理相关用户的资源。管理员首先确定需要多少配置文件来包含数据库中所有的用户类型，然后为每个配置文件决定适合的资源限制。

 

决定配置文件中的资源限制的值

在创建配置文件和设置相关的资源限制之前，为每个资源限制决定适当的值。你可以依据典型用户执行的操作的类型来设置这些值。通常，为一个用户配置文件决定适合的资源限制值的最好的方式是为每个资源使用的类型聚集历史信息。

你可以使用oracle企业管理器的监控特性，尤其是统计监控器，来为其他限制收集统计信息。

 

权限的介绍

一个权限是运行一个特殊特性的SQL语句或者访问其他用户的对象的权利。

对用户授予权限以便他们可以完成这些用户工作中所需要完成的任务。授予权限只授予那些绝对需要这些权限的用户。过多的授予那些不需要的权限会有安全隐患。一个有两种方式来接受一个权限：

*你可以显式地授予权限。例如：你可以显式地将向EMPLOYEE表的插入记录的权限授予给SCOTT用户；

*你可以给一个角色（一个已命名的权限组）授予权限，并且然后将这个角色授予给一个或者多个用户。例如：你可以将对表EMPLOYEES表的查询，插入，更新，以及删除记录的权限授予给角色名为CLECK这个角色，然后你可以将这个角色授予用户SCOTT以及brain。

因为角色给对权限的管理带来简单化和更好的管理，所以你应该一般地授予权限给角色而不是授予给用户。

有两种不同的权限分类：

*系统权限

*方案对象权限

 

系统权限

一个系统权限是一个执行特殊活动，或者对一个特殊类型的任何方案对象执行活动的权利。例如：创建表表空间以及删除数据库中的任何表中的记录的权限是系统权限。在数据库中有100个不同的系统权限。

 

方案对象权限

一个方案对象权限是一个在一个特定的方案对象上执行一个特殊活动的权限和权利。

不同的对象权限对于不同类型的方案对象是可用的。比如：从表departments删除行记录的权限是一个对象权限。

一些方案对象，比如：簇，索引，触发器以及数据库连接，没有必要和对象权限相关。这些方案对象的使用是由系统权限控制的。比如：为了变更一个簇，用户必须拥有该簇或者有 alter any cluster的系统权限。

一个方案对象和它的同义词对于权限来说是一个对象。对表，视图，序列，存储过程，函数，或者包授予的对象权限，既可以通过名字引用基本的对象，也可以使用同义词。

如果同义词被使用的话，将对表，视图，序列，存储过程，或者包对象授予权限与对该对象的同义词授予权限有相同的效果。当一个同义词被删除的话，即便授权时引用的是该同义词名称，所有对该同义词所对应的方案对象仍然保持有效。

 

角色的介绍

通过使用角色使得管理和控制权限更加容易，角色是命名的相关的一组权限，作为组被授予给用户或者其他角色。在数据库中，每个角色名必须唯一，不同于用户名以及所有其他的角色名。不象方案对象，角色不包含在任何的方案中。因此，创建角色的用户被删除对于该角色是没有影响的。

角色使终端用户系统和方案对象权限的管理更加简单。但是，角色并不会被应用程序开发者所使用，因为在存储程序结构中访问方案对象的权限必须被直接授予。

角色的下面的属性使得在数据库中对权限的管理更加简单：

属性	描述
减少权限管理工作	而不是将相同权限集合显式地授予多个用户，你可以将相关的用户组授予一个角色，然后只需要将角色授予给组中的每个成员
动态权限管理	如果一个组的权限必须改变，然后只需要修改角色的权限。所有被授予组角色的用户的安全域自动地反映出对角色所做的变更。
设定权限的可用性	可以选择性地给用户设置角色所授予的权限。这样就可以在任何情况下可以控制用户的特定权限
通过应用程序自动管理	数据字典记录了哪些角色在数据库中存在，所以你可以设计应用程序来查询数据字典并且当用户试图使用被给予的用户名来运行应用程序时，自动地有选择性的授予这个用户权限
应用程序管理的安全性	你可以使用密码保护角色的使用。用户需要提供密码应用程序才能够决定是否授予该用户这个角色。如果用户不知道密码的话，用户是不能够授予该角色的。

数据库管理员经常为一个数据库应用程序创建角色。DBA需要授予一个安全应用程序角色所需要的权限，然后将安全应用程序角色授予其他角色或者用户。一个应用程序能够有一些不同的角色，当使用应用程序时，每个授予不同的权限集合的角色允许或多或少的数据访问。

DBA使用密码创建一个角色来防止未授权的用户使用该角色中的权限。典型地，一个应用程序被设计以便当应用程序开始运行时，应用程序会启用相关的数据库角色。所以，应用程序无需知道相关的应用程序角色的密码。

 

角色的一般用途

一般来说，创建一个角色主要有两个目的：

*管理数据库应用程序的权限

*管理一个用户组的权限

 

图20-2 下面部分主要讲了角色的两个用途

图20-2 角色的一般用途

 

应用程序角色

你将运行数据库应用程序需要的所有权限授予一个应用程序角色。然后，你可以将安全应用角色授予其他角色或者指定的用户。一个应用程序可以有多个不同的角色，每个角色被分配不同的权限集合，这些权限集合在使用应用程序时能够允许用户或多或少的数据访问。

用户角色

可以为有一般权限需要的数据库用户组授予用户权限。你可以通过授予安全应用角色和授予用户角色权限的方式来管理用户权限，然后将用户角色授予适当的用户。

 

角色机制

数据库角色有下面的功能：

*一个角色能够被授予系统权限或者方案对象权限

*一个角色可以被授予其他角色。但是，一个角色不能够授予它自己并且不能够循环授予。例如：如果角色B已经被授予给角色A，那么角色A就不能够授予给角色B。

*任何角色能够授予给任何数据库用户

*被授予用户的每个角色，在给定的时间内，或者是可用的或者是不可用的。一个用户的安全域包括当前为该用户可以使用的所有角色的权限，并且不包括当前为该用户不可以使用的所有角色的权限。

*当一个角色被授予给另一个角色时，前者被称为间接授予角色。该角色可以显式地为该用户启用或者禁用。但是通过启用那个包含其他角色的角色，你可以隐式地启用直接授予角色中的间接授予角色。

 

操作系统和角色

在一些环境中，你可以通过操作系统管理数据库安全。操作系统能够被用来管理数据库角色的授予和撤消和管理这些角色的密码身份验证。但是此功能并是所有的操作系统都可用的。

 

安全应用角色

Oracle提供了安全应用角色，安全应用角色只能够通过授权的PL/SQL包来启用。这种机制限制了调用应用程序中这样的角色的启用。

当密码没有嵌入到应用程序源代码中或者存储在表中这样系统的安全性增强了。取而代之的是，一个安全应用角色能够被创建，并指定哪个PL/SQL包是被授予给角色并且启用该角色。包的身份被用来决定是否权限足够来启用该角色。在启用该角色之前，应用程序能够执行身份验证和自定义身份验证，比如：检查该用户通过协议是否已经连接到数据库。

因为在定义者的正确的存储过程中用户不能改变安全域的限制，安全应用角色只能够在调用者的存储过程中被启用。

 

对表，视图，同义词，或者行记录的访问限制

这部分描述的是不与用户有关的限制，但是和对象有关。这些限制不管那些寻求来访问或者修改这些对象的实体，为这些对象提供了保护。

你通过设计和使用原则来提供保护来限制对特定表，视图，同义词，或者行记录的访问。这些原则调用数据库管理设计用来定义动态谓词建立限制的函数。数据库管理员也可以将已经建立的原则分组，将一个原则组应用到一个特殊的应用程序中去。

建立好这样的原则保护之后，当这些原则被威胁到或者被违背时需要通知数据库管理员。通知知道之后，你数据库管理员可以加强预防或者处理不适当行为的后果和处理造成这些威胁的实体。

 

精细粒度访问控制

精细粒度访问控制让你使用函数来执行安全原则以及和将这些安全原则和表，视图或者同义词联系起来。数据库服务自动地加强数据库的安全原则，不管数据是如何被访问的（比如：即席访问）。

你可以：

*为select ,insert ,update 和delete（以及index ，对于行级安全原则）使用不同的安全原则；

*只有在需要这些安全原则的地方使用安全原则（比如：对薪水信息）；

*为每张表使用多个原则，包括在被打包的应用程序中的基础原则上建立新的原则；

*通过使用原则组，针对不同的应用程序使用不同的安全原则。每个安全原则组是一组属于一个应用程序的原则的集合。数据库管理员需要指定一个应用程序的上下文，被称为驱动上下文，来控制原则组是否生效。当表，视图，或者同义词被访问时，精细粒度访问控制引擎查询上下文来决定原则组是否生效以及执行所有属于那个原则组的相关原则。

PL/SQL包DBMS_RLS让你管理安全原则，使用这个包，你可以添加，启用，禁用以及刷新你创建的原则（或者原则组）。

 

动态谓词

当基表或者视图在DML语句中被引用时，而不是将安全原则嵌入到视图中，动态谓词在语句解析时是被需要的。

执行你创建的安全原则的函数或者包返回一个谓词。这个谓词根据原则的定义来控制访问。查询重新是被优化的以及共享的。

对于表，视图，或者同义词的动态谓词是由PL/SQL函数生成，这个憾事通过一个PL/SQL接口和一个安全原则有关联。

 

应用程序上下文

应用程序上下文帮助你应用精细粒度访问控制因为你能够将基于函数的安全原则与应用程序相关联。

每个应用程序都有属于它自己特定的上下文，这些上下文用户不能够随意的改变（例如：通过SQL*Plus）。上下文属性是对于那些执行安全原则的函数来说是可访问的。例如：对于人力资源应用程序的上下文属性能够包括“位置”，“组织单元”，以及“国家”，然后对于定单列表控制的属性可能是“客户数量”以及“销售区域”。

应用程序上下文因此可以根据应用程序的属性信息来对应用程序进行灵活的，基于参数的访问控制。

你可以：

*基于上下文属性值生成谓词

*在谓词中使用上下文的值作为绑订变量

*设置用户属性

*访问用户属性

 

动态的上下文

可以通过定义一个原则是静态的，共享的，基于上下文的，或者还是动态的方式，来确认你的安全原则在运行时的效率高的方式。

如果是静态的，对于任何人访问对象产生同样的谓词字符串，然后将谓词运行一次并且缓存在SGA中。对于访问相同对象的语句的安全原则不再需要重新运行安全原则函数，而是使用缓寸中的谓词。

对于静态原则的方式也适合于共享静态原则，对于共享静态原则服务器首先查找通过相同原则类型的相同原则函数所产生的缓存谓词。对于数据分区是适合采用共享静态安全原则的因为几乎所有的对象共享相同的函数并且原则都是静态的。

如果选择了基于上下文方式，然后服务总是在当语句在解析时使用原则；这种方式不会缓存返回的值。只有在自从最后一次使用游标之后检查到上下文有变更时，原则函数才会在语句执行时重新评估上下文。（对于多个客户端共享一个数据库会话的会话池，中间层复杂在用户切换时重新设置上下文）。

如果基于上下文原则是共享的，服务首先查询在相同会话中相同原则类型的相同原则函数所产生的缓存谓词。如果谓词在该会话内存中被发现，那么原则函数就不会被重新运行并且缓存值是有效的，除非会话应用程序的上下文发生改变。

对于动态的原则，服务器假设可能会在任何时候被任何系统或者任何会话环境所影响，并且在每个语句解析或者执行时都会重新运行原则函数。

 

精细粒度审计

精细粒度审计允许基于上下文的数据访问的监控。精细粒度审计对查询，以及插入，更新以及删除操作提供粒度审计。比如：中央税务部门需要通过获取数据被访问的详细信息来跟踪对退税数据的访问，以防止员工为规查询。知道对特定的表的查询权限被特定的用户使用这个信息不够的。精细粒度审计提供了更深入的信息。

一般而言，精细粒度审计原则是基于对表对象的简单的自定义的SQL谓词，并且将这些SQL谓词作为审计选择条件。在获取数据阶段，对于一个返回的数据行只要原则条件满足，那么查询将被记录下来。之后，oracle使用自治事务来运行用户自定义的审计事件处理器来处理事件。

能够使用DBMS_FGA包或者使用数据库触发器来在用户应用程序中执行精细粒度审计。

 

安全原则的概述

这部分包含下面的内容：

*系统安全原则

*数据安全原则

*用户安全原则

*密码管理原则

*审计原则

 

系统安全原则

每个数据库都有一个或者多个数据库管理员负责维护安全原则的所有方面：这个角色为安全管理员。如果数据库系统是非常小的话，数据库管理员可能可能会负责数据库安全管理这方面。但是，如果数据库系统非常的大，那么就需要有专门的人或者组来负责这些安全的管理。

每个数据库都需要制定一个安全管理原则。一个安全管理原则应该包括几个子原则，下面部分将描述这些子原则：

数据用户管理

根据数据库系统的大小以及管理数据库用户所需要的数据库的工作量，来决定是否需要一个专门的安全管理员有权限来管理数据库用户的创建，修改或者删除操作。也有可能需要多个安全管理员有权限来管理数据库用户。只有可信的人才可以有权限管理数据库用户。

用户身份验证

可以通过数据库密码，数据库所在的操作系统，网络服务，或者安全套接字层的方式来授予数据库用户权限（验证数据库用户是否为有效的用户）。

操作系统安全

如果可行的话，在执行 oracle或者是任何数据库应用系统时对于操作系统环境下面的安全问题必须要考虑：

*数据库管理员必须有创建和删除文件的操作系统权限；

*典型地数据库用户不应该有创建或者删除与数据库相关的操作系统权限；

*如果操作系统识别出用户的数据库角色，然后安全管理员必须有修改操作系统帐号安全域的操作系统权限；

 

数据安全原则

数据安全包括在对象级别上控制对数据库的访问和使用机制。你的数据安全原则决定了哪些用户对指定的方案对象可以访问，并且在该对象上对于每个用户都允许指定的活动类型。比如：用户scott可以对表employee进行查询以及插入，但是不可以使用删除语句。如果每个方案对象都被审计，那么数据安全原则也应该定义相应的行为。

你的数据安全原则在数据库中主要是根据需要的安全级别来决定的。比如：当你想允许任何用户都可以创建方案对象或者将这些对象的访问权限授予给系统的任何其他用户时，在数据库中数据安全原则级别是比较低的。当你想使数据库管理员或者安全管理员有权限来创建对象以及将对象的访问权限授予角色和用户时，数据安全级别比较高的。

整体的数据安全应该是基于数据的敏感。如果这些信息不是敏感信息的话，数据安全原则级别是比较低的；如果数据是敏感数据，那么安全原则应该是对对象的访问进行严格的控制。

执行数据安全的一些手段包括系统和对象权限，以及通过角色。一个角色是能够授予用户的组合在一起的权限的集合。视图也可以执行数据安全因为视图的定义可以限制对表数据的访问。他们能够排除包含敏感数据的列。

执行数据安全的另一个手段是通过精细粒度访问控制以及对一个相关的应用上下文的使用的方式。精细粒度访问控制让你能够使用函数执行安全原则并且将这些安全原则和表或者视图相关联。在效果上，安全原则函数是产生一个WHERE条件，这个条件被添加到一个SQL语句中，因此对表或者视图中的行记录的访问做了一些限制。一个应用程序上下文是对于存储用来决定数据访问控制决定的信息来说是一个安全的数据缓存。

 

用户安全原则

这部分描述了用户安全原则的方面，并且包含了下面的内容：

*一般用户的安全

*终端用户的安全

*管理员安全

*应用开发者安全

*应用管理员安全

 

一般用户安全

对于所有数据库类型，考虑密码安全和权限管理。

如果用户身份验证是由数据库管理的话，那么安全管理员应该开发出一个密码安全原则来维护数据库访问安全。比如：数据库用户必须变更在规定的时间间隔内改变他们的密码。通过 强制用户修改密码的方式，未授权的数据库访问能够减少。为了能够更好地保护用户密码的机密性，oracle能够为客户/服务以及服务/服务之间的连接使用给密码加密的方式来给密码配置下。

也需要考虑对于各种用户类型与权限管理相关的问题。比如：有许多用户，有许多应用程序或者许多对象的数据库的数据库能够通过使用角色来管理用户可以使用的权限，这样对于数据库是有益的。相反，有大量用户的数据库内部，可能明确的授予用户权限的方式会更好并且避免角色的使用。

 

终端用户的安全

安全管理员必须为终端用户的安全定义一个原则。如果一个数据库有许多用户，那么安全管理员能够决定哪些用户组能够被分类成为用户组，并且为这些用户组创建用户角色。安全管理员能够对每个用户角色授予必须的权限或者应用角色，并且分配用户角色给这些用户。为了考虑一些异常，安全管理员也必须需要决定哪些具体的权限必须显式地授予单个用户。

角色是授予和管理不同的数据库用户组所需要的一般权限的最简单的方法。在直接目录中，通过oracle高级安全的企业用户和企业角色特性，你也能够集中管理用户和他们的授予情况。

 

管理员安全

安全管理员需要为数据库管理员定义安全原则。比如：当数据库很大并且有几种数据库管理员，安全管理员可能会决定将相关的管理权限分组为几个管理角色。管理角色可以授予适当的管理用户。相反，当数据库很小并且只有几个 管理员，安全管理员可能只需要创建一个管理角色并且将这个角色授予所有的管理员。

 

作为SYS和SYSTEM用户连接数据库的保护

当数据库被创建时，并且如果使用SYS和SYSTEM的默认密码的话，需要立即为SYS和SYSTEM管理用户修改密码。以SYS和SYSTEM用户连接数据库给该用户一个强大的权限来修改数据库。

如果你已经安装了创建其他管理用户的名字的选项的话，那么这些用户帐号被创建之后初始状态是被锁住的。

 

管理员连接的保护

只有数据库管理员应该有能力通过使用管理权限来连接数据库。比如：

Connect  username/password AS SYSDBA/SYSOPER

作为SYSOPER身份连接使该用户有执行基本（比如：STARTUP，SHUTDOWN ，以及恢复操作）的操作任务的能力。以SYS身份连接数据库使该用户具有SYSOPER用户的能力以及在数据库中对数据库或者对对象有可以做任何操作的不受限制的权限（包括：CREATE，DROP以及DELETE）。SYSDBA将SYS用户放在SYS方案中，在SYS方案中该用户可以修改数据字典表。

 

应用程序开发者安全

安全管理员必须为使用数据库的应用程序开发者定义一个安全原则。一个安全管理员能够授予应用程序开发者创建需要的对象的权限。或者，相反，创建对象的权限可以能够被授予给数据库管理员，DBA根据数据库开发者的要求创建对象的请求来创建对象。

 

应用程序开发者和他们的权限

数据库管理员应用程序开发者是特殊的用户，这些用户需要特别的权限组来完成他们的任务。不象终端用户，开发者需要系统权限，笔比如：CREATE TABLE，CREATE PROCEDURE等等。但是，只有特殊的系统权限应该被授予给开发者来限制开发者在数据库中的整体的能里。

在许多案例中，应用程序开发被限制来测试数据库并且不允许在生产库上。这样的限制确保了应用程序开发者和终端用户不会竞争数据库资源，并且他们不会严重影响到一个生产库。在一个应用程序已经被完全开发和已经测试之后，应用程序才能够允许访问生产库并且允许生产库上适当的终端用户访问该应用程序。

安全管理员能够创建角色来管理典型的应用程序开发者所需要的权限。

当应用程序开发者在开发过程中部分被授予创建对象的权限，安全管理员必须维护对哪些数据库表空间以及有多少数据库表空间被每个应用程序开发者所使用的问题进行限制。比如：安全管理员应该为每个应用程序开发者设置或者限制下面的限制：

*开发者能够在哪些表空间进行创建表或者索引

*对每个表空间开发者能够访问的限额

这两个限制是通过修改开发者的安全域的方式来设置的。

 

应用程序管理员的安全

在多个数据库应用程序使用的大的数据库系统中，考虑分派一个应用程序管理员来负责下面的责任：

*为一个应用程序创建角色并且为每个应用程序角色管理权限

*创建和管理被一个数据库应用程序管理的对象

*必要的时候，需要维护和更新应用程序代码以及oracle存储过程以及包

经常地，一个应用程序管理员也是设计应用程序的开发者。但是，一个应用程序管理员能够是任何一个了解数据库应用程序的人员。

 

密码管理原则

依赖密码的数据库安全系统需要密码一直被保密。你可以决定禁用数据库审计除非需要怀疑存在问题。当需要审计时，决定审计数据库的详细级别；通常得，一般系统的审计先确定可疑活动来源，再进行各类详细审计。审计在下面的部分主要讨论。

 

数据库审计的概述

审计是有选择性的对数据库用户的活动进行监控以及记录。审计可以是基于单个的活动，比如：SQL语句运行的类型，也可以是基于多种因素的组合。比如：名字，应用程序，时间等等。当数据库中指定的成员被访问或者被修改，包括内容时，那么安全原则可以被设置在这个时候进行审计。

审计一般被用来：

*记录在特定的方案中对表，或者行记录，或者影响特定内容的当前活动，确保将来具有可审计性；

*调查可疑的活动。比如：如果一个未授予权限的用户删除了表中的数据，那么安全管理员应该审计对数据库的所有连接，以及审计所有对数据库中的表进行删除记录成功以及不成功的操作。

*监控和收集有关特定数据库活动的数据。比如：数据库管理员能够收集关于哪些表被更新，有多少逻辑I/O被执行，或者在高峰期有多少并发的用户等的统计信息。

你可以使用企业管理器来查看和配置审计相关的初始参数并且设置是根据语句审计还是方案对象审计来管理被审计的对象。比如：企业管理器显示了当前被审计的语句，权限，以及对象的属性。你可以查看每个对象的属性，并且你可以通过这些对象的属性查找被审计的对象。你能够打开和关闭对对象，语句以及权限的审计。

 

审计的记录和类型

Oracle允许审计选项设置为聚焦审计型或者是大范围审计类型。你可以审计：

*审计成功的语句执行，不成功的语句执行，或者两者都被审计

*只有在每个用户会话中或者在每次语句被运行的时候审计语句执行

*所有用户的活动或者指定用户的活动审计

Oracle审计有几种不同的机制的使用，有下面的特性：

表20-1 审计类型

审计类型	含义/描述
语句审计	根据语句类型来审计SQL语句，而不是根据他们操作的特定的方案对象。一般来说，语句审计为每个选项审计相关的活动的几种类型的使用。比如：ADUIT  TABLE 不管这些语句所操作的表只跟踪一些DDL语句。你也可以设置语句审计来审计选定的用户或者是数据库中的所有用户。
权限审计	启动相应的活动比如；ADUIT CREATE TABLE 来审计强大系统的权限的使用。权限审计是比语句审计目标更加集中因为权限审计只审计目标权限的使用。你可以设置权限审计来审计在数据库中的指定用户或者所有用户。
方案对象审计	审计基于特定方案对象指定的特定语句，比如：ADUIT SELECT ON employees。方案对象审计是非常集中的，是基于特定方案对象的只审计特定的语句。方案对象审计总是应用到数据库中的所有用户。
精细粒度审计	审计数据访问并且审计基于内容的活动。使用DBMS_FGA包，安全管理员针对目标表创建一个审计原则。如果DML语句返回的任何行记录与审计条件相匹配，那么一个审计事件记录会被插入到审计跟踪库中。

 

审计记录和审计跟踪库

审计记录包括的信息比如：被审计的操作，用户执行的操作，以及操作的日期和时间。审计记录能够被存储在或者数据字典中，被称为数据库审计跟踪库，或者存储在操作系统文件中，被称为操作系统审计跟踪库。

 

数据库审计跟踪库

数据库审计跟踪库是每个oracle数据库中的数据字典中SYS方案里的一个命名为SYS.ADU$的表。一些预定义的视图会帮助管理员使用在这张表中的信息。

审计跟踪库记录包括不同类型的信息，依据被审计的事件，以及审计的选项设置。如果这些信息对于特殊的审计活动是有意义的，下面的新鲜是包括在每个审计跟踪记录中的。

*用户名字

*实例号

*进程标识符

*会话标识符

*终端标识符

*被访问的方案对象的名字

*已执行的或者试图执行的操作

*操作的结束代码

*日期和时间戳

*使用的系统权限

 

在分布式数据库中的审计

审计只能针对节点自身。一个实例只针对被直接连接到该实例上的用户发起的语句进行审计。一个本地oracle节点不能审计那些发生在远程数据库中的活动。因为远程连接是通过数据库Link的用户帐号建立连接的，通过数据库link的连接发起的语句被远程oracle节点所审计。

 

操作系统的审计跟踪库

如果操作系统使这样的审计跟踪库对于oracle来说是可以获取的话，Oracle允许审计跟踪记录被直接记录到操作系统审计跟踪库中。如果操作系统的审计跟踪库对于oracle来说是不可以获取的话，那么审计记录被写到数据库外部的一个文件中去，以类似于其他oracle跟踪文件一样的格式。

即使当操作系统审计跟踪库（或者包含审计记录的操作系统文件）不能够记录审计记录时，oracle允许一些审计活动继续进行。通常造成不能够记录审计记录的原因是操作系统审计跟踪库或者文件系统已经满了并且不能接受新的审计记录。

配置操作系统审计的系统管理员应该确保审计跟踪库或者文件系统不完全被添满，大多数系统为管理员提供足够的信息和警告来确保上面的情况不会发生。注意：但是，使用数据库审计跟踪库来配置审计就会消除这种弱点，因为如果审计跟踪库不能够为该语句接受数据库审计记录的话，oracle数据库服务器会防止审计事件的发生。

 

操作系统审计记录

操作系统审计跟踪库是经过编码的，并且可以通过数据字典和错误消息来解码。

*操作代码：描述了已经执行过或者试图执行的操作。AUDIT_ACTION数据字典表描述了这些代码。

*权限使用的代码：描述了用来执行操作的任何系统权限。SYSTEM_PRIVILEGE_EAP表描述了所有这些代码。

*操作结束代码：描述了试图操作的结果。成功的操作返回0值，并且不成功的操作返回oracle的错误代码来描述为什么操作是不成功的。

 

总是写入操作系统审计跟踪库中的审计记录

一些数据库相关的活动总是被记录在操作系统审计库中不管数据库审计是否被启用。

*在数据库实例被启动的时候，审计记录产生，详细描述了操作系统用户启动实例，用户的终端标识符，日期和时间戳，以及数据库审计是否被启用或者禁用。这个信息被记录在操作系统审计跟踪库中，因为数据库审计跟踪库不能够获取这些信息的直到数据库成功地启动之后。在数据库启动的时候记录数据库审计的状态的作用是作为一个审计标志，防止在数据库在数据库重新启动时将数据库审计禁用的话就执行未审计活动。

*在数据库被关闭的时候，一个审计记录产生详细描述了操作系统用户关闭数据库实例，用户的终端标识，以及日期和时间戳。

*在使用管理员权限连接数据库时，一个审计记录产生记录了使用管理员权限连接到oracle数据库的操作系统用户。这个记录对使用管理员权限连接到oracle数据库的操作系统用户提供了具有可审计性。

对于那些使审计跟踪库不能被oracle所访问的操作系统来说，这些审计跟踪库记录被放置在相同目录下的一个oracle审计跟踪库文件中作为后台进程跟踪文件。

 

审计记录是什么时候被创建的

任何授权的数据库用户能够在任何时候设置他们自己的审计选项，但是审计信息的记录是通过安全管理员来启用或者禁用的。

当审计功能在数据库中被启用时，一个审计记录在语句执行阶段产生审计信息。

当PL/SQL程序单元被运行的时候，根据需要，在PL/SQL程序单元中的SQL语句被单独的审。

一个审计跟踪记录的产生和插入是独立于用户事务的提交的。也就是说，即使用户的事务被回滚，审计记录也被记录并且提交。

在数据库用户连接到数据库时有效的语句和权限审计选项在该会话期间始终保持有效。在该会话中设置或者改变语句审计或者权限审计选项在该会话中不会起作用。被修改的语句审计或者权限审计选项只有在当前会话结束并且新的会话被创建的时候才会起作用。相反，对方案对象的审计选项的改变会立即对当前的会话起作用。

SYS用户的操作以及通过SYS或者SYSOPER身份连接数据库的用户的操作能够使用AUDIT_SYS-OPERATIONS初始参数被完全地审计记录下来。来自SYS用户发起的成功的SQL语句不加选择的被审计记录下来。SYS用户或者使用管理权限连接的用户所建立的审计记录被发送存储到操作系统中。象上面的存储到操作系统中而不是存储在SYS方案中的数据库审计跟踪库中提供更好的审计安全性。