ORACLE: Seguridad

La informacin dicen que es poder, y como las BD son un almacn de informacin tambin
almacenan poder, por lo que han sido objeto de intentos de acceso no autorizados desde su
nacimiento. Por eso, las BD se han dotado de unos mecanismos que hacen posible la
gestin de la seguridad en el acceso a la informacin que almacenan.
Mayo de 1998.
Jess Vegas
Dpto. Informtica
Universidad de Valladolid
jvegas@infor.uva.es

ndice
1 Posibilidades
1.1 Seguridad de Cuentas
1.2 Seguridad de Objetos
1.3 Roles del Sistema
2 Implementacin de Seguridad
2.1 Creacin de Usuarios
2.2 Eliminacin de Usuarios
2.3 Privilegios del Sistema
2.4 Perfiles de Usuario
2.5 Cuentas BD sobre Cuentas SO
2.6 Protegidos por passwords
2.7 Gestionando Privilegios
2.8 Listar Privilegios Otorgados
3 Encriptacin de passwords y Trucos
3.1 Almacenamiento de Passwords
3.2 Passwords Imposibles
3.3 Convertirse en otro Usuario
4 Auditora de Seguridad
4.1 Auditando Conexiones
4.2 Auditando Acciones
4.3 Auditando Objetos
4.4 Protegiendo los Registros de Auditora

1 Posibilidades
Oracle pone al alcance del DBA varios niveles de seguridad:

Seguridad de cuentas para la validacin de usuarios.

Seguridad en el acceso a los objetos de la base de datos.

Seguridad a nivel de sistema para la gestin de privilegios globales.

1.1 Seguridad de Cuentas

Para acceder a los datos en una BD Oracle, se debe tener acceso a una cuenta en esa BD.
Cada cuenta debe tener una palabra clave o password asociada. Una cuenta en una BD
puede estr ligada con una cuenta de sistema operativo. Los passwords son fijados cuando
se crea un usuario y pueden ser alterados por el DBA o por el usuario mismo. La BD
almacena una versin encriptada del password en una tabla del diccionario llamada
dba_users. Si la cuenta en la BD est asociada a una cuenta del sistema operativo puede
evitarse la comprobacin del password, dndose por vlida la comprobacin de la identidad
del usuario realizada por el SO.

1.2 Seguridad de Objetos

El acceso a los objetos de la BD se realiza via privilegios. Estos permiten que determinados
comandos sean utilizados contra determinados objetos de la BD. Esto se especifica con el
comando GRANT, conceder. Los privilegios se pueden agrupar formando lo que se conoce
por roles. La utilizacin de los roles simplifica la administracin de los privilegios cuando
tenemos muchos usuarios. Los roles pueden ser protegidos con passwords, y pueden
activarse y desactivarse dinmicamente, con lo que constituyen una capa ms de seguridad
en el sistema.

1.3 Roles del Sistema

Los roles se pueden utilizar para gestionar los comandos de sistema disponibles para los
usuarios. Estos incluyen comandos como CREATE TABLE o SELECT ANY TABLE. Todos los
usuarios que quieran acceder a la BD deben tener el rol CONNECT; aquellos que necesiten
crear segmentos necesitaran el rol RESOURCE. Un usuario con el rol DBA tiene derecho para
ver y manejar todos los datos de la BD. En Oracle CONNECT, RESOURCE y DBA son roles de
sistema. Las acciones contra cada tipo de objeto son autorizadas por privilegios separados.

As, un usuario puede tener concedido el privilegio CREATE TABLE, pero no el ALTER
TABLE.

2 Implementacin de Seguridad
No se podr acceder a la BD a menos que se acceda primero al servidor en el que la BD
est ejecutndose. El primer paso en la seguridad de la BD es asegurar la plataforma en la
que reside. Una vez que esto ha sido conseguido, se debe considerar la seguridad del
sistema operativo. Oracle utiliza una serie de ficheros a los que los usuario no tienen porque
acceder de manera directa. Por ejemplo, los ficheros de datos o los de redo log son escritos
y leidos slo por los procesos Oracle. As, slo los DBAs que han creado estos ficheros
necesitan acceder directamente a ellos a nivel del sistema operativo.

2.1 Creacin de Usuarios

El objetivo de la creacin de usuarios es establecer una cuenta segura y til, que tenga los
privilegios adecuados y los valores por defecto apropiados. En Oracle se puede especificar
todo lo necesario para abrir una cuenta con el comando CREATE USER. Los parmetros que
se le pueden pasar son:
Parmetro

Significado

Username

Nombre del Usuario (Esquema)

Password

Palabra clave de la cuenta. Puede ser asociada directamente a

una cuenta del sistema operativo.

Default
Tablespace

Espacio de tablas por defecto en el que los objetos de este

usuario sern creados. Esto no da al usuario derechos de crear
objetos.

Temporary
Tablespace

El espacio de tablas en el que se almacenarn los segmentos

temporales de las ordenaciones.

Quota

Espacio mximo que puede ocupar en un espacio de tablas.

Profile

Asigna un perfil al usuario. Los perfiles se utilizan para

restringir el uso de recursos como el tiempo de CPU.

A continuacin se puede ver un ejemplo de uso del comando CREATE USER en el que se
crea una cuenta para el usuario Prez:

SVRMGR> create user perez

2> identified by zerep

3> default tablespace users

4> temporary tablespace temp;

Si no se especifica un perfil, se aplica el perfil por defecto de la BD, que se llama DEFAULT
y tiene asignados todos los lmites a UNLIMITED.
Si no se especifca una cuota el usuario no puede crear objetos.

2.2 Eliminacin de Usuarios

Los usuarios pueden ser eliminados de la BD utilizando el comando DROP USER. Este
comando tiene un nico parmetro, CASCADE, el cual permite borrar todos los objetos del
usuario antes de eliminar el usuario.
A continuacin un ejemplo en el que eliminamos al usuario Prez:

SVRMGR> drop user perez cascade;

Si a continuacin se crea otro usuario con el mismo nombre no hereda los objetos del
anterior usuario con ese nombre. La razn estriba en que Oracle asigna a cada cuenta un
nmero adems del nombre, y utiliza ese nmero para determinar el propietario de todos
los objetos que crea esa cuenta, y no utiliza el nombre sino para la comunicacin con los
usuarios. De este modo al crear un nuevo usuario, aunque sea con el mismo nombre, no
puede heredar los objetos que antes eran de otro usuario con el mismo nombre.

2.3 Privilegios del Sistema

Los roles de sistema se utilizan para distribuir la disponibilidad de los comandos del
sistema utilizados para gestionar la BD. Los privilegios ms comunes estn en la siguiente
tabla. En ella se distinguen entre privilegios de manejo de objetos y de gestin de la BD. La
palabra clave ANY significa que ese usuario tiene el privilegio para todos los esquemas en la
BD. Hay que hacer notar que ANY y PUBLIC no son sinnimos.
Privilegio

Capacidades

Manejo de
Objetos

...

CREATE ANY
INDEX

Crear cualquier ndice.

CREATE [PUBLIC]

Crear sinnimos [pblicos].

SYNONYM
CREATE [ANY]
TABLE

Crear tablas. El usuario debe tener cuota en el espacio de

tablas, o ha de tener asignado el privilegio UNLIMITED
TABLESPACE.

CREATE [ANY]
VIEW

Crear vistas.

ALTER ANY INDEX

Alterar cualquier ndice.

ALTER ANY TABLE

Alterar cualquier tabla

DROP ANY INDEX

Borrar cualquier ndice.

DROP ANY
SYNONYM

Borrar cualquier sinnimo.

DROP PUBLIC
SYNONYM

Borrar sinnimos pblicos.

DROP ANY VIEW

Borrar cualquier vista.

DROP ANY TABLE

Borrar cualquier tabla.

SELECT ANY
TABLE

Efectuar selecciones de cualquier tabla o vista.

INSERT ANY
TABLE

Insertar en cualquier tabla o vista.

DELETE ANY
TABLE

Borrar filas de cualquier tabla o vista, y tambin truncar.

ALTER SESSION

Alterar los parmetros de la sesin.

CREATE SESSION

Conectarse a la BD.

Gestin de la BD

...

CREATE PROFILE

Crear perfiles de usuario.

CREATE ROLE

Crear roles.

CREATE ROLLBACK
SEGMENT

Creacin de segmentos de rollback.

CREATE
TABLESPACE

Crear espacios de tablas.

CREATE USER

Crear usuarios.

ALTER PROFILE

Alterar perfiles existentes.

ALTER ANY ROLE

Alterar cualquier rol.

ALTER ROLLBACK
SEGMENT

Alterar segmentos de rollback.

ALTER
TABLESPACE

Alterar espacios de tablas.

ALTER USER

Alterar usuarios.

DROP PROFILE

Borrar un perfil existente.

DROP ANY ROLE

Borrar cualquier rol.

DROP ROLLBACK

Borrar un segmento de rollback existente.

SEGMENT
DROP TABLESPACE

Borrar un espacio de tablas.

DROP USER

Borrar un usuario. Aadir CASCADE si el usuario posee

objetos.

ALTER DATABASE

Permite una sentencia ALTER DATABASE.

GRANT ANY
PRIVILEGE

Otorgar cualquiera de estos privilegios.

GRANT ANY ROLE

Otorgar cualquier rol a un usario.

UNLIMITED
TABLESPACE

Puede usar una cantidad de almacenamiento ilimitada.

DROP PROFILE

Borrar un perfil existente.

Los privilegios se pueden agrupar en roles, para as satisfacer a distintos tipos de usuarios.
En la instalacin se crea un rol llamado OSOPER que sirve para los operarios de la mquina
donde est la BD y permite realizar copias de seguridad en frio y en caliente. Los
privilegios de OSOPER son STARTUP, SHUTDOWN, ALTER DATABASE OPEN/MOUNT, ALTER
DATABASE BACKUP, ARCHIVE LOG, RECOVER y RESTRICTED SESSION.
Se pueden crear nuevos roles. Por ejemplo, podemos crear un rol llamado creadorCuentas
que slo pueda crear usuarios y no pueda realizar ninguna otra operacin de DBA. Las
sentencias que permiten hacer esto son las siguientes:

SVRMGR> create role creadorCuentas;

Statement processed.
SVRMGR> grant create session, create user to creadorCuentas;
Statement processed.
Oracle incluye otros tres roles de sistema: CONNECT, RESOURCE y DBA, cuyos privilegios son:
Rol

Privilegios

CONNECT

alter session, create session, create cluster, create

table, create view, create synonym, create sequence,
create database link

RESOURCE

create cluster, create table, create procedure, create

sequence, create trigger

DBA

todos los privilegios de sistema con la opcion with admin option

2.4 Perfiles de Usuario

Los perfiles se utilizan para limitar la cantidad de recursos del sistema y de la BD
disponibles para un usuario. Si no se definen perfiles para un usuario se utiliza el perfil por
defecto, que especifica recursos ilimitados.

Los recursos que pueden ser limitados via perfil son los siguientes:
Recurso

Descripcin

SESSIONES_PER_USER

El nmero de sesiones concurrentes que un

usuario puede tener en una instancia.

CPU_PER_SESSION

El tiempo de CPU, en centenas de segundos, que

una sesin puede utilizar.

CONNECT_TIME

El nmero de minutos que una sesin puede

permanecer activa.

IDLE_TIME

El nmero de minutos que una sesin puede

permanecer sin que sea utilizada de manera
activa.

LOGICAL_READS_PER_SESSION

El nmero de bloques de datos que se pueden leer

en una sesin.

LOGICAL_READS_PER_CALL

El nmero de bloques de datos que se pueden leer

en una operacin.

PRIVATE_SGA

La cantidad de espacio privado que una sesin

puede reservar en la zona de SQL compartido de
la SGA.

COMPOSITE_LIMIT

El nmero de total de recursos por sesin, en

unidades de servicio. Esto resulta de un calculo
ponderado de CPU_PER_SESSION, CONNECT_TIME,
LOGICAL_READS_PER_SESSION y PRIVATE_SGA,
cuyos pesos se pueden variar con el comando
ALTER RESOURCE COST.

Los perfiles se pueden crear via el comando CREATE PROFILE, y se pueden modificar con
la sentencia ALTER PROFILE.
En general, el perfil por defecto debe ser adecuado para los usuarios normales; los usuarios
con requerimientos especiales deberan tener perfiles especiales.

2.5 Cuentas BD sobre Cuentas SO

Los usuarios pueden entrar en la BD una vez que han dado un nombre de usuario y una
palabra de paso. Sin embargo, es posible aprovecharse del Sistema Operativo para obtener
un nivel adicional de autentificacin.
La cuenta de la BD y del SO pueden relacionarse de manera que la de la BD se diferencie
slo en un prefijo de la cuenta del SO. Este prefijo se fija en el parmetro
OS_AUTHENTIC_PREFIX del fichero init.ora. Por defecto esta puesto a "OPS$", pero puede

tomar cualquier forma, incluso ser la cadena nula, "", con lo que no existe prefijo que
diferencie las cuentas en la BD y en el SO.
Por ejemplo, consideremos la cuenta del SO llamada alu10. La correspondiente cuenta en
la BD sera OPS$ALU10. Cuando el usuario alu10 est en activo en el SO, puede acceder a
su cuenta OPS$ALU10 sin especificar el password, como se muestra a continuacin:

$ sqlplus /
En este caso el carcter "/" toma el lugar de la combinacin del nombre de usuario y del
password que debera aparecer.
Las cuentas pueden ser creadas con passwords aunque no vaya a ser utilizado. Ya que de
este modo ser posible acceder a la cuenta de OPS$ALU10 desde otra cuenta diferente a la
alu10 del SO. La sentencia de creacin de la cuenta OPS$ALU10 puede ser la siguiente:

SVRMGR> create user ops$alu10

2> identified by 01ula
3> default tablespace users
4> temporary tablespace temp;
As, la forma de conectarse como OPS$ALU10 desde una cuenta del SO diferente es:

$ sqlplus ops$alu10/01ula
Existen dos formas de evitar este problema. La primera es creando el usuario BD sin
especificar un password, utilizando la clasula IDENTIFIED EXTERNALLY. De esta manera
evitamos la necesidad de expecificar un password para la cuenta, obligando a la conexin
entre las cuentas de la BD y del SO:

SVRMGR> create user ops$alu10

2> identified externally
3> default tablespace users
4> temporary tablespace temp;
La otra manera de evitar el problema es crear una cuenta con un password imposible,
aspecto este que se explicar ms adelante.

2.6 Protegidos por passwords

Los passwords puede proteger tanto cuentas como roles. Los passwords se fijan a la hora de
la creacin de ambos y se pueden modificar con los comandos ALTER USER y ALTER ROLE,
respectivamente.
No es necesario asignar un password a un rol, pero si tiene uno debe ser especificado por el
usuario cuando se asigna ese rol.

2.7 Gestionando Privilegios

Los privilegios dan acceso a los usuarios a los datos que no poseen. Los roles con grupos de
privilegios que facilitan la administracin de los privilegios. Pero los privilegios se pueden
manejar de manera explcita en algunas circunstancias.
Los privilegios se crean via el comando GRANT y son registrados en el diccionario de datos.
Los privilegios que pueden otorgarse sobre objetos son los siguientes:
Privilegio

Capacidades Otorgadas

SELECT

Puede consultar a un objeto.

INSERT

Puede insertar filas en una tabla o vista. Puede especificarse las

columnas donde se permite insertar dentro de la tabla o vista.

UPDATE

Puede actualizar filas en una tabla o vista. Puede especificarse las

columnas donde se permite actualizar dentro de la tabla o vista.

DELETE

Puede borrar filas dentro de la tabla o vista.

ALTER

Puede alterar la tabla.

INDEX

Puede crear ndices de una tabla.

REFERENCES

Puede crear claves ajenas que referencie a esta tabla.

EXECUTE

Puede ejecutar un procedimieto, paquete o funcin.

Haciendo un privilegio PUBLIC lo hace disponible a todos los usuarios de la BD.

Aunque los privilegios se puedan otorgar individualmente, no resulta razonable basar la
gestin de los privilegios en su asignacin individual. La gestin de los privilegios se
facilita con la utilizacin de los roles. A continuacin se puede ver como se crean dos roles,
el ALUMNOS que permite establecer una sesin, y el rol INSERTA_PEREZ que permite insertar
y seleccionar en la tabla emp de perez:

SVRMGR> create role alumnos;

Statement processed.
SVRMGR> grant create session to alumnos;

Statement processed.
SVRMGR> create role inserta_perez;
Statement processed.
SVRMGR> grant select, insert on perez.emp to inserta_perez;
Statement processed.
Se pueden asignar roles a roles:

SVRMGR> grant usuarios to inserta_perez;

Los roles pueden asignarse a los usuarios. As, podemos asignar el rol INSERTA_PEREZ al
usuario alu20:

SVRMGR> grant inserta_perez to alu20;

Los roles se pueden denegar con el comando REVOKE.

2.8 Listar Privilegios Otorgados

La informacin de los privilegios otorgados se almacena en el diccionario de datos. Estos
datos son accesibles a travs de las siguientes vistas del diccionario de datos:
Vista

Contenidos

DBA_ROLES

Nombres de los roles y su estado del password.

DBA_ROLES_PRIVS

Usuarios a los que han sido otorgados roles.

DBA_SYS_PRIVS

Usuarios a los que han sido otorgados privilegios del sistema.

DBA_TAB_PRIVS

Usuarios a los que han sido otorgados privilegios sobre

objetos.

DBA_COL_PRIVS

Usuarios a los que han sido otorgados privilegios sobre

columnas de tablas.

ROLE_ROLE_PRIVS

Roles que han sido otorgados a otros roles.

ROLE_SYS_PRIVS

Privilegios de sistema que han sido otorgados a roles.

ROLE_TAB_PRIVS

Privilegios de tabla que han sido otorgados a roles.

3 Encriptacin de Passwords y Trucos

Conocer el modo en que se encriptan y se tratan los passwords puede posiblitar al DBA la
realizacin de ciertas tareas que de otro modo le resultaran imposibles. Esto incluye el
establecer passwords imposibles y la habilidad de convertirse en otro usuario.

3.1 Almacenamiento de Passwords

Cuando se especifica un password para un usuario o rol, la BD almacena la versin
encriptada del mismo en el diccionario de datos. El mismo password para diferentes
usuarios genera diferentes versiones encriptadas. stas estn compuestas por una cadena de
16 caractres alfanumricos (con las letras en maysculas).
El proceso de validacin de los passwords es sencillo, ya que cuando un usuario introduce
su password es encriptado y comparado lo almacenado en el diccionario de datos. Si son
iguales el password es correcto; incorrecto en otro caso.
Se puede echar un vistazo a los passwords mirando en la tabla DBA_USERS:

SQL> select username, password from dba_users;

3.2 Passwords Imposibles

Qu puede pasar si en vez de especificar el password especificamos su versin encriptada,
y esa versin encriptada no sigue las normas de generacin de passwords encriptados? El
resultado es que tendremos una cuenta a la que nunca se podr entrar, ya que ningn
password generar la versin encriptada que est almacenada en el diccionario de datos.
Esto se puede hacer utilizando una forma no comentada del comando CREATE USER como
se indica a continuacin:

SVRMGR> create user perez identified by values

'123AB456CD789EF0';
Una buena manera de crear una versin encriptada que no coincida con ningn password es
poner menos de 16 caractres, de esta manera tendremos un password imposible.
Los efectos de este comando se ven cuando el usuario perez intenta acceder introduciendo
su password, desde otra cuenta por ejemplo. Como la versin encriptada del password no
va a coincidir con la almacenada, se obliga al usuario perez a entrar desde su cuenta del
SO, proceso que no comprueba el password de la BD. De este modo se impide que un
usuario pueda suplantar a otro desde una cuenta de SO no apropiada.

3.3 Convertirse en otro Usuario

Como se puede fijar la versin encriptada de un password, es posible tomar una cuenta
temporalmente, cambiando su password original, para restaurarlo a continuacin. Esto
permite que el DBA se convierta temporalmente en otro usuario.
Esto se puede hacer siguiendo los siguientes pasos:
1. Consultar la tabla DBA_USERS para conseguir la versin encriptada del password
actual del usuario que vamos a utilizar.
2. Generar el comando alter user que permita restaurar el password original,
guardandolo en un fichero para su posterior ejecucin.
3. Cambiar el password de la cuenta y acceder a ella.
4. Cuando el trabajo como el otro usuario haya acabado, ejecutar el comando alter
user creado antes para restaurar el valor original del password.
Esto se puede ver en el siguiente script:

REM *
REM * Este script genera los comandos necesarios para
convertirse
REM * temporalmente en otro usuario.
REM *
REM * Solo para DBAs
REM *
set
set
set
set

pagesize 0
verify of
feedback of
echo of

REM *
REM * Preguntar por el usuario a manipular.
REM *
accept user prompt 'Usuario? '
set termout of
REM *

REM * Crear el fichero llamado reset.sql

REM *
spool reset.sql
REM *
REM * seleccionar el password encriptado de DBA_USERS.
REM *
select 'alter user &&user
identified by values '||''''||password||''''||';'
from dba_users where username= upper('&&user');
prompt ! rm reset.sql
prompt exit
REM *
REM * Cerrar el fichero llamado reset.sql
REM *
spool of
REM *
REM * Cambiar el password a user
REM *
set termout on
accept clave prompt 'Nueva Clave para &&user? '
REM *
REM * Cambiar la clave para el usuario
REM *
alter user &&user identified by &&clave;
connect &&user/&&clave;
prompt
prompt
prompt
prompt

***
*** Ahora es &&user
*** No olvide ejecutar reset.sql al final
***

La ejecucin de este script produce otro script llamado reset.sql con el siguiente
contenido:

alter user pepe identified by values '742A081355525D4E';

! rm reset.sql
exit
El script reset.sql se ejecutar con la orden

$ sqlplus system/manager @reset.sql

4 Auditora de Seguridad
El SGBD Oracle tienen la capacidad de auditar todas las acciones que tienen lugar en la
BD. Se pueden auditar tres tipos de acciones:

intentos de entrada en cuentas de la BD.

accesos a los objetos de la BD.

acciones sobre la BD.

La BD registra todos los intentos de accin, tanto los exitosos como los infructuosos,
aunque es un parmetro configurable.
Para habilitar la capacidad de auditora, se debe fijar el parmetro AUDIT_TRAIL en el
fichero init.ora. Los registros de auditora se almacenan en la tabla SYS.AUD$ o bien su
gestin se deja al SO. Cuando se decide utilizar la tabla SYS.AUD$ esta debe revisarse
peridicamente, por si hiciera falta truncarla debido a que su aumento de tamao puede
causar problemas de espacio en el tablespace SYSTEM. Los valores del parmetro
AUDIT_TRAIL son los que se exponen en la siguiente tabla:
Valor

Descripcin

NONE

Deshabilita la auditora

BD

Habilita la auditora, escribiendo en la tabla SYS.AUD$.

OS

Habilita la auditora, dejando al SO su gestin.

4.1 Auditando Conexiones

Todo intento de conexin con la BD ser registrado. El comando para iniciar la auditora es

SVRMGR> audit session;

Para determinar si se deben registrar slo los xitos, o slo los fracasos se pueden utilizar
los siguientes comandos:

SVRMGR> audit session whenever successful;

SVRMGR> audit session whenever not successful;
Si los registros de auditora se almacenan en la tabla SYS.AUD$, entonces pueden verse a
travs de la vista DBA_AUDIT_SESSION.

select
os_username,
/* nombre de usuario SO */
username,
/* nombre de usuario BD */
terminal,
decode(returncode,'0','Conectado',
'1005','Solo username, sin password',
'1017','Password incorrecto',
returncode), /* comprobacion de error */
to_char(timestamp,'DD-MON-YY HH24:MI:SS'), /* hora de
entrada */
to_char(logof_time,'DD-MON-YY HH24:MI:SS') /* hora de salida
*/
from dba_audit_session;
Para deshabilitar la auditoria de las conexiones basta con ejecutar la siguiente sentencia:

SVRMGR> noaudit session;

4.2 Auditando Acciones

Se puede auditar cualquier accin que afecte a cualquier objeto de la BD. Para facilitar la
gestin, las acciones a auditar se encuentran agrupadas segn los grupos que se muestran en
la siguiente tabla:
Grupo

Comandos Auditados

CLUSTER

Todas las sentencias que afecten a clusters.

DATABASE LINK

Todas las sentencias que afecten a enlaces de BD.

EXISTS

Todas las sentencias que fallen porque ya existe un objeto

en la BD.

INDEX

Todas las sentencias que afecten a ndices.

NOT EXISTS

Todas las sentencias que fallen porque un determinado

objeto no existe.

PROCEDURE

Todas las sentencias que afecten a procedimientos.

PROFILE

Todas las sentencias que afecten a perfiles.

PUBLIC DATABASE
LINK

Todas las sentencias que afecten a enlaces pblicos de BD.

PUBLIC SINONYM

Todas las sentencias que afecten a sinnimos pblicos.

ROLE

Todas las sentencias que afecten a roles.

ROLLBACK SEGMENT

Todas las sentencias que afecten a segmentos de rollback.

SEQUENCE

Todas las sentencias que afecten a secuencias.

SESSION

Todas las sentencias de acceso a la BD.

SYNONYM

Todas las sentencias que afecten a sinnimos.

SYSTEM AUDIT

Todas las sentencias AUDIT y NOAUDIT.

SYSTEM GRANT

Todas las sentencias afecten a privilegios.

TABLE

Todas las sentencias que afecten a tablas.

TABLESPACE

Todas las sentencias que afecten a espacios de tablas.

TRIGGER

Todas las sentencias que afecten a disparadores.

USER

Todas las sentencias que afecten a las cuentas de usuarios.

VIEW

Todas las sentencias que afecten a vistas.

Por ejemplo, para auditar todas acciones que tienen que ver con las tablas sirve el siguiente
comando:

SVRMGR> audit table;

Y para deshabilitar la auditora se utilizar el siguiente comando:

SVRMGR> noaudit table;

Tambin se puede afinar un poco ms en la auditora fijando un usuario concreto al que
seguir la pista:

SVRMGR> audit table by perez;

Cada accin auditada recibe un cdigo numrico al que se puede acceder a travs de la vista
AUDIT_ACTIONS. Una vez que conocemos el cdigo de la accin, podemos utilizarlo para
determinar como dicha accin ha afectado a un objeto, consultado la vista
DBA_AUDIT_OBJECT.

4.3 Auditando Objetos

Adems de la auditora de acciones sobre los objetos, se puede seguir el rastro a las
operaciones de manipulacin de tablas: SELECT, INSERT, UPDATE y DELETE. Estas auditoras
se pueden hacer por sesin o por acceso.
Un ejemplo de sentencias de auditoras sobre objetos se puede ver en el siguiente grupo de
sentencias:

SVRMGR> audit insert on perez.emp;

SVRMGR> audit all on perez.emp by session;
SVRMGR> audit delete on perez.emp by access;
Los registros de auditora se pueden ver en la misma vista DBA_AUDIT_OBJECT
anteriormente mencionada.

4.4 Protegiendo los Registros de Auditora

Los registros de la tabla SYS.AUD$ pueden ser objeto de intentos de acceso para ser
eliminados ya que pueden reflejar acciones no autorizadas en la BD. As, resulta interesante
reflejar ese tipo de acciones. Esto se consigue con el siguiente comando:

SVRMGR> audit all on sys.aud$ by access;

De este modo cualquier accin contra la tabla SYS.AUD$ quedar registrado. Adems, las
acciones contra la tabla SYS.AUD$ slo pueden ser borradas por los usuarios que puedan
conectarse como INTERNAL.

- Si quieres ordenadas por la ltima ejecutada :

Select * from
( Select LAST_ACTIVE_TIME ULTIMA_EJECUCION,

SQL_FULLTEXT SENTENCIA,
EXECUTIONS VECES_EJECUTADA,
USERS_EXECUTING VECES_DIFERENTES_USUARIOS
From V$sqlarea a
Order by a.LAST_ACTIVE_TIME desc)
Where rownum <= (numero de sentencias que quieres que te salgan);
- Si quieres ordenadas por la ltima CARGADA :
Select * from
( Select FIRTS_LAST_TIME ULTIMA_CARGADA,
SQL_FULLTEXT SENTENCIA,
EXECUTIONS VECES_EJECUTADA,
USERS_EXECUTING VECES_DIFERENTES_USUARIOS
From V$sqlarea a
Order by FIRTS_LAST_TIME desc)
Where rownum <= (numero de sentencias que quieres que te salgan;

Cambia el password:
alter user loginname identified by newPassword;

Backup & Restore Database

exp system/mypassword@mibase file=exptotal.dmp full=y log=exptotal.log
Esto te hara el export completo de la Base de Datos... Si lo que necesitas es solamente
el de un usuario con todas sus tablas y sus procedimientos, packages, functionts, etc.
has lo siguiente.
exp system/devilhunter817@bmidesa owner=miusuario file=expmiusuario.dmp
log=expmiusuario.log grants=y indexes=y rows=y triggers=y constraints=y

Backup & Restore Database

exp userid=ACTIVO/calma@hcpg file=d:\exp\ACTIVO.dmp owner=ACTIVO
imp userid=GENERAL/sfp@toshiba file=d:\exp\GENERAL.dmp full=y

Usuarios y privilegios en Oracle

1. Crear Usuarios y asignar privilegios en Oracle

El siguiente es un resumen de algunas consideraciones al momento de crear un usuario o
cuenta en Oracle, y los privilegios y roles que le podemos asignar.

El nombre de usuario no debe superar 30 caracteres, no debe tener caracteres

especiales y debe iniciar con una letra.

Un mtodo de autentificacin. El mas comn es una clave o password, pero Oracle

10g soporta otros mtodos (como biometric, certificado y autentificacin por medio
de token).

Un Tablespace default, el cual es donde el usuario va a poder crear sus objetos por
defecto, sin embargo, esto no significa que pueda crear objetos, o que tenga una
cuota de espacio. Estos permisos se asignan de forma separada, salvo si utiliza el
privilegio RESOURCE el que asigna una quota unlimited, incluso en el Tablespace
SYSTEM! Sin embargo si esto ocurre, ud. puede posteriormente mover los objetos
creados en el SYSTEM a otro Tablespace.

Un Tablespace temporal, donde el usuario crea sus objetos temporales y hace los
sort u ordenamientos.

Un perfil o profile de usuario, que son las restricciones que puede tener su cuenta
(opcional).

Por ejemplo, conectado como el usuario SYS, creamos un usuario y su clave asi:
SQL> CREATE USER ahernandez IDENTIFIED BY ahz
DEFAULT TABLESPACE users;
Si no se indica un Tablespace por defecto, el usuario toma el que est definido en la BD
(generalmente el SYSTEM). Para modificar el Tablespace default de un usuario se hace de
la siguiente manera:
SQL> ALTER USER jperez DEFAULT TABLESPACE datos;
Tambin podemos asignar a los usuarios un Tablespace temporal donde se almacenan
operaciones de ordenamiento. Estas incluyen las clusulas ORDER BY, GROUP BY,
SELECT DISTINCT, MERGE JOIN, o CREATE INDEX (tambin es utilizado cuando se
crean Tablas temporales).

SQL> CREATE USER jperez IDENTIFIED BY jpz

DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp;
Adicionalmente, a cada usuario se puede asignar a un profile o perfil, que tiene dos
propsitos principalmente:

Limita el uso de recursos, lo que es recomendable, por ejemplo en ambientes de

Desarrollo

Garantiza y refuerza reglas de Seguridad a nivel de cuentas

Ejemplos, cuando se crea el usuario o asignar un perfil existente:

SQL> CREATE USER jperez IDENTIFIED BY jpz
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp
PROFILE resource_profile;
SQL> ALTER USER jperez
PROFILE perfil_desa;
2. Eliminar un Usuario de la Base de Datos
Para eliminar un usuario de la BD se hace uso de la clausula DROP USER y opcionalmente
se puede utilizar CASCADE, para decirle que tambin elimine todos los objetos creados
por ese usuario.
SQL> DROP USER jperez CASCADE;
3. Modificar cuentas de Usuarios
Para modificar un usuario creado, por ejemplo cambiar su clave, tenemos la sintxis:
SQL> ALTER USER NOMBRE_USUARIO
IDENTIFIED BY CLAVE_ACCESO
[DEFAULT TABLESPACE ESPACIO_TABLA]
[TEMPORARY TABLESPACE ESPACIO_TABLA]
[QUOTA {ENTERO {K | M } | UNLIMITED } ON ESPACIO_TABLA
[PROFILE PERFIL];
4. Privilegios de Sistema y de Objetos
En Oracle existen dos tipos de privilegios de usuario.

4.1 System: Que permite al usuario hacer ciertas tareas sobre la BD, como por ejemplo
crear un Tablespace. Estos permisos son otorgados por el administrador o por alguien que
haya recibido el permiso para administrar ese tipo de privilegio. Existen como 100 tipos
distintos de privilegios de este tipo.
En general los permisos de sistema, permiten ejecutar comandos del tipo DDL (Data
definition Language), como CREATE, ALTER y DROP o del tipo DML (Data
Manipulation Language). Oracle 10g tiene mas de 170 privilegios de sistema los cuales
pueden ser vistos consultando la vista: SYSTEM_PRIVILEGE_MAP
Entre todos los privilegios de sistema que existen, hay dos que son los importantes:
SYSDBA y SYSOPER. Estos son dados a otros usuarios que sern administradores de base
de datos.
Para otorgar varios permisos a la vez, se hace de la siguiente manera:
SQL> GRANT CREATE USER, ALTER USER, DROP USER TO ahernandez;
4.2 Object: Este tipo de permiso le permite al usuario realizar ciertas acciones en objetos
de la BD, como una Tabla, Vista, un Procedure o Funcin, etc. Si a un usuario no se le dan
estos permisos slo puede acceder a sus propios objetos (vase USER_OBJECTS). Este
tipo de permisos los da el owner o dueo del objeto, el administrador o alguien que haya
recibido este permiso explcitamente (con Grant Option).
Por ejemplo, para otorgar permisos a una tabla Ventas para un usuario particular:
SQL> GRANT SELECT,INSERT,UPDATE, ON analista.venta TO jperez;
Adicionalmente, podemos restringir los DML a una columna de la tabla mencionada. Si
quisieramos que este usuario pueda dar permisos sobre la tabla Factura a otros usuarios,
utilizamos la clusula WITH GRANT OPTION. Ejemplo:
SQL> GRANT SELECT,INSERT,UPDATE,DELETE ON venta TO mgarcia WITH
GRANT OPTION;
5. Asignar cuotas a Usuarios
Por defecto ningun usuario tiene cuota en los Tablespaces y se tienen tres opciones para
poder proveer a un usuario de una quota:
5.1Sin limite, que permite al usuario usar todo el espacio disponible de un Tablespace.
5.2 Por medio de un valor, que puede ser en kilobytes o megabytes que el usuario puede
usar. Este valor puede ser mayor o nenor que el tamao del Tablespace asignado a l.
5.3 Por medio del privilegio UNLIMITED TABLESPACE, se tiene prioridad sobre
cualquier cuota dada en un Tablespace por lo que tienen disponibilidad de todo el espacio
incluyendo en SYSTEM y SYSAUX.

No se recomienda dar cuotas a los usuarios en los Tablespaces SYSTEM y SYSAUX, pues
tipicamente slo los usuarios SYS y SYSTEM pueden crear objetos en stos. Tampoco dar
cuotas en los Tablespaces Temporal o del tipo Undo.
6. Roles
Finalmente los Roles, que son simplemente un conjunto de privilegios que se pueden
otorgar a un usuario o a otro Rol. De esa forma se simplifica el trabajo del DBA en esta
tarea.
Por default cuando creamos un usuario desde el Enterprise Manager se le asigna el permiso
de connect, lo que permite al usuario conectarse a la BD y crear sus propios objetos en su
propio esquema. De otra manera, debemos asignarlos en forma manual.
Para crear un Rol y asignarlo a un usuario se hace de la siguiente manera:
SQL> CREATE ROLE appl_dba;
Opcionalmente, se puede asignar una clave al Rol:
SQL> SET ROLE appl_dba IDENTIFIED BY app_pwd;
Para asignar este Rol a un usuario:
SQL> GRANT appl_dba TO jperez;
Otro uso comn de los roles es asignarles privilegios a nivel de Objetos, por ejemplo en una
Tabla de Facturas en donde slo queremos que se puedan hacer Querys e Inserts:
SQL> CREATE ROLE consulta;
SQL> GRANT SELECT,INSERT on analista.factura TO consulta;
Y finalmente asignamos ese rol con este perfil a distintos usuarios finales:
SQL> GRANT consulta TO ahernandez;
Nota: Existen algunos roles predefinidos, tales como:
CONNECT, CREATE SESSION, CREATE TABLE, CREATE VIEW, CREATE
SYNONYM, CREATE SEQUENCE, CREATE DATABASE LINK, CREATE CLUSTER,
ALTER SESSION, RESOURCE, CREATE PROCEDURE, CREATE SEQUENCE,
CREATE TRIGGER, CREATE TYPE, CREATE CLUSTER, CREATE INDEXTYPE,
CREATE OPERATOR SCHEDULER, CREATE ANY JOB, CREATE JOB, EXECUTE
ANY CLASS, EXECUTE ANY PROGRAM,
MANAGE SCHEDULER, etc.
DBA: Tiene la mayora de los privilegios, no es recomendable asignarlo a usuarios que no

son administradores.
SELECT_CATALOG_ROLE: No tiene privilegios de sistema, pero tiene cerca de 1600
privilegios de objeto.
Para consultar los roles definidos y los privilegios otorgados a travs de ellos, utilize las
vistas:
SQL> select * from DBA_ROLES;
SQL> select * from DBA_ROLE_PRIVS order by GRANTEE;

Administracin y Optimizacin de Bases de

Datos Oracle
Copyright 1999-2004

Manuel de la Herrn Gascn

Mtodos de autentificacin para operaciones sobre la

instancia
En cuanto a la confidencialidad relativa a operaciones sobre la instancia, existen dos
formas de autentificacin

Mtodos de autentificacin para operaciones sobre la instancia

por sistema operativo

por fichero de passwords

Mtodos recomendados

Tipo de
Administracin

hay una
Mtodo recomendado
conexin segura?

local

si

por fichero de passwords o

por sistema operativo

local

no

por fichero de passwords o

por sistema operativo

remota

si

por fichero de passwords o

por sistema operativo

remota

no

por fichero de passwords

Mtodos de autentificacin utilizados

Sistema Operativo

Mtodo utilizado

Unix y VMS

por sistema operativo

NT

por fichero de passwords

Configuracin

En c:\orant\database\initorcl.ora
Autentificacin por Sistema Operativo

Autentificacin por fichero de passwords

remote_login_passwordfile = none

remote_login_passwordfile = exclusive
remote_login_passwordfile = shared

remote_login_passwordfile = shared indica que el fichero de passwords puede ser

compartido por varias bases de datos, pero entonces los nicos usuarios permitidos
sern SYS y INTERNAL
En la autentificacin por Sistema Operativo, Oracle comprueba que el usuario del
Sistema Operativo posee los roles del Sistema Operativo:
OSDBA
OSOPER
y los hace equivalentes a los modos de conexin de Oracle:
SYSDBA

 SYSOPER

SQL>connect scott/tiger@orcl as sysdba

SQL>connect scott/tiger@orcl as sysoper
Por ejemplo, sys no puede hacer shutdown conectandose como

SQL>connect sys/change_on_install
pero s como

SQL>connect sys/oracle as sysdba

El rol del
Sistema
Operativo

Supone

OSOPER

Permiso para realizar las acciones STARTUP, SHUTDOWN, ALTER DATABASE

OPEN/MOUNT, ALTER DATABASE BACKUP, ARCHIVE LOG, RECOVER, y
incluye el privilegio RESTRICTED SESSION

OSDBA

Todos los privilegios con ADMIN OPTION, el OSOPER y el comando CREATE

DATABASE

Cambio de la password del usuario internal

1. Borrar o mover el fichero C:\orant\database\pwdorcl.ora

2. Ejecutar

c:\orant\bin>orapwd80.exe file=c:\orant\database\pwdorcl.ora
password=oracle
Suplantacin de un usuario

1. Obtener y copiar la password encriptada

SQL>select password from dba_users where username='SCOTT';

2. Modificar la password

SQL>alter user scott identified by nueva;

3. Realizar las acciones deseadas

4. Restaurar la password

SQL>alter user scott identified by values 'F894844C34402B67';