Pular para o conteúdo principal
Última atualização em

Políticas DENY ABAC (Beta)

info

Beta

As políticas DENY de ABAC estão em Beta. As políticas DENY são anexadas no nível de catálogo ou esquema e negam o privilégio MANAGE ACCESS CONTROL nos tipos de objetos protegíveis suportados. Consulte Tipos de objetos protegíveis e privilégios suportados.

As políticas ABAC DENY negam explicitamente privilégios do Unity Catalog a principais em objetos protegíveis cujas tags governadas correspondem a uma condição, sempre tendo precedência sobre qualquer concessão. Esta página aborda como criar, editar, listar e excluir políticas ABAC DENY, o que significa negar MANAGE ACCESS CONTROL, e o escopo e as limitações atuais.

Você pode criar e gerenciar políticas DENY ABAC usando o Catalog Explorer, SQL, a API REST, Terraform ou os SDKs do Databricks.

Para uma visão geral de ABAC e conceitos fundamentais, incluindo tags governadas e funções integradas como has_tag e has_tag_value, consulte Conceitos fundamentais para controle de acesso baseado em atributos (ABAC).

Compute requirements​

Usar SQL para criar, modificar ou excluir políticas DENY requer um recurso de compute clássico executando o Databricks Runtime 18 LTS ou superior.

nota

O Databricks Runtime 18 é mais recente que o Databricks Runtime 18.0, 18.1 e 18.2. Os recursos que anteriormente seriam 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.

O que é uma política DENY​

Uma política DENY é uma política de controle de acesso baseada em atributos que nega explicitamente um privilégio do Unity Catalog a principais especificados nos objetos seguros cujas tags governadas correspondem à condição da política. O Unity Catalog avalia a condição WHEN da política em relação às tags governadas em cada objeto seguro no escopo da política toda vez que o acesso é verificado, e nega o privilégio em cada objeto seguro correspondente.

Uma política DENY tem precedência sobre qualquer concessão do mesmo privilégio e não pode ser substituída por uma concessão individual.

Uma política DENY é regida pelas seguintes regras:

  • DENY sempre tem precedência. Uma política DENY substitui qualquer concessão do mesmo privilégio, incluindo concessões mantidas por herança, associação a grupos ou implicitamente por meio de propriedade de objeto. Nenhuma concessão individual pode substituir um DENY ativo.
  • Os administradores do metastore estão sempre implicitamente isentos. Um administrador do metastore nunca é afetado por uma política DENY para MANAGE ACCESS CONTROL, o que garante que sempre haja um caminho para modificar ou remover qualquer política DENY.
  • DENY é herdado para baixo. A negação em si é herdada pela hierarquia de objetos da mesma forma que as concessões seguem a herança de privilégios. Uma política DENY em um catálogo nega o privilégio em todos os objetos atuais e futuros dentro desse catálogo, e uma política DENY em um esquema nega o privilégio em todos os objetos atuais e futuros dentro desse esquema.
  • Políticas de DENY sobrepostas são combinadas, e o resultado mais restritivo é aplicado. Quando várias políticas de DENY se aplicam ao mesmo principal, seus efeitos são unidos. Uma política de DENY não pode isentar um principal que outra política de DENY tem como alvo. Se qualquer política aplicável negar o privilégio, ele será negado.
  • As políticas DENY são independentes de concessões (grants). Ao contrário de um REVOKE, que apenas remove um privilégio que foi explicitamente concedido, uma política DENY não depende de uma concessão existente. Você pode negar um privilégio que nunca foi concedido, e remover uma concessão não remove uma política DENY. Uma política DENY permanece em vigor até que seja explicitamente descartada.

As políticas DENY podem referenciar tags controladas que você mesmo cria ou tags do sistema predefinidas pela Databricks em suas condições.

As políticas DENY diferem das políticas de filtro de linha e máscara de coluna de duas maneiras:

  • Políticas de filtro de linha e máscara de coluna restringem o conteúdo dos dados que um usuário já pode acessar. Políticas DENY determinam se um principal pode realizar uma ação, como gerenciar o controle de acesso, de qualquer forma.
  • As políticas de filtro de linha e máscara de coluna exigem uma função definida pelo usuário (UDF) para implementar o filtro ou a máscara. As políticas DENY não utilizam UDFs. A condição é expressa em linha na definição da política.

O que significa negar GERENCIAR CONTROLE DE ACESSO?​

MANAGE ACCESS CONTROL é um filho do privilégio MANAGE que rege o gerenciamento de acesso, como conceder e revogar privilégios, transferir a propriedade e gerenciar políticas de ABAC. Ele pode ser negado, mas não concedido. Para obter detalhes, consulte GERENCIAR CONTROLE DE ACESSO.

As políticas DENY podem ser usadas para negar o privilégio MANAGE ACCESS CONTROL para impedir que principais especificados, incluindo proprietários de objetos, realizem operações de gerenciamento de acesso nos objetos no escopo de uma política. Isso remove os recursos de gerenciamento de acesso que este privilégio governa, independentemente de como um principal os detém, seja por meio do privilégio MANAGE ou implicitamente por meio da propriedade do objeto.

Nos objetos afetados, um principal negado perde a capacidade de:

Negar MANAGE ACCESS CONTROL não remove a capacidade de um principal de visualizar metadados de objetos. Um principal com MANAGE ou um proprietário de objeto ainda pode ver que o objeto existe e ainda pode exercer todas as outras capacidades que MANAGE, seus outros privilégios ou a propriedade oferecem. Eles perdem apenas as habilidades de gerenciamento de acesso listadas acima.

Negar MANAGE ACCESS CONTROL não fecha todos os caminhos pelos quais um principal pode compartilhar dados. Consulte Considerações sobre compartilhamento de dados.

Exemplos de políticas DENY​

A política a seguir nega MANAGE ACCESS CONTROL em todas as tabelas com a tag sensitive em catalog_a para todos os usuários da account, exceto o grupo data_admins. Os principais afetados, incluindo proprietários de tabelas, perdem a capacidade de conceder ou revogar privilégios, alterar a propriedade ou gerenciar filtros de linha e máscaras de coluna nessas tabelas:

SQL
CREATE POLICY deny_manage_access_control_sensitive_tables
ON CATALOG catalog_a
COMMENT 'Prevent non-admins from managing permissions on sensitive tables'
TO `account users`
EXCEPT `data_admins`
DENY MANAGE ACCESS CONTROL
FOR TABLES
WHEN has_tag('sensitive');

A política a seguir nega MANAGE ACCESS CONTROL em todos os esquemas em catalog_a a um grupo designado, exceto data_admins. Como o DENY é herdado nos níveis inferiores, os principais afetados também perdem a capacidade de gerenciar o acesso aos objetos dentro desses esquemas:

SQL
CREATE POLICY deny_designated_users_catalog_access
ON CATALOG catalog_a
COMMENT 'Prevent designated users from managing access on catalog objects'
TO `designated_users`
EXCEPT `data_admins`
DENY MANAGE ACCESS CONTROL
FOR SCHEMAS;

Tipos protegíveis e privilégios suportados​

As políticas DENY oferecem suporte a um privilégio, MANAGE_ACCESS_CONTROL, nos seguintes tipos protegíveis. Uma política se aplica a um tipo protegível. O Unity Catalog valida o privilégio em relação ao tipo protegível quando você cria a política.

Tipo protegível

MANAGE_ACCESS_CONTROL

Catálogo

✓

Esquema

✓

Tabela

✓

Volume

✓

Função

✓

Modelo

✓

Segredo

✓

Tipo protegível

MANAGE_ACCESS_CONTROL

Catálogo

✓

Esquema

✓

Tabela

✓

Volume

✓

Função

✓

Modelo

✓

Segredo

✓

Esta é a lista de tipos protegíveis suportados na cláusula FOR. Quando uma política é vinculada a um catálogo ou esquema, o DENY é herdado por todos os objetos dentro desse catálogo ou esquema, mesmo objetos cujo tipo não é suportado pela cláusula FOR.

Em SQL, use o tipo protegível no plural após FOR, como DENY MANAGE ACCESS CONTROL FOR TABLES ou FOR SCHEMAS. Formas no singular não são aceitas. Na API REST, defina for_securable_type para a forma no singular, por exemplo TABLE.

Criar uma política DENY​

Você pode criar uma política DENY por meio da interface do usuário do Catalog Explorer, com a instrução SQL CREATE POLICY ou com a API REST.

Para criar uma política DENY, você deve ter MANAGE no catálogo ou esquema onde a política está vinculada, ou ser o proprietário desse objeto protegível.

As políticas DENY devem ser criadas a partir de um catálogo ou esquema. O tipo de política Deny access não está disponível quando você começa a partir de um objeto individual, como uma tabela.

  1. No seu workspace do Databricks, clique em Ícone de dados. Catálogo .

  2. Selecione o catálogo ou esquema onde deseja anexar a política. Políticas DENY só podem ser anexadas no nível de catálogo ou esquema.

  3. Clique na guia Políticas .

  4. Clique em Nova política .

  5. Em Identificação da política , insira um Nome da política e uma Descrição opcional.

  6. Em Entidades e escopo :

    • Em Applied to , selecione os principais (usuários, grupos ou Service Principal) aos quais a política se aplica.
    • Em Exceto para , selecione opcionalmente os principais a serem excluídos da política.
    • Em Escopo , confirme o catálogo ou esquema onde a política está vinculada.

  7. Em Tipo de política , selecione Negar acesso .

  8. Em Objetos protegíveis , selecione o tipo protegível ao qual a política se aplica. Consulte tipos e privilégios suportados.

  9. Em Condição , escolha como definir o escopo da política para objetos seguros do tipo selecionado no catálogo ou esquema:

    • Nenhuma condição aplica a política a todos os objetos protegíveis desse tipo sob o catálogo ou esquema selecionado.
    • Objetos protegíveis que correspondem a qualquer uma dessas tags aplica a política apenas a objetos protegíveis que contenham pelo menos uma das tags regidas selecionadas.
    • Securables que correspondem a uma expressão personalizada permite que você escreva uma expressão baseada em tags para determinar a quais securables a política se aplica. Consulte Condições e funções integradas para ver as funções de condição disponíveis.

  10. Em Privilégios , selecione GERENCIAR CONTROLE DE ACESSO . Este é o único privilégio que as políticas DENY suportam.

  11. Clique em Mostrar código para revisar a instrução SQL equivalente antes de salvar e, em seguida, clique em Criar política .

Editar uma política DENY​

Gerencie políticas DENY na tab Policies do catálogo pai ou esquema ao qual elas estão anexadas.

  1. No seu workspace do Databricks, clique em Ícone de dados. Catálogo .
  2. Selecione o catálogo ou esquema ao qual a política está anexada.
  3. Clique na guia Políticas .
  4. Selecione a política que deseja editar.
  5. Atualize todos os campos que deseja alterar.
  6. Clique em Atualizar política .

Excluir uma política DENY​

Gerencie políticas DENY na tab Policies do catálogo pai ou esquema ao qual elas estão anexadas.

  1. No seu workspace do Databricks, clique em Ícone de dados. Catálogo .
  2. Selecione o catálogo ou esquema ao qual a política está anexada.
  3. Clique na guia Políticas .
  4. Selecione a política.
  5. Clique em Excluir política .

Mostrar políticas​

Use SHOW POLICIES para listar as políticas definidas em um objeto protegível. Use SHOW EFFECTIVE POLICIES para incluir também políticas herdadas de escopos pai, como políticas em nível de catálogo que afetam um esquema.

SQL
SHOW [EFFECTIVE] POLICIES ON { CATALOG | SCHEMA } securable_name

O resultado inclui o nome da política, o tipo de política, o catálogo e o esquema do objeto protegível no qual cada política é definida, além do tipo e do nome completo desse objeto protegível. As políticas DENY são retornadas com o tipo de política DENY juntamente com quaisquer políticas de filtro de linha, máscara de coluna e GRANT anexadas no mesmo escopo. A coluna Table é preenchida apenas quando uma política é definida em uma tabela. Isso se aplica a políticas de filtro de linha e máscara de coluna. Para políticas GRANT e DENY, a coluna Table é NULL.

Exemplo:

SQL
SHOW EFFECTIVE POLICIES ON CATALOG catalog_a;
Text
Policy Name                                  Policy Type  Catalog    Schema  Table  Comment                                                           on_securable_type  on_securable_fullname
-------------------------------------------  -----------  ---------  ------  -----  ----------------------------------------------------------------  -----------------  ---------------------
deny_manage_access_control_sensitive_tables  DENY         catalog_a  NULL    NULL   Prevent non-admins from managing permissions on sensitive tables  CATALOG            catalog_a

SHOW GRANTS não reflete as políticas DENY. Consulte Limitações.

Descrever uma política​

Use DESCRIBE POLICY para visualizar os detalhes de uma política DENY específica. Requer READ METADATA ou MANAGE no objeto seguro de destino, ou propriedade do objeto.

SQL
{ DESC | DESCRIBE } POLICY policy_name ON { CATALOG | SCHEMA } securable_name

O resultado mostra as propriedades da política como pares key-value, incluindo nome, tipo de objeto protegível, nome do objeto protegível, principais, privilégios negados e a condição WHEN.

Definições de política de informação com query Schema​

Você pode fazer query das definições de política DENY no catálogo atual usando INFORMATION_SCHEMA.ABAC_POLICY_DEFINITIONS:

SQL
SELECT *
FROM information_schema.abac_policy_definitions
WHERE policy_type = 'DENY';

Para as colunas disponíveis e exemplos adicionais, consulte ABAC_POLICY_DEFINITIONS.

Cotas de política​

Recursos

Limite

Políticas por metastore

10.000

Políticas por catálogo ou esquema

100

Recursos

Limite

Políticas por metastore

10.000

Políticas por catálogo ou esquema

100

Estas cotas são separadas das cotas para políticas de filtro de linha e máscara de coluna e das cotas para políticas GRANT.

Log de auditoria​

As operações de criação, alteração e exclusão de políticas DENY são registradas sob as mesmas ações createPolicy, deletePolicy, getPolicy e listPolicies que as políticas de filtro de linha e máscara de coluna. Consulte Registro de auditoria para obter exemplos de queries de log de auditoria.

Práticas recomendadas​

  • Use grupos em TO e EXCEPT, não usuários individuais. Adicionar ou remover usuários de um grupo nomeado em uma política altera a quem a política se aplica, sem editar a política.
  • Sempre isente um grupo confiável da política, para que você não bloqueie acidentalmente o acesso de todos. Isso é especialmente importante quando uma política se aplica ao grupo account users. Use a cláusula EXCEPT para nomear um grupo que retém o privilégio, de modo que pelo menos um conjunto de entidades (principals) ainda possa gerenciar o acesso aos objetos afetados.
  • Anexe políticas no menor escopo que cubra os alvos. Um escopo mais amplo traz objetos protegíveis não relacionados para a correspondência de tags da política e pode negar acesso onde você não pretendia.

Considerações sobre o compartilhamento de dados​

Negar MANAGE ACCESS CONTROL bloqueia apenas os recursos que a propriedade e o privilégio MANAGE controlam. Isso não fecha todos os caminhos pelos quais um principal pode compartilhar dados. Uma política DENY não impede o seguinte:

  • Copiando dados com CTAS. Um principal com SELECT em uma tabela e CREATE TABLE em um esquema (juntamente com USE CATALOG e USE SCHEMA) pode copiar os dados para uma nova tabela com CREATE TABLE ... AS SELECT. Para restringir isso, evite conceder CREATE TABLE.
  • Expondo dados por meio de uma view. Um principal com SELECT em uma tabela e CREATE TABLE em um esquema (junto com USE CATALOG e USE SCHEMA) pode criar uma view sobre a tabela. Como uma visualização é executada com os privilégios de seu proprietário, os principais aos quais foi concedido SELECT na visualização podem ler os dados subjacentes sem acesso direto à tabela de origem. Para restringir isso, evite conceder CREATE TABLE, que também autoriza a criação de view.
  • Aplicando ou removendo tags controladas. Um principal com APPLY TAG em um objeto e o privilégio ASSIGN em uma tag controlada ainda pode alterar essa tag no objeto, o que pode afetar políticas baseadas em tags. Para restringir isso, limite quem possui ASSIGN na tag controlada e APPLY TAG no objeto. Consulte Gerenciar permissões em tags controladas.
  • OpenSharing. Um proprietário de compartilhamento com o privilégio necessário sobre um objeto pode adicioná-lo a um compartilhamento. Para restringir isso, evite conceder CREATE SHARE no metastore.
  • Credential vending. Um principal pode compartilhar o acesso a objetos por meio de credential vending. Para restringir isso, evite ativar o acesso a dados externos no metastore e não conceda EXTERNAL USE SCHEMA.
  • Gerenciamento de grupo. Um principal com a permissão Gerenciar em um grupo do Databricks (incluindo administradores de conta e de workspace, que a possuem automaticamente) pode alterar a associação ao grupo, o que pode alterar quem herda o acesso por meio desse grupo. Para restringir isso, limite quem tem a permissão Gerenciar em grupos.

Limitações​

  • Apenas o privilégio MANAGE ACCESS CONTROL pode ser negado. Outros privilégios, como SELECT e MODIFY, não são suportados por políticas DENY.
  • O privilégio MANAGE ACCESS CONTROL pode ser negado, mas não concedido.
  • Uma política pode ser anexada a um catálogo ou a um esquema, não a um objeto protegível individual.
  • Uma política se aplica a um tipo de objeto protegível. Para negar o privilégio em mais de um tipo de objeto protegível no mesmo escopo, crie uma política separada para cada tipo ou crie uma política FOR SCHEMAS para que MANAGE ACCESS CONTROL seja negado em todos os tipos de objetos dentro do esquema.
  • SHOW GRANTS, GetPermissions e GetEffectivePermissions não refletem políticas DENY. Para ver as políticas DENY em vigor, use SHOW EFFECTIVE POLICIES no catálogo ou esquema do objeto.

Mais informações​

Nesta página