Multitenant: Conversión de NonCDB a PDB

#OracleTIPSSV

#OracleACEPRO

#26082024

En este ejercicio vamos a ver los pasos para convertir una BD Noncdb de cualquier version hacia PDB , para el caso, si la DB es 12c y la CDB destino es 19c, obvio yo sugiero que hay hacer el upgrade primero.

Primero validamos todos los componentes se encuentran en estado valido y mas importante, esta cantidad de componentes debe ser igual a los componentes que la CDB tiene instalados y funcionando.

DBA_REGISTRY

CATALOG Oracle Database Catalog Views 12.2.0.1.0 VALID
CATPROC Oracle Database Packages and Types 12.2.0.1.0 VALID
XDB Oracle XML Database 12.2.0.1.0 VALID
OWM Oracle Workspace Manager 12.2.0.1.0 VALID
JAVAVM JServer JAVA Virtual Machine 12.2.0.1.0 VALID
XML Oracle XDK 12.2.0.1.0 VALID
CATJAVA Oracle Database Java Packages 12.2.0.1.0 VALID
APEX Oracle Application Express 18.1.0.00.45 VALID
RAC Oracle Real Application Clusters 12.2.0.1.0 VALID

— Si es RAC asegurarse de tener solo una instancia encendida, asegurarse de que el OMF el db_create_file_dest este definido apuntando al diskgroup.

Procedimiento

Existen varias formas de pegar una NonCDB a PDB,

Copia , el método de copia se asegura de dejar la BD original intacta pero es mas tardado. El Reuso, método de reuso no tiene punto de retorno, pues utiliza los datafiles actuales.

Para realizar el procedimiento de reuso de archivos.

Procedimiento de clonación en bd01

1 Apagamos la BD y la ponemos en Read ONLY para que el SCN en la cabecera de todos los datafiles este sincronizado al mismo valor con el control file.

export ORACLE_SID=bd01
sqlplus / as sysdba
SHUTDOWN IMMEDIATE;
STARTUP OPEN READ ONLY;

2 crear manifiesto
el archivo que contiene el descriptivo de la bd sus datafiles, objetos, SCN , etc etc.

BEGIN
DBMS_PDB.DESCRIBE(
pdb_descr_file => ‘/tmp/bd01.xml’);
END;
/

En este caso activamos el modo archive, y creamos los redolog de 4g porque estaban de menos tamaño.

3 shutdown bd01

export ORACLE_SID=db12c
sqlplus / as sysdba
SHUTDOWN IMMEDIATE;

4 en cdb destino

Observar la respuesta de YES en el plsql anónimo siguiente:

SET SERVEROUTPUT ON;
DECLARE
compatible CONSTANT VARCHAR2(3) := CASE DBMS_PDB.CHECK_PLUG_COMPATIBILITY(pdb_descr_file => '/tmp/bd01.xml')
WHEN TRUE THEN 'YES'
ELSE 'NO'
END;
BEGIN
DBMS_OUTPUT.PUT_LINE(compatible);
END;
/
SQL> SQL> 2 3 4 5 6 7 8 9 YES

5. Para chequear imcompatibilidad de PDB a pegar

SQL> select message from PDB_PLUG_IN_VIOLATIONS where type='ERROR' and status ='PENDING';
no rows selected

6. Revisar los dbfiles de la cdb destino para que pueda albergar los datafiles que vienen de la NONCDB.

show parameter db_file, si no es suficiente aumentar valor

NOTA
CREATE PLUGGABLE DATABASE pbd01 USING ‘/tmp/bd01.xml’ nocopy;

LEER ADENDA AL FINAL

Cuando se ocupa nocopy en la sentencia de create plugable database, los tempfile si estan en asm u OMF daran error

1>CREATE PLUGGABLE DATABASE pbd01 USING '/tmp/bd01.xml' nocopy;
CREATE PLUGGABLE DATABASE pbd01 USING '/tmp/bd01.xml' nocopy
*
ERROR at line 1:
ORA-27038: created file already exists
ORA-01119: error in creating database file
'

Solucion ver documento: “Failure In Creating PDB With Temp Files Stored In ASM / OMF Format From Non-CDB Using NOCOPY Option (Doc ID 2778041.1)”
Below bug was opened with our development team:

BUG 26621022 – NEW TEMPFILES ARE CREATED NOT REUSED USING CREATE PLUGGABLE ..TEMPFILE REUSE
Above bug was closed by our development team stating it as expected behavior. In order to resolve this issue,
we can use either of below solutions:
Make sure sufficient free space available in the desired ASM disk group or filesystem (in case of OMF).
or
Delete the TEMP tablespace temp files from source Non-CDB database environment after generating
the XML file and then shutting down the Non-CDB database.


Hay que borrar los tempfiles de la bd origen en el FS datastore después de generar el xml, después de apagar la instancia y antes de pegarla en la cdb

Query para monitorear avance de copia en CDB

select opname, sid, serial#, sofar, totalwork, time_remaining,time_remaining/60 fm,time_remaining/60/60 fh, message
from v$session_longops where time_remaining > 0;

7. Cuando termine, se abre la PDB recién pegada

alter pluggable database pbd01 open;
alter session set container=pbd01 ;

8.Validar violación al pegar pdb

No debe devolver filas, si hay filas debe analizarse cada situación contra MOS.

column message format a50
column status format a9
column type format a9
column con_id format 9
select con_id, type, message, status
from PDB_PLUG_IN_VIOLATIONS
where status='PENDING' and type='ERROR' and con_id=3
order by time;
SQL> SQL> SQL> SQL> 2 3 4
no rows selected

9.Script de no marcha atrás: finalización de paso a PDB.

Este script se asegura de crear el diccionario de datos de los objetos permisos, etc que vienen de la NONCDB a PDB.

Yo no se pero en mi experiencia aun hay cositas que le faltan pulir a la PDB , aun en 19c.

@?/rdbms/admin/noncdb_to_pdb.sql

——- el TEMPFILE debe tener espacio suficient een la pdb. mas de 5g.
64GB en PDB y 32Gb en CDB y 20GB al tempo.
–para ejemplo:

alter database tempfile '+dg/tempfile.2.1106479113' resize 31g;

10.Validar fallas en pegado y script final

No debe devolver filas

Observese que hay restricciones de OPEN MODE

     2 PDB$SEED                       READ ONLY  NO
     3 pbd01                        MIGRATE    YES
SQL> column message format a50
column status format a9
column type format a9
column con_id format 9
select con_id, type, message, status
from PDB_PLUG_IN_VIOLATIONS
where status='PENDING' and type='ERROR' and con_id=3
order by time;SQL> SQL> SQL> SQL> 2 3 4
no rows selected

SQL> alter session set container=pbd01;

Session altered.

SQL> column message format a50
column status format a9
column type format a9
column con_id format 9
select con_id, type, message, status
from PDB_PLUG_IN_VIOLATIONS
where status=’PENDING’ and type=’ERROR’ and con_id=3
order by time;SQL> SQL> SQL> SQL> 2 3 4

no rows selected


11. validar open mode y que este RW sin restricciones

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 – Production
Version 19.12.0.0.0

SQL> show pdbs;

CON_ID CON_NAME                       OPEN MODE  RESTRICTED

     2 PDB$SEED                       READ ONLY  NO
     3 pbd01                        READ WRITE NO
SQL> alter session set container=pbd01;
Session altered.

PASO MIL.

Abrir la PDB en RW en todos los nodos en todas las instancias si fuera RAC y guardar el estatus.

alter pluggable database pbd01 open instances=all;
alter pluggable database pbd01 save state instances=all;
Pluggable database altered.

SQL> show pdbs;

CON_ID CON_NAME                       OPEN MODE  RESTRICTED

     2 PDB$SEED                       READ ONLY  NO
     3 pbd01                        READ WRITE NO

Espero les sea de utilidad

ADENDA

Puede usarse la instrucción de pegado que pega copiando los datafiles, dejando los originales intactos, esto facilita un método de reversa sin restaurar de backup.

CREATE PLUGGABLE DATABASE pdb6 USING '/tmp/db12c.xml'
COPY
FILE_NAME_CONVERT = ('/rutaCDB/', 'ruta_PDB/');

puede usarse OMF para definir la ruta de crecion, especialmente si es ASM Diskgroup.

Oracle Database Security : Native Network Encryption.

#OracleTIPSV

#ORACLEACEPRO

#25/08/2024

Siguiendo con la serie de artículos de seguridad en la Base de Datos Oracle, vamos a tratar el tema de la seguridad de los datos en el trafico de red.

En un entorno natural en el que se ve involucrada una Base de Datos Oracle, la comunicación es siempre establecida usando el protocolo OracleNet que no es mas que el trafico basado en TCP, por lo cual dicho trafico puede interceptarse por un agente externo no autorizado y descifrar el contenido y hacerlo legible con el objetivo de extraer informacion de forma no autorizada.

Existen mas de un método para cifrar el trafico que se consume de una base de datos Oracle, pero nos centraremos en el ofrecido de forma nativa por Oracle Database: Native Network Encryption.

Al aplicar dicha configuración el flujo de trafico se denota porque no puede leerse dado que ya no viaja plano si no cifrado.

Vamos a validar, me conecto a una BD remota en la Nube de Oracle, no precisamente el funciona solo a dicho tipo de plataformas, pero todavía es una mejor prueba dado que el trafico va por internet.

Ejecuto un SQL a una tabla y observamos sus filas devueltas.

Durante reejecute los statements, previamente active el sniffer para capturar paquetes TCP, mi ambiente es OSX y use tcpdump, para linux funcionaria, para Solaris SNOOP, esta herramienta necesita activar el modo promiscuo de la interfaz y necesita privilegios elevados.

Aquí envíe el trafico capturado al archivo channel-11

El contenido del archivo de trafico se observa así, lo cual personal de redes puede entenderlo mejor, pero aun así no cumple el objetivo en el entendimiento de las tramas para mi Demostración.

Para nuestro caso, utilice una herramienta un poco mas avanzada llamada WireShark ( Un compañero de Redes me enseño a usarla).

Resultado de las filas

Como puede observarse abajo del lado derecho en la imagen de arriba, puede observase el resultado de las filas, de la misma forma puede observarse las encabezados de columnas, el statement o instrucción enviada al motor y de la misma forma, usuarios y passwords.

Para configurar la opción del lado del motor, es tan simple como agregar un parametro en el sqlnet.ora en el $OH del RDBMS.

Encryption_server y types_server para controlas el algoritmo.

Del lado del cliente también debe configurarse la opción:

Hay que denotar las palabras clave required y requested.

Requerido del lado del motor obligara que todas las conexiones obliguen al cifrado en el ingreso de la sesión; solicitado, permitirá aceptar conexiones cifradas y no cifradas.

Al activar la característica, y volver a examinar el trafico de red, ya no logramos leer los paquetes ya muestra texto ilegible.

Algo Importante la característica Native Network Encryption es gratis desde 11.2, ya no forma parte de la opción Advanced Security Option (ASO).

Puede leerse del sitio de información de licenciamiento.

https://apex.oracle.com/pls/apex/features/r/dbfeatures/licenses?license_id=92

La característica funciona tanto para conexiones usando TNSNAMES de forma nativa, para JDBC OCI y/o THIN.

Tomado del sitio Oficial:

https://docs.oracle.com/en/database/oracle/oracle-database/18/dbseg/configuring-thin-jdbc-client-network.html#GUID-96B18FF8-611F-46BC-B7D3-217023234BCB

Saludos, espero les sea de utilidad.

Oracle Data Redaction : Previniendo que se consulten datos no autorizados a observar.

#################

redaction, #OracleACEPRO, #OracleTIPSSV, 23jul2024

#################

Que es la redacción?

Es una característica de Base de Datos que permite colocar un lente ( así lo llamo yo) enfrente de los datos, dicho lente permite que se observen los datos reales o no, dependiendo el origen de la conexión, el usuario que consulta, etc etc, siendo las propiedades de la sesión las posibles variables que permiten consultar los datos al natural redactados.

Usuarios autorizados de consulta podrán observar los datos de forma normal , mientras los que no, observaran patrones generados con informacion totalmente transformada , parcial, etc, dependiendo del patron.

Existen diferentes tipos de patrones para la transformación ( porque eso es la redacción).

PERO HAY QUE HACER MENCION: LA REDACCION ES PURAMENTE VISUAL, TOTALMENTE ONLINE.

De la pagina de la documentación oficial:

Beneficios

Preparación de la DEMO:

Creamos 2 usuarios

--drop user testuser1 cascade;
create user testuser1 identified by testuser1 quota unlimited on users;
grant create session, create table to testuser1;
--drop user testuser2 cascade;

create user testuser2 identified by testuser2 quota unlimited on users;

grant create session to testuser2;

drop table payment_details purge;

create table payment_details (

  id          number       not null,

  customer_id number       not null,

  card_no     number       not null,

  card_string varchar2(19) not null,

  expiry_date date         not null,

  sec_code    number       not null,

  valid_date  date,

  constraint payment_details_pk primary key (id)

);

Nos conectamos e insertamos datos:

conn testuser1/testuser1

insert into payment_details values (1, 4000, 1234123412341234, ‘1234-1234-1234-1234’, trunc(add_months(sysdate,12)), 123, null);

insert into payment_details values (2, 4001, 2345234523452345, ‘2345-2345-2345-2345’, trunc(add_months(sysdate,12)), 234, null);

insert into payment_details values (3, 4002, 3456345634563456, ‘3456-3456-3456-3456’, trunc(add_months(sysdate,12)), 345, null);

insert into payment_details values (4, 4003, 4567456745674567, ‘4567-4567-4567-4567’, trunc(add_months(sysdate,12)), 456, null);

insert into payment_details values (5, 4004, 5678567856785678, ‘5678-5678-5678-5678’, trunc(add_months(sysdate,12)), 567, null);

commit;

alter session set nls_date_format=’dd-mon-yyyy’;

column card_no format 9999999999999999

SQL> 

SQL> 

set linesize 200

SQL> /

Ahora vamos a agregar una simple regla de protección que impida que al conectarse desde una IP especifica los datos se observen naturales.

begin

  dbms_redact.add_policy(

    object_schema => user,

    object_name   => ‘payment_details’,

    column_name   => ‘card_no’,

    policy_name   => ‘redact_card_info’,

    function_type => dbms_redact.full,

    expression=> ‘sys_context(”userenv”,”IP_ADDRESS”) = ”192.168.1.1”’

  );

end;

/

Si desearemos borrar la politica seria:

begin

  dbms_redact.drop_policy (

    object_schema => user,

    object_name   => ‘payment_details’,

    policy_name   => ‘redact_card_info’

  );

end;

/

Al consultar los datos desde la IP indicada:

TOAD EN MI PC

        ID CUSTOMER_ID    CARD_NO CARD_STRING         EXPIRY_DATE   SEC_CODE

———- ———– ———- ——————- ———– ———-

VALID_DATE

———-

         1        4000          0 1234-1234-1234-1234 27-JUN-25          123

         2        4001          0 2345-2345-2345-2345 27-JUN-25          234

         3        4002          0 3456-3456-3456-3456 27-JUN-25          345

         4        4003          0 4567-4567-4567-4567 27-JUN-25          456

         5        4004          0 5678-5678-5678-5678 27-JUN-25          567

5 rows selected.

Al consultar desde otro servidor en la Nube de Oracle

sqlplus testuser1/testuser1@//IPREMOTA:1521/orcl12c.us.oracle.com

SQL*Plus: Release 19.0.0.0.0 – Production on Thu Jun 27 23:43:37 2024

Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Last Successful login time: Thu Jun 27 2024 23:42:59 +00:00

Connected to:

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 – 64bit Production

With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

alter session set nls_date_format=’dd-mon-yyyy’;

column card_no format 9999999999999999

set linesize 200

select *

from   payment_details

order by id;   

Desde el propio servidor de base de Datos

alter session set nls_date_format=’dd-mon-yyyy’;

column card_no format 9999999999999999

set linesize 200

select *

from   payment_details

order by id; 

I

Como pudo observarse la redacción es una característica bastante util, transparente a las aplicaciones sin implicaciones de cambio de código y sin implicaciones de no poder alterar los datos, forma parte de la opción Advanced Security Option, de pago extra sobre Licencia de EE.

Espero les sea de utilidad.

saludos.

Prevención del hurto de información: Oracle TDE

Raúl Antonio Molina Alvarenga

05Ago024

#OracleACEPRO

#OracleTIPSSV

Tomado de:

https://docs.oracle.com/en/database/oracle/oracle-database/19/asoag/introduction-to-transparent-data-encryption.html

Este articulo se centra en la activación de una de las características de seguridad de la base de datos Oracle Enterprise Edition, Transparent Data Encryption, de la documentación Oficial:

Como mucha característica EE, de paga extra por la metrica de licenciamiento x el # de licencias adquiridas, y replicable a Contingencia, ambientes de desarrollo previos si se utilizan copias de RMAN.

Como primer paso hay que configurar el wallet, en versiones anteriores se usaba solo el sqlnet.ora pero pude percatarme según la guía que ahora se ocupa un parámetro de BD.

De la documentación, el wallet nos sirve para almacenar las claves de encriptación maestras y puede almacenarse en varios lados,

La encriptación puede hacerse a nivel de Columna o tablespace, se recomienda de tablespace porque es menos impactante en la operación que la de columnas.

La de columna encripta y decripta al momento de DMLs, la de tablespace no.

El funcionamiento de la encriptación de tablespaces con la llave maestra y su interacción con el wallet.

El wallet por defecto es un keystore que almacenara la información que permitirá encriptar y desencriptar los datos de la BD.

Solicitado por Luis Caballero, asegurese que el Keystore es autologin y no Local autologin , porque dicho WALLET agrega una validacion de HOST que no permite usarse en diferente maquina, ni siquiera en un Oracle RAC.

These keystores are as follows:

  • Auto-login TDE wallets: Auto-login TDE wallets are protected by a system-generated password, and do not need to be explicitly opened by a security administrator. Auto-login TDE wallets are automatically opened when accessed at database startup. Auto-login TDE wallets can be used across different systems. If your environment does not require the extra security provided by a keystore that must be explicitly opened for use, then you can use an auto-login TDE wallet. Auto-login TDE wallets are ideal for unattended scenarios (for example, Oracle Data Guard standby databases). 
  • Local auto-login TDE wallets: Local auto-login TDE wallets are auto-login TDE wallets that are local to the computer on which they are created. Local auto-login keystores cannot be opened on any computer other than the one on which they are created. This type of keystore is typically used for scenarios where additional security is required (that is, to limit the use of the auto-login for that computer) while supporting an unattended operation. You cannot use local auto-open wallets in Oracle RAC-enabled databases, because only shared wallets (in ACFS or ASM) are supported. 
  • Password-protected TDE wallets: Password-protected TDE wallets are protected by using a password that you create. You must open this type of keystore before the keys can be retrieved or used and use a password to open this type of keystore.

ALTER SYSTEM SET WALLET_ROOT = '/bkp/wallet' SCOPE = SPFILE SID = '*';
ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=FILE" SCOPE = BOTH SID = '*';

Luego de esto debemos configurar el password del keystore donde guardaremos la clave de encriptación maestra:

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE IDENTIFIED BY password;
ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE IDENTIFIED BY password;

Una vez configurado, se debe abrir el wallet para permitir operaciones de encriptación de columnas o tablespaces.

OJO o NOTA:DEBE CUIDARSE LA LLAVE MAESTRA PORQUE PUEDE SIGNIFICAR LA PERDIDA DE LA BD.

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY password;

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN 

FORCE KEYSTORE 

IDENTIFIED BY EXTERNAL STORE;

Una vez se ha creado el wallet y aperturado, este puede consultarse su estado en esta vista:

select * from  V$ENCRYPTION_WALLET;

Una vez tenemos abierto el Wallet y clave maestra asignada, podemos encriptar ya sea columnas o tablespaces, mi ejemplo en este articulo es para tablesapaces completos.

Ejecutamos la encriptación Online, lo cual requiere tanto espacio para la creación temporal de o los archivos ya cifrados.

ALTER TABLESPACE users  ENCRYPTION ONLINE ENCRYPT ;

Con una exploración en el Sistema Operativo podemos ver que el contenido del datafile del tablespace se vuelve ilegible y sin posibilidad de realizar ingeniería inversa.

Pero dirán, es un efecto simulado, vamos a probar algo para demostrar la característica,

create tablespace demo datafile '/bkp/oradata/orclcdb/demo01.dbf' size 10m autoextend on next 50m;
alter tablespace demo  add  datafile '/bkp/oradata/orclcdb/demo02.dbf' size 10m autoextend on next 50m;
create table dba_copia8 tablespace demo as select * from dba_objects;

SQL> select ENCRYPTED,tablespace_name from dba_tablespaces;

ENC TABLESPACE_NAME

— ——————————

YES SYSTEM

YES SYSAUX

YES UNDOTBS1

NO  TEMP

YES USERS

YES NEW_UNDO_TS

YES ENCRYPT_TS

NO  DEMO

8 rows selected.

SQL> 

Antes

Quiero resaltar el hecho que en el listado de resultado del select anterior, el datafile single del tablespace DEMO indica aun no esta encriptado.

Al consultar el contenido del datafile, de forma no autorizada con un tool del Sistema operativo, puede consultarse el contenido bastante legible en Humano.

Despues

ALTER TABLESPACE demo  ENCRYPTION ONLINE ENCRYPT ;

Ya al volver a consultar el contenido del datafile ya aparece encriptado.

Y una vez un tablespace ha sido encriptado, todo datafile que se agregue o crezca no pierde dicha propiedad y contenido protegido.

alter tablespace demo  add  datafile ‘/bkp/oradata/orclcdb/demo03.dbf’ size 10m autoextend on next 50m;

insert into  dba_copia8  select * from dba_objects;

Por ultimo, la propiedad de encriptado o cifrado puede revertirse en caso de ser necesario de la misma forma
Espero les sea de utilidad.