Planteamiento y alcance
Un data lake contiene columnas públicas y confidenciales en archivos Parquet. El equipo desea cifrar los datos y metadatos confidenciales manteniendo la proyección, el predicate pushdown y la compresión. Diseñe el cifrado de footer, las claves de columna, la custodia de claves, la autorización de lectura, el comportamiento de lectores heredados y la recuperación ante rotación.
Esta pregunta analiza las capacidades de la especificación Parquet Modular Encryption; no asume que cada motor o binding de lenguaje admita la misma configuración de claves.
Qué evalúa el entrevistador
- Si distingue entre footers cifrados, columnas cifradas y protección exclusiva a nivel de página.
- Si las KEK, DEK, los metadatos de clave y los permisos de KMS se separan en lugar de almacenar una clave maestra en el archivo.
- Si comprende cómo un footer cifrado afecta al esquema, las estadísticas, el predicate pushdown y los lectores heredados.
- Si la rotación, la revocación, la reescritura y los fallos de descifrado observables se diseñan de forma conjunta.
Preguntas de aclaración
- ¿Qué columnas son confidenciales y deben ocultarse también el esquema, los row groups y las estadísticas?
- ¿Qué columnas necesitan los motores de consulta y admiten claves de columna y descifrado de footer?
- ¿La custodia de claves reside en un servicio central, un HSM en la nube o una clave inyectada por el invocador?
- ¿Se replican los archivos entre cuentas o regiones, y cómo obtienen las copias de seguridad el permiso de descifrado?
- ¿La rotación se orienta a archivos nuevos, reescrituras históricas o revocación inmediata?
Respuesta en 30 segundos
“Parquet Modular Encryption puede proteger los datos y metadatos del archivo manteniendo las características columnares, pero un footer cifrado oculta la información del esquema y de los row groups a los lectores que no tengan su clave. Yo separaría las claves maestras de KMS de las claves de archivo o columna y autorizaría a los lectores por columna. Un lector heredado debería reportar un cifrado no compatible en lugar de clasificar el archivo como corrupto. La rotación escribe archivos nuevos con claves recién envueltas y reescribe el historial de forma controlada, registrando a la vez las versiones de claves y los fallos. Una matriz de capacidades debe verificar el predicate pushdown para cada motor”.
Diseño paso a paso
1. Elegir el alcance de la protección
El cifrado de footer protege FileMetaData, incluidos los row groups y column chunks; el cifrado de columna puede usar diferentes claves para columnas confidenciales. Si el footer permanece en texto plano, un lector puede ver el esquema o las estadísticas incluso cuando no puede leer páginas cifradas. Elija el alcance a partir del modelo de amenazas.
2. Separar las responsabilidades de las claves
Un KMS o HSM almacena las claves de cifrado de claves (KEK). La escritura crea u obtiene claves de cifrado de datos (DEK) y almacena metadatos de clave protegidos en el archivo. Un servicio de autorización de lectores resuelve los metadatos y solicita al KMS que desenvuelva solo las claves permitidas; el archivo no debe contener una clave maestra utilizable directamente.
3. Evaluar las capacidades de consulta
Apache Parquet documenta que el cifrado modular puede cifrar y autenticar datos y metadatos manteniendo la proyección, el predicate pushdown, la codificación y la compresión. Un motor de consultas aún necesita primero las claves pertinentes. Un footer cifrado puede bloquear a un escáner sin clave para que no lea el esquema y las estadísticas, por lo que se deben probar la proyección solo pública, los filtros de columnas confidenciales y las proyecciones mixtas.
KMS KEK -> wraps file/column DEK -> protected key metadata
reader authorization -> unwrap allowed DEK -> decrypt footer/pages4. Identificar archivos y lectores heredados
Los archivos con footer cifrado usan bytes mágicos diferentes: Apache Parquet documenta PARE, mientras que los archivos en texto plano usan PAR1. Un lector heredado puede clasificar el archivo cifrado como no compatible. Registre la capacidad en un registro o sondeo, en lugar de esperar a un error vago de corrupción durante una consulta.
5. Diseñar la rotación y la revocación
La rotación debe afectar primero a los archivos nuevos: las nuevas DEK se envuelven con una nueva KEK y los archivos antiguos se reescriben según la retención. La revocación inmediata hace que KMS rechace el desenvolvimiento y las lecturas fallen; la plataforma necesita una cola de reescritura, versiones de claves y pasos de recuperación. Reescriba en un archivo temporal y reemplácelo atómicamente para que una interrupción no deje un archivo a medio cifrar.
6. Observar los fallos por capa
Registre el ID del archivo, la versión de la clave de footer o columna, el principal, la latencia de KMS, el tipo de fallo de descifrado y las columnas consultadas; nunca registre claves ni valores en texto plano. Separe la denegación de autorización, la clave faltante, el fallo en la etiqueta de autenticación, el lector heredado no compatible y la corrupción del archivo para alertas y remediación.
Respuesta modelo de alta calidad
“Decidiría si ocultar el footer basándome en el modelo de amenazas. El cifrado modular puede proteger el footer, las columnas y las páginas; el cifrado de footer oculta el esquema y las estadísticas, mientras que las claves de columna limitan el acceso a columnas confidenciales. KMS mantiene las KEK y se hace referencia a las DEK de archivo o columna a través de metadatos protegidos; los lectores las desenvuelven solo tras la autorización. Una matriz de capacidades prueba la proyección pública, los filtros confidenciales y el predicate pushdown. PARE frente al texto plano PAR1 permite a la plataforma identificar tempranamente el riesgo de lectores heredados. La rotación utiliza archivos nuevos, reescrituras controladas y reemplazo atómico, con versiones de clave y clases de fallo registradas; la revocación utiliza la denegación de KMS más una cola de recuperación”.
Errores comunes
- Escribir una KEK directamente en el archivo → la posesión del archivo permite el descifrado → almacenar solo metadatos de clave protegidos.
- Cifrar columnas sin evaluar el footer → el esquema y las estadísticas aún pueden filtrarse → elegir el modo de footer a partir del modelo de amenazas.
- Asumir que todos los motores admiten claves de columna → las consultas en producción revelan una brecha de capacidades → mantener una matriz de motores y bindings.
- Sobrescribir archivos in situ durante la rotación → una interrupción deja una salida parcial ilegible → escribir una salida temporal y reemplazar atómicamente.
- Llamar archivo corrupto a un fallo de autenticación → la investigación sigue el camino equivocado → separar errores de KMS, autorización, etiqueta y formato.
Preguntas de seguimiento y respuestas
¿El cifrado de footer deshabilita el predicate pushdown?
No necesariamente. Después de obtener el footer y las claves de columna requeridas, el formato puede retener las lecturas columnares y el predicate pushdown. Un escáner sin la clave de footer no puede leer estadísticas; el comportamiento real depende del soporte de cifrado del motor.
¿Por qué usar claves a nivel de columna?
Diferentes principales pueden tener permiso para leer diferentes columnas. Las claves de columna restringen la autorización de todo el archivo a columnas confidenciales y reducen la exposición al otorgar acceso a columnas públicas.
¿Qué debería hacer un lector heredado con PARE?
Debería reportar claramente un cifrado modular no compatible y dirigir al operador a un lector compatible o a una ruta de descifrado y reescritura. No debería tratar silenciosamente un archivo PARE como un archivo PAR1 corrupto.