Migración a la nube: cómo proteger los datos sensibles antes de que lleguen a desarrollo y pruebas
Cuando se habla de seguridad en una migración a la nube, la conversación suele concentrarse en el destino.
Cómo configurar la nueva plataforma. Qué identidades y permisos definir. Qué información cifrar. Qué controles exige el proveedor cloud.
Todo eso es necesario.
Pero existe otra parte del riesgo que suele recibir menos atención: lo que ocurre con los datos durante el trayecto.
Para migrar, validar y probar, una organización puede generar réplicas, copias temporales, ambientes de QA, entornos de integración y bases para desarrollo. Muchas de ellas se crean a partir de información de producción.
Y cada una puede contener nombres, cuentas, direcciones, datos financieros u otra información sensible.
Por eso, antes de preguntar qué tan segura será la nueva plataforma, conviene hacer otra pregunta:
¿Cuántos lugares nuevos tienen hoy datos de producción?
En los artículos anteriores de esta serie hablamos de cómo replicar, mantener actualizados y aprovisionar los datos durante una migración. Este artículo se concentra en el paso que completa ese flujo: proteger.
Una migración no mueve los datos a un solo lugar
Es fácil imaginar una migración como un traslado entre dos puntos:
Centro de datos → nube
Pero en la práctica, los datos rara vez viajan a un solo destino.
Durante la transición pueden existir al mismo tiempo:
- la base productiva en el sistema legacy;
- una réplica en el entorno cloud;
- ambientes temporales para validar la migración;
- ambientes de QA y UAT;
- entornos de integración entre legacy y cloud;
- bases para desarrollo;
- copias solicitadas por proveedores o equipos externos que participan en el proyecto.
Como explicamos al hablar de cloud híbrida, muchas organizaciones necesitan que legacy y cloud convivan durante meses. Y durante ese periodo, los datos tienen que estar disponibles en ambos mundos.
El resultado es que una migración no solo traslada información.
También puede multiplicar los lugares donde esa información existe.
La seguridad del destino no protege las copias que se generan en el camino
Una plataforma cloud puede estar correctamente configurada.
Puede tener controles de acceso, cifrado, monitoreo y políticas de seguridad bien definidas.
Aun así, existe una pregunta que esos controles no responden por sí solos:
¿Qué información contiene cada ambiente?
El cifrado protege los datos frente a un acceso no autorizado al almacenamiento. Los permisos determinan quién puede entrar a un sistema.
Pero si un ambiente de QA se creó a partir de una copia de producción, las personas autorizadas a usarlo siguen viendo nombres reales, números de cuenta e identificadores personales.
Y en un proyecto de migración, el número de personas autorizadas suele ser mayor de lo habitual: desarrolladores, testers, integradores, consultores externos y equipos de distintas unidades de negocio.
Por eso conviene distinguir dos niveles de protección:
- proteger la plataforma, es decir, la infraestructura, las identidades y el acceso;
- proteger el contenido, es decir, qué datos llegan a cada ambiente y en qué forma.
Una estrategia de migración necesita ambos.
Más ambientes, más superficie de exposición
Cada copia de producción que llega a desarrollo, QA o UAT puede convertirse en otro punto de exposición de información sensible.
En esta serie hemos repetido una idea: más ambientes no deberían significar más exposición.
Durante una migración, esa idea se vuelve especialmente relevante por tres razones.
Primero, aumenta el número de copias. Cada equipo que necesita probar, validar o integrar puede requerir su propio ambiente. Como vimos en el análisis sobre ambientes de pruebas en paralelo, habilitar varios entornos acelera las validaciones. Pero si todos se crean con datos reales, también se multiplican los lugares que hay que proteger.
Segundo, aumenta el número de personas con acceso. Una migración suele involucrar equipos internos, integradores y proveedores. Cada acceso adicional a un ambiente con datos reales es un punto más que la organización tiene que controlar.
Tercero, aparecen ambientes temporales que nadie da de baja. Una copia creada para validar una etapa puede seguir existiendo semanas o meses después de que se cumplió su propósito. Fuera de la vista de los equipos de seguridad, sigue conteniendo información sensible.
El riesgo no siempre está en un ataque sofisticado.
Muchas veces está en algo más simple: datos reales en lugares donde nadie esperaba encontrarlos.
🔗 La proliferación de copias también tiene un impacto económico. Lo analizamos en el costo oculto de los datos en una migración a la nube.
¿Desarrollo y QA realmente necesitan datos reales?
La respuesta corta: necesitan datos realistas, no necesariamente datos identificables.
Para probar correctamente una aplicación, los equipos requieren información que se comporte como la de producción:
- con la misma estructura;
- con un volumen representativo;
- con relaciones consistentes entre tablas;
- con casos reales de negocio, excepciones y combinaciones poco frecuentes.
Lo que normalmente no necesitan es saber que un registro pertenece a una persona concreta, con su nombre, su número de cuenta o su dirección.
Ahí es donde el enmascaramiento de datos adquiere sentido dentro de una migración: sustituir la información sensible por valores ficticios pero realistas, conservando la utilidad de los datos para desarrollar y probar.
Enmascarar no es borrar ni inventar datos
Enmascarar no consiste en dejar campos vacíos ni en generar datos aleatorios sin relación entre sí.
Si un cliente aparece en varias tablas, o en varios sistemas, el valor enmascarado debe ser el mismo en todos ellos. De lo contrario, las relaciones se rompen y las pruebas dejan de ser confiables.
Durante una migración, esta consistencia es todavía más importante. Los equipos pueden necesitar comparar resultados entre legacy y cloud, o validar integraciones que cruzan ambos entornos. Si cada plataforma enmascara de forma distinta, esas validaciones pierden sentido.
🔗 Si quieres profundizar en técnicas y criterios, consulta nuestra guía técnica de enmascaramiento de datos.
Proteger antes de entregar, no después de copiar
Identificar, enmascarar y aprovisionar: la protección se integra al flujo de entrega de datos antes de que lleguen a los equipos.
En muchas organizaciones, la protección de datos en ambientes no productivos funciona en este orden:
copiar producción → distribuir la copia → intentar controlar quién accede
El problema es que, cuando llegan los controles, los datos reales ya están en el ambiente.
Y si el enmascaramiento depende de un proceso manual posterior, siempre existe la posibilidad de que algún ambiente quede sin proteger: por prisa, por una solicitud urgente o porque nadie sabía que esa copia existía.
Una estrategia moderna invierte el orden:
identificar → enmascarar → aprovisionar
Primero se identifica dónde está la información sensible. Después se protege. Y solo entonces se entrega a los ambientes que la necesitan.
De esta forma, la protección deja de ser un paso opcional que depende de la disciplina de cada equipo.
Se convierte en parte del flujo mediante el cual los datos llegan a desarrollo y pruebas.
Durante una migración, cuando se crean y renuevan ambientes con frecuencia, esa diferencia determina si la protección escala junto con el proyecto o se queda atrás.
El cumplimiento también viaja con los datos
Una copia de producción en un ambiente de pruebas no deja de contener datos personales por estar fuera de producción.
Tampoco deja de ser responsabilidad de la organización por estar alojada en otra infraestructura o administrada por otro proveedor.
En México, la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) vigente desde marzo de 2025 mantiene las obligaciones del responsable de proteger los datos personales que trata y de guardar su confidencialidad, incluso cuando terceros intervienen en el tratamiento. Desde la entrada en vigor de esa ley, la autoridad encargada de vigilar su cumplimiento es la Secretaría Anticorrupción y Buen Gobierno.
Para las organizaciones de sectores regulados, como banca, seguros o servicios financieros, el escrutinio puede venir además de auditorías internas y de autoridades sectoriales. En banca y entidades financieras, por ejemplo, las revisiones de la Comisión Nacional Bancaria y de Valores (CNBV) también pueden poner la lupa sobre cómo se gestiona la información de los clientes en los distintos ambientes tecnológicos.
En ese contexto, una migración plantea una pregunta incómoda:
¿La organización puede demostrar dónde están sus datos personales durante la transición y qué controles existen sobre ellos?
No basta con tener un aviso de privacidad actualizado o una política de seguridad aprobada. Cuando se revisa el cumplimiento, la evidencia depende de la capacidad técnica de saber qué ambientes contienen datos personales, quién accede a ellos y cómo están protegidos.
Y durante una migración, ese mapa cambia constantemente.
📄 ¿Tu inventario de datos personales incluye los ambientes de tu migración?
Muchas auditorías no fallan en Legal, sino en TI: en ambientes no productivos con datos reales que el inventario documental no refleja. Descarga el whitepaper Inventario de Datos Personales: cumplimiento técnico de la LFPDPPP y evalúa si tu inventario es realmente defendible.
¿Dónde entra Delphix?
Delphix trabaja sobre la capa de datos de la migración y permite integrar la protección dentro del mismo flujo con el que los datos llegan a los equipos.
Sus capacidades permiten:
- identificar datos sensibles dentro de las bases de datos mediante perfilamiento, lo que también ofrece un insumo técnico para saber dónde vive la información personal;
- enmascarar de forma consistente, de modo que un mismo valor se transforme igual en distintas tablas y fuentes, preservando las relaciones necesarias para probar;
- aprovisionar ambientes virtuales ya protegidos para desarrollo, QA o integración, sin que cada equipo tenga que partir de una copia física con datos reales.
Con esto se completa el flujo que hemos recorrido a lo largo de esta serie:
replicar → mantener actualizado → aprovisionar → proteger
El objetivo no es frenar la migración con controles adicionales.
Es lograr que la velocidad y la protección avancen juntas: que los equipos tengan los datos que necesitan, cuando los necesitan, sin que la información sensible llegue a lugares donde no debería estar.
🔗 Conoce más sobre Delphix Data Masking.
Antes de migrar, pregunta dónde terminarán tus datos sensibles
Antes de comenzar o mientras avanza una migración, estas preguntas ayudan a detectar si la protección de datos está acompañando al proyecto:
- ¿Cuántos ambientes se crearán durante la migración y cuáles contendrán datos de producción?
- ¿Qué equipos, internos y externos, tendrán acceso a esos ambientes?
- ¿Cuáles de ellos realmente necesitan datos reales y cuáles pueden trabajar con datos enmascarados?
- ¿Sabemos en qué tablas, columnas y sistemas vive la información sensible?
- ¿El enmascaramiento es consistente entre legacy y cloud?
- ¿La protección ocurre antes de entregar los datos o depende de un paso manual posterior?
- ¿Quién decide cuándo se elimina un ambiente temporal?
- ¿Nuestro inventario de datos personales contempla los ambientes temporales, réplicas y copias que genera la migración?
- ¿Podríamos demostrar en una auditoría qué controles existen en cada ambiente no productivo?
Si varias respuestas son inciertas, es probable que la migración esté ampliando la superficie de exposición más rápido de lo que la organización la está controlando.
La migración no debería multiplicar el riesgo
Una migración a la nube es una oportunidad para modernizar infraestructura, aplicaciones y procesos.
También puede ser una oportunidad para corregir prácticas heredadas, como la de copiar producción a cualquier ambiente que lo solicite.
Si esas prácticas se trasladan sin cambios, la organización puede terminar con una plataforma moderna y, al mismo tiempo, con más datos sensibles distribuidos que antes de comenzar.
Por eso la protección no debería llegar al final del proyecto.
Debería formar parte de la manera en que los datos se replican, se actualizan y se entregan a cada equipo.
Llegar a la nube más rápido no sirve de mucho si los datos sensibles llegan a más lugares de los necesarios.
¿Sabes cuántos ambientes de tu migración tienen datos reales?
Conoce cómo la identificación, el enmascaramiento y el aprovisionamiento de datos pueden ayudar a proteger la información sensible sin frenar a tus equipos de desarrollo y pruebas.
Conoce cómo NETI puede ayudarte
0 comments
Write a comment