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

O ABAC (controle de acesso baseado em atributo) é um modelo de controle de acesso que usa marcas e políticas governadas para conceder permissões com base em atributos de objeto em vez de concessões por objeto. Esta página define os componentes fundamentais: tags governadas, os três tipos de política ABAC (filtro de linhas, mascaramento de coluna e políticas GRANT), as permissões necessárias para configurá-las e a segregação de funções que o ABAC permite entre 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 objetos protegíveis. No Catálogo do Unity, esses atributos são representados por meio de marcas governadas. Essas tags 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.

O ABAC também suporta concessões dinâmicas de privilégios por meio de GRANT apólices, sobre tipos de seguro suportados. Veja as políticas da ABACGRANT.

Etiquetas Reguladas

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

Por padrão, objetos protegidos herdam tags do catálogo ou esquema pai. Você pode substituir tags herdadas em todos os níveis, exceto no nível da coluna: as tags de coluna não herdam da tabela pai e 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 objeto securizável ao qual a política está associada, especificado pela cláusula ON. Anexar uma política a um objeto 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 objeto e todos os seus descendentes.
  • Para políticas de filtro de linha e máscara de coluna, os escopos de política com suporte são CATALOG, SCHEMAou TABLE. Para políticas GRANT, os escopos de política com suporte são CATALOG e SCHEMA.
  • Tabelas, incluindo tabelas de streaming e visualizações materializadas, são o único tipo de objeto protegível compatível com políticas de filtro de linha e de mascaramento de coluna, especificadas por meio da cláusula FOR TABLES. GRANT as políticas se aplicam a modelos, serviços de modelo, serviços de provedor de modelo, serviços MCP e serviços de agente, e usam a cláusula GRANT <privilege> FOR <securable_type>. Para ver a lista completa de tipos securáveis e privilégios compatíveis, consulte Tipos securáveis e privilégios compatíveis.
  • Uma política anexada a um catálogo é avaliada em relação a todos os recursos protegíveis do tipo especificado na cláusula FOR nesse 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 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 entidades específicas dessa 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 UDF (função definida pelo usuário) para implementar a lógica de filtragem ou mascaramento. GRANT as políticas não usam UDFs. 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 suporta três tipos de políticas: políticas de filtro de linhas, políticas de mascaramento de coluna e políticas GRANT. As políticas de filtro de linha e máscara de coluna exigem UDFs para implementar a lógica de filtragem ou mascaramento. GRANT As políticas não usam UDFs e concedem privilégios quando sua condição baseada em marca corresponde aos atributos do objeto de destino.

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 convertido no 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. Ele também aceita funções de introspecção de tags, que extraem o valor de uma tag no momento da consulta e o repassam à UDF. 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. UDFs em Python registrados no Catálogo do Unity também têm suporte, embora o otimizador de consulta não possa integrá-los 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.

GRANT Políticas

GRANT as políticas concedem dinamicamente um privilégio do Unity Catalog quando sua condição baseada em tags corresponde às tags de um objeto protegível. Sempre que um usuário tenta acessar um objeto protegível, o Catálogo do Unity identifica todas as GRANT políticas cujo escopo abrange o objeto, verifica se o usuário está na TO lista e não está na EXCEPT lista e avalia a condição da WHEN política em relação às marcas no protegível, incluindo marcas herdadas. Se a política for aplicável, o Unity Catalog concederá o privilégio. GRANT as políticas usam o mesmo modelo de avaliação que as políticas de filtro de linha e máscara de coluna, exceto que elas não usam UDFs. A condição é especificada diretamente na definição da política.

Os privilégios efetivos sobre um objeto são a união das permissões concedidas diretamente e de quaisquer GRANT políticas aplicáveis. Uma entidade tem o privilégio se uma política GRANT no escopo se aplicar a essa entidade ou se uma atribuição direta de GRANT do mesmo privilégio se aplicar. GRANT as políticas só adicionam acesso. Eles não podem revogar o acesso concedido diretamente.

Condições e funções internas

As condições são expressões baseadas em tags que determinam a quais tabelas e colunas uma política se aplica no 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 (cláusula MATCH COLUMNS): uma ou mais expressões boolianas separadas por vírgulas que identificam a 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:

Para fazer a correspondência com base nos atributos do usuário que executa a consulta, em vez de usar tags de recurso, consulte Funções de atributo de identidade.

Para fazer a correspondência com base no contexto de uma solicitação, como o aplicativo chamador, consulte Funções de atributo de contexto.

As tags não se propagam de tabelas para colunas. Usar has_tag() em uma cláusula MATCH COLUMNS corresponde apenas a tags no nível da coluna, não a tags na tabela pai ou aos 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.

Funções de atributo de identidade (Beta)

As funções de atributo de identidade avaliam propriedades do usuário que executa a consulta, como departamento, país ou função de cargo. Esses atributos podem ser fornecidos pelo seu provedor de identidade e referenciados diretamente nas condições da apólice. Isso permite expressar 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 provedor de identidade, as políticas usam os valores de atributo atualizados, assim como usam a associação ao grupo atualizada.

Essas funções têm suporte na cláusula WHEN das políticas de mascaramento de coluna.

Tenha em mente o seguinte comportamento ao escrever políticas que as utilizam:

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

Para os atributos que o Azure Databricks suporta e como eles são provisionados, veja atributos de identidade. Para exemplos de como usar atributos de identidade em políticas, veja Mascarar uma coluna baseada nos atributos do usuário que faz a consulta.

Funções de atributos de contexto (Beta)

Atributos de contexto são usados para restringir o acesso a dados para requisições feitas em nome de um usuário por meio de uma aplicação OAuth. Essa configuração pode ser usada para restringir agentes de acessar dados quando agem em nome de um usuário, mantendo esses mesmos dados acessíveis caso o usuário os consulte diretamente no espaço de trabalho.

Ele cobre qualquer aplicação OAuth, seja uma app embutida como a CLI do Azure Databricks ou uma app OAuth personalizada. Existem 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 requisição de um app OAuth tem esse valor definido como 'true'.
• request.client_id: o ID do cliente OAuth. Isso pode ser usado para direcionar um cliente OAuth específico, seja um app OAuth embutido (por exemplo, databricks-cli) ou um app OAuth personalizado. O client_id pode ser observado na página Conexões do app no console da conta. Para os aplicativos do Databricks, isso também pode ser observado na página de detalhes da Autorização do aplicativo, em OAuth2 App Client ID. Ou, pode ser consultado a partir do identity_metadata.acting_resource campo nos logs de auditoria.

Esses atributos não são modificáveis pelo usuário e são explicitamente fornecidos pelo sistema; Um chamador os influencia apenas pela forma como eles autenticam. Esses atributos podem ser usados para identificar agentes externos, não agentes Gênio.

Atributos de contexto podem ser usados pelas seguintes funções:

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

Para aprender como usar esses atributos de contexto para controlar o acesso de agentes externos, veja Restringir acesso para agentes externos que atuam em nome de um usuário.

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 funções definidas pelo usuário (UDFs) de SQL e Python no Unity Catalog para saber como criar e gerenciar UDFs, e Padrões comuns de filtragem de linhas e mascaramento de colunas para ver exemplos.

Funções de introspecção de tags

As funções de introspecção de tags extraem o valor de uma tag governada e o passam para uma UDF por meio da cláusula USING COLUMNS. Como a UDF recebe o valor da tag como argumento, uma única política e UDF podem lidar com 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, pois GRANT as políticas não usam UDFs.

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

No momento da consulta, o Unity Catalog avalia essas funções com base nas tags da tabela ou das colunas às quais a política se aplica: 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 só podem aparecer na cláusula USING COLUMNS, não nas condições WHEN ou MATCH COLUMNS.

As duas funções assumem a chave de marcação como um literal de cadeia de caracteres. A tag deve ser uma tag gerenciada, e get_column_tag_value() deve fazer referência a um alias que existe na cláusula MATCH COLUMNS da política. Se a tag não estiver sob governança ou o alias não for válido, a criação da política falhará. Se uma tag referenciada não estiver mais sujeita à governança quando uma consulta é executada, as consultas feitas nas tabelas de destino da política falham em tempo de execução.

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

Sem a introspecção de tags, o mascaramento de cada tipo de informação de identificação pessoal (e-mail, SSN, telefone) requer uma política e uma UDF separadas para cada valor de tag. Com get_column_tag_value(), uma única política passa o valor da marcação da pii da coluna correspondente para uma UDF. O UDF se ramifica com base naquele valor:

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') resolve para o valor da marcação pii dessa coluna (email, ssn, phone, etc.), e mask_pii aplica a transformação correspondente. Um novo valor de tag requer apenas uma nova ramificação na UDF, não uma nova política.

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 criem objetos dentro de escopos controlados e os consumidores de dados acessem os objetos controlados.

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 tags 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 objetos protegíveis do Catálogo do Unity, como catálogos, esquemas, tabelas, colunas, modelos e volumes. Por exemplo, marque colunas que contêm informações de identificação pessoal com pii : ssnou marque um modelo com lifecycle : production. 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 se aplica, quais condições avalia e qual ação deve ser aplicada, como um filtro de linha, uma máscara de coluna ou uma concessão de privilégio.

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

4. Criar objetos de dados. Os criadores de dados criam objetos protegíveis, como tabelas, modelos ou volumes dentro dos escopos aos quais receberam acesso. Novos objetos herdam tags dos catálogos e esquemas pai. 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. Acessar objetos controlados. Quando um usuário tenta acessar um objeto protegível dentro do escopo de uma política, o Catálogo do Unity avalia as políticas aplicáveis automaticamente. Para políticas de filtro de linha e máscara de coluna, o usuário verá 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 GRANT , o usuário ganha o privilégio concedido se as condições coincidirem 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 uma concessão de objeto direto. Essas políticas filtram registros ou mascaram colunas em tabelas que o usuário já pode acessar. Eles não concedem permissões por conta própria. GRANT As políticas concedem o próprio privilégio e são combinadas com quaisquer concessões diretas no mesmo objeto protegível.

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 as tags 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.

Recursos adicionais

• 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 para políticas de filtro de linha e máscara de coluna