Planteamiento y alcance
Los datos del negocio residen en almacenamiento de objetos, tablas de lakehouse y un warehouse; los analistas utilizan SQL, Spark y herramientas de BI. El acceso se mantiene mediante tickets manuales y cuentas locales en cada motor. El proceso de desvinculación (offboarding) es lento y una auditoría no puede reconstruir las consultas entre distintas cuentas. Los objetivos son solicitudes de autoservicio, privilegio mínimo, protección a nivel de fila y columna, acceso de emergencia y una pista de auditoría unificada.
Diseña la capa de gobernanza: clasificación, aprobadores, puntos de decisión y aplicación de políticas (policy decision and enforcement points), cobertura multimotor, acceso de emergencia (break-glass), revocación, cachés, exportaciones y pruebas de que tanto la autorización como las lecturas reales son auditables. La habilidad principal es la gobernanza y operación de plataformas de datos, por lo que se trata de una pregunta de datos.
Qué evalúa el entrevistador
El entrevistador busca un ciclo compuesto por catálogo, políticas, aplicación, evidencia y operaciones, en lugar de un simple "agregar RBAC". Las respuestas sólidas distinguen entre identidad, propósito, etiquetas de recursos, filtros de fila/columna y enmascaramiento, además de explicar el límite entre la decisión y la aplicación.
También evalúan la consistencia entre servicios. Un mismo usuario que accede a Athena, Spark, herramientas de BI o un trabajo de exportación no debería perder el contexto de autorización ni los campos de auditoría. Los registros deben ser a prueba de manipulaciones, permitir búsquedas, retenerse de manera deliberada e incluir denegaciones, cambios administrativos y accesos de emergencia, no solo las consultas exitosas.
Preguntas para aclarar primero
- ¿Qué fuentes de datos, motores, proveedores de identidad y límites entre cuentas existen?
- ¿Cuáles columnas contienen datos personales, financieros o restringidos por contrato, y quién mantiene la clasificación?
- ¿El acceso se decide mediante roles, atributos, propósito, inquilino (tenant), filtros de fila/columna o una combinación de estos?
- ¿Las aprobaciones son de un solo uso, renovables o requeridas por consulta?
- ¿Cuáles son la duración máxima, el aprobador y el proceso de revisión para el acceso de emergencia?
- ¿Puede el sistema registrar el alcance escaneado, las filas devueltas, el destino de exportación y la identidad del servicio?
Una respuesta de 30 segundos
"Crearía un catálogo con propietarios asignados y etiquetas de sensibilidad; luego enviaría la identidad, el equipo, el propósito, la región y las etiquetas de recursos a un punto de decisión de políticas. La aplicación en cada motor o proxy de datos aplicaría filtros de fila/columna y enmascaramiento, con concesiones limitadas en el tiempo. Los eventos de permiso, denegación, versión de política, recurso consultado, identidad del servicio y exportación se enviarían a un flujo centralizado a prueba de manipulaciones. El acceso break-glass expiraría y activaría una revisión. Realizaría pruebas de revocación, contexto entre cuentas, cachés y desviación de políticas para demostrar que las lecturas reales coinciden con la pista de auditoría".
Solución paso a paso
Construye un inventario de activos para tablas, columnas, rutas, temas (topics), inquilinos y datos derivados. Cada activo necesita un propietario, clasificación, origen, retención y propósitos aprobados. La clasificación no puede ser un escaneo único: los cambios de esquema, las nuevas columnas y los cambios en las reglas del negocio deben activar una revisión. Los campos sensibles inciertos deben recibir etiquetas conservadoras hasta que sean revisados.
Separa la decisión de la aplicación. La entrada de la decisión incluye la identidad del sujeto, grupos, atributos, propósito, condiciones del dispositivo o red, etiquetas del recurso y entorno. La salida incluye permitir o denegar, filtros, enmascaramiento, versión de la política y expiración. La aplicación puede residir en un proxy, un plugin del motor o un filtro de tabla, pero eludir el motor de consultas nunca debe exponer los archivos sin procesar en el almacenamiento de objetos.
Las solicitudes de autoservicio muestran el propósito, los campos, la duración y el propietario. Los usos preaprobados de bajo riesgo pueden recibir roles de corta duración automáticamente; el acceso sensible requiere la aprobación del propietario de los datos o de cumplimiento. Los permisos expiran rápidamente y se renuevan deliberadamente. La desvinculación de personal, los cambios de equipo y la finalización de proyectos activan la revocación. Vincula la evidencia de aprobación con la versión de la política que efectivamente entró en producción.
Explica la semántica de filas y columnas. Un analista puede ver un correo electrónico enmascarado y un resultado agregado, pero no debe poder reconstruir el original mediante combinaciones (joins), exportaciones o mensajes de error. Los predicados de inquilino provienen de una identidad confiable, no de un ID de inquilino proporcionado por el usuario. Aplica controles equivalentes a exportaciones, tablas temporales, cachés y vistas materializadas para que una fuente protegida no cree una copia desprotegida.
Un evento de auditoría debe contener el sujeto, la cadena de identidades, el propósito, el recurso, la decisión de fila/columna, la versión de la política, el motor, el ID de la consulta o trabajo, la hora, la cuenta de origen, el tamaño escaneado o devuelto, el destino de exportación y si fue permitido o denegado. Escribe en rutas de adición de bajo privilegio y con lectores controlados en almacenamiento inmutable; utiliza sumas de verificación (checksums) o una cadena de versiones para detectar eliminaciones y manipulaciones. Las denegaciones y las ediciones de políticas importan tanto como las consultas exitosas.
A través de los motores y cuentas, preserva la identidad original del usuario y del servicio. Un servicio que actúa en nombre de un usuario mantiene su cadena de delegación; los eventos entre cuentas se copian al propietario del recurso. Un motor heredado que no pueda transportar el contexto se aísla, se restringe a vistas prefiltradas o se marca como una brecha de auditoría en lugar de declararlo en cumplimiento.
Diseña el acceso break-glass para un grupo reducido y fuertemente autenticado. Exige una justificación, una expiración automática corta, alertas inmediatas y revisión; el acceso de emergencia nunca elude la auditoría. Publica versiones de políticas con despliegues canary y capacidad de reversión (rollback). Monitorea denegaciones, intentos de escalada de privilegios, latencia de revocación, activos sin propietario, brechas de auditoría y exportaciones de alto riesgo. Utiliza identidades sintéticas y columnas trampa (honey columns) para probar si los datos se pueden leer y si dicha lectura queda registrada.
Respuesta modelo
"Crearía un catálogo con propietarios asignados y etiquetas de sensibilidad que cubra datos de origen, derivados, rutas de objetos y exportaciones. Un punto de decisión de políticas recibiría la identidad, el equipo, el propósito, la región y las etiquetas del recurso, y devolvería permitir, denegar, filtros de fila/columna, enmascaramiento, versión de la política y expiración. La aplicación se ubicaría en un proxy o plugin del motor, mientras que las rutas directas a los objetos permanecerían inaccesibles.
Las solicitudes indicarían propósito, alcance, duración y propietario; el acceso sensible requeriría aprobación y los permisos expirarían tras la desvinculación o la finalización del proyecto. La misma política de filas y columnas se aplicaría a tablas temporales, cachés y exportaciones para que los usuarios no puedan reconstruir valores a través de una copia.
Los eventos de auditoría preservarían las cadenas de identidad de usuario y servicio, el recurso, la versión de la política, el motor, el ID de la consulta, el resultado del filtrado, el tamaño, el destino de exportación y el resultado de permitir/denegar en almacenamiento inmutable. El acceso break-glass expiraría, generaría alertas y requeriría revisión. Probaría el contexto entre cuentas, la revocación, los motores heredados, las cachés, las exportaciones y las columnas trampa para demostrar que las lecturas reales coinciden con la evidencia".
Errores comunes
- Diseñar solo RBAC → faltan los límites por propósito, región y columna → combina identidad, atributos, etiquetas y filtros.
- Proteger únicamente el motor de consultas → los usuarios lo eluden a través del almacenamiento de objetos → asegura la ruta sin procesar y aplica un único límite de acceso.
- Registrar únicamente una cuenta ETL compartida → la trazabilidad por usuario desaparece → preserva la cadena de delegación.
- Registrar solo las consultas exitosas → las denegaciones y las desviaciones desaparecen → registra denegaciones, ediciones de políticas y uso de emergencia.
- Concesiones permanentes → el acceso a proyectos sobrevive para siempre → expiración corta, renovación y revocación.
- Proteger únicamente las tablas de origen → las cachés, exportaciones y materializaciones se filtran → aplica la política en cada ruta derivada.
- El acceso break-glass elude la auditoría → la vía de emergencia se convierte en una puerta trasera → autenticación fuerte, justificación, expiración, alertas y revisión.
- Probar solo la salida de las políticas → los filtros pueden ser eludidos → prueba lecturas reales, exportaciones, identidades sintéticas y columnas trampa.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿RBAC o ABAC?
Utiliza roles para límites de equipo estables y atributos para dinámicas de propósito, región, etiquetas y tiempo. La mayoría de los sistemas reales combinan ambos para limitar la complejidad de las políticas.
Pregunta de seguimiento 2: ¿Cómo evitas la reconstrucción mediante agregaciones?
Limita los grupos reducidos (small cohorts), las combinaciones (joins), las consultas de diferenciación y la frecuencia de exportación; utiliza umbrales o ruido cuando sea apropiado. Valida las reglas frente a los requisitos de sensibilidad y precisión.
Pregunta de seguimiento 3: ¿Cómo auditas las lecturas en caché?
Vincula las claves de caché con el sujeto y la versión de la política, registra las cadenas de identidad de llenado y lectura, e invalida tras revocaciones o cambios de política. Las cachés compartidas sin contexto de usuario no deben almacenar resultados sensibles.
Pregunta de seguimiento 4: ¿Qué ocurre si el registro de auditoría contiene SQL sensible?
Almacena identificadores de recursos estructurados y resúmenes seguros en lugar del SQL completo, parámetros o datos sin procesar. Cifra, restringe y retén los campos de auditoría deliberadamente.
Pregunta de seguimiento 5: ¿Qué pasa si un motor heredado no puede aplicar políticas de fila o columna?
Aísla el motor, expón únicamente vistas prefiltradas o colócalo detrás de un proxy, y documenta la brecha de auditoría restante. Las convenciones de equipo no sustituyen la aplicación técnica.
Pregunta de seguimiento 6: ¿Cómo demuestras que la gobernanza no ralentiza el análisis?
Monitorea la latencia de decisión, el percentil 95 (p95) de las consultas, las denegaciones falsas, la tasa de aciertos en caché y el tiempo de aprobación. Invalida las decisiones en caché de inmediato ante cambios de identidad o de versión de política.
Pregunta de seguimiento 7: ¿Por qué registrar las versiones de las políticas?
La misma consulta puede devolver resultados diferentes antes y después de una actualización de política. Una versión explica por qué el acceso fue permitido, denegado o filtrado, y respalda las reversiones y la revisión de incidentes.