Trabajar con información sensible —salarios, datos personales, contratos, etc.— implica algo más allá de modelar datos y construir dashboards. Implica diseñar arquitecturas de seguridad coherentes entre plataforma y herramienta de visualización.
En este artículo voy a explicar un punto clave que suele generar confusión en muchos proyectos:
Cómo combinar Snowflake y Power BI para gestionar datos enmascarados según el rol del usuario, utilizando correctamente los dos modos de acceso de Power BI: Import y DirectQuery.
NOTA: en este artículo no se contempla el caso de SKU F64 o superior de Microsoft Fabric donde se puede hacer uso de Direct Lake.
1. El punto clave: cómo funciona realmente el modo Import
Power BI ofrece dos formas principales de conectarse a Snowflake:
- Import → copia los datos dentro del modelo de Power BI
- DirectQuery → consulta los datos directamente en Snowflake
Vamos al problema.
En modo Import:
- Power BI carga los datos y los almacena en su propio motor en memoria
- Las consultas contra Snowflake ocurren solo durante el refresh
- A partir de ahí, Snowflake ya no participa
Esto tiene una implicación crítica:
La seguridad y el enmascaramiento dinámico de Snowflake NO se aplican en tiempo de visualización. Esto ocurre porque el dataset ya no consulta Snowflake cuando el usuario navega por el informe, sino que trabaja sobre una copia en el Power Bi Service.
2. El problema real: la identidad del usuario
En entornos modernos, solemos usar:
- Snowflake como data platform
- Power BI como capa de consumo
- Entra ID (Azure AD) como identidad común
Esto abre una gran oportunidad… pero solo si usamos el modo adecuado.
En DirectQuery
- Power BI envía cada consulta en tiempo real
- Snowflake puede evaluar quién está consultando
- Se puede aplicar seguridad dinámica por usuario
En Import
- Power BI usa el usuario técnico del dataset
- Snowflake NO sabe quién está viendo el informe
- El masking dinámico no funciona
Es decir:
Aunque tengas Entra ID, en Import no hay passthrough de identidad.
3. Cuándo usar DirectQuery para datos sensibles
Si el requisito es claro:
“cada usuario debe ver datos enmascarados según su rol”
Entonces necesitas:
DirectQuery + Autenticación Entra ID (OAuth passthrough)
Esto permite:
- Consultas en tiempo real contra Snowflake
- Snowflake aplica sus Masking Policies automáticamente
- El resultado depende del rol/usuario
Recordemos:
Snowflake aplica el masking dinámico modificando la query en tiempo de ejecución según el contexto del usuario.
Configuración recomendada
- Conectar Power BI a Snowflake usando Entra ID
- Activar passthrough de usuario
- Definir en Snowflake:
- Masking policies
- Row access policies
- Usar DirectQuery en el dataset
Resultado:
cada usuario ve datos distintos sin duplicar datasets ni lógica.
4. ¿Y si necesitas Import? (porque casi siempre lo necesitas)
Import sigue siendo el modo preferido en muchos casos:
- mejor rendimiento
- modelo semántico más potente
- menor coste Snowflake (menos queries)
Pero entonces el control cambia.
En Import:
- Snowflake deja de controlar el acceso dinámico
- Power BI pasa a ser responsable de la seguridad
Opciones en Power BI
- Row-Level Security (RLS)
- Lógica en DAX (enmascarado condicional)
- Separación de datasets / vistas
Ejemplo conceptual:
Salary Masked =IF( USERPRINCIPALNAME() IN VALUES(AllowedUsers[Email]), [Salary], BLANK())
5. Import vs DirectQuery (resumen claro)
| Aspecto | Import | DirectQuery |
|---|---|---|
| Datos en Power BI | Sí | No |
| Snowflake participa en el runtime | No | Sí |
| Contexto de usuario (Entra ID) | No | Sí |
| Masking dinámico en Snowflake | No | Sí |
| Performance | Alto | Dependiente del origen |
| Coste Snowflake | Bajo | Alto (por queries) |
DirectQuery es clave cuando la seguridad depende del usuario
Import es mejor para performance y modelado
6. La solución real: arquitectura híbrida
Aquí es donde viene la parte interesante (y la que pocas veces se explica bien):
La arquitectura óptima NO es elegir uno u otro, sino combinarlos
Patrón recomendado
- Import → datos generales (rendimiento)
- DirectQuery → datos sensibles (seguridad dinámica)
Esto se puede implementar con:
- Composite models
- Datasets separados (Front vs Sensitive)
- Queries híbridas
Este enfoque está alineado con buenas prácticas:
combinar Import (performance) con DirectQuery (acceso a datos en tiempo real y control de acceso)
Conclusión
Diseñar seguridad en una arquitectura Snowflake + Power BI no es solo un tema técnico, es una decisión de arquitectura.
Las reglas clave son:
- Import rompe el contexto de usuario
- DirectQuery preserva la identidad y la seguridad dinámica
- Snowflake solo puede enmascarar dinámicamente si recibe la identidad real
En resumen:
Si necesitas enmascarado por rol en tiempo real → usa DirectQuery
Si necesitas rendimiento → usa Import
Si necesitas ambos → diseña una arquitectura híbrida
Reflexión final
Este tipo de decisiones son las que separan una arquitectura “que funciona” de una arquitectura realmente enterprise:
👉 la seguridad no se añade después, se diseña desde el inicio
Y aquí, literalmente:
una fina línea separa rendimiento de control… y la clave está en saber combinarlos.
Foto de portada gracias a RDNE Stock project: https://www.pexels.com/es-es/foto/hombre-trabajando-musica-musico-8197232/
Alb3rto Alonso 