Problemas de seguridad y privacidad de los macrodatos

Los entornos de big data recopilan, procesan y almacenan información mucho más sensible que los sistemas tradicionales, a la vez que plantean desafíos de seguridad que los controles convencionales no están diseñados para abordar. Los marcos de computación distribuida, los almacenes de datos no relacionales y las canalizaciones de datos de alta velocidad crean superficies de ataque y riesgos de cumplimiento distintos. La acción recomendada es: clasificar los datos por sensibilidad antes de que entren en la canalización, cifrarlos en reposo con AES-256 y en tránsito con TLS 1.3, aplicar controles de acceso granulares a nivel de campo y gestionar todas las claves criptográficas mediante un sistema de gestión de claves centralizado y basado en hardware.

Respuesta rápida: ¿Cuáles son los principales desafíos de seguridad del Big Data?

La seguridad de los macrodatos es compleja debido a la combinación de escala, velocidad, variedad y arquitectura distribuida que caracteriza a estos entornos. Los volúmenes de datos son demasiado grandes para una revisión manual. La velocidad implica que los datos se ingieren y procesan más rápido que la revisión de seguridad humana. La variedad significa que datos estructurados, semiestructurados y no estructurados de cientos de fuentes ingresan al mismo entorno con una clasificación de sensibilidad inconsistente. La arquitectura distribuida implica que los datos se procesan en múltiples nodos que, individualmente, carecen de los controles de seguridad de los sistemas de bases de datos tradicionales. Los siete desafíos principales son: asegurar la computación distribuida, proteger los registros de datos y transacciones de múltiples niveles, validar las entradas de los puntos finales, asegurar los almacenes de datos no relacionales, habilitar análisis que preserven la privacidad, aplicar un control de acceso granular y mantener la monitorización de seguridad en tiempo real a gran escala.

¿Qué es el Big Data y por qué supone un riesgo de seguridad específico?

El big data se refiere a conjuntos de datos caracterizados por tres dimensiones que superan la capacidad de las herramientas tradicionales de gestión de datos: volumen (petabytes o más de datos), velocidad (generación e ingesta continua de datos a alta velocidad) y variedad (registros de bases de datos estructuradas, archivos de registro semiestructurados, texto no estructurado, imágenes y datos de sensores procesados ​​conjuntamente). Una cuarta dimensión, la veracidad, se refiere a la fiabilidad y precisión de las fuentes de datos.

Los entornos de big data representan un objetivo concentrado. Una filtración de base de datos tradicional expone un único conjunto de datos. Una filtración en una plataforma de big data expone registros consolidados de todas las fuentes que alimentan la plataforma, incluyendo potencialmente información personal identificable de clientes, transacciones financieras, historiales médicos, registros operativos y datos comerciales confidenciales simultáneamente. El informe de IBM sobre el coste de una filtración de datos de 2025 reveló que el coste medio global de una filtración alcanzó los 4.88 millones de dólares en 2024, y que las filtraciones que involucran grandes volúmenes de registros resultaron significativamente más costosas debido a los requisitos de notificación regulatoria y la magnitud de la remediación.

Entre los componentes comunes de la tecnología de big data que presentan desafíos de seguridad específicos se incluyen Apache Hadoop y su HDFS (Hadoop Distributed File System), MapReduce y Apache Spark para computación distribuida, bases de datos NoSQL (MongoDB, Cassandra, HBase, DynamoDB) para almacenamiento flexible no estructurado, Apache Kafka para transmisión de datos a alta velocidad y lagos de datos nativos de la nube en almacenamiento de objetos (S3, Azure Blob Storage, Google Cloud Storage).

Los siete principales desafíos en materia de seguridad y privacidad de los macrodatos

1. Computaciones distribuidas seguras

Los marcos de computación de big data, como MapReduce y Apache Spark, procesan datos confidenciales en nodos distribuidos. MapReduce divide los datos en fragmentos, asigna cada fragmento a un mapeador para su procesamiento y agrega los resultados mediante un reductor. Spark ejecuta transformaciones en memoria en todo el clúster para un mayor rendimiento. En ambos casos, la capa de procesamiento de datos se diseñó históricamente para priorizar la disponibilidad y el rendimiento, considerando la seguridad como una preocupación secundaria.

Los riesgos de seguridad son específicos. Un mapeador no confiable o comprometido en un trabajo MapReduce puede modificar los datos que se procesan sin que el framework detecte la modificación. Un nodo ejecutor de Spark comprometido puede extraer datos en memoria antes del cifrado o después del descifrado, ya que el cálculo generalmente se realiza sobre texto plano. La naturaleza distribuida implica que los controles de acceso deben aplicarse en cada nodo, no solo en un punto de acceso central.

Controles: aplicar TLS mutuo entre los nodos del clúster; usar la firma de código para verificar que la lógica de cálculo no haya sido manipulada; implementar la autenticación de nodos para que solo los nodos autorizados puedan unirse al clúster; y aplicar cifrado a nivel de campo a los datos más sensibles para que incluso un mapeador comprometido solo vea texto cifrado.

2. Protección de datos y registros de transacciones

Los macrodatos y los registros de transacciones que rastrean las operaciones realizadas sobre ellos se almacenan en entornos de almacenamiento multinivel mediante la organización automática por niveles: los datos se mueven automáticamente entre almacenamiento en caliente (rápido, costoso y de acceso frecuente), almacenamiento tibio (velocidad y costo moderados) y almacenamiento en frío (lento, económico y de acceso poco frecuente) según los patrones de acceso. La organización automática por niveles optimiza el costo, pero oculta la ubicación física de los datos en un momento dado.

Surgen dos riesgos de seguridad. En primer lugar, la organización pierde visibilidad sobre la ubicación física de los datos específicos, lo que complica la clasificación de datos, el cumplimiento normativo (el RGPD exige saber dónde se almacenan los datos personales de la UE) y la contención de las brechas de seguridad. En segundo lugar, la transmisión de datos entre los distintos niveles de almacenamiento crea oportunidades de interceptación si no se cifra durante el tránsito.

Los registros de transacciones contienen información operativa confidencial: qué consultas se ejecutaron, a qué datos se accedió, qué usuarios realizaron qué operaciones y en qué fechas y horas. Los registros mal protegidos constituyen un objetivo secundario de filtración de datos. Controles: cifrar todos los datos en todos los niveles de almacenamiento; cifrar los datos en tránsito entre niveles mediante TLS 1.3; aplicar políticas de almacenamiento WORM (Write Once, Read Many) a los registros de auditoría para evitar manipulaciones; y mantener un inventario de ubicaciones de datos mediante el descubrimiento seguro de CBOM.

3. Validación de las entradas de los puntos finales

Las plataformas de big data ingieren datos de cientos o miles de fuentes: sensores IoT, registros de aplicaciones, feeds de análisis web, captura de cambios en bases de datos, proveedores de datos externos y contenido generado por el usuario. Cada fuente es un vector de ataque potencial para el envenenamiento de datos, donde un atacante controla una fuente de datos e inyecta registros maliciosos diseñados para corromper los resultados analíticos o explotar vulnerabilidades de procesamiento.

La manipulación de datos afecta a los sistemas de toma de decisiones que utilizan análisis de macrodatos. Por ejemplo, un sensor defectuoso que introduce lecturas falsificadas en el sistema de análisis de un sistema de control industrial puede provocar respuestas automatizadas incorrectas. Un conjunto de datos de entrenamiento manipulado afecta al comportamiento de los modelos de aprendizaje automático de maneras que pueden ser difíciles de detectar.

Controles: autenticar todas las fuentes de datos antes de su ingesta mediante claves API, certificados o firmas de origen; aplicar validación de esquema para rechazar registros que no se ajusten a los formatos esperados; implementar detección de anomalías en los flujos de datos entrantes para señalar valores atípicos estadísticos que puedan indicar registros manipulados; y mantener un registro de fuentes de datos autorizadas para que las fuentes nuevas no registradas activen alertas en lugar de la ingesta automática.

4. Protección de almacenes de datos no relacionales

Las bases de datos NoSQL, como MongoDB, Cassandra, HBase y DynamoDB, se utilizan ampliamente en entornos de big data por su escalabilidad y flexibilidad de esquema. Históricamente, muchas bases de datos NoSQL se diseñaron para su implementación en redes internas de confianza y carecían de características que las bases de datos relacionales tradicionales ofrecían por defecto: cifrado nativo en reposo, autenticación robusta, controles de acceso granulares y registro de auditoría completo.

Los sistemas NoSQL modernos han mejorado sustancialmente sus funciones de seguridad, pero las implementaciones que no se reforzaron explícitamente siguen expuestas. Los fallos más comunes en la práctica son: instancias implementadas sin autenticación habilitada (expuestas directamente a internet sin contraseña); archivos de datos almacenados en disco sin cifrado en reposo (accesibles para cualquier persona con acceso al sistema de archivos); y ausencia de registro de auditoría (la investigación de brechas es imposible sin un registro de las consultas ejecutadas).

Controles: habilitar el cifrado en reposo para todos los archivos de datos NoSQL; aplicar la autenticación y autorización para cada conexión; usar TLS 1.3 para toda la comunicación de cliente a base de datos y de nodo a nodo; habilitar el registro de auditoría de todos los intentos de autenticación y operaciones de consulta; aplicar el principio de mínimo privilegio a los roles de usuario de la base de datos; y realizar un inventario criptográfico para detectar cualquier instancia NoSQL no cifrada mediante CBOM Secure.

5. Análisis de datos que preservan la privacidad

El análisis de macrodatos está diseñado para encontrar patrones en grandes conjuntos de datos. Esta misma capacidad, que hace que el análisis sea valioso para la inteligencia empresarial, también genera riesgos para la privacidad: la agregación de múltiples campos de datos de una persona en distintos conjuntos de datos puede permitir inferir información que dicha persona no reveló, o bien, reidentificar a personas en conjuntos de datos que se creían anonimizados.

Tres escenarios generan vulnerabilidades de privacidad. Primero, la reidentificación: combinar un conjunto de datos supuestamente anonimizado con otro que contiene campos de identificación permite vincular registros con personas reales. Segundo, la inferencia: los datos agregados revelan atributos personales que ningún dato individual divulgaría. Tercero, el análisis por terceros: externalizar el análisis a un proveedor externo otorga a un tercero acceso a datos sin procesar que pueden contener información de identificación personal, incluso si la intención comercial era compartir únicamente información agregada.

Controles: aplicar la tokenización para reemplazar la información de identificación personal con tokens irreversibles antes de compartir los datos con procesos analíticos o terceros; utilizar técnicas de privacidad diferencial (añadir ruido estadístico calibrado a los resultados de las consultas para que no se puedan inferir registros individuales) para los resultados analíticos sensibles; implementar el enmascaramiento de datos para entornos de desarrollo y prueba; y vincular contractualmente a los proveedores de análisis de terceros a las restricciones de procesamiento de datos según los requisitos del artículo 28 del RGPD para los encargados del tratamiento de datos.

6. Control de acceso granular

Las plataformas de big data contienen registros con clasificaciones de confidencialidad muy diversas en un mismo entorno. Un lago de datos puede almacenar registros de transacciones financieras, diagnósticos médicos, comunicaciones internas y análisis web públicos en rutas de almacenamiento adyacentes. Los controles de acceso tradicionales, que otorgan acceso a nivel de almacén de datos, son demasiado imprecisos: un usuario autorizado para consultar datos de transacciones de clientes no debería tener acceso automático a los registros médicos en el mismo entorno.

Los controles deben operar en múltiples niveles de granularidad:

• Control de acceso basado en roles (RBAC) a nivel de plataforma: Control de acceso basado en roles que limita qué usuarios y servicios pueden conectarse a qué almacenes de datos.
• Seguridad a nivel de columna: Dentro de una tabla o almacén de datos, las columnas individuales que contienen campos confidenciales (número de seguro social, número de cuenta, código de diagnóstico) solo son accesibles para los roles autorizados, no para todos los usuarios que pueden consultar la tabla.
• Seguridad a nivel de fila: Los datos se filtran en el momento de la consulta según los atributos del usuario, de modo que este solo recibe los registros que tiene autorización para ver. Un analista regional solo ve los registros de su región; un responsable de cumplimiento ve todos los registros de su categoría de datos.
• Cifrado con control de acceso mediante clave: El cifrado a nivel de campo, combinado con los controles de acceso de gestión de claves, garantiza que incluso los usuarios con acceso directo al sistema de archivos no puedan leer los campos cifrados sin la clave de descifrado correspondiente.
• Gestión de identidad centralizada: Los derechos de acceso deben aplicarse de forma coherente en todos los nodos del clúster distribuido desde un proveedor de identidad central, de modo que los cambios de permisos surtan efecto simultáneamente en todas partes y no se eludan conectándose directamente a un nodo del clúster en lugar de a través de la capa de aplicación.

7. Monitoreo de seguridad en tiempo real

Los entornos de big data generan enormes volúmenes de eventos relevantes para la seguridad: intentos de autenticación, ejecuciones de consultas, operaciones de acceso a datos, acciones administrativas y conexiones de red entre múltiples nodos. La monitorización en tiempo real a esta escala presenta un desafío estructural, ya que el volumen de eventos genera un elevado número absoluto de falsas alarmas, incluso con tasas bajas de falsos positivos, lo que sobrecarga a los equipos de seguridad.

Controles: integrar los registros de la plataforma de big data con una plataforma SIEM (Gestión de información y eventos de seguridad) que aplique detección de anomalías basada en aprendizaje automático en lugar de solo alertas basadas en reglas, para distinguir el comportamiento inusual del ruido de fondo de las operaciones rutinarias; establecer líneas base de comportamiento por usuario y por servicio para que las anomalías se detecten en relación con patrones normales en lugar de umbrales absolutos; configurar alertas para señales de alta prioridad, como exportaciones masivas de datos, acceso a clasificaciones sensibles fuera del horario normal, fallos de autenticación seguidos de autenticación exitosa y creación de nuevos usuarios administrativos; y priorizar la clasificación de alertas según la sensibilidad de los datos para que las alertas que involucren los datos de clasificación más alta reciban la respuesta más rápida.

Cómo el cifrado protege los macrodatos

El cifrado protege los macrodatos en múltiples etapas de su ciclo de vida. Comprender qué tipo de cifrado se aplica en cada caso determina si los datos confidenciales permanecen protegidos cuando fallan otros controles.

• Datos en reposo (HDFS, almacenamiento de objetos, NoSQL): AES-256-GCM se aplica a nivel de volumen (cifrado de disco completo), a nivel de archivo o a nivel de campo. El cifrado a nivel de campo es el más granular y permite diferentes claves de cifrado para cada clasificación de datos, por lo que la vulneración de una clave no expone todos los datos. La gestión de claves debe ser externa al sistema de almacenamiento para que un nodo de almacenamiento comprometido no exponga simultáneamente claves y datos.
• Datos en tránsito (canalización, clúster, API): TLS 1.3 con intercambio de claves ECDHE para todo el movimiento de datos: entre fuentes de datos y la capa de ingesta, entre etapas de la canalización, entre nodos del clúster, entre consumidores de análisis y la plataforma de datos. La comunicación interna del clúster es una brecha que a menudo se pasa por alto; el tráfico entre nodos en clústeres de big data no cifrados representa una oportunidad de movimiento lateral para los atacantes que hayan alcanzado cualquier nodo del clúster.
• Tokenización para análisis: La tokenización de la información de identificación personal (PII) antes de su entrada en los flujos de análisis preserva la integridad referencial (los registros del mismo cliente aún pueden combinarse entre conjuntos de datos) sin exponer la PII subyacente al proceso de análisis ni a los proveedores de análisis de terceros.
• Gestión clave con HSM: Todas las claves de cifrado para entornos de big data deben gestionarse en un sistema centralizado de gestión de claves respaldado por una validación FIPS 140-3. HSMLa gestión de claves basada en hardware significa que incluso una vulneración total de un nodo de almacenamiento no expone las claves de cifrado, lo que evita la exposición simultánea de datos y claves que permitiría el descifrado de datos robados.

Tabla de decisiones sobre seguridad de macrodatos: cómo relacionar los controles con los desafíos

Desafío	Control primario	Control de apoyo	Relevancia del cumplimiento
Seguridad en computación distribuida (MapReduce, Spark)	mTLS entre nodos del clúster; autenticación de nodos	Cifrado a nivel de campo; firma de código para tareas de computación.	Artículo 32 del RGPD; Norma de seguridad de HIPAA
Almacenamiento multinivel y protección del registro de transacciones	Cifrado AES-256-GCM en todos los niveles de almacenamiento; TLS 1.3 entre niveles.	Almacenamiento WORM para registros de auditoría; inventario de ubicación de datos	Artículo 32 del RGPD; Requisitos 3 y 10 de PCI DSS
Validación de entrada de punto final no confiable	Autenticación de origen (basada en certificados); validación de esquema	Detección de anomalías en flujos de datos entrantes; registro de fuentes autorizadas	Norma de seguridad HIPAA; ISO 27001
seguridad de bases de datos NoSQL	Cifrado en reposo; aplicación de autenticación; TLS para conexiones de cliente	Registro de auditoría; roles de base de datos con privilegios mínimos; descubrimiento seguro de CBOM	RGPD Art. 32; HIPAA; PCI DSS Req. 3 y 8
Análisis que preservan la privacidad	Tokenización de la información de identificación personal antes de la ingesta analítica; privacidad diferencial para los resultados de las consultas.	Enmascaramiento de datos para entornos que no son de producción; acuerdos con procesadores de datos de terceros	Pseudonización según el artículo 4(5) del RGPD; la CCPA; la HIPAA, la desidentificación.
Control de acceso granular	Seguridad a nivel de columna y de fila; RBAC a nivel de plataforma y de almacén de datos.	Cifrado a nivel de campo con controles de acceso de clave; gestión centralizada de identidades	Minimización de datos según el RGPD; datos mínimos necesarios según la HIPAA; requisito 7 de PCI DSS.
Monitorización de seguridad en tiempo real a gran escala	SIEM con detección de anomalías de comportamiento; priorización de alertas basada en clasificación.	Supervisión de exportaciones masivas; alertas de acceso fuera del horario laboral; alertas de nuevas cuentas de administrador.	Controles de auditoría HIPAA; Requisito 10 de PCI DSS; Artículo 32 del RGPD

Mapeo de cumplimiento: Marcos de privacidad de macrodatos

Marco conceptual	Requisito clave de big data	Implicación
RGPD (Reglamento General de Protección de Datos de la UE)	Minimización de datos, limitación de la finalidad, seudonimización, cifrado, derecho de supresión.	Los entornos de big data deben documentar qué datos personales poseen, por qué y durante cuánto tiempo; el derecho de supresión requiere la capacidad de localizar y eliminar registros individuales específicos en una plataforma distribuida.
Regla de seguridad de HIPAA	Controles de acceso, registro de auditoría, seguridad de transmisión, cifrado para información médica electrónica protegida (ePHI)	Todos los entornos de big data que contengan información médica electrónica protegida (ePHI) deben cifrarla tanto en reposo como en tránsito, implementar controles de acceso, registrar todos los accesos y realizar evaluaciones de riesgos periódicas.
CCPA (Ley de privacidad del consumidor de California)	Derecho a saber, derecho a eliminar, derecho a oponerse a la venta	Las plataformas de big data deben admitir la búsqueda y eliminación de registros asociados con una identidad de consumidor específica, lo que requiere el etiquetado de datos y el seguimiento del linaje en el momento de la ingesta.
PCI DSS v4.0	Cifrado de los datos del titular de la tarjeta en reposo (Req. 3) y en tránsito (Req. 4); controles de acceso (Req. 7); registro de auditoría (Req. 10)	Los entornos de big data que ingieren datos de pago deben aplicar todos los controles PCI DSS; la tokenización antes de la ingesta es un enfoque común para eliminar los datos del titular de la tarjeta del ámbito de big data.

Ejemplo de implementación: Protección de un lago de macrodatos sanitarios

Una organización sanitaria que consolida historiales de pacientes, datos de reclamaciones y telemetría de dispositivos médicos IoT en un lago de datos en la nube debe abordar simultáneamente los siete desafíos de seguridad. A continuación, se describe cómo se estructura una implementación que cumpla con la normativa:

1. Clasificación en el momento de la ingesta: Una capa de clasificación automatizada etiqueta cada registro entrante con su nivel de confidencialidad de datos (ePHI, datos clínicos anonimizados, datos operativos, datos públicos) según la coincidencia de esquemas y la inspección de contenido. Las etiquetas de clasificación determinan qué clave de cifrado y política de acceso se aplican.
2. Cifrado en reposo por clasificación: Los registros ePHI se cifran con AES-256-GCM a nivel de campo; los datos clínicos anonimizados con cifrado a nivel de volumen; los datos operativos como mínimo con cifrado a nivel de volumen. Se gestionan claves de cifrado separadas por clasificación en un HSM como servicio.
3. TLS 1.3 en tránsito: Todo el movimiento de datos entre la capa de ingesta, la capa de procesamiento y la capa de almacenamiento utiliza TLS 1.3. La comunicación de clúster Spark de nodo a nodo utiliza mTLS con certificados administrados por Administrador de CertSecure.
4. Tokenización antes del análisis: Los identificadores de pacientes (nombre, fecha de nacimiento, número de historia clínica) se tokenizan antes de que los registros ingresen a la capa de análisis. Los procesos de análisis trabajan con tokens, lo que permite realizar análisis longitudinales sin exponer información de identificación personal al equipo de análisis ni a ningún proveedor de análisis externo.
5. Control de acceso a nivel de columna: Los códigos de diagnóstico, la información sobre medicamentos y las notas clínicas están restringidos a roles clínicos autorizados. Los datos de pago de reclamaciones están restringidos a roles financieros. La telemetría operativa es accesible para roles de ingeniería. Los filtros de seguridad a nivel de fila dirigen los registros al panel de pacientes asignado a cada usuario clínico.
6. Integración SIEM: Todos los eventos de acceso a la plataforma, las ejecuciones de consultas y las acciones administrativas se envían a un SIEM. Se configuran alertas para el acceso masivo a información médica electrónica protegida (posible filtración masiva), el acceso fuera del horario laboral por parte de personal que no está de guardia y los fallos de autenticación.
7. Documentación de cumplimiento de HIPAA: La cobertura de cifrado, los registros de acceso y los resultados de las evaluaciones de riesgo anuales se mantienen a través de Servicios de asesoramiento sobre cumplimiento para cumplir con los requisitos de auditoría de la Regla de Seguridad de HIPAA.

Limitaciones de los controles de seguridad de Big Data

• Impacto del rendimiento del cifrado a gran escala: El cifrado a nivel de campo y de columna añade una sobrecarga computacional a cada operación de lectura y escritura. A escala de big data, esta sobrecarga es significativa y debe tenerse en cuenta en la planificación de capacidad. El cifrado AES acelerado por hardware (AES-NI en procesadores modernos) reduce, pero no elimina, el coste de rendimiento.
• El riesgo de reidentificación no se puede eliminar por completo: Incluso los sistemas de anonimización y tokenización mejor implementados han sido burlados mediante la combinación de conjuntos de datos. Ningún control técnico garantiza una prevención absoluta de la reidentificación; los controles legales (acuerdos de procesamiento de datos, limitación de la finalidad) deben complementar los técnicos.
• Escala de monitorización en tiempo real frente a fatiga por alertas: La detección de anomalías de comportamiento reduce significativamente los falsos positivos en comparación con las alertas basadas en reglas, pero ningún sistema de monitorización elimina por completo la fatiga por alertas a escala de big data. La priorización mediante la clasificación de la sensibilidad de los datos reduce el problema, pero requiere una clasificación precisa como requisito previo.
• El cumplimiento normativo no equivale a la seguridad: Cumplir con los requisitos del RGPD, HIPAA o PCI DSS es un mínimo, no un máximo. Los marcos de cumplimiento describen los controles mínimos necesarios en función de las amenazas conocidas en el momento de su redacción. La evaluación de seguridad basada en amenazas identifica las brechas entre los requisitos de cumplimiento y el entorno real de amenazas al que se enfrentan los datos de una organización específica.

Cómo puede ayudar la consultoría de cifrado

• Servicios de asesoramiento sobre cifrado: nuestro mapa de Servicios de asesoramiento sobre cifrado Evaluamos la cobertura de cifrado en todo su entorno de big data, identificando almacenes de datos sin cifrar, algoritmos débiles, falta de cifrado en tránsito para la comunicación del clúster y deficiencias en la gestión de claves. Ofrecemos una hoja de ruta de remediación priorizada que cumple con los requisitos de NIST, GDPR, HIPAA y PCI DSS.
• CBOM Seguro: CBOM seguro Analiza su entorno para generar una lista completa de materiales criptográficos (CBOM, por sus siglas en inglés), que muestra todos los algoritmos, claves y certificados utilizados en su plataforma de big data. Identifica almacenes de datos no cifrados, algoritmos débiles o en desuso y claves no administradas, que representan los objetivos de remediación de máxima prioridad.
• HSM como servicio: HSM como servicio Proporciona almacenamiento de claves de hardware validado según FIPS 140-3 para las claves de cifrado que protegen su entorno de big data, lo que garantiza que la vulneración de claves y datos no pueda ocurrir simultáneamente, incluso en caso de una brecha de seguridad sofisticada.
• Servicios de asesoramiento en materia de cumplimiento normativo: nuestro mapa de Servicios de asesoramiento sobre cumplimiento Ayudamos a las organizaciones a alinear sus controles de seguridad de big data con los requisitos del RGPD, HIPAA, CCPA y PCI DSS, a elaborar la documentación necesaria para las auditorías regulatorias y a realizar las evaluaciones de riesgos exigidas por HIPAA y PCI DSS con una periodicidad definida.
• Servicios de asesoramiento de PQC: Para entornos de big data que almacenan datos sensibles de larga duración sujetos al riesgo HNDL, nuestra Servicios de asesoramiento de PQC Evaluar la exposición cuántica y elaborar una hoja de ruta para la migración a algoritmos post-cuánticos estandarizados por el NIST (FIPS 203, 204, 205), en consonancia con el calendario de descontinuación de 2030 del NIST IR 8547.

Conclusión

La seguridad de los macrodatos no se resuelve con un solo control. La escala, la velocidad, la variedad y la arquitectura distribuida que caracterizan a los entornos de macrodatos implican que ningún control individual, ya sea cifrado, control de acceso o monitorización, proporciona una protección adecuada. Una seguridad eficaz requiere controles que funcionen en conjunto: clasificación para determinar qué protecciones se aplican, cifrado para que los datos comprometidos sean ilegibles, controles de acceso para prevenir el acceso no autorizado, validación de entrada para evitar la contaminación de datos y monitorización continua para detectar las deficiencias en la prevención.

El panorama del cumplimiento normativo también se ha adaptado al big data: el derecho de supresión del RGPD exige la capacidad de localizar y eliminar registros individuales específicos en plataformas distribuidas; la HIPAA exige el cifrado de la información médica electrónica protegida (ePHI) dondequiera que se encuentre; y la norma PCI DSS v4.0 exige controles de acceso y registros de auditoría que abarquen los entornos de big data que procesan datos de pago. Cumplir con estos requisitos exige los mismos controles técnicos por capas que una seguridad sólida.

Si desea evaluar la cobertura de cifrado de sus macrodatos, identificar almacenes de datos desprotegidos o elaborar la documentación de cumplimiento que exigen sus obligaciones regulatorias, póngase en contacto con Encryption Consulting para hablar sobre por dónde empezar.

Preguntas frecuentes

¿Cuáles son los principales desafíos de seguridad del big data?

Siete desafíos principales: asegurar la computación distribuida (MapReduce, Spark); proteger el almacenamiento de múltiples niveles y los registros de transacciones; validar las entradas de puntos finales no confiables; asegurar las bases de datos NoSQL que históricamente carecían de cifrado y autenticación nativos; habilitar análisis que preserven la privacidad y eviten la inferencia de información de identificación personal; aplicar un control de acceso granular a nivel de columna y fila; y mantener la supervisión de seguridad en tiempo real a la escala que generan los entornos de big data.

¿Cómo protege el cifrado los macrodatos?

AES-256-GCM cifra los datos en reposo en HDFS, almacenamiento de objetos y bases de datos NoSQL. TLS 1.3 protege los datos en tránsito entre las etapas del flujo de datos, los nodos del clúster y los consumidores de datos. La tokenización reemplaza la información de identificación personal (PII) con tokens irreversibles antes de que los datos ingresen a los flujos de análisis. La gestión de claves respaldada por HSM garantiza que las claves y los datos no se vean comprometidos simultáneamente.

¿Cuándo debería utilizarse la tokenización en lugar del cifrado en el análisis de grandes volúmenes de datos?

La tokenización es preferible cuando los procesos analíticos necesitan combinar registros por identificador sin acceder a la información de identificación personal subyacente, cuando se requiere reducir el alcance de PCI DSS (los números de tarjeta de pago tokenizados eliminan los datos asociados del entorno de datos del titular de la tarjeta) o cuando los datos se comparten con proveedores de análisis externos que no deben tener acceso a los valores originales. El cifrado es preferible cuando los datos originales deben poder recuperarse mediante procesos autorizados.

¿Qué marcos de cumplimiento normativo se aplican a la seguridad de los macrodatos?

El RGPD exige cifrado, seudonimización, minimización de datos y la capacidad de localizar y eliminar registros individuales. La HIPAA exige el cifrado de la información médica electrónica protegida (ePHI) en reposo y en tránsito, controles de acceso y registro de auditoría. La CCPA exige la capacidad de identificar, recuperar y eliminar registros de consumidores específicos de California. La norma PCI DSS v4.0 exige cifrado, controles de acceso y registro de datos de tarjetas de pago.

¿Qué es HDNL y por qué es importante para el big data?

HNDL (Harvest Now, Decrypt Later) es una amenaza de computación cuántica en la que un atacante copia datos cifrados hoy para descifrarlos cuando haya una computadora cuántica disponible. Los entornos de big data son objetivos de alto valor para HNDL porque concentran grandes volúmenes de registros sensibles. El NIST finalizó ML-KEM (FIPS 203), ML-DSA (FIPS 204) y SLH-DSA (FIPS 205) en agosto de 2024. Las organizaciones que almacenan big data sensibles de larga duración deben evaluar su exposición a HNDL y planificar la migración a algoritmos resistentes a la computación cuántica.

¿Cómo se debe implementar el control de acceso en las plataformas de big data?

Se requieren controles de acceso por capas: control de acceso basado en roles (RBAC) a nivel de plataforma que limite quién puede conectarse; seguridad a nivel de columna que restrinja el acceso a campos confidenciales dentro de las tablas; seguridad a nivel de fila que filtre los registros por atributos de usuario; cifrado a nivel de campo con controles de acceso de clave que garanticen que el acceso al sistema de archivos no pueda eludir los controles a nivel de aplicación; y administración centralizada de identidades que aplique permisos de manera consistente en todos los nodos del clúster distribuido.