La introducción de políticas de auditoría y la pista de auditoría unificada son las dos novedades, que aparecen en esta entrega de nuestra base de datos favorita. Que simplifican la configuración de la auditoría de bases de datos en Oracle 12c. La nueva funcionalidad de auditoría también se puede usar para crear políticas de auditoría de muy sencillas a muy complicadas, pero no creo que sea la forma en que la mayoría de la gente querrá abordarla, Una vez que hayas aprendido a andar, puedes empezar a correr y complicar tus políticas de auditoria, eso sí, bajo tu responsabilidad.
Si quieres saber más en profundidad acerca de la auditoria unificada en Oracle 12c, te recomiendo que sigas lo artículos de Joel Perez, Aman Sharma, Karan Dodwal y Sebastián D'Alessandro, en la technetwork de Oracle:
Creando Políticas de Auditoría
Al igual que la auditoría estándar anterior, que mencionamos en mi anterior artículo, la auditoría unificada se puede utilizar para crear reglas de auditoría extremadamente complejas. Como la documentación de Oracle para administrar las políticas de auditoría es muy buena, en lugar de tratar repetirla aquí, solo mostraré algunos ejemplos sencillos para despertar la curiosidad del lector.
Es mejor crear una política de auditoría que contenga todas las auditorías necesarias para una sesión, en lugar de usar varias políticas pequeñas. El uso de múltiples políticas genera una mayor sobrecarga de inicio de sesión, un mayor consumo de UGA y una funcionalidad de verificación de auditoría interna menos eficiente.
Una política de auditoría se compone de varias cláusulas distintas, algunas de las cuales son opcionales.
- privilege_audit_clause: se usa para especificar una lista de privilegios del sistema para auditar.
- action_audit_clause: define las acciones que necesitan ser auditadas. Estas pueden ser standard_actions, como DELETE, o específicas del objeto, como DELETE ON schema.table. También pueden ser componentes_actividades que se dirigen a funciones específicas como Data Pump o SQL * Loader.
- role_audit_clause: especifica una lista de roles. Todos los privilegios del sistema otorgados a través de esos roles son auditados.
- When ... Evaluate per: permite definir una condición de auditoría para determinar cuándo se realizará esta. La condición se puede evaluar para cada sentencia SQL, sesión en a base de datos o instancia de base de datos, según el nivel de granularidad que requiera la condición.
- CONTAINER: determina si una política de auditoría es específica para un PDB individual (CURRENT) o común a todos los AP (ALL).
Algunos de los siguientes ejemplos requieren estos tres usuarios de prueba.
Auditoría de privilegios
Como su nombre lo indica, la auditoría de privilegios le permite auditar el uso de los privilegios del sistema. La vista SYSTEM_PRIVILEGE_MAP identifica los privilegios del sistema que se pueden auditar.
Si queremos auditar la creación de tablas y secuencias por parte del usuario de ARTOS, podríamos hacer algo como lo siguiente.
Muestra la configuración de la política.
Conéctese con el usuario de ARTOS y cree algunos objetos.
Verifique la pista de auditoría. Si está en modo de escritura diferida (delayed-write), es posible que necesite vaciar la pista de auditoría antes de poder ver los registros de auditoría.
Componente de Auditoría de Acciones
En lugar de auditar acciones en objetos específicos, en su lugar puede auditar acciones relevantes para funcionalidades o utilidades específicas, tales como Oracle Label Security (OLS), Real Application Security, Database Vault, Data Pump o SQL * Loader. Hay dos ejemplos de auditoría de componente_acción vinculados a continuación.- Auditoría de Operaciones de Data Pump
- Auditoría de las cargas de ruta directa de SQL * Loader
Administración Unificada de la Pista de Auditoría
La administración de la auditoría unificada puede parecer un poco complicada al principio, pero hay algunas cosas que se deben tener en cuenta.- La auditoría unificada funciona de manera predeterminada, por lo que no necesita hacer nada para comenzar.
- La configuración predeterminada es correcta. Probablemente solo deba centrarse en sus políticas de auditoría específicas.
- Configurar un proceso de archivado y depuración necesitará algo de reflexión, pero probablemente solo lo haga una vez en la vida de su base de datos, así que no se asuste por este aspecto de la auditoría.
En los artículos referenciados más arriba encontrareis información en profundidad acerca de esta materia.
Seguridad de las pistas de auditoria
El mantenimiento del seguimiento de auditoría y las políticas de auditoría se limita a aquellos usuarios a los que se les haya otorgado el rol AUDIT_ADMIN.La función AUDIT_VIEWER se puede otorgar a los usuarios que necesitan ver la información de auditoría, pero no administrar el seguimiento de auditoría o las políticas de auditoría.
Bajo la auditoría unificada, los usuarios ya no pueden crear políticas de auditoría contra sus propios objetos. Para la compatibilidad con versiones anteriores, esto aún es posible para la auditoría tradicional. Esta es posiblemente una razón para alejarse de la auditoría en modo mixto.
Actualizaciones en 12.2
Una de las principales críticas de la auditoría unificada en 12.1 fue el rendimiento. En 12.2, la pista de auditoría unificada ahora reside en una tabla convencional llamada AUDSYS.AUD_$_UNIFIED. Cuando actualiza una base de datos, puede optar por migrar la información de auditoría existente a esta tabla utilizando TRANSFER_UNIDED_RECORDS en el DBMS_AUDIT_MGMT, que debería proporcionar un mejor rendimiento.
No hay comentarios:
Publicar un comentario
Por favor deja tu comentario, es valioso.