授予数据库账号dba权限_oracle数据库限制dba权限

2011年10月10日星期一

最小化原则，宁少勿滥，尤其对any系统权限，需要谨慎控制

主要角色及dba权限说明，详见压缩包中excel文件：

数据库系统管理员，sys用户默认具有sysdba权限，详细权限列表，可以参看压缩包中excel文件：

可以进行如下管理活动：

启动和关闭数据库

挂载、打开、备份数据库，并且修改字符集

创建数据库

删除数据库

创建服务器参数文件

更改数据库归档模式

执行数据库恢复操作，包括完全恢复和不完全恢复

启用限制会话模式

通常通过操作系统认证，是权限最高的oracle数据库用户，可以认为，sysdba用户，可以对数据库做任任何事情。

数据库管理员，system用户默认具有dba权限，详细权限列表及说明，可以参看压缩包中excel文件：

dba用户可以进行日常的大多数数据库维护操作，可创建、修改、删除任何大多数数据库对象，可创建用户，可修改用户，可修改数据库、数据库系统配置，可审计 、调优数据库，可建立自制任务，可影响会话，可备份任何表等等，权限等级仅次于sysdba。

在创建某个用户，并且该用户创建了一些数据库对象(当然，前提是具有相应的create或者create any 的权限)，oracle会默认创建并维护一个schema，并且，该用户具有对所创建用户的all权限。

通常，某个用户作为数据库主要的开发用户，赋予该用户connect + resource角色权限即可，connect角色中包含create session系统权限，resource角色权限，详细参见

如果该用户需要创建物化视图，则需要另外赋予系统权限：

CREATE MATERIALIZED VIEW

在创建普通用户后，应首先赋予create session系统权限，或者connect角色权限，并限定使用的默认表空间及表空间配额。普通用户默认具有public角色权限，public角色权限详细参见：

普通用户的权限需要做到细粒度控制：需要的时候给，不需要的时候立即取消权限。对表的访问，可建立合理视图，再赋予普通用户视图的select权限。对于procedure，切忌赋予execute any procedure权限！！！对于表的更改、插入操作，需要普通用户操作的，可以建立procedure，并赋予该普通用户execute权限。注意在procedure做好审计记录。

在很多时候，为了企业的数据安全，需要dba只进行一些管理操作，而不能访问业务数据。限制dba是很困难的，限制过严，则dba很多工作不能做，最终转化为sysdba的负担。

dba对业务数据访问的权限，可以是以下几种：

dba本身具有SELECT ANY TABLE的系统权限，可以访问业务数据；

dba本身具有GRANT ANY PRIVILEGE的权限，可以给自己赋予SELECT ANY TABLE的权限，从而访问业务数据；

dba本身具有GRANT ANY OBJECT PRIVILEGE的权限，可以给自己赋予对相应业务数据表的访问权限，以实现访问目的；

dba本身具有DATAPUMP_IMP_FULL_DATABASE、OLAP_DBA等角色权限，这些角色权限中具有select any table的系统权限，或者GRANT ANY PRIVILEGE、GRANT ANY OBJECT PRIVILEGE的权限，也可以通过相应的赋权，获得对业务数据的访问。

dba本身具有EXECUTE ANY PROCEDURE的权限，可以通过一些系统包的存储过程，实现给自己赋权，从而访问业务数据。

dba具有ALTER USER的权限，可以通过修改相应schema用户的密码，用shemale user连接数据库，访问业务数据。

要限制dba对业务数据的访问，就要将这些方面杜绝。为此，可以创建新的dba角色，将敏感的、不需要的权限，从dba角色中剔除，再建立新的dba账户时，赋予新的dba角色，以起到限制dba的目的。

注意：不要试图直接修改dba角色的权限，这个操作很危险！！！

在压缩包中，scripts文件夹中，包含了限制dba需要的sql脚本，包括获得dba角色权限的脚本，应该赋予自定义dba角色权限的脚本，供参考。

具有GRANT权限的角色：

具有SELECT ANY TABLE权限的角色：

具有EXECUTE ANY PROCEDURE权限的角色：

需要创建awr报告的，只需对包dbms_workload_repository的execute权限。