Seguridad BD Oracle

Jaime Amigo P. © 2006, Santiago - Chile
Instituto Profesional DuocUC
Escuela de Ingeniería
Oracle Database Security

2
Objetivos
Después de completar esta lección, usted deberá
saber lo siguiente:
• Aplicar El Principio del Menor Privilegio
• Administrar cuentas por defecto
• Implementar características de seguridad
estandares
• Auditar la actividad de una base de datos

3
Seguridad de Base de Datos
Un sistema seguro, garantiza la confidencialidad de
los datos que contiene. Hay varios aspectos de
seguridad a considerar:
• Acceso restringido a datos y servicios
• Autentificación de usuarios
• Monitoreo de actividades sospechosas
Seguridad de Base de Datos
Oracle Database 10g provee el mejor framework de la industria para un sistema
seguro, pero para que ese framework sea efectivo, el administrador de base de datos
debe seguir buenas prácticas y estar continuamente monitoreando la actividad de la
base de datos.
Restringiendo acceso a los Datos y Servicios
Todos los usuarios no pueden tener acceso a todos los datos. Dependiendo que está
almacenado en la base de datos, restringuir el acceso a ellos debe ser una regla
inquebrantable. Estas restricciones pueden ser por requerimientos del negocio, por
restricciones legales o espectativas del cliente. Información de tarjetas de crédito,
datos de salud, información de identidad, etc, deben ser protegidas para acceso no
autorizado. Oracle provee una gran gama de controles para limitar el acceso a una
base de datos. Restricción de acceso debe aplicar el “Principio del Menor Privilegio”.

4
Seguridad de Base de Datos (continuación)
Autentificación de usuarios
Para hacer cumplir los controles de acceso el sistema debe primero saber quién esta
tratando de accesar los datos. Una autentificación comprometida puede hacer el
resto de las otras precauciones de seguridad, inútiles. La manera mas simple de
autentificar un usuario es a través del método de que este provee una password. Es
preciso asegurarse que las password sigan cientras reglas simples para incrementar
el nivel de seguridad de un sistema. Existen métodos de autentificación más robusta
que solicitan al usuario algo, por ejemplo un certificado PKI (Public Key
Infrastructure). Otro método de autentificación fuerte es utilizar un dispositivo
biométrico como huella digital (fingerprint), lector de iris o diafragma (iris scan),
patrones de la estructura del hueso (bone structure pattern), otros. Oracle soporta
técnicas avanzadas de autentificación tales como token, biometría, certificados
digitales y certificados basados a través de la opción Advanced Security del RDBMS.
Las cuentas de usuario que no están en uso, deben ser bloqueadas pues
comprometen la seguridad del sistema.
Monitoreo para actividades sospechosas
Usuario debidamente autentificados y autorizados algunas veces pueden
comprometer la seguridad del sistema. Identificar actividades irregulares como un
empleado que repentinamente comience a consultar grandes cantidades de
información de tarjetas de créditos u otra información sensible en una empresa,
puede ser el primer paso para detectar el hurto de información. Oracle provee un rico
juego de herramientas de auditoria para seguir la pista a usuarios e identificar
actividades sospechosas.

5
Aplicando el Principio del Menor Privilegio
• Proteger el diccionario de datos
• Revocar privilegios PUBLIC innecesarios
• Restringir acceso a directorios a usuarios
• Limitar a los usuarios con privilegio de administrador
• Restringir autentificación de bases de datos remotas
Aplicando el Principio del Menor Privilegio
Oracle Database 10g es líder en la industria en seguridad. Sin embargo, para maximizar las
características de seguridad ofrecidas en cualquier ambiente de negocios, es imperativo que
Oracle Database 10g a si mismo sea protegido y adecuadamente configurado.
El uso adecuado de las características de seguridad internas y buenas prácticas de
seguridad ayudaran a proteger la base de datos de ataques y proveer un ambiente seguro
para operar.
Practica del Principio del Menor Privilegio
Este principio indica que un usuario solo debe tener los privilegios mínimos que sea
requeridos para completar una tareas eficientemente. Esto permite reducir la posibilidad que
usuarios accidentalmente o maliciosamente pueden modificar o ver datos para los cuales
ellos no tienen los privilegios respectivos.
La mayoria de la organizaciones de IT desean para sus ambientes de producción una
política cerrada o basada en la Política del Menor Privilegio.

6
Proteger el Diccionario de Datos
• Proteger el diccionario de datos, para asegurarse este
parámetro debe estar inicializado en FALSE:
• Esto previene que usuarios con privilegio de sistemas
ANY TABLE puedan accesar tablas del diccionario de
datos.
• Un seteo a FALSE previene que el usuario SYS se
logee de una manera difernte a SYSDBA
• El valor por defecto es FALSE. Si usted lo encuentra
seteado a TRUE, asegurese de tener una buena razón
de negocio para ello.
O7_DICTIONARY_ACCESSIBILITY = FALSE
Proteger el Diccionario de Datos
Usuarios que no son administradores no necesitan tener acceso al diccionario de datos, pero pueden
accederlo si se le otorgan privilegios de sistema * ANY TABLE tal como, SELECT ANY TABLE o
UPDATE ANY TABLE. EL diccionario de datos contiene información con la que un usuario malicioso
podría alterar o dañar el sistema. Para excluir las tables del diccionario de datos del privilegio * ANY
TABLE, el parámetro de inicialización O7_DICTIONARY_ACCESSIBILITY debe estar en FALSE.
Si existe un usuario no administrador que requiera por alguna razón, acceder al diccionario de datos,
se le puede otrogar acceso:
• Usando el comando estándar GRANT para permitir el objetivo específico del diccionario de
datos a accesar
• Otorgando un privilegio de sistema SELECT ANY DICTIONARY para dar acceso al diccionario
de datos completo
En Oracle 10g y Oracle 9i, el valor del parámetro O7_DICTIONARY_ACCESSIBILITY es FALSE; sin
embargo, en Oracle 8i e inferior, era TRUE; por lo tanto, si dispone de una versión más vieja es
preciso setear a FALSE dicho parámetro para habilitar la protección del diccionario de datos.
Precacución: Si este parámetro esta en TRUE, cualquier usuario con privilegio de sistema DROP
ANY TABLE podría maliciosamente o accidentalmente borrar parte del diccionario de datos de una
base de datos. Algunas instalaciones tienen por defecto todo habilitado y solo cierran accesos en
casos que se requieran. Esto es sencillamente una muy mala práctica que pone en riesgo la
seguridad de la información. Típicamente nos encontramos con este tipo de configuraciones en
ambientes de aprendizaje o académicos.

7
Revocar los Privilegios PUBLIC
innecesarios
• Revocar todos los privilegios y roles innecesarios de
la base de datos del grupo PUBLIC.
• Muchos packages construidos tienen otorgrados
EXECUTE TO PUBLIC.
• Execute sobre los siguientes package pueden ser
revocados desde PUBLIC:
– UTL_SMTP
– UTL_TCP
– UTL_HTTP
– UTL_FILE
– DBMS_OBFUSCATION_TOOLKIT
• Ejemplo:
SQL> REVOKE execute ON utl_file FROM PUBLIC;
Revocar los Privilegios PUBLIC innecesarios
Revoque todos aquellos privilegios y roles innecesarios asociados a los usuarios que sean
de acceso PUBLIC, ya que este tipo de grant son peligros.
Privilegios como EXECUTE sobre package PL/SQL podrían habilitar a un usuario a ejecutar
procedimientos que usted no desea realiza, por tanto, se deben otorgar los mínimos
privilegios para la acción que ellos requieren sobre la base de datos. Muchos de los
paquetes DBMS_* y UTL_* son instalados con el privilegio EXECUTE y grant PUBLIC.
Siguiendo el principio del mínimo privilegio, debe revocar esos permisos para algunos
paquetes mas sensitivos y otorgar permisos de ejecución individuales a usuarios que
requieran de dichos paquetes. Restringir el acceso a privilegios públicos afecta a todos los
usuarios..
Los paquetes mas poderosos que pueden ser mal utilizados son:
• UTL_SMTP: Permite enviar mensajes vía mail usando la base de datos como Servidor
de Correo SMTP (Simple Mail Transfer Protocol). Dejar este procedimiento con grant
PUBLIC permitiría a un usuario no autorizado intercambiar mensajes de mail.
• UTL_TCP: Permite establecer conexiones de red entre el servidor de base de datos y
cualquier otro servicio de red. Asi, datos arbitrariamente pueden ser enviados entre el
servidor de base de datos y cualquier servicio de red de espera..

8
Revoke Unnecessary Privileges from PUBLIC (continued)
• UTL_HTTP: Permite que el servidor de base de datos solicite y recupere datos
via HTTP (HyperText Transfer Protocol). Otorgando un gran PUBLIC a este
paquete, permite enviar datos en formularios HTML (HyperText Markup
Language) a sitios web maliciosos.
• UTL_FILE: Si esta configurado incorrectamente, permite acceso a nivel de texto
a cualquier archivo del sistema operativo del servidor. A menudo, cuando esta
correctamente configurado, este paquete no distingue entre llamadas de
aplicaciones. Una aplicación con acceso a UTL_FILE puede escribir datos
arbitrariamente dentro de la misma localización que es escrita por otra
aplicación.
• DBMS_OBFUSCATION_TOOLKIT: Encripta datos. Generalmente, la mayoria
de los usuarios no tiene privilegios para encriptar datos porque la encriptación
de datos no es recuperable si los datos cifrados no son almacenados y
administrados con seguridad.
Este es un paquete muy útil para aplicaciones que lo utilizan, pero requiere una
adecuada configuración para ser usado en forma segura. Por tanto, es
absolutamente necesario revocar los grant PUBLIC y otorgarlo solo a aquellos
usuarios o roles cuando lo requieran.
Listando Objetos Ejecutables Públicos
Use la siguiente consulta para listar los objetos propiedad del usuario SYS que tiene
privilegio de EXECUTE con grant PUBLIC:
SQL> SELECT table_name
2 FROM dba_tab_privs
3 WHERE owner='SYS'
4 AND privilege = 'EXECUTE'
5 AND grantee='PUBLIC'
6 /
TABLE_NAME
--------------------
AGGXMLIMP
AGGXMLINPUTTYPE
...
XMLTYPEEXTRA
XMLTYPEPI
437 rows selected.
SQL>

9
Restringiendo Acceso a Directorios del
Sistema Operativos a Usuarios
Parámetro de configuración UTL_FILE_DIR:
• Indica cuáles directorios del SO estan disponibles
para PL/SQL
• Habilita a usuarios de bases de datos a leer y escribir
desde diretorios sobre el servidor de bases de datos
Restringiendo Acceso a Directorios del Sistema Operativo a Usuarios
El parámetro de configuración UTL_FILE_DIR indica en cual directorio del sistema operativo
paquetes PL/SQL pueden leer o escribir. Por defecto, no hay directorios accesibles.
Los privilegios del sistema operativo siguen aplicables. Los directorios que el usuario levanto
en la base de datos solo pueden ser accesibles hasta que no se setee UTL_FILE_DIR.
Para especificar múltiples directorios, el listado de directorios debe estar entre comillas y
separado por comas (como se indica abajo). Este no es un parámetro dinámico y la instancia
debe ser reiniciada para que los cambios tengan efecto. Recuerde no usar variables de
ambiente en el path del directorio. La instancia no chequea que existan los directorios, por
tanto, debe cambiar el parámetro o crear el directorio posteriormente.
Todos los usuarios de PL/SQL pueden leer o escribir en los directorios especificados, todos
los usuarios de PL/SQL deben confiar con la información en los directorios especificados por
este parámtro.
Los directorios listados deben también ser accesibles por la instancia Oracle.
Precaución: Nunca setee UTL_FILE_DIR = *, porque esto habilita acceso a todos los
directorios accesible por la instancia Oracle, incluyendo a los directorios de datos y redo log.

10
Limitar Usuarios con Privilegios
Administrativos
• Restringir los siguientes tipos de privilegios:
– Grants de privilegios de sistema y objetos
– Conexiones privilegiadas, SYSDBA y SYSOPER
– Privilegios tipo DBA, tales como DROP ANY TABLE
– Permisos de tiempo de ejecución
• Ejemplo: Listar todos los usuarios con rol DBA:
SQL> SELECT grantee FROM dba_role_privs
2 WHERE granted_role = 'DBA';
GRANTEE
------------------------------
SYS
SYSTEM
Limitar Usuarios con Privilegios Administrativos
No otorge a usuarios de bases de datos mas privilegios que los necesarios. Al
implementar el Principio del Mínimo Privilegio, restringir los siguientes tipos de
privilegios:
• Gran a privilegios de Sistemas y Objetos
• Conexiones privilegiadas SYS, tales como SYSDBA y SYSOPER
• Otros privilegios de tipo DBA, tales como DROP ANY TABLE
Es importante determinar muy bien qué privilegios necesita cada usuario o grupo de
estos, para otorgar sólo aquellos que son necesarios a su función dentro de la base
de datos.
Ver los usuarios que les han sido otorgados los privilegios de SYSDBA o SYSOPER,
use la siguiente consulta:
SQL> SELECT * FROM V$PWFILE_USERS;
USERNAME SYSDBA SYSOPER
------------------------------ ------ -------
SYS TRUE TRUE
Hay muy pocas razones para que algún usuario que no sea SYS tenga privilegios de
SYSDBA.

11
Deshabilitar Autentificación Remota de
Sistema Operativo
• Autentificación remota debe ser solo usada cuando se
confia en todos los clientes para autentificar a los
usuarios
• Proceso de Autentificación Remota:
– El usuario de base de datos es autentificado
externamente.
– El sistema remoto autentifica al usuario.
– El usuario ingresa a la base de datos sin
autentificaciones adicionales.
• Para deshabilitar, asegurese que el siguiente
parámetro de inicialización esta seteado por defecto
como sigue:
REMOTE_OS_AUTHENT = FALSE
Deshabilitar Autentificación Remota de Sistema Operativo
Esta característica esta deshabilitada por defecto. Cuando se habilita (TRUE), la
autentificación externa de usuarios de base de datos, esta se delega al sistema
remoto. Esto significa que la instancia confía implícitamente que los usuarios han
sido autentificados adecuadamente en el cliente PC y no solicita una nueva
credencial de autentificación. Los usuarios pueden conectarse a la base de datos sin
proveer una password. El username del sistema operativo debe ser el mismo que el
de la base de datos para poder ser autentificado externamente.
La mayoría de los sistemas operativos remotos, especialmente las conexsiones de usuarios
desde PC’s, no debería ejecutar autentificación confiando en ellos. Estos es una pobre practica
de seguridad que debería modificarse.

12
Administrar Cuentas de Usuarios por
Defecto
• DBCA expira y
bloquea todas las
cuentes excepto:
– SYS
– SYSTEM
– SYSMAN
– DBSNMP
• Para una base de
datos creada
manualmente,
bloquee y experire
las cuentas no
utilizadas.
Administrar Cuentas de Usuario por Defecto
Oracle Database 10g se instala con un número de cuentas de usuarios por defecto. Estas
cuentas estan pensadas para almacenar datos, PL/SQL propio, Código de Objetos Java con
el propósito de no permitir conexiones a la base de datos. Cuando el DBCA es usado para
crear una base de datos, automáticamente bloquea y expira todas las cuentas por defecto de
usuarios de la base de datos, excepto las siguientes:
• SYS
• SYSTEM
• DBSNMP
• SYSMAN
Oracle soporta la creación de base de datos a través de scripts. Muchas aplicaciones
esperan que la base de datos este configurada de cierta manera y se automatiza la creación
a través de un script. Las bases de datos creadas de este forma, no bloquean las cuentas
por defecto. Valide que las cuentas no bloqueadas estan siendo usadas por conexiones a la
base de datos y no simplemente para almacenar datos.

13
Usuario
Expiración y
Envejecimiento de
Password
Verificación
de
Password
Seteo de
Perfiles
Implementar Características Estandares
de Seguridad de Password
Historial
de
Password
Cuentas
Bloquedas
Implementando Características Estandares de Seguridad de Password
La administración de password Oracle esta implementada con perfiles de usuarios.
Los perfiles proveen muchas características de seguridad incluyendo:
• Account locking: Habilita el bloqueo automático de cuentas cuando el usuario falla un número
especificado de intentos al momento de logearse al sistema.
• Password aging and expiration: Habilita a la password de usuario a tener un tiempo de
activación o duración, después de dicho periodo la password expira y debe ser cambiada.
• Password history: Chequea la nuevas nueva password y verifica que no sean reusadas en un
periodo de tiempo o un número específico de password a retener.
• Password complexity verification: Hace un chequeo de la complejidad de la password y verifica
que reuna ciertas características. El chequeo permite que las password sean lo suficientemente
complejas para proveer protección de intrusos que puedan querer acceder al sistema.
Recuerde que cuando se crea un nuevo usuario a ellos se les asigna el perfil DEFAULT a menos que
otro perfil les sea asignado.

14
Bloqueo de Cuentas
Número de días que la cuenta esta
bloqueda despues que el número
de intentos fallidos se ha superado
PASSWORD_LOCK_TIME
Número de intents fallidos de
conexión antes de bloquearse la
cuenta
FAILED_LOGIN_ATTEMPTS
DescripciónParámetro
Bloqueo de Cuentas
Oracle bloquea automáticamente cuentas después que el usuario ha fallado su logeo en el valor
señalado en FAILED_LOGIN_ATTEMPTS. La cuenta es automáticamente desbloqueada después de
un instante de tiempo señalado en el valor PASSWORD_LOCK_TIME o bien, desbloqueda por el
Administrador usando el comando ALTER USER.
La cuenta de usuario puede ser explícitamente bloqueada con el comando ALTER USER o con
Enterprise Manager. Cuando esto sucede, la cuenta no es automáticamente desbloqueda despues del
tiempo indicado en PASSWORD_LOCK_TIME, pero tanto, debe ser manual desbloqueda por el DBA.
SQL> ALTER USER hr ACCOUNT LOCK;
User altered.
SQL> CONNECT hr/hr
ERROR: ORA-28000: the account is locked
Warning: You are no longer connected to ORACLE.
SQL> CONNECT / as sysdba
Connected.
SQL> ALTER USER hr ACCOUNT UNLOCK;
User altered.

15
Expiración y Envejecimiento de Password
Periodo de gracia en días para
cambiar la password después del
primer intento de sesión y después
que la password ha expirado
PASSWORD_GRACE_TIME
Tiempo de validez de la password en
días después de ello, la password
expira
PASSWORD_LIFE_TIME
DescripciónParámetero
Expiración y Envejecimiento de Password
El administrador de la base de datos puede especificar un periodo de gracia
PASSWORD_GRACE_TIME, el que comienza después del primer intento de sesión después que la
password a expirado. Se despliega un mensaje de advertencia cada vez que el usuario intenta
logearse hasta que el periodo de gracia vence. Si un usuario no cambia la password dentro del periodo
de gracia, su cuenta queda bloqueada.
Nota: Si la cuenta es una cuenta de aplicación (no accesible a traves de SQL*Plus), vefrificar que la
aplicación esta habilitada para cambiar password antes de habilitar expiración de password. Muchos
DBAs asignan perfiles separados a cuentas de usuarios de aplicaciones.
Una cuenta de usuario puede ser expirada manualmente seteando la password a expirada.
SQL> ALTER USER hr PASSWORD EXPIRE;
User altered.
SQL> CONNECT hr/hr
ERROR: ORA-28001: the password has expired
Changing password for hr
New password: ********
Retype new password: ********
Password changed

16
Historial de Password
Número de password modificadas
requeridas antes que la actual
password pueda ser reusada
PASSWORD_REUSE_MAX
Número de dias antes que la
password pueda ser reusada
PASSWORD_REUSE_TIME
Historial de Password
El Historial de Password se asegura que un usuario no pueda reusar una password
después de un intervalo de tiempo. Estos chequeos pueden ser implementados
usando uno de los siguientes valores:
• PASSWORD_REUSE_TIME: Especifica que el usuario no puede reusar una
password hasta el número de días indicado.
• PASSWORD_REUSE_MAX: Específica el número de password modificadas
antes que la password actual pueda ser reutilizada.
Estos dos parámetros son mutuamente excluyentes, cuando un parámetro se setea a
un valor el otro se setea a UNLIMITED (o DEFAULT si el perfil tiene seteado el valor
UNLIMITED).

17
Verificación de Password
La funcion de verificación de password debe:
• Ser propiedad del usuario SYS
• Retornar un valor Boolean (true o false)
Una función PL/SQL que asegura
la complejidad de la password es
chequeada antes de ser asignada
PASSWORD_VERIFY_
FUNCTION
Verificación de Password
Antes de asignar una nueva password al usuario, una función PL/SQL puede ser
invocada para verificar la validez de la password.
Oracle provee una rutina de verificación por defecto que puede ser cargada
ejecutando un script SQL localizado en $ORACLE_HOME/rdbms/admin/utlpwdmg.sql
o el DBA puede escribir una función PL/SQL personalizada que reuna los
requerimientos de seguridad necesarios.
Además de las restricciones listadas en la diapositiva, funciones de verificación de
password deben seguir las siguientes especificaciones para declarar variables de
entrada:
function_name(userid_parameter IN VARCHAR2,
password_parameter IN VARCHAR2,
old_password_parameter IN VARCHAR2)
RETURN BOOLEAN
Si la función de password levanta una excepción o llega a ser inválida, un mensaje
de error es retornado cuando el comando ALTER USER o CREATE USER es
finalizado.

18
Función Provista para Verificación de
Password: VERIFY_FUNCTION
La función provista para la verificación de
password, fuerza restricciones donde el:
• Minimo largo es 4 caracteres
• Password no puede ser igual al nombre del usuario
• Password debe tener al menos un alfabético, un
número y un caracter especial
• Password debe diferir de las 3 passsword previas en
al menos 3 letras
Función Provista para Verificación de Password: VERIFY_FUNCTION
Oracle provee una función de verificación de complejidad de password llamada
VERIFY_FUNCTION. Esta función es creada con el script
$ORACLE_HOME/rdbms/admin/utlpwdmg.sql. Esta función debe ser creado con el
esquema SYS.
Además de crear VERIFY_FUNCTION, con el script utlpwdmg también debe
cambiar el perfil DEFAULT con el siguiente comando ALTER PROFILE:
ALTER PROFILE default LIMIT
PASSWORD_LIFE_TIME 60
PASSWORD_GRACE_TIME 10
PASSWORD_REUSE_TIME 1800
PASSWORD_REUSE_MAX UNLIMITED
FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME 1/1440
PASSWORD_VERIFY_FUNCTION verify_function;

19
Creando un Perfil de Password
Creando un Perfil de Password
Para crear un perfil de password, abra Enterprise Manager y navege hasta la página
Administration. Seleccione Profile y haga click en el botón Create.
Valores comúnes para cada configuración pueden seleccionarse desde un listado de
valores (icono linterna) o bien se ingresa el valor deseado.
Todos los períodos de tiempo están expresados en días, pero pueden ser
expresados como fracciones. Hay 1440 minutos en un día, así 5/1440 son 5 minutos.
Borrando Perfiles de Password
Si desea eliminar un perfil, todos los usuarios asignados a ese perfil seran
automáticamente asignados al perfil por defecto.

20
Asignando Usuarios a un Perfil de
Password
Asignando Usuarios a un Perfil de Password
Para asignar un usuario a un perfile de password:
1. Abra Enterprise Manager y navege a la página Administration.
2. Seleccione Users. Seleccione el usuario que dese asignar a un perfil y haga
click en el botón Edit.
3. Desde el listado drop-down en profile, seleccione el perfil que desea aplicar al
usuario y haga click en el botón Apply.
Recuerde que un usuario puede solo tener asignado un perfil a la vez. Si un usuario
esta logeado cuando se realiza un cambio en su perfil, los cambios no tienen efecto
en este usuario hasta la siguiente sesión.
La cuenta de usuario puede también ser bloqueada o expirada desde la pagina Edit
User.

21
Monitoreando Actividades Sospechosas
Monitorear o auditar debe ser parte integral de los
procedimientos de seguridad.
Oracle incluye las siguientes herramientas para
auditar:
• Auditoria estándar de base de datos
• Auditoria basada en valor
• Auditoria fina (Fine-grained auditing (FGA))
Monitoreo para actividades sospechosas
Oracle Database 10g provee 3 tipos diferentes de auditoria. El administrador puede auditar todas las
acciones que tienen lugar dentro de una base de datos. Es importante recordar que la captura y
registro de información sobre que esta aconteciendo en el sistema puede aumentar la carga de trabajo
sobre el servidor. La auditoria puede ser focalizada sólo en aquellos eventos que nos interesa capturar
o monitorear. De modo que la auditoria tenga el mínimo impacto en la performance del sistema. De
cualquier otro modo, el impacto sobre el rendimiento del sistema es muy significativo.
La auditoria estándar captura varias piezas de información acerca de eventos auditables, cuándo
ocurrio el evento, qué usuario lo causo y cuál en máquina cliente estaba el usuario cuando sucedio el
evento.
La auditoria basada en valor, audita los cambios sobre los datos (insert, delete, update). Es una
extensión a la auditoria estándar de base de datos, capturando no solo los eventos auditables cuando
ocurren, sino también los valores que fueron insertados, borrados o modificados. La auditoria basada
en valor se implementa a traves de triggers de base de datos.
Auditoria fina (Fine-Grained Auditing (FGA)), audita sentencias SQL. FGA es una extensión a la
auditoria estándar de base de datos, capturando la sentencia SQL actual que ha sido ejecutada.

22
Comparación de Herramientas de
Auditoria
Conjunto fijo de
Datos incluyendo
sentencias SQL
Sentencias SQL (insert,
update, delete, y select)
basadas sobre el
contenido
De Granja Fina
Definidas por el
Administrador
Datos cambiados por
sentencias DML
Basada en valores
Conjunto Fijo de
Datos
Uso de Privilegios
incluyendo acceso a
Objetos
Estándar
¿Qué registra?¿Qué es auditado?Tipo de Auditoria

23
Auditoria Estándar de Base de Datos
Habilitada a través del parámetro AUDIT_TRAIL
• NONE: Deshabilita la recolección de registros
auditables
• DB: Habilita la auditoria con registros almacenados en
la base de datos
• OS: Habilita la auditoria con registros almacenados en
el sistema operativo
Se puede auditar:
• Eventos de Login
• Exercise of system privileges
• Exercise of object privileges
• Uso de sentencias SQL
Antes de usar la auditoria es preciso setear primeramente el parámetro
AUDIT_TRAIL que indica la localización en el sistema operativo donde se
almacenaran los registros de auditoria. El seteo normal de este parámetro es DB, lo
que indica que los registros auditables seran almacenados en la tabla
DBA_AUDIT_TRIAL.
La auditoria puede capturar información sobre eventos de logins, ejecución de
privilegios de sistemas y ejecución de privilegios de objetos. La información de
auditoria puede focalizarse en el evento generado por el usuario o en el estado del
evento (exitóso o no). El siguiente comando genera información de auditoria pero
esta mal focalizado. Esta opción captura cualquier operación que afecte a cualquier
tabla:
SQL> AUDIT TABLE;
Audit succeeded.
Un mejor ejemplo de un comando de auditoria es (ya esta mas focalizado) :
SQL> AUDIT DELETE ON hr.employees WHENEVER SUCCESSFUL;
Audit succeeded.

24
Opciones específicas auditables
AUDIT select any table, create any trigger;
AUDIT select any table BY hr BY SESSION;
AUDIT table;
AUDIT ALL on hr.employees;
AUDIT UPDATE,DELETE on hr.employees BY ACCESS;
AUDIT session whenever not successful;
Auditando sentencias SQL
Auditando privilegios de sistema (focalizado o no focalizado)
Auditando privilegios de objetos (focalizado o no focalizado)
Auditando sesiones
Opciones específicas auditables
Auditando sentencias SQL: La sentencia mostrada en la figura auditara cualquier sentencia que
afecte a una tabla incluyendo CREATE TABLE, DROP TABLE, TRUNCATE TABLE, etc. Las
auditorias sobre sentencias SQL pueden ser focalizadas al usuario o al estado (éxito o fracaso de la
sentencia).
SQL> AUDIT TABLE BY hr WHENEVER NOT SUCCESSFUL;
Auditar el sistema de privilegios puede ser usado para chequear la ejecución de cualquier privilegio del
sistema, por ejemplo, DROP ANY TABLE. La auditoria se puede focalizar por usuario o éxito o fracaso
de la acción. Por defecto, cada vez que se ejecuta un privilegio de sistema un registro de auditoria es
ejecutado. Es posible agrupar esos eventos para que solo se registre uno por sesión (de esta forma si
hay 100,000 actualizaciones de registro en una tabla que realiza un usuario, por tanto solo se registra
un evento de auditoria). Si la cláusula BY SESSION no especificada, el valor por defecto es BY
ACCESS. Considere usar la cláusula BY SESSION para limitar el registro de eventos de auditoria y no
afectar el rendimiento del sistema.
Auditoria de objetos puede ser usada para auditar acciones sobre tablas, vistas, procedimientos,
secuencias, directorios, etc. Este tipo de auditorias puede enfocarse por éxito o fracaso y agruparse
por sesión o acceso. Semejante a la auditoria de privilegios de sistema, el valor por defecto de
agrupamiento es por sesión, por tanto, implícitamente debe indicarse BY ACCESS si se desea separar
el registro de auditoria generada por cada acción.

25
Especificando opciones de auditoria (Continuación)
La opción AUDIT SESSION audita la creación de sesiones de usuario. Puede
focalizarse la auditoria por usuario o éxito/fracaso. Esta opción es única ya que
genera un registro de auditoria por cada sesión que se conecta a la base de datos.
Un registro de auditoria es insertado en el registro de auditoria al momento de
conexión y modificado al momento de desconectarse. La información acumulada
sobre una sesión como el tiempo de conexión, tiempo de desconexión, I/O lógicos y
físicos procesados y mucho mas, son almacenados en un simple registro de auditoria
que corresponde a la sesión. En muchas bases de datos es común usar el comando
AUDIT SESSION (no focalizado). En la mayoria de las bases de datos se debe
configurar AUDIT SESSION WHENEVER NOT SUCCESSFUL porque permite
detectar intentos indebidos de acceso a la base de datos.
Nota: A menudo las opciones comienzan como no focalizadas porque no se tiene
certeza que actividad debemos monitorear. La opción AUDIT ALL un “atajo”
conveniente para auditar uma amplia gama de actividades en la base de datos.
Si la opción AUDIT ALL es usado con un username:
SQL> AUDIT ALL BY hr;
El usuario tendrá sentencias DDL auditables para los siguientes objetos:
UpdateSelectRenameRead
LockInsertIndexGrant
DeleteCommentAuditAlter
ViewUser
TypeTriggerTablespaceTable
System GrantSystem AuditSynonymSequence
Rollback SegmentRolePublic SynonymPublic Database Link
ProfileProcedureNot ExistsMaterialized View
IndexDirectoryDimensionDatabase Link
Create SessionContextClusterAlter System

26
Viendo Opciones de Auditoria
Opciones Auditoria Objetos
del Esquema
DBA_OBJ_AUDIT_OPTS
Opciones Auditoria de
Privilegios
DBA_PRIV_AUDIT_OPTS
Opciones de auditoria de
Sentencias
DBA_STMT_AUDIT_OPTS
Opciones por DefectoALL_DEF_AUDIT_OPTS
DescripciónVista Diccionario de Datos
Viendo Opciones de Auditoria
Para ver que opciones de auditoria se han seleccionado, liste las vistas mencionadas a
continuación.
DBA_STMT_AUDIT_OPTS y DBA_PRIV_AUDIT_OPTS contienen solo registros de
sentencias y opciones de auditoria de privilegios que se han especificado.
DBA_OBJ_AUDIT_OPTS contiene un registro por objeto auditable sin importar que opciones
se han. La vista muestra una columna para cada opción auditable. Por ejemplo, opciones de
auditoria para INSERT son mostradas en la columna INS.
Opciones de auditoria son desplegadas como SUCCESSFUL/NOT SUCCESSFUL con 3
posibles valores para cada estado:
• - Not audited
• S Collect audit records by session
• A Collect audit records by access
SQL> SELECT object_name, object_type, ins, upd
FROM dba_obj_audit_opts WHERE object_name = 'EMPLOYEES‘
OBJECT_NAME OBJECT_TY INS UPD
------------ --------- --- ---
EMPLOYEES TABLE A/S -/-

27
Registros
Auditoria
Archivo de
Parámetros
Especificar opciones auditoria
Generar
Registro Auditoria
Revisar Información Auditoria
DBA Usuario
Habilitar Auditoria
de Base de Datos
Ejecutar
Comandos
Database
Registrar
Auditoria
SO
Opciones
Auditoria
Server
process
Después que el administrador a habilitado la auditoria (con el parámetro AUDIT_TRAIL) y
especificado sus opciones (con sentencias SQL como se mostro en páginas previas), la base
de datos comienza a recolectar información de auditoria.
Si AUDIT_TRAIL esta setea al Sistema Operativo, los registros de auditoria serán
registrados en el sistema operativo en archivos. En un ambiente Windows, esto es un evento
de log. En ambientes UNIX, los registros son almacenados en un archivo. La localización de
este archivo esta especificado con el parámetro AUDIT_FILE_DEST. Asumiendo que
AUDIT_TRAIL está setea a DB, los registros auditables son almacenados en una tabla que
es parte del esquema SYS.
El mantenimiento de los registros de auditoria es una tarea administrativa importante que
debe ejecutar el DBA. Dependiendo den la focalización de la auditoria, la cantidad de
información a registrar podría crecer enormemente de forma muy rápida. Sino se mantiene
adecuadamente el registro de auditorias, esto puedo consumir mucho espacio de
almacenamiento y puede afectar el rendimiento del sistema.

28
Vistas Auditables
DBA_AUDIT_TRAIL
DBA_AUDIT_EXISTS
DBA_AUDIT_OBJECT
DBA_AUDIT_SESSION
DBA_AUDIT_STATEMENT
Descripción
Audita todas las entradas
Registros para AUDIT EXISTS/NOT
EXISTS
Registros objetos del esquema
Conexiones y desconexiones
Sentencias Auditables
Viendo Resultados Auditables
Viendo Resultados Auditables
El acceso a los registros auditables debe ser controlado rigurosamente pues puede
contener información sensitiva para el negocio de la empresa. Usualmente la tarea
de administrar los registros auditables es llevada por el DBA pero si necesita ser
delegada se deben otorgar grant a DELETE_CATALOG_ROLE para borrar
información.

29
Auditoria basada en Valores
Cambios de
Usuario
Confirmados
Dispara Triggers Registro Auditoria es
creado por Trigger
E Insertado en
una tabla de
auditoria
Cambios hechos
por Usuario
Auditoria Basada en Valores
Los registros de auditoria de base de datos que hacen insert y delete sobre objetos
auditables, no capturan los valores reales que fueron cambiados o insertados. La
auditoria basada en valores es una extensión de la auditoria estándar y capturan los
valores actuales que han sido modificados. Se activan disparadores (triggers)
construidos en PL/SQL. Cuando un usuario inserta, modifica o elimina datos desde
una tabla con el adecuado trigger asociado, el trigger trabaja en background y copia
la información a una tabla diseñada para contener información de auditoria. La
auditoria basada en valores, tiende a degradar más el rendimiento que la auditoria
estándar, porque el código del trigger debe ejecutarse cada vez que ocurre una
operación de insert, delete o update. La degradación dependerá mucho del la
eficiencia del código PL/SQL del trigger. Este tipo de auditorias solo debe ser usada
en situación donde la información capturada por la auditoria estándar de base de
datos es insuficiente.

30
Auditoria basada en Valores (continuación)
La clave de la auditoría basada en valores es el trigger auditable. A continuación un
ejemplo:
CREATE OR REPLACE TRIGGER system.hrsalary_audit
AFTER UPDATE OF salary
ON hr.employees
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
IF :old.salary != :new.salary THEN
INSERT INTO system.audit_employees
VALUES (sys_context('userenv','os_user'), sysdate,
sys_context('userenv','ip_address'),
:new.employee_id ||' salary changed from '||:old.salary||
' to '||:new.salary);
END IF;
END;
/
Este trigger se focaliza en auditar y capturar los cambios sobre la columna salary de
la tabla hr.employees. Cuando una fila es modificada, el trigger verifica la columna
salary. Si el salario anterior no es igual al nuevo valor, entonces el trigger inserta un
registro de auditoria en la tabla audit_employees (tabla creada en el esquema
SYSTEM). El regitro de auditoria incluirá username, IP address desde donde se hace
el cambio, la clave primaria que identifica el registro modificado y el actual salario que
se ha modificado.
Los triggers de base de datos puede ser usados también para capturar información
de conexiones de usuarios en casos donde la auditoria estándar no entrege los datos
suficientes. Con trigger de logon, el DBA puede capturar:
- IP address de la persona que se conecta
- Los primeros 48 caracteres del programa usado para conectarse a la instancia
- Nombre del terminal usado para conectarse a la instancia

31
31
Auditoria Fina (FGA)
• Monitoreo de acceso a datos sobre contexto
• Audita SELECT or INSERT,UPDATE,DELETE
• Puede ser linqueado a tabla o vista
• Puede disparar un procedimiento
• Es gestionado con el paquete DBMS_FGA
employees
Policy: AUDIT_EMPS_SALARY
SELECT name, salary
FROM employees
WHERE
department_id = 10;
Auditoria Fina - Fine-Grained Auditing (FGA)
Los registros de auditoria de base de datos registran que una operación ha sucedido pero no capturan
la información de la sentencia SQL que genero la operación.. La auditoria fina es una extensión que
tiene la capacidad de capturan la sentencia SQL que consulta o manipula datos. FGA permite también
auditar mas detalladamente que la auditoria estándar o la auditoria basada en valores.
Las opciones de auditoria fina puede focalizarse por columnas individuales dentr de una tabla o vista y
a menudo puede ser condicionada a que los registros auditables sean capaturados solo si se reunen
ciertas especificaciones indicadas por el administrador o DBA.
A diferencia de la auditoria basada en valores, FGA no requiere del uso de triggers y el impacto en el
rendimiento es similar a la auditoria estándar.
El administrador usa el paquete DBMS_FGA PL/SQL para crear una política de auditoria sobre una
tabla o vista. Si alguna de las filas retornadas de una consulta complete la condición establecida en la
auditoria y afecta a la columna auditable, entonces se genera un registro y se almacena dicha
información. Opcionalmente dicho evento puede ejecutar un procedimiento almacenado. FGA
automáticamente focaliza la auditoria a sentencias SELECT, en aquellas que retornan cientos de filas
se genera solo un registro auditable.

32
32
Politica FGA
dbms_fga.add_policy (
object_schema => 'hr',
object_name => 'employees',
policy_name => 'audit_emps_salary',
audit_condition=> 'dept_id=10',
audit_column => 'salary',
handler_schema => 'secure',
handler_module => 'log_emps_salary',
enable => TRUE,
statement_types=> 'select' );
SELECT name, job_id
FROM employees;
SELECT name, salary
FROM employees
WHERE
department_id = 10;
SECURE.LOG_
EMPS_SALARY
employees
• Define:
– Criterio Auditoria
– Acción Auditoria
• Es creado con
DBMS_FGA
.ADD_POLICY
Política FGA
El ejemplo de la figura muestra una Política FGA creada con el procedimiento
DBMS_FGA.ADD_POLICY. El procedimiento acepta los siguientes argumentos:
Policy Name
Usted asigna un nombre a cada vez que crea una Política FGA. El ejemplo muestra
el nombre AUDIT_EMPS_SALARY, usando los siguientes argumentos:
policy_name => 'audit_emps_salary'
Audit Condition
La condición de auditoria es el predicado de SQL que define cuando el evento de
auditoria debe ser disparado o llamado. En el ejemplo, todas las filas en las ventas
de departamentos están auditadas,usando el siguiente argumento en la condición:
audit_condition => 'department_id = 10'
Statement Type
¿Cuál tipo de sentencia será auditada? Se puede auditar sentencias SELECT y
(todas en un solo string) INSERT,UPDATE,DELETE.

33
Política FGA (continuación)
Audit Column
La columna auditable define el dato que esta siendo auditado para dicha tabla. Un evento auditable
ocurre solo si la columna es incluida en la cláusula SELECT. En el ejemplo es la columna SALARY,
usando los siguientes argumentos:
audit_column => 'salary'
Este argumento es opcional. Sino se especifica, entonces el argumento AUDIT_CONDITION
determina cuando ocurre un evento a auditar.
Object
El objeto es la tabla o vista que esta siendo auditada. Hay 2 argumentos passados:
• El esquema que contiene el objeto
• El nombre del objeto
En el ejemplo la tabla auditable hr.employees usando los siguientes argumentos:
object_schema => 'hr'
object_name => 'employees'
Handler
Es opcional y determina el procedimiento PL/SQL a ejecutar si se requieren acciones adicionales a
tomar cuando ocurra un evento auditable. Por ejemplo, el evento podría enviar una página de alerta al
administrador. Sino se define el manejador de eventos, entonces la entrada del evento es insertada en
el registro auditable. Si el manejador de eventos esta definido, entonces se inserta un registro en la
bitacora de auditoria y se ejecuta el manejador de eventos.
La entrada de auditoria incluye la política que causo el evento, el usuario que ejecuto la sentencia SQL
y la sentencia SQL y sus variables o parámetros que la componen.
El administrador de eventos es pasado como 2 argumentos:
• El esquema que contiene el programa PL/SQL
• El nomrbre del programa PL/SQL
El ejemplo ejecuta el procedimiento SECURE.LOG_EMPS_SALARY usando los siguientes
argumentos:
handler_schema => 'secure'
handler_module => 'log_emps_salary'
Status
El estado indica si la política FGA esta permitida o habilitada. En el ejemplo, los siguientes argumentos
estan habilitados para la política:
enable => TRUE

34
Paquete DBMS_FGA
• Use DBMS_FGA to maintain FGA policies
• Grant the execute privilege only to administrators
• Includes the following subprograms:
Deshabilita una políticaDISABLE_POLICY
Habilita una politicaENABLE_POLICY
Borra una políticaDROP_POLICY
Crea politica usando el predicado como
la condición de auditoria
ADD_POLICY
DescripciónSubprograma
Paquete DBMS_FGA
El paquete DBMS_FGA es la herramienta de administración para funciones de
auditoria fina. Privilegios de Execute sobre DBMS_FGA son necesarios para
administrar políticas de auditoria fina. Dado que este tipo de auditoria puede contener
información sensible para el negocio. Esos privilegios de execute sobre este package
deben estar reservados solo para el administrador o DBA.

35
Habilitando y Deshabilitando una Política FGA
• Habilitando una Política:
• Deshabilitando una Política:
dbms_fga.enable_policy (
policy_name => 'audit_emps_salary' );
dbms_fga.disable_policy (
policy_name => 'audit_emps_salary' );
Habilitando y Deshabilitando una Política FGA
Deshabilitar una política FGA significa que la política no generará eventos auditables.
Si desea que la política comience a registrar eventos, ustede deberá habilitarla
nuevamente. Por defecto la política queda habilitada al momento de la creación. En
el ejemplo se muestra como habilitar y deshabilitar una política. Para ambos
procedimientos, todos los argumentos son requeridos.

36
Borrando una Política FGA
SQL> EXEC dbms_fga.drop_policy ( -
> object_schema => 'hr', -
> object_name => 'employees', -
> policy_name => 'audit_emps_salary');
PL/SQL procedure successfully completed.
SQL>
Borrando una Política
Sino se desea seguir con una política, usted puede removerla con
DBMS_FGA.DROP_POLICY. Todos los argumentos son requeridos.

37
37
Disparando Eventos Auditables
• La siguiente sentencia SQL causa una auditoria:
• La siguiente sentencia no causa una auditoria:
SELECT count(*)
FROM hr.employees
WHERE department_id = 10
AND salary > v_salary;
SELECT salary
FROM hr.employees;
SELECT last_name
FROM hr.employees
WHERE department_id = 10;
Disparando Eventos Auditables
En general, la política de auditoria fina esta basada en columnas auditables y simpre predicados SQL
definidos por el usuario. Durante el análisis de las condiciones de la política reunidas para la condición,
la sentencia es auditada y si hay un evento a manejar, éste es disparado.
La función de auditoria es ejecutada como una transacción autónoma. Cada política de auditoria se
aplica individualmente. Es decir, mientras las filas estan siendo devueltas o modificadas, un registro de
auditoria será generado y habrá un registro de auditoria por cada política para sentencias SQL.
Ejemplos
Los dos primeros ejemplos de la figura, producen un evento auditable perque accesan la columna
salary y filas con department_id = 10. En el segundo ejemplo, Oracle se da cuenta que hay una política
asociada a la columna salary que accesan a las filas del departamento 10, a pesar que department_id
no es referenciado en la cláusila WHERE.
En el último ejemplo, no se produce una auditoria porque no se accesa la columna salary. Si la
columna salary no ha sido especificada como AUDIT_COLUMN cuando la política es creada, entonces
la sentencia SELECT produciría un evento auditable.

38
Vistas Diccionario de Datos
Todas las politicas FGA para
objetos en el esquema del usuario
actual
USER_AUDIT_POLICIES
Todas las politicas en la base de
datos
DBA_AUDIT_POLICIES
Todas las políticas FGA para
objetos accesados por el usuario
actual
ALL_AUDIT_POLICIES
Todos lso eventos FGADBA_FGA_AUDIT_TRAIL
DescripciónNombre de Vista
Vistas del Diccionario de datos
Las entradas auditables de FGA se registran en una tabla separada de las auditorias
de objetos y privilegios. Las entrada son registradas en la vista
DBA_FGA_AUDIT_TRAIL.
Hay otras 2 vistas que contienen definición de políticas: ALL_AUDIT_POLICIES,
DBA_AUDIT_POLICIES, USER_AUDIT_POLICIES.

39
DBA_FGA_AUDIT_TRAIL
SQL> SELECT to_char(timestamp, 'YYMMDDHH24MI')
2 AS timestamp,
3 db_user,
4 policy_name,
5 sql_bind,
6 sql_text
7 FROM dba_fga_audit_trail;
TIMESTAMP DB_USER POLICY_NAME SQL_BIND
---------- ------- ----------------- ----------
SQL_TEXT
-----------------------------------------------
0201221740 SYSTEM AUDIT_EMPS_SALARY #1(4):1000
SELECT count(*)
FROM hr.employees
AND salary > :b1
DBA_FGA_AUDIT_TRAIL
Nombre Descripción
TIMESTAMP Fecha y Hora de Ejecución
DB_USER Nombre del usuario de la base de datos
OS_USER Nombre del usuario del Sistema Operativo
OBJECT_SCHEMA Propietario del objeto auditable
OBJECT_NAME Nombre del objeto auditables
POLICY_NAME Nombre de la política que causo el evento auditable
SCN El SCN de la transacción
SQL_TEXT Sentencia SQL que causo el evento auditable
SQL_BIND Variable del evento auditable formateada como: #n(s):v:
Donde n es el número de la variable en la sentencia
s es el largo de la variabley v es el valor de la variable
COMMENT$TEXT Un comentario

40
DBA_FGA_AUDIT_TRAIL (continuación)
Seleccionando desde la Auditoria FGA
El siguiente ejemplo despliega 2 files de auditoria creadas para ejemplos válidos de páginas
anteriores. La columna sql_bind en la segunda fila tiene un valor de #1(4):1000, que incluye las
siguientes componentes:
#1 Indica que este es la primera variable de ambiente en la sentencia.
(4) Indica que la variable de ambiente tiene largo 4.
1000 indica que la variable de ambiente tiene valor 1000.
Ejemplo
Este ejemplo es similar al visto en la figura, a menos que también incluya una política para fila sin un
manejador de auditoria.
SQL> COL timestamp FORMAT A10
SQL> COL db_user FORMAT A7
SQL> COL policy_name FORMAT A20
SQL> COL sql_bind FORMAT A20
SQL> COL sql_text FORMAT A60
SQL>
SQL> SELECT to_char(timestamp, 'YYMMDDHH24MI')
2 AS timestamp,
3 db_user,
4 policy_name,
5 sql_bind,
6 sql_text
7 FROM dba_fga_audit_trail;
TIMESTAMP DB_USER POLICY_NAME SQL_BIND
---------- ------- -------------------- ------------------
SQL_TEXT
----------------------------------------------------------
0201221740 SYSTEM AUDIT_EMPS_SALARY #1(4):1000
SELECT count(*)
FROM hr.employees
AND salary > :b1
0201221741 SYSTEM AUDIT_EMPS_SALARY
SELECT salary
FROM hr.employees
SQL>

41
Pautas para FGA
• Para auditar todas las sentencias, use la condición
null.
• Si intenta agregar una política que ya existe,
aparecerá el error ORA-28101.
• Cuando se crea una política, la tabla o vista debe
existir.
• Si la sintáxis de la condición de auditoria es inválida,
un error ORA-28112 aparecerá cuando el objeto
auditado sea accesado.
• Si la columna auditable no existe en la tabla, las filas
no serán auditadas.
• Si el manejador de eventos no existe, no se devuelve
ningún error y los registros auditables son creados.
Pautas para FGA
Condición de Auditoria
Cuando se crea una nueva política FGA, la condición por defecto es null, lo que
significa que todas las sentencias sera auditadas.
Error en Nombre de Políticas
El nombre de la política debe ser único dentro de la base de datos. Las políticas no
tienen propietario. Si un nombre duplicado es usado, usted recibe un mensaje de
error cuando esta creando la política:
ORA-28101: policy already exists
Errores de Objetos Auditados
La tabla o vista auditada deben existir cuando se crea la política. Sino existe, usted
recibe un error como el siguiente:
ORA-00942: table or view does not exist

42
Pautas para FGA (continuación)
Errores de Condiciones Auditables
Si la sintáxis de la condición es inválida, la política se creará sin errores, pero el
siguiente mensaje aparece cuando el objeto es accesado:
ORA-28112: failed to execute policy function
Si la sintáxis de la condición es válida, pero es incorrecta, entonces las filas
incorrectas se auditan.
Errores de Columnas Auditables
Si la columna a auditar no existe en la tabla, entonces la política se creará, sin
embargo, no hay filas que serán auditadas porque la columna nunca será accesada.
Si la columna a auditar es válida, pero incorrecta, entonces las filas incorrectas serán
auditadas.
Errores de Manejador de Eventos (Event Handler)
Cuando la política hace referencia a un manejador de eventos que no existe, la
política se creará, sin embargo, no habrá filas retornadas cuando ocurra un evento
auditable.

43
Auditando Usuarios SYSDBA y SYSOPER
Usuarios con privilegios SYSDBA o SYSOPER privileges
pueden conectarse a una base de datos cerrada.
• El registro de auditoria debe ser almacenado fuera de
la BD (es decir, SO).
• Conexiones como SYSDBA o SYSOPER siempre deben
ser auditadas.
• Habilitar auditoria adicional de acciones de SYSDBA o
SYSOPER con audit_sys_operations.
• El control del registro de auditorias llevarlo con
audit_file_dest. Default es:
– $ORACLE_HOME/rdbms/audit (UNIX/Linux)
– Windows Event Log (Windows)
Auditando usuarios SYSDBA y SYSOPER
Los usuarios con privilegios SYSDBA y SYSOPER pueden subir y bajar una base de
datos. Debido a que pueden hacer cambios mientras una base de datos esta
cerrada, el registro de auditorias (bitácora) debe ser almacenado fuera de la base de
datos. Oracle captura los eventos de login automáticamente para usuarios SYSDBA
y SYSOPER, pero no captura nada más que el login a menos que este habilitada una
auditoria específica.
Habilitar la auditoria para usuarios SYSDBA y SYSOPER, se hace seteando un
parametro de inicialización:
audit_sys_operations=TRUE (default es FALSE)
Si las operaciones del usuario SYS son auditadas, el parámetro de inicialización
audit_file_dest indica dónde los regitros de esta bitácora serán almacenados. En
plataforma Windows quedan por defecto en el Windows Event Log. En plataformas
UNIX, os registros son almacenados en $ORACLE_HOME/rdbms/audit.

44
Actualizaciones de Seguridad
• Oracle coloca sus alertas de seguridad en su sitio web
Oracle Technology Network Web:
http://otn.oracle.com/deploy/security/alerts.htm
• Los administradores y desarrolladores Oracle puede
subscribirse para ser notificados sobre alertas críticas
de seguridad a través de mail haciendo Click en el
Link “Subscribe to Security Alerts Here”.
Actualizaciones de Seguridad
Las alertas de seguridad Oracle contienen una descripción de las vulnerabilidades,
riesgos posibles y grado de exposición asociado a la vulnerabilidad, aplicaciones
afectadas y los posibles parches de seguridad a aplicar.
Las alertas de seguridad son colocadas en el Sitio Web Oracle Technology Network y
en el sitio Web de OracleMetaLink (MetaLink). Aunque las alertas de seguridad son
de público conocimiento, solo los clientes registrados (Customer Support
Identification (CSI ))en Oracle puede accesar y bajar los parches de seguridad que
corrigen las falencias de seguridad.

Seguridad BD Oracle

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a Seguridad BD Oracle

Similar a Seguridad BD Oracle (20)

Más de victdiazm

Más de victdiazm (20)

Seguridad BD Oracle