Conceitos principais para o ABAC (controle de acesso baseado em atributo)

Esta página apresenta o ABAC, como ele usa marcas governadas, políticas e funções definidas pelo usuário para controlar quais linhas os usuários podem ver e como os valores de coluna são apresentados e seus benefícios. Esta página também aborda as permissões necessárias para configurar o ABAC e a separação de tarefas que ela habilita entre as equipes.

Consulte o controle de acesso baseado em atributos no Catálogo do Unity para obter uma visão geral de todos os tópicos do ABAC, incluindo tutoriais, gerenciamento de políticas, práticas recomendadas e limitações.

O que é ABAC?

O ABAC (controle de acesso baseado em atributo) é 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 protegíveis. No Catálogo do Unity, esses atributos são representados por meio de marcas governadas. Essas marcas governadas são usadas em condições de política para corresponder a objetos de dados em um determinado escopo, como um catálogo ou um esquema. Isso permite que uma única política seja aplicada automaticamente em vários objetos de dados que atendam às suas condições.

Por exemplo, uma política ABAC pode mascarar todas as colunas marcadas PII para tabelas dentro de esquemas marcados HR. À medida que novos objetos de dados são criados e marcados, a política se aplica automaticamente sem exigir definições de política separadas para cada objeto.

O ABAC dá 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, visões materializadas e tabelas de streaming. As políticas de filtro de linha restringem quais linhas um usuário pode ver. As políticas de máscara de coluna controlam como os valores de coluna são apresentados aos usuários.

Para obter uma comparação com filtros de linha no nível da tabela e máscaras de coluna, consulte Quando usar ABAC versus filtros de linha no nível da tabela e máscaras de coluna.

Etiquetas Reguladas

No Catálogo do Unity, os atributos são implementados como marcas governadas. As marcas governadas são pares chave-valor definidos no nível da conta e aplicados a elementos de segurança do Unity Catalog, como catálogos, esquemas, tabelas e colunas, além de objetos do ambiente de trabalho. Eles representam características como confidencialidade, classificação ou domínio de negócios.

Por padrão, as tags herdam de catálogos pai e esquemas para tabelas, mas não de tabelas para colunas. Você pode sobrescrever tags herdadas em qualquer nível, mas tags no nível da coluna devem ser aplicadas diretamente.

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

As tags controladas são definidas no nível da conta. Isso significa que você pode usar a mesma taxonomia de etiquetas em todo o patrimônio de dados dentro de uma mesma conta, incluindo em vários metastores.

Para obter mais informações, consulte Tags Governadas e Aplicar Tags a Objetos Securáveis do Unity Catalog.

Policies

As políticas são anexadas a objetos protegíveis no Catálogo do Unity para definir regras de controle de acesso com base em condições de etiqueta. Veja um exemplo:

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 protegível em que a política está anexada, especificada pela ON cláusula. Anexar uma política a um protegível significa que as condições de política são avaliadas para todos os objetos do tipo especificado na FOR cláusula, entre esse protegível e todos os seus descendentes.
  • Os escopos de política com suporte hoje são CATALOG, SCHEMAou TABLE.
  • As tabelas, incluindo tabelas de streaming e visões materializadas, são atualmente o único tipo securizável com suporte, especificado usando a cláusula FOR TABLES.
  • Uma política anexada em um catálogo é avaliada em relação a todas as tabelas desse catálogo. Uma política anexada em um esquema é avaliada em relação a todas as tabelas nesse esquema. Uma política anexada em uma tabela é avaliada somente em relação a essa tabela.

• Principais: a quem a política se aplica e quem está isento. A TO cláusula especifica os usuários, grupos ou entidades de serviço sujeitos à política. A cláusula opcional EXCEPT exclui principais específicos dessa política.
• Ações: Se a política aplica um filtro de linha ou uma máscara de coluna. A ação é implementada por uma UDF (função definida pelo usuário) que define a lógica de filtragem ou mascaramento. Consulte os tipos de política.
• Condições: expressões baseadas em tags que determinam quais tabelas ou colunas a política se destina. Consulte Condições e funções internas.

As políticas são criadas e gerenciadas por meio da interface do usuário ou programaticamente com instruções SQL, como CREATE POLICYDROP POLICY, SHOW POLICIESDESCRIBE POLICYSDKs do Databricks ou Terraform. Consulte Criar e gerenciar políticas ABAC para obter a sintaxe completa e os exemplos.

Tipos de política

O ABAC dá suporte a dois tipos de políticas: políticas de filtro de linha e políticas de máscara de coluna. Ambos exigem UDFs para implementar a lógica de filtragem ou mascaramento.

Políticas de filtro de linha

As políticas de filtro de linha restringem quais linhas um usuário pode ver em uma tabela com base em valores em colunas identificadas por marcas que correspondem às condições e funções internas. A política faz referência a uma UDF 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 por meio da USING COLUMNS cláusula.

Exemplo de caso de uso: Para um catálogo de vendas, verifique se a equipe do EMEA vê apenas registros de venda do EMEA em todas as tabelas que têm uma coluna marcada region.

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 marcas que correspondem às condições e funções internas. A política faz referência a uma UDF que usa 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 por meio de USING COLUMNS. O tipo de retorno deve corresponder ou ser castível para o tipo de dados da coluna.

Exemplo de caso de uso: Mascarar colunas SSN marcadas com pii : ssn de modo que os usuários vejam ***-**-XXXX (somente os quatro últimos dígitos), a menos que estejam em um grupo de conformidade isento da política.

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 marca ou valores constantes (cadeias de caracteres entre aspas, literais numéricos, valores boolianos (TRUE/FALSE) ou NULL), fornecidos na ordem em que a função as espera. Para políticas de máscara de coluna, esses são argumentos adicionais além da coluna mascarada (que é associada automaticamente a partir de ON COLUMN). Isso permite que um único UDF seja reutilizado entre políticas com parâmetros diferentes.

UDFs do SQL são recomendados para melhor desempenho. Python UDFs registrados no Catálogo do Unity também têm suporte, embora o otimizador de consulta não possa inlinhar ou otimizá-los da maneira como faz com UDFs em SQL. Confira as considerações de desempenho para obter diretrizes sobre a seleção de idioma UDF.

Condições e funções internas

As condições são expressões baseadas em tags que determinam quais tabelas e colunas uma política se aplica em seu escopo.

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

Ambos os tipos de cláusula usam as seguintes funções internas, avaliadas pelo Catálogo do Unity em relação aos metadados protegíveis:

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

Exemplo: usando duas condições de coluna. Um customers esquema tem tabelas com uma coluna de email marcada pii : email e uma coluna de consentimento marcada consent_to_contact. A política mascara endereços de email, a menos que o cliente tenha consentido em ser contatado. Ele usa duas condições de coluna:

1. has_tag_value('pii', 'email') identifica a coluna que contém endereços de 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 deseja mascarar).

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

Essa política só se aplica a tabelas que têm uma coluna marcada pii : email e uma coluna marcada consent_to_contact. Se uma tabela não tiver colunas que correspondam às duas condições, a política não se aplicará e os dados serão retornados desmascarados.

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

As políticas de filtro de linha e máscara de coluna usam UDFs (funções definidas pelo usuário) para implementar sua lógica de filtragem ou mascaramento. Consulte UDFs (funções definidas pelo usuário) no Catálogo do Unity para saber como criar e gerenciar UDFs e padrões comuns para filtragem de linhas e mascaramento de colunas , por exemplo.

Separação de tarefas e permissões

A configuração do ABAC envolve várias etapas, cada uma com seus próprios requisitos de permissão. As organizações podem distribuir essas tarefas entre grupos especializados, dependendo de como elas optam por separar as tarefas. Por exemplo, uma organização pode definir uma taxonomia de marca centralmente e, em seguida, fazer com que os administradores de dados classifiquem dados, os administradores de governança escrevam políticas, os criadores de dados criam objetos dentro de escopos controlados e os consumidores de dados consultam os resultados.

1. Crie a taxonomia de etiquetas. Defina as chaves de marca governadas e seus valores permitidos antes que alguém as aplique ou grave políticas. Por exemplo, crie uma sensitivity marca com valores controlados (public, , internal, confidential) restrictedou uma pii marca com valores como ssn, emaile phone_number. Consulte Padronizar atributos e nomes 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 de CREATE para etiquetas no nível da conta.

2. Marcar ativos de dados. Um administrador de dados, criador de dados ou sistema de classificação de IA aplica marcas governadas a catálogos, esquemas, tabelas ou colunas. Por exemplo, marque colunas que contêm informações de identificação pessoal com pii : ssn. A marcação correta é o primeiro passo essencial para que as políticas ABAC sejam aplicadas.

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

3. Criar uma 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 ela se aplica, a quais condições ela avalia e a UDF que implementa a lógica de filtragem ou mascaramento.

   • Permissões necessárias: MANAGE permissão ou titularidade de objeto no elemento protegido em que a política está anexada (catálogo, esquema ou tabela) e EXECUTE privilégio na UDF.

4. Criar objetos de dados. Os criadores de dados criam tabelas dentro dos escopos aos quais receberam acesso. Novas tabelas herdam tags de objetos principais, como catálogos e esquemas. Os criadores de dados também têm APPLY TAG automaticamente em objetos que criam, para que possam aplicar marcas adicionais. Como alternativa, eles podem contar com a classificação automática de dados para lidar com a marcação. Se uma organização depende de criadores de dados para marcar seus próprios objetos, ela deve estabelecer práticas de marcação claras. Os criadores de dados não precisarão configurar controles de acesso se as políticas forem definidas em níveis mais altos, o que Azure Databricks recomenda.

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

5. Consultar dados. Quando um consumidor de dados consulta uma tabela dentro do escopo da política, a política é avaliada automaticamente. Se a tabela ou as colunas corresponderem às condições da política e o usuário não estiver isento, o consumidor verá dados filtrados ou mascarados.

   • Permissões necessárias: os usuários devem receber permissões na tabela, como SELECT, por meio de uma concessão direta de objeto. As suas políticas de filtro de linha ABAC e máscara de coluna não concedem permissões por conta própria. Eles filtram apenas registros ou mascaram colunas para tabelas que um usuário já pode acessar.

Benefícios do ABAC

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

• Aplicativo automático para novos objetos: Quando novos objetos de dados são criados dentro do escopo e marcados com os atributos relevantes, as políticas abac existentes se aplicam sem configuração adicional. As políticas agem como concessões futuras, o que significa que os controles de acesso se aplicam automaticamente à medida que novos dados são criados e marcados adequadamente.

• Imposiçã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 remove diferenças na forma como dados semelhantes são filtrados ou mascarados.

• Menor manutenção contínua: As alterações podem ser feitas atualizando a lógica da política ou marcas governadas, em vez de revisitar cada objeto individual, conforme necessário com filtros de linha no nível da tabela e máscaras de coluna.

• Governança centralizada: Como as políticas podem ser definidas uma vez e aplicadas em muitos 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ítica.

Mais informações

• Etiquetas governadas
• CRIAR POLÍTICA
• Gerenciar privilégios no Catálogo do Unity
• Filtros de linha e máscaras de coluna
• Referência à tabela do sistema de log de auditoria
• Requisitos, cotas e limitações do ABAC