Conceitos básicos para controle de acesso baseado em atributos (ABAC)

O controle de acesso baseado em atributos (ABAC) é um modelo de controle de acesso que usa tags governadas e políticas para conceder permissões com base em atributos de objeto, em vez de concessões por objeto. Esta página define os blocos de construção: tags governadas, os quatro tipos de política ABAC (filtro de linha, máscara de coluna, políticas GRANT e DENY (Beta)), as permissões necessárias para configurá-las e a separação de funções que o ABAC permite entre as equipes.

Consulte para obter Unity Catalog uma visão geral de todos os tópicos sobre ABAC, incluindo tutoriais, gerenciamento de políticas, práticas recomendadas e limitações.

O que é ABAC?

O controle de acesso baseado em atributos (ABAC) é um modelo de controle de acesso dinâmico em que as decisões de acesso são baseadas em políticas avaliadas em relação a atributos associados a objetos protegíveis. No Unity Catalog, esses atributos são representados por meio de tags gerenciadas. Essas tags regulamentadas são usadas em condições de política para corresponder a objetos de dados dentro de um escopo específico, como um catálogo ou um esquema. Isso permite que uma única política seja aplicada automaticamente a vários objetos de dados que atendam às suas condições.

Por exemplo, uma política ABAC pode mascarar todas as tags de coluna PII para tabelas dentro de tags de esquema HR. À medida que novos objetos de dados e tags são criados, a política é aplicada automaticamente, sem a necessidade de definições de política separadas para cada objeto.

O ABAC oferece suporte à segurança em nível de linha e coluna por meio de políticas de filtro de linha e políticas de máscara de coluna em tabelas, visualizações materializadas e tabelas de transmissão. Políticas de filtro de linha restringem quais linhas o usuário pode ver. Políticas de mascaramento de coluna controlam como os valores de coluna são apresentados aos usuários. Para uma comparação com filtros de linha e máscaras de coluna em nível de tabela, consulte Quando usar ABAC vs. filtros de linha e máscaras de coluna em nível de tabela.

O ABAC também oferece suporte a concessões dinâmicas de privilégios por meio de políticas de GRANT , em tipos protegíveis compatíveis. Consulte políticas de GRANT ABAC.

O ABAC também pode negar privilégios explicitamente por meio de políticas DENY (Beta), atualmente com escopo para o privilégio MANAGE ACCESS CONTROL. Uma política DENY sempre tem precedência sobre qualquer concessão. Consulte políticas ABAC DENY (Beta).

tagsregulamentadas

No Unity Catalog, os atributos são implementados como tags governadas. Tags governadas são pares key-value definidos no nível da account e aplicadas a objetos protegíveis do Unity Catalog, como catálogos, esquemas, tabelas, colunas, modelos e volumes, além de objetos de workspace. Eles representam características como sensibilidade, classificação ou domínio de negócios.

Por padrão, os itens protegíveis herdam tags do catálogo ou esquema pai. Você pode substituir tags herdadas em todos os níveis, exceto no nível da coluna: tags de coluna não herdam da tabela principal e devem ser aplicadas diretamente.

tags governadas podem ser referenciadas nas condições da política usando funções integradas como has_tag() e has_tag_value(), que verificam se uma determinada tag está presente no objeto de dados de destino, seja diretamente ou por meio de herança tag .

tags controladas são definidas no nível account . Isso significa que você pode usar a mesma taxonomia tag em todos os seus dados em uma account, inclusive em vários metastores.

Para obter mais informações, consulte tagsregidas e Aplicar tags a objetos protegíveis Unity Catalog.

Políticas

As políticas são associadas a objetos protegíveis no Unity Catalog para definir regras de controle de acesso com base nas condições tag . Segue abaixo um exemplo:

SQL

CREATE FUNCTION mask_pii(val STRING) RETURNS STRING
    RETURN '***';

CREATE POLICY mask_pii_for_hr
ON CATALOG catalog_a
COLUMN MASK mask_pii
TO `account users` EXCEPT `HR admins`
FOR TABLES
WHEN has_tag('HR')
MATCH COLUMNS has_tag('PII') AS pii_col
ON COLUMN pii_col;

Cada política especifica:

• Escopo : O objeto protegível ao qual a política está anexada, especificado pela cláusula ON . Anexar uma política a um objeto protegível significa que as condições da política são avaliadas para todos os objetos do tipo especificado na cláusula FOR , nesse objeto e em todos os seus descendentes.
  • For row filter and column mask policies, supported policy scopes are CATALOG, SCHEMA, or TABLE. For GRANT policies, supported policy scopes are CATALOG and SCHEMA. You can also attach any policy type at the METASTORE level so it applies across every catalog in the metastore. See Metastore-level ABAC policies (Beta).
  • Tabelas, incluindo tabelas de transmissão e views materializadas, são o único tipo protegível suportado para políticas de filtro de linha e máscara de coluna, especificadas usando a cláusula FOR TABLES. As políticas GRANT se aplicam a modelos, serviços de modelo, serviços de provedor de modelos, serviços MCP e serviços de agente, e usam a cláusula GRANT <privilege> FOR <securable_type>. Para a lista completa de tipos protegíveis e privilégios suportados, consulte Tipos protegíveis e privilégios suportados.
  • Uma política anexada no metastore é avaliada em relação a todos os objetos protegíveis do tipo especificado na cláusula FOR em todos os catálogos no metastore. Uma política anexada a um catálogo é avaliada em relação a todos os objetos protegíveis desse tipo dentro desse catálogo. Uma política anexada a um esquema é avaliada em relação a todos os objetos protegíveis desse tipo dentro desse esquema. Uma política anexada a uma tabela é avaliada apenas em relação a essa tabela.

nota

A Databricks recomenda anexar políticas no nível mais alto aplicável, geralmente o catálogo, para maximizar a eficiência da governança. Consulte as Melhores práticas para políticas ABAC.

• Principais : A quem a política se aplica e quem está isento. A cláusula TO especifica os usuários, grupos ou entidade de serviço sujeitos à política. A cláusula opcional EXCEPT exclui princípios específicos desta política.
• Ações : se a política aplica um filtro de linha, uma máscara de coluna ou uma concessão de privilégio. As políticas de filtro de linha e máscara de coluna usam uma função definida pelo usuário (UDF) para implementar a lógica de filtragem ou mascaramento. As políticas de GRANT não usam UDFs. Consulte Tipos de política.
• Condições : expressões baseadas em tags que determinam quais tabelas ou colunas a política visa. Consulte Condições e funções integradas.

As políticas são criadas e gerenciadas por meio da interface do usuário ou programaticamente com instruçõesSQL, como CREATE POLICY, DROP POLICY, SHOW POLICIES ou DESCRIBE POLICY, APIsREST, SDKsDatabricks ou Terraform. Consulte Criar e gerenciar políticas ABAC para obter a sintaxe completa e exemplos.

Tipos de política

O ABAC oferece suporte a quatro tipos de política: políticas de filtro de linha, políticas de máscara de coluna, políticas GRANT e políticas DENY (Beta). As políticas de filtro de linha e máscara de coluna exigem UDFs para implementar a lógica de filtragem ou mascaramento. As políticas GRANT e DENY não usam UDFs e, em vez disso, concedem ou negam privilégios quando sua condição baseada em tag corresponde aos atributos do objeto de destino.

Políticas de filtro de linha

As políticas de filtro de linhas restringem quais linhas um usuário pode ver em uma tabela com base em valores em colunas identificadas por tags que correspondem às Condições e funções integradas. A política faz referência a uma UDF (função definida pelo usuário) que avalia cada linha. As linhas em que a função retorna FALSE são excluídas dos resultados da consulta. Os argumentos são passados para a UDF através da cláusula USING COLUMNS .

Exemplo de caso de uso: Para um catálogo de vendas, garantir que a equipe EMEA veja apenas registros de vendas da EMEA em todas as tabelas que têm uma coluna tags region.

SQL

CREATE FUNCTION filter_by_region(region STRING, allowed STRING) RETURNS BOOLEAN
    RETURN region = allowed;

CREATE POLICY regional_access_emea
ON CATALOG sales
ROW FILTER filter_by_region
TO `emea team`
FOR TABLES
MATCH COLUMNS has_tag('region') AS rgn
USING COLUMNS (rgn, 'EMEA');

Políticas de máscara de coluna

As políticas de máscara de coluna controlam quais valores um usuário vê para colunas específicas identificadas por tags que correspondem às Condições e funções integradas. A política faz referência a uma UDF (função definida pelo usuário) que recebe o valor da coluna como entrada e retorna o valor original ou uma versão mascarada. O valor da coluna mascarada é vinculado automaticamente como o primeiro argumento da cláusula ON COLUMN , e argumentos adicionais podem ser passados através de USING COLUMNS. O tipo de retorno deve corresponder ou ser convertível para o tipo de dados da coluna.

Exemplo de caso de uso: Mascarar as tags das colunas do SSN com pii : ssn para que os usuários vejam ***-**-XXXX (apenas os últimos quatro dígitos), a menos que pertençam a um grupo compliance isento da política.

SQL

CREATE FUNCTION mask_ssn(ssn STRING, show_last INT) RETURNS STRING
    RETURN CONCAT('***-**-', RIGHT(ssn, show_last));

CREATE POLICY mask_ssn_columns
ON CATALOG hr_catalog
COLUMN MASK mask_ssn
TO `account users` EXCEPT `compliance team`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'ssn') AS ssn_col
ON COLUMN ssn_col
USING COLUMNS (4);

A cláusula USING COLUMNS passa argumentos para a UDF. Ele aceita aliases para colunas que correspondem a uma expressão baseada em tags, ou valores constantes (strings entre aspas, literais numéricos, valores booleanos (TRUE/FALSE), ou NULL), fornecidos na ordem que a função os espera. Ele também aceita funções de introspecção de tag, que extraem o valor de uma tag no tempo de query e o passam para a UDF. Para políticas de máscara de coluna, estes são argumentos adicionais além da coluna mascarada (que é vinculada automaticamente de ON COLUMN). Isso permite que um único UDF seja reutilizado em políticas com parâmetros diferentes.

Recomenda-se o uso de UDFs SQL para melhor desempenho. As UDFs em Python registradas no Unity Catalog também são suportadas, embora o otimizador de consultas não consiga incorporá-las ou otimizá-las da mesma forma que faz com as UDFs em SQL. Consulte a seção Considerações sobre desempenho para obter orientações sobre a seleção da linguagem UDF.

Políticas GRANT

As políticas GRANT concedem dinamicamente um privilégio do Unity Catalog quando sua condição baseada em tags corresponde às tags de um objeto protegível. Cada vez que um usuário tenta acessar um objeto protegível, o Unity Catalog identifica todas as políticas GRANT cujo escopo abrange o objeto, verifica se o usuário está na lista TO e não na lista EXCEPT, e avalia a condição WHEN da política em relação às tags no protegível, incluindo tags herdadas. Se a política se aplicar, o Unity Catalog concede o privilégio. Políticas GRANT usam o mesmo modelo de avaliação que as políticas de filtro de linha e máscara de coluna, exceto por não usarem UDFs. A condição é expressa em linha na definição de política.

Os privilégios efetivos em um objeto são a união de concessões diretas e quaisquer políticas de GRANT aplicáveis. O principal possui o privilégio se uma política de GRANT em vigor se aplicar a esse principal ou se um GRANT GRANT direto do mesmo privilégio for aplicado. Políticas GRANT apenas concedem acesso. Não é possível revogar o acesso que foi concedido diretamente.

Políticas DENY (Beta)

info

Beta

As políticas DENY estão em Beta, atualmente limitadas ao privilégio MANAGE ACCESS CONTROL. Consulte Políticas ABAC DENY (Beta) para sintaxe, exemplos e limitações da versão Beta.

As políticas DENY negam explicitamente um privilégio do Unity Catalog a principais nos objetos protegíveis em seu escopo e sempre têm precedência sobre qualquer concessão do mesmo privilégio, seja direta, herdada ou mantida por meio da propriedade do objeto. Assim como as políticas GRANT, as políticas DENY são anexadas no nível do catálogo ou esquema, usam condições baseadas em tag e não usam UDFs. Quando várias políticas DENY se aplicam ao mesmo principal, seus efeitos são combinados e nenhuma concessão pode substituir uma DENY ativa. Consulte políticas ABAC DENY (Beta).

Condições e funções integradas

As condições são expressões baseadas em tagque determinam quais tabelas e colunas uma política abrange em seu escopo.

• Condições de tabela (cláusula WHEN ): expressões Boolean que correspondem a tabelas com base em suas tags. Se omitido, o padrão é TRUE, o que significa que a política se aplica a todas as tabelas no escopo.
• Condições de coluna (cláusula MATCH COLUMNS ): Uma ou mais expressões booleanas separadas por vírgulas que identificam quais colunas a política visa. Cada expressão pode ser uma única função integrada como has_tag('pii') ou uma combinação usando operadores lógicos como has_tag_value('pii', 'ssn') AND has_tag('sensitive'). A cada expressão pode ser atribuído um alias (especificado após AS) que pode ser referenciado nas cláusulas ON COLUMN e USING COLUMNS . Uma política pode incluir expressões de até 3 colunas, e todas devem corresponder para que a política seja aplicada.

Ambos os tipos de cláusula utilizam as seguintes funções integradas, avaliadas pelo Unity Catalog em relação aos metadados protegíveis:

Função	Contexto	Descrição
has_tag('tag_key')	Tabelas e colunas	Retorna verdadeiro se o recurso possuir a tag especificada. Nas condições da tabela (WHEN), verifica as tags definidas diretamente na tabela ou herdadas de um catálogo ou esquema pai. Nas condições de coluna (MATCH COLUMNS), verifica apenas as tags definidas diretamente na coluna — não corresponde às tags da tabela.
has_tag_value('tag_key', 'tag_value')	Tabelas e colunas	Retorna verdadeiro se o recurso tiver a tag especificada com o valor especificado. Mesmo comportamento de contexto que has_tag().

Função	Contexto	Descrição
has_tag('tag_key')	Tabelas e colunas	Retorna verdadeiro se o recurso possuir a tag especificada. Nas condições da tabela (WHEN), verifica as tags definidas diretamente na tabela ou herdadas de um catálogo ou esquema pai. Nas condições de coluna (MATCH COLUMNS), verifica apenas as tags definidas diretamente na coluna — não corresponde às tags da tabela.
has_tag_value('tag_key', 'tag_value')	Tabelas e colunas	Retorna verdadeiro se o recurso tiver a tag especificada com o valor especificado. Mesmo comportamento de contexto que has_tag().

Para corresponder aos atributos do usuário que executa a query em vez de tags de recurso, consulte Funções de atributo de identidade.

Para corresponder ao contexto de uma solicitação, como o aplicativo chamador, consulte Funções de atributo de contexto.

As tags não se propagam das tabelas para as colunas. O uso de has_tag() em uma cláusula MATCH COLUMNS corresponde apenas a tags de nível de coluna, não a tags na tabela pai ou em seus ancestrais.

nota

As funções has_tag e has_tag_value usam nomes snake_case. As formas camelCase mais antigas (hasTag, hasTagValue) continuam a funcionar, mas não são recomendadas. A Databricks planeja descontinuar o uso de formulários em camelCase na criação de novas políticas. As políticas existentes não serão afetadas.

Exemplo: usando condições de duas colunas. Um esquema customers possui tabelas com uma coluna email com tags pii : email e uma coluna de consentimento com tags consent_to_contact. A política oculta os endereços email , a menos que o cliente tenha consentido em ser contatado. Utiliza duas condições de coluna:

1. has_tag_value('pii', 'email') Identifica a coluna que contém endereços email (a coluna a ser mascarada).
2. has_tag('consent_to_contact') Identifica a coluna que contém informações de consentimento (usadas pela UDF para decidir se deve ou não mascarar os dados).

SQL

CREATE FUNCTION mask_email_by_consent(email STRING, consent BOOLEAN)
RETURNS STRING
RETURN CASE
  WHEN consent = true THEN email
  ELSE '****@****.***'
END;

CREATE POLICY mask_email_with_consent
ON SCHEMA customers
COLUMN MASK mask_email_by_consent
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'email') AS m,
  has_tag('consent_to_contact') AS c
ON COLUMN m
USING COLUMNS (c);

Esta política aplica-se apenas a tabelas que têm uma coluna com a etiqueta pii : email e uma coluna com a etiqueta consent_to_contact. Se uma tabela não tiver colunas que correspondam a ambas as condições, a política não se aplica e os dados são retornados sem máscara.

Funções de atributo de identidade (Beta)

info

Beta

Os atributos de identidade em políticas ABAC estão em Beta. Para usá-los, um administrador account deve habilitar a pré-visualização Identity Attributes in ABAC Policies na página Previews do console da account. Consulte Gerenciar prévias em nível de account.

As funções de atributo de identidade avaliam propriedades do usuário que executa a query, como departamento, país ou Job role. Esses atributos podem ser provisionados a partir do seu provedor de identidade e referenciados diretamente nas condições de política. Isso permite que você expresse condições mais flexíveis sem criar grupos separados para cada combinação de propriedades de identidade. Quando as informações de identidade mudam no seu provedor de identidade, as políticas usam os valores de atributo atualizados, assim como usam a associação de grupo atualizada.

atenção

Não use atributos de identidade para armazenar informações confidenciais.

Função	Contexto	Descrição
has_identity_attribute_value('attribute_key', 'value')	Máscara de coluna (WHEN)	Retorna true quando value é um dos valores do atributo de identidade attribute_key do usuário que realiza a consulta.
has_identity_attribute_tag_match('attribute_key', 'tag_key')	Máscara de coluna (WHEN)	Retorna true quando qualquer valor do atributo de identidade attribute_key do usuário que faz a query corresponde ao valor da tag controlada tag_key no recurso. Retorna false se a tag não tiver valor.

Função	Contexto	Descrição
has_identity_attribute_value('attribute_key', 'value')	Máscara de coluna (WHEN)	Retorna true quando value é um dos valores do atributo de identidade attribute_key do usuário que realiza a consulta.
has_identity_attribute_tag_match('attribute_key', 'tag_key')	Máscara de coluna (WHEN)	Retorna true quando qualquer valor do atributo de identidade attribute_key do usuário que faz a query corresponde ao valor da tag controlada tag_key no recurso. Retorna false se a tag não tiver valor.

Essas funções são suportadas na cláusula WHEN de políticas de máscara de coluna.

Considere o seguinte comportamento ao escrever políticas que os utilizam:

• Um atributo ausente é resolvido como false. Se o usuário não tiver valor para o atributo, não tiver nenhum atributo ou se o atributo não existir, a função retornará false em vez de gerar um erro. Formule as condições para que este resultado false restrinja o acesso. Consulte Condições de atributo de identidade.
• As keys e os valores de atributo diferenciam maiúsculas de minúsculas e são comparados exatamente: Finance e finance não correspondem.
• As alterações de atributo não são instantâneas. As alterações no seu provedor de identidade não são sincronizadas com o Databricks imediatamente. Consulte atributos de identidade para obter mais informações.

Para saber quais atributos o Databricks suporta e como eles são provisionados, consulte atributos de identidade. Para obter exemplos de como usar atributos de identidade em políticas, consulte Mascarar uma coluna com base nos atributos do usuário que faz a query.

Funções de atributo de contexto (Beta)

info

Beta

Os atributos de contexto em políticas ABAC estão em Beta. Para usá-los, um administrador de account deve habilitar a prévia UC ABAC Context Attributes na página Previews do console da account. Consulte Gerenciar prévias em nível de account.

Atributos de contexto são usados para restringir o acesso a dados para solicitações feitas em nome de um usuário por meio de um aplicativo OAuth. Essa configuração pode ser usada para restringir o acesso de agentes a dados quando eles agem em nome de um usuário, mantendo esses mesmos dados acessíveis se o usuário fizer uma query diretamente no workspace.

Ele abrange qualquer aplicativo OAuth, seja um aplicativo integrado como a CLI do Databricks ou um aplicativo OAuth personalizado. Há dois atributos de contexto diferentes:

• request.is_on_behalf_of: a string 'true' ou 'false'. Indica se a solicitação é executada em nome de um usuário por meio de um aplicativo OAuth. Qualquer solicitação de um aplicativo OAuth tem este valor definido como 'true'.
• request.client_ido cliente OAuth. Isso pode ser usado para direcionar um cliente OAuth específico, seja um aplicativo OAuth integrado (por exemplo, databricks-cli) ou um aplicativo OAuth personalizado. O client_id pode ser observado em Settings > App Connections no console de account. Para o Databricks Apps, ele também pode ser observado na página de detalhes de Autorização do aplicativo, em ID de cliente do aplicativo OAuth2 . Ou ele pode ser consultado a partir do campo identity_metadata.acting_resource nos logs de auditoria.

Estes atributos não são modificáveis pelo usuário e são fornecidos explicitamente pelo sistema. Um chamador os influencia apenas pela forma como se autentica. Estes atributos podem ser usados para identificar agentes externos, não para o Genie.

Atributos de contexto podem ser usados por meio das seguintes funções:

Função	Contexto	Descrição
has_context_attribute('key')	Máscara de coluna & Filtro de linha (WHEN)	Retorna true se o contexto tiver o atributo especificado.
has_context_attribute_value('key', 'attribute_value')	Máscara de coluna & Filtro de linha (WHEN)	Retorna true se o contexto tiver o valor de atributo especificado.

Função	Contexto	Descrição
has_context_attribute('key')	Máscara de coluna & Filtro de linha (WHEN)	Retorna true se o contexto tiver o atributo especificado.
has_context_attribute_value('key', 'attribute_value')	Máscara de coluna & Filtro de linha (WHEN)	Retorna true se o contexto tiver o valor de atributo especificado.

As chaves de atributo não diferenciam maiúsculas de minúsculas, e os valores diferenciam.

Para saber como usar esses atributos de contexto para controlar o acesso de agentes externos, consulte Restringir o acesso de agentes externos que agem em nome de um usuário.

Funções definidas pelo usuário (UDFs)

Políticas de filtro de linha e máscara de coluna usam funções definidas pelo usuário (UDFs) para implementar sua lógica de filtragem ou mascaramento. Consulte Funções definidas pelo usuário (UDFs) SQL e Python no Unity Catalog para saber como criar e gerenciar UDFs, e Padrões comuns para filtragem de linha e mascaramento de coluna para exemplos.

Funções de introspecção de tag

As funções de introspecção de tag extraem o valor de uma tag governada e o passam para um UDF por meio da cláusula USING COLUMNS. Como o UDF recebe o valor da tag como um argumento, uma única política e UDF podem manipular vários valores de tag, em vez de exigir uma política separada para cada valor de tag. Essas funções estão disponíveis apenas para políticas de filtro de linha e máscara de coluna, porque as políticas GRANT não usam UDFs.

A criação de uma política que usa essas funções requer o Databricks Runtime 18 LTS ou acima. Este requisito se aplica apenas à criação de políticas, não à consulta das tabelas governadas.

nota

O Databricks Runtime 18 é mais recente que o Databricks Runtime 18.0, 18.1 e 18.2. Recursos que antes teriam sido lançados como uma versão numerada posterior, agora são lançados como atualizações datadas para o Databricks Runtime 18. Para obter detalhes, consulte Sobre as notas sobre a versão unificadas.

No momento da query, o Unity Catalog avalia essas funções em relação às tags na tabela ou nas colunas que a política corresponde: get_tag_value() lê da tabela que satisfaz a condição WHEN, e get_column_tag_value() lê das colunas identificadas por MATCH COLUMNS. Eles podem aparecer apenas na cláusula USING COLUMNS, não nas condições WHEN ou MATCH COLUMNS.

Função	Contexto	Descrição
get_tag_value('tag_key')	tabelas	Retorna o valor da tag especificada aplicada à tabela que está sendo acessada, ou herdada de seu esquema ou catálogo pai. Retorna NULL se a tag não for aplicada à tabela ou a qualquer ancestral, ou se não tiver valor.
get_column_tag_value(column_alias, 'tag_key')	Colunas	Retorna o valor da tag especificada aplicada diretamente a uma coluna correspondente. Ao contrário de get_tag_value(), esta função não consulta tags na tabela pai, porque as tags de coluna não herdam. O primeiro argumento é um alias definido na cláusula MATCH COLUMNS. Retorna NULL se a tag não for aplicada à coluna ou não tiver valor.

Função	Contexto	Descrição
get_tag_value('tag_key')	tabelas	Retorna o valor da tag especificada aplicada à tabela que está sendo acessada, ou herdada de seu esquema ou catálogo pai. Retorna NULL se a tag não for aplicada à tabela ou a qualquer ancestral, ou se não tiver valor.
get_column_tag_value(column_alias, 'tag_key')	Colunas	Retorna o valor da tag especificada aplicada diretamente a uma coluna correspondente. Ao contrário de get_tag_value(), esta função não consulta tags na tabela pai, porque as tags de coluna não herdam. O primeiro argumento é um alias definido na cláusula MATCH COLUMNS. Retorna NULL se a tag não for aplicada à coluna ou não tiver valor.

Ambas as funções aceitam a chave da tag como um literal de string. A tag deve ser uma tag controlada, e get_column_tag_value() deve fazer referência a um alias que exista na cláusula MATCH COLUMNS da política. Se a tag não for controlada ou o alias não for válido, a criação da política falhará. Se uma tags referenciada não for mais controlada quando uma query for execução, as consultas nas tabelas de destino da política falharão em Runtime.

Exemplo: uma política para todos os tipos de PII

Sem introspecção de tag, mascarar cada tipo de informação de identificação pessoal (email, SSN, telefone) requer uma política e UDF separadas para cada valor de tag. Com get_column_tag_value(), uma única política passa o valor da tag pii da coluna correspondente para uma UDF. A UDF Branch nesse valor:

SQL

CREATE FUNCTION mask_pii(col STRING, pii_type STRING)
RETURNS STRING
RETURN CASE
  WHEN pii_type = 'email' THEN regexp_replace(col, '(^[^@]+)', '***')
  WHEN pii_type = 'ssn' THEN '***-**-' || right(col, 4)
  WHEN pii_type = 'phone' THEN '***-***-' || right(col, 4)
  ELSE col
END;

CREATE POLICY mask_all_pii
ON CATALOG main
COLUMN MASK mask_pii
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('pii') AS col
ON COLUMN col
USING COLUMNS (get_column_tag_value(col, 'pii'));

Para cada coluna mascarada, get_column_tag_value(col, 'pii') é resolvido para o valor da tag pii dessa coluna (email, ssn, phone, etc.), e mask_pii aplica a transformação correspondente. Um novo valor de tag exige apenas um novo Branch no UDF, e não uma nova política.

Separação de funções e permissões

A configuração de ABAC envolve vários passos, cada um com seus próprios requisitos de permissão. As organizações podem distribuir essas tarefas entre grupos especializados, dependendo de como optem por separar as funções. Por exemplo, uma organização pode definir uma taxonomia de tags centralmente. Em seguida, os gestores de dados classificam os dados, os administradores de governança elaboram políticas, os criadores de dados criam objetos dentro de escopos governados, e os consumidores de dados acessam os objetos governados.

1. Crie a taxonomia tag . Defina a chave tag governada e seus valores permitidos antes que alguém as aplique ou escreva políticas. Por exemplo, crie uma tag sensitivity com valores controlados (public, internal, confidential, restricted) ou uma tag pii com valores como ssn, email e phone_number. Consulte a seção Padronizar atributos e nomenclatura para obter recomendações sobre convenções de nomenclatura e design de taxonomia.

   • Permissões necessárias: administrador da conta ou um usuário com permissão CREATE para tags no nível account .

2. tag dados ativos. Um gestor de dados, criador de dados ou sistema de classificação de AI aplica tags governadas a objetos protegíveis do Unity Catalog, como catálogos, esquemas, tabelas, colunas, modelos e volumes. Por exemplo, tag as colunas que contêm informações de identificação pessoal com pii : ssn, ou tag um modelo com lifecycle : production. A tag correta é o primeiro o passo essencial para que as políticas ABAC se apliquem.

   • Permissões necessárias: ASSIGN na tag e APPLY TAG no objeto.

atenção

As tags representam um limite de segurança. Se um usuário puder alterar as tags de um ativo de dados, ele poderá alterar quais políticas se aplicam a ele. As organizações devem controlar quem pode aplicar tags e auditar as alterações tag .

3. Criar política. Um administrador de governança cria uma política em um escopo, como um catálogo ou esquema. A política especifica a quem se aplica, que condições avalia e a ação a ser aplicada, como um filtro de linha, uma máscara de coluna ou uma concessão de privilégio.

   • Permissões necessárias: MANAGE permissão ou propriedade do objeto no objeto protegível onde a política está anexada. Para políticas de filtro de linha e de máscara de coluna, também é necessário EXECUTE privilégio na UDF.

4. Criar objetos de dados. Criadores de dados criam objetos seguros, como tabelas, modelos ou volumes, dentro dos escopos aos quais foi concedido acesso. Novos objetos herdam tags de catálogos e esquemas principais. Criadores de dados também têm APPLY TAG automaticamente em objetos que criam, de modo que possam aplicar tags adicionais. Alternativamente, eles podem recorrer à classificação automática de dados para realizar a tag. Se uma organização depende de criadores de dados para marcar seus próprios objetos, ela deve estabelecer práticas claras de marcação. Os criadores de dados não precisam configurar nenhum controle de acesso se as políticas forem definidas em níveis superiores, o que a Databricks recomenda.

   • Permissões necessárias: CREATE TABLE ou outros privilégios de criação relevantes no objeto pai.

5. Acesse objetos regidos. Quando um usuário tenta acessar um objeto protegível dentro do escopo de uma política, o Unity Catalog avalia as políticas aplicáveis automaticamente. Para políticas de filtro de linha e máscara de coluna, o usuário vê dados filtrados ou mascarados se a tabela ou as colunas corresponderem às condições da política e o usuário não estiver isento. Para políticas de GRANT, o usuário ganha o privilégio concedido se as condições corresponderem e o usuário estiver em TO e não em EXCEPT.

   • Permissões necessárias: Para políticas de filtro de linha e máscara de coluna, os usuários devem receber permissões na tabela, como SELECT, por meio de um GRANT de objeto direto. Essas políticas filtram registros ou mascaram colunas para tabelas que o usuário já pode acessar. Elas não concedem permissões por si mesmas. As políticas GRANT concedem o privilégio por si mesmas e unem-se a quaisquer GRANTs diretos no mesmo objeto protegível.

Benefícios do ABAC

• Políticas reutilizáveis baseadas em atributos: Uma única política pode ser aplicada a vários objetos de dados que correspondam às mesmas condições baseadas em atributos, em vez de estar vinculada a um objeto específico.

• Aplicação automática a novos objetos: Quando novos objetos de dados são criados dentro do escopo e marcados com os atributos relevantes, as políticas ABAC existentes são aplicadas sem configuração adicional. As políticas funcionam como concessões futuras, o que significa que os controles de acesso são aplicados automaticamente à medida que novos dados são criados e etiquetados adequadamente.

• Aplicação consistente dentro de um escopo: as políticas anexadas no nível do catálogo ou do esquema são avaliadas dinamicamente em relação aos objetos de dados correspondentes nesse escopo, o que elimina as diferenças na forma como dados semelhantes são filtrados ou mascarados.

• Redução da necessidade de manutenção contínua: as alterações podem ser feitas atualizando a lógica da política ou as tags regulamentadas, em vez de revisar cada objeto individualmente, como é necessário com filtros de linha em nível de tabela e máscaras de coluna.

• Governança centralizada: Como as políticas podem ser definidas uma única vez e aplicadas a vários objetos de dados correspondentes, as equipes de governança podem gerenciar controles em partes maiores do conjunto de dados com menos definições de políticas.

Recursos adicionais

• tagsregulamentadas
• CRIAR POLÍTICA
• Consulte Gerenciar privilégios no Unity Catalog
• Filtros de linha e máscaras de coluna
• Referência da tabela do sistema de logs de auditoria
• Requisitos, cotas e limitações para políticas de filtros de linha e máscaras de coluna