ID #51063

Oracle数据库11g新特性:安全性

  默认口令

  2006 年,OTN 发布了我撰写的一系列题为“安全保护项目:一种分阶段的数据库基础架构保护方法”的文章。在这些文章中,我讨论了如何应对常见的安全挑战(如用户使用默认口令)以及如何扫描您的数据库以查找这些用户。

  对我而言很不幸的是,您可能已经忘记了我文章中的那一部分。Oracle 数据库 11g 现在提供一种快速识别使用默认口令的用户的方法。该方法实施起来极为简单,只需检查单个数据字典视图:DBA_USERS_WITH_DEFPWD.(注意,DBA_ 是一个标准前缀,它不仅包含使用默认口令的 DBA 用户。)您可以执行以下命令来识别这些用户:

select *
from dba_users_with_defpwd

  输出如下:

USERNAME
------------------------------
DIP
MDSYS
WK_TEST
CTXSYS
OLAPSYS
OUTLN
EXFSYS
SCOTT
MDDATA
ORDPLUGINS
ORDSYS
XDB
LBACSYS
SI_INFORMTN_SCHEMA
WMSYS

  由于 SCOTT 使用了默认口令 TIGER,因此您会看到他出现在上面的清单中。使用下面的语句进行更改:

SQL> alter user scott identified by tiger1;
User altered.

  现在,如果您查看该视图:

SQL> select * from dba_users_with_defpwd;

  您就不会在该清单中看到 SCOTT 了。就这么简单!

  区分大小写的口令

  在版本 11g 之前的 Oracle 数据库中,用户口令是不区分大小写的。例如:

SQL> conn scott/tiger
Connected.
SQL> conn scott/TIGER
Connected.

  这种安排为支付卡行业 (PCI) 数据安全标准之类的标准带来了问题,这些标准要求口令区分大小写。

  该问题得到了解决,在 Oracle 数据库 11g 中,口令也可以区分大小写。通过 DBCA 创建数据库时,系统会提示您是否希望升级到“新的安全标准”,其中之一就是区分大小写的口令。如果您接受该标准,口令在创建时的大小写状态将被记录下来。假如您接受了新标准,相应的操作结果如下:

  SQL> conn scott/tiger
Connected.
SQL> conn scott/TIGER
ERROR:
ORA-01017:invalid username/password; logon denied
  Warning:You are no longer connected to ORACLE.

  注意对“tiger”和“TIGER”的不同处理方式。

  现在,您的某些应用程序可能无法立刻传递大小写正确的口令。典型示例是用户输入表单:很多表单在接受口令时不会进行大小写转换。然而,在 Oracle 数据库 11g中,这种登录方式可能会失败,除非用户以区分大小写格式输入口令,或者开发人员对应用程序进行了修改,使其能够进行大小写转换(这一点不可能迅速实现)。

  不过,如果您希望的话,仍然可以通过更改系统参数 SEC_CASE_SENSITIVE_LOGON 恢复到不区分大小写的状态,如以下示例所示。

SQL> conn / as sysdba
Connected.
SQL> alter system set sec_case_sensitive_logon = false;
System altered.
SQL> conn scott/TIGER
Connected.

  在将现有 Oracle 数据库 10g 升级到 11g 时,可将口令移植到新标准。可以通过查询 DBA_USERS 视图来检查口令状态,尤其是新的 PASSWORD_VERSIONS 列。

  select username, password, password_versions
from dba_users;
  USERNAME         PASSWORD            PASSWORD
------------------------- ------------------------------ ------------------------
SYSTEM                                   10G 11G
SYS                                       10G 11G
MGMT_VIEW                              10G 11G

  您首先会注意到 PASSWORD 列为空,没有像 Oracle 数据库 10g 和以前的版本中那样使用散列值填充。那么,口令出什么问题了?口令仍然存储在数据库中(在表 USER$ 中),但它在 DBA_USERS 视图中不可见。当用户被创建为全局或外部认证时,其状态指示为 GLOBAL 或 EXTERNAL,但不显示口令的散列值。

  接下来,注意 PASSWORD_VERSIONS 列,它是 Oracle 数据库 11g 中新增的。该列表明口令是否区分大小写。值“10G 11G”的意思是,用户要么是在 10g 中创建然后移植到 11g 中的,要么是直接在 11g 中创建的。

  如果您希望的话,在创建口令文件时,您也可以输入一个新参数 ignorecase 来实现 SYSDBA 口令的大小写区分,如下所示:

$ orapwd file=orapwPRODB3 password=abc123 entries=10 ignorecase=n

  在以上示例中,SYSDBA 的口令将为 abc123,而不是 ABC123 或任何其他大小写变体。

  通过采用区分大小写的口令,不仅使得强行破解口令更为困难,同时能够使您满足更多合规性要求。更为重要的是,您可以动态地执行口令要求而不必关闭数据库。在进行升级或因升级原有应用程序而对登录问题进行调试时,这是非常有用的。

  概要文件和口令验证功能

  还记得 Oracle 数据库中的口令验证功能吗?很多人甚至可能都不知道它的存在,更不要说使用它了。该功能是快速、轻松地确保数据库口令的质量 — 例如,口令应当包含一定数目的字符,不应当与用户名相同,等等。也许它的最佳特色在于它是内置的,您只需要启用它即可。但很可能的是,您并没有启用该功能。

  在 Oracle 数据库 11g 中,口令管理功能具有新的经过改进的验证逻辑。如果您查看 $ORACLE_HOME/rdbms/admin 下的口令验证文件 utlpwdmg.sql,您会发现脚本新建了一个名为 verify_fnction_11g 的口令函数。脚本末尾的语句如下所示:

  ALTER PROFILE DEFAULT LIMIT
PASSWORD_LIFE_TIME 180
PASSWORD_GRACE_TIME 7
PASSWORD_REUSE_TIME UNLIMITED
PASSWORD_REUSE_MAX UNLIMITED
FAILED_LOGIN_ATTEMPTS 10
PASSWORD_LOCK_TIME 1
PASSWORD_VERIFY_FUNCTION verify_function_11G;

  脚本将该函数附加到概要文件 DEFAULT 中。除非明确分配了其他文件,该文件是所有用户的默认概要文件。这使得认证符合许多规定的要求。您要做的只是运行该脚本以创建 11 g 版的口令检查函数,该脚本将通过将自身附加到默认概要文件中来启用口令验证功能。

  改进的即需即用的审计

  审计是另一个常见难题。Oracle 数据库包括强大的审计功能,可用于跟踪用户活动。大多数人由于担心 I/O 争用问题,并不利用审计功能。但事实上,一些审计可以被安全打开而风险却很小。

  相关的示例包括 CREATE SESSION,它在会话开始时编写一条记录,然后在会话结束时更新该记录。该审计对 I/O 的影响极小,但带来了众多好处。

  在 Oracle 数据库 11g 中,进行了两个简单的改动以提供更强大的审计解决方案。首先,数据库参数 audit_trail 现在默认情况下设置为 DB,在以前的版本中,它的默认值为 NONE.这允许您对任何对象、语句或权限打开审计,而无需重复使用数据库。

  第二处改动是,默认情况下更多语句处于审计范围内。清单如下:

ALTER SYSTEM
SYSTEM AUDIT
CREATE SESSION
CREATE USER
ALTER USER
DROP USER
ROLE
CREATE ANY TABLE
ALTER ANY TABLE
DROP ANY TABLE
CREATE PUBLIC DATABASE LINK
GRANT ANY ROLE
ALTER DATABASE
CREATE ANY PROCEDURE
ALTER ANY PROCEDURE
DROP ANY PROCEDURE
ALTER PROFILE
DROP PROFILE
GRANT ANY PRIVILEGE
CREATE ANY LIBRARY
EXEMPT Access POLICY
GRANT ANY OBJECT PRIVILEGE
CREATE ANY JOB
CREATE EXTERNAL JOB

  如您所见,审计这些活动不会导致严重的 I/O 问题,因此,可将审计活动维持在可接受水平,同时对性能的影响最小。

  这两处改动带来了一些强大的即需即用的审计功能。当然,它们只是一些数据库参数和审计设置;如果需要的话,您可以轻松地关闭它们。但如果您看看这些语句清单,您实际上会发现即使在开发数据库中,它们也是值得审计的。不过,您可能想对它们进行细微的调整。(例如,在数据仓库中,用户创建并删除大量临时表,因此审计 CREATE/DROP TABLE 可能会在审计线索中泛滥。)

  (警告: 当您升级到 Oracle 数据库 11g 时,默认情况下上述语句的审计将打开。因此,审计线索将写入到 SYSTEM 表空间中的表 AUD$ 中,这些审计线索将迅速填充。密切关注该表空间。

  透明表空间加密

  由于各种新的法律法规,人们现在对加密的重视程度越来越高。您需要以某种方式对数据进行加密,但最大的问题在于如何加密?

  对于仍然使用 Oracle 数据库 10g 第 1 版和以前版本的人来说,DBMS_CRYPTO 和 DBMS_OBFUSCATION_TOOLKIT 工具包允许您构建自己的加密框架。在 Oracle 数据库 10g 第 2 版中,该框架通过透明数据加密特性得以增强。

  透明数据加密使您可以对特定列进行加密,这足以满足大多数要求。然而,性能仍然是该特性的一个问题(或者说,任何其他加密解决方案都存在着性能问题):索引范围扫描不能应用于加密列,这会对性能造成严重的负面影响。

  这正是 Oracle 数据库 11g 中透明表空间加密的真正出色之处。当表空间声明已加密时,表空间(包括透明表空间、备份等)上的任何数据都已加密,而不仅仅是单独声明为已加密的表。但在进行索引扫描时,扫描发生在未对数据进行加密的内存中,因而不会对性能造成影响。

  感觉激动吗?让我们看一下它的工作原理。加密过程与透明数据加密过程相同:您需要创建一个钱夹以存储主加密密钥。如果您还没有设置透明数据加密,则需要创建钱夹和密钥。

  首先,创建钱夹的文件位置;默认位置为 $ORACLE_BASE/admin//wallet.默认情况下钱夹子目录并不存在,您需要进行创建。因此,在我的示例中,该目录为 /home/oracle/app/admin/PRODB3/wallet.

  接下来,执行下面的语句以在钱夹中创建加密密钥:

alter system set encryption key identified by "abcd1234!";

  该语句同时创建钱夹和密钥。如果您现在检查该目录,您会看到刚刚创建的钱夹文件 (ewallet.p12)。

$ cd /home/Oracle/app/admin/PRODB3/wallet
$ ls
ewallet.p12

  钱夹要使用口令才能打开,在本例中,口令为 abcd1234!。该语句也可以打开钱夹。以后,您无需再创建钱夹了。数据库启动后,您只需通过执行以下语句来打开钱夹:

  alter system set wallet open identified by "abcd1234!"

  现在创建表空间:

  create tablespace secure1
datafile '/home/oracle/oradata/PRODB3/secure1_01.dbf'
size 1M
encryption using 'AES128'
default storage (encrypt)
/

  子句“encryption using …… default storage (encrypt)”将表空间标记为经过加密的。(注:我们对此表空间使用了 AES 128 位加密算法。其他选择包括 Triple DES 168 位密钥算法、AES 192 位密钥算法和 AES 256 位密钥算法。)

  既然已经创建了表空间,您就可以像在常规表空间中那样创建表了。

  create table secure_trans
tablespace secure1
as
select * from trans
where rownum < 201
/
  create table secure_res
tablespace secure1
as
select * from res
where rownum < 201
/

  上述语句在加密的表空间 SECURE1 中创建了表。为进行比较,以正常方式(不加密)创建另一个名为 INSECURE1 的表空间,并在其中创建表 INSECURE_TRANS 和 INSECURE_RES.INSECURE_TRANS 和 SECURE_TRANS 在结构和数据方面相同,但位于不同的表空间中。SECURE_RES 和 INSECURE_RES 也是如此。

  现在更新这些表中的一个文本字段,以便在数据文件中搜索该字段:

update secure_trans set comments = 'Transaction Comments';
update insecure_trans set comments = 'Transaction Comments';
commit;

  通过使表空间先脱机再联机,将内容强制写到磁盘上:

alter tablespace secure1 offline;
alter tablespace secure1 online;
alter tablespace insecure1 offline;
alter tablespace insecure1 online;

  此时,缓存中的数据已经写到磁盘上。搜索该字段,看会发生什么?

$ strings insecure1_01.dbf | grep Transaction
Transaction Comments
...

  该字符串以明文形式出现在数据文件中。现在,对经过加密的 SECURE1 表空间执行同样的操作。

$ strings secure1_01.dbf | grep Transaction
$

  该操作不会返回任何结果,因为数据文件是加密的,您不会以明文形式看到各列的值。一切都完美无缺,但性能怎么样呢?我们运行以下查询来体验一下。

select hotel_id, sum(amt)
from secure_trans t, secure_res r
where t.res_id = r.res_id
group by hotel_id

  运行该查询时,我们也会对其进行跟踪。下面是跟踪文件的节选。

call   count    CPU  elapsed    disk   query  current    rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse    1   0.00    0.00     0     0     0      0
Execute   1   0.00    0.00     0     0     0      0
Fetch    14   0.01    0.01     4     6     0     186
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total    16   0.01    0.01     4     6     0     186
Rows   Row Source Operation
------- ---------------------------------------------------
186 HASH GROUP BY (cr=6 pr=4 pw=4 time=5 us cost=8 size=10400 card=200)
200  HASH JOIN (cr=6 pr=4 pw=4 time=45 us cost=7 size=10400 card=200)
200  TABLE Access FULL SECURE_TRANS (cr=3 pr=2 pw=2 time=8 us cost=3 size=5200 card=200)
200  TABLE ACCESS FULL SECURE_RES (cr=3 pr=2 pw=2 time=9 us cost=3 size=5200 card=200)

  现在,对 INSECURE_RES 和 INSECURE_TEST 运行相同的测试,它们处于正常的(未加密的)表空间内。

call   count    CPU  elapsed    disk   query  current    rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse    1   0.00    0.00     0     0     0      0
Execute   1   0.00    0.00     0     0     0      0
Fetch    14   0.00    0.01     4     6     0     186
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total    16   0.01    0.01     4     6     0     186
Rows   Row Source Operation
------- ---------------------------------------------------
186 HASH GROUP BY (cr=6 pr=4 pw=4 time=4 us cost=8 size=10400 card=200)
200  HASH JOIN (cr=6 pr=4 pw=4 time=46 us cost=7 size=10400 card=200)
200  TABLE Access FULL INSECURE_TRANS (cr=3 pr=2 pw=2 time=8 us cost=3 size=5200 card=200)
200  TABLE ACCESS FULL INSECURE_RES (cr=3 pr=2 pw=2 time=9 us cost=3 size=5200 card=200)

  注意各例中的执行时间,它们都是相似的。因解密而导致的 CPU 消耗也并不显著。因此,表空间加密不会对性能产生影响。

  DBA_TABLESPACES 视图有一个新列 ENCRYPTED,该列用于显示某个表空间是否已加密。此外,一个名为 V$ ENCRYPTED_TABLESPACES 的新视图用于显示针对该表空间启用的加密类型。

貧匯匈 1 2 3 4 5 6 7 8 9 10 和匯匈

  SQL> desc v$encrypted_tablespaces
Name                   Null?Type
----------------------------------------- -------- ------------
TS#                        NUMBER
ENCRYPTIONALG                   VARCHAR2(7)
ENCRYPTEDTS                    VARCHAR2(3)
  SQL> select * from v$encrypted_tablespaces;
  TS# ENCRYPT ENC
---------- ------- ---
5 AES128 YES

  乎篇夕辛參才 V$TABLESPACE 篇夕議 TS# 双潤栽・參資誼頼屁議佚連。和中頁乎篇夕議翌鉱・

SQL> desc v$tablespace
Name                                     Null?Type
----------------------------------------- -------- ---------------------------------------------
TS#                                            NUMBER
NAME                                         VARCHAR2(30)
INCLUDED_IN_DATABASE_BACKUP            VARCHAR2(3)
BIGFILE                                       VARCHAR2(3)
FLASHBACK_ON                               VARCHAR2(3)
ENCRYPT_IN_BACKUP                         VARCHAR2(3)

  廣吭・ENCRYPT_IN_BACKUP 双才邑苧燕腎寂紗畜短嗤販採購狼。・郡・万頁姥芸豚寂燕腎寂議 RMAN 紗畜・頁壓 Oracle 方象垂 10g 及 2 井嶄哈秘議。

貧匯鐙・ Oracle方象垂11g仟蒙來・SQL Performance Analyzer
和匯鐙・ Oracle方象垂11g仟蒙來・徭癖哘嗄炎嚥SQL柴皿砿尖

貧匯匈 1 2 3 4 5 6 7 8 9 10 和匯匈

  如您所见,透明表空间加密以一种相当完美的方式解决了两个问题:它对磁盘上处于静止状态的数据进行加密,由于数据管理发生在 SGA 内,因此不会影响性能。

  Data Pump 转储文件的加密

  Oracle 数据库 10g 引入了用于数据移动的最强大的特性之一:Data Pump,它用于代替原来的导出/导入工具。除了速度更快之外,Data Pump 还具有很多优点,如并行化进程和重新映射表空间。在 Oracle 数据库 11g 中,它还通过一个新参数 ENCRYPTION 来帮助保护转储文件的安全。

  转储文件位于数据库和数据库安全领域之外,并且包含潜在的敏感数据。在如今的安全意识环境中,它们构成了一组独特的问题。在一些真正具有安全意识的环境中,DBA 在导出数据后通过第三方实用程序对转储文件进行加密 — 如果导出工作量巨大,这不是一个非常方便的方法。

  首先,我们了解一下典型转储文件的易受攻击程度。假设您有一个名为 TRANS 的表,它包含一个名为 COMMENTS 的列。该列中的值为“Transaction Comments”。如果您以正常方式导出该表:

$ expdp scott/tiger tables=trans dumpfile=insec.dmp directory=tmp_dir

  检查转储文件以查看该列值是否存在:

$ strings /tmp/insec.dmp | grep Transaction

  将出现大量匹配项。转储文件中的数据未加密,处于明文状态。

  现在,使用新参数 ENCRYPTION 执行导出。您还必须指定要使用的算法类型。我们将使用 AES 128 位算法。

$ expdp scott/tiger tables=trans dumpfile=sec.dmp directory=
tmp_dir encryption=data_only encryption_algorithm=aes128
Export:Release 11.1.0.5.0 - Beta on Sunday, 22 July, 2007 18:17:30
Copyright (c) 2003, 2007, Oracle.All rights reserved.
Connected to:Oracle Database 11g EntERPrise Edition Release 11.1.0.5.0 - Beta
With the Partitioning, Oracle Label Security, OLAP, Data Mining
and Real Application Testing options
Starting "SYS"."SYS_EXPORT_TABLE_01":
  '/******** AS SYSDBA' tables=scott.insecure_trans dumpfile=
  sec.dmp directory=tmp_dir encryption=data_only encryption_algorithm=aes128
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method:64 KB
Processing object type TABLE_EXPORT/TABLE/TABLE
. . exported "SCOTT"."TRANS"               16.82 KB   200 rows
Master table "SYS"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SYS.SYS_EXPORT_TABLE_01 is:
/tmp/sec.dmp
Job "SYS"."SYS_EXPORT_TABLE_01" successfully completed at 18:17:44


2008-12-16 00:00
阅读:
I'm VC , Just U know Y
本站部分文章来源于互联网,版权归原作者所有。

延伸阅读:

Oracle 11g R2新特性概述

ORACLE 10g 中恢复已删除的表_flashback

ORACLE 中ROWNUM用法总结

Oracle 10g 统计信息自动收集功能(automatic statistics gathering)学习总结

oracle文档第九章触发器(1)