Conceitos centrais para controlo de acesso baseado em atributos (ABAC)

O controlo de acesso baseado em atributos (ABAC) é um modelo de controlo de acesso que utiliza etiquetas e políticas governadas para conceder permissões com base nos atributos do objeto em vez de concessões por objeto. Esta página define os blocos de construção: etiquetas governadas, os três tipos de políticas ABAC (filtro de linhas, máscara de coluna e GRANT políticas), as permissões necessárias para as configurar e a separação de funções que o ABAC permite entre equipas.

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

O que é ABAC?

O controlo de acesso baseado em atributos (ABAC) é um modelo dinâmico de controlo de acesso onde as decisões de acesso são baseadas em políticas avaliadas em relação a atributos associados a objetos securáveis. No Unity Catalog, estes atributos são representados através de etiquetas governadas. Estas etiquetas governadas são usadas em condições de política para corresponder a objetos de dados dentro de um determinado âmbito, como um catálogo ou um esquema. Isto permite que uma única política se aplique automaticamente entre múltiplos objetos de dados que cumpram as suas condições.

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

O ABAC suporta segurança ao nível de linha e coluna através de políticas de filtro de linha e políticas de máscaras de coluna em tabelas, vistas materializadas e tabelas de streaming. As políticas de filtro de linhas restringem quais as linhas que o utilizador pode ver. As políticas de máscara de coluna controlam como os valores das colunas são apresentados aos utilizadores. Para uma comparação entre filtros de linha ao nível de tabela e máscaras de coluna, veja Quando usar ABAC vs filtros de linha ao nível de tabela e máscaras de coluna.

O ABAC também suporta concessões dinâmicas de privilégios através de políticasGRANT, em tipos de objetos protegíveis suportados. Consulte as políticas da ABACGRANT.

Tags controladas

No Unity Catalog, os atributos são implementados como etiquetas governadas. As etiquetas governadas são pares-chave-valor definidos ao nível da conta e aplicados a objetos securáveis do Unity Catalog, como catálogos, esquemas, tabelas, colunas, modelos e volumes, além dos objetos de espaço de trabalho. Representam características como sensibilidade, classificação ou domínio de negócio.

Por defeito, os objetos protegidos herdam etiquetas do catálogo ou esquema principal a que pertencem. Pode sobrescrever etiquetas herdadas em todos os níveis, exceto no nível da coluna: as etiquetas de coluna não herdam da tabela pai e devem ser aplicadas diretamente.

Etiquetas governadas podem ser referenciadas em condições de política usando funções incorporadas como has_tag() e has_tag_value(), que verificam se uma dada etiqueta está presente no objeto de dados alvo, seja diretamente ou através de herança de etiquetas.

As etiquetas governadas são definidas ao nível da conta. Isto significa que pode usar a mesma taxonomia de etiquetas em todo o seu património de dados numa conta, incluindo em múltiplas metastores.

Para mais informações, veja Etiquetas Governadas e Aplicar etiquetas a objetos seguros do Unity Catalog.

Policies

As políticas são anexadas a objetos securáveis no Unity Catalog para definir regras de controlo de acesso com base nas condições da etiqueta. Abaixo encontra-se 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 apólice especifica:

• Âmbito: O objeto protegível ao qual a política está associada, especificado pela cláusula ON. Anexar uma política a um objeto securável significa que as condições da 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 linhas e máscaras de coluna, os escopos de política suportados são CATALOG, SCHEMA, ou TABLE. Para as políticas GRANT, os âmbitos de política suportados são CATALOG e SCHEMA.
  • As tabelas, incluindo tabelas de streaming e vistas materializadas, são o único tipo de objeto protegível suportado para políticas de filtro de linhas e de mascaramento de colunas, especificadas através da cláusula FOR TABLES. GRANT as políticas aplicam-se a modelos, serviços de modelo, serviços de fornecedores de modelos, serviços MCP e serviços de agentes, e utilizam a cláusula GRANT <privilege> FOR <securable_type>. Para a lista completa de tipos de objetos protegíveis e privilégios suportados, consulte Tipos de objetos protegíveis e privilégios suportados.
  • Uma política associada a um catálogo é aplicada a todos os recursos protegidos do tipo especificado na cláusula FOR nesse catálogo. Uma política associada a um esquema é avaliada em relação a todos os objetos protegíveis desse tipo nesse esquema. Uma política anexada a uma tabela avalia apenas contra essa mesma tabela.

• Destinatários: A quem se aplica a apólice e quem está isento. A TO cláusula especifica os utilizadores, grupos ou principais 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 atribuição de privilégios. As políticas de filtro de linhas e de mascaramento de colunas utilizam uma função definida pelo utilizador (UDF) para implementar a lógica de filtragem ou de mascaramento. GRANT as políticas não utilizam UDFs. Ver Tipos de Políticas.
• Condições: Expressões baseadas em etiquetas que determinam quais as tabelas ou colunas a que a política se destina. Ver Condições e funções incorporadas.

As políticas são criadas e geridas através da interface ou programaticamente com instruções SQL, como CREATE POLICY, DROP POLICY, SHOW POLICIES, ou DESCRIBE POLICY, APIs REST, SDKs Databricks ou Terraform. Consulte Criar e gerir políticas ABAC para a sintaxe completa e 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 colunas e políticas GRANT. As políticas de filtro de linhas e de mascaramento de colunas exigem UDFs para implementar a lógica de filtragem ou de mascaramento. GRANT as políticas não usam UDFs e, em vez disso, concedem privilégios quando a condição baseada em etiquetas corresponde aos atributos do objeto alvo.

Políticas de filtro de linha

As políticas de filtro de linhas restringem que linhas um utilizador pode ver numa tabela com base em valores em colunas identificadas por etiquetas que correspondem às Condições e funções incorporadas. A política faz referência a um UDF que avalia cada linha. As linhas onde a função devolve FALSE são excluídas dos resultados da consulta. Os argumentos são transmitidos à UDF através da USING COLUMNS cláusula.

Exemplo de caso de uso: Para um catálogo de vendas, certifique-se de que a equipa EMEA vê apenas os registos de vendas EMEA em todas as tabelas com uma coluna etiquetada 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áscaras em coluna

As políticas de máscaras de coluna controlam que valores um utilizador vê para colunas específicas identificadas por etiquetas que correspondem às Condições e funções incorporadas. A política faz referência a um UDF que recebe o valor da coluna como entrada e devolve o valor original ou uma versão mascarada. O valor da coluna mascarada é atribuído automaticamente como o primeiro argumento da ON COLUMN cláusula, e argumentos adicionais podem ser passados por USING COLUMNS. O tipo de retorno deve corresponder ou ser castável ao tipo de dados da coluna.

Exemplo de caso de uso: Máscara colunas de SSN etiquetadas com pii : ssn para que os utilizadores vejam ***-**-XXXX (apenas nos últimos quatro dígitos), a menos que estejam num 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 USING COLUMNS cláusula passa os argumentos para a UDF. Aceita pseudónimos para colunas que correspondem a uma expressão baseada em etiquetas, ou valores constantes (cadeias entre aspas, literais numéricos, valores booleanos (TRUE/FALSE), ou NULL), fornecidos na ordem que a função espera. Também aceita funções de introspeção de etiquetas, que extraem o valor de uma etiqueta no momento da consulta e o transmitem para a UDF. Para políticas de máscaras de coluna, estes são argumentos adicionais para além da coluna mascarada (que é vinculada automaticamente a partir de ON COLUMN). Isto permite que um único UDF seja reutilizado entre políticas com diferentes parâmetros.

Recomenda-se UDFs SQL para melhor desempenho. UDFs Python registados no Catálogo Unity também são suportados, embora o otimizador de consultas não os consiga incorporar diretamente ou otimizar da mesma forma que faz com UDFs SQL. Consulte Considerações de Desempenho para orientações sobre a seleção da língua UDF.

GRANT Políticas

GRANT as políticas concedem dinamicamente um privilégio do Unity Catalog quando a condição baseada em etiquetas corresponder às etiquetas de um objeto protegível. Cada vez que um utilizador tenta aceder a um objeto securável, o Unity Catalog identifica todas GRANT as políticas cujo âmbito cobre o objeto, verifica se o utilizador está na TO lista e não na EXCEPT lista, e avalia a condição da WHEN política em relação às etiquetas do securável, incluindo as etiquetas herdadas. Se a política for aplicável, o Unity Catalog concede o privilégio. GRANT as políticas utilizam o mesmo modelo de avaliação que as políticas de filtro de linhas e máscaras de coluna, exceto que não utilizam UDFs. A condição é expressa em linha na definição da política.

Os privilégios efetivos sobre um objeto são a união de subvenções diretas e quaisquer políticas aplicáveis GRANT . Um principal tem o privilégio se uma política GRANT no âmbito se aplicar a esse principal ou se uma atribuição direta GRANT do mesmo privilégio se aplicar. GRANT As políticas apenas adicionam acesso. Não podem revogar o acesso concedido diretamente.

Condições e funções incorporadas

As condições são expressões baseadas em etiquetas que determinam quais as tabelas e colunas que uma política tem como alvo dentro do seu âmbito.

• Condições de tabela (WHEN cláusula): Expressões booleanas que correspondem às tabelas com base nas suas etiquetas. Se omitido, o padrão é TRUE, ou seja, a política aplica-se a todas as tabelas no âmbito definido.
• Condições de coluna (MATCH COLUMNS cláusula): Uma ou mais expressões booleanas separadas por vírgulas que identificam quais as colunas que a política destina. Cada expressão pode ser uma única função incorporada 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 ser atribuída a um alias (especificado após AS) que pode ser referenciado nas cláusulas ON COLUMN e USING COLUMNS. Uma política pode incluir até 3 expressões de colunas, e todas têm de coincidir para que a política se aplique.

Ambos os tipos de cláusulas utilizam as seguintes funções incorporadas, avaliadas pelo Unity Catalog em relação a metadados securáveis:

Para corresponder nos atributos do utilizador que executa a consulta em vez de nas etiquetas de recursos, veja Funções de atributos de identidade.

Para fazer corresponder com base no contexto de uma solicitação, como a aplicação de chamada, veja Funções de atributo de contexto.

As etiquetas não se propagam das tabelas para as colunas. Usar has_tag() numa MATCH COLUMNS cláusula apenas corresponde a etiquetas ao nível da coluna, nem etiquetas na tabela pai ou seus antecessores.

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

1. has_tag_value('pii', 'email') identifica a coluna que contém endereços de email (a coluna para mascarar).
2. has_tag('consent_to_contact') identifica a coluna que contém informações de consentimento (usada pela UDF para decidir se deve 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);

Esta política aplica-se apenas a tabelas que tenham tanto uma coluna etiquetada pii : email como uma coluna etiquetada 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 devolvidos sem mascaramento.

Funções do atributo identidade (Beta)

As funções de atributos de identidade avaliam propriedades do utilizador que executa a consulta, como departamento, país ou função de trabalho. Estes atributos podem ser fornecidos pelo seu fornecedor de identidade e referenciados diretamente nas condições da apólice. Isto permite-lhe expressar condições mais flexíveis sem criar grupos separados para cada combinação de propriedades de identidade. Quando a informação de identidade muda no seu fornecedor de identidade, as políticas utilizam os valores atualizados dos atributos, tal como utilizam a atualização da pertença ao grupo.

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

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

• Um atributo em falta resolve-se para false. Se o utilizador não tiver valor para o atributo, não tiver atributos nenhuns, ou o atributo não existir, a função devolve false em vez de gerar um erro. Condições de frase para que este false resultado restrinja o acesso. Ver Condições de atributo de identidade.
• As chaves e os valores dos atributos fazem distinção entre maiúsculas e minúsculas e são comparados exatamente: Finance e finance não correspondem.
• As alterações de atributos não são instantâneas. As alterações no seu fornecedor de identidade não são sincronizadas imediatamente com o Azure Databricks. Consulte atributos de identidade para mais informações.

Para os atributos que o Azure Databricks suporta e como 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 utilizador que faz a consulta.

Funções de atributos de contexto (Beta)

Os atributos de contexto são usados para restringir o acesso a dados para pedidos feitos em nome de um utilizador através de uma aplicação OAuth. Esta configuração pode ser usada para restringir o acesso de agentes a dados quando atuam em nome de um utilizador, mantendo esses mesmos dados acessíveis caso o utilizador os consulte diretamente no espaço de trabalho.

Abrange qualquer aplicação OAuth, seja uma aplicação incorporada como a CLI do Azure Databricks ou uma aplicação OAuth personalizada. Existem dois atributos contextuais diferentes:

• request.is_on_behalf_of: a cadeia de caracteres 'true' ou 'false'. Indica se o pedido é executado em nome de um utilizador através de uma aplicação OAuth. Qualquer pedido de uma aplicação OAuth tem este valor definido para 'true'.
• request.client_id: o ID do cliente OAuth. Isto pode ser usado para direcionar um cliente OAuth específico, seja uma aplicação OAuth incorporada (por exemplo, databricks-cli) ou uma aplicação OAuth personalizada. Pode client_id ser observado na página de ligações da aplicação na consola da conta. Para aplicações Databricks, também pode ser observado na página de detalhes de autorização da aplicação, em OAuth2 App Client ID. Ou, pode ser consultado a partir do identity_metadata.acting_resource campo nos registos de auditoria.

Estes atributos não são modificáveis pelo utilizador e são explicitamente fornecidos pelo sistema; Um interlocutor influencia-os apenas pela forma como autenticam. Estes atributos podem ser usados para identificar agentes externos, não agentes Génio.

Os atributos de contexto podem ser usados através das seguintes funções:

As chaves dos atributos não distinguem maiúsculas de minúsculas, e os valores distinguem maiúsculas de minúsculas.

Para aprender a usar estes atributos de contexto para controlar o acesso de agentes externos, veja Restringir acesso para agentes externos que atuam em nome de um utilizador.

Funções definidas pelo utilizador (UDFs)

As políticas de filtro de linhas e máscaras de coluna utilizam funções definidas pelo utilizador (UDFs - User-Defined Functions) para implementar a sua lógica de filtragem ou máscara. Consulte funções definidas pelo utilizador (UDFs) em SQL e Python no Catálogo Unity para saber como criar e gerir UDFs, e Padrões comuns para filtragem de linhas e mascaramento de colunas para ver exemplos.

Funções de introspeção de etiquetas

As funções de introspeção de etiquetas extraem o valor de uma etiqueta governada e passam-no para um UDF através da USING COLUMNS cláusula. Como o UDF recebe o valor da etiqueta como argumento, uma única política e UDF podem gerir múltiplos valores de etiqueta, em vez de exigir uma política separada para cada valor da etiqueta. Estas funções estão disponíveis apenas para políticas de filtragem de linhas e de mascaramento de colunas, porque as políticas GRANT não utilizam UDFs.

Criar uma política que utilize estas funções requer Databricks Runtime 18 LTS ou superior. Este requisito aplica-se apenas à criação de políticas, não à consulta das tabelas governadas.

No momento da consulta, o Unity Catalog avalia estas funções com base nas etiquetas da tabela ou das colunas às quais a política se aplica: get_tag_value() lê dados da tabela que satisfaz a condição WHEN, e get_column_tag_value() lê dados das colunas identificadas por MATCH COLUMNS. Só podem aparecer na cláusula USING COLUMNS, não nas condições WHEN ou MATCH COLUMNS.

Ambas as funções recebem a chave da etiqueta como um literal de string. A etiqueta deve ser uma etiqueta governada e get_column_tag_value() deve referenciar um alias que exista na cláusula da MATCH COLUMNS política. Se a etiqueta não for governada ou o alias não for válido, a criação de políticas falha. Se uma etiqueta referenciada já não for regida quando uma consulta é executada, as consultas contra as tabelas de destino da política falham em tempo de execução.

Exemplo: Uma apólice para todos os tipos de PII

Sem introspeção das etiquetas, mascarar cada tipo de informação pessoal identificável (email, SSN, telefone) requer uma política e um UDF separados para cada valor da etiqueta. Com get_column_tag_value(), uma única política passa o valor da pii etiqueta da coluna correspondente para um UDF. A UDF bifurca em função desse 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') corresponde ao valor da etiqueta pii dessa coluna (email, ssn, phone, etc.), e mask_pii aplica a transformação correspondente. Um novo valor de etiqueta requer apenas um novo ramo no UDF, não uma nova política.

Separação de deveres e permissões

A criação do ABAC envolve vários passos, cada um com os seus próprios requisitos de permissão. As organizações podem distribuir estas tarefas por grupos especializados dependendo de como escolherem separar as tarefas. Por exemplo, uma organização pode definir uma taxonomia de etiquetas centralmente, depois fazer com que os gestores de dados classifiquem os dados, os administradores de governação escrevam políticas, os criadores de dados criem objetos dentro de escopos governados e os consumidores de dados acedam aos objetos governados.

1. Crie a taxonomia da etiqueta. Defina as chaves de etiquetas governadas e os seus valores permitidos antes de alguém as aplicar ou escrever políticas. Por exemplo, criar uma sensitivity etiqueta com valores controlados (public, internal, confidential, restricted) ou uma pii etiqueta com valores como ssn, email, e phone_number. Consulte Standardize atributos e nomenclatura para recomendações sobre convenções de nomenclatura e design de taxonomia.

   • Permissões necessárias: administrador de conta, ou um utilizador com CREATE permissão para etiquetas ao nível da conta.

2. Etiquetar ativos de dados. Um gestor de dados, criador de dados ou sistema de classificação de IA aplica etiquetas governadas a objetos protegidos pelo Unity Catalog, como catálogos, esquemas, tabelas, colunas, modelos e volumes. Por exemplo, marcar colunas que contenham informação pessoalmente identificável com pii : ssn, ou etiquetar um modelo com lifecycle : production. A etiquetagem correta é o primeiro passo essencial para que as políticas ABAC se apliquem.

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

3. Crie uma política. Um administrador de governação cria uma política num âmbito específico, como um catálogo ou esquema. A política especifica a quem se aplica, que condições avalia e a ação a aplicar, como um filtro de linhas, uma máscara de coluna ou uma concessão de privilégio.

   • Permissões necessárias: MANAGE permissão ou propriedade de objeto sobre o objeto garantido onde a apólice está anexada. Para políticas de filtro de linha e máscaras de coluna, também EXECUTE tem privilégio no UDF.

4. Criar objetos de dados. Os criadores de dados criam objetos protegíveis, como tabelas, modelos ou volumes, no âmbito ao qual lhes foi concedido acesso. Os novos objetos herdam etiquetas dos catálogos e esquemas principais. Os criadores de dados também têm APPLY TAG automaticamente sobre os objetos que criam, para poderem aplicar etiquetas adicionais. Em alternativa, podem confiar na classificação automática dos dados para tratar da marcação. Se uma organização depende dos criadores de dados para marcar os seus próprios objetos, deve estabelecer práticas claras de marcação. Os criadores de dados não precisam de configurar quaisquer controlos de acesso se as políticas forem definidas em níveis superiores, como o Azure Databricks recomenda.

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

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

   • Permissões necessárias: Para políticas de filtro de linhas e políticas de mascaramento de colunas, os utilizadores devem ter permissões concedidas sobre a tabela, tais como SELECT, através de uma concessão direta sobre o objeto. Estas políticas filtram registos ou mascaram colunas em tabelas às quais o utilizador já pode aceder. Eles não concedem permissões por si próprios. GRANT as políticas concedem elas próprias o privilégio, em conjunto com quaisquer concessões diretas sobre o mesmo objeto protegível.

Benefícios do ABAC

• Apólices reutilizáveis baseadas em atributos: Uma única política pode aplicar-se a múltiplos objetos de dados que correspondam às mesmas condições baseadas em atributos, em vez de estarem ligadas a um objeto específico.

• Aplicação automática a novos objetos: Quando novos objetos de dados são criados dentro do âmbito e etiquetados com os atributos relevantes, as políticas ABAC existentes aplicam-se sem configuração adicional. As políticas funcionam como futuras subvenções, o que significa que os controlos de acesso aplicam-se automaticamente à medida que novos dados são criados e etiquetados adequadamente.

• Aplicação consistente dentro de um determinado âmbito: As políticas associadas ao nível do catálogo ou esquema são avaliadas dinamicamente contra objetos de dados correspondentes nesse âmbito, o que elimina 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 de políticas ou etiquetas governadas, em vez de revisitar cada objeto individual, como é exigido com filtros de linhas ao nível de tabela e máscaras de coluna.

• Governação centralizada: Como as políticas podem ser definidas uma vez e aplicadas em muitos objetos de dados correspondentes, as equipas de governação podem gerir controlos em partes maiores do património de dados com menos definições de políticas.

Recursos adicionais

• Tags controladas
• CRIAR POLÍTICA
• Gerenciar privilégios no Catálogo Unity
• Filtros de linha e máscaras de coluna
• Referência da tabela do sistema de registos de auditoria
• Requisitos, quotas e limitações para políticas de filtro de linhas e máscaras de coluna