ORACLE: Seguridad

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 estár ligada con una cuenta de sistema operativo. Las passwords son fijadas cuando se crea un usuario y pueden ser alterados por el DBA o por el usuario mismo. La BD almacena una versión “hashing” del password en una vista del diccionario llamada dba_users. Si la cuenta en la BD está asociada a una cuenta del sistema operativo puede evitarse la comprobación del password, dándose por válida la comprobación 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 utilización de los roles simplifica la administración de los privilegios cuando tenemos muchos usuarios. Los roles pueden ser protegidos con passwords, y pueden activarse y desactivarse dinámicamente, con lo que constituyen una capa más 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 clásicos 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 Implementación de Seguridad

No se podrá acceder a la BD a menos que se acceda primero al servidor en el que la BD está ejecutándose. 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 archivos a los que los usuario no tienen porque acceder de manera directa. Por ejemplo, los archivos de datos o los de redo log son escritos y leidos sólo por los procesos Oracle. Así, sólo los DBAs que han creado estos archivos necesitan acceder directamente a ellos a nivel del sistema operativo.

2.1 Creación de Usuarios

El objetivo de la creación 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 parámetros que se le pueden pasar son:

*Parámetro*	*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 serán creados. Esto no da al usuario derechos de crear objetos.
`Temporary Tablespace`	El espacio de tablas en el que se almacenarán los segmentos temporales de las ordenaciones.
`Quota`	Espacio máximo 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 numero de conexiones que puede tener un usuario o el tiempo de cpu, etc y además para controlar políticas de administración de passwords.

A continuación se puede ver un ejemplo de uso del comando CREATE USER en el que se crea una cuenta para el usuario Pérez:

SQL> create user aperez

     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 límites a UNLIMITED.

Si no se especifíca una cuota el usuario no puede crear objetos.

2.2 Eliminación de Usuarios

Los usuarios pueden ser eliminados de la BD utilizando el comando DROP USER. Este comando tiene un único parámetro, CASCADE, el cual permite borrar todos los objetos del usuario antes de eliminar el usuario.

A continuación un ejemplo en el que eliminamos al usuario Pérez:

SQL> drop user perez cascade;

Si a continuación se crea otro usuario con el mismo nombre no hereda los objetos del anterior usuario con ese nombre. La razón estriba en que Oracle asigna a cada cuenta un número además del nombre, y utiliza ese número para determinar el propietario de todos los objetos que crea esa cuenta, y no utiliza el nombre sino para la comunicación 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 más comunes están en la siguiente tabla. En ella se distinguen entre privilegios de manejo de objetos y de gestión 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 sinónimos.

*Privilegio*	*Capacidades*
*Manejo* *de Objetos*	...
`CREATE ANY INDEX`	Crear cualquier índice.
`CREATE [PUBLIC] SYNONYM`	Crear sinónimos [públicos].
`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 sinónimo.
`DROP PUBLIC SYNONYM`	Borrar sinónimos públicos.
`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 también truncar.
`ALTER SESSION`	Alterar los parámetros de la sesión.
`CREATE SESSION`	Conectarse a la BD.
*Gestión* *de la BD*	...
`CREATE PROFILE`	Crear perfiles de usuario.
`CREATE ROLE`	Crear roles.
`CREATE ROLLBACK SEGMENT`	Creación 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 SEGMENT`	Borrar un segmento de rollback existente.
`DROP TABLESPACE`	Borrar un espacio de tablas.
`DROP USER`	Borrar un usuario. Añadir `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 instalación se crea un rol llamado OSOPER que sirve para los operarios de la máquina 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 sólo pueda crear usuarios y no pueda realizar ninguna otra operación de DBA. Las sentencias que permiten hacer esto son las siguientes:

SQL> create role creadorCuentas;

Statement processed.

SQL> grant create session, create user to creadorCuentas;

Statement processed.

Oracle incluye otros roles de sistema: CONNECT, RESOURCE y DBA, cuyos privilegios son:

*Rol*	*Privilegios*
`CONNECT`	`create session`
`RESOURCE`	`create trigger , create sequence , create type, create procedure, create cluster, create operator, create indextype, create table`
`DBA`	160 privilegios de sistema con la opcion `with` `admin option`

PRIVILEGIOS ROL DBA

----------------------------------------

CREATE SESSION

ALTER SESSION

DROP TABLESPACE

BECOME USER

DROP ROLLBACK SEGMENT

SELECT ANY TABLE

INSERT ANY TABLE

UPDATE ANY TABLE

DROP ANY INDEX

SELECT ANY SEQUENCE

CREATE ROLE

EXECUTE ANY PROCEDURE

ALTER PROFILE

CREATE ANY DIRECTORY

CREATE ANY LIBRARY

EXECUTE ANY LIBRARY

ALTER ANY INDEXTYPE

DROP ANY INDEXTYPE

DEQUEUE ANY QUEUE

EXECUTE ANY EVALUATION CONTEXT

EXPORT FULL DATABASE

CREATE RULE

ALTER ANY SQL PROFILE

ADMINISTER ANY SQL TUNING SET

CHANGE NOTIFICATION

ALTER ROLLBACK SEGMENT

DELETE ANY TABLE

ALTER DATABASE

FORCE ANY TRANSACTION

ALTER ANY PROCEDURE

DROP ANY TRIGGER

DROP ANY MATERIALIZED VIEW

UNDER ANY TYPE

ALTER ANY LIBRARY

CREATE DIMENSION

DEBUG ANY PROCEDURE

CREATE RULE SET

ALTER ANY RULE SET

ANALYZE ANY DICTIONARY

RESTRICTED SESSION

CREATE TABLESPACE

ALTER TABLESPACE

CREATE USER

ALTER USER

LOCK ANY TABLE

CREATE VIEW

DROP ANY VIEW

GRANT ANY ROLE

CREATE TRIGGER

CREATE TYPE

EXECUTE ANY OPERATOR

CREATE ANY DIMENSION

ALTER ANY DIMENSION

CREATE ANY OUTLINE

ADMINISTER DATABASE TRIGGER

RESUMABLE

FLASHBACK ANY TABLE

CREATE ANY RULE SET

EXECUTE ANY RULE SET

IMPORT FULL DATABASE

EXECUTE ANY RULE

EXECUTE ANY PROGRAM

CREATE ANY TABLE

CREATE ANY INDEX

CREATE ANY SEQUENCE

ALTER ANY ROLE

ANALYZE ANY

DROP ANY LIBRARY

CREATE ANY OPERATOR

CREATE INDEXTYPE

UNDER ANY TABLE

DROP ANY DIMENSION

SELECT ANY DICTIONARY

GRANT ANY OBJECT PRIVILEGE

CREATE EVALUATION CONTEXT

CREATE ANY EVALUATION CONTEXT

DROP ANY EVALUATION CONTEXT

CREATE ANY RULE

CREATE JOB

CREATE ANY JOB

ALTER SYSTEM

AUDIT SYSTEM

CREATE ROLLBACK SEGMENT

DROP ANY TABLE

COMMENT ANY TABLE

CREATE CLUSTER

ALTER ANY INDEX

DROP PUBLIC DATABASE LINK

CREATE PROFILE

ALTER ANY MATERIALIZED VIEW

ALTER ANY TYPE

DROP ANY TYPE

UNDER ANY VIEW

EXECUTE ANY INDEXTYPE

DROP ANY CONTEXT

ALTER ANY OUTLINE

ADMINISTER RESOURCE MANAGER

MANAGE SCHEDULER

MANAGE FILE GROUP

CREATE TABLE

BACKUP ANY TABLE

CREATE ANY CLUSTER

DROP ANY SYNONYM

DROP PUBLIC SYNONYM

CREATE ANY VIEW

CREATE SEQUENCE

ALTER ANY SEQUENCE

FORCE TRANSACTION

CREATE PROCEDURE

CREATE ANY PROCEDURE

ALTER RESOURCE COST

DROP ANY DIRECTORY

CREATE ANY TYPE

CREATE ANY INDEXTYPE

ENQUEUE ANY QUEUE

ON COMMIT REFRESH

DEBUG CONNECT SESSION

DROP ANY RULE SET

EXECUTE ANY CLASS

MANAGE ANY FILE GROUP

ALTER ANY TABLE

DROP ANY CLUSTER

CREATE SYNONYM

CREATE PUBLIC SYNONYM

DROP ANY SEQUENCE

DROP ANY ROLE

AUDIT ANY

DROP ANY PROCEDURE

CREATE ANY TRIGGER

ALTER ANY TRIGGER

DROP PROFILE

GRANT ANY PRIVILEGE

CREATE LIBRARY

CREATE OPERATOR

DROP ANY OUTLINE

MERGE ANY VIEW

ADMINISTER SQL TUNING SET

MANAGE TABLESPACE

DROP USER

ALTER ANY CLUSTER

CREATE ANY SYNONYM

CREATE DATABASE LINK

CREATE PUBLIC DATABASE LINK

CREATE MATERIALIZED VIEW

CREATE ANY MATERIALIZED VIEW

EXECUTE ANY TYPE

DROP ANY OPERATOR

QUERY REWRITE

GLOBAL QUERY REWRITE

MANAGE ANY QUEUE

CREATE ANY CONTEXT

ALTER ANY EVALUATION CONTEXT

ALTER ANY RULE

DROP ANY RULE

ADVISOR

SELECT ANY TRANSACTION

DROP ANY SQL PROFILE

CREATE ANY SQL PROFILE

READ ANY FILE GROUP

CREATE EXTERNAL JOB

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*	*Descripción*
`SESSIONES_PER_USER`	El número de sesiones concurrentes que un usuario puede tener en una instancia.
`CPU_PER_SESSION`	El tiempo de CPU, en centenas de segundos, que una sesión puede utilizar.
`CONNECT_TIME`	El número de minutos que una sesión puede permanecer activa.
`IDLE_TIME`	El número de minutos que una sesión puede permanecer sin que sea utilizada de manera activa.
`LOGICAL_READS_PER_SESSION`	El número de bloques de datos que se pueden leer en una sesión.
`LOGICAL_READS_PER_CALL`	El número de bloques de datos que se pueden leer en una operación.
`PRIVATE_SGA`	La cantidad de espacio privado que una sesión puede reservar en la zona de SQL compartido de la SGA.
`COMPOSITE_LIMIT`	El número de total de recursos por sesión, 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 deberían 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 autentificación.

La cuenta de la BD y del SO pueden relacionarse de manera que la de la BD se diferencie sólo en un prefijo de la cuenta del SO. Este prefijo se fija en el parámetro OS_AUTHENTIC_PREFIX del archivo 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 sería 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 continuación:

$ sqlplus /

En este caso el carácter "/" toma el lugar de la combinación del nombre de usuario y del password que debería 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 creación de la cuenta OPS$ALU10 puede ser la siguiente:

SQL> 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 claúsula IDENTIFIED EXTERNALLY. De esta manera evitamos la necesidad de expecificar un password para la cuenta, obligando a la conexión entre las cuentas de la BD y del SO:

SQL> 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á más adelante.

2.6 Protegidos por passwords

Los passwords puede proteger tanto cuentas como roles. Los passwords se fijan a la hora de la creación 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 administración de los privilegios. Pero los privilegios se pueden manejar de manera explícita 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 función.

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 gestión de los privilegios en su asignación individual. La gestión de los privilegios se facilita con la utilización de los roles. A continuación se puede ver como se crean dos roles, el ALUMNOS que permite establecer una sesión, y el rol INSERTA_PEREZ que permite insertar y seleccionar en la tabla emp de perez:

SQL> create role alumnos;

Statement processed.

SQL> grant create session to alumnos;

Statement processed.

SQL> create role inserta_perez;

Statement processed.

SQL> grant select, insert on perez.emp to inserta_perez;

Statement processed.

Se pueden asignar roles a roles:

SQL> grant usuarios to inserta_perez;

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

SQL> grant inserta_perez to alu20;

Los roles se pueden denegar con el comando REVOKE.

2.8 Listar Privilegios Otorgados

La información de los privilegios otorgados se almacena en el diccionario de datos. Estos datos son accesibles a través 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 Encriptación de Passwords y Trucos

Conocer el modo en que se encriptan y se tratan los passwords puede posiblitar al DBA la realización de ciertas tareas que de otro modo le resultarían 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 versión encriptada del mismo en el diccionario de datos. El mismo password para diferentes usuarios genera diferentes versiones encriptadas. Éstas están compuestas por una cadena de 16 caractéres alfanuméricos (con las letras en mayúsculas).

El proceso de validación 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 versión encriptada, y esa versión encriptada no sigue las normas de generación de passwords encriptados? El resultado es que tendremos una cuenta a la que nunca se podrá entrar, ya que ningún password generará la versión 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 continuación:

SQL> create user perez identified by values '123AB456CD789EF0';

Una buena manera de crear una versión encriptada que no coincida con ningún password es poner menos de 16 caractéres, 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 versión 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 versión encriptada de un password, es posible tomar una cuenta temporalmente, cambiando su password original, para restaurarlo a continuación. Esto permite que el DBA se convierta temporalmente en otro usuario.

Esto se puede hacer siguiendo los siguientes pasos:

Consultar la tabla DBA_USERS para conseguir la versión encriptada del password actual del usuario que vamos a utilizar.
Generar el comando alter user que permita restaurar el password original, guardandolo en un archivo para su posterior ejecución.
Cambiar el password de la cuenta y acceder a ella.
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 pagesize 0

set verify off

set feedback off

set echo off

REM *

REM * Preguntar por el usuario a manipular.

REM *

accept user prompt 'Usuario? '

set termout off

REM *

REM * Crear el archivo 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 archivo llamado reset.sql

REM *

spool off

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 *** Ahora es &&user

prompt *** No olvide ejecutar reset.sql al final

prompt ***

La ejecución 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 símbolo ! equivale al comando sqlplus host

El script reset.sql se ejecutará con la orden

$ sqlplus system/manager @reset.sql

4 Auditoría de Seguridad

Antes de auditar se debe definir qué auditar

· Usuarios, sentencias, u objetos

· Ejecuciones de sentencias

· Ejecuciones exitosas de sentencias, , ejecuciones NO exitosas de sentencias , o ambas

Ud debe administrar la información de audit trail:

· Monitorear el crecimiento de la información de audit trail.

· Proteger la información de audit trail de acceso de usuarios no autorizados

El SGBD Oracle tiene 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 acción, tanto los exitosos como los infructuosos, aunque es un parámetro configurable.

Para habilitar la capacidad de auditoría, se debe fijar el parámetro AUDIT_TRAIL en el archivo init.ora o spfile. Los registros de auditoría se almacenan en la tabla SYS.AUD$ o bien su gestión se deja al SO. Cuando se decide utilizar la tabla SYS.AUD$ esta debe revisarse periódicamente, por si hiciera falta truncarla debido a que su aumento de tamaño puede causar problemas de espacio en el tablespace SYSTEM.

Los valores del parámetro AUDIT_TRAIL son los que se exponen en la siguiente tabla:

*Valor*	*Descripción*
`TRUE`	habilita la auditoría
`FALSE`	Deshabilita la auditoría
`NONE`	Deshabilita la auditoría
`BD`	Habilita la auditoría, escribiendo en la tabla `SYS.AUD$` (si es permitido por el sistema operativo)
`OS`	Habilita la auditoría, dejando al SO su gestión.

Audit records will not be written to the audit trail unless the DBA has set the AUDIT_TRAIL parameter to DB or OS. Although the SQL statements AUDIT and NOAUDIT can be used at any time, records will only be written to the audit trail if the DBA has set the AUDIT_TRAIL parameter in the initialization file.

Note: The Installation and Configuration Guide for your operating system provides information on writing audit records to the OS audit trail.

Specifying audit options:

Next, you set specific auditing options using the AUDIT command. With the AUDIT command, you indicate which commands, users, objects, or privileges to audit. You can also indicate whether an audit record should be generated for each occurrence or once per session. If an auditing option is no longer required, you can turn off the option with the NOAUDIT command.

Execution of statements:

When users execute PL/SQL and SQL statements, the server process examines the auditing options to determine if the statement being executed should generate an audit record. SQL statements inside PL/SQL program units are individually audited, as necessary, when the program unit is executed. Because views and procedures may refer to other database objects, several audit records may be generated as the result of executing a single statement.

Generating audit data:

The generation and insertion of an audit trail record is independent of a user’s transaction; therefore, if a user’s transaction is rolled back, the audit trail record remains intact. Because the audit record is generated during the execute phase, a syntax error, which occurs during the parse phase, will not cause an audit trail record to be generated.

Reviewing audit information:

Examine the information that is generated during auditing by selecting from the audit trail data dictionary views or by using an operating system utility to view the operating system audit trail. This information is used to investigate suspicious activity and to monitor database activity.

Categorias de Auditoria

• Auditado por default

– Instance startup e instance shutdown

– Privilegios de Administrador

• Auditoria de Base de Datos

– Es activada por el DBA

– NO Puede registrar valores de columnas

• Auditoria basada en valores o auditoria de aplicaciones

– Es implementada a través de código (por ejemplo triggers de base de datos)

– Puede registrar valores de columnas

– Usada para realizar seguimiento a cambios a registros de tablas

Auditing Categories

Regardless of whether database auditing is enabled, Oracle always records some database operations into the operating system audit trail. These are:

• Instance startup: The audit record details the operating system user who is starting the instance, the user’s terminal identifier, the date and time stamp, and whether database auditing was enabled or disabled.

• Instance shutdown: This details the operating system user who is shutting down the instance, the user’s terminal identifier, and the date and time stamp.

• Administrator privileges: This details the operating system user who is connecting to Oracle with administrator privileges.

Database auditing:

Database auditing monitors and records selected user database actions. Information about the event is stored in the audit trail.

The audit trail can be used to investigate suspicious activity. For example, if an unauthorized user is deleting data from tables, the DBA may decide to audit all connections to the database in conjunction with successful and unsuccessful deletions of rows from tables in the database.

Auditing might also be used to monitor and gather data about specific database activities. For example, the DBA can gather statistics about which tables are being updated, how many logical I/Os are performed, and how many concurrent users connect at peak times.

Value-based auditing:

Database auditing cannot record column values. If the changes to database columns must be tracked and column values must be stored for each change, then use application auditing. Application auditing can be done either through client code, stored procedures, or database triggers.

4.1 Auditando Conexiones

Todo intento de conexión con la BD será registrado. El comando para iniciar la auditoría es

SQL> audit session;

Para determinar si se deben registrar sólo los éxitos, o sólo los fracasos se pueden utilizar los siguientes comandos:

SQL> audit session whenever successful;

SQL> audit session whenever not successful;

Si los registros de auditoría se almacenan en la tabla SYS.AUD$, entonces pueden verse a través 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(logoff_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:

SQL> noaudit session;

4.2 Auditando Acciones

Se puede auditar cualquier acción que afecte a cualquier objeto de la BD. Para facilitar la gestión, las acciones a auditar se encuentran agrupadas según 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 públicos de BD.
`PUBLIC SINONYM`	Todas las sentencias que afecten a sinónimos públicos.
`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 sinónimos.
`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:

SQL> audit table;

Y para deshabilitar la auditoría se utilizará el siguiente comando:

SQL> noaudit table;

También se puede afinar un poco más en la auditoría fijando un usuario concreto al que se desea controlar:

SQL> audit table by perez;

Cada acción auditada recibe un código numérico al que se puede acceder a través de la vista AUDIT_ACTIONS. Una vez que conocemos el código de la acción, podemos utilizarlo para determinar como dicha acción ha afectado a un objeto, consultado la vista DBA_AUDIT_OBJECT.

4.3 Auditando Objetos

Además de la auditoría de acciones sobre los objetos, se puede seguir el rastro a las operaciones de manipulación de tablas: SELECT, INSERT, UPDATE y DELETE. Estas auditorías se pueden hacer por sesión o por acceso.

Un ejemplo de sentencias de auditorías sobre objetos se puede ver en el siguiente grupo de sentencias:

SQL> audit insert on perez.emp;

SQL> audit all on perez.emp by session;

SQL> audit delete on perez.emp by access;

Los registros de auditoría se pueden ver en la misma vista DBA_AUDIT_OBJECT anteriormente mencionada.

4.4 Protegiendo los Registros de Auditoría

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:

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

De este modo cualquier acción contra la tabla SYS.AUD$ quedará registrada. Además, las acciones contra la tabla SYS.AUD$ sólo pueden ser borradas por los usuarios que puedan conectarse como SYSDBA.

4.5 Obtención de Información de Auditoria

Information about auditing can be obtained by querying the following views:

· ALL_DEF_AUDIT_OPTS

· DBA_STMT_AUDIT_OPTS

· DBA_PRIV_AUDIT_OPTS

· DBA_OBJ_AUDIT_OPTS

4.6 Obtención de Información de Registros de Auditoria

Listing audit records:

The database audit trail (SYS.AUD$) is a single table in each Oracle database’s dictionary. Several predefined views are available. Some of the views are listed in the slide. These views are created by the DBA.

Data Dictionary View Description

-------------------- -------------------------------

DBA_AUDIT_TRAIL All audit trail entries

DBA_AUDIT_EXISTS Records for AUDIT EXISTS/NOT EXISTS

DBA_AUDIT_OBJECT Records concerning schema objects

DBA_AUDIT_SESSION All connect and disconnect entries

DBA_AUDIT_STATEMENT Statement auditing records