Oracle 12C, ¿Que es Multitenant?

Introducción a las bases de datos de contenedores (CDB) y bases de datos conectables (PDB)

Este artículo se va a centrar en repasar los conceptos básicos de as novedades que Oracle 12c ha introducido desde su liberación de la release 1. Oracle 12c R1 (12.1) introdujo la opción Multitenant. Este artículo proporciona una descripción general básica de la opción multiusuario, con enlaces a otros artículos más detallados sobre dicha funcionalidad, que serán elaborados más adelante.

Introducción

La opción Multitenant representa uno de los mayores cambios arquitectónicos en la historia de la base de datos Oracle. Con esta novedad se  presentaron los conceptos de la base de datos de contenedores (CDB) y la base de datos conectable (PDB).

¿Que entendemos por CDB?

CDB  es el acrónimo de Base de Datos de Contenedores, en apariencia esto parece muy similar a una base de datos Oracle convencional, ya que contiene la mayoría de las partes funcionales con las que ya estará familiarizado (archivos de control, archivos de datos, deshacer, archivos temporales, registros de rehacer, etc.) esto es:

• Controlfiles
• Datafiles
• Undo files
• Tempfiles

También alberga el diccionario de datos para aquellos objetos que son propiedad del contenedor raíz y aquellos que son visibles para todos los PDB.

¿Que entendemos por CDB?

PDB es el acrónimo de Base de datos conectable, dado que el CDB contiene la mayoría de las partes que funcionan para la base de datos, el PDB solo necesita contener información específica para sí misma. No necesita preocuparse por los archivos de control, rehacer registros y deshacer, etc. En su lugar, está compuesto de archivos de datos y archivos temporales para manejar sus propios objetos. Esto incluye su propio diccionario de datos, que contiene información sobre solo aquellos objetos que son específicos del PDB. Desde Oracle 12.2 en adelante, un PDB debería, tener un tablespace undo local.

Esta división del diccionario de datos entre objetos comunes, en el contenedor raíz, y objetos específicos de PDB, en el diccionario de datos del PDB, es muy importante, porque esta separación es lo que le da a la opción multiusuario su flexibilidad. Desde la perspectiva del PDB, el diccionario de datos es la unión de los diccionarios de datos raíz y PDB, por lo que internamente el PDB se parece mucho a una base de datos Oracle normal. Por ejemplo, las vistas DBA_% y ALL_% dentro del PDB aparecen igual que cualquier base de datos que no sea CDB.

Oracle Managed Files (OMF) y Multitenant

Oracle recomienda el uso de Oracle Managed Files (OMF) cuando se usa la arquitectura Multitenant, ya que simplifica varias funciones. Parece que el uso de OMF es obligatorio para algunas funcionalidades, como la funcionalidad de Contenedores de aplicaciones en Oracle 12.2.

Creación de bases de datos conectables (PDB)

Dado que la mayor parte de las piezas de trabajo ya están presentes en el contenedor raíz, la creación de un nuevo PDB es una tarea comparativamente rápida y sencilla. Al crear un PDP completamente nuevo, el PDB se crea como una copia de un PDB inicial, por lo que solo toma el tiempo que los archivos tarden en copiarse.

Creación

En lugar de crear un nuevo PDB desde la semilla, puede clonar desde un PDB ya existente.

Clonación

También es posible crear clones en un CDB remoto.

Clonación remota

Esto no solo permite que las bases de datos se muevan fácilmente, sino que también proporciona una forma alternativa de parchear y actualizar a versiones futuras. Aquí puede encontrar un ejemplo del uso de desenchufar / complemento para realizar un parche. Aquí se describe una discusión general del mecanismo de desconexión / complemento.

La conversión de una base de datos que no es de CDB a una base de datos conectable implica obtener una descripción de la base de datos que no es de CDB y usarla para conectarla a un CDB como un nuevo PDB. Este método se describe aquí.

Reubicar una base de datos conectable (PDB)

Desde Oracle 12.2 en adelante, es posible reubicar un AP, moviéndolo de un CDB a otro. Esto es significativamente más simple que hacer un unplug / plugin convencional.

Actualizar una base de datos conectable (PDB)

Desde Oracle 12.2 en adelante, es posible actualizar un PDB clonado desde el PDB de origen, siempre que solo se haya abierto en modo de solo lectura.

Base de datos proxy conectable (PDB)

Desde Oracle 12.2 en adelante, es posible crear un servidor proxy PDB, que es un esqueleto PDB que envía SQL a un PDB remoto para ser procesado. Esto le permite tener un punto final local para una base de datos remota.

Contenedores de aplicaciones

Oracle 12.2 presenta el concepto de contenedores de aplicaciones, que actúan como un contenedor mini-raíz. Se pueden usar para centralizar la configuración y las aplicaciones compartidas, que son utilizadas por sus PDB de aplicaciones dependientes.

Novedades en las vistas del diccionario de datos

La introducción de la opción multiusuario trae consigo una capa adicional de vistas de diccionario de datos, lo que permite generar informes a través del contenedor raíz y las bases de datos conectables (PDB). Ignorando las ediciones por el momento, las versiones anteriores tenían la siguiente jerarquía.

DBA_: todos los objetos en la base de datos.

|

--ALL_: Objetos accesibles para el usuario actual, incluidos los que posee el usuario actual.

  |

  --USER_: objetos propiedad del usuario actual.

Con Oracle 12c, se agrega una capa adicional a la jerarquía.

CDB_: todos los objetos en todos los contenedores * (root y todos los PDB).

|

--DBA_: todos los objetos en el contenedor actual (root o PDB).

  |

  --ALL_: objetos accesibles por el usuario actual en el contenedor actual (root o PDB), incluidos los que posee el usuario actual.

    |

    --USER_: objetos propiedad del usuario actual en el contenedor actual (root o PDB).

El resultado de las vistas CDB_ depende del contenedor desde el que se accede. Cuando se accede desde el contenedor raíz, de hecho presentan toda la información de todos los contenedores. Cuando se accede desde un AP, actúan efectivamente como las vistas DBA desde dentro del contenedor. Esto puede ser un poco confuso al principio.

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.

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.