Seguridad a nivel de fila en Fabric Data Warehouse

Se aplica a:✅ punto de conexión de análisis SQL y almacén de datos en Microsoft Fabric

La característica Seguridad de nivel de fila (RLS) permite utilizar la pertenencia a un grupo o el contexto de ejecución para controlar el acceso a las filas de una tabla de base de datos. Por ejemplo, puede asegurarse de que los trabajadores accedan únicamente a aquellas filas de datos que sean pertinentes para su departamento. Otro ejemplo es restringir el acceso a los datos de los clientes únicamente a los datos relevantes para su empresa en una arquitectura multiusuario. La característica es similar a la seguridad de nivel de fila en SQL Server.

Seguridad de nivel de fila en el nivel de datos

La seguridad de nivel de fila simplifica el diseño y la codificación de la seguridad de la aplicación. La seguridad de nivel de fila le ayuda a implementar restricciones en el acceso a filas de datos.

La lógica de restricción de acceso está en el nivel de base de datos, no en ningún nivel de aplicación único. La base de datos aplica las restricciones de acceso cada vez que se intenta acceder a los datos, desde cualquier aplicación o plataforma de informes, incluido Power BI. Esto hace que el sistema de seguridad resulte más sólido y confiable al reducir el área expuesta del sistema de seguridad. La seguridad de nivel de fila solo se aplica a las consultas realizadas en un almacén o en un punto de conexión de análisis de SQL en Fabric. Las consultas de Power BI sobre un almacén en modo Direct Lake volverán al modo Direct Query para respetar la seguridad de nivel de fila.

Restringir el acceso a determinadas filas a determinados usuarios

Implemente RLS mediante la instrucción Transact-SQL CREATE SECURITY POLICY y los predicados creados como funciones con valores de tabla insertadas.

La seguridad a nivel de fila se aplica a los almacenes compartidos o lakehouse, porque la fuente de datos subyacente no ha cambiado.

Seguridad de nivel de fila basada en predicados

La seguridad de nivel de fila en Fabric Data Warehouse admite la seguridad basada en predicados. Los predicados de filtro filtran silenciosamente las filas disponibles para las operaciones de lectura.

El acceso a los datos de nivel de fila de una tabla está restringido por un predicado de seguridad que se define como una función con valores de tabla insertada. Luego, la función se invoca y una directiva de seguridad la aplica. En el caso de los predicados de filtro, la aplicación no es consciente de las filas que se filtran del conjunto de resultados. Si se filtran todas las filas, se devolverá un conjunto nulo.

Los predicados de filtro se aplican al leer los datos de la tabla base. Afectan a todas las operaciones get:SELECT, DELETE y UPDATE. Cada tabla debe tener su propia seguridad de nivel de fila definida por separado. Los usuarios que consultan tablas sin una directiva de seguridad de nivel de fila verán los datos sin filtrar.

Los usuarios no pueden seleccionar o eliminar las filas filtradas. El usuario no puede actualizar las filas filtradas. Pero, es posible actualizar las filas de tal manera que se filtren después.

Los predicados de filtro y las directivas de seguridad tienen el siguiente comportamiento:

• Puede definir una función de predicado que se combine con otra tabla y/o invoque una función. Si la directiva de seguridad se crea con SCHEMABINDING = ON (el valor predeterminado), entonces se puede acceder a la función o combinación desde la consulta, y funciona como se espera sin comprobaciones de permisos adicionales.

• Puede emitir una consulta a una tabla que tenga un predicado de seguridad definido pero deshabilitado. Todas las filas que se han filtrado o bloqueado no se ven afectadas.

• Si el usuario dbo, un miembro del rol db_owner o el propietario de la tabla consulta una tabla que tiene una directiva de seguridad definida y habilitada, las filas se filtran o bloquean según indique la directiva de seguridad.

• Los intentos de modificar el esquema de una tabla enlazada por una directiva de seguridad enlazada a un esquema producirán un error. Sin embargo, se pueden modificar las columnas a las que el predicado no hace referencia.

• Los intentos de agregar un predicado a una tabla que ya tiene uno definido para la operación especificada producen un error. Esto ocurrirá tanto si el predicado está habilitado como si no.

• Los intentos de modificar una función, que se usa como predicado en una tabla dentro de una directiva de seguridad enlazada a un esquema, producen un error.

• Definir varias directivas de seguridad activas que contienen predicados no superpuestos, será correcto.

Los predicados de filtro tienen el siguiente comportamiento:

• Definir una directiva de seguridad que filtre las filas de una tabla. La aplicación no es consciente de las filas que se filtran para las operaciones SELECT, UPDATE y DELETE. Incluidas las situaciones en las que todas las filas se filtran. La aplicación puede INSERT filas, incluso si se filtrarán durante cualquier otra operación.

Permisos

Para crear, modificar o anular directivas de seguridad se requiere el permiso ALTER ANY SECURITY POLICY. Para crear o anular directivas de seguridad se requiere el permiso ALTER en el esquema.

Además, son necesarios los siguientes permisos para cada predicado que se agrega:

• Los permisos SELECT y REFERENCES sobre la función utilizada como predicado.

• El permiso REFERENCES en la tabla de destino que se enlaza a la directiva.

• El permiso REFERENCES sobre cada columna de la tabla de destino utilizada como argumento.

Las directivas de seguridad se aplican a todos los usuarios, incluidos los usuarios dbo de la base de datos. Los usuarios dbo pueden modificar o quitar directivas de seguridad, sin embargo, se pueden auditar los cambios en las directivas de seguridad. Si los miembros de roles como Administrador, Miembro o Colaborador deben ver todas las filas para solucionar problemas o validar datos, la directiva de seguridad debe escribirse para permitirlo.

Si se crea una política de seguridad con SCHEMABINDING = OFF, entonces para consultar la tabla de destino, los usuarios deben tener el permiso SELECT o EXECUTE en la función predicada y en cualquier tabla, vista o función adicional utilizada dentro de la función predicada. Si se crear una directiva de seguridad con SCHEMABINDING = ON (el valor predeterminado), entonces estas comprobaciones de permiso se omiten cuando los usuarios consultan la tabla de destino.

Consideraciones de seguridad: ataques de canal lateral

Tenga en cuenta y prepárese para los dos escenarios siguientes.

Administrador de directivas de seguridad malintencionado

Es importante señalar que un administrador malintencionado de directivas de seguridad, con permisos suficientes para crear una directiva de seguridad sobre una columna confidencial y con permisos para crear o modificar funciones de tabla insertadas en línea, puede confabularse con otro usuario que tenga permisos SELECT en una tabla para exfiltrar datos mediante la creación malintencionada de funciones de tabla insertadas en línea diseñadas para usar ataques de canal lateral para deducir datos. Estos ataques requerirían colusión (o la concesión de permisos excesivos a un usuario malintencionado) y probablemente exigirían varias iteraciones de modificación de la política (lo que requeriría permiso para quitar el predicado a fin de romper el enlace al esquema), de modificación de las funciones de tabla insertadas en línea y de ejecución repetida de instrucciones SELECT en la tabla de destino. Se recomienda limitar los permisos según sea necesario y supervisar cualquier actividad sospechosa. Se debe supervisar la actividad, como los cambios constantes de políticas y las funciones de valor de tabla insertadas en línea relacionadas con la seguridad de nivel de fila.

Consultas cuidadosamente diseñadas

Es posible provocar la pérdida de información mediante consultas cuidadosamente diseñadas que usan errores para filtrar datos. Por ejemplo, SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; permitiría a un usuario malintencionado saber que el salario de John Doe es exactamente 100.000 $. Aunque hay un predicado de seguridad para impedir que un usuario malintencionado consulte directamente el salario de otras personas, el usuario puede determinar el momento en que la consulta devuelve una excepción de división por cero.

Ejemplos

Podemos demostrar la seguridad de nivel de fila en Warehouse y en el punto de conexión de análisis de SQL en Microsoft Fabric.

En el ejemplo siguiente se crean tablas de ejemplo que funcionarán con Warehouse en Fabric, pero en el punto de conexión de análisis SQL se usan tablas existentes. En el punto de conexión de análisis SQL, no puedes CREATE TABLE, pero sí CREATE SCHEMA, CREATE FUNCTION y CREATE SECURITY POLICY.

En este ejemplo, cree primero un esquema sales, una tabla sales.Orders.

CREATE SCHEMA sales;
GO

-- Create a table to store sales data
CREATE TABLE sales.Orders (
    SaleID INT,
    SalesRep VARCHAR(100),
    ProductName VARCHAR(50),
    SaleAmount DECIMAL(10, 2),
    SaleDate DATE
);

-- Insert sample data
INSERT INTO sales.Orders (SaleID, SalesRep, ProductName, SaleAmount, SaleDate)
VALUES
    (1, 'Sales1@contoso.com', 'Smartphone', 500.00, '2023-08-01'),
    (2, 'Sales2@contoso.com', 'Laptop', 1000.00, '2023-08-02'),
    (3, 'Sales1@contoso.com', 'Headphones', 120.00, '2023-08-03'),
    (4, 'Sales2@contoso.com', 'Tablet', 800.00, '2023-08-04'),
    (5, 'Sales1@contoso.com', 'Smartwatch', 300.00, '2023-08-05'),
    (6, 'Sales2@contoso.com', 'Gaming Console', 400.00, '2023-08-06'),
    (7, 'Sales1@contoso.com', 'TV', 700.00, '2023-08-07'),
    (8, 'Sales2@contoso.com', 'Wireless Earbuds', 150.00, '2023-08-08'),
    (9, 'Sales1@contoso.com', 'Fitness Tracker', 80.00, '2023-08-09'),
    (10, 'Sales2@contoso.com', 'Camera', 600.00, '2023-08-10');

Cree un esquema Security, una función Security.tvf_securitypredicate y una directiva de seguridad SalesFilter.

-- Creating schema for Security
CREATE SCHEMA Security;
GO
 
-- Creating a function for the SalesRep evaluation
CREATE FUNCTION Security.tvf_securitypredicate(@SalesRep AS nvarchar(50))
    RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS tvf_securitypredicate_result
WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'manager@contoso.com';
GO
 
-- Using the function to create a Security Policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO

Para modificar una función de seguridad de nivel de fila, primero debe eliminar la directiva de seguridad. En el siguiente script, eliminamos la política SalesFilter antes de ejecutar una instrucción ALTER FUNCTION en Security.tvf_securitypredicate. A continuación, se vuelve a crear la directiva SalesFilter.

-- Drop policy so we can change the predicate function.
DROP SECURITY POLICY SalesFilter;
GO

-- Alter the function for the SalesRep evaluation
ALTER FUNCTION Security.tvf_securitypredicate(@SalesRep AS nvarchar(50))
    RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS tvf_securitypredicate_result
WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'president@contoso.com';
GO
 
-- Re-create a Security Policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO

Paso siguiente

Implementar seguridad a nivel de fila en Fabric Data Warehouse

Contenido relacionado

• Seguridad en Fabric Data Warehouse
• Uso compartido de los datos y administración de permisos
• Seguridad a nivel de columna en Fabric Data Warehouse
• Enmascaramiento dinámico de datos en Fabric Data Warehouse