Segurança em nível de linha em Fabric Data Warehouse

Aplica-se a:✅ endpoint de análise SQL e Warehouse no Microsoft Fabric

A Segurança em Nível de Linha (RLS) permite que você use o contexto de execução ou associação de grupo para controlar o acesso a linhas em uma tabela de banco de dados. Por exemplo, você pode garantir que os funcionários acessem somente as linhas de dados que são relevantes aos seus departamentos. Outro exemplo é restringir o acesso de dados dos clientes apenas aos dados relevantes para sua empresa em uma arquitetura multilocatário. O recurso é semelhante à Segurança em Nível de Linha no SQL Server.

Segurança em nível de linha no nível dos dados

A Segurança em Nível de Linha simplifica o design e a codificação de segurança em seu aplicativo. A Segurança em Nível de Linha ajuda você a implementar restrições no acesso a linhas de dados.

A lógica de restrição de acesso está na camada de banco de dados, não em nenhuma camada de aplicativo. O banco de dados aplica as restrições de acesso sempre que há uma tentativa de acesso aos dados, de qualquer aplicativo ou plataforma de relatórios, incluindo o Power BI. Isso torna o sistema de segurança mais robusto e confiável, reduzindo a área de superfície do sistema de segurança. A segurança em nível de linha só se aplica a consultas em um Warehouse ou ponto de extremidade de análise SQL no Fabric. As consultas do Power BI em um warehouse no modo Direct Lake retornarão ao modo Direct Query para cumprir a segurança em nível de linha.

Restringir o acesso a determinadas linhas a determinados usuários

Implemente a RLS usando a instrução CREATE SECURITY POLICY Transact-SQL e predicados criados como funções com valor de tabela embutida.

A segurança em nível de linha é aplicada ao warehouse ou lakehouse compartilhado, porque a fonte de dados subjacente não foi alterada.

Segurança em nível de linha baseada em predicado

A segurança em nível de linha no Data Warehouse do Fabric dá suporte à segurança baseada em predicado. Predicados de filtro filtram silenciosamente as linhas disponíveis para operações de leitura.

O acesso aos dados no nível de linha em uma tabela é restrito por um predicado de segurança definido como uma função com valor de tabela embutida. A função é então invocada e imposta por uma política de segurança. Para predicados de filtro, a aplicação não tem conhecimento das linhas que são filtradas do conjunto de resultados. Se todas as linhas forem filtradas, um conjunto de null será retornado.

Predicados de filtro são aplicados durante a leitura de dados da tabela base. Elas afetam todas as operações get: SELECT, DELETE, e UPDATE. Cada tabela deve ter sua própria segurança em nível de linha definida separadamente. Os usuários que consultarem tabelas sem uma política de segurança em nível de linha visualizarão dados não filtrados.

Os usuários não podem selecionar ou excluir linhas que são filtradas. Os usuários não podem atualizar as linhas que são filtradas. Mas é possível atualizar as linhas de forma que elas sejam filtradas posteriormente.

O predicado de filtro e as políticas de segurança têm o seguinte comportamento:

  • Você pode definir uma função de predicado que une a outra tabela e/ou invoca uma função. Se a política de segurança for criada com SCHEMABINDING = ON (o padrão), a junção ou função será acessível pela consulta e funcionará como o esperado, sem nenhuma verificação de permissão adicional.

  • Você pode emitir uma consulta em uma tabela que tenha um predicado de segurança definido, mas desabilitado. Quaisquer linhas que tenham sido filtradas ou bloqueadas não serão afetadas.

  • Se um usuário dbo, um membro da função db_owner ou o proprietário da tabela consultarem uma tabela que tenha uma política de segurança definida e habilitada, as linhas serão filtradas ou bloqueadas conforme definido pela política de segurança.

  • As tentativas de alterar o esquema de uma tabela associada por uma política de segurança associada ao esquema resultarão em um erro. No entanto, as colunas não referenciadas pelo predicado podem ser alteradas.

  • Tentar adicionar um predicado em uma tabela que já tenha um definido para a operação especificada resultará em um erro. Isso ocorrerá se o predicado estiver habilitado ou não.

  • As tentativas de modificar uma função que é usada como um predicado em uma tabela em uma política de segurança associada ao esquema resultarão em um erro.

  • Definir múltiplas políticas de segurança ativas que contêm predicados não sobrepostos é uma ação que terá êxito.

Os predicados de filtro apresentam o seguinte comportamento:

  • Defina uma política de segurança que filtra as linhas de uma tabela. O aplicativo não reconhece quaisquer linhas que estejam filtradas nas operações SELECT, UPDATE e DELETE. Incluindo situações em que todas as linhas são filtradas. O aplicativo pode INSERT linhas, mesmo que elas sejam filtradas durante qualquer outra operação.

Permissões

Criar, alterar ou remover políticas de segurança requer a permissão ALTER ANY SECURITY POLICY. Criar ou remover uma política de segurança requer a permissão ALTER no esquema.

Além disso, as seguintes permissões são necessárias para cada predicado adicionado:

  • Permissões SELECT e REFERENCES para a função usada como predicado.

  • Permissão REFERENCES na tabela de destino associada à política.

  • REFERENCES permissão em cada coluna da tabela de destino usada como argumento.

Políticas de segurança aplicam-se a todos os usuários, incluindo usuários dbo no banco de dados. Os usuários do dbo podem alterar ou descartar as políticas de segurança, mas suas alterações às políticas de segurança podem ser auditadas. Se membros de funções como Administrador, Membro ou Colaborador precisarem ver todas as linhas para solucionar problemas ou validar dados, a política de segurança deverá ser gravada para permitir isso.

Se uma política de segurança for criada com SCHEMABINDING = OFF, para consultar a tabela de destino, os usuários deverão ter a permissão SELECT ou EXECUTE na função de predicado e quaisquer tabelas, exibições ou funções adicionais usadas dentro da função de predicado. Se uma política de segurança for criada com SCHEMABINDING = ON (o padrão), essas verificações de permissão serão ignoradas quando os usuários consultarem a tabela de destino.

Considerações de segurança: ataques de canal lateral

Considere e prepare-se para os dois cenários a seguir.

Gerente de política de segurança mal-intencionado

É importante observar que um administrador de políticas de segurança mal-intencionado, com permissões suficientes para criar uma política de segurança sobre uma coluna sensível e permissão para criar ou alterar funções de tabela embutidas, pode agir em conluio com outro usuário que tenha permissão de SELECT em uma tabela para realizar exfiltração de dados, criando maliciosamente funções de tabela embutidas projetadas para usar ataques de canal lateral a fim de inferir dados. Esses ataques exigiriam a colusão (ou excesso de permissões concedidas a um usuário mal-intencionado) e provavelmente demandariam várias iterações de modificação da política (exigindo permissão para remover o predicado, para que pudessem então quebrar a associação do esquema), modificando as funções com valor de tabela embutida e repetidamente executando instruções de seleção na tabela de destino. Recomendamos que você limite as permissões conforme necessário e monitore qualquer atividade suspeita. Atividades como políticas em constante mudança e funções de tabela embutidas relacionadas à segurança em nível de linha devem ser monitoradas.

Consultas cuidadosamente elaboradas

É possível causar vazamento de informações usando consultas cuidadosamente criadas que usam erros para exfiltrar dados. Por exemplo, SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; deixaria um usuário mal-intencionado saber que o salário de John Doe é exatamente US$ 100.000. Mesmo que haja um predicado de segurança em vigor para impedir que um usuário mal-intencionado consulte diretamente o salário de outras pessoas, o usuário pode determinar quando a consulta retorna uma exceção de divisão por zero.

Exemplos

Podemos demonstrar a segurança em nível de linha no Warehouse e no endpoint de análise SQL no Microsoft Fabric.

O exemplo a seguir cria tabelas de exemplo que funcionam com o Warehouse no Fabric, mas, no endpoint de análise SQL, use tabelas existentes. No endpoint de análises SQL, você não pode CREATE TABLE, mas pode CREATE SCHEMA, CREATE FUNCTION e CREATE SECURITY POLICY.

Neste exemplo, primeiro crie um esquema sales, uma tabela 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');

Criar um esquema Security, uma função Security.tvf_securitypredicate e uma política de segurança 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 uma função de segurança em nível de linha, você deve primeiro descartar a política de segurança. No script a seguir, removemos a política SalesFilter antes de executar uma instrução ALTER FUNCTION em Security.tvf_securitypredicate. Em seguida, recriamos a política 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

Próxima etapa

Implemente segurança em nível de linha no Fabric Data Warehouse

Conteúdo relacionado

  • Last updated on