Mostrando entradas con la etiqueta Audit trail. Mostrar todas las entradas
Mostrando entradas con la etiqueta Audit trail. Mostrar todas las entradas

12 octubre 2018

Auditoría unificada en Oracle Database 12c


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.

La política de auditoria unificada es como un grupo de opciones de auditoria con diferentes condiciones. Para habilitar la auditoria, primero debe crear una política con diferentes opciones de auditoria y luego debe habilitar o deshabilitar para todos o pocos usuarios, según los requisitos que tengamos. Todos los registros de auditoria se almacenarán en la tabla UNIFIED_AUDIT_TRAIL

Por defecto, hay 7 políticas de auditoria que estarán presentes en una base de datos Oracle 12c.

En versiones anteriores a 12c, el DBA tiene a su disposición 5 tipos diferentes de  auditoria. Estas son:

Auditoria obligatoria: Este tipo de auditoria está siempre habilitada y monitoriza las operaciones que involucren el inicio o apagado 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 auditoria se habilita con el comando de AUDIT cuando es necesario auditar sentencias SQL, privilegios, objetos de esquema, y actividades de red o multicapa. Este tipo de auditoria se define y controla completamente a nivel de base de datos.



Auditoria 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 auditoria aprovecha la funcionalidad de los triggers de base de datos (construcciones PL/SQL que responden a eventos) para lograr este objetivo.



Auditoria de grano fino: La auditoria de grano fino se centra 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 auditoria cuando alguien trata de realizar acciones que responden a las condiciones especificadas en la definición de la política.



Auditoria SYS: Este tipo de auditoria en realidad permite monitorizar 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.

Auditoria mixta: por defecto está habilitada en 12c. Permite utilizar tanto la auditoria tradicional como los métodos de auditoria unificada. Es decir. Además de la auditoria tradicional, podemos usar todas las características de la auditoria unificada. Una vez que nos sentimos cómodos con el concepto unificado, podemos migrar la configuración de auditoria existente a una política unificada, podemos habilitar la auditoria pura.
Esto sirve como un buen mediador para un cambio fácil y sin problemas a la auditoria Unificada preferida.

Auditoria pura: una vez que se habilita la auditoria pura. No podemos utilizar los métodos de auditoria tradicionales.


  • Valor: FALSE  -> AUDITORIA MIXTA
  • Valor: TRUE   -> AUDITORIA PURA


¿Qué modo de auditoria unificado está habilitado para mi base de datos?


¿Cómo cambiar de una auditoria mixta a pura?



Políticas por defecto en la base de datos Oracle 12c:



Pero no todos están habilitados. Consulta AUDIT_UNIFIED_ENABLED_POLICIES para buscar, qué políticas están habilitadas.



Consulta para comprobar las opciones de auditoria incluidas en una política:



Incluso si no se crea una nueva política en la base de datos, la acción de auditoria de las opciones de auditoria anteriores se registrará en UNIFIED_AUDIT_TRAIL.

Eliminamos la política de auditoria:



Purgamos la pista de auditoria:



07 octubre 2018

Migrar de Oracle 11g a Oracle 12c: ¿Qué hacemos con la auditoria?



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.






27 noviembre 2017

Mejoras de auditoría (DBMS_AUDIT_MGMT) en Oracle Database 12c

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:

  • Oracle Database 12c: "Auditoria en 12c: Auditoría Unificada Parte I
  • Oracle Database 12c: "Auditoria en 12c: Auditoría Unificada Parte II
  • Oracle Database 12c: "Auditoria en 12c: Auditoría Unificada Parte III

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.

Los ejemplos de los usos se dan en las secciones a continuación, pero aquí hay un resumen rápido de ellos.


  • 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).
Esto puede sonar un poco confuso, pero si alguna vez ha utilizado la auditoría de bases de datos en versiones anteriores, rápidamente se verá bastante familiar. Lo más importante que debe recordar es que en lugar de emitir los comandos AUDIT / NOAUDIT directamente, usted crea una política de auditoría que contiene las piezas relevantes, luego la habilita y deshabilita usando los comandos AUDIT / NOAUDIT.

Algunos de los siguientes ejemplos requieren estos tres usuarios de prueba.


En algunos casos, el contenido de la pista de auditoría unificada se ha purgado entre las pruebas para mantener el resultado simple y específico para la funcionalidad que se 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.

Deshabilitar la política y eliminarla.







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.

26 noviembre 2017

Mejoras de auditoría (DBMS_AUDIT_MGMT) en Oracle Database 11g Release 2

Oracle, para la release 11g R1 activó la auditoría por defecto por primera vez. Oracle 11g Release 2 ahora permite una mejor administración de la pista de auditoría utilizando el paquete DBMS_AUDIT_MGMT.

Mover la pista de auditoría de base de datos a un espacio de tabla diferente

El procedimiento SET_AUDIT_TRAIL_LOCATION te permite modificar la ubicación de la pista de auditoría de base de datos (normal / detallada). Aunque no permite la alteración de la pista de auditoría del sistema operativo,  la documentación sugiere que esto puede suceder en el futuro. 
Este procedimiento acepta dos parámetros.

  • AUDIT_TRAIL_TYPE: tipo de pista de auditoría que se va a mover.
  • AUDIT_TRAIL_LOCATION_VALUE: el espacio de tabla al que deben moverse las tablas de seguimiento de auditoría.

El parámetro AUDIT_TRAIL_TYPE se especifica utilizando una de estas constantes.

  • DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: pista de auditoría estándar (AUD $).
  • DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: pista de auditoría detallada (FGA_LOG $).
  • DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: pistas de auditoría estándar y de grano fino.


Primero vemos la ubicación actual de las tablas de seguimiento de auditoría.

A continuación, creamos un nuevo tablespace para contener el seguimiento de auditoría.
Luego movemos la pista de auditoría estándar al nuevo espacio de tabla.
A continuación, movemos la pista de auditoría detallada.

Controlar el tamaño y la antigüedad de la pista de auditoría del sistema operativo

El procedimiento SET_AUDIT_TRAIL_PROPERTY le permite establecer el tamaño máximo y / o la edad de los archivos del registro de auditoría del sistema operativo. El procedimiento puede establecer parámetros para varios propósitos, pero restringiré la discusión solo a aquellos relevantes para esta sección. Se puede encontrar una lista completa de las constantes disponibles aquí.

El procedimiento acepta tres parámetros.
  • AUDIT_TRAIL_TYPE: el tipo de pista de auditoría a modificar (AUDIT_TRAIL_OS, AUDIT_TRAIL_XML o AUDIT_TRAIL_FILES).
  • AUDIT_TRAIL_PROPERTY: el nombre de la propiedad que se establecerá (OS_FILE_MAX_SIZE o OS_FILE_MAX_AGE).
  • AUDIT_TRAIL_PROPERTY_VALUE: el valor requerido para la propiedad.
Para verificar la configuración actual, consulte la vista DBA_AUDIT_MGMT_CONFIG_PARAMS.

Para estableder  el tamaño máximo de los archivos de auditoría del sistema operativo en 15,000 Kb, ejecuta el siguiente script:
Para establecer la edad máxima de los archivos de auditoría XML en 30 días, ejecuta el siguiente script.
El procedimiento CLEAR_AUDIT_TRAIL_PROPERTY se puede utilizar para eliminar las restricciones de tamaño y edad o restablecerlas a los valores predeterminados. Establecer el valor del parámetro USE_DEFAULT_VALUES en FALSE elimina las restricciones, mientras que establecerlo en TRUE devuelve la restricción al valor predeterminado.

Purga de registros de seguimiento de auditoría

Al igual que en versiones anteriores, puede eliminar manualmente registros de las tablas AUD $ y FGA_LOG $ y eliminar manualmente los archivos de auditoría del sistema de archivos, pero el paquete DBMS_AUDIT_MGMT le brinda algunos mecanismos nuevos y más seguros para mantener la pista de auditoría.

Inicializando la infraestructura de gestión

Para poder purgar la pista de auditoría de la base de datos, se debe realizar una inicialización única de la infraestructura de administración de auditoría. Esto se hace usando el procedimiento INIT_CLEANUP. El procedimiento acepta dos parámetros.
  • AUDIT_TRAIL_TYPE: la pista de auditoría a inicializar (constantes).
  • DEFAULT_CLEANUP_INTERVAL: El intervalo predeterminado en horas, después del cual el procedimiento de limpieza se debe volver a llamar (1-999).

El siguiente script SQL verifica la configuración de parámetros actual, inicializa la infraestructura de administración de auditoría para todas las pistas de auditoría con un intervalo predeterminado de 12 horas y vuelve a verificar la configuración.
Observa que el 'DB AUDIT TABLESPACE' para las pistas de auditoría de la base de datos no ha cambiado y que se ha establecido el 'INTERVALO DE LIMPIEZA POR DEFECTO' para las cuatro pistas de auditoría. El estado de inicialización actual de una pista de auditoría específica se puede verificar utilizando IS_CLEANUP_INITIALIZED.

Para desconfigurar la infraestructura de gestión de auditoría, ejecute el procedimiento DEINIT_CLEANUP.

Gestión de marca de tiempo

Lo siguiente a considerar antes de purgar la pista de auditoría es la cantidad de datos que desea depurar. El paquete DBMS_AUDIT_MGMT nos permite purgar todos los registros, o todos los registros anteriores a una marca de tiempo específica. La marca de tiempo en cuestión se especifica individualmente para cada pista de auditoría utilizando el procedimiento SET_LAST_ARCHIVE_TIMESTAMP, que acepta tres parámetros.
  • AUDIT_TRAIL_TYPE: el seguimiento de auditoría cuya marca de tiempo debe establecerse (constantes). Solo son válidos los registros de auditoría individuales, no las constantes que especifican los múltiplos.
  • LAST_ARCHIVE_TIME: se borrarán los registros o archivos anteriores a esta hora.
  • RAC_INSTANCE_NUMBER: opcionalmente especifique el nodo RAC para las pistas de auditoría del sistema operativo. Si no está configurado, asume la instancia actual.

Purga manual

El procedimiento CLEAN_AUDIT_TRAIL es el mecanismo básico para purgar manualmente el seguimiento de auditoría. Acepta dos parámetros.
  • AUDIT_TRAIL_TYPE: la pista de auditoría a purgar (constantes).
  • USE_LAST_ARCH_TIMESTAMP: establézcalo en FALSE para purgar todos los registros / archivos, o TRUE solo purgue los registros / archivos anteriores a la marca de tiempo especificada para la pista de auditoría.

Purga automatizada

El procedimiento CREATE_PURGE_JOB le permite programar un trabajo para llamar al procedimiento CLEAN_AUDIT_TRAIL. Al crear un trabajo de purga, puede especificar 4 parámetros.
  • AUDIT_TRAIL_TYPE: la pista de auditoría a purgar por el trabajo programado (constantes).
  • AUDIT_TRAIL_PURGE_INTERVAL: intervalo en horas entre purgas.
  • AUDIT_TRAIL_PURGE_NAME: un nombre para el trabajo de depuración.
  • USE_LAST_ARCH_TIMESTAMP: establézcalo en FALSE para purgar todos los registros / archivos, o TRUE solo purgue los registros / archivos anteriores a la marca de tiempo especificada para la pista de auditoría.



.




20 octubre 2017

Games of Roles (Season 2): Controla a tus super usuarios


Si deseas ver la primera arte de este artículo sigue este enlace.

Realms (Reinos)

Los usuarios con el rol DBA tienen los privilegios SELECT (y UPDATE, DELETE, o INSERT) ANY  TABLE y, por lo tanto, todavía pueden manipular datos en la tabla AHORROS, observa Cersei, preguntándose si hay una manera de evitarlo. Hay, responde Tycho. Implica crear un "círculo de protección" especial conocido como un Realm en Oracle Database Vault y colocar la tabla dentro de él. Solo el usuario administrador de Oracle Database Vault creado anteriormente, DVADMIN, puede crear dominios. Tycho inicia sesión como DVADMIN y ejecuta el SQL que se muestra en el Listado 1 para crear un Realm denominado BRAAVOS Schema Realm. El parámetro AUDIT_OPTIONS muestra qué nivel de auditoría debe habilitarse para las operaciones en el ámbito. Tycho elige crear pistas de auditoría solo para intentos fallidos de controlar la cantidad de información de seguimiento de auditoría generada. Menciona que luego explicará los detalles de la auditoría.


-- Listado1: Como DVADMIN, Crear un Realm
begin
 dbms_macadm.create_realm(
  realm_name    => 'BRAAVOS Schema Realm',
  description   => 'Realm for entire BRAAVOS schema',
  enabled       => dbms_macutl.g_yes,
  audit_options => dbms_macutl.g_realm_audit_fail, 
                  
  realm_type    => 1
 ) ;
end;
/
-- Como DVADMIN, añadir un objeto al Realm 
begin
  dbms_macadm.add_object_to_realm (
    realm_name   => 'BRAAVOS Schema Realm',
    object_owner => 'BRAAVOS',
    object_name  => 'ACCOUNTS',
    object_type  => 'TABLE'
  );
end;

/

A continuación, Tycho agrega la tabla CUENTAS al reino que acaba de crear, usando el SQL que se muestra en el Listado 2, nuevamente como el usuario DVADMIN. Después de eso, inicia sesión como usuario de WEBAPP1 e intenta seleccionar de la tabla:

-- Listado2: Como WEBAPP1
SQL> select * from Braavos.accountss;
select * from Braavos.savings
                   *
ERROR at line 1:
ORA-01031: insufficient privileges

Petyr está perplejo. Refiriéndose a la secuencia de comandos setup.sql, ella señala que el usuario de WEBAPP1 sí tiene privilegios SELECT en la tabla, por lo que la instrucción SELECT no debería haber fallado. El motivo es simple, explica Tycho: la tabla está protegida por el reino, que tiene prioridad sobre los privilegios típicos de la base de datos de Oracle. Tycho luego agrega al usuario WEBAPP1 como un usuario autorizado del reino, usando el SQL, tal y como e muestra a continuación.

-- Listado3: Añadiendo un usuario autorizado
begin
  dbms_macadm.add_auth_to_realm(
    realm_name    => 'BRAAVOS Schema Realm',
    grantee       => 'WEBAPP1',
    auth_options  => dbms_macutl.g_realm_auth_participant
  );
end;
/

Con el usuario de WEBAPP1 permitido dentro del dominio, se respetarán los privilegios típicos de la base de datos Oracle del usuario, como SELECT en la tabla. Debido a que ni siquiera los privilegios SYSDBA están permitidos dentro del reino, el poderoso privilegio del sistema SELECT ANY TABLE no sirve para las tablas dentro de ese reino y, por lo tanto, su instrucción SELECT falla con un error de "privilegios insuficientes",  lo que Cersei, nuestra auditora IT, quería.

Vistas del diccionario de datos de Oracle.


Cersei y Petyr ahora son visiblemente felices; ambos obtuvieron lo que querían. Pero tienen más preguntas: ¿Cómo conocemos los distintos reinos, quiénes son los usuarios autorizados, etc.? Hay varias vistas de diccionario de datos, explica Tycho. Señala algunas importantes que son propiedad de un esquema llamado DVSYS, que se crea cuando Oracle Database Vault está activado:
  • DVSYS.DBA_DV_REALM muestra todos los reinos creados.
  • DVSYS.DBA_DV_REALM_OBJECT muestra los objetos dentro de un reino.
  • DVSYS.DBA_DV_REALM_AUTH muestra a todos los usuarios autorizados para acceder a los objetos en los reinos.

Informes de auditoría

Cersei recuerda a todos que un requisito muy importante es capturar el historial de los cambios y las infracciones, los rastros de auditoría, de tal manera que el administrador de seguridad, pero no el usuario de DBA, pueda verlos. Es posible, continúa Tycho, a través de dos clases principales de pistas de auditoría (audit trails):

  • Auditoría de configuración Esta ruta de auditoría registra los cambios en varios elementos de configuración, como los reinos creados, los usuarios autorizados y los objetos ubicados en los reinos. El recorrido está disponible como una vista DV $ CONFIGURATION_AUDIT en el esquema DVSYS. Esta política de auditoría no se puede desactivar. Todos los cambios a la configuración de Oracle Database Vault serán capturados.
  • Auditoría de cumplimiento. Esta ruta de auditoría registra las actividades realizadas en la base de datos relacionadas con Oracle Database Vault. Está disponible a través de la vista DV $ ENFORCEMENT_AUDIT en el esquema DVSYS. El Listado 4 muestra la declaración de SQL que Tycho usa para ver las acciones que causaron una violación de dominio en esta pista de auditoría. Apuntando al primer registro en la salida, muestra que el usuario de WEBAPP1 emitió la declaración
  • SELECT * FROM BRAAVOS.ACCOUNTS, el 17-DEC-15 a las 08.11.31.123646 PM y recibió un error ORA-1031 (privilegios insuficientes). Esto es cuando el usuario de WEBAPP1 aún no estaba autorizado para el reino y trató de seleccionar de la tabla AHORROS. Esta vista tiene varias columnas valiosas, incluidas OS_USERNAME, USERHOST e INSTANCE_NUMBER, que muestran el nombre de usuario del sistema operativo que emitió la instrucción, el nombre del sistema del cliente y la Id. De la instancia (para una base de datos Oracle Real Clusters de aplicaciones [Oracle RAC]) respectivamente .
Comprobación de un rastro de auditoría para las vulneraciones de dominio de la base de datos Oracle Vault
-- Listado4: Como DVADMIN
select extended_timestamp, username, action_command, returncode
from dvsys.dv$enforcement_audit
where action_name = 'Realm Violation Audit'
and action_object_name = 'BRAAVOS Schema Realm'
order by 1,2,3
/

Rules (Reglas) 


Una de las políticas permanentes de la operación de TI en Braavos es rechazar cualquier operación de lenguaje de definición de datos (DDL) durante la semana, para evitar problemas de rendimiento y posibles ataques contra la base de datos. Actualmente, esta política se aplica a través de disparadores de DDL después de nivel de esquema que simplemente generan una excepción cuando las sentencias DDL se ejecutan durante los días laborables. Pero estos disparadores son propiedad de SYS, observa Cersei, por lo que los DBA pueden potencialmente manipular el efecto de estos desencadenantes, incluso incluso suprimirlos. Para reducir la posibilidad de que una cuenta poderosa como el DBA provoque un ataque, y con un espíritu de segregación de deberes, Cersei se pregunta si sería posible hacer cumplir esta política, no a través de desencadenantes propios de SYS, y por lo tanto, imposibilitaría que el política a ser influenciada por los DBA.

-- Listado5:Como DVADMIN, Configuración de reglas en Oracle Database Vault
-- Primero crea una regla
begin
   dvsys.dbms_macadm.create_rule (
      rule_name => 'Weekday',
      rule_expr => 'to_char(sysdate,''DY'') not in
             (''MON'',''TUE'',''WED'',''THU'',''FRI'')'
          );
end;
/
-- Luego crea un conjunto de reglas
begin
   dvsys.dbms_macadm.create_rule_set(
      rule_set_name => 'WEEKDAY_RULE_SET',
      description   => 'Weekday',
      audit_options => dbms_macutl.g_ruleset_audit_fail +
                      
      enabled       => dbms_macutl.g_yes,
      eval_options  => dbms_macutl.g_ruleset_eval_any,
      fail_options  => dbms_macutl.g_ruleset_fail_silent,
      fail_message  => 'Security Doesn''t Allow This Operation on a Weekday',
      fail_code        => 20001,
      handler_options  => dbms_macutl.g_ruleset_handler_off,
      handler          => ''
   );

   dvsys.dbms_macadm.add_rule_to_rule_set(
      rule_set_name => 'WEEKDAY_RULE_SET',
      rule_name     => 'Weekday',
      rule_order    => 1
   );
end;
/

-- Cree una regla de comando que impida que la tabla truncar
begin
   dvsys.dbms_macadm.create_command_rule(
       command=> 'TRUNCATE TABLE',
       rule_set_name => 'WEEKDAY_RULE_SET',
       object_owner => 'BRAAVOS',
       object_name => '%',
       enabled => 'Y'
   );
end;   
/

Es, asegura Tycho, con reglas en Oracle Database Vault. Tycho configura la regla que se muestra en el Listado 5, utilizando los siguientes pasos:

  • Cree una regla que muestre el período permitido. Para el ejemplo, Tycho especifica que el período no es un día laborable.
  • Cree un conjunto de reglas. Tycho especifica que cuando se infringe la regla, el usuario debe obtener un error ORA-20001 con este mensaje personalizado: "La seguridad no permite esta operación en un día laborable".
  • Agregue la regla al conjunto de reglas.
  • Cree una "regla de comando" en Oracle Database Vault que impida una acción específica. Para el ejemplo, Tycho elige evitar TRUNCATE TABLE en todas las tablas del esquema de BRAAVOS.
  • Después de configurar la regla, Tycho inicia sesión como el usuario WEBAPP1. La reunión de hoy es un día laborable, por lo que emite el siguiente SQL:


SQL> truncar la tabla Braavos.t1;
tabla truncada Braavos.t1
                    *
ERROR en la línea 1:
ORA-47306: 20001: la seguridad no permite esta operación en un día laborable


La operación falla y el mensaje de salida proporciona una explicación bastante clara. La aplicación de esta regla se realiza a través de Oracle Database Vault, no desencadenadores, por lo que los usuarios de DBA no pueden alterar la configuración o ignorar esta regla. Solo los administradores de Oracle Database Vault pueden cambiarlo. Las reglas se pueden definir para cualquier tipo de cheque, explica Tycho, como verificar una dirección IP específica. Cersei no podría estar más feliz.