Embed Size (px)
Citation preview
ORACLE IBÉRICA, S.R.L. ADVANCED CUSTOMER SUPPORT
JUNTA DE ANDALUCÍA
CONFIGURACIÓN AUDITORIA
DATABASE 11G.
SOLUTION SUPPORT CENTER
Referencia documento: InfV5_JdA_AuditoriaOracleLOPDpara11g_v1.doc Fecha: 10 de Noviembre del 2015 Versión: 1.1 Copyright(c) 2.009 ORACLE IBÉRICA Todos los derechos reservados
2
Registro de Cambios
Fecha Autor Versión Notas
10/11/2015 Paola Juárez Gómez 1.0 Creación del documento
Revisiones
Nombre Role
Marisol Segade
Principal Advanced Support Engineer
Distribución
Copia Nombre Empresa
Servicio informática CAPDER
3
Índice de Contenidos
INTRODUCCIÓN .................................................................................................................................... 4 LOPD ................................................................................................................................................... 5 AUDITORIA 11G ................................................................................................................................... 9
Tipos de auditoria ........................................................................................................................ 9 ¿Donde se guardan los registros de auditoría? ..................................................................... 11 Tablas y Vistas ............................................................................................................................ 11 Parametrizacion ......................................................................................................................... 12 ¿Para qué se puede usar la auditoria?..................................................................................... 14
AUDITORIA ESTÁNDAR ...................................................................................................................... 15 Auditar los inicios de sesión de la base de datos .................................................................. 17 Auditar una sentencia concreta ............................................................................................... 17 Auditar acciones de cada usuario............................................................................................ 17 Auditar acciones sobre cada objeto ......................................................................................... 17 Auditar privilegios del sistema ................................................................................................ 18 Auditoria de Oracle NET .......................................................................................................... 18
AUDITORIA DE GRANO FINO ............................................................................................................. 19 LOGMINER ......................................................................................................................................... 21 GUÍA PRÁCTICA DEL MANTENIMIENTO DE LA AUDITORIA ............................................................... 23 ANEXO ................................................................................................................................................ 29 ACCIONES ........................................................................................................................................... 31
4
Introducción
Una de las principales funciones de un DBA es implementar seguridad en la base de datos. Hay muchos aspectos relacionados a la aplicación de la misma, quizás no todos pueden ser aplicados en tu entorno, pero podría ser interesante conocer todas las opciones. Puede que un DBA no tenga que llegar a implementar una solución de autenticación basada en Kerberos pero siempre va a tener la responsabilidad de saber que está pasando en su base de datos. Es decir, quién se está conectado, qué sentencias se están ejecutando, etc.
La auditoría ha sido desde hace años la manera de satisfacer esta necesidad. No solamente es fácil de implementar y administrar, sino que además cubre todos los aspectos necesarios que un DBA tiene que cuidar cuando se trata de proteger su base de datos.
Con idea de recoger los conceptos y tareas básicas se ha creado este documento orientado a facilitar la implantación de los requisitos de la LOPD mediante la auditoria de Oracle en una base de datos 11g.
5
LOPD
Según la Agencia Española de Protección de Datos podemos catalogar los ficheros en tres niveles en función a la tipología de los datos.
Reglamento de medidas de seguridad de los ficheros que contengan datos de carácter personal (RD 994/1999)
Nivel básico: Ficheros que contengan datos de carácter personal.
Nivel medio: Ficheros que contengan datos relativos a la comisión de infracciones administrativas o penales, Hacienda Pública, servicios financieros y los que se rijan por el artículo 29 de la LOPD (prestación de servicios de solvencia y crédito).
Nivel alto: Ficheros que contengan datos de ideología, religión, creencias, origen racial, salud o vida sexual así como los recabados para fines policiales sin consentimiento de las personas afectadas
Detalle de los requisitos para los datos LOPD.
Teniendo en cuenta la tipología de los datos comentada antes, tendremos que realizar diferentes tareas para asegurarnos que nuestros cumplimos la LOPD. Para ayudar al lector vamos a diferencias las secciones con colores.
Verde
Algunos puntos básicos están asociados a la gestión y administración de los datos y procedimientos. Estos puntos deben definirse y documentarse entre los departamentos de base de datos, sistemas y responsables de aplicaciones.
Naranja
Hay tareas a cumplir asociadas directamente al plan de Backup&Recovery o Plan de contingencia. Si no se tiene claro como cumplir cualquiera de estos puntos se puede solicitar a ACS una revisión del plan de Backup&Recovery durante la definición del SDP del cliente.
Rojo
La mayoría de los puntos, son requisitos de seguridad que se pueden realizar con configuraciones de seguridad específicas. Si no se tiene claro como cumplir cualquiera de estos puntos se puede solicitar a ACS una revisión de seguridad durante la definición del SDP del cliente.
Negro
En este documento nos vamos a centrar en aquellos puntos que se pueden cumplir configurando la auditoria de Oracle.
6
NIVEL BASICO
NIVEL MEDIO
NIVEL ALTO
DOCUMENTO DE SEGURIDAD
- Ámbito de aplicación. - Medidas, normas, procedimientos reglas y estándares
de seguridad. - Funciones y obligaciones del personal.
- Estructura y descripción de ficheros y sistemas de información.
- Procedimiento de notificación, gestión y respuesta ante incidencias.
- Procedimientos de realización copias de respaldo y recuperación de datos.
- Identificación del responsable de seguridad. - Control periódico del cumplimiento del
documento. - Medidas a adoptar en caso de reutilización o
desecho de soportes.
PERSONAL
- Funciones y obligaciones claramente definidas y
documentadas. - Difusión entre el personal, de las normas que les
afecten y de las consecuencias por incumplimiento.
INCIDENCIAS
- Registrar tipo de incidencia, momento en que se ha
producido, persona que la notifica, persona a la que se comunica y efectos derivados.
- Registrar realización de procedimientos de
recuperación de los datos, persona que lo ejecuta, datos restaurados y grabados manualmente.
- Autorización por escrito del responsable del fichero para su recuperación.
IDENTIFICACIÓN Y AUTENTICACIÓN
- Relación actualizada de usuarios y accesos
autorizados.
- Procedimientos de identificación y autenticación. - Criterios de accesos. - Procedimientos de asignación y gestión de contraseñas
- Se establecerá el mecanismo que permita la
identificación de forma inequívoca y personalizada de todo usuario y la verificación de que está autorizado.
- Límite de intentos reiterados de accceso no
7
NIVEL BASICO
NIVEL MEDIO
NIVEL ALTO
y periodicidad con que se cambian. - Almacenamiento ininteligible de contraseñas activas.
autorizado.
CONTROL DE ACCESO
- Cada usuario accederá únicamente a los datos y recursos necesarios para el desarrollo de sus funciones.
- Mecanismos que eviten el acceso a datos o recursos con derechos distintos de los autorizados.
- Concesión de permisos de acceso sólo por personal autorizado.
- Control de acceso físico a los locales donde
se encuentren ubicados los sistemas de información.
GESTIÓN DE SOPORTES
- Identificar el tipo de información que contienen.
- Inventario. - Almacenamiento con acceso restringido. - Salida de soportes autorizada por el responsable del
fichero.
- Registro de entrada y salida de soportes.
- Medidas para impedir la recuperación posterior de información de un soporte que vaya a ser desechado o reutilizado.
- Medidas que impidan la recuperación indebida de la información almacenada en un soporte que vaya a salir como consecuencia de operaciones de mantenimiento.
- Cifrado de datos en la distribución de soportes.
COPIAS DE RESPALDO
- Verificar la definición y aplicación de los procedimientos de copias y recuperación.
- Garantizar la reconstrucción de los datos en el estado en que se encontraban en el momento de producirse la pérdida o destrucción.
- Copia de respaldo, al menos semanal.
- Copia de respaldo y procedimientos de recuperación en un lugar diferente del que se encuentren los equipos.
RESPONSABLE
- Uno o varios nombrados por el responsable
del fichero. - Encargado de coordinar y controlar las
8
NIVEL BASICO
NIVEL MEDIO
NIVEL ALTO
medidas del documento. - No supone delegación de responsabilidad
del responsable del fichero.
PRUEBAS
- Solo se realizarán si se asegura el nivel de
seguridad correspondiente al tipo de fichero tratado.
AUDITORIA - Al menos cada dos años, interna o externa. - Adecuación de las medidas y controles. - Deficiencias y propuestas correctoras. - Análisis del responsable de seguridad y
conclusiones al responsable del fichero,
- Adopción de las medidas correctoras adecuadas.
REGISTRO DE ACCESOS
- Registrar usuario, hora,
fichero, tipo acceso y registro accedido.
- Control del responsable de seguridad. Informe mensual.
- Conservación 2 años.
TELECOMUNICA CIONES
- Transmisión de datos cifrada.
9
Auditoria 11G
Para empezar realizaremos una breve descripción del concepto auditoria.
Auditoria informática
Consiste en recoger, agrupar y evaluar evidencias para determinar si un sistema de información salvaguarda el activo empresarial, mantiene la integridad de los datos, lleva a cabo eficazmente los fines de la organización, utiliza eficientemente los recursos y cumple con las leyes y regulaciones establecidas.
Auditoria para Oracle
En el caso de Oracle, la auditoría es un conjunto de características que permite al administrador de la base de datos y a los usuarios hacer un seguimiento del uso de la base de datos. El administrador de base de datos puede definir la actividad de auditoría predeterminada. La información de las auditorías se almacena en el diccionario de datos, en la tabla SYS.AUD$, o en la pista de auditoría del sistema operativo.
Cuando se realizan auditorías, la funcionalidad de la base de datos es dejar constancia de los comandos correctos e incorrectos. Esto puede modificarse cuando se configura cada tipo de auditoría.
Tipos de auditoria
El DBA tiene a su disposición varios tipos diferentes de auditoría:
Auditoria Obligatoria
Este tipo de auditoría está siempre habilitada y monitorea las operaciones que involucren el startup o shutdown de la base de datos. Además de estas acciones, en cualquier momento que alguien utilice los roles predefinidos del sistema SYSDBA, SYSASM o SYSOPER esa acción será auditada.
Auditoria Estándar
Este tipo de auditoría se habilita con el comando de AUDIT cuando es necesario auditar sentencias SQL, privilegios, objetos de esquema o actividades de red. Este tipo de auditoría se define y controla completamente a nivel de base de datos.
Auditoria basada en valores
La auditoría basada en valores fue introducida para poder capturar los valores reales que se cambian cada vez que algún tipo de sentencia DML es ejecutada en todas o determinadas filas de una tabla. Este tipo de auditoría aprovecha la funcionalidad de los triggers de base de datos (construcciones PL/SQL que responden a eventos) para lograr este objetivo.
10
Auditoria de Grano Fino
La auditoría de grano fino se focaliza en una auditoría de nivel mas granular y las acciones auditadas se capturan basándose en el contenido accedido o modificado. Se puede simplemente crear políticas para disparar eventos de auditoría cuando alguien trata de realizar acciones que responden a las condiciones especificadas en la definición de la política.
Auditoria de Sistema
Por defecto, el usuario SYS está exento de ser auditado, esto es ciertamente un agujero de seguridad. Se puede cambiar este comportamiento cambiando el parámetro AUDIT_SYS_OPERATIONS=TRUE.
Los usuarios que se conecten como SYS serán auditados y los registros de sus acciones serán escritos en un archivo de sistema operativo para evitar que sean borrados de la tabla aud$ dentro de la base de datos. El parámetro de inicialización AUDIT_SYS_OPERATIONS se utiliza para activar y desactivar la auditoria de SYS.
Cuando el parámetro esta a true, oracle registrará todos las sentencias ejecutadas por SYS en la localizacion definida en el AUDIT_FILE_DEST en el caso de UNIX o en el visor de Eventos en el caso de Windows. Si el parámetro AUDIT_SYSLOG_LEVEL está además definido se escribirán también en el syslog de UNIX.
Audit Vault
Como complemento de estas soluciones y para proteger la información sensible recolectada tenemos a disposición el producto Oracle Audit Vault (requiere licencia) que se encarga de resguardar, centralizar y gestionar los registros de auditoría de distintas bases de datos y múltiples orígenes.
Logminer
También podríamos incluir dentro de los escenarios de auditoría el uso de LogMiner. Log Miner es una herramienta que Oracle incorpora en su BBDD que nos ayuda a hacer más sencillo e interpretable los redo logs permitiendo consultar y tracear las operaciones DDL y DML realizadas.
Combinando todas estas opciones, un DBA dispone de un completo arsenal con todas las herramientas necesarias para gestionar la auditoría y así poder construir un sólido sistema de monitoreo que le permita tener bajo control cualquier actividad sospechosa que pueda ocurrir en la base de datos.
Nota:
En una base de datos 11G recién instalada, configuremos o no alguna auditoria, vamos a tener por defecto la Auditoria Obligatoria, como hemos comentado incluye las operaciones de inicio y parada y las conexiones y desconexiones de usuarios con privilegios SYSDBA o SYSOPER que será registrado en los ficheros AUD en el AUD_FILE_DEST.
Además la configuración por defecto en la versión 11G incluye el valor DB para el parámetro AUDIT_TRAIL, que auditara por defecto algunos privilegios de sistema y sentencias siendo guardadas en la tabla SYS.AUD$ (consultar vista AUDIT_TRAIL ).
11
El DBA siempre tiene la posibilidad de desactivarla en caso de no querer que se active. Y por supuesto el complementar estas políticas de auditoría base con las suyas propias para cumplir con las necesidades y nivel de auditoría requerido en esa BD en particular.
Para revisar la configuración actual o cambiarla basta con revisar el valor de los parámetros AUDIT_TRAIL y AUDIT_FILE_DEST
¿Donde se guardan los registros de auditoría?
La base de datos Oracle registra las actividades de auditoría en registros de Auditoria. Estos registros van a dar información sobre la operación que ha sido auditada, el usuario que realizo dicha operación o sobre la fecha y tiempo en la que se realizo dicha operación.
Los registros de auditoría pueden ser almacenados en las tablas de diccionario asociadas, llamadas AUDIT TRAIL o en el sistema. Oracle dispone de un conjunto de vistas de diccionario que nos van a permitir rastrear las actividades sospechosas.
Cuando se usa la auditoria estándar, Oracle escribe los registros en la DBA_AUDIT_TRAIL (tabla SYS.AUD$), en el AUDIT_TRAIL del sistema operativo o si estamos usando también la auditoria de grano fino en la vista DBA_COMMON_AUDIT_TRAIL que combina ambas entradas.
Si se activa o desactiva la auditoria a operaciones de usuarios con privilegios de sistema , asociada al usuario SYS, o cualquier usuario que se conecte usando los privilegios SYSDBA or SYSOPER esas opraciones se guardan en ORACLE_BASE/ admin/ORACLE_SID/adump o ORACLE_HOME/rdbms/audit.
Las acciones realizadas por los administradores serán auditadas en el syslog audit siempre que el parámetro AUDIT_SYSLOG_LEVEL se encuentre definido.
Tablas y Vistas
Para consultar la información existente se recomienda consultar las vistas de diccionario asociadas a la auditoria.
Las principales son:
Vista
Descripción
ALL_AUDIT_POLICIES Define las políticas en las tablas y vistas accesibles al usuario actual.
ALL_AUDIT_POLICY_COLUMNS Define las políticas de auditoría en las tablas y vistas accesibles para el usuario actual.
ALL_DEF_AUDIT_OPTS Lista las opciones por defecto de auditoría que serán aplicadas a los objetos que se crean.
AUDIT_ACTIONS Lista las acciones que pueden ser auditadas. DBA_AUDIT_EXISTS Lista las entradas auditadas producidas por AUDIT
NOT EXISTS. DBA_AUDIT_OBJECT Lista los registros de auditoría de todos los objetos del
sistema. DBA_AUDIT_POLICIES Lista toda la información sobre las políticas de
auditoría del sistema. DBA_AUDIT_SESSION Lista todos los registros que conciernen a CONNECT y
12
Vista
Descripción
DISCONNECT.
DBA_AUDIT_POLICY_COLUMNS Lista las columnas de política en las tablas y vistas de toda la base de datos.
BDA_AUDIT_STATEMENT Lista los registros auditados que conciernen a GRANT, REVOKE, AUDIT, NOAUDIT y ALTER SYSTEM de toda la base de datos.
DBA_AUDIT_TRAIL Lista todas las entradas estándares que hay en la tabla AUD$.
DBA_COMMON_AUDIT_TRAIL Combina los logs estándares con los exhaustivos, incluye SYS y los registros obligatorios escritos en formato XML.
DBA_FGA_AUDIT_TRAIL Lista los registros completos de una auditoría.
DBA_OBJ_AUDIT_OPTS Describe las opciones de auditoría en todos los objetos.
DBA_PRIV_AUDIT_OPTS Describe los privilegios de sistema actuales que estan siendo auditados por algún usuario.
DBA_STMT_AUDIT_OPTS Describe todas las opciones de auditoría actuales de todo el sistema y por usuario.
USER_AUDIT_OBJECT Lista los registros auditados para sentencias que conciernen objetos accesibles para el usuario actual.
USER_AUDIT_POLICIES Describe exhaustivamente las columnas de políticas de auditoría en las tablas y vistas accesibles por el usuario actual.
USER_AUDIT_SESSION Lista todos los registros de auditoría relacionados a conexiones y desconexiones del usuario actual.
Hay bastantes vistas más, para verlas todas podemos usar esta sentencia:
SELECT view_name
FROM dba_views
WHERE view_name LIKE ‘%AUDIT%’
ORDER BY view_name
Parametrizacion
Parámetro Valor por defecto Descripción
AUDIT_TRAIL
DB
Activa o desactiva el uso de la auditoria. Existen diferentes valores: – none: desactiva la auditoría de la base de datos.
– os: activa la auditoría de la base de datos. Los sucesos auditados se escribirán en la pista de auditoría del sistema operativo, no se auditará en Oracle sino en el sistema operativo anfitrión. Esta opción funcionará dependiendo del sistema operativo.
– db: activa la auditoría y los datos se almacenarán en la taba SYS.AUD$ de Oracle.
13
Parámetro Valor por defecto Descripción
– db, extended: activa la auditoría y los datos se almacenarán en la taba SYS.AUD$ de Oracle. Además se escribirán los valores correspondientes en las columnas SQLBIND y SQLTEXT de la tabla SYS.AUD$. – xml: activa la auditoría de la base de datos, los sucesos será escritos en ficheros XML del sistema operativo.
– xml, extended: activa la auditoría de la base de datos, los sucesos será escritos en el formato XML del sistema operativo, además se incluirán los valores de SqlText y SqlBind.
AUDIT_FILE_DEST
ORACLE_BASE/ admin/ORACLE_SID/adump or ORACLE_HOME/rdbms/audit
Especifica el directorio de sistema operativo donde audit trail escribirá en caso de estar usando cualquier de las
opciones OS, XML, o
XML,EXTENDED. Hay que tener en
cuenta que la auditoria obligatoria usará este directorio, además si está definido el
AUDIT_SYS_OPERATIONS,
también se incluirá la auditoria del usuario SYS.
AUDIT_SYS_OPERATIONS FALSE Activa o desactiva la auditoria a
operaciones de usuarios con privilegios de sistema , asociada al usuario SYS, o cualquier usuario que se conecte usando
los privilegios SYSDBA or
SYSOPER.
AUDIT_SYSLOG_LEVEL
Sin valor por defecto
Configurando este parámetro podemos integrar la auditoria de Oracle ( Audit Trail) con el syslog de UNIX o incluso mandar esa información a un sistema remoto usando la utilidad SYSLOGD
Ejemplo
AUDIT_SYSLOG_LEVEL = 'LOCAL1.WARNING';
/etc/syslog.conf:
LOCAL1.WARNING /var/log/dbaudit.log
14
¿Para qué se puede usar la auditoria?
A continuación se listan algunos casos de usos en los que se puede usar la auditoria.
- Problemas de rendimiento asociados a logon excesivos. Nos permitirá cuantificar que usuarios son los que más conexiones realizan. Normalmente estos problemas están asociados a problemas de configuración de los pools de conexión de los servidores de aplicaciones y una vez identificados son fáciles de solucionar.
- Errores en la app como “Table Or View Does Not Exist” o “Insufficient Privileges”. Cuando aparecen estos errores podemos acudir a la auditoria para identificar que tabla es la involucrada únicamente consultando el AUDIT_TRAIL
- Quien borro/modifico una tabla/procedimiento o índice?
- Privilegios inapropiados asignados a algunos usuarios. ¿Sabes si algún usuario tiene privilegios que no le corresponden? ¿Algún usuario con permisos DBA en tu entorno productivo?
- Diagnostico de problemas de conexión. Por ejemplo la cuenta de un usuario se bloquea frecuentemente pero no se sabe que persona está usando ese usuario. Con la auditoria puedes identificar desde que máquina se están conectando.
- Configurar la auditoria de Oracle te permite cumplir la LOPD si tienes datos de catalogados como nivel medio o alto.
15
Auditoria Estándar
Esta sección explica cómo usar la auditoria estándar para auditar las actividades realizadas contra sentencias SQL, privilegios, objetos de sistema, red o actividades multitier.
Cuando creamos una base de datos con el asistente DBCA por defecto se configura la auditoria de los privilegios y sentencias SQL. El parámetro AUDIT_TRAIL se configura a DB.
- Con la auditoria estándar se pueden tracear las acciones que tienen resultado fallido, correcto o ambas.
- Se puede especificar “BY SESSION” o “BY ACCESS” según la granularidad que queramos. Oracle recomienda que se use la opción BY ACCESS, ya que esa opción incluye más información como fecha/hora ejecución, privilegios usados, objetos accedidos, SQL text o bind variables. Además se incluirá el SCN de cada ejecución que nos puede ser útil para realizar flashback query
- Podemos tracear las actividades de algunos usuarios en particular.
- Para chequear la configuración podemos usar las vistas DBA_STMT_AUDIT_OPTS, DBA_PRIV_AUDIT_OPTS y DBA_OBJ_AUDIT_OPTS.
- Para desactivar cualquier traceo basta con usar la opción NOAUDIT.
Oracle Database 11G audita los siguientes privilegios por defecto:
ALTER ANY PROCEDURE
CREATE ANY LIBRARY
DROP ANY TABLE
ALTER ANY TABLE
CREATE ANY PROCEDURE
DROP PROFILE
ALTER DATABASE
CREATE ANY TABLE
DROP USER
ALTER PROFILE
CREATE EXTERNAL JOB
EXEMPT ACCESS POLICY
ALTER SYSTEM
CREATE PUBLIC
DATABASE LINK
GRANT ANY ROLE
OBJECT PRIVILEGE
ALTER USER
CREATE SESSION
GRANT ANY PRIVILEGE
AUDIT SYSTEM
16
CREATE USER
GRANT ANY ROLE
CREATE ANY JOB
DROP ANY PROCEDURE
Oracle 11G audita los siguientes accesos directos SQL por defecto.
ROLE
SYSTEM AUDIT
PUBLIC SYNONYM
Auditoria de Sentencias , Privilegios, Objetos o Red
- Las sentencias SQL que se pueden auditar podrían separarse en dos categorías.
Sentencias DDL . Por ejemplo habilitando la auditoria de tablas ( AUDIT TABLE) auditariamos las sentencias CREATE y DROP TABLE.
Sentencias DML. Por ejemplo activando la auditoria SELECT TABLE podríamos auditar todas las sentencias, SELECT FROM TABLE/VIEW.
- La auditoria de privilegios nos permite controlar que privilegios de sistema están siendo usados. Por ejemplo se puede auditar el privilegio SELECT ANY TABLE. Para hacer esto usaremos la sentencia AUDIT y NOAUDIT para activar y desactivar la auditoria de ese privilegio respectivamente. Antes de nada hay que auditar el privilegio AUDIT SYSTEM para poder realizar esa tarea.
Ejemplos:
Si queremos auditar el uso del privilegio de sistema DELETE ANY TABLE:
AUDIT DELETE ANY TABLE BY ACCESS WHENEVER NOT SUCCESSFUL;
Si queremos incluir los casos con fallo y acierto:
AUDIT DELETE ANY TABLE BY ACCESS;
Para auditar los intentos fallidos de uso del privilegio SELECT, INSERT y delete en todas las tablas y el intento fallido del privilegio de sistema EXECUTE PROCEDURE:
AUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE, EXECUTE PROCEDURE BY
ACCESS WHENEVER NOT SUCCESSFUL;
Si queremos completar la auditoria podemos hacerlo en los siguientes puntos:
Auditar los inicios de sesión de la base de datos
Auditar una sentencia concreta
Auditar acciones de cada usuario
Auditar acciones sobre cada objeto
Auditar privilegios del sistema
17
Auditar los inicios de sesión de la base de datos
Para auditar los inicios de sesión de la base de datos usaremos la sentencia “AUDIT SESSION” (la cual podemos filtrar por usuarios de la siguiente forma “AUDIT SESSION BY usuario1, usuario2;” Al igual que el comando AUDIT tenemos el comando NOAUDIT para desactivarla política de auditoría previamente activada.
SQL> AUDIT SESSION BY SCOTT;
SQL> select * from dba_priv_audit_opts where USER_NAME='SCOTT';
USER_NAME PROXY_NAME PRIVILEGE SUCCESS FAILURE
SCOTT CREATE SESSION BY ACCESS BY ACCESS
SQL> Select username, timestamp, action_name, comment_text,
priv_used from dba_audit_trail where username='SCOTT'
USERNAME TIMESTAMP ACTION_NAME COMMENT_TEXT
PRIV_USED
SCOTT 28-OCT-15 LOGON Authenticated by: DATABASE
CREATE SESSION
SQL> Select Username, userhost, extended_timestamp, action_name from
dba_audit_session where username='SCOTT';
USERNAME USERHOST EXTENDED_TIMESTAMP
ACTION_NAME
SCOTT oel64 28-OCT-15 01.40.48.055753 PM +01:00 LOGON
Auditar una sentencia concreta
Pongámonos en la situación que por ejemplo vamos a auditar todas las sentencias que creen una tabla. Por ejemplo vamos a auditar el CREATE TABLE para el usuario SCOTT.
AUDIT CREATE TABLE BY SCOTT;
Con las vistas DBA_STMT_AUDIT_OPTS y DBA_PRIV_AUDIT_OPTS podemos ver que la auditoría de la sentencia create table ha sido activada para ese usuario.
Auditar acciones de cada usuario
Si vamos a auditar las acciones de cada usuario, lo primero vamos a definir en Oracle que registre todas las actividades que hacen:
SQL> AUDIT ALL;
SQL> AUDIT ALL BY SCOTT;
Auditar acciones sobre cada objeto
Auditando acciones sobre objetos tendremos seguridad sobre la actividad de los usuarios que han interactuado con ese objeto. La sentencia para auditar un objeto es la siguiente:
SQL> AUDIT INSERT ON SCOTT.TABLAOBJETO BY ACCESS;
18
Para auditar todas las acciones de esa misma tabla haríamos:
SQL > audit all on CONTABILIDAD by access;
Auditar privilegios del sistema
Para auditar un privilegio de sistema simplemente debemos de usar la orden AUDIT seguida del privilegio de sistema que necesitemos:
SQL > AUDIT DELETE ANY TABLE BY ACCESS;
Podemos ver todos los privilegios de la base de datos con la siguiente sentencia:
SQL > Select privilege from dba_sys_privs;
Como en sesiones podemos filtrar los privilegios que se terminan correctamente y los que no, con “WHENEVER (NOT) SUCCESSFUL” al final de la sentencia, si no se define auditará todos los tipos. Si nos conectamos con SCOTT y borramos una tabla podemos ver que dejamos “huella” de ello.
Auditoria de Oracle NET
Podemos activar la auditoria de red para registrar errores internos o de protocolo en la capa de red
Para activarla / desactivarla usaremos:
AUDIT NETWORK BY ACCESS;
NOAUDIT NETWORK;
Alguno de los errores auditables:
• TNS-2507, TNS-12648, TNS-12649, TNS-12650
19
Auditoria de Grano Fino
La auditoria de Grano Fino o FGA es una funcionalidad disponible en la versión Enterprise que permite crear políticas que definen condiciones específicas de auditoría. Permite auditar a bajo nivel consultas con operaciones INSERT, UPDATE y DELETE.
Por ejemplo se puede usar FGA en estos casos:
Acceso a una tabla fuera de los horario laboral
Login desde una IP en particular
Consulta o modificación de una columna en particular.
Los registros de auditoría de grano fino se guardan en la tabla SYS.FGA_LOG$. Para consultar esos registros se puede usar la vista DBA_FGA_AUDIT_TRAIL. Si también estamos usando la auditoria estándar podemos acceder a la vista DBA_COMMON_AUDIT_TRAIL, que contiene los registros estándar y FGA unificados.
Para crear una política de FGA se debe usar el procedimiento DBMS_FGA.ADD_POLICY. La base de datos ejecuta esa política teniendo en cuenta los privilegios del usuario que la está creando. El máximo número de políticas que se pueden configurar en una tabla o vista es de 256. La base de datos Oracle almacenara la política en el diccionario. La definición de la política se almacenara en la taba de diccionario SYS.FGA$. Una política no podrá ser modificada una vez creada, si se quiere modificar tendremos que borrarla y volver a crearla.
Para poder crear una política hay que tener permisos EXECUTE DBMS_FGA package.
20
El siguiente ejemplo muestra la creación de una política para registrar todos los updates realizados en la columna SALARY a no ser que el usuario que las realice sea el propietario de la tabla, SCOTT.
begin
DBMS_FGA.ADD_POLICY(
object_schema => 'SCOTT',
object_name => 'EMPLOYEE',
policy_name => 'salary_change',
audit_column => 'SALARY',
audit_condition => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') <>
''SCOTT'' ',
enable => TRUE,
statement_types => 'UPDATE',
audit_trail => DBMS_FGA.DB + DBMS_FGA.EXTENDED);
end;
/
Otro ejemplo donde podemos ver como activar la auditoria para saber quien consulta registros donde los valores de una columna son más altos al valor indicado.
begin
dbms_fga.add_policy(
object_schema => 'SCOTT',
object_name => 'BOOK',
policy_name => 'EXPENSIVE_BOOKS',
audit_condition => 'BOOK_RETAIL_PRICE>=50',
audit_column => 'BOOK_TITLE',
handler_schema => null,
handler_module => null,
enable => true
);
end;
/
Para chequear las políticas definidas se debe consultar la vista DBA_AUDIT_POLICIES
SELECT object_schema, object_name, policy_name, policy_column ,
enabled, sel, ins ,upd ,del FROM dba_audit_policies;
Una de las ventajas de usar FGA, si la comparamos con la auditoria estándar, es que no necesitamos modificar el parámetro AUDIT_TRAIL para que funcione, con lo que no tendremos que reiniciar la base de datos para empezar a auditar.
21
LogMiner
Oracle registra todos los cambios realizados en la base de datos en los ficheros de REDO.
En cada registro de redo encontramos:
Usuario que realizó la acción
En caso de UPDATE, información previa y posterior
En el caso de INSERT la información almacenada
En el caso de DELETE , los registros borrados
Los ficheros de REDO se pueden ir conservando si se activa el archivado, ya que estos son reutilizados
Log Miner es una herramienta que Oracle incorpora en su BBDD que nos ayuda a hacer más sencillo e interpretable el contenido de los ficheros de redo log. Para activarlo tenemos que definir una ruta de archivos con el parámetro “UTL_FILE_DIR”, podemos ver inicialmente el valor del mismo de la siguiente manera
SQL> show parameter utl
El parámetro UTL_FILE_DIR miner es estático, con lo que tendremos que reiniciar la base de datos una vez cambiado si queremos que se realice dicha modificación.
SQL > alter system set utl_file_dir='/home/oracle/logminer'
scope=spfile;
Otro requisito es tener activo la opción de “supplemental log data”.
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
Para confirmar que está configurado podemos consultar la siguiente vista:
SELECT SUPPLEMENTAL_LOG_DATA_MIN FROM V$DATABASE;
Una vez configurados los prerrequisitos tenemos que crear el diccionario de LogMiner. Para ello usaremos la ruta definida en el paso previo:
SQL> exec DBMS_LOGMNR_D.BUILD( DICTIONARY_FILENAME
=>'/home/oracle/logminer.ora', DICTIONARY_LOCATION =>
'/home/oracle/logminer');
PL/SQL procedure successfully completed.
Una vez definido el diccionario, tendremos que ir indicando que ficheros son los que queremos
ir leyendo. Las sentencias para añadir o quitar ficheros son:
SQL> exec DBMS_LOGMNR.add_logfile('nombrearchivo');
SQL> exec DBMS_LOGMNR.remove_logfile (LOGFILENAME =>
'nombrearchivo');
22
Ejemplo:
exec DBMS_LOGMNR.add_logfile ('/u01/app/oracle/flash_recovery_area
/ORCL11/archivelog/2015_10_29/o1_mf_1_8_c345w605_.arc');
Si queremos ver los ficheros que tenemos registrados :
select FILENAME , RESET_SCN, LOW_SCN,NEXT_SCN from v$LOGMNR_LOGS
FILENAME RESET_SCN LOW_SCN NEXT_SCN
/u01/app/oracle/oradata/ORCL11/redo03.log 945184 1137442
1143618
/u01/app/oracle/oradata/ORCL11/redo01.log 945184 1143618
2.8147E+14
El último paso sería iniciar la sesión de Log miner para empezar a leer los ficheros.
SQL > exec
DBMS_LOGMNR.START_LOGMNR(DICTFILENAME=>'/home/oracle/logminer/logmin
er.ora');
Para consultar información que nos ayudará a interpretar los datos de los redo, se recomienda consultar la vista v$logmnr_contents, aunque también existen estas otras:
V$LOGMNR_CONTENTS
V$LOGMNR_DICTIONARY
V$LOGMNR_LOGS
V$LOGMNR_PARAMETERS
Ejemplo:
Supongamos que el usuario SCOTT realiza un update en la tabla EMP y queremos consultar la auditoria de ese cambio, para ello consultaríamos la vista V$LOGMNR_CONTENTS
SQL> update EMP set JOB='CLERK' where ENAME='FORD';
1 row updated.
column sql_redo format a30 word_wrapped
column sql_undo format a30 word_wrapped
column username format a12
SELECT scn, username, sql_redo, sql_undo from v$logmnr_contents
where username='SCOTT';
SCN USERNAME SQL_REDO SQL_UNDO
---------- ------------ ------------------------------ -------------
1144131 SCOTT set transaction read write;
1144131 SCOTT update "SCOTT"."EMP" set "JOB" update
"SCOTT"."EMP" set "JOB"= 'CLERK' where "JOB" = = 'CLERK'
where "JOB" ='CLERK' and ROWID = 'CLERK' and ROWID =
'AAAR3xAAEAAAACXAAM'; 'AAAR3xAAEAAAACXAAM';
Para finalizar la sesión de LogMiner solo es necesario ejecutar el siguiente comando:
SQL > exec DBMS_LOGMNR.END_LOGMNR;
O salir de la sesión de SYS y automáticamente se cerrará la base de datos.
23
Guía práctica del mantenimiento de la Auditoria
Ficheros Auditoria por defecto
Aunque no tengamos activada la auditoria, tenemos que recordar que la versión 11 viene configurada por defecto con la opción DB. Con lo que tendremos ciertos registros en el DBA_AUDIT_TRAIL.
Además no nos debemos olvidar que Auditoria Obligatoria genera ficheros en el AUDIT_DEST, si en nuestro entorno hay muchos usuarios que se conectan como SYSDBA o SYSOPER se generaran muchos ficheros que pueden terminar llenando el filesystem.
Se recomienda realizar revisiones periódicas y realizar purgados frecuentemente.
Tablespace específico para Auditoria
El primer paso a tener en cuenta cuando se empieza a usar la auditoria es mover los registros a su propio tablespace, ya que por defecto estará en el SYSTEM.
En versiones previas este cambio debía de realizarse manualmente, en 11G se puede realizar mediante el paquete DBMS_AUDIT_MGMT. Tenemos que tener cuidado y no realizar esta tarea en ventana de tiempo de producción porque puede haber problemas de rendimiento. Por ejemplo si tenemos auditado el LOGON/LOGOFF puede causar un cuello de bloqueo si no se puede realizar login nuevos por tener bloqueadas las tablas de auditoría.
Otra opción es desactivar el traceo con NOAUDIT y volverlo a activarlo después de haber movido las tablas al nuevo tablespace.
Como primer paso creamos el tablespace Audit.
create tablespace audit_tbs
datafile '/u01/app/oracle/oradata/ORCL12/datafile/audit_tbs01.dbf'
size 20M autoextend on next 5m maxsize 2000M;
Movemos las tablas de auditoría al nuevo tablespace.
BEGIN
DBMS_AUDIT_MGMT.set_audit_trail_location(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
audit_trail_location_value => 'AUDIT_TBS');
END;
Job de Purgado
Para que la tabla unified_audit_trail no crezca demasiado, se recomienda implantar una buena práctica que consiste crear una tabla de histórico en un tablespace dedicado.
En la tabla de histórico se van a mantener los registros más antiguos y en la tabla unified_audit_trail los registros más recientes ( Por ejemplo último mes ). Para realizar este procedimiento se puede crear un job diario que se encargue de realizar el traspaso de registros.
Creación de un usuario específico para el mantenimiento.
24
SQL> create user registro identified by **** default tablespace
AUDIT_TBS;
User created.
SQL> grant connect to registro;
Grant succeeded.
SQL> grant AUDIT_ADMIN to registro;
Grant succeeded.
SQL> grant AUDIT_VIEWER to registro;
Grant succeeded.
SQL> alter user registro quota unlimited on AUDIT_TBS;
User altered.
Diariamente se copian los registros en la tabla de histórico y posteriormente se purgan de la tabla audit.
Para ello nos conectamos con el usuario registro.
CREATE TABLE registro_auditoria AS (SELECT * FROM
UNIFIED_AUDIT_TRAIL);
Truncate table registro_auditoria;
INSERT INTO registro_auditoria (SELECT * FROM UNIFIED_AUDIT_TRAIL);
Con el siguiente paquete podemos fijar el timestamp con el momento en el que hemos realizado el paso a histórico para luego hacer un purgado usando ese timestamp
Se fija el time stamp final de lo último que se ha archivado
BEGIN
dbms_audit_mgmt.set_last_archive_timestamp(
audit_trail_type => dbms_audit_mgmt.audit_trail_unified,
last_archive_time =>sysdate);
END;/
Posteriormente se puede purgar sin problema.
SELECT last_archive_ts FROM dba_audit_mgmt_last_arch_ts;
LAST_ARCHIVE_TS
-----------------------------------
13-JAN-15 01.22.00.000000 PM +00:00
BEGIN
dbms_audit_mgmt.clean_audit_trail(
audit_trail_type => dbms_audit_mgmt.audit_trail_unified,
use_last_arch_timestamp => TRUE);
END;
/
La recomendación es crear un job para realizar esta tarea de forma diaria o semanal en función de los registros que se quieran mantener en la tabla UNIFIED_AUDIT_TRAIL.
25
Comprobamos los registros de cada tabla:
select count(*) from registro_auditoria;
select count(*) from unified_audit_trail;
Si queremos realizar un purgado diario sin pasar a histórico los registros diarios, podemos seguir los siguientes pasos:
1. Inicializar el mantenimiento de auditoria
2. Confirmar cual es el intervalo de Limpieza configurado por defecto
3. Fijar el valor de Last Archive Timestamp
4. Chequear el valor definido
5. Configurar el job de purgado
6. Configurar el job para fijar el Last Archive Timestamp
7. Chequear la configuración de los jobs.
--
-- Set-up Audit Management
--
BEGIN
DBMS_AUDIT_MGMT.init_cleanup(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL,
default_cleanup_interval => 12 /* hours */);
END;
/
--
-- Check Default Clean Up Interval has been Set and Cleanup is Initialized
--
COLUMN parameter_name FORMAT A30
COLUMN parameter_value FORMAT A20
COLUMN audit_trail FORMAT A20
SELECT * FROM dba_audit_mgmt_config_params WHERE PARAMETER_NAME = 'DEFAULT
CLEAN UP INTERVAL'
/
SET SERVEROUTPUT ON
BEGIN
IF
DBMS_AUDIT_MGMT.is_cleanup_initialized(DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD)
THEN
DBMS_OUTPUT.put_line('YES');
ELSE
DBMS_OUTPUT.put_line('NO');
END IF;
END;
/
pause Check the default clean up interval been set and the cleanup has been
initialized.
--
-- Set Last Archive Timestamp Values for OS and XML Files.
--
BEGIN
DBMS_AUDIT_MGMT.set_last_archive_timestamp(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS,
last_archive_time => SYSTIMESTAMP-31);
END;
26
/
BEGIN
DBMS_AUDIT_MGMT.set_last_archive_timestamp(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
last_archive_time => SYSTIMESTAMP-31);
END;
/
BEGIN
DBMS_AUDIT_MGMT.set_last_archive_timestamp(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML,
last_archive_time => SYSTIMESTAMP-31);
END;
/
--
-- Check Last Archive Timestamp Values are Set
--
SELECT * FROM dba_audit_mgmt_last_arch_ts
/
pause Check the last archive timestamp values have been set.
--
-- Set-up Automated Purge Job
--
BEGIN
DBMS_AUDIT_MGMT.create_purge_job(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL,
audit_trail_purge_interval => 24 /* hours */,
audit_trail_purge_name => 'PURGE_ALL_AUDIT_TRAILS',
use_last_arch_timestamp => TRUE);
END;
/
--
-- Set-up a Job to Move the Last Archive Timestamp Forward Each Day
--
-- Unhash if rerunning code.
--
-- BEGIN
-- SYS.DBMS_SCHEDULER.DROP_JOB
-- (job_name => 'SYS.MOVE_LAST_TIMESTAMP_FORWARD');
-- END;
-- /
BEGIN
SYS.DBMS_SCHEDULER.CREATE_JOB
(
job_name => 'SYS.MOVE_LAST_TIMESTAMP_FORWARD'
,start_date => TO_TIMESTAMP_TZ('2012/04/13 08:00:00.000000
+01:00','yyyy/mm/dd hh24:mi:ss.ff tzr')
,repeat_interval => 'FREQ=DAILY;INTERVAL=1'
,end_date => NULL
,job_class => 'DEFAULT_JOB_CLASS'
,job_type => 'PLSQL_BLOCK'
,job_action => 'BEGIN
DBMS_AUDIT_MGMT.set_last_archive_timestamp(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS,
last_archive_time => SYSTIMESTAMP-31);
END;
BEGIN
DBMS_AUDIT_MGMT.set_last_archive_timestamp(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
last_archive_time => SYSTIMESTAMP-31);
END;
BEGIN
DBMS_AUDIT_MGMT.set_last_archive_timestamp(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML,
last_archive_time => SYSTIMESTAMP-31);
END;'
,comments => NULL
);
27
SYS.DBMS_SCHEDULER.SET_ATTRIBUTE
( name => 'SYS.MOVE_LAST_TIMESTAMP_FORWARD'
,attribute => 'RESTARTABLE'
,value => FALSE);
SYS.DBMS_SCHEDULER.SET_ATTRIBUTE
( name => 'SYS.MOVE_LAST_TIMESTAMP_FORWARD'
,attribute => 'LOGGING_LEVEL'
,value => SYS.DBMS_SCHEDULER.LOGGING_OFF);
SYS.DBMS_SCHEDULER.SET_ATTRIBUTE_NULL
( name => 'SYS.MOVE_LAST_TIMESTAMP_FORWARD'
,attribute => 'MAX_FAILURES');
SYS.DBMS_SCHEDULER.SET_ATTRIBUTE_NULL
( name => 'SYS.MOVE_LAST_TIMESTAMP_FORWARD'
,attribute => 'MAX_RUNS');
BEGIN
SYS.DBMS_SCHEDULER.SET_ATTRIBUTE
( name => 'SYS.MOVE_LAST_TIMESTAMP_FORWARD'
,attribute => 'STOP_ON_WINDOW_CLOSE'
,value => FALSE);
EXCEPTION
-- could fail if program is of type EXECUTABLE...
WHEN OTHERS THEN
NULL;
END;
SYS.DBMS_SCHEDULER.SET_ATTRIBUTE
( name => 'SYS.MOVE_LAST_TIMESTAMP_FORWARD'
,attribute => 'JOB_PRIORITY'
,value => 3);
SYS.DBMS_SCHEDULER.SET_ATTRIBUTE_NULL
( name => 'SYS.MOVE_LAST_TIMESTAMP_FORWARD'
,attribute => 'SCHEDULE_LIMIT');
SYS.DBMS_SCHEDULER.SET_ATTRIBUTE
( name => 'SYS.MOVE_LAST_TIMESTAMP_FORWARD'
,attribute => 'AUTO_DROP'
,value => TRUE);
SYS.DBMS_SCHEDULER.ENABLE
(name => 'SYS.MOVE_LAST_TIMESTAMP_FORWARD');
END;
/
--
-- Check the DBMS Scheduler Jobs are Configured.
--
SELECT owner,job_name FROM DBA_SCHEDULER_JOBS WHERE job_name IN
('PURGE_ALL_AUDIT_TRAILS','MOVE_LAST_TIMESTAMP_FORWARD')
/
pause Check the jobs are scheduled.
Note 73408.1 How to Truncate, Delete, or Purge Rows from the Audit Trail Table SYS.AUD$
Note 731908.1 New Feature DBMS_AUDIT_MGMT To Manage And Purge Audit Information
Auditoria del Sistema
Para gestionar los registros de auditoría de Oracle debemos tener claro que cualquier usuario que se conecte con privilegios de administrador puede borrar estos archivos. Para poder controlar eso se recomienda activar el parámetro AUDIT_SYS_OPERATIONS=TRUE, que nos permitirá tener registrado que esos registros han sido borrados.
28
Control de acceso a la tabla AUD$
Si en algún momento necesitamos habilitar el acceso a usuarios a la tabla AUD$ podemos habilitar auditoria para cualquier acción que se realice sobre esta tabla.
AUDIT INSERT, UPDATE, DELETE ON SYS.AUD$ BY ACCESS;
Así podremos controlar la actividad relevante que se realiza sobre esta tabla.
Configuración Avanzada
Se recomienda completar la auditoria por defecto con las siguientes sentencias. Este cambio capturara la mayoría de las operaciones DLL y Grant además de los intentos de ejecución de sentencias SQL fallidos.
audit not exists;
audit select any table;
audit select any dictionary;
audit SELECT TABLE whenever not successful;
audit INSERT TABLE whenever not successful;
audit UPDATE TABLE whenever not successful;
audit DELETE TABLE whenever not successful;
audit table; (shortcut for create, drop, truncate)
audit alter table;
audit procedure;
audit trigger;
audit view;
audit index;
audit grant procedure;
audit grant table;
29
Anexo
En esta sección se incluyen información utiles.
Estructura principales tablas de auditoria
30
Como auditar las conexiones fallidas
select username, terminal, action_name,
to_char(timestamp,'DDMMYYYY:HHMISS') timestamp,
to_char(logoff_time,'DDMMYYYY:HHMISS') logoff_time,
returncode from dba_audit_session
SQL> /
USERNAME TERMIN ACTION_N TIMESTAMP LOGOFF_TIME RETURNCODE
SYS pts/1 LOGOFF 09042009:051046 09042009:051641 0
JULIA pts/1 LOGON 09042009:051641 1017
SYS pts/1 LOGOFF 09042009:051649 09042009:053032 0
SYS pts/2 LOGOFF 09042009:052622 09042009:053408 0
JULIA pts/1 LOGON 09042009:053032 1017
Como auditar las conexiones en horarios NO laborales
SQL> select username, terminal, action_name, returncode,
to_char(timestamp,'DD-MON-YYYY HH24:MI:SS'),
to_char(logoff_time,'DD-MON-YYYY HH24:MI:SS') from dba_audit_session
where to_date(to_char(timestamp,'HH24:MI:SS'),'HH24:MI:SS') <
to_date('08:00:00','HH24:MI:SS') or
to_date(to_char(timestamp,'HH24:MI:SS'),'HH24:MI:SS')
>to_date('19:30:00','HH24:MI:SS')
USERNAME TERMIN ACTION_N RETURNCODE TO_CHAR(TIMESTAMP,'D
TO_CHAR(LOGOFF_TIME,
SYS pts/1 LOGOFF 0 09-APR-2009 20:10:46 09-APR-2009 20:16:41
SYSTEM pts/5 LOGOFF 0 09-APR-2009 21:49:20 09-APR-2009 21:49:50
JULIA pts/5 LOGON 0 09-APR-2009 21:49:50
PEPE pts/6 LOGON 0 09-APR-2009 22:49:12
Como auditar las conexiones de usuario NO definidos
SQL> select username, terminal,
to_char(timestamp,'DD-MON-YYYY HH24:MI:SS')
from dba_audit_session
where returncode<>0 and
not exists (select 'x' from dba_users where
dba_users.username=dba_audit_session.username)
USERNAME TERMIN TO_CHAR(TIMESTAMP,'D
PEPE pts/3 09-APR-2003 17:31:47
PEPE pts/3 09-APR-2003 17:32:02
PEPE pts/3 09-APR-2003 17:32:15
ANAJ pts/3 09-APR-2003 17:33:01
31
Acciones
Acciones Riesgo o Mejora Responsable Estado
Repaso de la documentación proporcionada, buenas prácticas para el uso de políticas de Seguridad
Cumplimiento LOPD
CAPDER con ayuda de Oracle Soporte
Pendiente
Soporte a la implantación de la auditoria para cumplir la LOPD de tipo MEDIO / ALTO en las tablas seleccionadas
Cumplimiento LOPD
CAPDER con ayuda de Oracle Soporte
Pendiente
