Entrevista de Ingeniería de Datos: ¿Cómo protegerías columnas sensibles en Parquet?

Problema y alcance

Un data lake almacena direcciones de correo electrónico, identificadores de pago, regiones y agregaciones públicas en los mismos archivos Parquet. El almacenamiento de objetos, los servicios de metadatos y los clústeres de cómputo pertenecen a diferentes equipos. Los trabajos autorizados deben leer únicamente las columnas requeridas; los lectores no autorizados no deben ver valores sensibles ni metadatos que revelen identidades. Diseña el cifrado a nivel de columna y la gestión de claves, y luego analiza el footer, los índices, el predicate pushdown, la rotación, los lectores heredados y la recuperación.

El Cifrado Modular de Apache Parquet protege módulos serializados por separado, tales como páginas, encabezados de página, índices de columna, índices de desplazamiento (offset indexes), filtros de Bloom y el footer, manteniendo al mismo tiempo las opciones habituales de proyección de columnas, predicate pushdown, codificación y compresión. Una respuesta sólida separa los datos cifrados, los metadatos protegidos, la autorización de claves y la validación de que las lecturas y escrituras sean correctas.

Qué evalúa el entrevistador

• ¿Puedes explicar la relación entre las claves de columna, la clave del footer, las claves de cifrado de datos (DEK) y las claves maestras?
• ¿Sabes que cifrar únicamente las columnas sensibles aún puede exponer el esquema, las estadísticas o indicios de identidad?
• ¿Puedes comparar footers cifrados frente a footers en texto plano en términos de seguridad, compatibilidad y costo de migración?
• ¿Entiendes la integridad de AES-GCM y la vinculación mediante AAD, así como las limitaciones de las páginas CTR?
• ¿Puedes conectar KMS, autorización, rotación, copias de seguridad, fallos de consulta y auditoría en un diseño ejecutable?

Una respuesta débil dice simplemente "usa AES-256 para el archivo". Una respuesta sólida demuestra qué módulos de Parquet se protegen, qué trabajo puede obtener qué clave y a qué renuncian los lectores heredados y el predicate pushdown.

Preguntas de clarificación que debes hacer primero

1. ¿Se deben ocultar el esquema, el conteo de filas y las estadísticas, o solo los valores de las columnas? Esto determina si el footer debe cifrarse.
2. ¿Qué trabajos, inquilinos y columnas pueden leerse juntos? Esto define los dominios de claves de columna y los límites de las políticas de KMS.
3. ¿El motor de consultas y su biblioteca PyArrow/Parquet admiten el Cifrado Modular? Si no es así, la ruta de lectura/escritura no puede cambiar directamente.
4. ¿Los lectores heredados deben continuar leyendo columnas no cifradas? Esto determina si una transición con footer en texto plano es aceptable.
5. ¿Los archivos son particiones inmutables o se sobrescriben, copian y reproducen? Esto determina la identidad de AAD, la rotación y la detección de reproducciones (replay).

Una respuesta en 30 segundos

"Primero decidiría si el footer y las estadísticas son sensibles y luego definiría los dominios de acceso por columna. Cada archivo o columna recibe una DEK aleatoria envuelta por una MEK o KEK administrada por KMS; las páginas de columnas, encabezados, índices y metadatos de columnas requeridos usan claves de columna, mientras que el footer se protege por separado. Preferiría AES-GCM porque proporciona confidencialidad e integridad, y vincularía la tabla, partición, versión de archivo e identidad del módulo mediante AAD para evitar reemplazos. Si los lectores heredados deben leer columnas públicas, un footer en texto plano puede ser una transición acotada en el tiempo, aunque expone ciertos metadatos; los conjuntos de datos sensibles con estricta confidencialidad de esquema deben usar un footer cifrado. Verificaría la autorización en KMS, la rotación, el predicate pushdown, la recuperación ante errores, el comportamiento heredado y los casos de manipulación indebida antes del despliegue."

Razonamiento paso a paso

1. Enumerar los módulos de Parquet que necesitan protección

Parquet no es una caja negra con solo un área de datos. Las páginas y los encabezados de página contienen valores; los índices de columna, índices de desplazamiento y filtros de Bloom pueden revelar rangos o distribuciones; el footer contiene el esquema, conteo de filas, información de ordenamiento, estadísticas y metadatos clave-valor. Cifrar solo las páginas de columnas aún puede exponer categorías de clientes o ventanas temporales.

file
├── row-group
│   └── column chunk
│       ├── dictionary/data pages
│       ├── page headers
│       ├── column index
│       ├── offset index
│       └── bloom-filter modules
└── footer / FileMetaData

Utiliza el modelo de amenazas para elegir el conjunto de protección. Las columnas de baja sensibilidad pueden permanecer legibles para herramientas heredadas; las columnas sensibles y sus estadísticas, esquema e identidad de archivo necesitan una protección más sólida del footer y de los metadatos de columna. Esta decisión es más relevante que seleccionar la longitud de la clave AES de forma aislada.

2. Diseñar el cifrado de sobre y los límites de acceso

Asigna a cada archivo o columna una clave de cifrado de datos (DEK) aleatoria, envuelta por una clave de cifrado maestra (MEK) o clave de cifrado de claves (KEK). Mantén la MEK en el KMS de la organización. Un trabajo recibe permiso de desencapsulamiento (unwrap) mediante una identidad de corta duración; el almacenamiento de objetos contiene texto cifrado y los metadatos de clave necesarios, no una clave maestra en texto plano.

authorized job -> KMS policy -> unwrap DEK -> decrypt footer/columns
object storage  -> ciphertext + key metadata only

Separa las claves de columna por inquilino, dominio de datos o sensibilidad para que un solo trabajo no reciba permisos sobre una tabla completa. Los metadatos de clave pueden ser un ID de clave de KMS, un identificador de material envuelto o una referencia externa; no son el secreto en sí, pero afectan la auditoría y la rotación. Durante la rotación de la clave maestra, reenvuelve primero las DEK. No reescribas todas las páginas de datos inmutables simplemente porque cambió una MEK.

3. Elegir entre footers cifrados y en texto plano

Un footer cifrado oculta el esquema, conteo de filas, nombres de columnas, información de ordenamiento y metadatos adicionales de las columnas. Ofrece un límite más estricto, pero todos los lectores de archivos sensibles deben admitir cifrado modular. Parquet utiliza los bytes mágicos PARE para archivos con footer cifrado, de modo que un lector heredado que espere PAR1 puede rechazar el formato de inmediato.

Un footer en texto plano permite que los lectores más antiguos vean algunos metadatos y lean columnas no cifradas. No pueden leer datos de columnas cifradas, mientras que el footer está firmado para garantizar la integridad. Este puede ser un modo de migración acotado en el tiempo, no un sustituto de seguridad cuando las estadísticas son sensibles.

Prueba una matriz de lectores: ¿puede el motor descubrir columnas cifradas?, ¿falla el acceso no autorizado?, ¿puede una consulta que solo accede a datos públicos seguir aplicando pushdown de predicados?, y ¿un lector heredado reporta un error explícito de cifrado no compatible en lugar de tratar el archivo como corrupto?

4. Seleccionar un algoritmo y vincular AAD

AES-GCM proporciona cifrado y una etiqueta de autenticación. AAD vincula la tabla, la partición, la versión del archivo y la posición del módulo al texto cifrado, evitando que un atacante reemplace el archivo actual, otra partición u otro row group bajo la misma clave. Los nonces aleatorios deben permanecer únicos para una clave determinada, y los presupuestos de invocación de claves deben gestionarse entre los escritores.

Parquet también define AESGCMCTRV1: los módulos que no son páginas usan GCM, mientras que las páginas de datos usan CTR para mejorar el rendimiento. Las páginas CTR no cuentan con la integridad autenticada de GCM. Si el modelo de amenazas requiere detección de manipulación en las páginas, prefiere AESGCM_V1 en lugar de decidir únicamente por la velocidad de CPU.

5. Preservar la capacidad de consulta y definir rutas de fallo

El cifrado se aplica a las páginas comprimidas y a otros módulos, por lo que el formato aún puede admitir proyección, predicate pushdown, codificación y compresión. Un optimizador/planificador puede leer un footer o índice visible y solicitar solo las columnas autorizadas. Sin embargo, si el footer o el índice de columnas está cifrado, el planificador necesita el permiso de descifrado correspondiente; "solo consulto columnas públicas" no significa automáticamente que "no se necesita ninguna clave".

Registra por separado los fallos de descifrado, los tiempos de espera de KMS, los permisos revocados, las discrepancias de AAD y los fallos de etiquetas de autenticación. Nunca recurras silenciosamente a texto plano y no clasifiques cada fallo como un archivo corrupto. Conserva el ID de archivo, los metadatos de clave, la versión del algoritmo y el principal de auditoría, pero nunca registres DEKs, valores en texto plano ni material de clave completo.

6. Verificar rotación, manipulación indebida y recuperación ante desastres

Prueba lecturas no autorizadas de columnas sensibles, lecturas autorizadas de columnas públicas, lecturas autorizadas de columnas sensibles, reemplazo de archivos antiguos, intercambio de row groups, edición de páginas de texto cifrado, denegación en KMS, lecturas posteriores a la rotación y recuperación entre regiones. Para cada prueba, registra el error esperado, si se devolvió texto plano y el evento de auditoría correspondiente.

La recuperación necesita los archivos cifrados, los metadatos de clave, los mapeos de versiones de clave de KMS y la identidad de archivo en AAD. Restaurar el almacenamiento sin permisos de KMS genera archivos ilegibles; restaurar KMS sin el prefijo de AAD puede impedir la verificación de la identidad del archivo. Conserva las versiones de clave antiguas durante la ventana de validación de snapshots, reproducciones y copias de seguridad antes de su destrucción.

Respuesta de ejemplo de alta calidad

"Comenzaría definiendo el modelo de amenazas: ¿se deben ocultar el esquema, el conteo de filas y las estadísticas, y qué trabajos pueden leer qué columnas? El Cifrado Modular de Parquet puede proteger no solo las páginas de columnas, sino también los encabezados de página, índices de columna, índices de desplazamiento, filtros de Bloom y el footer. Generaría DEKs aleatorias para archivos o columnas y las envolvería con una MEK/KEK en un KMS. Los trabajos obtienen permisos de desencapsulamiento mediante identidades de corta duración, y los archivos contienen solo metadatos de clave auditables.

Para un límite completo, utilizaría un footer cifrado. Si los lectores heredados deben acceder a columnas públicas, utilizaría una migración temporal con footer en texto plano y documentaría los metadatos que este expone. Preferiría AES-GCM con AAD vinculando tabla, partición, versión de archivo e identidad del módulo, y no sacrificaría la integridad de las páginas simplemente porque las páginas CTR sean más rápidas. Antes del despliegue, probaría la proyección y el predicate pushdown, la denegación en KMS, la manipulación de AAD, la rotación de claves, la recuperación entre regiones y el comportamiento heredado. Los registros excluirían DEKs, texto plano y material de claves. El diseño hace que el cifrado, la autorización, el comportamiento de consulta y la recuperación sean comprobables de forma independiente."

Errores comunes

• Usar únicamente cifrado a nivel de almacenamiento → cualquiera con acceso a los objetos puede leer todas las columnas → diseña límites en columnas, footer y módulos.
• Cifrar páginas sensibles pero no el footer → el esquema, las estadísticas y el conteo de filas pueden filtrarse → elige un footer cifrado o declara explícitamente la exposición del footer en texto plano.
• Tratar una DEK como una clave maestra de larga duración → la filtración de un solo archivo amplía el impacto de rotación y revocación → envuelve DEKs aleatorias con una MEK o KEK de KMS.
• Ignorar el AAD → se pueden sustituir archivos antiguos u otras particiones bajo la misma clave → vincula la identidad del archivo y del módulo y prueba sustituciones.
• Llamar a AESGCMCTR_V1 totalmente autenticado → las páginas CTR pueden carecer de autenticación de página de GCM → elige según los requisitos de integridad y prueba la manipulación.
• Eliminar claves antiguas inmediatamente después de la rotación → los snapshots, las copias de seguridad y los trabajos de reproducción no podrán recuperarse → conserva los mapeos de versiones y una ventana controlada para las claves antiguas.

Preguntas de seguimiento y respuestas

Los lectores heredados deben seguir leyendo columnas públicas. ¿Cómo realizas la migración?

Usa temporalmente un footer en texto plano mientras cifras las páginas de datos de columnas sensibles, y permite que los lectores heredados accedan solo a las columnas públicas. Mide el esquema y las estadísticas expuestas, define una fecha límite de actualización y luego pasa a un footer cifrado una vez superadas las pruebas de cobertura con nuevos lectores y de reproducción. Mantén una versión de archivo para reversión (rollback).

¿Cómo evitas que una página de otra partición se copie en este archivo?

Construye una identidad AAD estable a partir del archivo, la tabla, la partición, el row group y el módulo. Cualquier discrepancia debe fallar la autenticación. Prueba sustituciones de versiones antiguas, entre particiones y entre columnas bajo la misma clave, y verifica que todas sean rechazadas.

¿Cada lectura de página requiere una llamada de ida y vuelta a KMS?

No. Desencapsula una DEK o KEK a través de KMS y luego almacena en caché el material de corta duración dentro de un proceso controlado. Limita el alcance de la caché y su TTL, invalídala ante rotaciones o revocaciones, y monitorea los fallos de KMS y los aciertos de caché. No coloques una llamada a KMS en la ruta crítica de lectura de páginas.

¿Por qué no usar solo AES-CTR para obtener mayor rendimiento?

CTR no autentica la integridad, por lo que una página modificada puede pasar desapercibida. Usa AES-GCM cuando el modelo de amenazas requiera detección de manipulación. Considera CTR solo cuando el compromiso de integridad sea explícito y se haya verificado un mecanismo de integridad externo.

¿Cómo demuestras que el predicate pushdown no elude la autorización?

Ejecuta consultas de solo datos públicos, con filtros sensibles y con proyecciones sensibles bajo identidades autorizadas y no autorizadas. Inspecciona los módulos solicitados y los permisos de KMS. Los registros de auditoría deben relacionar la consulta, el archivo, la columna, los metadatos de clave y el motivo de denegación; un simple conteo final de filas no es suficiente.