Oracle Database 12c: "Auditoría Unificada (Unified Auditing)"

Por Joel Perez , Aman Sharma , Karan Dodwal (OCM) y Sebastián D'Alessandro (OCE)
Publicado en Mayo 2015

Introducción
Una de las principales funciones de un DBA es implementar seguridad en la base de datos. Aunque si bien hay muchos aspectos relacionados a la aplicación de la misma, no siempre todos son utilizados en todos las empresas. Pero a pesar de esto, 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, quien se está conectado, que sentencias se están ejecutando, etc. La auditoria 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.

Opciones de auditoría en versiones pre-12c
En versiones anteriores a 12c, el DBA tiene a su disposición 5 tipos diferentes de  auditoría. Ellas son:

Mandatory Auditing: 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.

Standard Auditing: Este tipo de auditoría se habilita con el comando de AUDIT cuando es necesario auditar sentencias SQL, privilegios, objetos de esquema, y actividades de red o multitier. Este tipo de auditoría se define y controla completamente a nivel de base de datos.

Auditoría basada en valores: La auditoria 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.

Fine-Grained Auditing: La auditoria de grano fino se focaliza en una auditoria 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.

Sys Auditoría: Este tipo de auditoría en realidad permite monitorear las actividades de un administrador del sistema. 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.

Como complemento de estas soluciones y para proteger la información sensible recolectada tenemos a disposición el producto Oracle Audit Vault que se encarga de resguardar, centralizar y  gestionar los registros de auditoría de distintas bases de datos y  múltiples orígenes.

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.

Entonces, ¿Qué tiene de malo la auditoría que nos proporciona 11g?
Bueno, en realidad no hay nada de malo en las opciones que tenemos disponibles en 11g. Pero si, que son múltiples las tareas que debe llevar adelante el DBA para gestionar la auditoria en aspectos de configuración y  mantenimiento de los datos recolectados. Por ejemplo, debe definir y configurar los parámetros AUDIT_TRAIL y AUDIT_FILE_DEST, mantener diferentes  tablas de auditoría SYS.AUD$ y SYS.FGA_LOG$ (gestión de espacio, cambio del default tablespace,  tratamiento de registros antiguos, etc.), habilitar las opciones de auditoría y si además se está utilizando una solución más robusta como por ejemplo Database Vaut, puede que tenga que gestionar también la tabla  DVSYS.AUDIT_TRAIL $.Para un usuario con privilegios como SYS, los registros de auditoría son creados utilizando el usuario root del sistema operativo con lo que la gestión es aún más difícil ya que normalmente no se le da el acceso de root a los DBA.

Que queremos decir con esto, que hay muchas otras tareas que exceden la simple habilitación de la auditoría y que si de alguna manera, este proceso de gestión  se puede simplificar, obviamente esto ayudaría bastante las tareas diarias del DBA.

Le damos la bienvenida entonces  a la Auditoría Unificada (Unified Auditing) de Oracle Database 12c!

Introducción a la Auditoría Unificada (Unified Auditing)
Oracle 12c ha introducido una forma completamente nueva de implementar y gestionar la auditoría en la base de datos. Este nuevo esquema permite agrupar varias políticas en una sola (de ahí el nombre de "unificada") permitiendo también crear políticas basadas en acciones (action-based) y condiciones (condition-based) si así fuera necesario. La implementación de este nuevo tipo de política es controlada por un usuario específico que es el “owner” de las tablas de auditoría. Estas tablas tienen la particularidad que son de sólo lectura (read-only), incluso para el propio usuario SYS. Por otro lado, todos los tipos de  auditoría disponibles que puedan generarse son administrados por un único usuario y en una única tabla de seguimiento. Si se  requiere dar acceso a algún usuario con nivel de administrador a los datos de auditoría (trail), esto puede realizarce tranquilamente ya que existen dos nuevos roles para tal fin,  uno con privilegios únicamente de "viewer" y uno de "admin".

Arquitectura de la Política de Auditoría Unificada (Unified Auditing)
Como señalábamos, Unified auditing  a diferencia de las versiones anteriores, es propiedad de una nueva cuenta de usuario: AUDSYS. Con la nueva arquitectura existen en la SGA una serie de colas “background queues”, dos por cliente, que reciben los registros de auditoría y los almacenan temporalmente, luego los datos son vaciados sobre la vista de solo lectura UNIFIED_AUDIT_TRAIL (propiedad del usuario SYS). Esta tarea de “flushing” la realiza un nuevo proceso background llamado Gen0 (General Task Execution process) que continuamente, en un intervalo de 3 segundos, realiza la escritura sobre dicha vista.

Como la vista es completamente de sólo lectura, no hay posibilidad que el usuario SYS realice ninguna modificación, voluntaria o no, sobre la misma. Si por algún motivo se requiere vaciar la información de la SGA manualmente, esto puede hacerse utilizando el paquete DBMS_AUDIT_MGMT como se muestra a continuación,

SQL>Exec SYS.DBMS_AUDIT_MGMT.Flush_Unified_Audit_Trail;
 

No debería haber ninguna necesidad de utilizar de manera explícita el paquete ya que ese intervalo predeterminado de 3 segundos se supone suficiente para capturar toda la información de auditoría necesaria.

Como se mencionó anteriormente, la información de auditoría es capturada en primera instancia en colas de memoria en la SGA. Cuando una cola se llena, su contenido es descargado (GEN0) y el cliente, por ejemplo RMAN, puede utilizar la otra cola para continuar almacenando su información de auditoría. Puesto que la captura de esta información de auditoría no necesariamente es un  proceso síncrono y al ejecutarse el mismo en tal corto intervalo de tiempo, no tiene impacto negativo en el rendimiento de la base de datos. La memoria asignada por defecto dentro de la SGA para las colas es de 1 MB y puede ser configurada por el DBA con el parámetro UNIFIED_AUDIT_SGA_QUEUE_SIZE (el valor máximo permitido es de 30 MB). La decisión para cambiar la memoria asignada debe hacerse en base a la cantidad esperada de información de auditoría que se generará. Para la mayoría de los sistemas, el valor por defecto de 1 MB debería ser suficiente.

Hay dos modos en los que operan las colas de auditoría en la SGA: inmediato (Immediate) y encolado (Queued). Dependiendo del modo definido, la información de auditoría es descargada de manera inmediata o se vacía cada cierto intervalo. El modo por defecto es de encolamiento (queued) el cual hace que la información sea vaciada a  disco sólo cuando las colas en memoria están completas. El modo de escritura inmediata tiene una manera de escribir la información mucho más agresiva y, en  consecuencia, podría llegar a afectar al rendimiento de manera significativa si la cantidad de información generada es alta. Se puede variar entre ambos modos de escritura utilizando el paquete DBMS_AUDIT_MGMT.

Podemos ver en el código de abajo como se habilita el modo de escritura IMMEDIATE modificando la configuración por defecto.

SQL>EXECUTE DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(-
DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED, -
DBMS_AUDIT_MGMT.AUDIT_TRAIL_WRITE_MODE, -
DBMS_AUDIT_MGMT.AUDIT_TRAIL_IMMEDIATE_WRITE);
 

Utilizando el mismo paquete, puede ser habilitado nuevamente el modo default Queued-Write.

Vale la pena mencionar que como la información de auditoría es generada y capturada primero en la SGA, si ocurre un “crash” de instancia dentro del intervalo de timeout de 3 segundos  podría producirse la pérdida de los datos de ese período de tiempo. Pero teniendo en cuenta que ese intervalo es bastante corto, se supone que no debería haber una gran cantidad de datos de auditoría perdidos, si es que pudiera existir alguno!

Este tema seguirá siendo desarrollado en dos ediciones adicionales a la presente. Si ya haz leído esta podrás continuar con la Parte II.



Joel Pérez es un experto DBA (Oracle ACE Director, OCM Cloud Admin. & OCM11g) con más de 14 años de experiencia real en el mundo de tecnología Oracle, especializado en diseño e implementación de soluciones de: Cloud, Alta disponibilidad, Recuperación contra desastres, Upgrades, Replicación y toda área relacionada con bases de datos Oracle. Consultor Internacional con trabajos, conferencias y actividades relacionadas en más de 50 países alrededor del mundo. Habitual Orador en eventos Oracle alrededor del mundo como: OTN LAD, OTN MENA, OTN APAC y más. Joel se ha caracterizado siempre por ser un pionero en materia de tecnología Oracle desde los inicios de su carrera siendo el primer latinoamericano en ser nombrado "OTN Expert" en el año 2003, uno de los primeros Oracle ACE en el programa ACE en el año 2004, unos de los primeros OCP Cloud en el mercado global en el año 2013 y como uno de los mayores logros de su carrera, recientemente en el 2014 fue honorificado como uno de los primeros "OCM Database Cloud Administrator" del mundo. En la actualidad Joel Pérez esta radicado en el continente de Asia con base en Beijing, China llevando a cabo operaciones profesionales en alianza con una de las mayores compañías de consultoría Oracle en China "Enmotech". http://education.oracle.com/education/otn/JoelPerez.htm

Aman Sharma es un especialista en Oracle Database, Oracle Certified Professional (9i, 10g, 11g), un experto certificado de Oracle para Linux, SQL y Sun Certified System Admin con más de 6 años de experiencia. Aman trabaja como instructor de la formación de profesionales en todo Asia Pacífico en tecnología Oracle. Antes de esto, trabajó como un DBA para una gran empresa de desarrollo de software. En su tiempo libre, cuando Aman no está enseñando o de viaje, le gusta pasar tiempo en varios foros de Oracle a través de Internet.

Karan Dodwal (OCM) es un arquitecto especializado en Alta Disponibilidad de Oracle. Senior OCM DBA Oraclecon varios años de experiencia en el area de desarrollo y administración de base de datos Oracle. Trabaja como consultor Oracle. Ha brindado diversos servicios y capacitaciones sobre los productos de Oracle en Asia Pacífico, Asia del Sur y la Gran China. Es ponente del Grupo de Usuarios "All India Oracle Users Group (North India Chapter)". Ha realizado configuraciones de Oracle de alta disponibilidad en todas las plataformas de misión crítica de Oracle Database. Él es un experto en todas las soluciones de alta disponibilidad de Oracle como RAC, Exadata, Data Guard y otros. Con frecuencia publica artículos en varios sitios web y en su blog: http: //karandba.blogspot.in. Participa activamente en eventos de grupos de usuarios y participa de forma frecuente en foros de OTN.

Sebastián D'Alessandro es un Senior DBA con más de 12 años de experiencia en tecnología Oracle, focalizado principalmente en seguridad de base de datos, soluciones de alta disponibilidad, disaster recovery y virtualización. Actualmente desarrolla su actividad como consultor e instructor de manera independiente.

Este artículo ha sido revisado por el equipo de productos Oracle y se encuentra en cumplimiento de las normas y prácticas para el uso de los productos Oracle.