Seguridad del lago de datos en la nube

La seguridad de los lagos de datos en la nube comprende el conjunto de controles de cifrado, control de acceso, gestión de claves y monitorización que protegen un repositorio centralizado de datos en la nube contra el acceso no autorizado y las infracciones normativas. Es fundamental porque los lagos de datos consolidan datos estructurados, semiestructurados y no estructurados de toda la empresa en un único destino, lo que los convierte en un objetivo de alto valor para las brechas de seguridad. El punto de partida recomendado es cifrar todos los datos en reposo con una clave de cifrado gestionada por el cliente, aplicar el principio de mínimo privilegio para cada zona del lago de datos, habilitar el registro de auditoría de todas las operaciones con claves y decidir con antelación si la gestión nativa de claves en la nube, BYOK (Bring Your Own Key) o HYOK (Hyper Key Key) se ajusta a sus requisitos de soberanía de datos.

Respuesta rápida: ¿Qué requisitos debe cumplir un lago de datos en la nube seguro?

Un lago de datos en la nube seguro requiere cuatro controles que funcionen conjuntamente: cifrado en reposo para cada objeto en cada zona mediante AES-256, aplicado con claves gestionadas por el cliente que usted controla y puede auditar; cifrado en tránsito mediante TLS aplicado por políticas de depósitos de almacenamiento; gestión de identidades y accesos que otorga a cada rol solo los permisos que necesita para las zonas específicas en las que opera; y un registro de auditoría que captura cada operación de lectura, escritura y clave vinculada a una identidad autenticada. Los marcos de cumplimiento, incluidos HIPAA, PCI DSS, GDPR y FedRAMP, requieren los cuatro controles. Ninguno de estos controles por sí solo es suficiente.

Puntos Clave

• Los lagos de datos son objetivos de alto valor para las filtraciones de datos: Consolidar todos los datos de la organización en un solo lugar simplifica el análisis, pero crea un único punto vulnerable. La seguridad debe integrarse en la arquitectura, no añadirse una vez que los datos ya están fluyendo.
• El control de acceso basado en zonas es la base arquitectónica: Dividir el lago de datos en zonas temporales, sin procesar, de confianza y refinadas permite aplicar diferentes claves de cifrado y políticas de acceso a cada zona, lo que limita el movimiento lateral si alguna zona se ve comprometida.
• Las claves de cifrado gestionadas por el cliente son el requisito mínimo para los datos regulados: El cifrado nativo en la nube (claves gestionadas por el proveedor) protege contra el robo de almacenamiento físico, pero no ofrece un registro de auditoría ni un control de claves independiente. Las claves gestionadas por el cliente (CMK) ofrecen ambas ventajas.
• BYOK vs. HYOK es una decisión sobre soberanía: BYOK conserva la procedencia del material clave, pero permite que el proveedor de la nube utilice la clave operativamente. HYOK (cifrado del lado del cliente antes de la carga) significa que el proveedor de la nube nunca accede al texto sin cifrar bajo ninguna circunstancia.
• El registro de auditoría debe abarcar tanto los eventos de almacenamiento como los eventos clave: Los registros de acceso al almacenamiento registran quién leyó o escribió datos. Los registros del servicio de administración de claves registran quién los cifró o descifró. Ambos son necesarios para un paquete completo de evidencia de cumplimiento.

¿Qué es un lago de datos en la nube?

Un lago de datos es un repositorio centralizado que almacena datos sin procesar en su formato original hasta que se necesiten para su análisis o procesamiento. A diferencia de un almacén de datos, que requiere que los datos estén estructurados y transformados antes de su ingesta, un lago de datos acepta cualquier formato: datos relacionales estructurados, archivos JSON o Parquet semiestructurados, archivos de texto o de registro no estructurados, medios binarios y telemetría en tiempo real. La capa de almacenamiento suele ser almacenamiento de objetos en la nube: Amazon S3 para lagos de datos de AWS, Azure Data Lake Storage Gen2 (ADLS Gen2) para Azure y Google Cloud Storage (GCS) para GCP.

Los lagos de datos en la nube se construyen sobre esta base de almacenamiento de objetos y se complementan con motores de computación (Amazon EMR, Azure Databricks, Google Dataproc), motores de consulta (Amazon Athena, Azure Synapse Analytics, BigQuery) y herramientas de catalogación y gobernanza de datos (AWS Glue Data Catalog, Microsoft Purview, Google Dataplex). Los controles de seguridad deben aplicarse en cada capa de esta arquitectura, no solo a nivel de depósito de almacenamiento.

¿Por qué los lagos de datos en la nube son objetivos de alto valor para las filtraciones de datos?

La misma propiedad que hace que los lagos de datos sean valiosos para el análisis (consolidar todos los datos de la organización en un solo lugar) los convierte en objetivos atractivos para los atacantes. Un solo bucket de S3 mal configurado o una cuenta de servicio con privilegios excesivos pueden exponer datos de múltiples unidades de negocio simultáneamente. Los vectores de ataque comunes contra los lagos de datos en la nube incluyen políticas de bucket mal configuradas que otorgan acceso de lectura público, roles de IAM con privilegios excesivos utilizados por cargas de trabajo de análisis que también tienen acceso a información de identificación personal (PII) sin procesar, credenciales comprometidas utilizadas para extraer datos a gran escala del almacenamiento de objetos y ataques a la cadena de suministro dirigidos a herramientas de canalización de datos que tienen acceso de escritura a datos de la zona de confianza.

El modelo de amenazas para un lago de datos difiere del de una base de datos transaccional. Los lagos de datos suelen contener datos históricos de varios años, múltiples tipos de datos y datos de empresas adquiridas con diferentes estándares de seguridad originales. Los controles de seguridad deben tener en cuenta esta diversidad y aplicarse de forma coherente, incluso a medida que aumenta el volumen y la variedad de datos en el lago.

Zonificación de Data Lake: La base de la arquitectura de seguridad

La zonificación divide el lago de datos en áreas de almacenamiento separadas según la etapa de procesamiento de datos, la sensibilidad y los requisitos de acceso. Las cuatro zonas estándar son:

• Zona temporal: Almacena datos de ingesta transitorios que no requieren retención a largo plazo. Los datos en esta zona suelen estar sin validar y pueden contener flujos de eventos sin procesar o registros incompletos. El acceso debe restringirse únicamente a las canalizaciones de ingesta de datos.
• Zona cruda: Almacena los datos tal como se recibieron de los sistemas de origen, en su formato original y con total fidelidad. Los datos de la zona sin procesar suelen contener información de identificación personal (PII), información de salud protegida (PHI) y otros campos confidenciales que aún no se han enmascarado ni tokenizado. El acceso a la zona sin procesar debe restringirse a los ingenieros de datos y a los procesos de procesamiento de datos, no a los analistas ni a los usuarios finales.
• Zona segura: Contiene datos validados, depurados, transformados y, en muchos casos, anonimizados o enmascarados. Los datos en esta zona están listos para ser utilizados por cargas de trabajo analíticas, científicos de datos y herramientas de inteligencia empresarial. El acceso es más amplio que en la zona de datos sin procesar, pero sigue estando restringido por roles.
• Zona refinada: Contiene resultados agregados, resumidos o diseñados específicamente para el procesamiento analítico. Los datos en esta zona a menudo se han reducido o anonimizado aún más. Aquí es donde normalmente se conectan los usuarios finales y las herramientas de generación de informes.

Desde el punto de vista de la seguridad, cada zona debe tener su propia clave de cifrado (o jerarquía de claves), sus propias políticas de acceso y su propio registro de auditoría. Un incidente de seguridad que comprometa una zona no debería otorgar acceso automáticamente a las demás. Aplique roles de IAM, claves KMS y políticas de almacenamiento independientes para cada zona.

Cifrado para lagos de datos en la nube: en reposo y en tránsito

Todos los principales marcos de cumplimiento para lagos de datos en la nube requieren cifrado tanto en reposo (para proteger los objetos almacenados) como en tránsito (para proteger los datos mientras se mueven entre servicios). Estos requieren configuraciones independientes y no se proporcionan automáticamente de forma conjunta.

El cifrado en reposo en un lago de datos en la nube implica que cada objeto almacenado en el almacenamiento de objetos en la nube subyacente se cifra antes de escribirse en el disco. El algoritmo de cifrado es AES-256 (Estándar de Cifrado Avanzado con una clave de 256 bits), normalmente en GCM (Modo de Contador de Galois), que proporciona cifrado autenticado. La cuestión clave no es si se produce el cifrado (los tres principales proveedores de servicios en la nube cifran el almacenamiento de objetos por defecto), sino quién controla las claves de cifrado.

El cifrado en tránsito implica que todos los datos que se mueven entre clientes, motores de procesamiento y almacenamiento de objetos viajan a través de TLS (Transport Layer Security). Los proveedores de la nube admiten HTTPS para el acceso al almacenamiento de objetos, pero es necesario implementarlo mediante políticas de depósito de almacenamiento que rechacen cualquier solicitud que no utilice HTTPS. Sin una política de rechazo explícita, algunos SDK y aplicaciones heredadas podrían recurrir a HTTP, enviando los datos en texto plano.

Más allá del cifrado en reposo y en tránsito, las cargas de trabajo de data lake que utilizan formatos de almacenamiento columnar (Parquet, ORC) también deberían evaluar el cifrado a nivel de columna, que cifra columnas sensibles específicas (número de la seguridad social, número de tarjeta de crédito, fecha de nacimiento) dentro de un formato de archivo analítico, dejando las columnas no sensibles accesibles para las consultas analíticas sin necesidad de descifrado. Apache Parquet admite el cifrado a nivel de columna de forma nativa, lo que resulta útil para datos de zonas de confianza que deben ser consultados por analistas que no deberían ver campos de información personal identificable (PII).

Control de clave nativa frente a BYOK frente a HYOK: La decisión de soberanía

La decisión de seguridad más importante para un lago de datos en la nube es quién controla las claves de cifrado. Existen tres modelos, cada uno con diferentes implicaciones en cuanto a cumplimiento normativo, complejidad operativa y coste.

Opción 1: Claves nativas del proveedor de la nube (gestionadas por el proveedor)

El proveedor de la nube genera, almacena, rota y administra todas las claves de cifrado. En AWS, esto se refiere a la clave de servicio aws/s3; en Azure, a las claves administradas por Microsoft; y en GCP, a las claves de cifrado administradas por Google (GMEK). Los datos están cifrados, pero el proveedor controla las claves. No es posible deshabilitar la clave de forma independiente para revocar el acceso, ni auditar las operaciones de descifrado individuales con identidades específicas, ni demostrar a un organismo regulador que el acceso a las claves está separado del acceso a los datos.

La gestión nativa de claves del proveedor es adecuada para datos no regulados donde la simplicidad es la prioridad. Sin embargo, resulta insuficiente para cargas de trabajo que cumplen con HIPAA, PCI DSS, FedRAMP o GDPR, las cuales requieren que el cliente tenga control sobre las claves de cifrado.

Opción 2: BYOK (Trae tu propia llave)

BYOK significa que usted genera el material de clave de cifrado fuera del proveedor de la nube y lo importa al servicio de administración de claves del proveedor: AWS KMS, Azure Key Vault o GCP Cloud KMS. El KMS del proveedor de la nube utiliza su material de clave para generar las claves de cifrado de datos que protegen los objetos de su lago de datos. Usted conserva el material de clave de origen en su propio HSM y puede eliminarlo del KMS del proveedor de la nube para revocar inmediatamente la capacidad del proveedor para descifrar sus datos.

Con BYOK y una clave gestionada por el cliente, obtendrá un registro de auditoría completo: cada evento de cifrado y descifrado se registra en el servicio de auditoría del proveedor de la nube (CloudTrail para AWS, Azure Monitor para Azure, Cloud Audit Logs para GCP) con el ID de la clave, la identidad del solicitante y una marca de tiempo. Puede desactivar la clave para impedir cualquier descifrado posterior de inmediato sin eliminar sus datos. Puede rotar el material de la clave según su propio calendario.

La contrapartida: durante el uso activo, el sistema de gestión de claves (KMS) del proveedor de la nube tiene acceso operativo al material de clave para realizar operaciones de cifrado y descifrado. BYOK satisface los requisitos de procedencia de claves del cliente, pero no los requisitos que exigen que el proveedor de la nube no tenga acceso a la clave en ningún momento.

Opción 3: HYOK (Mantén tu propia llave)

HYOK significa que su aplicación cifra los datos antes de subirlos al almacenamiento de objetos en la nube. Lo que el proveedor de la nube almacena ya está cifrado; el proveedor nunca tiene acceso al texto sin cifrar ni a la clave de cifrado bajo ninguna circunstancia, ni siquiera en caso de requerimiento legal. Este es el único modelo que excluye por completo al proveedor de la nube de la cadena de confianza de sus datos.

HYOK requiere que su aplicación o canalización de datos gestione todas las operaciones criptográficas antes de que los datos entren en la nube, que su sistema externo de gestión de claves tenga una alta disponibilidad (porque cada escritura y lectura del lago de datos requiere una operación de clave contra su KMS externo) y que su equipo gestione el ciclo de vida completo de las claves, incluida la rotación de claves, la copia de seguridad y la recuperación ante desastres para la infraestructura externa de gestión de claves.

HYOK es apropiado para datos clasificados, datos sujetos a estrictos requisitos nacionales de soberanía de datos donde el acceso de gobiernos extranjeros a la infraestructura del proveedor de la nube constituye un modelo de amenaza creíble, o datos donde los requisitos reglamentarios exigen explícitamente que el proveedor de la nube no tenga acceso a las claves de cifrado.

Dimensión	Claves nativas (gestionadas por el proveedor)	BYOK (Clave gestionada por el cliente en KMS en la nube)	HYOK (Cifrado del lado del cliente)
Clave generada por	Proveedor de la nube	Cliente (importado al sistema de gestión del conocimiento en la nube)	Cliente (nunca accede a la nube)
Acceso del proveedor a la clave durante el uso	Sí:	Sí (operativo)	No
Registro de auditoría por operación	No	Sí (en los registros de auditoría de KMS en la nube)	Solo si su KMS externo lo registra
Desactivar/revocar clave independiente	No	Sí (desactive CMK inmediatamente)	Sí (revocar en su KMS externo)
Rotación automática de la llave	Sí (horario del proveedor)	Sí (anual para CMK) o manual para material importado.	Gestión totalmente centrada en el cliente.
Complejidad operativa	Bajo	Media	Alto
Costo	Incluido en el costo de almacenamiento.	Tarifa de clave KMS + tarifa por llamada a la API	Costo de la infraestructura externa de KMS
Ideal para	Datos analíticos internos no regulados	Datos regulados por HIPAA, PCI DSS, FedRAMP y GDPR	Datos clasificados, impuestos por la soberanía y de confianza cero.

Modelo IAM: Principio de mínimo privilegio para el acceso a lagos de datos en la nube

El principio del mínimo privilegio exige que cada identidad (usuario humano, cuenta de servicio o aplicación) tenga acceso únicamente a las zonas específicas del lago de datos, las ubicaciones de almacenamiento y las operaciones que necesita para realizar su función definida. En un lago de datos en la nube, esto significa diseñar controles de acceso en tres niveles:

Políticas de identidad (por rol): Defina qué acciones puede realizar cada rol. Un rol de canalización de ingesta de datos necesita acceso de escritura solo a la zona temporal. Un rol de ingeniería de datos necesita acceso de lectura a la zona sin procesar y acceso de escritura a la zona de confianza. Un rol de análisis necesita acceso de lectura solo a las zonas de confianza y refinada. Ningún rol de análisis debe tener acceso de lectura a la zona sin procesar donde reside la información de identificación personal sin enmascarar. Separe los permisos de uso de claves de los permisos de administración de claves: un rol que puede cifrar y descifrar datos usando una clave KMS no debe poder rotar, deshabilitar o eliminar esa clave.

Políticas de recursos (por zona): Aplique políticas de bucket o contenedor que denieguen explícitamente el acceso a las entidades principales que no estén en la lista de roles aprobados para esa zona, independientemente de las políticas de identidad. Las políticas de denegación basadas en recursos proporcionan una segunda capa de defensa: incluso si una política de identidad está mal configurada para otorgar un acceso más amplio, la denegación a nivel de recurso impide la operación. Deniegue el acceso a la zona raw para todas las entidades principales, excepto el rol de ingeniería de datos y las cuentas de servicio de canalización de datos. Deniegue el acceso de escritura a la zona de confianza para todas las entidades principales, excepto la canalización de transformación.

Políticas de claves de cifrado (por CMK): La clave KMS administrada por el cliente de cada zona debe tener una política de claves que defina por separado a los administradores de claves (quienes pueden administrar la clave) y a los usuarios de claves (quienes pueden usar la clave para cifrar y descifrar). Ninguna identidad debe ser a la vez administradora y usuaria de la misma clave. Para arquitecturas de lago de datos entre cuentas, una política de claves basada en recursos debe otorgar explícitamente al principal entre cuentas permiso para usar la clave, además de la política de identidad propia del principal.

Rotación de claves en un lago de datos en la nube

La rotación de claves en un entorno de lago de datos en la nube implica rotar la clave administrada por el cliente (CMK) que protege las claves de cifrado de datos a nivel de zona, no volver a cifrar todos los objetos del lago de datos. Al habilitar la rotación anual automática de una CMK en AWS KMS, Azure Key Vault o GCP Cloud KMS, el servicio genera nuevo material criptográfico según la programación configurada. Los nuevos objetos que se escriben en el lago de datos utilizan el nuevo material de clave. Los objetos existentes permanecen cifrados con la versión de clave que estaba activa cuando se cargaron, y KMS conserva todas las versiones anteriores de clave para descifrar esos objetos antiguos. No es necesario volver a cargar ningún objeto.

Para las claves BYOK con material importado, la rotación automática no está disponible a través del KMS del proveedor de la nube. Debe gestionar la rotación externamente: genere nuevo material de clave en su HSM, impórtelo al CMK como una nueva versión de clave, designe esta como la versión de clave principal y espere a que finalicen las operaciones en curso antes de dejar de utilizar la versión anterior. Este proceso requiere una coordinación minuciosa entre todos los flujos de datos que utilizan la clave.

Además de la rotación de CMK, los entornos de data lake también deben rotar las credenciales de las cuentas de servicio y las claves de acceso de IAM según un cronograma definido, y auditar todas las credenciales activas comparándolas con la lista de credenciales que deberían permanecer activas. Las credenciales de larga duración utilizadas por las canalizaciones de ingesta de datos son una fuente común de acceso no autorizado.

Registro de auditoría para la seguridad de lagos de datos en la nube

Para obtener un registro de auditoría completo de un lago de datos en la nube, es necesario registrar los eventos en dos niveles: eventos de acceso al almacenamiento y eventos de gestión de claves. Ninguno de los dos por sí solo es suficiente para cumplir con la normativa.

Los registros de acceso al almacenamiento capturan quién leyó, escribió, listó o eliminó objetos en cada zona del lago de datos. En AWS, el registro de acceso al servidor S3 y los eventos de datos de S3 CloudTrail cubren las operaciones a nivel de objeto. En Azure, los registros de diagnóstico de ADLS Gen2 cubren las operaciones de lectura y escritura en los contenedores de almacenamiento. En GCP, los registros de auditoría de Cloud cubren el acceso a los objetos en los buckets de Cloud Storage. Los registros de almacenamiento deben habilitarse explícitamente; por lo general, no están activados de forma predeterminada. Dirija los registros de almacenamiento a una cuenta de auditoría independiente y protegida contra escritura para evitar manipulaciones.

Los registros de administración de claves capturan cada operación de cifrado y descifrado vinculada a una clave maestra de cliente (CMK) específica, incluyendo la identidad solicitante, la marca de tiempo y el recurso que se cifra o descifra. En AWS, cada llamada a la API de KMS aparece en CloudTrail. En Azure, los registros de auditoría de Key Vault capturan las operaciones de clave. En GCP, los registros de auditoría de Cloud KMS capturan las operaciones criptográficas. Los registros de administración de claves proporcionan evidencia vinculada a la identidad de que se accedió a los datos, no solo de que un proceso desconocido modificó un objeto.

Alerta sobre los siguientes patrones: cualquier operación de descifrado por parte de una entidad principal que no esté en la lista de roles aprobados para la CMK de esa zona; solicitudes de descifrado de alto volumen (posible exfiltración de datos); cualquier intento de deshabilitar o eliminar una CMK de lago de datos; y cualquier acceso al almacenamiento desde una dirección IP o ubicación geográfica fuera de su perímetro operativo previsto.

Mejores prácticas de seguridad para lagos de datos en la nube

1. Clasifique los datos antes de que entren en el lago: Antes de ingerir cada fuente de datos, asigné una clasificación de sensibilidad. Esta clasificación determina la zona a la que acceden los datos, la clave de cifrado que los protege y las políticas de acceso que se aplican. Los datos que acceden a la zona sin clasificar se clasifican automáticamente con el nivel de sensibilidad más alto.
2. Aplicar claves de cifrado específicas para cada zona: Utilice una clave KMS independiente gestionada por el cliente para cada zona. Si la clave de zona de confianza se ve comprometida, los datos brutos de la zona permanecen protegidos. Si es necesario rotar la clave de zona de confianza debido a una posible vulneración, los datos de zona de confianza y refinados no se verán afectados.
3. Implemente el cifrado mediante políticas de recursos, no solo con valores predeterminados: Configure el cifrado predeterminado del bucket o contenedor según el método que prefiera, pero también agregue una política de denegación para cualquier solicitud PutObject que no incluya el encabezado de cifrado requerido. El cifrado predeterminado es una configuración predeterminada, no una imposición; un cliente mal configurado puede anularlo sin una política de denegación.
4. Separe las funciones del lago de datos de las funciones clave de gestión: Ningún rol de ingeniería de datos o análisis debería tener permisos de administración de claves KMS. La administración de claves (creación, rotación, desactivación, eliminación) debería requerir un flujo de trabajo independiente y auditado a través de un rol de operaciones de seguridad específico.
5. Habilite el bloqueo de objetos S3 o equivalente para los registros de auditoría: Configure el bucket o contenedor de destino de su registro de auditoría con protección WORM (Write Once, Read Many) para evitar que una cuenta comprometida modifique o elimine los registros. Los registros de auditoría inmutables son una prueba necesaria para las auditorías SOC 2, FedRAMP y PCI DSS.
6. Analizar automáticamente la zona de datos sin procesar en busca de información confidencial: Utilice herramientas de detección de datos nativas de la nube (Amazon Macie, Microsoft Purview, GCP Cloud DLP) para analizar los datos de la zona sin procesar en busca de información de identificación personal (PII), información de salud protegida (PHI) y otros patrones confidenciales a medida que llegan los datos. Marque los objetos que contengan campos confidenciales para aplicar restricciones de acceso adicionales antes de que se procesen en la zona de confianza.
7. Utilice el cifrado a nivel de columna para cargas de trabajo analíticas: Para los datos Parquet u ORC en la zona de confianza, aplique cifrado a nivel de columna a los campos confidenciales (número de la seguridad social, fecha de nacimiento, número de tarjeta de crédito) para que las consultas analíticas en columnas no confidenciales no requieran claves de descifrado que también desbloqueen las columnas confidenciales.
8. Realizar revisiones trimestrales de acceso: Revise trimestralmente la lista de entidades principales de IAM con acceso a cada zona del lago de datos. Elimine el acceso a los roles que ya no sean necesarios. Verifique que se hayan revocado las cuentas de servicio asociadas a las canalizaciones de datos desactivadas.

Capacidades de seguridad del Data Lake del proveedor de la nube

Cada proveedor importante de servicios en la nube ofrece un conjunto propio de servicios de seguridad que se adaptan a los requisitos de seguridad de los lagos de datos. Comprender lo que ofrece cada proveedor de forma nativa ayuda a identificar las deficiencias que requieren herramientas de terceros o una configuración personalizada.

Seguridad de los lagos de datos de AWS: Amazon S3 sirve como base de almacenamiento. AWS Key Management Service (KMS) proporciona administración de claves gestionada por el cliente con integración de CloudTrail. Amazon Macie proporciona detección y clasificación automatizadas de información de identificación personal (PII) en S3. AWS Lake Formation proporciona una capa de control de acceso unificada sobre S3 que permite definir políticas de acceso a nivel de columna y fila para consultas analíticas, sin necesidad de replicar dichas políticas en cada motor de consulta. AWS Glue Data Catalog proporciona metadatos de clasificación de datos. AWS CloudTrail ofrece registros de operaciones de claves de KMS y registros de eventos de datos de S3.

Seguridad de Azure Data Lake: Azure Data Lake Storage Gen2 (ADLS Gen2) sirve como base de almacenamiento. Azure Key Vault proporciona administración de claves gestionada por el cliente con integración de Azure Monitor. Microsoft Purview proporciona gobernanza de datos, clasificación y etiquetado de confidencialidad en ADLS Gen2. Azure Active Directory (Entra ID) proporciona administración de identidades. Azure Policy proporciona mecanismos de control para aplicar estándares de configuración de cifrado y acceso. Azure Monitor ofrece registros de diagnóstico de almacenamiento y registros de auditoría de Key Vault.

Seguridad del lago de datos de GCP: Google Cloud Storage (GCS) sirve como base de almacenamiento. Google Cloud KMS (incluido Cloud HSM para el almacenamiento de claves FIPS 140-2 Nivel 3) proporciona administración de claves gestionada por el cliente con integración de Cloud Audit Logs. Google Cloud DLP (Prevención de pérdida de datos) proporciona detección y clasificación automatizadas de datos confidenciales en GCS. Dataplex proporciona gobernanza de datos y administración de políticas en todos los buckets de GCS. Cloud Audit Logs proporciona registros de operaciones de KMS y registros de acceso a datos de GCS.

Arquitectura de seguridad para lagos de datos multi-nube

Las organizaciones que gestionan lagos de datos en múltiples proveedores de nube, o que combinan lagos de datos en la nube con almacenes de datos locales, se enfrentan a un desafío de seguridad específico: las herramientas de seguridad nativas de cada proveedor de nube son específicas de dicho proveedor. Las políticas de AWS Lake Formation no se extienden a ADLS Gen2. Las clasificaciones de GCP Cloud DLP no se propagan automáticamente a los objetos de S3. Gestionar inventarios de claves, políticas de acceso, esquemas de clasificación y flujos de registros de auditoría independientes para cada proveedor multiplica la complejidad operativa y aumenta el riesgo de una postura de seguridad inconsistente en todo el entorno.

Existen tres patrones para abordar la seguridad de los lagos de datos en entornos multi-nube:

• Catálogo de datos unificado y capa de clasificación: Implementar una plataforma de clasificación y catalogación de datos independiente de la nube que ingiera metadatos de los tres proveedores, aplique etiquetas de confidencialidad consistentes y garantice políticas de acceso uniformes, independientemente del proveedor que almacene los datos. Este enfoque, que prioriza la gobernanza, es cada vez más común en empresas altamente reguladas con entornos multinube.
• BYOK centralizado con entrega de claves por nube: Genere todo el material de clave de cifrado desde un único HSM externo o sistema de gestión de claves. Importe las claves derivadas a AWS KMS (para lagos de datos S3), Azure Key Vault (para ADLS Gen2) y GCP Cloud KMS (para GCS). Todos los rastros de cifrado se remontan a una única fuente de clave autorizada, lo que garantiza la coherencia en la gestión del ciclo de vida de las claves y la recopilación de pruebas de cumplimiento entre proveedores.
• HYOK con una capa de cifrado compartida: Cifra los datos a nivel de canalización antes de entregarlos a cualquier capa de almacenamiento en la nube. Utiliza la misma biblioteca de cifrado del lado del cliente y la misma clave maestra, independientemente de la nube de destino. Esto proporciona la máxima coherencia y soberanía, pero requiere que todas las canalizaciones de datos gestionen las operaciones criptográficas antes de cualquier llamada a la API de la nube.

Marcos de cumplimiento para la seguridad de los lagos de datos en la nube

Los lagos de datos en la nube que almacenan datos regulados deben cumplir con los controles técnicos específicos requeridos por el marco de cumplimiento aplicable. Los marcos más comunes en las implementaciones de lagos de datos en la nube son:

HIPAA (Ley de Portabilidad y Responsabilidad del Seguro Médico): Requiere cifrado en reposo y en tránsito para la Información de Salud Protegida (PHI), controles de acceso que limiten el acceso a la PHI a personas autorizadas, registro de auditoría de todos los accesos a la PHI y un Acuerdo de Asociado Comercial (BAA) con cualquier proveedor de servicios en la nube que procese PHI. La zona sin procesar de un lago de datos de atención médica generalmente contiene PHI y requiere los controles de acceso más estrictos y una clave maestra de cliente (CMK) dedicada.

PCI DSS (Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago): Requiere el cifrado de los datos del titular de la tarjeta, tanto en reposo como en tránsito, controles de gestión de claves que incluyen la rotación y el control dual para las operaciones con claves, restricciones de acceso a la red y revisiones de acceso trimestrales. Los datos del titular de la tarjeta en un repositorio de datos de pago deben almacenarse en una zona sin procesar segregada con una clave maestra de cliente (CMK) dedicada, accesible únicamente a las canalizaciones de procesamiento de pagos autorizadas.

RGPD (Reglamento General de Protección de Datos): Requiere medidas técnicas y organizativas para proteger los datos personales de los residentes de la UE, incluyendo el cifrado, la seudonimización y la capacidad de garantizar los derechos de los interesados ​​(derecho de acceso, derecho de supresión). Una arquitectura de lago de datos compatible con el RGPD debe poder localizar y eliminar todos los registros asociados a una persona específica en todas las zonas, lo que requiere el etiquetado de datos en el momento de la ingesta y un sistema de linaje de datos consultable.

FedRAMP (Programa Federal de Gestión de Riesgos y Autorización): Requiere módulos criptográficos validados según FIPS 140-2 o FIPS 140-3 para el cifrado, controles de seguridad NIST SP 800-53 Rev. 5 y monitorización continua. Las cargas de trabajo de alto nivel de FedRAMP requieren almacenamiento de claves con HSM de nivel 3 según FIPS 140-2. Los tres principales proveedores de servicios en la nube ofrecen servicios autorizados por FedRAMP para cargas de trabajo de lagos de datos, pero el cliente debe configurar dichos servicios según la línea base de control requerida.

Cómo puede ayudar la consultoría de cifrado

Encryption Consulting es una empresa de criptografía aplicada y seguridad en la nube con certificaciones ISO/IEC 27001:2022 y SOC 2. Ayudamos a las organizaciones a diseñar, implementar y auditar arquitecturas de seguridad para lagos de datos en la nube, desde el diseño inicial del cifrado hasta la recopilación continua de evidencia de cumplimiento.

• Aviso sobre la protección de datos en la nube: Evaluamos la configuración actual de cifrado de su lago de datos, identificamos deficiencias (zonas no cifradas, claves administradas por el proveedor donde se requieren CMK, falta de registro de auditoría, cuentas de servicio con privilegios excesivos) y diseñamos la arquitectura de seguridad objetivo, que incluye una jerarquía de CMK basada en zonas, un modelo de privilegios mínimos de IAM, la aplicación de políticas de bucket y un programa de rotación. Consulte nuestra servicios de consultoría en la nube.
• HSM como servicio: Para arquitecturas de lago de datos BYOK y HYOK donde el material de clave de cifrado debe generarse en un HSM validado por FIPS fuera del proveedor de la nube, Encryption Consulting HSM como servicio Proporciona una infraestructura HSM dedicada con certificación FIPS 140-2 de nivel 3, con integración en los flujos de trabajo de importación de claves de AWS KMS, Azure Key Vault y GCP Cloud KMS.
• CBOM Seguro: Los entornos de lagos de datos multi-nube a menudo acumulan configuraciones de cifrado inconsistentes en cientos de buckets y contenedores. CBOM seguro Descubre e inventaría todas las configuraciones de cifrado de almacenamiento, las configuraciones de claves KMS y las políticas de acceso en las cuentas de AWS, Azure y GCP, generando una lista de materiales criptográficos (CBOM) en formato CycloneDX que identifica las brechas de seguridad y admite paquetes de evidencia de auditoría.
• Infraestructura de clave pública como servicio: Para entornos de lagos de datos que utilizan TLS mutuo (mTLS) para la autenticación de servicio a servicio entre componentes de canalización de datos, Encryption Consulting ofrece soluciones. PKI como servicio Proporciona una CA privada gestionada con administración automatizada del ciclo de vida de los certificados mediante ACME, lo que garantiza que los certificados de la canalización de datos estén siempre actualizados y con el alcance adecuado.
• Asesoramiento sobre cumplimiento normativo (HIPAA, PCI DSS, FedRAMP, GDPR): Mapeamos los controles de seguridad de su lago de datos a los requisitos técnicos específicos de su marco de cumplimiento, identificamos las brechas de control, elaboramos el plan de remediación y producimos el paquete de evidencia para su auditoría. Servicios de asesoramiento sobre cumplimiento Cubre HIPAA, PCI DSS, FedRAMP, GDPR, NIST CSF 2.0 y NIST SP 800-53 Rev. 5.
• Preparación para PQC: El NIST finalizó los estándares de criptografía post-cuántica FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA) en agosto de 2024. El NIST IR 8547 apunta a la desaprobación de RSA y ECC para nuevos usos alrededor de 2030. Si bien AES-256-GCM, utilizado para el cifrado de objetos de lagos de datos, se considera resistente a la computación cuántica, la infraestructura de gestión de claves (encapsulación de claves KMS, conexiones TLS entre componentes de la canalización) deberá adaptarse. Preparación para PQC Este servicio compara la postura criptográfica de su lago de datos con el cronograma de migración post-cuántica.

Para hablar sobre sus requisitos de seguridad para el lago de datos en la nube, póngase en contacto con Encryption Consulting.

Conclusión

Los lagos de datos en la nube consolidan los datos organizacionales a una escala y variedad que los almacenes de datos tradicionales no pueden igualar. Esta misma consolidación los convierte en el objetivo de mayor valor en un entorno de nube. Los controles de seguridad necesarios para proteger un lago de datos no son mejoras opcionales; son parte fundamental de la arquitectura.

La arquitectura basada en zonas es fundamental: permite aplicar diferentes claves de cifrado, políticas de acceso y controles de retención a los datos en distintas etapas de procesamiento y niveles de sensibilidad, limitando así el impacto de cualquier vulneración. Las claves de cifrado gestionadas por el cliente son el requisito mínimo para cargas de trabajo reguladas: proporcionan el registro de auditoría y el control independiente de claves que las claves gestionadas por el proveedor no pueden ofrecer. BYOK cumple con los requisitos de procedencia de claves; HYOK cumple con los requisitos de soberanía de datos de confianza cero, donde el proveedor de la nube debe quedar totalmente excluido de la jerarquía de claves.

El modelo IAM, la aplicación de políticas de bucket, el cronograma de rotación de claves y la configuración del registro de auditoría son tan importantes como la elección del algoritmo de cifrado. Una seguridad de data lake que solo cumple con el requisito de cifrado sin abordar el control de acceso, la gobernanza de claves y la monitorización continua deja expuestas las vulnerabilidades más importantes.

Preguntas frecuentes

¿Qué es la seguridad de los lagos de datos en la nube?

La seguridad de un lago de datos en la nube es el conjunto de controles que protegen un repositorio centralizado de datos en la nube contra el acceso no autorizado y las infracciones de cumplimiento. Los controles principales son el cifrado en reposo (AES-256 con claves gestionadas por el cliente) y en tránsito (TLS aplicado mediante políticas de bucket), la gestión de identidades y accesos que aplica el principio de mínimo privilegio por zona del lago de datos, la gestión de claves de cifrado, incluida la rotación y el registro de auditoría, la clasificación de datos y la monitorización continua mediante SIEM y herramientas de seguridad nativas de la nube.

¿Cuál es la diferencia entre BYOK y HYOK en un lago de datos en la nube?

BYOK implica generar el material de clave fuera del proveedor de la nube e importarlo a su KMS. El proveedor utiliza la clave para las operaciones de cifrado, por lo que tiene acceso operativo a ella durante su uso, pero no al material original. HYOK implica cifrar los datos antes de subirlos, de modo que el proveedor de la nube solo almacena el texto cifrado y nunca tiene acceso a la clave de cifrado bajo ninguna circunstancia. HYOK ofrece la máxima seguridad, aunque a costa de una mayor complejidad de la aplicación y mayores requisitos de infraestructura KMS externa.

¿Cómo se garantiza el acceso con privilegios mínimos en un lago de datos en la nube?

Aplique el principio de mínimo privilegio mediante tres capas de control: políticas de identidad que otorgan a cada rol solo los permisos necesarios para las zonas específicas en las que opera; políticas de bucket o contenedor basadas en recursos que deniegan explícitamente el acceso a las entidades principales que no figuran en la lista de roles aprobados para esa zona; y políticas de claves KMS que separan a los administradores de claves (que pueden gestionar las claves) de los usuarios de claves (que pueden cifrar y descifrar). Aplique políticas independientes para cada zona del lago de datos, de modo que el acceso directo a la zona no otorgue automáticamente acceso a la zona de confianza.

¿Qué marcos de cumplimiento se aplican a la seguridad de los lagos de datos en la nube?

HIPAA se aplica a los lagos de datos de salud que contienen PHI y requiere cifrado, controles de acceso y registro de auditoría. PCI DSS se aplica a los lagos de datos de pago y requiere cifrado, rotación de claves, control dual para operaciones de claves y revisiones de acceso. GDPR se aplica a los datos personales de los residentes de la UE y requiere controles técnicos, además de la capacidad de cumplir con los derechos de los interesados, incluido el borrado. FedRAMP se aplica a las cargas de trabajo en la nube del gobierno de EE. UU. y hace referencia a los controles NIST SP 800-53 Rev. 5 con módulos criptográficos validados FIPS 140-2 o 140-3 requeridos para la línea base alta.

¿Cómo funciona la rotación de claves de cifrado en un lago de datos en la nube?

La rotación de claves funciona mediante el KMS del proveedor de la nube, que rota el material criptográfico de la clave administrada por el cliente según el cronograma configurado. Los nuevos objetos que se escriben en el lago de datos utilizan el nuevo material de clave. Los objetos existentes permanecen cifrados con la versión de clave activa en el momento de su escritura, y el KMS conserva todas las versiones anteriores para su descifrado. No es necesario volver a cifrar ni a cargar los objetos existentes del lago de datos. Para las claves BYOK con material importado, la rotación automática no está disponible a través del KMS en la nube; debe gestionar la rotación externamente y volver a importar el material de clave actualizado.

¿Qué es la zonificación de lagos de datos y por qué es importante para la seguridad?

La zonificación del lago de datos divide el lago en áreas de almacenamiento separadas según la etapa de procesamiento de datos: temporal (datos de ingesta transitorios), sin procesar (formato original, que a menudo contiene información personal identificable), confiable (validado y procesado, listo para el análisis) y refinado (resultados agregados). La zonificación es importante porque permite aplicar diferentes claves de cifrado, políticas de acceso y políticas de retención a cada zona. Una vulneración de la zona confiable no expone automáticamente la información personal identificable de la zona sin procesar si esta está protegida por claves y políticas de acceso independientes.