Segurança em Nível de Linha no armazenamento de dados do Fabric

Aplica-se a:✅ ponto de extremidade de análise do 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 de 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 ponto de extremidade de análise do SQL ou Warehouse 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. Filtrar predicados filtrar 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, não há nenhuma indicação ao aplicativo de que as linhas tenham sido filtradas no 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 de obtenção: SELECT, DELETEe 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 está ciente de todas as linhas filtradas para 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 na função que está sendo usada como um predicado.

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

• Permissão REFERENCES em cada coluna da tabela de destino usada como argumentos.

Diretivas de segurança se aplicam a todos os usuários, incluindo usuários de dbo do 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 gerente de política de segurança mal-intencionado, com permissões suficientes para criar uma política de segurança na parte superior de uma coluna confidencial, tendo permissão para criar ou alterar funções embutidas com valor de tabela, poderá conspirar com outro usuário que tenha permissões SELECT em uma tabela para realizar a exportação de dados, pela criação mal-intencionada de funções embutidas com valor de tabela, projetadas para usar ataques de temporização para 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. É recomendável limitar as permissões conforme necessário e o monitor para qualquer atividade suspeita. As atividade como políticas em constante mudança e as 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 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 o Warehouse de Segurança em Nível de Linha e o ponto de extremidade de análise do 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 de análise do SQL usam tabelas existentes. No ponto de extremidade de análise do SQL, não é possível CREATE TABLE, mas você poderá 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, descartamos a política SalesFilter antes de emitir 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

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

Conteúdo relacionado

• Segurança para armazenamento de dados no Microsoft Fabric
• Compartilhar os dados e gerenciar as permissões
• Segurança em nível de coluna no armazenamento de dados do Fabric
• Mascaramento dinâmico de dados no armazenamento de dados do Fabric