La mayoría de los equipos de datos empieza —y termina— el control de acceso en los objetos: quién lista un schema, quién lee una tabla, quién abre un path. Es necesario. Y deja la pregunta importante sin responder.
Porque la misma tabla mezcla tenants, países y PII con métricas operativas. El control de acceso granular —FGAC (fine-grained access control)— responde a lo que pasa dentro del recurso permitido: qué filas salen y qué aspecto tienen las columnas sensibles.
Y aquí va la tesis de este artículo, por si no lees más: un control cuyo bypass no sabes nombrar todavía no es un control. El FGAC de motor sin control sobre el storage es una puerta con cerradura buena y ventana abierta. Todo lo demás son detalles de implementación.
Qué hace el FGAC (y qué no)
En la práctica, FGAC combina al menos tres mecanismos:
- Filtrado a nivel de fila (RLF) — la consulta solo devuelve filas que cumplen una condición (unidad de negocio, país, marca, propósito).
- Restricción o proyección de columnas — columnas fuera de política no aparecen o no son seleccionables.
- Enmascaramiento / ofuscación — la columna existe, pero el valor se redacta, tokeniza o cifra según el principal.
Lo que el FGAC no es: un sustituto de la gobernanza de identidades, ni de las políticas de conservación, ni del control sobre el storage en bruto. Si alguien puede leer el Parquet o el fichero fuera del motor gobernado, el filtrado SQL no lo detiene. Ahí entra el control a nivel de objeto (OLAC o equivalentes del cloud).
Dos formas de aplicar la misma política
El patrón útil para arquitectos: el modelo de política puede ser común (quién, sobre qué columnas/filas, con qué transformación), pero el punto de aplicación depende del servicio.
| Enfoque | Idea | Ejemplos típicos de motor |
|---|---|---|
| Plugin en el motor | La política se evalúa al ejecutar la consulta (interceptación en el engine) | Trino / Starburst, Hive, clusters con plugin tipo Apache Ranger |
| Política nativa del servicio | La política se traduce a reglas del propio servicio (UDF de masking, row filter de Unity Catalog, Lake Formation, etc.) | Snowflake, Redshift, Databricks Unity Catalog, AWS Lake Formation |
Para un estate híbrido, la decisión de diseño no es “¿cuál es mejor en abstracto?”, sino: dónde se evalúa la política, qué latencia añade, y qué pasa si alguien consulta por otro camino (BI directo, notebook con privilegios altos, dump a S3).
Flujo operativo habitual:
- Definición — filas/columnas, grupos o roles, masking.
- Aplicación — plugin o política nativa ya materializada.
- Auditoría — intentos concedidos y denegados, no solo el documento de política.
Un ejemplo concreto
Tabla ventas con 40 millones de filas: pais, cliente_email, importe, unidad_negocio.
Una analista de marketing en España consulta SELECT * FROM ventas. Con la política aplicada, recibe:
- filas: solo
pais = 'ES'(filtro de fila por unidad de negocio / territorio) - cliente_email:
a****@dominio.com(enmascarado; puede agrupar y contar, no puede exportar identificadores) - importe, unidad_negocio: en claro
La consulta no falla ni pide permisos: devuelve menos. Ese es el punto — el control es invisible para quien trabaja bien y silencioso para quien no debería ver.
Casos que sí justifican FGAC
- Multi-tenant o multi-BU en la misma tabla — el filtrado por fila evita copiar tablas por cada unidad “por si acaso”.
- Analistas sobre PII — pueden agregar o unir sin ver SSN/NIF/email en claro si el masking está en el plano de datos.
- Lakehouse con Unity Catalog u homólogo — políticas de fila alineadas a roles (p. ej. marketing vs finanzas) sin duplicar datasets.
En todos los casos, el valor está en una política coherente que se aplica aunque cada motor la ejecute distinto — y en poder nombrar el bypass.
Límites (léelos antes del PoC)
Trata estas restricciones como requisitos de diseño, no como letra pequeña:
- Rendimiento — masking y row filters cuestan CPU/IO en tablas grandes; midelos en el peor query, no en el demo.
- Bypass por object store — sin control a nivel de objeto (o IAM/path policies equivalentes) sobre el storage, el FGAC del motor es incompleto.
- Heterogeneidad — no todos los servicios tienen el mismo nivel de hooks; a veces el “FGAC” real son vistas seguras o UDFs.
- Dependencia del nativo — la calidad del control no supera lo que el motor sabe aplicar.
Regla práctica — la misma tesis del inicio: diseña política + evidencia + camino de bypass. Si no puedes nombrar el bypass, aún no has cerrado el control.
Cómo plantearlo en España / LatAm sin teatro
Para operadores sujetos a RGPD / LOPDGDD, el FGAC es un control de minimización técnica y segregación: reduce quién ve identificadores en claro. No sustituye:
- base jurídica y registro de tratamientos,
- plazos de conservación,
- evaluaciones de impacto cuando toquen,
- contratos con encargados y transferencias.
Úsalo donde el riesgo es consulta masiva por personas o agentes sobre tablas ya compartidas en el lakehouse —no como eslogan de “plataforma de cumplimiento”.
Cómo saber si tu FGAC está cerrado
Tres preguntas. Si fallas una, tienes política, no control:
- ¿Puedes nombrar el bypass? Si un notebook con credenciales del bucket lee el Parquet, ¿lo detiene algo?
- ¿Tienes evidencia de las denegaciones? Los intentos concedidos son un log. Los denegados son la prueba.
- ¿Lo has medido en la consulta peor, no en la demo? El masking cuesta CPU donde más filas hay.
Si respondes «no» a alguna, ahí está tu próximo sprint —no en comprar otra plataforma.
Fuentes
Documentación técnica pública (inglés). Este artículo es lectura de operador multi-motor, no una traducción literal de un único producto. Las plataformas aplican; nosotros diseñamos política y evidencia. Cuando citamos un proveedor concreto, es porque documenta el patrón —no por cuota de reventa.
Motores / nativos (primarios):
- Unity Catalog — row filters and column masks — Databricks
- Snowflake — Dynamic Data Masking y Row Access Policies
- AWS Lake Formation — data filters
- Apache Ranger — authorization overview (origen del patrón plugin)
Gestión centralizada de políticas (secundario):
- About Fine-Grained Access Control (FGAC) — docs.privacera.com
- Índice de Access Management
Siguiente paso
Si estás acotando políticas de fila/columna sobre Databricks, Snowflake u otro motor del estate, el enfoque de implementación está en gobernanza de datos. Para un diagnóstico concreto: cuéntanos qué bloquea el progreso.
Preguntas frecuentes
¿En qué se diferencia el FGAC del acceso a nivel de tabla o fichero?
El acceso a nivel de objeto (tabla, path, bucket) decide si puedes tocar el recurso. El FGAC decide, dentro de ese recurso, qué filas devuelve la consulta y si columnas sensibles van en claro, enmascaradas o cifradas.
¿Plugin en el motor o política nativa del servicio?
Depende de lo que ofrezca cada plataforma. Unos motores admiten un plugin (p. ej. patrón Apache Ranger) que intercepta la consulta; otros aplican mejor si la política se traduce a estructuras nativas (row filter, UDF de masking, Lake Formation, etc.). El modelo de política puede ser el mismo; el punto de aplicación no.
¿Con FGAC ya cumplo el RGPD?
No. El FGAC es un control técnico de minimización y segregación. Ayuda a demostrar que no todo el mundo ve PII en claro, pero no sustituye base legal, conservación, EIPD ni el resto del programa de privacidad.
¿Por dónde empiezo en un lakehouse real?
Inventario de datos sensibles por columna, mapa de principales (humanos y no humanos), decisión fila vs columna vs masking, y una prueba en el motor donde más duele el riesgo —no un despliegue multiplataforma el día uno. Nombra el bypass antes de celebrar el PoC.