Mejores prácticas de enmascaramiento de datos

Muchas organizaciones arriesgan inadvertidamente la información cuando rutinariamente copian datos de producción sensibles o regulados en entornos que no son de producción. Como resultado, los datos en el entorno de no producción se han convertido cada vez más en el blanco de los delincuentes y pueden ser robados. Al igual que las brechas de datos en entornos de producción, las violaciones de datos en entornos no productivos pueden causar millones de euros en sanciones y causar daños irreparables a la reputación y la marca.

Con Oracle Data Masking, la información sensible y valiosa puede ser reemplazada por valores realistas. Esto permite que los datos se utilicen con seguridad en no producción e incumplimiento con requisitos regulatorios como Sarbanes-Oxley, PCI DSS, HIPAA y en breve la GDPR.

Este artículo describe las mejores prácticas para implementar Oracle Data Masking para proteger la información confidencial en bases de datos Oracle y otras bases de datos heterogéneas como IBM DB2, Microsoft SQL Server.

Las empresas comparten datos de sus aplicaciones de producción con otros usuarios para una variedad de necesidades empresariales.

• Las empresas minoristas comparten datos de puntos de venta con los investigadores de mercado para analizar los patrones de compra de los clientes.
• Las organizaciones farmacéuticas o de salud comparten los datos de los pacientes con los investigadores médicos para evaluar la eficacia de los ensayos clínicos o los tratamientos médicos.
• Las empresas para mantenerse competitivas requieren una funcionalidad nueva y mejorada en las aplicaciones de producción existentes. Como resultado, los desarrolladores de aplicaciones requieren un entorno que imita cerca de la producción para crear y probar la nueva funcionalidad asegurando que la funcionalidad existente no se rompa.

Como resultado de lo anterior, las organizaciones copian datos confidenciales de clientes y consumidores en entornos que no son de producción y muy pocas compañías hacen algo para proteger estos datos, incluso cuando comparten con terceros.

Enmascarar datos en entornos no productivos.

Las organizaciones han tomado estas amenazas en serio y se han propuesto abordar estas cuestiones tan pronto como sea posible conocer las ramificaciones. A pesar de esto, la idea de eliminar información sensible del entorno de no producción parece ser sencilla, pero puede plantear serios desafíos en varios aspectos.

Identificación de información confidencial.

• ¿Qué define la información sensible?
• ¿Dónde reside?
• ¿Cómo se hace referencia?

El desafío también se convierte en mantener el conocimiento de metadatos de la arquitectura de la aplicación a lo largo de su ciclo de vida.

El proceso de enmascaramiento ha de ser tal que la integridad de la aplicación se vuelve primordial. Como ejemplo, enmascarar una parte de la dirección de un cliente, como zip sin considerar la ciudad y el estado, puede hacer que la aplicación sea inutilizable. Por lo tanto el desarrollo o la prueba se vuelven si no imposible, no confiable.La auditoría es otro desafío que se considera seriamente. Saber quién cambió qué y cuándo se convierte en un importante requisito de control de negocios para demostrar el cumplimiento de las regulaciones y leyes.

Para implementar estos controles, se ha de instaurar:

El desafío se convierte en separaciones de deberes, permisos basados en roles y la capacidad de reportar sobre estas actividades.

Las bases de datos se están volviendo muy grandes y la frecuencia de solicitudes para un entorno seguro no relacionado con la producción ha aumentado drásticamente a lo largo de los años. La razón de este aumento es que las empresas desarrollen aplicaciones nuevas y mejores que presten servicios a sus clientes a un ritmo más rápido para mantenerse competitivas. Un proceso de enmascaramiento debe tener un rendimiento aceptable y confiabilidad.

Y, finalmente, tener una solución flexible que puede evolucionar con la aplicación y extenderse a otras aplicaciones dentro de una empresa se convierte en un reto importante para abordar.

La solución más común: scripts de base de datos. A primera vista, una ventaja del enfoque de scripts de base de datos parecería que se refieren específicamente a las necesidades de privacidad de una base de datos específica para la que fueron diseñados. Pueden incluso haber sido ajustados por un DBA para correr en su más rápido

Veamos los problemas con este enfoque.

• Reutilización: No hay capacidades comunes en un script que pueden ser fácilmente apalancadas en otras bases de datos.
• Transparencia: Como los scripts tienden a ser programas monolíticos, los auditores no tienen transparencia en los procedimientos de enmascaramiento utilizados en los scripts. Los auditores encontrarían extremadamente difícil ofrecer cualquier recomendación sobre si el proceso de enmascaramiento incorporado en un guión es seguro y ofrece a la empresa el grado apropiado de protección.
• Mantenimiento: cuando se actualizan estas aplicaciones empresariales, se pueden agregar nuevas tablas y columnas que contienen datos confidenciales como parte del proceso de actualización. Con un enfoque basado en secuencias de comandos, todo el guión tiene que ser revisado y actualizado para acomodar nuevas tablas y columnas agregadas como parte de un parche de aplicación o una actualización.

Implementación de la máscara de datos

Con estos desafíos empresariales en mente, Oracle ha desarrollado un enfoque integral de 4 pasos para implementar el enmascaramiento de datos a través de Oracle Data Masking Pack llamado: Find, Assess, Secure y Test (F.A.S.T). Estos pasos son:

• Buscar: Esta fase implica la identificación y catalogación de datos sensibles o regulados en toda la empresa. Normalmente llevado a cabo por analistas de negocios o de seguridad, el objetivo de este ejercicio es crear una lista exhaustiva de elementos de datos confidenciales específicos de la organización y descubrir las tablas, columnas y relaciones asociadas a las bases de datos empresariales que contienen los datos confidenciales.

• Evaluar: En esta fase, los desarrolladores o DBAs en conjunto con los analistas de negocios o de seguridad identifican los algoritmos de enmascaramiento que representan las técnicas óptimas para reemplazar los datos sensibles originales. Los desarrolladores pueden aprovechar la biblioteca de enmascaramiento existente o ampliarla con sus propias rutinas de enmascaramiento.

• Seguro: Este y el siguiente paso pueden ser iterativos. El administrador de seguridad ejecuta el proceso de enmascaramiento para proteger los datos confidenciales durante las pruebas de enmascaramiento. Una vez que el proceso de enmascaramiento ha finalizado y se ha verificado, el DBA entrega el entorno a los probadores de aplicaciones.

• Prueba: En el paso final, los usuarios de producción ejecutan procesos de aplicación para probar si los datos enmascarados resultantes pueden ser entregados a otros usuarios que no producen. Si las rutinas de enmascaramiento necesitan ser ajustadas aún más, el DBA restaura la base de datos al estado pre-enmascarado, corrige los algoritmos de enmascaramiento y vuelve a ejecutar el proceso de enmascaramiento.

La base de datos Oracle y GDPR, una introducción

El Reglamento General de Protección de Datos (Reglamento de la UE 2016/679) es el nuevo marco jurídico de la UE que rige el uso de los datos personales. Este texto deroga la actual Directiva 95/46/CE de protección de datos y sustituye a las leyes de protección de datos nacionales existente (En España, la Ley 15/1999 de Protección de Datos). El texto será aplicable en todos los estados de la Unión Europea de desde 25 de mayo de 2018.

La Unión Europea (UE) introdujo su norma de protección de datos hace 20 años a través de la Directiva 95/46 / CE sobre protección de datos. Debido a que una Directiva permite a los Estados miembros un cierto margen de maniobra al aplicarla en el Derecho nacional, Europa ha terminado con un mosaico de diferentes leyes de privacidad. Además, el aumento de las brechas de seguridad, los rápidos avances tecnológicos y la globalización en los últimos 20 años ha traído nuevos retos para la protección de los datos personales. En un esfuerzo por abordar esta situación, la UE desarrolló el Reglamento General de Protección de Datos (GDPR).

¿Qué debemos hacer ahora para prepararnos para el GDPR?

• Implementar medidas de seguridad desde el diseño y por defecto en todos los procesos del tratamiento mediante procedimientos y sistemas que garanticen la protección de datos y el ejercicio de los derechos de los interesados.

• Realizar un análisis de los riesgos que atañen al tratamiento y prevenir su impacto para garantizar los derechos y las libertades de las personas que puedan ser afectadas, asumiendo que la protección de datos es mucho más que un cumplimiento formal y documental.

¿Qué puede hacer Oracle para prepararnos para el GDPR?

El GDPR es aproximadamente de tres a cuatro veces la longitud de la Ley de Protección de Datos (LOPD) de  1998 que está reemplazando.

Los requisitos para las bases de datos son:

• Descubrimiento
• Clasificación
• Enmascaramiento
• Supervisión
• Informes de auditoría
• Respuesta y notificación de incidentes

La sanción máxima por incumplimiento es del 4% del ingreso anual o de 20 millones de euros, el que sea mayor. Pueden aplicarse multas inferiores al 2% para las infracciones administrativas, como no realizar evaluaciones de impacto o notificar a las autoridades o particulares en caso de incumplimiento de los datos. Esto pone las penas de protección de datos en la misma categoría que la anticorrupción o el cumplimiento de la competencia.

Lo que los DBA deben comenzar ahora es cuenta e identificar el 100% de los datos privados ubicados en todas las bases de datos.

Hay cuatro categorías principales en las que participará DBA. 

1. Evaluar
2. Evitar
3. Detectar
4. Maximizar la protección

Las principales bases legales para el procesamiento de datos son el consentimiento y la necesidad. Los datos pueden ser reconocidos como una necesidad si:

• Se relaciona con la ejecución de un contrato
• Ilustra el cumplimiento de una obligación legal
• Protege los intereses vitales del titular de los datos u otra persona
• Se relaciona con una tarea que es de interés público
• Se utiliza para fines de interés legítimo perseguido por el responsable del tratamiento o por un tercero (en caso de que los derechos de la persona afectada lo anulen)

Las solicitudes de acceso de los sujetos de los datos deben ser respondidas dentro de un mes y sin cargo alguno. Esta es una nueva legislación dentro del GDPR y el mismo plazo de un mes se aplica a la rectificación de datos inexactos.

Las notificaciones de infracción deben hacerse dentro de las 72 horas siguientes a la toma de conciencia. Si no se cumple este plazo, se puede imponer una multa de 10 millones de euros, o el 2% del volumen de negocios global. Un incumplimiento es cualquier falla de seguridad que conduzca a la destrucción, pérdida, alteración, divulgación no autorizada o acceso a datos personales. Las autoridades supervisoras deben ser notificadas si una violación resulta en un riesgo para los derechos y libertades de las personas.

Los datos almacenados de forma encriptada o seudónima no se consideran datos personales y quedan fuera del ámbito de aplicación de estas nuevas normas. A pesar de esto, los datos cifrados y considerados seguros utilizando la tecnología de hoy en día pueden volverse legibles en el futuro. Por lo tanto vale la pena considerar el formato que preserva la encriptación / o usar pseudónimos que los hacen anónimos, pero permite al procesamiento seleccionado de esos datos.

Oracle Database 12c R1: TDE en Pluggable Databases (PDBs)

La base de datos Oracle 12c introdujo una nueva forma de administrar almacenes de claves claves cifradas y datos a securizar mediante el comando:

• ADMINISTER KEY MANAGEMENT. 

Esto reemplaza los comandos:

• ALTER SYSTEM SET ENCRYPTION KEY
• ALTER SYSTEM SET ENCRYPTION WALLET 

para la administración de claves y wallets de versione anteriores La terminología de la documentación mezcla libremente los términos wallet y keystore, pero la intención parece ser pasar al término keystore, de acuerdo con la terminología de Java.

La arquitectura de múltiples terminales complica un poco la gestión de claves, ya que el contenedor raíz necesita un almacén de claves abierto con una clave de cifrado principal activa. El almacén de claves CDBs se utiliza para almacenar claves de cifrado para todos los PDB asociados, pero cada uno necesita su propia clave de cifrado principal. La clave de cifrado maestro para el PDB se debe exportar antes de una operación de desenchufado, por lo que se puede importar después de una operación de complemento posterior.

Aquí vamos a describir las operaciones de administración de claves básicas que se relacionan con Transparent Data Encryption (TDE). Algunas de las funcionalidades del keystore que vamos a ver en el presente artículo son:

• Localización del Almacén de claves
• Como crear un Almacén de claves
• Usar el Keystore para  implementar la opción TDE
• Usar PDBs Con la opción TDE
• Auto-Login en Almacenes de claves

Localización del Almacén de claves

Se debe crear un almacén de claves para mantener la clave de cifrado. El orden de búsqueda para encontrar el almacén de claves es el siguiente.

• Si está presente, la ubicación especificada por el parámetro ENCRYPTION_WALLET_LOCATION en el archivo "sqlnet.ora".
• Si está presente, la ubicación especificada por el parámetro WALLET_LOCATION en el archivo "sqlnet.ora".
• La ubicación predeterminada para el almacén de claves. Si se establece $ ORACLE_BASE, esto es "$ ORACLE_BASE / admin / DB_UNIQUE_NAME / wallet", de lo contrario es "$ ORACLE_HOME / admin / DB_UNIQUE_NAME / wallet", donde DB_UNIQUE_NAME proviene del archivo de parámetros de inicialización.

Los almacenes de claves no se deben compartir entre los CDB, por lo que si se ejecutan varios CDB desde el mismo ORACLE_HOME, debe realizar una de las siguientes acciones para mantenerlos separados.

• Utilice la ubicación predeterminada keystore, por lo que cada base de datos CDB tiene su propia almacén de claves.
• Especifique la ubicación mediante el método $ ORACLE_SID

ENCRYPTION_WALLET_LOCATION =
  (SOURCE =(METHOD = FILE)(METHOD_DATA =
    (DIRECTORY = /u01/app/oracle/admin/$ORACLE_SID/encryption_keystore/)

• Tenga un "sqlnet.ora" por separado para cada base de datos, asegurándose de que la variable TNS_ADMIN está establecida correctamente.

Independientemente de dónde coloque el almacén de claves, asegúrese de no perderlo. Oracle 12c es extremadamente sensible a la pérdida del keystore. Si lo pierdes o cometes un error tendrás que tener que recrear la instancia limpia una y otra vez.

Crear un Almacén de claves

Debemos de editar el fichero sqlnet.ora, añadiendo la siguiente entrada al fichero:

ENCRYPTION_WALLET_LOCATION =
  (SOURCE =(METHOD = FILE)(METHOD_DATA =
    (DIRECTORY = /u01/app/oracle/admin/$ORACLE_SID/encryption_keystore/)

Crea el directorio para mantener el almacén de claves.

mkdir -p /u01/app/oracle/admin/$ORACLE_SID/encryption_keystore

Conecta al contenedor raíz y crea el almacén de claves

CONN / AS SYSDBA

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/oracle/admin/cdb1/encryption_keystore/' IDENTIFIED BY myPassword;

HOST ls /u01/app/oracle/admin/cdb1/encryption_keystore/

ewallet.p12

SQL>

Puedes abrir y cerrar el almacén de claves desde el contenedor raiz usando los siguientes comandos. 

Para abrir:

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY myPassword CONTAINER=ALL;

Para cerrar:

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY myPassword CONTAINER=ALL;

Es necesario crear y activar una clave maestra en el contenedor de raíz y una en cada una de las bases de datos conectables. Utilizar la cláusula CONTAINER = ALL lo hace en un solo paso. Si se omite la cláusula CONTAINER = ALL, sólo se realizará en el contenedor actual y se deberá volver a realizar para cada PDB individualmente. La información sobre la clave maestra se muestra usando la vista V $ ENCRYPTION_KEYS.

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY myPassword WITH BACKUP CONTAINER=ALL;

SET LINESIZE 100

SELECT con_id, key_id FROM v$encryption_keys;

    CON_ID KEY_ID

---------- ------------------------------------------------------------------------------

         0 AdaYAOior0/3v0AoZDBV8hoAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

         0 AYmKkQxl+U+Xv3UHVMgSJC8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA

SQL>

La información sobre el almacén de claves se muestra usando la vista V $ ENCRYPTION_WALLET.

SET LINESIZE 200

COLUMN wrl_parameter FORMAT A50

SELECT * FROM v$encryption_wallet;

WRL_TYPE             WRL_PARAMETER                                      STATUS                         WALLET_TYPE          WALLET_OR FULLY_BAC     CON_ID

-------------------- -------------------------------------------------- ------------------------------ -------------------- --------- --------- ----------

FILE                 /u01/app/oracle/admin/cdb1/encryption_keystore/    OPEN                           PASSWORD             SINGLE    NO                 0

SQL>

Conectar al PDB. Si no creó la clave en el paso anterior, cree una nueva clave maestra para el PDB.

CONN sys@pdb1 AS SYSDBA

SELECT con_id, key_id FROM v$encryption_keys;

    CON_ID KEY_ID

---------- ------------------------------------------------------------------------------

         0 DSrc9RAE//v/jcxEDSGIEEEEEEEEEEEEEEEEEEEEEEEEEEE

SQL>

Usar el Almacén de claves con la opción TDE

Ahora debe ser capaz de crear una tabla con una columna cifrada en el PDB.

CONN test/test@pdb1

-- Encrypted column

CREATE TABLE tde_test (

  id    NUMBER(10),

  data  VARCHAR2(50) ENCRYPT

);

INSERT INTO tde_test VALUES (1, 'This is a secret!');

COMMIT;

También podemos crear tablespaces cifrados

CONN sys@pdb1 AS SYSDBA

CREATE TABLESPACE encrypted_ts

DATAFILE SIZE 128K

AUTOEXTEND ON NEXT 64K

ENCRYPTION USING 'AES256'

DEFAULT STORAGE(ENCRYPT);

ALTER USER test QUOTA UNLIMITED ON encrypted_ts;

CONN test/test@pdb1

CREATE TABLE tde_ts_test (

  id    NUMBER(10),

  data  VARCHAR2(50)

) TABLESPACE encrypted_ts;

INSERT INTO tde_ts_test VALUES (1, 'This is also a secret!');

COMMIT;

Si se reinicia el PDB, el almacén de claves debe abrirse en el PDB antes de que se pueda acceder a los datos.

CONN sys@pdb1 AS SYSDBA

SHUTDOWN IMMEDIATE;

STARTUP;

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY myPassword;

CONN test/test@pdb1

SELECT * FROM tde_test;

        ID DATA

---------- --------------------------------------------------

         1 This is a secret!

SQL>

SELECT * FROM tde_ts_test;

        ID DATA

---------- --------------------------------------------------

         1 This is also a secret!

SQL>

Si se reinicia el CDB, el almacén de claves debe estar abierto tanto en el CDB como en los PDB.

CONN / AS SYSDBA

SHUTDOWN IMMEDIATE;

STARTUP;

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY myPassword CONTAINER=ALL;

CONN test/test@pdb1

SELECT * FROM tde_test;

        ID DATA

---------- --------------------------------------------------

         1 This is a secret!

SQL>

SELECT * FROM tde_ts_test;

        ID DATA

---------- --------------------------------------------------

         1 This is also a secret!

SQL>

Auto-Login en Almacenes de claves

La creación de un almacén de claves de inicio automático significa que ya no es necesario abrir explícitamente el almacén de claves después de reiniciarlo. La primera referencia a una clave hace que el almacén de claves se abra automáticamente, como se muestra a continuación.

CONN / AS SYSDBA

ADMINISTER KEY MANAGEMENT CREATE LOCAL AUTO_LOGIN KEYSTORE FROM KEYSTORE '/u01/app/oracle/admin/cdb1/encryption_keystore/' IDENTIFIED BY myPassword;

SHUTDOWN IMMEDIATE;

STARTUP

CONN test/test@pdb1

SELECT * FROM tde_test;

        ID DATA

---------- --------------------------------------------------

         1  Esto es un texto secreto

SQL>

SELECT * FROM tde_ts_test;

        ID DATA

---------- --------------------------------------------------

         1 Esto es otro texto secreto

SQL>

Java Forensics en bases de datos Oracle

Esta vez quiero mostrar cómo determinar si los ataques de privilegio de Java se han producido en su base de datos, tanto como medida de precaución como para el análisis forense después del incidente, con el fin de verificar si un ataque de esta naturaleza ha ocurrido o no.

En primer lugar veamos la situación en la que un atacante utiliza DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY para concederse a sí mismos cualquier privilegio Java de CREATE SESSION debido a ejecutar DBMS_JVM_EXP_PERMS.

Si su base de datos está recogiendo mensajes de error a continuación, busca errores del tipo ORA-29532:

SQL> DECLARE  
  2  POL DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY;  
  3  CURSOR C1 IS SELECT 'GRANT','JAVATEST','SYS','java.io.FilePermission','$','execute',
                        'ENABLED' FROM DUAL;  
BEGIN  
OPEN C1;  
  4    5  FETCH C1 BULK COLLECT INTO POL;  
  6  CLOSE C1;  
DBMS_JVM_EXP_PERMS.IMPORT_JVM_PERMS(POL);  
  7    8  END;  
  9  / 10  
DECLARE  
*  
ERROR at line 1:  
ORA-29532: Java call terminated by uncaught Java exception:  
java.lang.SecurityException: policy table update java.lang.RuntimePermission,  
loadLibrary.*  
ORA-06512: at "SYS.DBMS_JVM_EXP_PERMS", line 189  
ORA-06512: at line 8 

La escalada de privilegios aún ha tenido éxito por lo que el mensaje de error es un poco engañoso, pero podría ser un indicador útil.

SQL>  SELECT TYPE_NAME, NAME, ACTION FROM USER_JAVA_POLICY WHERE GRANTEE_NAME ='JAVATEST';  
  
TYPE_NAME  
--------------------------------------------------------------------------------  
NAME  
--------------------------------------------------------------------------------  
ACTION  
--------------------------------------------------------------------------------  
java.io.FilePermission  
 $ 
execute  

Vamos a centrarnos en la identificación de la escalada de privilegios de Java. 
Una vez que se han asignado privilegios de Java existen múltiples formas de utilizar el privilegio de ganar SYSDBA, y una vez adquirido, el atacante tendría limpiar el rastro que habían dejado atrás, primero instalando un rootkit, y luego revocar privilegios y eliminando las cuentas que se crearon en el camino. 

Así, el reto de un investigador forense es buscar pistas que un atacante puede no haber sido lo suficientemente diligente para limpiar. 

Así, en primer lugar, ¿cómo podemos saber si un usuario se ha concedido privilegios Java? DBA_JAVA_POLICY es la vista fundamental, y esto muestra amablemente todos los privilegios concedidos por orden cronológico de Java utilizando el número de secuencia de incrementar…

SELECT TYPE_NAME, NAME, ACTION FROM USER_JAVA_POLICY WHERE GRANTEE_NAME ='JAVATEST';  
  
TYPE_NAME  
--------------------------------------------------------------------------------  
NAME  
--------------------------------------------------------------------------------  
ACTION  
--------------------------------------------------------------------------------  
java.io.FilePermission  
ALL FILES
execute 

Así que si un atacante sabe esto, es probable que ha ga drop de a cuenta de ataque y lo recrea si es necesario como parte de un ataque posterior. Sin embargo, si nos fijamos en la tabla base sys.java $ policy $ para la vista DBA_JAVA_POLICY, veremos que la tabla realmente persiste en las concesiones de Java, incluso después de que el usuario haya sido eliminado !!! Esto es útil para una investigación posterior a incidentes.

SELECT * FROM sys.java$policy$ ORDER BY key DESC;  
  
KIND#   GRANTEE#    TYPE_SCHEMA#    TYPE_NAME   NAME    ACTION  STATUS# KEY  
-----------------------------------------------------------------------------------------------------  
0   101 0   java.io.FilePermission  ALL FILES   execute 2   282  
0   100 0   java.io.FilePermission  ALL FILES   execute 2   262  
0   54  0   java.io.FilePermission  ALL FILES   execute 2   242  
  
--Note that the GRANTEE# correlates to the sys.user$.USER# column and we can see   
-- that user 101 and 100 both had execute on ALL FILE   
-- ,but these users no longer exist in sys.user$ and still the privs are recorded in sys.java$policy$ ~which could be very useful info..  
  
SQL> select name from sys.user$ where user# in (101, 100);  
  
no rows selected  
  
SQL> select name from sys.user$ where user# in (54);  
  
NAME  
------------------------------  
SCOTT  
  
--Of course a clever attacker that had gained SYS could delete from the base table..  
  
SQL> delete from sys.java$policy$ where key='242';  
  
1 row deleted.  
  
SQL> commit;  
  
Commit complete.  
  
--And the evidence of the escalation has gone.. How would an investigator see that the table had been modified in this case?   
--Tracing back further it would hopefully be possible to use the dba_tab_modifications view:  
  
SQL> SELECT * FROM dba_tab_modifications WHERE table_name='JAVA$POLICY$'  
  2  ;  
  
no rows selected  
--This empty result set is due to the fact that MONITORING is not set on this table by default. This could be rectified as follows in this example.  
SQL> exec dbms_stats.gather_table_stats ('SYS','JAVA$POLICY$');  
  
PL/SQL procedure successfully completed.  
  
SQL> delete from sys.java$policy$ where key='282';  
  
0 rows deleted.  
  
SQL>  delete from sys.java$policy$ where key='242';  
  
1 row deleted.  
  
SQL> execute dbms_stats.flush_database_monitoring_info;  
  
PL/SQL procedure successfully completed.  
  
SQL> SELECT * FROM dba_tab_modifications WHERE table_name='JAVA$POLICY$';  
  
TABLE_OWNER     TABLE_NAME      PARTITION_NAME      SUBPARTITION_NAME  INSERTS    UPDATES    DELETES TIMESTAMP TRU DROP_SEGMENTS  
------------------------------ ------------------------------ ------------------------------ ------------------------------ ---------- ----------   
SYS                 JAVA$POLICY$                                           0          0          1        31-MAR-10 NO              0  
  
--It is unlikely that a DB will have had this default setting changed beforehand though..   
--So what else can be done to see if the DBA_JAVA_POLICY table has been changed recently?  
  
SQL> select scn_to_timestamp(Max(ora_rowscn)) from sys.java$policy$;  
  
SCN_TO_TIMESTAMP(MAX(ORA_ROWSCN))  
-----------------------------------------------------  
30-MAR-10 06.10.06.000000000 PM  

Nota: esta consulta normalmente trabajará hasta 7 días después de que el cambio haya ocurrido, por lo que si obtiene este error ORA-08181 la tabla probablemente no ha tenido comandos de manipulación de datos (DML) en él durante ese tiempo.

ORA-08181: specified number is not a valid system change number

ASO y HSM Wallet (Parte 1 de 2)

En el anterior artículo hablamos de cifrar datos mediante el uso de una fichero que almacena nuestra clave maestra (wallet), ahora veremos como asegurar ese fichero para, evitar ataques, es una capa más para tener mayores garantías de que nuestros datos están asegurados. 

Mini guía de Integración de Oracle Database con HSM Thales ncipher
Debido a anteriores experiencias laborales, estuve trabajando con esta tecnología, integrando los HSM de mi anterior compañía, Thales, con las Bases de Datos Oracle. HSM son las siglas de "Hardware Security Module" (Módulo de Seguridad Hardware).


Un HSM es un dispositivo criptográfico basado en hardware que genera, almacena y protege claves criptográficas y suele aportar aceleración hardware para operaciones criptográficas. Estos dispositivos pueden tener conectividad SCSI / IP u otras y aportar funcionalidad criptográfica de clave pública (PKI) de alto rendimiento que se efectúa dentro del propio hardware.

Oracle Database 11g Release 2 TDE cifra de forma transparente los datos que se almacenan en la base de datos Oracle, sin requerir ningún cambio de código en la aplicación que se ejecuta. Es compatible tanto con TDE cifrado de tabla y columna de cifrado TDE. El HSM asegura la clave maestra para cifrar tablespaces y tablas.

El HSM es usado en lugar del fichero Oracle Wallet para proveer un más alto nivel de garantía de seguridad, incluyendo:

• Almacenamiento centralizado y gestión de las claves maestras. El fichero de clave ya no está en servidor de base de datos, reside en el hardware.
• Gestión del ciclo de vida completo de la clave (s) de cifrado principal.
• Mayor nivel de garantía de la seguridad, las claves nunca se almacenan en el dispositivo como texto plano.
• Certificación FIPS 140-2 level 3 en el hardware. Añade resistencia a la intrusión física con fines de desmontaje o modificación, de manera que dificulta al máximo los ataques. Si se detecta la intrusión, el dispositivo debe ser capaz de borrar los parámetros de seguridad críticos. El Nivel 3 también incluye protección criptográfica eficaz y administración de claves, autenticación basada en la identidad y separación física o lógica entre las interfaces a través de las que se accede a los parámetros de seguridad crítica y se sale de ellos.
• Soporte de fallos.

 Dependiendo de cómo esté tu instalación de la base de datos esta pequeña guía servirá para:

• Crear e inicializar un nuevo Wallet protegido mediante un dispositivo HSM. Si no tienes ninguna tabla o tablespace cifrado.
• Migrar de un Oracle Wallet, que actualmente cifra tablas y tablespaces a un Wallet protegido mediante un HSM.

Al utilizar Oracle TDE, Yo recomiendo utilizar un fichero Wallet separada para almacenar la clave de cifrado principal. La integración entre el HSM y Oracle TDE utiliza la API criptográfica PKCS # 11. La integración ha sido probado con éxito en, y sólo se admite en las siguientes configuraciones:

Para integrar Oracle Database 11g Release 2 TDE con un HSM tendremos que pasar por las siguientes fases:

• Instalar Oracle Database 11g Release 2 y aplicar los correspondientes parches.
• Instalar el dispositivo HSM.
• Instalar el software de soporte y configurar el HSM.
• Configurar Oracle Database 11g Release 2 TDE para usar el HSM.

Nos centraremos únicamente en la configuración de la base de datos, dado, que los otros pasos se salen del ámbito de esta guía, instalar la base de datos es algo trivial y lo relacionado con los HSM de Thales  se salen de ámbito de este blog, para cualquier duda al respecto, deberéis consultar la web del fabricante, o consultar a algún experto.

Configurar Oracle Database 11g Release 2 TDE para usar el HSM

Copiar la librería  PKCS #11 localizada en  /opt/nfast/toolkits/pkcs11/libcknfast-64.so (o libcknfast.so dependiendo de la arquitectura de tu Sistema operativo) a una de las siguientes localizaciones dependiendo del sistema operativo:

• Red Hat Enterprise Linux 5 (x86) /opt/oracle/extapi/32/hsm/libcknfast.so
• Solaris 10 SPARC (64-bit) /opt/oracle/extapi/64/hsm/libcknfast-64.so
• IBM AIX (PPC64) /opt/oracle/extapi/64/hsm/libcknfast-64.so

Asegúrese de que el directorio existe y que oracle: oinstall es el propietario:grupo del

directorio con acceso de lectura.

Agregue el usuario oracle al grupo nFast. Puede verificar esta adición al ver la entrada correspondiente el grupo nFast en /etc/group.

En el archivo $TNS_ADMIN /sqlnet.ora  añadir o editar las líneas siguientes, dependiendo de si está migrando desde un Oracle wallet:

Autentícate en la base de datos usando uno de estos comandos:

• Si estás en la shell con UNIX: sqlplus / as sysdba
• Si estás en SQL*Plus: connect / as sysdba

Cree la clave de cifrado principal dentro del HSM usando uno de los siguientes comandos, dependiendo de cómo desea proteger la clave y si está migrando desde un Oracle wallet:

Protección mediante una tarjeta del juego de operador de HSM (OCS):

Protección de clave OCS requiere una tarjeta OCS para ser insertada en la ranura del módulo. Debe Especificar el nombre de la tarjeta OCS después de la clave de esta,  para identificar una tarjeta OCS en particular en el dominio de seguridad del HSM. 

En el archivo cknfastrc, debe establecer CKNFAST_LOADSHARING = 1

Protección mediante una tarjeta "soft", tarjeta virtual:

Protección de clave soft debe especificar el nombre de la tarjeta soft después de la clave de esta, en el archivo cknfastrc, debe establecer CKNFAST_LOADSHARING = 1

Protección solo HSM:

Esta forma admite cualquier clave dada, únicamente ha de ser alfanumérica de 8 dígitos, en el archivo cknfastrc, debe establecer CKNFAST_FAKE_ACCELERATOR_LOGIN=1

ASO y Oracle Database Vault (Prueba de concepto)

Hasta ahora hemos intentado cubrir ataques externos que vulneren la confidencialidad de nuestros datos, por eso ciframos los datos almacenados, mediante ka tecnología TDE de Oracle, pero la amenaza interna es la mas peligrosa y los DBAs, se han convertido por, culpa de algunos ejemplos de mala praxis, en fuente de inseguridad. Las regulaciones como Sarbanes-Oxley (SOX), la Ley de Portabilidad y Responsabilidad de Seguros de Salud (HIPAA), Basilea II y PCI-DSS tienen temas comunes que incluyen controles internos, separación de tareas y estrictos controles de acceso a la información sensible. 

Un buen CISO, que los hay, recomendaría usar políticas severas de auditorias a los superusuarios, como sysdba y sysadmin y para evitar a priori cualquier tentación recomendaría usar Oracle Database Vault, este producto brinda controles de seguridad flexible, transparente y altamente adaptable sin realizar cambios en la aplicación.

Pero Oracle Database Vault y la opción TDE de cifrado de tablespaces no son suficientes para ocultar datos de los administradores base de datos. Vamos a demostrarlo.

Descripción del entorno de laboratorio

• OS Oracle Linux Server release 6.3
• Database Oracle Database 11.2.0.4 EE with Database Vault and Transparent Data  Encryption

Detalles de la prueba de concepto

Queremos demostrar que ODV and TDE for tablespaces puede no ser suficiente para proteger los datos sensibles del “todopoderoso” sysdba. En este pequeño experimento hemos usado el esquema de ejemplo HR y su tabla EMPLOYEES para ilustrar esta incidencia en la seguridad de nuestros datos.

Vamos a suponer que mis datos sensibles son, por ejemplo, los números de teléfono de los empleados. He creado un ámbito (realm) que protege esquema HR conjunto, por lo que SYSDBA no tiene acceso a ella.

SQL> select user from dual; USER ----------- SYS SQL> select count(1) from hr.jobs; From hr.jobs            * ERROR at line 2; ORA-01031: insufficient privileges

La base de datos que estamos usando se ha habilitado el AMM (Gestión automática de la memoria de la SGA de la base de datos)

SQL> show parameters memory_target; NAME                                TYPE                    VALUE -------------------------           -------------              ----------------- Memory_target                 big integer             1520M SQL>

La tabla Employees esta en un tablespace cifrado, así que acceder al datafile no es posible.

SQL> select table_name, t.tablespace_name, ts.encrypted from DBA_TABLES, t, 2  DBA_TABLESPACES ts where t.tablespace_name=ts.tablespace_name and t.owner=’HR’ and 3   t.table_name=’EMPLOYEES’; TABLE_NAME                                   TABLESPACE_NAME                              ENC --------------------------                           ---------------------------------                          --------- EMPLOYEES                                     EMPLOYEES_AES128                            YES

Cuando estoy usando AMM en Linux, la memoria está representada por los archivos en  /dev/shm, que se puede comprobar mediante los comandos ipcs y lsof.

• lsof (Lista de archivos abiertos, en español) es una conocida herramienta de monitorización de sistemas operativos tipo Unix que se utiliza para mostrar todos los archivos de disco que mantienen abiertos los procesos, incluyendo los sockets de red abiertos, tuberías, entre otros tipos.
• ipcs: proporciona información sobre los recursos ipc para los cuales el proceso de llamada tiene derechos de lectura

Ahora un usuario conectado como HR hace una consulta sobre EMPLOYEES:

SQL> select user from dual; USER ------------- HR SQL> select phone_number from hr.jobs; PHONE_NUMBER ---------------------------- 650.507.9833 650.507.9844 515.123.4444 515.123.5555 . . .

Después de esta consulta que deberíamos tener los bloques del segmento EMPLOYEES copiados en el búfer cache. Ahora vamos a ver qué podemos hacer con él a nivel de sistema operativo sin ningún privilegio especial...

[oracle@dbaFhell]$ cd /dev/shm/ [oracle@dbaFhell]$ strings ora_orcl_* | egrep …^ {[0-9] {3}\.[0-9] {3}\.}\.[0-9] {4}$” | sort | uniq | tail -10 650.507.9833 650.507.9844 515.123.4444 515.123.5555

Conclusión

Cuando la base de datos Oracle está utilizando AMM en Linux (parámetro MEMORY_TARGET) Oracle Database Vault y TDE no es suficiente para mantener los datos confidenciales ocultos de administrador de base de datos

Si ellos saben lo que están buscando... y lo saben, ¿verdad?