Tabela sensível a filtros uso de dados filtros de linha e máscaras de coluna
Este artigo apresenta diretrizes e exemplos para usar filtros de linha, máscaras de coluna e tabelas de mapeamento para filtrar dados confidenciais em suas tabelas. Esses recursos exigem o Unity Catalog.
O que são filtros de linha?
Os filtros de linha permitem que você aplique um filtro a uma tabela para que as consultas retornem somente as linhas que atendam aos critérios do filtro. O senhor implementa um filtro de linha como uma função definida pelo usuário (UDF) SQL. As UDFs do Python e do Scala também são compatíveis, mas somente quando são agrupadas em UDFs do SQL.
O que são máscaras de coluna?
As máscaras de coluna permitem aplicar uma função de mascaramento a uma coluna da tabela. A função de mascaramento é avaliada no tempo de execução da consulta, substituindo cada referência da coluna de destino pelos resultados da função de mascaramento. Na maioria dos casos de uso, as máscaras de coluna determinam se o valor original da coluna deve ser retornado ou editado com base na identidade do usuário que está invocando. As máscaras de coluna são expressões escritas como UDFs de SQL ou como UDFs de Python ou Scala envoltas em UDFs de SQL.
Cada coluna da tabela pode ter somente uma função de mascaramento aplicada a ela. A função de mascaramento usa o valor não mascarado da coluna como entrada e retorna o valor mascarado como resultado. O valor de retorno da função de mascaramento deve ser do mesmo tipo da coluna que está sendo mascarada. A função de mascaramento também pode usar colunas adicionais como parâmetros de entrada e usá-las em sua lógica de mascaramento.
Qual é a diferença entre esses filtros e a exibição dinâmica?
Exibições dinâmicas, filtros de linha e máscaras de coluna possibilitam que você aplique uma lógica complexa às tabelas e processe suas decisões de filtragem no tempo de execução da consulta.
Um viewdinâmico é um view abstrato e somente leitura de uma ou mais tabelas de origem. O usuário pode acessar um view dinâmico sem ter acesso direto às tabelas de origem. A criação de um view dinâmico define um novo nome de tabela que não deve corresponder ao nome de nenhuma tabela de origem ou de outras tabelas e visualizações presentes no mesmo esquema.
Por outro lado, associar um filtro de linha ou máscara de coluna a uma tabela de destino aplica a lógica correspondente diretamente à tabela em si, sem introduzir novos nomes de tabela. Consultas subsequentes podem continuar a se referir diretamente à tabela de destino utilizando seu nome original.
Use a visualização dinâmica se precisar aplicar a lógica de transformações, como filtros e máscaras, a tabelas somente de leitura e se for aceitável que os usuários se refiram à visualização dinâmica usando nomes diferentes. Se quiser filtrar os dados ao compartilhá-los usando Delta Sharing, o senhor deve usar a visualização dinâmica. Use filtros de linha e máscaras de coluna se quiser filtrar ou compute expressões sobre dados específicos, mas ainda assim fornecer aos usuários acesso às tabelas usando seus nomes originais.
Antes de começar
Para adicionar filtros de linha e máscaras de coluna a tabelas, você deve ter:
- Um espaço de trabalho preparado para o Unity Catalog.
- Uma função que está registrada no Unity Catalog. Essa função pode ser uma UDF SQL ou uma UDF Python ou Scala registrada no Unity Catalog e envolvida em uma UDF SQL. Para obter detalhes, consulte O que são funções definidas pelo usuário (UDFs)? , cláusula da coluna
mask
e cláusulaROW FILTER
.
Você também deve atender aos seguintes requisitos:
- Para atribuir uma função que adiciona filtros de linha ou máscaras de coluna a uma tabela, você deve ter o privilégio
EXECUTE
na função,USE SCHEMA
no esquema eUSE CATALOG
no catálogo principal. - Se você estiver adicionando filtros ou máscaras ao criar uma nova tabela, deverá ter o privilégio
CREATE TABLE
no esquema. - Se você estiver adicionando filtros ou máscaras a uma tabela existente , deverá ser o proprietário da tabela.
Para acessar uma tabela que tenha filtros de linha ou máscaras de coluna, seu recurso de compute deve atender a um desses requisitos:
- A SQL warehouse.
- Modo de acesso padrão (anteriormente modo de acesso compartilhado) em Databricks Runtime 12.2 LTS ou acima.
- Modo de acesso dedicado (anteriormente, modo de acesso de usuário único) em Databricks Runtime 15.4 LTS ou acima.
O senhor não pode ler filtros de linha ou máscaras de coluna usando o site dedicado compute em Databricks Runtime 15.3 ou abaixo.
Para aproveitar a filtragem de dados fornecida em Databricks Runtime 15.4 LTS e acima, o senhor também deve verificar se o seu workspace está habilitado para serverless compute , pois a funcionalidade de filtragem de dados que suporta filtros de linha e máscaras de coluna é executada em serverless compute. O senhor poderá ser cobrado pelo serverless compute recurso quando usar o compute configurado como modo de acesso dedicado para ler tabelas que usam filtros de linha ou máscaras de coluna. Consulte Controle de acesso refinado em compute dedicado (anteriormente, usuário único compute).
Aplicar um filtro de linha
Para criar um filtro de linha, você escreve uma função (UDF) para definir a política de filtro e, em seguida, aplica a uma tabela. Cada tabela pode ter apenas um filtro de linha. Um filtro de linha aceita zero ou mais parâmetros de entrada em que cada parâmetro de entrada se vincula a uma coluna da tabela correspondente.
O senhor pode aplicar um filtro de linha usando o Catalog Explorer ou SQL comando. As instruções do Catalog Explorer pressupõem que o senhor já criou uma função e a registrou no Unity Catalog. As instruções SQL incluem exemplos de como criar uma função de filtro de linha e aplicá-la a uma tabela.
- Catalog Explorer
- SQL
- In your Databricks workspace, click
Catalog.
- Browse or search for the table you want to filter.
- On the Overview tab, click Row filter: Add filter.
- On the Add row filter dialog, select the catalog and schema that contain the filter function, then select the function.
- On the expanded dialog, view the function definition and select the table columns that match the columns included in the function statement.
- Click Add.
To remove the filter from the table, click fx Row filter and click Remove.
To create a row filter, and then add it to an existing table, use CREATE FUNCTION
and apply the function using ALTER TABLE
. You can also apply a function when you create a table using CREATE TABLE
.
-
Create the row filter:
SQLCREATE FUNCTION <function_name> (<parameter_name> <parameter_type>, ...)
RETURN {filter clause whose output must be a boolean}; -
Apply the row filter to a table using a column name:
SQLALTER TABLE <table_name> SET ROW FILTER <function_name> ON (<column_name>, ...);
Additional syntax examples:
-
Apply the row filter to a table using a constant literal that matches a function parameter:
SQLALTER TABLE <table_name> SET ROW FILTER <function_name> ON (<constant_literal>, ...);
-
Remove a row filter from a table:
SQLALTER TABLE <table_name> DROP ROW FILTER;
-
Modify a row filter:
SQLRun a DROP FUNCTION statement to drop the existing function, or use CREATE OR REPLACE FUNCTION to replace it.
-
Delete a row filter:
SQLALTER TABLE <table_name> DROP ROW FILTER;
DROP FUNCTION <function_name>;
You must perform the ALTER TABLE ... DROP ROW FILTER
command before you drop the function. If you don’t, the table will be in an inaccessible state.
If the table becomes inaccessible in this way, alter the table and drop the orphaned row filter reference using ALTER TABLE <table_name> DROP ROW FILTER;
.
See also ROW FILTER
clause.
Exemplos de filtro de linha
Este exemplo cria uma função SQL definida pelo usuário que se aplica aos membros do grupo admin
na região US
.
Quando esta função de exemplo é aplicada à tabela sales
, os membros do grupo admin
podem acessar todos os registros na tabela. Se a função for chamada por um não administrador, a condição RETURN_IF
falhará e a expressão region='US'
será avaliada, filtrando a tabela para mostrar apenas registros na região US
.
CREATE FUNCTION us_filter(region STRING)
RETURN IF(IS_ACCOUNT_GROUP_MEMBER('admin'), true, region='US');
Aplicar a função a uma tabela como um filtro de linha. Consultas subsequentes da tabela sales
retornam um subconjunto de linhas.
CREATE TABLE sales (region STRING, id INT);
ALTER TABLE sales SET ROW FILTER us_filter ON (region);
Desativar o filtro de linha. Em seguida, consultas futuras de usuários da tabela sales
retornam todas as linhas na tabela.
ALTER TABLE sales DROP ROW FILTER;
Crie uma tabela com a função aplicada como filtro de linha como parte da instrução CREATE TABLE
. Em seguida, consultas futuras da tabela sales
retornam um subconjunto de linhas.
CREATE TABLE sales (region STRING, id INT)
WITH ROW FILTER us_filter ON (region);
Aplique uma máscara de coluna
Para aplicar uma máscara de coluna, crie uma função (UDF) e aplique-a a uma coluna da tabela.
O senhor pode aplicar uma máscara de coluna usando o Catalog Explorer ou SQL comando. As instruções do Catalog Explorer pressupõem que o senhor já criou uma função e a registrou no Unity Catalog. As instruções SQL incluem exemplos de como criar uma função de máscara de coluna e aplicá-la a uma coluna de tabela.
- Catalog Explorer
- SQL
- In your Databricks workspace, click
Catalog.
- Browse or search for the table.
- On the Overview tab, find the row you want to apply the column mask to and click the
Mask edit icon.
- On the Add column mask dialog, select the catalog and schema that contain the filter function, then select the function.
- On the expanded dialog, view the function definition. If the function includes any parameters in addition to the column being masked, select the table columns in which you want to cast those additional function parameters.
- Click Add.
To remove the column mask from the table, click fx Column mask in the table row and click Remove.
To create a column mask and add it to an existing table column, use CREATE FUNCTION
and apply the masking function using ALTER TABLE
. You can also apply a function when you create a table using CREATE TABLE
.
You use SET MASK
to apply the masking function. Within the MASK
clause, you can use any of the Databricks built-in runtime functions or call other user-defined functions. Common use cases include inspecting the identity of the invoking user running the function by using current_user( )
or getting the groups they are a member of using is_account_group_member( )
. For details, see Column mask
clause and Built-in functions.
-
Create a column mask:
SQLCREATE FUNCTION <function_name> (<parameter_name> <parameter_type>, ...)
RETURN {expression with the same type as the first parameter}; -
Apply the column mask to a column in an existing table:
SQLALTER TABLE <table_name> ALTER COLUMN <col_name> SET MASK <mask_func_name> USING COLUMNS <additional_columns>;
Additional syntax examples:
-
Apply the column mask to a column in an existing table using a constant literal that matches a function parameter:
SQLALTER TABLE <table_name> ALTER COLUMN <col_name> SET MASK <mask_func_name> USING COLUMNS (<constant_name>, ...);
-
Remove a column mask from a column in a table:
SQLALTER TABLE <table_name> ALTER COLUMN <column where mask is applied> DROP MASK;
-
Modify a column mask, either
DROP
the existing function or useCREATE OR REPLACE TABLE
. -
Delete a column mask:
SQLALTER TABLE <table_name> ALTER COLUMN <column where mask is applied> DROP MASK;
DROP FUNCTION <function_name>;
You must perform the ALTER TABLE
command before dropping the function or the table will be in an inaccessible state.
If the table becomes inaccessible in this way, alter the table and drop the orphaned mask reference using ALTER TABLE <table_name> ALTER COLUMN <column where mask is applied> DROP MASK;
.
Exemplos de máscaras de coluna
Neste exemplo, você cria uma função definida pelo usuário que mascara a coluna ssn
para que somente usuários que são membros do grupo HumanResourceDept
possam visualizar valores nessa coluna.
CREATE FUNCTION ssn_mask(ssn STRING)
RETURN CASE WHEN is_account_group_member('HumanResourceDept') THEN ssn ELSE '***-**-****' END;
Aplique a nova função a uma tabela como uma máscara de coluna. Você pode adicionar a máscara de coluna ao criar a tabela ou posteriormente.
--Create the `users` table and apply the column mask in a single step:
CREATE TABLE users (
name STRING,
ssn STRING MASK ssn_mask);
--Create the `users` table and apply the column mask after:
CREATE TABLE users
(name STRING, ssn STRING);
ALTER TABLE users ALTER COLUMN ssn SET MASK ssn_mask;
As consultas nessa tabela agora retornam valores de coluna ssn
mascarados quando o usuário que consulta não é membro do grupo HumanResourceDept
:
SELECT * FROM users;
James ***-**-****
Para desativar a máscara de coluna para que as consultas retornem os valores originais na coluna ssn
:
ALTER TABLE users ALTER COLUMN ssn DROP MASK;
Use tabelas de mapeamento para criar uma lista de controle de acesso
Para obter segurança em nível de linha, considere definir uma tabela de mapeamento (ou lista de controle de acesso). Uma tabela de mapeamento abrangente codifica quais linhas de dados na tabela original podem ser acessadas por determinados usuários ou grupos. As tabelas de mapeamento são úteis porque oferecem uma integração simples com suas tabelas de fatos por meio de junção direta.
Essa metodologia aborda muitos casos de uso que incluem requisitos personalizados. Os exemplos incluem:
- Impor restrições com base no usuário conectado e, ao mesmo tempo, acomodar regras diferentes para grupos de usuários específicos.
- Criar hierarquias complexas, como estruturas organizacionais, que exigem conjuntos diversos de regras.
- Replicação de modelos de segurança complexos de sistemas de origem externa.
Ao adotar tabelas de mapeamento, você pode realizar esses cenários desafiadores e garantir implementações robustas de segurança em nível de linha e coluna.
Exemplos de tabelas de mapeamento
Use uma tabela de mapeamento para verificar se o usuário atual está em uma lista:
USE CATALOG main;
Criar uma nova tabela de mapeamento:
DROP TABLE IF EXISTS valid_users;
CREATE TABLE valid_users(username string);
INSERT INTO valid_users
VALUES
('fred@databricks.com'),
('barney@databricks.com');
Criar um novo filtro:
Todos os filtros são executados com os direitos do definidor, exceto as funções que verificam o contexto do usuário (por exemplo, as funções CURRENT_USER
e IS_ACCOUNT_GROUP_MEMBER
) que são executadas como invocador.
Neste exemplo, a função verifica se o usuário atual está na tabela valid_users
. Se o usuário for encontrado, a função retornará true.
DROP FUNCTION IF EXISTS row_filter;
CREATE FUNCTION row_filter()
RETURN EXISTS(
SELECT 1 FROM valid_users v
WHERE v.username = CURRENT_USER()
);
O exemplo abaixo aplica o filtro de linha durante a criação da tabela. Você também pode adicionar o filtro posteriormente usando uma instrução ALTER TABLE
. Ao aplicá-la a uma tabela inteira, use a sintaxe ON ()
. Para uma linha específica, use ON (row);
.
DROP TABLE IF EXISTS data_table;
CREATE TABLE data_table
(x INT, y INT, z INT)
WITH ROW FILTER row_filter ON ();
INSERT INTO data_table VALUES
(1, 2, 3),
(4, 5, 6),
(7, 8, 9);
Selecione os dados da tabela. Isso só deve retornar dados se o usuário estiver na tabela valid_users
.
SELECT * FROM data_table;
Crie uma tabela de mapeamento com contas que sempre devem ter acesso para visualizar todas as linhas na tabela, independentemente dos valores das colunas:
CREATE TABLE valid_accounts(account string);
INSERT INTO valid_accounts
VALUES
('admin'),
('cstaff');
Agora, crie um UDF SQL que retorne true
se os valores de todas as colunas da linha forem menores que cinco ou se o usuário que o invocou for membro da tabela de mapeamento acima.
CREATE FUNCTION row_filter_small_values (x INT, y INT, z INT)
RETURN (x < 5 AND y < 5 AND z < 5)
OR EXISTS(
SELECT 1 FROM valid_accounts v
WHERE IS_ACCOUNT_GROUP_MEMBER(v.account));
Finalmente, aplique o SQL UDF à tabela como um filtro de linha:
ALTER TABLE data_table SET ROW FILTER row_filter_small_values ON (x, y, z);
Suporte e limitações
Filtros de linha e máscaras de coluna não são suportados por todas as funcionalidades do Databricks ou em todos os recursos de computação. Esta seção lista as funcionalidades e limitações suportadas.
Recursos e formatos suportados
Essa lista de funcionalidades suportadas não é exaustiva. Alguns itens estão listados porque não eram compatíveis durante o pré-lançamento público.
-
Há suporte para Databricks SQL e notebooks Databricks para cargas de trabalho SQL.
-
Há suporte para o comando DML por usuários com privilégios
MODIFY
. Filtros e máscaras são aplicados aos dados lidos pelas instruçõesUPDATE
eDELETE
e não são aplicados aos dados gravados (incluindoINSERT
). -
Formatos de dados compatíveis:
- Delta e Parquet para tabelas gerenciadas e externas.
- Vários outros formatos de dados para tabelas externas registradas em Unity Catalog usando a lakehouse Federation.
-
Os parâmetros de política podem incluir expressões constantes (strings, números, intervalos, booleanos, nulos).
-
As UDFs de SQL, Python e Scala são suportadas como funções de filtro de linha ou máscara de coluna se estiverem registradas no Unity Catalog. As UDFs de Python e Scala devem ser agrupadas em uma UDF de SQL.
-
Você pode criar exibições em tabelas que fazem referência a máscaras de coluna ou filtros de linha, mas não pode adicionar máscaras de coluna ou filtros de linha a uma exibição.
-
Os feeds de dados de alteração do Delta Lake são suportados se o esquema for compatível com os filtros de linha e as máscaras de coluna que se aplicam à tabela de destino.
-
Tabelas externas são suportadas.
-
A amostragem de tabela é suportada.
-
MERGE
as declarações são suportadas quando tabelas de origem, tabelas de destino ou ambas usam filtros de linha e máscaras de coluna. Isso inclui tabelas com funções de filtro de linha que contêm subconsultas simples. As limitações estão listadas na seção a seguir.
Recomendações de desempenho
Os filtros de linha e as máscaras de coluna controlam a visibilidade dos dados, garantindo que os usuários não possam view o conteúdo dos valores das tabelas de base antes das operações de filtragem e máscara. Eles funcionam bem em resposta a consultas em casos de uso comuns. Em aplicativos menos comuns, em que o mecanismo de consulta deve escolher entre otimizar o desempenho da consulta e proteger-se contra o vazamento de informações dos valores filtrados/mascarados, ele sempre tomará a decisão segura às custas de algum impacto no desempenho da consulta. Para minimizar esse impacto no desempenho, aplique as seguintes recomendações:
- Use funções de política simples: as funções de política com menos expressões geralmente têm um desempenho melhor do que expressões mais complexas. Evite usar tabelas de mapeamento e subconsultas de expressão em favor de funções CASE simples.
- Reduzir o número de argumentos de função: O Databricks não pode otimizar as referências de coluna à tabela de origem resultantes de argumentos de função de política, mesmo que essas colunas não sejam usadas na consulta. Use funções de política com menos argumentos, pois as consultas dessas tabelas terão um desempenho melhor.
- Evite adicionar filtros de linha com muitos conjuntos AND: como cada tabela só suporta a adição de no máximo um filtro de linha, uma abordagem comum é combinar várias funções de política desejadas com
AND
. No entanto, para cada conjunto, aumentam as chances de que o(s) conjunto(s) inclua(m) componentes mencionados em outra parte desta tabela que possam afetar o desempenho (como tabelas de mapeamento). Use menos conjuntos para melhorar o desempenho. - Use expressões determinísticas que não podem gerar erros nas políticas de tabela e nas consultas dessas tabelas: Algumas expressões podem gerar erros se as entradas fornecidas não forem válidas, como a divisão ANSI. Nesses casos, o compilador SQL não deve empurrar as operações com essas expressões (como filtros) muito para baixo no plano de consulta para evitar a possibilidade de erros como "divisão por zero" que revelam informações sobre valores antes de filtrar e/ou mascarar operações. Use expressões determinísticas que nunca geram erros, como
try_divide
neste exemplo. - Execute consultas de teste em sua tabela para avaliar o desempenho: crie consultas realistas que representem a carga de trabalho esperada para a sua tabela com filtros de linha e/ou máscaras de coluna e meça o desempenho. Faça pequenas modificações nas funções da política e observe seus efeitos até alcançar um bom equilíbrio entre desempenho e expressividade da lógica de filtragem e mascaramento.
Limitações
- As versões do Databricks Runtime abaixo da 12.2 LTS não oferecem suporte a filtros de linha nem a máscaras de coluna. Esses tempos de execução falham com segurança, o que significa que se você tentar acessar tabelas de versões não suportadas desses tempos de execução, nenhum dado será retornado.
- O Delta Sharing não funciona com máscaras de segurança ou coluna em nível de linha.
- Você não pode aplicar máscaras de segurança ou de coluna no nível da linha a uma exibição.
- A viagem do tempo não funciona com segurança em nível de linha ou máscaras de coluna.
- Não há suporte para o acesso baseado em caminho a arquivos em tabelas com políticas.
- Não há suporte para políticas de filtro de linha nem máscara de coluna com dependências circulares em relação às políticas originais.
- Clones profundos e rasos não são suportados.
MERGE
as instruções não oferecem suporte a tabelas com políticas de filtro de linha ou máscara de coluna que contenham aninhamento, agregações, janelas, limites ou funções não determinísticas.- As APIs do Delta Lake não são suportadas.
Limitação do modo de acesso dedicado
O senhor não pode acessar uma tabela com filtros de linha ou máscaras de coluna a partir de um acesso dedicado compute recurso em Databricks Runtime 15.3 ou abaixo. O senhor pode usar o modo de acesso dedicado em Databricks Runtime 15.4 LTS ou acima se o seu workspace estiver habilitado para serverless compute . Para obter mais informações, consulte Controle de acesso refinado em compute dedicado (anteriormente, usuário único compute).