Partilhar via

Segurança em nível de linha no data warehousing da malha

  • Artigo

Aplica-se a: ponto de extremidade de análise SQL e Warehouse no Microsoft Fabric

A segurança em nível de linha (RLS) permite que você use a associação ao grupo ou o contexto de execução para controlar o acesso a linhas em uma tabela de banco de dados. Por exemplo, você pode garantir que os trabalhadores acessem apenas as linhas de dados pertinentes ao departamento. Outro exemplo é restringir o acesso dos clientes aos dados 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 de dados

A segurança em nível de linha simplifica o design e a codificação da segurança em seu aplicativo. A segurança em nível de linha ajuda a implementar restrições no acesso à linha de dados.

A lógica de restrição de acesso está na camada de banco de dados, não em qualquer camada de aplicativo único. O banco de dados aplica as restrições de acesso sempre que o acesso a dados é tentado, de qualquer aplicativo ou plataforma de relatórios, incluindo o Power BI. Isto torna o seu sistema de segurança mais fiável e robusto, reduzindo a área de superfície do seu sistema de segurança. A segurança em nível de linha só se aplica a consultas em um ponto de extremidade de análise SQL ou Warehouse no Fabric. As consultas do Power BI em um depósito no modo Direct Lake retornarão ao modo de Consulta Direta para respeitar a segurança em nível de linha.

Restringir o acesso a determinadas linhas a determinados utilizadores

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

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

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

A segurança em nível de linha no Fabric Synapse Data Warehouse suporta segurança baseada em predicados. Os predicados de filtro filtram silenciosamente as linhas disponíveis para operações de leitura.

O acesso a dados de nível de linha em uma tabela é restrito por um predicado de segurança definido como uma função com valor de tabela embutido. A função é então invocada e imposta por uma política de segurança. Para predicados de filtro, o aplicativo não está ciente de linhas que são filtradas a partir do conjunto de resultados. Se todas as linhas forem filtradas, um conjunto nulo será retornado.

Os predicados de filtro são aplicados durante a leitura de dados da tabela base. Eles afetam todas as operações de obtenção: SELECT, DELETE, e UPDATE. Os usuários não podem selecionar ou excluir linhas filtradas. O usuário não pode atualizar linhas filtradas. Mas é possível atualizar as linhas de tal forma que elas sejam filtradas depois.

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 se 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 associação ou função estará acessível a partir da consulta e funcionará conforme o esperado, sem verificações de permissão adicionais.

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

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

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

  • Tentativas de adicionar um predicado em uma tabela que já tem um definido para a operação especificada resulta em um erro. Isso acontecerá independentemente de o predicado estar habilitado ou não.

  • As tentativas de modificar uma função, que é usada como um predicado em uma tabela dentro de uma diretiva de segurança vinculada ao esquema, resultarão em um erro.

  • A definição de várias políticas de segurança ativas que contêm predicados não sobrepostos é bem-sucedida.

Os predicados de filtro têm o seguinte comportamento:

  • Defina uma política de segurança que filtre as linhas de uma tabela. O aplicativo não tem conhecimento de quaisquer linhas que são filtradas para SELECT, UPDATEe DELETE operações. 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 descartar políticas de segurança requer a ALTER ANY SECURITY POLICY permissão. Criar ou descartar uma política de segurança requer ALTER permissão no esquema.

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

  • SELECT e REFERENCES permissões sobre a função que está sendo usada como predicado.

  • REFERENCES permissão na tabela de destino sendo vinculada à política.

  • REFERENCES permissão em todas as colunas da tabela de destino usadas como argumentos.

As políticas de segurança aplicam-se a todos os utilizadores, incluindo os utilizadores dbo na base de dados. Os usuários do Dbo podem alterar ou descartar as políticas de segurança, no entanto, suas alterações nas políticas de segurança podem ser auditadas. Se os membros de funções como Administrador, Membro ou Colaborador precisarem ver todas as linhas para solucionar problemas ou validar dados, a diretiva de segurança deverá ser gravada para permitir isso.

Se uma diretiva de segurança for criada com SCHEMABINDING = OFFo , para consultar a tabela de destino, os usuários deverão ter a SELECT permissão 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 diretiva 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.

Gestor de políticas de segurança maliciosas

É importante observar que um gerenciador de políticas de segurança mal-intencionado, com permissões suficientes para criar uma política de segurança em cima de uma coluna confidencial e com permissão para criar ou alterar funções com valor de tabela embutido, pode entrar em conluio com outro usuário que tenha permissões de seleção em uma tabela para executar a exfiltração de dados criando maliciosamente funções com valor de tabela embutidas projetadas para usar ataques de canal lateral para inferir dados. Tais ataques exigiriam conluio (ou permissões excessivas concedidas a um usuário mal-intencionado) e provavelmente exigiriam várias iterações de modificação da política (exigindo permissão para remover o predicado para quebrar a vinculação do esquema), modificando as funções com valor de tabela embutido e executando repetidamente instruções select 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 com valor de tabela em linha relacionadas à segurança em nível de linha devem ser monitoradas.

Consultas cuidadosamente elaboradas

É possível causar vazamento de informações usando consultas cuidadosamente elaboradas que usam erros para exfiltrar dados. Por exemplo, SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; informaria um usuário mal-intencionado de que o salário de John Doe é exatamente de US$ 100.000. Embora 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 o Warehouse de segurança em nível de linha e o ponto de extremidade de análise SQL no Microsoft Fabric.

O exemplo a seguir cria tabelas de exemplo que funcionarão com o Warehouse no Fabric, mas no ponto de extremidade da análise SQL usam tabelas existentes. No ponto de extremidade de análise SQL, você não pode CREATE TABLE, mas você pode CREATE SCHEMA, CREATE FUNCTIONe 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');

Crie um Security esquema, uma função Security.tvf_securitypredicatee uma política SalesFilterde segurança.

-- 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

Conteúdos relacionados

Próximo passo

Implementar segurança em nível de linha no Fabric Data Warehousing