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

Use RBAC com ABAC

O role-based access control (RBAC) define a identidade ativa para uma sessão. Attribute-based access control (ABAC) no Unity Catalog aplica filtros de linha e mascaramento de coluna a essa identidade:

  • RBAC : um usuário assume uma função para agir com as permissões dessa função em vez das suas próprias. Use funções para separar o acesso entre projetos ou níveis de sensibilidade.
  • Políticas de filtro de linha e mascaramento de coluna ABAC : Filtre linhas ou mascare valores de coluna para tabelas que a identidade ativa já pode acessar. As políticas são definidas em objetos protegíveis, como catálogos ou schemas, e usam tags governadas para identificar tabelas e colunas correspondentes. Veja Conceitos principais para attribute-based access control (ABAC).

Como as funções de identidade se comportam ao assumir uma função​

As funções SQL relacionadas à identidade do Unity Catalog são resolvidas em relação à identidade ativa da sessão, e não ao usuário de autenticação subjacente. Quando um usuário assume uma função, a identidade ativa da sessão se torna a função:

Função

Quando o usuário age como sua identidade de usuário.

Quando o usuário assume uma função

session_user()

Retorna o nome de usuário do usuário.

Retorna o nome da função assumida

is_member(group)

Retorna true se o usuário for um membro direto ou indireto de um grupo local de workspace ou de um grupo de account atribuído ao workspace

Retorna true somente se a função assumida for membro de group. Retorna false para grupos dos quais o usuário subjacente é membro, mas a função assumida não é.

is_account_group_member(group)

Retorna true se o usuário for um membro direto ou indireto do grupo de account

Retorna true com base nas associações diretas e indiretas de grupos de account da função assumida, incluindo grupos não atribuídos ao workspace.

Função

Quando o usuário age como sua identidade de usuário.

Quando o usuário assume uma função

session_user()

Retorna o nome de usuário do usuário.

Retorna o nome da função assumida

is_member(group)

Retorna true se o usuário for um membro direto ou indireto de um grupo local de workspace ou de um grupo de account atribuído ao workspace

Retorna true somente se a função assumida for membro de group. Retorna false para grupos dos quais o usuário subjacente é membro, mas a função assumida não é.

is_account_group_member(group)

Retorna true se o usuário for um membro direto ou indireto do grupo de account

Retorna true com base nas associações diretas e indiretas de grupos de account da função assumida, incluindo grupos não atribuídos ao workspace.

A função assumida é a identidade ativa para avaliação de políticas ABAC, resolução de concessão do Unity Catalog e atribuição de auditoria. Portanto, assumir uma função pode alterar o comportamento de políticas e views existentes criadas em torno da identidade do usuário.

nota

Uma função não é um membro de si mesma. Quando um usuário assume a função G, session_user() retorna G, mas is_member('G') e is_account_group_member('G') retornam false. Para corresponder à função assumida em uma política, compare com session_user() em vez de testar a associação usando is_member ou is_account_group_member.

A referência SQL recomenda session_user() em vez do alias current_user() descontinuado. Use is_account_group_member() para testar a associação ao grupo account. Veja função session_user e função is_member.

Armadilha comum: views de segurança em nível de linha construídas em session_user()​

Um padrão comum em ABAC e filtros de linha no nível da tabela é filtrar linhas por meio de uma junção com uma tabela de provisionamento (também chamada de tabela de mapeamento ou lista de controle de acesso) com chave no nome de usuário retornado por session_user(). Por exemplo:

SQL
CREATE OR REPLACE FUNCTION facility_filter(facility_id STRING)
RETURN EXISTS (
  SELECT 1
  FROM governance.user_facility_provisioning p
  WHERE p.user = session_user()
    AND p.facility_id = facility_filter.facility_id
);

A referência facility_filter.facility_id identifica o parâmetro da função. Sem o nome da função, facility_id resolve para a coluna da tabela de provisionamento em vez disso. Consulte Resolução de nome.

Quando o mesmo usuário assume uma função, session_user() não retorna mais seu nome de usuário. Ele retorna o nome da função. Como a função não está na tabela de provisionamento, o filtro não retorna linhas e o usuário parece perder o acesso aos dados que lhe foram concedidos.

Adicionar a função à tabela de provisionamento​

Trate a função como outra entidade principal em seus dados de provisionamento: insira uma linha por função com os recursos (ou outros atributos) que a função deve ver. O filtro então corresponde se a identidade ativa é o usuário ou a função assumida.

Padrões de uso combinado​

Os exemplos a seguir combinam RBAC com filtros de linha ABAC e máscaras de coluna.

Requisitos​

Antes de usar os exemplos, conclua os passos:

  • Use compute compatível com ABAC.
  • Crie as tags governadas e conceda as permissões necessárias para aplicar tags, criar funções definidas pelo usuário (UDFs) e gerenciar políticas. Consulte Separação de funções e permissões.
  • Conceda às identidades de consulta USE CATALOG, USE SCHEMA e SELECT nos dados relevantes. Os filtros de linha e as máscaras de coluna não concedem esses privilégios. Consulte Privilégios de uso.
  • Crie cada UDF de exemplo em um esquema onde você tenha permissão e use esse esquema como o esquema atual ao criar sua política, ou qualifique totalmente o nome da função. Para um passo a passo completo, consulte Tutorial: configurar ABAC com SQL.

Filtros de linha por projeto baseados na função assumida​

Uma organização de pesquisa clínica realiza vários testes concorrentes, cada um com sua própria função de acesso. Um filtro de linha limita cada função aos dados de seu teste. O mesmo padrão se aplica a outros projetos que precisam de acesso separado aos dados. Marque a coluna project_id em cada tabela com a key de tag governada project. Os valores da coluna identificam o projeto para cada linha.

Configuração:

  • Tabelas em clinical_trials.* têm uma coluna project_id marcada com a tag governada key project.
  • Cada projeto tem uma função de acesso correspondente chamada role-<project> (por exemplo, role-alpha, role-beta).
  • Os usuários têm a permissão Assumir apenas nas funções dos projetos em que trabalham.

Filtro de linha UDF:

SQL
CREATE FUNCTION project_match(project_id STRING) RETURNS BOOLEAN
DETERMINISTIC
RETURN session_user() = CONCAT('role-', project_id);

Política:

SQL
CREATE POLICY per_project_row_filter
ON CATALOG clinical_trials
ROW FILTER project_match
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('project') AS project
USING COLUMNS (project);

Este UDF compara a identidade ativa com o valor da coluna project_id de cada linha. MATCH COLUMNS usa a tag governada para encontrar essa coluna. As cláusulas TO e EXCEPT selecionam as principals às quais uma política se aplica. Eles não comparam valores de linha. Como explicado nas diretrizes de direcionamento principal, prefira TO / EXCEPT para escopo principal simples e reserve funções de identidade dentro de um UDF para casos como este, em que uma única regra depende da identidade ativa e do conteúdo da linha.

Uma única política cobre cada projeto: USING COLUMNS (project) passa o valor de cada linha da coluna correspondente para o UDF. O alias project nomeia a coluna correspondente, não um valor de tag. Para um exemplo que usa uma tabela de pesquisa para determinar o acesso à linha, consulte Usar tabelas de mapeamento para controle de acesso dinâmico.

Comportamento:

  • Um usuário atuando como sua identidade de usuário não vê linhas em nenhuma tabela clinical_trials. session_user() retorna o nome de usuário deles. Escolha nomes de funções que não possam corresponder ao nome de usuário de um usuário ou ao ID de aplicativo de um Databricks service principal.
  • Um usuário que assume role-alpha vê apenas linhas onde project_id é igual a alpha. Depois de mudar para role-beta, execução a query novamente para ver as linhas onde project_id é igual a beta.

Mascarar informações de identificação pessoal, a menos que uma função seja assumida​

Neste exemplo, informações de identificação pessoal (PII), como números do Seguro Social e endereços de email, aparecem mascaradas por default. Para ver os valores brutos, um usuário precisa assumir role-pii-cleared. Os eventos de auditoria identificam a função usada para acessar os dados e a identidade que iniciou o evento.

Configuração:

  • Marque colunas confidenciais com a key de tag governada pii (valores permitidos como ssn, email, phone).
  • Crie o grupo role-pii-cleared sem membros. Conceda a permissão Assume nesse grupo.
    • Usuários autorizados a view PII bruta podem assumir essa função de acesso para view dados não mascarados. Não adicione membros ao grupo, pois a cláusula EXCEPT da política permitiria que eles visualizassem dados não mascarados sem assumir a função.

Crie o UDF de mascaramento de coluna usando este SQL:

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

Política:

SQL
CREATE POLICY pii_default_mask
ON CATALOG customer_data
COLUMN MASK mask_pii
TO `account users`
EXCEPT `role-pii-cleared`
FOR TABLES
MATCH COLUMNS has_tag('pii') AS pii_col
ON COLUMN pii_col;

A cláusula EXCEPT exclui role-pii-cleared da política por completo, portanto, a UDF nunca é invocada quando essa função é a identidade ativa. Consulte Preferir PARA/EXCETO para direcionamento de principal para a orientação geral sobre o direcionamento de principal por meio de TO / EXCEPT.

Comportamento:

  • Um usuário agindo como sua identidade de usuário vê *** em cada coluna de PII. Este é o estado default para todos, incluindo usuários que têm a permissão Assume em role-pii-cleared.
  • Após assumir role-pii-cleared, a política não se aplica mais à sessão, e o mesmo usuário vê os valores brutos.
  • Os eventos de auditoria para essas queries identificam a role de autorização em identity_metadata.run_as e seu nome em identity_metadata.run_as_display_name. Consulte Atribuição de auditoria.

Políticas de camada de sensibilidade que variam por função assumida​

Os dados são classificados em níveis de sensibilidade (internal, confidential, restricted). Cada nível tem uma função de acesso correspondente, com restricted implicando acesso a confidential e internal também. Uma única UDF de filtro de linha controla a visibilidade das linhas comparando o nível de cada linha com a função assumida pelo usuário.

Configuração:

  • As tabelas têm uma coluna sensitivity_level marcada com a tag governada chave sensitivity (valores permitidos: internal, confidential, restricted).
  • Três funções de acesso: role-sens-internal, role-sens-confidential, role-sens-restricted.

Filtro de linha UDF:

SQL
CREATE FUNCTION sensitivity_allowed(row_sensitivity STRING) RETURNS BOOLEAN
DETERMINISTIC
RETURN CASE
  WHEN session_user() = 'role-sens-restricted' THEN TRUE
  WHEN session_user() = 'role-sens-confidential' THEN row_sensitivity IN ('internal', 'confidential')
  WHEN session_user() = 'role-sens-internal' THEN row_sensitivity = 'internal'
  ELSE FALSE
END;

Política:

SQL
CREATE POLICY sensitivity_filter
ON CATALOG corp_data
ROW FILTER sensitivity_allowed
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('sensitivity') AS sens
USING COLUMNS (sens);

Como uma função não é membro de si mesma, este UDF compara session_user() em relação a cada nome de função em vez de testar a associação com is_account_group_member(). Consulte a observação em Como as funções de identidade se comportam ao assumir uma função para saber por que os testes de associação não correspondem à função assumida. Consulte Considerações de desempenho para políticas de filtro de linha e máscara de coluna para características de desempenho de funções de identidade em UDFs.

Comportamento:

  • Um usuário que atua como sua identidade de usuário não vê linhas. A branch ELSE FALSE corresponde a qualquer coisa que não seja uma das três roles.
  • Assumindo que role-sens-internal revela apenas internal linhas.
  • Assumindo role-sens-confidential, revela internal e confidential linhas.
  • Supondo que role-sens-restricted revele todas as linhas.

Os usuários assumem o nível de que precisam para a sessão. O filtro é aplicado às tabelas com a coluna marcada e retorna as linhas permitidas por essa função.

Atribuição de auditoria​

Na tabela do sistema de log de auditoria, identity_metadata.run_by identifica quem iniciou um evento e identity_metadata.run_as identifica a identidade usada para autorização. Os campos correspondentes run_by_display_name e run_as_display_name contêm nomes legíveis por humanos. Para queries feitas de forma interativa ao assumir uma role, elas identificam o usuário e a role, respectivamente. As cargas de trabalho de job podem ter um iniciador diferente. Consulte Definir execução como para um grupo.

Use eventos de auditoria para revisar a atividade sob uma role. Para inspecionar quais políticas se aplicam a uma tabela, use SHOW EFFECTIVE POLICIES conforme descrito em Planejar a avaliação de políticas dinâmicas. Para acesso à auditoria, esquema e disponibilidade, consulte Verificar atribuição de auditoria.

Outros recursos​

Nesta página