Raúl Antonio Molina Alvarenga
05Ago024
#OracleACEPRO
#OracleTIPSSV
Tomado de:
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 |