[ 2015-06-20 ]

Oracle Database 12c: "Auditoria en 12c: Auditoría Unificada (Unified Auditing)" (Parte I)

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.


No hay comentarios:

Publicar un comentario