Exposición del lago de datos de los proveedores

Un proveedor de tecnología sanitaria tenía una sólida seguridad de datos en sus sistemas de aplicaciones: controles de acceso basados en roles, cifrado a nivel de campo, registro de auditoría y revisiones de accesos trimestrales. Tres años antes, el equipo de ingeniería de datos había construido un lago de datos central en AWS S3, alimentado por trabajos de replicación desde todas las bases de datos de las aplicaciones. El objetivo era hacer posible la analítica, las métricas de producto y el aprendizaje automático sin afectar a los sistemas de producción. En tres años, el lago de datos había crecido hasta contener el historial completo de todos los registros de clientes, todas las transacciones, todas las notas clínicas y todos los eventos de integración que el proveedor había tratado. El equipo de ingeniería de datos había configurado los controles de acceso al lago de datos al crearlo: acceso de lectura para cualquier persona de los equipos de ingeniería de datos y de producto, que habían pasado de ocho a cuarenta y siete personas. Nadie había realizado una revisión de accesos del lago de datos desde su creación. El lago de datos contenía el repositorio de datos sensibles más completo del entorno del proveedor. Tenía los controles de acceso más débiles de todos los sistemas que operaba el proveedor.

¿En qué consiste realmente el problema de la exposición de los lagos de datos de proveedores?

Un lago de datos es un repositorio centralizado diseñado para almacenar grandes volúmenes de datos brutos y sin procesar procedentes de múltiples fuentes (bases de datos de aplicaciones, flujos de eventos, registros de API, fuentes externas) en su formato nativo, lo que permite consultas analíticas flexibles sin las restricciones de esquema de una base de datos relacional tradicional. Los lagos de datos son valiosos precisamente por sus características de diseño: lo ingieren todo, lo almacenan a bajo costo y ofrecen un acceso amplio a las consultas que permite la analítica exploratoria, el aprendizaje automático y la inteligencia de producto, algo imposible en sistemas de producción estrictamente gobernados. Esas mismas características de diseño (ingesta exhaustiva, almacenamiento barato, acceso amplio) convierten a los lagos de datos en un riesgo importante para la seguridad de los datos cuando contienen datos sensibles de clientes.

La brecha de gobernanza surge de la tensión entre la finalidad analítica del lago de datos y los requisitos de gobernanza de los datos sensibles que contiene. Los lagos de datos los diseñan ingenieros de datos que optimizan la flexibilidad analítica: quieren que los científicos de datos, los analistas, los gerentes de producto y los ingenieros de ML puedan hacer consultas libremente sin cuellos de botella de acceso. Los programas de gobernanza de datos los diseñan equipos de seguridad y privacidad que optimizan la restricción del acceso: quieren que los datos sensibles sean accesibles solo para quienes los necesitan con fines específicos autorizados. Estos objetivos están estructuralmente en conflicto y, en la mayoría de las organizaciones, el equipo de ingeniería de datos construyó el lago de datos antes de que interviniera el equipo de gobernanza de datos, lo que creó un repositorio exhaustivo de datos sensibles que ya estaba en funcionamiento antes de que se definieran sus requisitos de gobernanza.

El problema de la agregación hace que la exposición de un lago de datos sea categóricamente distinta de la exposición de una base de datos individual. Un registro de cliente en una base de datos de aplicación contiene los datos de ese contexto transaccional concreto. Un lago de datos que ingiere datos de todas las bases de datos de aplicaciones contiene todos los registros transaccionales de todos los clientes a lo largo de toda la historia del proveedor: un perfil completo que es más sensible que cualquier sistema de origen individual porque combina datos de múltiples contextos en un único conjunto de datos consultable. El valor de ese conjunto de datos agregado para un atacante es proporcionalmente mayor que el de cualquier sistema de origen individual. El rigor de gobernanza que se le aplica suele ser proporcionalmente menor.

La exposición de los lagos de datos de proveedores se concentra en cinco patrones de riesgo específicos:

• Acceso amplio predeterminado: lagos de datos aprovisionados con acceso de lectura para equipos o departamentos enteros en lugar de controles de acceso específicos por rol y basados en la necesidad de saber, calibrados según la sensibilidad de los datos
• Sin seguridad a nivel de campo: lagos de datos que ofrecen acceso a nivel de tabla o de bucket sin restricciones a nivel de campo, lo que expone todos los campos, incluidos los sensibles, a cualquier usuario con acceso a la tabla
• Acumulación histórica exhaustiva sin gobernanza de la conservación: lagos de datos que lo ingieren todo y no suprimen nada, y acumulan años de historial de datos sensibles sin una aplicación automatizada de la conservación
• Ausencia de registro de auditoría: lagos de datos en los que la actividad de consultas no se registra o los registros no se revisan, lo que impide detectar patrones anómalos de acceso a los datos
• Exposición de datos de entrenamiento de ML: datos de clientes en lagos de datos utilizados como entradas de entrenamiento para modelos de aprendizaje automático sin autorización explícita, minimización de datos ni anonimización

Por qué es importante

La exposición de los lagos de datos de proveedores es relevante para TPRM porque representa una concentración de datos sensibles en un punto de la arquitectura del proveedor diseñado específicamente para ser ampliamente accesible. Una brecha en el lago de datos de un proveedor no expone los datos de una sola aplicación: expone el historial agregado de todos los sistemas de aplicaciones que lo alimentan. En el caso de un proveedor que atiende a cientos de clientes empresariales, una brecha en el lago de datos puede ser un incidente de exposición de datos de múltiples clientes y múltiples años, de una escala que ninguna brecha en una base de datos de aplicación individual produciría.

La dimensión de la amenaza interna es especialmente importante en los lagos de datos. Los atacantes externos deben comprometer el perímetro del proveedor para llegar a las bases de datos de las aplicaciones. El acceso al lago de datos suele estar al alcance de decenas de usuarios internos (ingenieros de datos, científicos de datos, analistas de producto), muchos de los cuales nunca han visto revisado su acceso y algunos de los cuales pueden haber dejado la organización conservando sus credenciales de acceso. El amplio acceso interno que hace valiosos a los lagos de datos desde el punto de vista analítico los convierte en objetivos de alto valor para las amenazas internas y para el compromiso de credenciales que elude los controles de seguridad externos.

La dimensión de los datos de entrenamiento de ML es cada vez más importante a medida que los proveedores incorporan el aprendizaje automático a su oferta de productos. Los datos de clientes del lago de datos de un proveedor pueden utilizarse como datos de entrenamiento para modelos de ML, ya sea de forma explícita en un programa de mejora de funcionalidades o de forma implícita porque el lago de datos es la fuente más cómoda de ejemplos de entrenamiento etiquetados. Sin prohibiciones contractuales explícitas ni controles técnicos que impidan que los datos de clientes se utilicen en canalizaciones de entrenamiento de ML, el lago de datos de un proveedor crea una vía para que los datos de clientes queden incorporados en pesos de modelos que se comparten con toda la base de clientes del proveedor.

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

El fallo más constante es no preguntar si el proveedor opera un lago de datos o un repositorio central de analítica equivalente que agregue datos de los sistemas de aplicaciones principales que se están evaluando. Las evaluaciones de TPRM que analizan exhaustivamente la seguridad de las bases de datos de las aplicaciones pueden no descubrir nunca que todas esas bases de datos alimentan un repositorio central con una gobernanza de accesos fundamentalmente distinta. El lago de datos es una decisión interna de infraestructura de analítica que los proveedores rara vez mencionan por iniciativa propia en las evaluaciones de seguridad, porque no es el sistema de registro del servicio contratado.

El segundo fallo es tratar la seguridad del lago de datos como una cuestión de ingeniería de datos en lugar de una cuestión de seguridad de los datos. En la mayoría de las organizaciones de proveedores, los lagos de datos los construyen y operan equipos de ingeniería de datos cuya principal preocupación de gobernanza es la calidad de los datos y la fiabilidad de las canalizaciones. La gobernanza de la seguridad de los datos (controles de acceso, registro de auditoría, políticas de conservación, cifrado a nivel de campo) se aplica a los sistemas de aplicaciones mediante la supervisión del equipo de seguridad. Los lagos de datos suelen quedar fuera de esa supervisión porque los aprovisionó otro equipo antes de que los procesos de gobernanza de seguridad se extendieran a la infraestructura de analítica.

• No preguntar si existe un lago de datos o un repositorio central de analítica: evaluar las bases de datos de las aplicaciones sin descubrir la copia agregada para analítica
• Lago de datos excluido del alcance de la evaluación de seguridad: evaluaciones de SOC 2 y de proveedores limitadas a los sistemas de aplicaciones de producción que excluyen explícitamente la infraestructura de analítica
• Ninguna evaluación de los controles de acceso al lago de datos: el acceso amplio de los equipos nunca se ha revisado en función de los requisitos de sensibilidad de los datos
• Ningún requisito de registro de auditoría para la infraestructura de analítica: la actividad de consultas en los lagos de datos no se registra o no se revisa
• No se evalúa el uso de datos de entrenamiento de ML: ninguna pregunta sobre si los datos de clientes del lago de datos se utilizan como entrada de entrenamiento de ML

Cómo se ve una buena práctica

Los programas maduros de gobernanza de lagos de datos de proveedores aplican a la infraestructura de analítica las normas de seguridad de datos con el mismo rigor que a los sistemas de aplicaciones: implementan seguridad basada en atributos o a nivel de fila que restringe el acceso a los campos sensibles, mantienen registros de auditoría de toda la actividad de consultas, aplican políticas de conservación que impiden la acumulación indefinida de datos sensibles y prohíben el uso de datos identificables de clientes como entrada de entrenamiento de ML sin autorización explícita.

• Seguridad basada en atributos o a nivel de fila en el lago de datos: controles de acceso que restringen los campos y filas sensibles según el rol del usuario y la necesidad de saber, no solo el acceso a nivel de tabla
• Registro de auditoría de toda la actividad de consultas: cada consulta al lago de datos se registra con la identidad del usuario, la marca de tiempo y el conjunto de datos consultado, con detección de anomalías en patrones de acceso inusuales
• Políticas de conservación aplicadas al lago de datos: supresión automatizada de los registros que han superado los plazos de conservación en lugar de una acumulación indefinida
• Anonimización o seudonimización para la analítica: datos sensibles de clientes anonimizados o seudonimizados antes de su ingesta en el lago de datos cuando los casos de uso analíticos no requieren identificación
• Autorización de datos de entrenamiento de ML: autorización explícita del cliente antes de que sus datos se utilicen como entrada de entrenamiento de ML, con minimización de datos y anonimización aplicadas
• Lago de datos incluido en el alcance de SOC 2 y de la evaluación de seguridad: la infraestructura de analítica se evalúa con las mismas normas de seguridad que los sistemas de aplicaciones

Herramientas

Gobernar la seguridad de los lagos de datos requiere herramientas diseñadas específicamente para el contexto de la infraestructura analítica: control de acceso, registro de auditoría y enmascaramiento de datos en entornos de lagos de datos en la nube.

Seguridad de lagos de datos en la nube: AWS Lake Formation, Azure Purview, Databricks Unity Catalog

AWS Lake Formation ofrece seguridad a nivel de columna y de fila para lagos de datos basados en S3, lo que permite controles de acceso detallados que restringen los campos sensibles a los usuarios autorizados y, al mismo tiempo, permiten un acceso más amplio a los datos que no son datos sensibles. Azure Purview ofrece gobernanza y clasificación de datos en todo el patrimonio de datos de Azure, incluidos los lagos de datos. Databricks Unity Catalog ofrece control de acceso y registro de auditoría unificados para lagos de datos basados en Databricks. Para los profesionales de TPRM, preguntar si el lago de datos del proveedor utiliza Lake Formation o controles de acceso detallados equivalentes permite saber si existe seguridad a nivel de campo o si el acceso se concede en el nivel más amplio de tabla o de bucket.

Enmascaramiento de datos para analítica: Tonic.ai, Gretel.ai, Immuta

Las plataformas de enmascaramiento de datos y de datos sintéticos transforman los datos sensibles de los clientes antes de que entren en el lago de datos, lo que proporciona datos aptos para la analítica que conservan las propiedades estadísticas sin contener información personal identificable. Immuta ofrece controles de acceso a datos basados en políticas que pueden enmascarar dinámicamente los campos sensibles según el rol del usuario, lo que permite que un mismo conjunto de datos sirva a distintos niveles de acceso sin mantener varias copias. Para los profesionales de TPRM, preguntar si el proveedor aplica enmascaramiento o anonimización a los datos sensibles antes de su ingesta en el lago de datos permite saber si el caso de uso analítico requiere datos identificables o si son viables alternativas que preserven la privacidad.

Auditoría y supervisión de lagos de datos: Securiti, Cyera, Laminar

Las plataformas de DSPM y de supervisión de lagos de datos ofrecen visibilidad continua de los patrones de acceso a los lagos de datos: detectan consultas anómalas, identifican datos sensibles ampliamente accesibles y generan alertas ante infracciones de las políticas de acceso. Para los profesionales de TPRM, preguntar si el proveedor supervisa la actividad de consultas del lago de datos en busca de patrones de acceso anómalos permite saber si el lago de datos es observable o si, en la práctica, es un punto ciego en su supervisión de seguridad.

Desafíos de gobernanza

El reto de gobernanza de la seguridad de los lagos de datos es la tensión entre escala y flexibilidad. Los lagos de datos contienen datos de muchos sistemas de origen en formatos diversos, consultados por muchos usuarios con necesidades analíticas diversas. Aplicar una seguridad a nivel de campo coherente en este entorno heterogéneo exige clasificar cada campo, definir políticas de acceso para cada rol de usuario y aplicarlas en la capa de consulta, una inversión en gobernanza que los equipos de ingeniería de datos normalmente no han hecho porque no formaba parte del planteamiento original del diseño del lago de datos.

Para los programas de TPRM, el enfoque práctico de gobernanza consiste en incluir la existencia del lago de datos y la gobernanza de sus accesos como pregunta estándar en las evaluaciones de todo proveedor que trate datos sensibles de clientes a gran escala. La existencia de un lago de datos no es un riesgo en sí misma: es un patrón arquitectónico común y legítimo. Los controles de acceso, el registro de auditoría y la gobernanza de la conservación que se le aplican determinan si representa una capacidad de analítica bien gobernada o un repositorio ampliamente accesible de todos los registros sensibles que el proveedor ha tratado jamás.

• Añadir la existencia del lago de datos a las preguntas de evaluación de proveedores: si existe un repositorio central de analítica que agregue datos de los sistemas de aplicaciones evaluados
• Preguntar específicamente por los controles de acceso al lago de datos: seguridad a nivel de campo, frecuencia de las revisiones de accesos y si el modelo de acceso se ha revisado en función de los requisitos de sensibilidad de los datos
• Exigir el registro de auditoría de la actividad de consultas del lago de datos: no solo el registro de la infraestructura, sino una auditoría a nivel de consulta con la identidad del usuario y el acceso a los conjuntos de datos
• Preguntar por la autorización de datos de entrenamiento de ML: si los datos de clientes del lago de datos se utilizan como entrada de entrenamiento de ML y qué proceso de autorización se aplica
• Incluir el lago de datos en los requisitos de alcance de SOC 2: la infraestructura de analítica se incluye en el alcance de la evaluación de seguridad y no se excluye como infraestructura operativa

Si usted forma parte de un equipo pequeño

Añada una pregunta a su evaluación de proveedores para todo proveedor que trate datos sensibles a gran escala: ¿opera usted un lago de datos central o un repositorio de analítica que agregue datos de sus sistemas de aplicaciones? Y, en tal caso, ¿quién tiene acceso a él y se ha revisado ese acceso en función de la sensibilidad de los datos que contiene? Esa pregunta sacará a la luz la existencia de una infraestructura de lago de datos a la que nunca llegó su evaluación de las bases de datos de las aplicaciones, y la respuesta le dirá si la copia más completa de los datos de sus clientes en el entorno del proveedor se gobierna con el mismo rigor que los sistemas principales que usted evaluó.

• Preguntar si existe un lago de datos o un repositorio central de analítica antes de concluir la evaluación de las bases de datos de las aplicaciones
• Preguntar cuántos usuarios tienen acceso al lago de datos y cuándo se revisó ese acceso por última vez
• Preguntar si los datos de clientes del lago de datos se utilizan como entrada de entrenamiento de ML
• Preguntar si el lago de datos está dentro del alcance de la auditoría de seguridad SOC 2 o equivalente del proveedor

Qué exigir

Pregunte directamente:

“¿Opera usted un lago de datos o un repositorio central de analítica que contenga datos de los sistemas de aplicaciones que utiliza para tratar los datos de nuestros clientes? Y, en tal caso, ¿qué controles de acceso se le aplican y cuándo se revisó el acceso por última vez?”

“¿Se utilizan los datos de clientes de su lago de datos como entrada para el entrenamiento de modelos de aprendizaje automático, ya sea para mejorar su propio producto o como datos de entrenamiento generales? Y, en tal caso, ¿qué procesos de autorización y anonimización se aplican?”

“¿Está su lago de datos incluido en el alcance de su auditoría de seguridad SOC 2 o equivalente, o está excluido como infraestructura operativa o de analítica?”

Evidencia que debe esperar

• Confirmación de la existencia del lago de datos con una descripción de los controles de acceso
• Evidencia de revisión de accesos: cuándo se revisó por última vez el acceso al lago de datos y cuál es la población actual con acceso
• Confirmación del uso de datos de entrenamiento de ML y del proceso de autorización
• Confirmación del alcance de SOC 2 o equivalente: el lago de datos incluido o excluido explícitamente con una explicación

Un proveedor que responde a la pregunta sobre el lago de datos con “utilizamos infraestructura de analítica para dar soporte a nuestro producto” ha confirmado su existencia sin describir el acceso. Pregunte concretamente cuántas personas pueden consultar el lago de datos y qué reveló la última revisión de accesos. La plataforma de analítica diseñada para la exploración tiene los controles de acceso que sirven a la exploración. Esos controles pueden no corresponder a la sensibilidad de sus datos.

Cómo demostrarlo

La gobernanza de los lagos de datos se aborda cada vez más en los principios de minimización de datos y de limitación del plazo de conservación del GDPR aplicados a la infraestructura de analítica, y en las orientaciones sectoriales sobre la gobernanza de los almacenes de datos analíticos. Demostrar la diligencia debida requiere evidencia de que la infraestructura de analítica se evaluó junto con los sistemas de aplicaciones.

• Registros de evaluación de proveedores que documenten las preguntas sobre la existencia del lago de datos, la gobernanza de accesos y el uso de datos de entrenamiento de ML
• Revisión del alcance de SOC 2 que confirme si la infraestructura de analítica está incluida
• Documentación de los controles de acceso al lago de datos para las relaciones con proveedores de mayor riesgo
• Confirmación de la autorización de datos de entrenamiento de ML

Conclusión clave

El lago de datos se construyó para el descubrimiento. Lo ingiere todo, lo conserva todo y ofrece un acceso amplio porque eso es lo que lo hace valioso desde el punto de vista analítico. Esas mismas propiedades lo convierten en el repositorio de datos sensibles más delicado del entorno del proveedor: una copia exhaustiva, históricamente completa y ampliamente accesible de cada registro de cada sistema que el proveedor ha operado. Las bases de datos de las aplicaciones tienen controles sólidos porque se diseñaron para el tratamiento transaccional bajo supervisión de seguridad. El lago de datos tiene controles más débiles porque lo diseñó un equipo de ingeniería de datos para la flexibilidad analítica antes de que la gobernanza de seguridad se extendiera a la infraestructura de analítica. Evaluar la seguridad de las bases de datos de las aplicaciones sin preguntar por el lago de datos es evaluar el escaparate mientras el almacén que está detrás permanece abierto.