Si estas pensando en migrar a Oracle Database 12c, sin importar el tipo de entorno implicado (
desarrollo, prueba, certificación producción), una de las muchas decisiones que debes consolidar con tu equipo es definir qué hacer con la
auditoria. La nueva característica más importante en esta área es la denominada
Auditoría Unificada, que captura información de auditoria de diferentes fuentes, como por ejemplo registros de auditoria "normales" y FGA, contextos de aplicación, RMAN o DataPump más algunas otras y las almacena en un formato y lugar comunes. , que es de solo lectura, tabla particionada en el esquema
AUDSYS, que reside de forma predeterminada en el tablespace
SYSAUX y utiliza la función
Oracle SecureFiles.
Afortunadamente, Oracle nos dio flexibilidad en cuanto a las opciones de migración disponibles. Por ejemplo, en 12c todavía es posible utilizar la auditoría tradicional, de manera similar a como lo haciamos en la versión 11g. Incluso existe la posibilidad de realizar auditorias de modo mixto, en las que se completan las pistas de auditoria tradicionales y unificadas. Por supuesto, usar solo un enfoque unificado también es posible.
Independientemente del modo que desees utilizar después de la migración, es una buena idea habilitar la auditoria unificada desde el principio, volviendo a vincular los binarios de la base de datos con el parámetro
uniaud_on. Esto le permitirá evitar la no disponibilidad si decide realizar una auditoria unificada (
o de modo mixto) en una etapa posterior. Utilice la siguiente consulta para encontrar si está correctamente habilitado:
Todos los parámetros de inicialización de auditoria utilizados anteriormente:
- audit_trail
- audit_file_dest
- audit_sys_operations
- audit_syslog_level
No tienen significado (en caso de usar solo auditoria unificada). Sin embargo, todavía están disponibles, ya que son necesarios para los modos tradicional y mixto.
Teniendo en cuenta las migraciones, también debe decidir qué hacer con los registros de auditoria antiguos. Incluso cuando la auditoria tradicional está deshabilitada, todavía existe la posibilidad de archivar y luego purgar los registros de auditoria de las pistas de auditoria tradicionales utilizando el paquete dbms_audit_mgmt, por lo que podría hacerse antes, durante o después de la actualización.
¿Qué debería convencerlo de que la auditoria unificada es una mejora significativa en comparación con el enfoque tradicional?
Probablemente la ventaja más importante está incorporada en la palabra "unificada": el hecho de que todos los registros de auditoria están disponibles a través de la vista unificada_audit_trail y en el caso de un entorno multitenant en la vista cdb_unified_audit_trail, que proporciona registros de auditoria de cada PDB (disponible solo en la raíz). Parece que Oracle ha analizado todas las opciones y características de auditoria disponibles en versiones anteriores y ha diseñado la auditoria unificada como más consistente, segura y más fácil de administrar.
A partir de 12c, podría olvidarse del manejo diferente de los registros ubicados en aud $, fga_log $ o archivos del sistema operativo. Aún así, cuando la base de datos no se puede escribir (por ejemplo, cerrada, montada, abierta de solo lectura), los registros de auditoría se colocarán en archivos del sistema operativo (ubicados en $ ORACLE_BASE / audit / $ ORACLE_SID, que desafortunadamente parece no ser modificable). Se debe hacer de esa manera: es crucial para auditar operaciones como la conexión como sysdba, pero, por supuesto, no puede persistir en una base de datos que no se pueda escribir. Afortunadamente, actualmente existe la posibilidad de cargar archivos de auditoria ubicados en este directorio en la base de datos utilizando el procedimiento dbms_audit_mgmt.load_unified_audit_files. Posteriormente, podrían manejarse como otros registros de auditoria, sin la necesidad de implementar analizadores dedicados, etc.
Gestión de auditoria distinta, pero más sencilla
Hablando de una gestión de auditoria más fácil, debemos recordar no solo el manejo de los registros de auditoria, sino también la configuración de lo que se debe auditar. Es muy diferente en comparación con 11g, ahora se define en las políticas de auditoria. Podría tener muchas de estas políticas definidas y habilitarlas / deshabilitarlas de forma independiente, pero tenga en cuenta que, según la documentación de Oracle, la cantidad de políticas de auditoria habilitadas al mismo tiempo en la base de datos debe ser limitada.
Como puede encontrar en el archivo $ ORACLE_HOME / rdbms / admin / secconf.sql, hay 3 políticas de auditoría predeterminadas definidas para nuevas instalaciones de 12c:
- ora_account_mgmt
- ora_database_parameter
- ora_secureconfig.
Solo el último está habilitado de forma predeterminada, pero es una buena idea borrar la configuración predeterminada y usarla como punto de partida para diseñar su propia política de auditoria. Al hacer eso, tenga en cuenta que hay una serie de actividades que se auditan obligatoriamente.
La administración en términos de acceso a los datos de auditoria también se simplifica, gracias a la introducción de dos nuevos roles, con nombres autodescriptivos: audit_admin y audit_viewer.
Desde el punto de vista de la seguridad, esta era una limitación bastante grande, que actualmente, como resultado del nuevo diseño de la auditoria en la versión 12c de la base de datos, se ha eliminado.
