Riesgos de la replicación de datos

La evaluación de TPRM de un proveedor de tecnología financiera confirmó una sólida seguridad de la base de datos: cifrado AES-256 en reposo, controles de acceso basados en roles, registro de auditoría habilitado y revisiones trimestrales de accesos completadas. La evaluación era exacta para la base de datos de producción. Lo que no captó fue que los mismos datos financieros de los clientes existían en una base de datos en espera activa con controles de acceso idénticos, en tres instancias de respaldo regionales restauradas cada semana para pruebas de DR, en un entorno de pruebas de desarrollador poblado con datos de producción para pruebas de integración, en un entorno de QA actualizado cada mes desde producción, en un almacén de datos de analítica con una tarea de replicación nocturna y en una réplica para compartir datos con un socio, usada para una integración de reportes. La base de datos principal tenía siete copias dependientes. Cada una había sido aprovisionada en momentos distintos por equipos distintos. Cada una tenía su propia configuración de controles de acceso o, en el caso del entorno de pruebas del desarrollador, nunca se le habían configurado controles de acceso porque se suponía que era “temporal”. El entorno de pruebas llevaba tres años siendo temporal.

¿Qué es realmente el problema del riesgo de replicación de datos?

La replicación de datos es la creación de copias de datos con fines operativos, de disponibilidad y analíticos: bases de datos en espera activa que garantizan la continuidad si falla el sistema principal, copias de respaldo que permiten recuperarse de pérdidas de datos, entornos de DR que reflejan la producción para las pruebas de conmutación por error, entornos de desarrollo y pruebas poblados con datos realistas, réplicas de analítica que alimentan los sistemas de reportes y datos compartidos con socios que hacen posibles los casos de uso de integración. La replicación es una práctica arquitectónica fundamental que proporciona la resiliencia, el rendimiento y la funcionalidad que requieren las aplicaciones empresariales modernas. También es el mecanismo por el cual un único conjunto de datos gobernado se convierte en muchas copias con una gobernanza variable.

La brecha de gobernanza surge de la asimetría de ciclo de vida entre la replicación y la gobernanza. Los datos se replican mediante procesos automatizados: tareas de respaldo que se ejecutan según un calendario, configuraciones de replicación que propagan cambios de forma continua, scripts de aprovisionamiento de entornos que copian datos de producción a pedido. Cada evento de replicación crea una nueva copia de los datos con los controles de acceso y la configuración de seguridad que se hayan aplicado al aprovisionarla. Esa configuración no se hereda automáticamente del sistema de origen, no se actualiza automáticamente cuando cambia la gobernanza del sistema de origen y no se elimina automáticamente cuando los datos dejan de ser necesarios. Los controles de acceso de la base de datos principal se mantienen con cuidado. La copia creada para un desarrollador hace tres años tiene los controles de acceso que se aplicaron al aprovisionarla y nada ha cambiado desde entonces.

El problema de escala es lo que hace que el riesgo de replicación sea realmente difícil de gobernar. En un entorno moderno de aplicaciones empresariales, el número de copias de datos sensibles puede ser grande, no porque alguien haya decidido crear tantas copias, sino porque cada necesidad operativa independiente generó una copia mediante su propio proceso de aprovisionamiento. Las pruebas de DR crean copias. Los entornos de desarrollo crean copias. Las pruebas de rendimiento crean copias. Los flujos de analítica crean copias. Las integraciones con socios crean copias. Cada copia es una superficie de ataque distinta, con sus propios controles de acceso, su propia gobernanza de retención y su propia exposición si se ve comprometida. La base de datos principal puede ser el objetivo más visible. Las copias no revisadas son las más accesibles.

El riesgo de replicación de datos se concentra en cinco patrones específicos de falla de gobernanza:

Entornos de desarrollo y pruebas con datos de producción: entornos de pruebas de desarrolladores, entornos de QA e instancias de pruebas de integración poblados con datos reales de clientes y gobernados con controles de acceso pensados para la comodidad de los desarrolladores y no con los estándares de seguridad de producción
Deriva de los controles de acceso de las copias de respaldo: instancias de respaldo y copias de restauración aprovisionadas con controles de acceso que eran correctos al crearse, pero que se han apartado de los estándares de seguridad actuales a medida que evolucionaron los controles del sistema principal
Proliferación de réplicas de analítica: bases de datos de reportes, instantáneas de almacenes de datos y conexiones de herramientas de BI que crean réplicas de datos sensibles gobernadas por los controles de acceso del equipo de analítica y no por los estándares de seguridad de datos
Persistencia de los datos compartidos con socios: datos compartidos con socios de integración que permanecen en réplicas accesibles para el socio después de que el caso de uso de integración cambió o terminó
Brecha de seguridad en el entorno de DR: entornos de recuperación ante desastres que reflejan los datos de producción pero se prueban con poca frecuencia, por lo que sus controles de acceso pueden no reflejar los estándares actuales de producción y pueden haber acumulado accesos no autorizados con el tiempo

Por qué es importante

El riesgo de replicación de datos es importante para TPRM porque la evaluación de seguridad del proveedor suele cubrir el sistema principal: la base de datos que el proveedor describe en su documentación de seguridad, que cubre su evaluación SOC 2 y que mantiene su proceso de revisión de accesos. Las copias replicadas que existen en todo el entorno del proveedor con fines operativos rara vez son objeto de una evaluación equivalente. Cuando se produce una violación de seguridad a través de una de esas copias (el entorno de pruebas del desarrollador, la réplica de analítica no revisada, la instancia de respaldo con controles de acceso desactualizados), el alcance de la violación incluye todos los datos de esa copia, que con frecuencia equivalen al conjunto completo de datos de producción.

La investigación de la violación de seguridad mostrará que la base de datos principal estaba bien protegida. El atacante no vulneró la base de datos principal. Vulneró la réplica de analítica que se había aprovisionado dieciocho meses antes con credenciales de acceso de lectura que nunca se rotaron ni se revisaron. El SOC 2 del proveedor cubría el sistema principal. La réplica de analítica la aprovisionó el equipo de ingeniería de datos y nunca estuvo dentro del alcance de SOC 2. Los datos del cliente estaban en ambas. La evaluación cubrió una. La violación expuso la otra.

La dimensión de los derechos de los interesados es igual de significativa. El derecho a la supresión de un interesado exige eliminar sus datos de cada copia en el entorno del proveedor: la base de datos principal y cada réplica. Un proveedor que no puede enumerar sus réplicas no puede cumplir una supresión completa. Un proveedor que atendió una solicitud de supresión eliminando los datos de la base de datos principal sin eliminarlos de la réplica de analítica, las instancias de respaldo y los entornos de desarrollo ha cumplido parcialmente la obligación y ha dejado intactas copias de los datos eliminados en sistemas que quedaron fuera del alcance del proceso de eliminación.

Dónde se equivocan la mayoría de los equipos

La falla más generalizada es evaluar la seguridad de la base de datos sin preguntar cuántas bases de datos contienen los mismos datos. Una evaluación de seguridad que cubre con exactitud la base de datos de producción, pero no pregunta por las réplicas, los respaldos, los entornos de desarrollo y las copias de analítica, ha evaluado un solo nodo de un panorama de datos con múltiples nodos. El informe SOC 2 que cubre los sistemas de producción puede excluir explícitamente los entornos de desarrollo, las instancias de pruebas y las réplicas de socios, exclusiones que son estándar en la definición del alcance de SOC 2, pero significativas en la evaluación de la seguridad de los datos.

La segunda falla es tratar la seguridad de los entornos de desarrollo y pruebas como un asunto de operaciones de desarrollo y no como un asunto de seguridad de datos. Los equipos de desarrollo necesitan datos de prueba realistas. Los controles de seguridad de los entornos de desarrollo suelen ser menos restrictivos que los de producción porque la velocidad de desarrollo es el requisito principal. Cuando los entornos de desarrollo se pueblan con datos de clientes de producción, que es el enfoque más cómodo para hacer pruebas realistas, la seguridad menos restrictiva del entorno de desarrollo se convierte en la postura de seguridad efectiva de una copia completa del conjunto de datos de producción. La mayoría de las evaluaciones de TPRM nunca preguntan si los entornos de desarrollo contienen datos de clientes de producción.

Evaluar la base de datos principal sin enumerar las réplicas: evaluaciones SOC 2 y de seguridad que cubren los sistemas de producción mientras las copias de desarrollo, respaldo y analítica quedan fuera del alcance
Seguridad de los datos en entornos de desarrollo sin evaluar: datos de producción de clientes en entornos de pruebas de desarrolladores y entornos de QA regidos por los controles de acceso de desarrollo
Sin inventario de réplicas: los proveedores que no pueden enumerar todas las ubicaciones donde existen datos del cliente en forma replicada no pueden gobernar esas réplicas
Controles de acceso de las réplicas de analítica sin revisar: réplicas de almacenes de datos y de BI aprovisionadas y gobernadas por los equipos de analítica sin supervisión de seguridad de datos
Solicitudes de supresión limitadas a la base de datos principal: eliminación de datos ejecutada en los sistemas principales sin activar la eliminación en las réplicas

Cómo se ve una buena práctica

Los programas maduros de gobernanza de la replicación de datos de proveedores mantienen un inventario actualizado de todos los sistemas donde existen datos del cliente en forma replicada, aplican controles de acceso y estándares de seguridad coherentes en los sistemas principales y de réplica, usan datos sintéticos o anonimizados en los entornos de desarrollo y pruebas en lugar de copias de producción, e incluyen la gobernanza de réplicas en los procesos de atención de los derechos de los interesados.

Inventario de réplicas mantenido: todos los sistemas que contienen datos del cliente en forma replicada están documentados con su responsable, controles de acceso y estado de retención
Datos sintéticos o anonimizados en los entornos de desarrollo: desarrollo y pruebas poblados con datos realistas pero no identificables en lugar de registros de clientes de producción
Estándares de control de acceso coherentes en todas las réplicas: los cambios en los controles de acceso del sistema principal se propagan a los sistemas de réplica según un calendario definido
Inclusión de las réplicas en los procesos de supresión y eliminación: la atención de los derechos de los interesados y la eliminación al desvincular al proveedor cubren explícitamente todos los sistemas de réplica
Revisión periódica de accesos a las réplicas: los controles de acceso de los sistemas de réplica se revisan con la misma periodicidad que los del sistema principal
Clasificación y gobernanza de las réplicas de analítica: réplicas de almacenes de datos y de BI gobernadas según estándares de seguridad de datos equivalentes a la clasificación de los datos de origen

Herramientas

Gestionar el riesgo de replicación de datos requiere herramientas de descubrimiento para enumerar las réplicas y herramientas de enmascaramiento de datos para eliminar la necesidad de usar datos de producción en los entornos de desarrollo.

Descubrimiento de datos: BigID, Varonis, Microsoft Purview

Las plataformas de descubrimiento de datos analizan todo el entorno de almacenamiento de una organización (bases de datos, almacenamiento en la nube, sistemas de archivos) para identificar dónde existen datos específicos en forma replicada. Para los profesionales de TPRM, preguntar si un proveedor usa herramientas de descubrimiento de datos para mantener un inventario de todos los sistemas donde existen datos del cliente es una pregunta concreta sobre capacidades que determina si la gobernanza de réplicas se basa en un inventario documentado o en la memoria de la organización.

Enmascaramiento de datos y datos sintéticos: Informatica, IBM InfoSphere Optim, Tonic.ai, Gretel.ai

Las plataformas de enmascaramiento de datos transforman los datos de producción en equivalentes realistas pero no identificables para su uso en entornos de desarrollo y pruebas, lo que elimina la exposición de datos de producción que convierte la seguridad del entorno de desarrollo en un riesgo de violación de datos. Tonic.ai y Gretel.ai generan datos sintéticos que conservan las propiedades estadísticas de los datos de producción sin contener información personal real. Para los profesionales de TPRM, preguntar si el proveedor usa datos sintéticos o enmascarados en los entornos de desarrollo en lugar de copias de producción es la pregunta más directa para la categoría de riesgo de los entornos de desarrollo.

Monitoreo de actividad de bases de datos: Imperva, IBM Guardium

Las plataformas de DAM monitorean la actividad de acceso en todas las instancias de bases de datos, incluidas réplicas, respaldos y copias de analítica, lo que proporciona un registro de auditoría de accesos unificado para todo el panorama de replicación de datos. Para los proveedores con un gran número de réplicas, DAM proporciona la cobertura de monitoreo que hace que la gobernanza de réplicas sea sostenible en la operación.

Desafíos de gobernanza

El desafío de gobernanza de la replicación de datos es la fragmentación de la responsabilidad. Las bases de datos de producción pertenecen a un equipo definido, que las gobierna. La réplica de analítica la creó el equipo de ingeniería de datos. El entorno de pruebas del desarrollador lo aprovisionó el equipo de plataforma. La instancia de DR la gestiona el equipo de infraestructura. Cada equipo aplicó los controles de seguridad que tenían sentido desde su perspectiva operativa, que pueden ser mucho menos restrictivos que los estándares de seguridad de datos aplicables a los datos de origen. Nadie tiene una responsabilidad integral sobre cuántas copias existen y si cada una se gobierna de manera adecuada.

Cerrar esta brecha requiere tratar la replicación de datos como un evento de gobernanza de datos: cada creación de una nueva réplica activa una revisión de gobernanza que aplica los controles adecuados antes de que se use la réplica. Se trata de un cambio de procesos y políticas tanto como de un cambio técnico, y requiere una coordinación entre los equipos de seguridad de datos, ingeniería de datos y desarrollo que la mayoría de las organizaciones no ha establecido.

Trate la creación de réplicas como un evento de gobernanza de datos: el aprovisionamiento de una nueva réplica activa una revisión de los controles de acceso y una clasificación antes de su uso
Exija datos sintéticos o enmascarados en los entornos de desarrollo: la eliminación de datos de producción de los entornos de pruebas de desarrolladores como requisito de política
Mantenga un inventario actualizado de réplicas: todos los sistemas que contienen datos del cliente documentados y con un responsable asignado
Incluya las réplicas en la periodicidad de la revisión de accesos: los controles de acceso de las réplicas se revisan con el mismo calendario que los controles del sistema principal
Incluya las réplicas en los procesos de eliminación y supresión: la atención de los derechos de los interesados y la eliminación al desvincular al proveedor cubren explícitamente todas las réplicas documentadas

Si usted forma parte de un equipo pequeño

Haga a sus proveedores de mayor riesgo una pregunta que la mayoría de las evaluaciones nunca hace: ¿cuántas copias de los datos que tratan en nuestro nombre existen en su entorno, incluidos respaldos, entornos de DR, instancias de desarrollo y pruebas, réplicas de analítica y datos compartidos con socios, y cada una de esas copias se gobierna con controles de seguridad equivalentes a los de su sistema de producción principal? La respuesta a esa pregunta revelará más sobre la exposición real de los datos que cualquier evaluación de seguridad de bases de datos centrada solo en el sistema principal.

Pida a los proveedores que enumeren todos los sistemas en los que existen datos del cliente en forma replicada
Pregunte específicamente si los entornos de desarrollo y pruebas contienen datos de clientes de producción o equivalentes sintéticos
Incluya la gobernanza de réplicas en sus requisitos de eliminación al desvincular al proveedor, no solo la eliminación de la base de datos principal
Pregunte si la cobertura de auditoría SOC 2 o equivalente del proveedor incluye los sistemas de réplica o se limita a producción

Qué exigir

Pregunte directamente:

“¿Cuántas copias de los datos que tratan en nuestro nombre existen en su entorno, incluidas las bases de datos de producción en espera, los respaldos, los entornos de DR, las instancias de desarrollo y pruebas, las réplicas de analítica y los datos compartidos con socios?”

“¿Sus entornos de desarrollo y pruebas contienen datos reales de clientes provenientes de producción, o usan datos sintéticos o anonimizados para fines de desarrollo y pruebas?”

“Cuando solicitamos la eliminación de nuestros datos, ya sea al terminar el contrato o en respuesta a una solicitud de supresión de un interesado, ¿su proceso de eliminación cubre todos los sistemas de réplica o solo la base de datos de producción principal?”

Evidencia que debe esperar

Inventario de réplicas: todos los sistemas que contienen datos del cliente, con su responsable y el estado de sus controles de acceso
Confirmación de los datos en los entornos de desarrollo: datos sintéticos o enmascarados, o datos de producción con controles equivalentes
Confirmación del alcance de la eliminación: todas las réplicas incluidas en los procesos de eliminación
Cobertura de la revisión de accesos: sistemas de réplica incluidos en la revisión periódica de accesos

Un proveedor que responde a la pregunta sobre el inventario de réplicas con “tenemos una sólida seguridad de bases de datos” ha vuelto a describir el sistema principal. Pregunte específicamente cuántas instancias de bases de datos contienen datos del cliente. El número es la respuesta. La gobernanza de cada instancia es la pregunta de seguimiento.

Cómo demostrarlo

La gobernanza de la replicación de datos se aborda de forma implícita en los principios de limitación del plazo de conservación y de exactitud del GDPR, en los requisitos de mínimo necesario y de salvaguardas de la HIPAA y en los criterios de disponibilidad y confidencialidad de SOC 2. Demostrar la debida diligencia requiere evidencia de que se evaluó la gobernanza de las réplicas, no solo la seguridad de la base de datos principal.

Registros de evaluación de proveedores que documentan las preguntas y respuestas sobre el inventario de réplicas
Confirmación del tipo de datos en los entornos de desarrollo: sintéticos o de producción
Documentación del alcance de la eliminación, incluidas las réplicas
Revisión del alcance de SOC 2 que confirma si los sistemas de réplica están incluidos o excluidos

Conclusión clave

La base de datos principal es la copia que todos gobiernan. Las otras once copias son las que todos olvidan. Cada réplica es una copia completa del conjunto de datos de producción, con sus propios controles de acceso, su propia gobernanza de retención y su propia exposición si se ve comprometida. El entorno de pruebas del desarrollador que debía ser temporal hace tres años tiene todos los datos de producción y ninguna revisión de accesos. La réplica de analítica aprovisionada por el equipo de ingeniería de datos tiene los controles de acceso que el ingeniero de datos aplicó a las dos de la tarde del día en que necesitaba que el tablero de reportes estuviera en funcionamiento. La seguridad de la base de datos principal es excelente. Cubre una copia. Pregunte cuántas copias existen. Luego pregunte cuáles se han revisado.