Oracle审计手册.docx
《Oracle审计手册.docx》由会员分享，可在线阅读，更多相关《Oracle审计手册.docx（91页珍藏版）》请在冰豆网上搜索。
Oracle审计手册
节标题页
介绍2
A特定现场的Oracle环境3
B密码管理6
COracle系统安全12
D操作系统安全18
E日常的批次作业22
F系统和对象审计24
G备份策略27
H数据库联网30
I完整性和性能32
1、介绍和概述
这个审计程序包含了一套在复审Oracle数据库环境时可以执行的审计测试。
这个审计程序可以独立使用，然而，它应该和Oracle审计软件OraAudit联合使用。
这些在OraAudit内生成的审计测试，或插件，一直以来都用对应的Oracle审计程序参考号来引用。
这个审计软件的使用指南可以在相关的帮助文件Oraaudit_Help_index.htm中找到。
这个程序内的审计测试，在能用到的地方，是作为审计程序的输出而被引用的。
在尽力维持审计程序的全面性和可行性的同时，审计师应该在执行每一个审计测试时，运用他们自己的判断力和创造性。
有了这一认识，，归档的审计测试就会得到持续的完善，也会获得审计程序和软件的定期修订。
Ref.No.
AuditTest
AuditFindings
TestOK?
Y/N
Completedby:
Initials
X-Ref:
WorkPapers
X-Ref:
OraAuditPlugins
A
A001
A002
A003
A004
A005
A006
A008
A009
A010
特定现场的Oracle环境
审计目标
通过复审和与DBA面谈，来理解现场的Oracle处理环境。
确定重要的数据库应用系统，数据仓库，管理信息系统，Web应用和其他使用数据库系统的关键业务系统。
提供主机系统和客户/服务器（C/S）处理环境的文档，例如：
a）以主机为中心的应用：
建立在单个数据库服务器上，用户通过操作系统（telnet）登录；
b）两层的C/S环境：
客户端的应用处理在PC上（胖客户端），用户通过客户端Oracle网络访问程序登录；
c）三层的C/S环境：
应用处理逻辑装载在应用服务器上，与数据库服务器和PC机（瘦客户端）相分离，用户通过应用程序——专门的网络访问程序登录。
记录使用的每一个数据库应用，实用工具，或管理程序。
确定Oracle服务器所安装的操作系统。
确定Oracle服务器所使用的版本和产品。
核查Oracle数据库的逻辑数据和处理模式是否记录进适当的手册中。
通过DBA执行SHOWPARAMETERS命令来获得Oracle目前的参数。
Oracle建议客户实施数据字典保护，以防止有‘ANY’系统权限的用户对数据字典使用这样的权限。
为了使数据字典保护有效，在init.ora（Oracle9i控制文件）中如下设置：
O7_DICTIONARY_ACCESSIBILITY=FALSE
注解：
这样做了以后，只有那些授权成DBA权限的用户（例如CONNECT/ASSYSDBA）的连接才可以对数据字典使用‘ANY’权限。
如果这个参数不象建议的这样设，一个拥有DROPANYTABLE（例如）的用户就有能力故意丢弃数据字典的一部分。
然而，如果用户需要对数据字典作视图访问，可以通过赋给它SELECTANYDICTIONARY权限来实现。
注意在Oracle9i，O7_DICTIONARY_ACCESSIBILITY=FASE是缺省的；而在Oracle8i，这个参数缺省设为TRUE，因而必须明确地将其改为FALSE以启用这一安全特性。
核查用于检查系统中所有软件具有有效许可证的流程是否到位。
特别是，LICENSE_MAX_SESSIONS或LICENSE_MAX_USERS应该设置成将连接到数据库的并发会话/用户限制在许可证协议所指定的限额之内。
注解：
值0表示没有启用内部控制，因此会允许无限制的会话/用户连接到数据库。
A005
A008
A009
A010
Ref.No.
AuditTest
AuditFindings
TestOK?
Y/N
Completedby:
Initials
X-Ref:
WorkPapers
X-Ref:
OraAuditPlugins
B
B001
B002
B003
B004
B005
B006
B007
B008
B009
B010
B011
B012
密码管理
审计目标
核查口令管理策略是否实施，以保证数据通过认证得到很好的保护。
核查在Oracle环境中与口令管理相关的标准是否已经建立，并已写入相应的手册中。
核查在Oracle中，对于用户帐号和组的建立和维护，是否有足够的授权程序。
从安全官员那里获得系统的视图DBA_USERS和DBA_PROFILES。
通过复审系统视图DBA_USERS和DBA_PROFILES，核查每一用户特性（profile）的参数，以确保他们按照安全标准设置：
a）IDLE_TIME——限定在一个会话自动退出前的持续非活动时间。
（建议的值:
15分钟）；
b）FAILED_LOGIN_ATTEMPTS——在用户帐号锁定前，允许登录到用户帐号的不成功尝试的次数。
（建议值：
3）；
c）PASSWORD_LIFE_TIME——同一密码可以用于认证的天数，在这之后密码必须改变。
（建议值：
30天）；
d）PASSWORD_REUSE_TIME——一个密码不能重新启用的间隔天数。
（建议值：
如果Password_reuse_max设置成12，则PASSWORD_REUSE_TIME设置为无限期，否则，PASSWORD_REUSE_TIME应设置为365而Password_reuse_max应该设为无限期，请见下面的注释）；
e）PASSWORD_REUSE_MAX——在一个密码重新启用前，密码改变的次数。
（建议值：
如果Password_reuse_time设置成365，则PASSWORD_REUSE_MAX设置为无限期，否则，PASSWORD_REUSE_MAX设置为12而Password_reuse_time应该设置为无限期，请见下面的注释；
f）PASSWORD_VERIFY_FUNCTION——PL/SQL口令复杂性验证脚本的名称；
g）PASSWORD_LOCK_TIME——在确定的不成功登录尝试后，用户帐号被锁住的天数。
（建议值：
无限期）；
h）PASSWORD_GRACE_TIME——宽限期的天数，在这段时间内，登录时会有警告信息但登录还可以继续。
（建议值：
5天）；
i）CPU_PER_SESSION——每个会话的CPU时间限制。
（建议值：
取决于应用的情况，但不应该设为无限制UNLIMITED）。
注解：
下面是应该注意的事项：
●任何没有被明确指定用户特性（profile）的用户将遵从DEFAULT特性（profile）定义的各项限制。
此外，如果明确指定给一个用户的用户特性（profile），忽略了对某些资源的限制，或者将某些限制指定为缺省，那么用户应遵从DEFAULT特性中对那些资源所定义的限制。
●更多的参数信息，请参考Oracle8ServerSQLReference。
●口令参数的限制（见Oracle文档）：
●如果PASSWORD_REUSE_TIME设置成一个整数值，PASSWORD_REUSE_MAX必须设置成无限制UNLIMITED。
如果PASSWORD_REUSE_MAX设置成整数值，PASSWORD_REUSE_TIME必须设置成无限制UNLIMITED。
●如果PASSWORD_REUSE_TIME和PASSWORD_REUSE_MAX都设置成无限制，则Oracle不会使用这些口令资源中的任何一个。
●如果PASSWORD_REUSE_MAX设置成DEFAULT，而PASSWORD_REUSE_TIME设置成无限制，则Oracle使用DEFAULT特性（profile）中定义的PASSWORD_REUSE_MAX的值。
●如果PASSWORD_REUSE_TIME设置成DEFAULT，而PASSWORD_REUSE_MAX设置成无限制，则Oracle使用DEFAULT特性（profile）中定义的PASSWORD_REUSE_TIME的值。
●如果PASSWORD_REUSE_TIME和PASSWORD_REUSE_MAX都设置成DEFAULT，则Oracle使用定义在DEFAULT特性（profile）中的任何一个值。
通过复审下列视图：
DBA_USERS和DBA_PROFILES，核查是否每个用户都已被指定了一个唯一的数据库特性（profile）。
从安全官员处取得一份PL/SQL密码复杂性验证脚本的拷贝（象上面在B004-f中确定的那样）。
确保通过脚本执行了如下核查：
a）口令长度至少是6个字符；
b）口令不能与相关的用户ID相同；
c）口令应由字符和数字组合而成；
d）无论密码如何改变，至少有3个字符与上次的口令不同。
确定安装的缺省密码是否已改变。
通过确认以下设置，来核查在客户端和服务器端都配置成在登录时对传输的密码进行加密：
a）在客户端机器，ORA_ENCRYPT_LOGIN环境变量设置成TRUE；
b）服务器初始化参数dblink_encrypt_login设置为TRUE。
检查确定只有sys和system帐号使用’system’表空间作为它们缺省的表空间，而对于其他用户，缺省表空间参数应设置为‘user’表空间。
注解：
其它用户使用SYSTEM之外的表空间，可以减少数据字典对象与用户对象使用同一个数据文件的冲突。
通常，不建议用户数据放在SYSTEM表空间上，以避免使SYSTEM表空间散乱的危险，和导致数据库面临潜在问题的风险。
要优先保持SYSTEM表空间干净，无碎片且使其免受伤害。
确保只有sys帐号把’system’作为临时表空间，所有其他用户应该将’temp’表空间作为他们的临时表空间。
注解：
如果用户的临时表空间没有明确设置，用户被指定使用在数据库创立时指定的缺省临时表空间，或在后来用ALTERDATABASE命令指定的临时表空间。
如果没有缺省的临时表空间，缺省的临时表空间就是SYSTEM。
就像之前所讨论的用户缺省表空间，不建议把用户数据存在SYSTEM 表空间。
另外，指定一个表空间为临时表空间也减少了临时段和其他类型段之间的文件冲突。
确保所有不成功的登录尝试都有记录，会进行复审和跟进。
基于安全原因，确认是否已禁用“SYS”和“SYSTEM”帐号。
注解：
这两个Oracle系统帐号各自用于系统维护和数据库管理。
按照Oracle安全手册，‘SYS’是整个数据库最有威力的用户，并拥有所有内部对象，而‘SYSTEM’则是执行大部分对象建立时的初始帐号。
一旦完成数据库初始建立，这些帐号建议不再使用。
B004
B005
B007
B009
B010
B011
B012
Ref.No.
AuditTest
AuditFindings
TestOK?
Y/N
Completedby:
Initials
X-Ref:
WorkPapers
X-Ref:
OraAuditPlugins
C
C001
C002
C003
C004
C005
C006
C007
C008
C009
C010
C011
C012
C013
C014
Oracle系统安全
审计目标
确保所有定义在Oracle数据库中的用户是适当的和合法的，其数据库权限与业务要求一致，并且遵循适当的口令控制。
确保数据有足够防护来自业务应用用户的直接访问。
提供文件来证明在应用设计中采取了防止对数据库对象获得直接访问的战略。
注解：
依赖所支持的应用的特性和所要求的安全级别，在Oracle中实施的安全策略可以有很大的不同。
应用和Oracle 安全系统之间的相互影响可以分为4种不同的模式：
●完全依靠Oracle安全系统——用这种方式的应用没有独立的安全系统，完全依靠数据库的安全控制。
用户在登录时提供的安全信息，用于在数据库中打开一个会话，或认证一个独立的动作。
这类应用通常用Oracle4GL（例如，OracleFinancial）开发；
●依靠Oracle安全系统用于用户认证——应用依靠一个并行的安全系统来控制用户的权限。
读写特定表的权限可以赋给所有应用的用户，而读或写数据的交易由应用安全系统进行限制。
在这种境况下，直接访问数据库是数据完整性很严重的问题，因为用户可以绕过应用安全控制去读或修改数据；
●依靠Oracle安全系统执行对数据库对象权限的授权——大部分Web应用采用这种方式获得保护，由于它在Oracle中设置和管理用户帐号是不现实的。
用户通过应用的并行安全系统进行认证，与数据库的交互是通过一个标准帐号来认证；
●独立于Oracle安全系统——这最后一个安全类别是复杂应用的一个特例，包含架构独立的应用，如SAPR/3。
从安全官员处取得下列系统视图：
a）DBA_USERS——列示数据库中建立的所有用户；
b）DBA_ROLES——列示数据库中建立的所有角色；
c）DBA_ROLE_PRIVS——列示赋给用户和其他角色的角色；
d）DBA_SYS_PRIVS——列示赋给用户和角色的系统权限；
e）DBA_TAB_PRIVS——列示赋给用户和角色的对象权限（不包含列特定权限）；
f）DBA_COL_PRIVS——列示赋给用户和角色的列特定权限。
从节C002获得的系统视图文档（也就是，DBA_USERS,DBA_SYS_PRIVS,DBA_ROLE_PRIVS），建立一个什么系统权限被赋给每个用户的表格，并评估每个系统权限赋予的适当性。
从节C002获得的系统视图文档（也就是，DBA_USERS，DBA_TAB_PRIVS,，DBA_COL_PRIVS,DBA_ROLE_PRIVS），建立一个什么对象权限被赋给每个用户的表格，并评估每个对象权限赋予的适当性。
通过相关手册指引并与安全官员讨论，确定每个角色和用户名的目的，特别是那些有很强权限的角色和用户名。
确定那些帐号的所有者，并查明这些权限的赋予是否适当。
在Oracle中，一个角色可以再赋予给别的角色。
这种灵活性也可能导致权限管理的困难。
与安全官员一起核查以查明实施了多少层角色的指定。
抽样检查用户帐号维护表格。
确定Oracle用户帐号维护的标准和流程。
业务用户不应该赋予除了直接SELECT表或视图之外的其他对象权限，因为这可能允许绕过要求的应用控制：
a）只有SELECT权限可以直接赋给用户和角色。
别的对象权限应该通过存储过程实现。
b）对于PROCEDURE对象，应该只有SELECT和EXECUTE权限赋给一般用户。
注解：
下面是要注意的一些事项：
●一个过程是一个模式对象，由一组SQL语句和PL/SQL结构组成，存储在数据库中，作为一个单位执行，以解决一个特定的问题或执行一组相关的任务；
●存储过程能有助于加强数据安全。
你可以通过只允许用户通过过程来访问数据来限制用户可以执行的数据库操作。
例如，你可以赋权给一个用户可以访问一个修改表的过程，但不赋权给它访问表本身。
当一个用户调用过程时，这个过程用过程所有者的权限执行。
只有执行过程的权限的用户（但没有权力去查询，修改，或删除表）能执行过程，但他们不能用任何别的方式来操作表的数据。
具有破坏性权限的角色（如在用户模式对象上删除，修改等）在建立时应该有密码以便认证。
核查DBA_ROLES以便查明是否为那些特殊角色设置密码，并保证那些角色没有被定义为缺省角色。
注解：
下面是要注意的一些事项：
●当一个用户首次建立时，用户缺省的角色设置是ALL，这样所有后续赋给用户的角色就会是缺省角色；
●如果一个角色定义为用户的缺省角色，即使角色本身有密码相关，在使用这个角色时也不会要求提供密码。
从在节C002取得的系统视图文档（也就是，DBA_SYS_PRIVS和DBA_ROLE_PRIVS），核查所有被授予系统权限或角色的被授予者，没有将ADM设置为YES。
注解：
为了赋权一个角色或系统权限，授权者应该分别拥有GRANTANYROLE或GRANTANYPRIVILEGE的系统权限，或被授予的角色或系统权限的ADMIN选项。
从在节C002取得的系统视图文档（也就是，DBA_TAB_PRIVS和DBA_COL_PRIVS），核查只有负责权限管理的安全官员，将对象权限‘GRANTABLE’设置为YES。
注解：
为了赋权一个对象权限，授权者应该要么是对象所有者，要么是被授予了将GRANTABLE设置为YES的对象权限。
从在节C002取得的系统视图文档（也就是，DBA_ROLE_PRIVS，DBA_SYS_PRIVS，DBA_TAB_PRIVS和DBA_COL_PRIVS），确定那些已经赋给PUBLIC的角色和权限。
复审这些赋权是否恰当。
注解：
通常而言，只有某几个表或视图的SELECT权限可以被赋权给PUBLIC。
从DBA取得系统视图DBA_TS_QUOTAS，与DBA讨论赋给每一个用户的表空间资源是否适当。
注解：
验证引入配额是非常重要的，其实际值取决于本地环境。
适当的配额可以节省分配给每一个表空间和个别用户请求的物理空间的总的大小。
核查OracleListener建立了密码以防止XX的远程配置。
另外，以下列方式核查listener.ora（OracleListener控制文件）的安全配置参数：
ADMIN_RESTRICTIONS_listener_name=ON
注解：
这样当listener在线时，会防止对OracleListenerXX的管理。
C002
C003
C004
C005
C013
C014
Ref.No.
AuditTest
AuditFindings
TestOK?
Y/N
Completedby:
Initials
X-Ref:
WorkPapers
X-Ref:
OraAuditPlugins
D
D001
D002
D003
D004
D005
D006
操作系统安全
审计目标
确定通过主机操作系统的数据库访问路径是安全的。
使用DBA_USERS系统视图（在节C002获得），确定所有的前缀是OPS$（操作系统传递给Oracle）的ID，检查主机操作系统的登录安全性，以确保所有ID代表合法和现有的用户。
前后对照ini.ora文件中和DBA_USERS系统视图中的OS_AUTHENT_PREFIX参数，以便确定和复审远程认证用户的清单。
注解：
OS_AUTHENT_PREFIX指定了一个Oracle用户登录服务器认证时的前缀。
Oracle将这个参数值放在操作系统的帐号和密码之前。
当收到一个连接请求，Oracle就将带前缀的用户名和数据库中的Oracle用户名作比较。
这个参数的缺省值是OPS$，以便与以前的版本兼容。
然而，更可取的是将前缀设置为“”（一个空串），这样可以免去在操作系统用户前加任何前缀。
如果你允许带OPS$的帐号从Windows工作站登录，你很难确定他们实际上是谁。
对于终端，你可以依靠操作系统的密码，而对于Windows，你却不能这样做。
如果在init.ora文件中REMOTE_OS_AUTHENT设置为TRUE，Oracle假定远程的操作系统已认证了这个用户。
如果REMOTE_OS_AUTHENT设置为FALSE，远程用户没有密码就无法登录。
IDENTIFIEDEXTERNALLY（让操作系统认证密码）只对本地主机有效。
同样，如果你使用”OPS$”作为你的前缀，你将可以用或不用密码登录本地，而不论你是否为你的ID指定密码或定义它为IDENTIFIEDEXTERNALLY。
通过确定remote_os_authent参数已设置为FALSE，来确保远程认证的网络用户不能够连接到数据库。
注解：
远程认证是由Oracle提供的一个安全功能，如果它设为TRUE，它把用户认证委托给连接到Oracle数据库的远程客户端来完成。
这样，数据库隐含相信任何成功认证自己的客户端。
注意到客户端，一般而言，如PC机，通常不能很好地执行操作系统认证，因此，将远程认证打开是一个非常糟糕的配置。
在一个更安全的配置中，这个功能是关闭的（FALSE），它强制客户端在进行数据库连接时使用正确的，基于服务器的认证。
为限制远程认证并将对客户端的信任委托给数据库，init.ora（Oracle控制文件）数据库配置参数应该按如下方式设置：
REMOTE_OS_AUTHENT=FALSE
审计UNIX或NT的Oracle文件系统的安全性，以确保用户受限访问Oracle程序，配置文件，日志和表空间：
a）确保所有目录和文件的属主是OracleDBA帐号；
b）确保UNIX/NT的组属主是组DBA/ORA_DBA；
c）确保UNIX目录的许可是755或更小，NT目录的许可设置如下：
●属主为全部控制；
●同组和所有人为只读（RX）。
d）确保可执行Oracle二进制文件的UNIX文件的许可是750，NT文件许可设置如下：
●属主，完全控制；
●同组，只读（RX）；
●所有人，无法访问。
e）确保UNIXumask参数已设置，这样日志文件不是所有人都能读和写的；
f）确保NT文件许可设置成文件继承其所在目录的许可；
g）审计Oracle数据库属主ID和组（Unix）的安全性，以确保只有授权的系统管理人员和进程能使用；
h）确保只有数据库管理员才能使用Oracle正在运行的这个帐号。
复审Unix/etc/group文件（或对应的NT组），以确保组DBA的成员限制在Oracle帐号，以防止XX的数据库内部连接。
复审SQL*DBA和服务器管理器程序（ServerManager,SVRMGR）的文件许可，以确保只有Oracle管理帐号可以使用它们。
下面的应用是Oracle标准的数据库配置和管理的工具：
●DBAStudio;
●DatabaseConfigurationAssistant;
●OracleDataMigrationAssistant;
●Net8Assistant;
●Net8ConfigurationAssistant。
另外，访问ODBC和OracleSQL客户端（也就是，SQLPlus或SQLPlus工作表），在单独授
升级会员 