Cuando hablamos de un almacenamiento de datos, muchas veces pensamos en tablas, cargas, consultas y modelos. Pero hay una parte igual de importante que a veces se deja para el final: la seguridad.
Y ese suele ser un error.
Porque un warehouse no solo tiene que responder rápido, estar bien modelado o alimentar informes. También tiene que garantizar que cada usuario vea solo lo que debe ver, que los datos sensibles estén protegidos y que el acceso esté controlado con el nivel de detalle adecuado.
Y ahí es donde entra la seguridad en Microsoft Fabric. No como un complemento, sino como una capa esencial del diseño del almacenamiento.
La seguridad en un warehouse no es un extra
En un entorno analítico, no todo el mundo debería poder acceder a todo.
Puede haber datos financieros, sanitarios, personales, estratégicos o simplemente información que solo tiene sentido para ciertos perfiles. Por eso, proteger un almacenamiento de datos no consiste solo en “poner permisos”, sino en aplicar distintos mecanismos según el tipo de protección que necesitas.
En Fabric, esto se apoya en una combinación bastante potente:
- roles de área de trabajo
- permisos a nivel de elemento
- permisos SQL granulares
- enmascaramiento dinámico de datos
- seguridad a nivel de fila
- seguridad a nivel de columna
Es decir, no hay una única palanca. Hay varias capas que se complementan entre sí.
Roles, permisos y protección de datos
La primera línea de control suele estar en los roles del área de trabajo. Estos roles definen niveles generales de acceso y permiten separar quién administra, quién colabora, quién solo visualiza y quién puede modificar.
Después están los permisos de elemento, que permiten compartir un almacén concreto sin abrir necesariamente el resto del workspace.
Y por debajo aparece la capa más fina: la protección de datos mediante SQL. Aquí ya no hablamos solo de acceso al activo, sino de acceso al contenido. A objetos concretos, a columnas específicas o incluso a determinadas filas según el contexto del usuario.
Y es aquí donde la seguridad empieza a ponerse realmente interesante.
Enmascaramiento dinámico de datos
El enmascaramiento dinámico de datos, o DDM, es una de esas funcionalidades que resulta muy útil cuando quieres ocultar información sensible sin cambiar físicamente los datos.
La idea es sencilla: los datos siguen estando en la tabla tal cual, pero cuando un usuario sin privilegios los consulta, lo que ve es una versión enmascarada.
Esto permite, por ejemplo, ocultar parcialmente emails, teléfonos, nombres o números de tarjeta sin necesidad de alterar la estructura de la aplicación ni de duplicar datos en otra tabla “protegida”.
Y aquí está una de sus grandes ventajas: se aplica en tiempo real sobre el resultado de la consulta.
Qué hace y qué no hace el DDM
El DDM resulta muy cómodo porque es relativamente fácil de implementar y no requiere modificar los datos almacenados.
Pero también conviene tener claro lo que es y lo que no es.
No cifra los datos.
No los ofusca físicamente.
No sustituye al control de permisos.
Lo que hace es limitar la exposición visual a usuarios que no deberían ver el valor real. Por eso funciona bien como parte de una estrategia de seguridad más amplia, pero no debería usarse como única defensa frente al acceso indebido.
Dicho de otra manera: ayuda mucho, pero no resuelve por sí solo todo el problema.
Reglas de enmascaramiento
El enmascaramiento dinámico se define a nivel de columna y permite varios tipos de reglas.
Puedes enmascarar completamente un valor, mostrar solo una parte al principio y al final, o incluso aplicar funciones aleatorias sobre datos numéricos.
Esto hace que puedas adaptar el nivel de visibilidad según el tipo de dato. No es lo mismo ocultar un email que una tarjeta o un teléfono. Y no siempre quieres ocultarlo todo: a veces basta con mostrar solo una pequeña parte para que el dato siga siendo útil sin exponer demasiado.
Ese equilibrio es precisamente una de las razones por las que esta funcionalidad suele encajar tan bien.
Seguridad a nivel de fila
Si el DDM controla cómo se ve el dato, la seguridad a nivel de fila o RLS controla directamente qué filas puede ver cada usuario.
Y aquí ya damos un paso mucho más fuerte.
La lógica es bastante clara: se define un predicado de seguridad que devuelve verdadero o falso según unas condiciones. Si la condición se cumple, el usuario ve esa fila. Si no, esa fila no aparece en el resultado de la consulta.
Esto permite construir escenarios muy potentes. Por ejemplo, que cada vendedor solo vea sus propios pedidos, que cada departamento solo vea sus datos o que cada tenant vea exclusivamente su porción de información.
Cómo funciona realmente el RLS
El RLS se apoya en dos piezas principales.
La primera es una función con valores de tabla que define la lógica del filtro. Es, por así decirlo, la regla que determina si una fila debe mostrarse o no.
La segunda es la directiva de seguridad, que aplica esa lógica a la tabla correspondiente.
Una vez configurado, el usuario consulta la tabla como siempre. No necesita saber que hay un filtro de seguridad detrás. SQL lo aplica automáticamente.
Y esto es precisamente parte de su valor: la seguridad queda integrada en el almacenamiento y no depende de que la aplicación “se porte bien”.
Cuándo tiene sentido el RLS
La seguridad a nivel de fila encaja especialmente bien cuando necesitas segmentar el acceso dentro de una misma tabla sin tener que duplicarla ni crear vistas específicas para cada perfil.
Es útil en escenarios de:
- aislamiento entre departamentos
- entornos multicliente
- cumplimiento normativo
- segmentación territorial o funcional
Y todo ello manteniendo una experiencia bastante natural para quien consulta, porque el filtro ocurre en segundo plano.
Algunas precauciones con el RLS
Como suele pasar con las funcionalidades potentes, también hay que usarlas con cuidado.
Se recomienda definir las funciones y directivas en un esquema separado, evitar conversiones innecesarias dentro del predicado y no complicar en exceso la lógica con combinaciones o recursividad, porque eso puede afectar al rendimiento.
Además, conviene recordar que ciertos diseños mal planteados pueden abrir la puerta a ataques indirectos o fugas de información por canal lateral. No es lo más habitual, pero existe. Y por eso la seguridad nunca debería implementarse de forma mecánica, sin pensar en sus implicaciones.
Seguridad a nivel de columna
Si el RLS protege filas y el DDM oculta valores, la seguridad a nivel de columna va directamente al grano: decide quién puede acceder a determinadas columnas y quién no.
Esto resulta especialmente útil cuando tienes tablas donde solo una parte de la información es sensible. No necesitas ocultar toda la fila ni enmascarar el dato para todos. Simplemente restringes el acceso a las columnas críticas.
Por ejemplo, un usuario puede tener derecho a consultar datos generales de pacientes, pero no su historial médico. O ver datos de clientes sin poder acceder a ciertos atributos financieros o personales.
Y ahí la seguridad de nivel de columna encaja muy bien.
Un control muy fino sobre datos sensibles
La gran ventaja de la seguridad a nivel de columna es su precisión.
Permite seguir compartiendo la tabla y la mayor parte de sus datos, pero restringiendo exactamente aquello que no debe quedar expuesto para ciertos roles o usuarios.
Esto resulta especialmente interesante en sectores regulados o en escenarios donde distintas áreas necesitan trabajar sobre la misma entidad, pero no sobre toda su información.
En cierto modo, es una forma muy quirúrgica de aplicar el principio de mínimo privilegio.
CLS frente a vistas
Muchas veces surge la comparación entre seguridad a nivel de columna y uso de vistas.
Ambas técnicas pueden servir para restringir exposición de datos, pero no juegan exactamente el mismo papel.
Las vistas pueden ayudar a simplificar y presentar una versión filtrada de los datos, pero la seguridad de nivel de columna actúa directamente sobre el objeto y ofrece un control más nativo y granular.
La elección entre una y otra no debería hacerse por costumbre, sino según lo que necesite realmente el modelo y el nivel de control que quieras mantener.
Permisos granulares con T-SQL
Además de estas capas de protección, Fabric permite trabajar con permisos SQL clásicos mediante GRANT, REVOKE y DENY.
Esto da bastante control sobre qué puede hacer cada usuario o rol:
-
SELECT -
INSERT -
UPDATE -
DELETE - ejecución de funciones o procedimientos
- acceso a tablas, vistas y columnas concretas
Y aquí conviene recordar una regla muy importante: cuando DENY y GRANT chocan, DENY prevalece.
Esto parece un detalle técnico, pero es clave para entender cómo se resuelve realmente el acceso.
Tablas, vistas, funciones y procedimientos
Los permisos no se limitan a tablas.
También puedes aplicarlos sobre vistas, funciones y procedimientos almacenados. Y esto es muy útil, porque muchas veces la mejor manera de proteger datos no es dar acceso directo a la tabla, sino permitir el acceso a través de una capa controlada.
En escenarios bien diseñados, la aplicación o el usuario final ni siquiera necesita permisos completos sobre las tablas base. Puede bastar con permitir ejecución sobre determinados procedimientos o acceso a ciertas vistas.
Y eso reduce muchísimo la superficie de exposición.
Principio de mínimo privilegio
Aquí aparece uno de los principios más importantes en seguridad: el de menor privilegio.
La idea es sencilla y muy potente: cada usuario, proceso o aplicación debe tener solo los permisos estrictamente necesarios para hacer su trabajo. Ni uno más.
Esto reduce riesgos, limita impacto en caso de error o abuso y ayuda a construir un sistema mucho más controlado.
Y en un warehouse, donde suele convivir gente con perfiles muy distintos, este principio deja de ser teoría y pasa a ser una necesidad real.
SQL dinámico y precauciones
Cuando se trabaja con permisos y lógica avanzada, a veces aparece SQL dinámico.
Y aquí conviene ser especialmente prudente. SQL dinámico puede ser útil, sí, pero mal usado abre la puerta a inyección SQL y otros problemas bastante serios.
Por eso, si se utiliza, debe hacerse con mecanismos seguros como parametrización, sp_executesql o QUOTENAME, y nunca concatenando texto sin control.
Es una herramienta válida, pero no para usarla a la ligera.
Conclusión
Asegurar un almacenamiento de datos en Microsoft Fabric no consiste en elegir una única técnica y dar el problema por resuelto.
Consiste en combinar capas:
- roles y permisos de workspace
- permisos de elemento
- seguridad SQL granular
- enmascaramiento dinámico
- seguridad a nivel de fila
- seguridad a nivel de columna
Cada una protege una parte distinta del problema. Y juntas permiten construir un entorno donde el dato no solo está disponible, sino también controlado.
