Seguridad de nivel de fila en el almacenamiento de datos de Fabric

Se aplica a:✅ punto de conexión de análisis de SQL y Warehouse 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 a nivel de fila solo se aplica a las consultas en un almacén de lago o punto de conexión de análisis SQL en Fabric. Las consultas de Power BI en un almacén en modo Direct Lake se revertirán al modo Direct Query para cumplir 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. Los predicados de filtro, la aplicación es consciente de las filas filtradas 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 desde la tabla base y 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 en la función que se usa como predicado.

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

• El permiso REFERENCES en todas las columnas de la tabla de destino que se usan como argumentos.

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 observar que un administrador de directivas de seguridad malintencionado, con permisos suficientes para crear una directiva de seguridad en una columna confidencial, y con permisos para crear o modificar funciones insertadas con valores de tabla, puede conspirar con otro usuario que tenga permisos SELECT en una tabla para exfiltrar datos creando de forma malintencionada funciones insertadas con valores de tabla diseñadas para usar ataques del lado de canal para inferir los datos. Estos ataques necesitarían una confabulación (o excesivos permisos concedidos a un usuario malintencionado) y es probable que necesiten varios cambios de la directiva (con permisos para quitar el predicado con el fin de romper el enlace de esquema), modificación de las funciones con valores de tabla insertadas y 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. Deben supervisarse actividades tales como el cambio constante de directivas y las funciones con valores tablas relacionadas con la seguridad a 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 que un usuario malintencionado sepa que el salario de Juan García es $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 el almacenamiento de lago de seguridad de nivel de fila y el punto de conexión de análisis 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 quitar la directiva de seguridad. En el script siguiente, debe quitar la directiva SalesFilter antes de emitir 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

Implementación de la seguridad de nivel de fila en el Almacenamiento de datos de Fabric

Contenido relacionado

• Seguridad para el almacenamiento de datos en Microsoft Fabric
• Uso compartido de los datos y administración de permisos
• Seguridad de nivel de columna en el almacenamiento de datos de Fabric
• Enmascaramiento dinámico de datos en el almacenamiento de datos de Fabric