Alternativas a Oracle Data Masking: qué evaluar antes de migrar

Oracle Data Masking y Subsetting está limitado a sus propios motores de base de datos. Esta restricción, sumada a su licencia independiente y a la dependencia de Enterprise Manager, motiva la búsqueda de alternativas. Este artículo analiza los criterios de selección, el impacto operativo y la migración considerando las reglas y formatos que tus aplicaciones ya utilizan.

Si no partes de una arquitectura previa de la marca y buscas evaluar opciones desde el principio, te recomendamos revisar nuestra comparativa de software de enmascaramiento.

Por qué se busca una alternativa

Es un pack con licencia independiente

No forma parte de Oracle Database Enterprise Edition. El pack debe licenciarse para el servidor de base de datos donde se ejecutan las operaciones de enmascaramiento y subsetting, incluida la base intermedia de staging cuando se utiliza. Consultoras independientes de licenciamiento informan de un precio de lista de 11.500 USD por procesador, o 230 USD por Named User Plus sujeto a los mínimos de Oracle, con un soporte anual del 22 % del valor neto de la licencia.

El límite es donde se cae la mayoría de los equipos. La licencia sigue a la base de datos donde se ejecuta la operación, no al número de personas que la usan, así que un parque pequeño de bases Enterprise Edition multiplica el coste de lo que en el fondo es una sola tarea recurrente: refrescar entornos no productivos.

Depende de Oracle Enterprise Manager

El pack opera a través de Oracle Enterprise Manager Cloud Control. Para un equipo que ha llevado el aprovisionamiento a pipelines y a infraestructura como código, esto significa que un flujo se queda en una consola: alguien abre Enterprise Manager, ejecuta la definición de enmascaramiento y avisa al solicitante cuando el entorno está listo. La dependencia no es solo técnica. Determina quién puede refrescar un entorno y cuánto espera la petición.

Las fuentes no Oracle pasan por un gateway

Oracle soporta DB2, Informix, SQL Server, Sybase, MySQL y Teradata, pero la funcionalidad no puede ejecutarse directamente contra la base no Oracle: esas fuentes se alcanzan mediante gateways que preparan antes los datos en una base Oracle soportada. En la práctica, enmascarar una base SQL Server implica hacerla pasar por Oracle, licenciar esa base intermedia y añadir una copia más de datos de producción al parque.

PostgreSQL, MongoDB y los almacenes cloud como Snowflake o BigQuery no figuran en esa lista. Un equipo con Oracle en el núcleo y otros motores alrededor acaba con dos procedimientos y dos conjuntos de reglas para la misma obligación.

Qué evaluar en una alternativa

Una alternativa a Oracle Data Masking se evalúa por cinco criterios: cobertura nativa de bases de datos, descubrimiento automático de datos sensibles, integridad referencial entre tablas, integración en CI/CD y modelo de licenciamiento. Los tres primeros son donde fallan las migraciones.

Cobertura nativa de bases de datos. Pregunta qué motores se leen y se escriben directamente, sin base intermedia, y pide la lista de conectores por escrito. Una herramienta que alcanza un motor mediante un fichero de exportación no lo cubre de forma nativa.

Descubrimiento automático de datos sensibles. Dos preguntas separan las opciones: si el descubrimiento se ejecuta sobre el esquema o sobre una muestra de datos, y si existe un paso de confirmación humana antes de que una clasificación se convierta en regla. Un descubrimiento que no se puede revisar convierte un error de clasificación en un dato sin proteger.

Integridad referencial. Este criterio se prueba, no se lee. Coge dos tablas relacionadas, enmascara el identificador compartido y ejecuta un join. Si el join no devuelve nada, la herramienta no preserva la integridad como la necesita tu aplicación.

Integración en CI/CD. Una API o una CLI marcan la diferencia entre un aprovisionamiento que dispara un despliegue y uno que se pide por ticket. Pregunta si un refresco puede programarse y si cada ejecución deja registro.

Modelo de licenciamiento. Comprueba la unidad: por base de datos, por fuente, por procesador, por usuario. La unidad decide cómo se comporta el coste cuando crece el parque, y eso importa más que el precio de entrada.

Otros cuatro criterios separan a las herramientas una vez cubiertos esos cinco: generación de datos sintéticos a partir del esquema, subsetting con filtros y límites, modelo de despliegue y evidencia de auditoría que deja cada ejecución.

Cobertura de bases de datos comparada

Lo relevante de esta tabla no es el número de motores. Es si el motor se alcanza directamente o a través de una base intermedia, porque ese paso añade licencias, latencia y un lugar más donde el dato de producción permanece sin proteger.

Integridad referencial: el requisito que rompe la mayoría de las migraciones

Un dataset enmascarado que no es coherente no sirve para probar. Si un identificador de cliente se sustituye por un valor distinto en cada tabla, las claves foráneas se rompen, los joins no devuelven nada y la aplicación falla por motivos que no tienen que ver con el código que se está probando.

El mecanismo que lo resuelve es el diccionario: un mapeo estable entre el valor original y su sustituto, aplicado allí donde ese valor aparezca, entre tablas y entre bases de datos. Preservar la integridad referencial al enmascarar datos depende por completo del alcance de ese diccionario, que en Gigantics se configura por regla, desde no usar diccionario hasta uno global.

Conviene entender el compromiso antes de elegir el alcance. Un mapeo persistente es lo que mantiene coherente el dataset, pero si ese mapeo se conserva y es accesible, debe protegerse con los mismos controles que el dato original. Una configuración sin diccionario produce una irreversibilidad mayor y un dataset que deja de ser coherente entre tablas.

Checklist de migración: de Oracle DMS a otra herramienta

El esfuerzo se concentra en los dos primeros pasos: entender qué hacen las definiciones de enmascaramiento existentes y mapear los formatos de los que dependen las aplicaciones. El resto es ejecución.

Conviene prever dos detalles. Las definiciones de enmascaramiento de Enterprise Manager contienen conocimiento de negocio que rara vez está documentado en otro sitio, como qué formato espera una aplicación en un campo. Y la posición de licenciamiento no cambia sola: el pack sigue licenciado hasta que los trabajos se detienen y el uso se revisa.

Cobertura normativa

Ninguna de estas normas exige una herramienta concreta. Lo que exigen es una configuración aplicada de forma consistente y un registro que demuestre que se aplicó, y ahí es donde se diferencian las opciones. El artículo 32 del RGPD nombra la seudonimización como medida técnica. El artículo 21(2)(e) de la NIS2 cubre la seguridad en la adquisición, el desarrollo y el mantenimiento de sistemas. Las normas técnicas de regulación de DORA restringen qué puede almacenarse en entornos no productivos. El control 8.11 de la ISO/IEC 27001:2022 exige enmascaramiento, seudonimización o anonimización para que los datos sensibles no queden expuestos fuera de producción.

Por eso conviene mirar qué evidencia deja cada ejecución: qué se transformó, cuándo, sobre qué fuente y quién lo aprobó. Una herramienta que aplica la regla correctamente pero no deja rastro obliga a reconstruir esa evidencia a mano en cada auditoría.

Preguntas frecuentes

¿Oracle Data Masking soporta bases de datos no Oracle?

No de forma directa. Oracle indica que las operaciones de DMS no pueden ejecutarse sobre una base no Oracle: el pack licenciado da acceso restringido a gateways que preparan antes los datos en una base Oracle soportada. Así se alcanzan DB2, Informix, SQL Server, Sybase, MySQL y Teradata. PostgreSQL, MongoDB y los almacenes cloud no figuran en la lista.

¿El dato enmascarado es reversible?

En Oracle DMS el enmascaramiento sustituye los valores de forma permanente y solo el formato Encrypt admite reversión. En las herramientas que usan diccionarios, la reversibilidad depende de si se conserva el mapeo entre el valor original y su sustituto. Si se conserva, debe protegerse con los mismos controles que el dato original.

¿En qué se diferencia Oracle Data Safe de Data Masking and Subsetting?

Ambos cubren descubrimiento de datos sensibles y enmascaramiento estático. Data Safe es el servicio de OCI, con un modelo de licenciamiento distinto y orientado a bases en Oracle Cloud. Data Masking and Subsetting está integrado en Enterprise Manager y es la opción on-premise. Ninguno elimina el requisito de Enterprise Edition para el pack.

¿Cuánto cuesta Oracle Data Masking and Subsetting?

Oracle no publica el precio en sus páginas de producto. Consultoras independientes de licenciamiento informan de un precio de lista de 11.500 USD por procesador, o 230 USD por Named User Plus sujeto a los mínimos de Oracle, con un soporte anual del 22 % del valor neto de la licencia. El pack se licencia para cada base donde se ejecute el enmascaramiento o el subsetting.

¿Qué conviene revisar antes de migrar desde Oracle Data Masking?

El inventario de definiciones de enmascaramiento existentes, los formatos de los que dependen las aplicaciones y cómo se preserva la integridad referencial entre tablas. Esos tres puntos determinan si la migración lleva días o meses.

¿Puede ejecutarse el enmascaramiento dentro de una pipeline CI/CD?

Sí, cuando la herramienta expone una API o una CLI. Esa es la diferencia entre un aprovisionamiento que dispara un despliegue y un aprovisionamiento que se solicita mediante un ticket.