RLS y CLS en Microsoft Fabric: Implementación de Seguridad Granular con T-SQL

En arquitecturas de datos tradicionales, la seguridad por filas solía delegarse a la capa de visualización. Sin embargo, en el ecosistema de Microsoft Fabric, este enfoque es insuficiente. Si solo implementas seguridad en los informes, cualquier usuario con acceso al SQL Analytics Endpoint o al Warehouse podría saltarse las restricciones y consultar datos sensibles directamente. La seguridad debe residir en el motor, lo más cerca posible del dato, para garantizar que el modelo de seguridad sea coherente independientemente de si el consumo se realiza vía Power BI, cuadernos de Python o consultas directas de SQL.

Implementar Row-Level Security (RLS) y Column-Level Security (CLS) en el Warehouse de Fabric no es solo una cuestión de cumplimiento; es una decisión de arquitectura que impacta directamente en el mantenimiento del linaje y la confianza de los datos. En mi experiencia en sectores regulados como el de la energía y el retail, centralizar estas reglas en el motor de SQL reduce drásticamente el error humano y evita la duplicación de lógica en decenas de medidas DAX o roles de Power BI.

Antes de entrar en el código, es fundamental entender que estamos ante un cambio de paradigma. Al trabajar en Fabric, debemos decidir si la seguridad se gestiona a nivel de espacio de trabajo o mediante el motor de SQL. Para proyectos de escala media y grande, el motor de SQL es el único que nos ofrece la granularidad necesaria sin fragmentar la arquitectura. Si quieres profundizar en estas diferencias, te recomiendo revisar esta Lakehouse vs Data Warehouse en Microsoft Fabric: Guía de Arquitectura y Selección.

RLS Dinámico en Fabric Warehouse: El enfoque de metadatos

El RLS dinámico permite filtrar los datos basándose en la identidad del usuario que ejecuta la consulta. En lugar de crear roles estáticos para cada región o departamento, creamos una lógica que cruza el USER_NAME() del usuario con una tabla de permisos. Este método es el estándar de oro en proyectos de consultoría profesional por su escalabilidad.

El primer paso es crear un esquema dedicado a la seguridad y una tabla de mapeo. Esta tabla debe estar alimentada por tu sistema de gestión de identidades o una aplicación de administración de accesos. Evita introducir registros manualmente en producción; automatiza este flujo mediante un pipeline o un procedimiento almacenado.

-- Crear esquema de seguridad para separar lógica de negocio de seguridad
CREATE SCHEMA Seguridad;
GO

-- Tabla de mapeo de usuarios y regiones (ejemplo Retail)
CREATE TABLE Seguridad.PermisosUsuarios (
 EmailUsuario NVARCHAR(256),
 ID_Region INT
);
GO

-- Insertar permisos de ejemplo
INSERT INTO Seguridad.PermisosUsuarios (EmailUsuario, ID_Region) VALUES 
('analista_norte@empresa.com', 1), -- Acceso a Región Norte
('director_comercial@empresa.com', 1), -- Acceso a Región Norte
('director_comercial@empresa.com', 2); -- Acceso a Región Sur
GO

Una vez tenemos la tabla de mapeo, el siguiente paso es definir la función de predicado. Esta función debe ser de tipo INLINE TABLE-VALUED FUNCTION y utilizar el modificador WITH SCHEMABINDING para asegurar que los objetos referenciados no puedan modificarse de forma que rompan la seguridad. Esta función determinará si una fila específica de la tabla de Ventas debe ser visible para el usuario actual.

-- Función de predicado para filtrar la tabla de Ventas
CREATE FUNCTION Seguridad.fn_SeguridadVentas (@ID_Region AS INT)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS Resultado
WHERE EXISTS (
 SELECT 1 
 FROM Seguridad.PermisosUsuarios 
 WHERE EmailUsuario = USER_NAME() 
 AND ID_Region = @ID_Region
);
GO

-- Aplicar la política de seguridad a la tabla de hechos
CREATE SECURITY POLICY Seguridad.VentasFilter
ADD FILTER PREDICATE Seguridad.fn_SeguridadVentas(ID_Region)
ON dbo.Ventas
WITH (STATE = ON);
GO

Este patrón garantiza que, incluso si un usuario conecta Excel al SQL Endpoint, solo verá las filas de las regiones para las que tiene permiso explícito. Si ya conoces cómo funciona esto en el entorno de visualización, verás que la lógica es similar a la del RLS en Power BI: seguridad por filas estática, dinámica y validación en el servicio, pero con la ventaja de ser persistente en la fuente de datos.

Column-Level Security (CLS): Protegiendo datos sensibles

Mientras que el RLS restringe qué filas se ven, el CLS restringe qué columnas son accesibles. En proyectos del sector salud o financiero, es común que un analista necesite ver el volumen total de ventas pero no deba tener acceso al margen de beneficio o a los datos de contacto del cliente. En Microsoft Fabric Warehouse, el CLS se implementa mediante sentencias GRANT a nivel de columna.

Es un error común pensar que el CLS oculta la columna; en realidad, lo que hace es denegar el acceso a la consulta. Si un usuario intenta realizar un SELECT * sobre una tabla donde no tiene permiso para una de las columnas, la consulta fallará. Por ello, es vital educar a los usuarios para que soliciten campos específicos.

-- Supongamos que tenemos la tabla dbo.Ventas con campos sensibles
-- [ID_Venta, Fecha, ID_Producto, Importe_Venta, Margen_Bruto]

-- Denegamos acceso general y permitimos solo columnas específicas al rol de analistas
GRANT SELECT ON dbo.Ventas(ID_Venta, Fecha, ID_Producto, Importe_Venta) TO [Rol_Analistas_Junior];

-- El Margen_Bruto queda restringido solo para el rol de control de gestión
GRANT SELECT ON dbo.Ventas TO [Rol_Control_Gestion];

El uso de CLS es una herramienta potente pero requiere una planificación cuidadosa del esquema. Si tus informes de Power BI están construidos sobre SELECT * (algo que deberías evitar siempre), la implementación de CLS romperá los modelos semánticos de aquellos usuarios sin permisos suficientes. Siempre recomiendo usar vistas intermedias para suavizar el impacto de estas restricciones. Para entender cómo el motor procesa estas solicitudes, consulta la Optimización del motor de consultas en Fabric Warehouse: Guía de rendimiento avanzado.

Decisiones de consultor: Cuándo usar RLS en el Warehouse vs Power BI

Una de las preguntas recurrentes en mis auditorías es: ¿Por qué complicarse con T-SQL si Power BI ya tiene roles? La respuesta reside en el Direct Lake. Microsoft Fabric permite que Power BI lea datos directamente de OneLake sin importar los datos. Si implementamos el RLS en el motor de SQL (Warehouse), perdemos la capacidad de usar Direct Lake en su forma más pura, ya que el motor de SQL debe interceptar la consulta, lo que a menudo nos obliga a pasar a modo DirectQuery o a gestionar la seguridad en el modelo semántico.

Aquí es donde entra el criterio de diseño. Si tu prioridad es el rendimiento extremo con volúmenes masivos de datos y todos tus consumos son vía Power BI, el RLS en el modelo semántico sigue siendo imbatible. Pero si tu prioridad es el gobierno del dato y tienes usuarios atacando el Warehouse desde notebooks, SQL Management Studio o aplicaciones externas, la seguridad debe estar en el Warehouse. Para más detalles sobre cómo medir este impacto, revisa las Pruebas de rendimiento en Fabric Warehouse: metodología y métricas reales.

Para facilitar la decisión, he preparado la siguiente tabla comparativa basada en escenarios reales de implementación:

Errores frecuentes en la implementación de seguridad granular

A lo largo de los años, he visto proyectos de BI descarrilar por una mala gestión de la seguridad. Estos son los tres errores más críticos que debes evitar en Microsoft Fabric:

1. Uso de funciones no deterministas: Si tu función de predicado realiza cálculos complejos o accede a tablas externas sin índices, penalizarás cada una de las consultas de tus usuarios. El RLS se ejecuta para cada fila; si añades 1ms de latencia por fila en una tabla de 100 millones de registros, el informe nunca cargará.
2. Olvidar el filtrado bidireccional en el modelo: Si aplicas RLS en el Warehouse y luego importas los datos a Power BI, asegúrate de que las relaciones entre tablas reflejen la seguridad. No hay nada peor que un RLS que filtra la tabla de hechos pero deja visibles todos los nombres de clientes en la dimensión.
3. No gestionar los administradores: En Fabric, los miembros con roles de Admin, Member o Contributor en el espacio de trabajo suelen tener permisos de db_owner, lo que significa que el RLS no les afecta. La seguridad por filas solo es efectiva para usuarios con permisos de Viewer o aquellos que acceden mediante aplicaciones con identidades específicas. Puedes profundizar en este tema en RLS y CLS en Microsoft Fabric: Seguridad de datos en Warehouse y Lakehouse.

Checklist de implementación para entornos de producción

• Validación de identidad: Confirmar que USER_NAME() devuelve el UPN (Email) esperado en el entorno de Fabric.
• Pruebas de regresión: Ejecutar consultas con un usuario con permisos limitados y verificar que el plan de ejecución no se degrada exponencialmente.
• Documentación de excepciones: Identificar qué usuarios (como cuentas de servicio para ETL) deben estar excluidos de la política de seguridad mediante una cláusula OR IS_MEMBER('RolAdmin') = 1.
• Seguridad por columnas: Verificar que las medidas de Power BI no fallan al intentar acceder a columnas restringidas por CLS.
• Monitoreo: Utilizar las vistas de sistema (DMVs) para auditar quién está accediendo a qué datos y si las políticas están bloqueando intentos de acceso no autorizados.

Preguntas frecuentes

¿El RLS en el Warehouse afecta al rendimiento de las consultas?

Sí, siempre hay un overhead. Al añadir un predicado de seguridad, el motor de SQL debe realizar un JOIN implícito con la tabla de permisos para cada consulta. Si la tabla de permisos es pequeña y está bien indexada, el impacto es despreciable, pero en modelos mal optimizados puede ser crítico.

¿Puedo aplicar CLS y RLS simultáneamente en la misma tabla?

Absolutamente. Puedes restringir que un usuario vea solo las filas de su departamento (RLS) y que, dentro de esas filas, no pueda ver la columna de ‘Salario’ o ‘Costo Unitario’ (CLS). Es la configuración recomendada para entornos de máxima seguridad.

¿Qué ocurre si un usuario no está en la tabla de permisos?

Depende de cómo hayas escrito la función. Si usas un INNER JOIN o un EXISTS y el usuario no tiene registros asociados, la función devolverá falso para todas las filas y el usuario verá una tabla vacía. Es el comportamiento más seguro (denegación por defecto).

¿Funciona el RLS de SQL con el modo Direct Lake de Power BI?

Actualmente, si aplicas RLS a nivel de SQL en el Warehouse, el modelo semántico de Power BI en modo Direct Lake suele hacer un fallback a DirectQuery para respetar la seguridad del motor. Esto impacta en el rendimiento, por lo que debes evaluar si prefieres velocidad (RLS en Power BI) o gobernanza (RLS en Warehouse).