Utilize RBAC com ABAC

Importante

O RBAC está em pré-visualização pública. O ABAC está geralmente disponível. Esta página descreve como os dois trabalham em conjunto.

O controlo de acesso baseado em funções (RBAC) e o controlo de acesso baseado em atributos (ABAC) no Catálogo Unity são controlos complementares concebidos para funcionar em conjunto. Respondem a diferentes perguntas:

• O RBAC controla com que identidade um utilizador atua numa sessão. Um utilizador assume uma função para agir com as permissões dessa função em vez das suas próprias. Use o RBAC para dar a um utilizador vários conjuntos de permissões distintos entre os quais alterna explicitamente — por exemplo, separando o acesso entre ensaios clínicos, projetos ou níveis de sensibilidade.
• O ABAC controla que dados a identidade ativa pode ver, linha a linha ou coluna a coluna. As políticas são anexadas aos dados através de tags governadas e aplicam-se à identidade que executa a consulta. Use ABAC para filtragem ou mascaramento consistente em várias tabelas orientadas por atributos de dados.

O RBAC define a identidade ativa da sessão, e o ABAC avalia as suas políticas em função dessa identidade. Esta página aborda como essa interação se manifesta na prática, o comportamento das funções SQL relacionadas com identidade e padrões de uso combinado.

Como as funções de identidade se comportam ao assumir um papel

As funções SQL do Unity Catalog relacionadas com a identidade são resolvidas com base na identidade ativa da sessão, e não no utilizador subjacente autenticado. Quando um utilizador assume uma função, a identidade da sessão ativa torna-se a função:

Function	Quando o utilizador age como a sua própria identidade de utilizador	Quando o utilizador assume um papel
current_user()	Devolve o nome de utilizador do utilizador	Retorna o nome da função assumida
is_member(group)	Retorna true se o utilizador for membro do grupo (um grupo local de espaço de trabalho, ou um grupo de contas atribuído ao espaço de trabalho)	Retorna true apenas se a função assumida for ela própria um membro de group. Devolve false para os grupos aos quais o utilizador subjacente pertence, mas aos quais a função assumida não pertence.
is_account_group_member(group)	Retorna true se o utilizador for membro do grupo de nível de conta	O mesmo que is_member: retorna true apenas com base na pertença ao grupo do papel assumido, não na do utilizador subjacente.

As políticas ABAC que referenciam estas funções avaliam contra o papel assumido, não contra o utilizador. O papel assumido é a identidade ativa para avaliação de políticas ABAC, resolução de subsídios do Catálogo Unity e atribuição de auditoria. Como resultado, assumir um papel altera o comportamento das políticas e opiniões existentes que foram construídas em torno da identidade de cada utilizador.

Note

Uma função não é automaticamente membro de si mesma. Quando um utilizador assume o papel G, current_user() devolve G, mas is_member('G') e is_account_group_member('G') devolvem false, a menos que G tenha sido explicitamente adicionado como membro de si próprio. Para fazer corresponder a função assumida numa política, compare com current_user() em vez de testar a pertença com is_member ou is_account_group_member.

Armadilha comum: vistas de segurança ao nível das linhas construídas sobre current_user()

Um padrão comum entre o ABAC e os filtros de linhas ao nível da tabela consiste em filtrar linhas fazendo uma junção com uma tabela de provisionamento (também chamada tabela de mapeamento ou lista de controlo de acesso) indexada pelo nome de utilizador devolvido por current_user(). Por exemplo:

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

Quando o mesmo utilizador assume um papel, current_user() deixa de devolver o seu nome de utilizador. Devolve o nome da função. Como a função não está na tabela de provisionamento, o filtro não devolve quaisquer linhas e o utilizador fica aparentemente sem acesso aos dados que lhe foram concedidos.

Adicionar a função à tabela de aprovisionamento

Trate a função como outro principal nos seus dados de provisionamento: insira uma linha por cada função com as instalações (ou outros atributos) que a função deve poder ver. O filtro verifica então se a identidade ativa corresponde ao utilizador ou à função assumida.

Padrões de uso combinado

Seguem-se exemplos de como os clientes utilizam o RBAC e o ABAC em conjunto para resolver problemas reais de controlo de acessos. Estes são pontos de partida, não receitas exaustivas.

Filtros de linha por projeto baseados no papel assumido

Filtrar linhas por projeto é uma necessidade comum em investigação de ensaios clínicos, marketing por contrato, consultoria para clientes e outros contextos onde uma equipa trabalha em vários projetos isolados. O exemplo seguinte utiliza ensaios clínicos, mas o padrão generaliza-se para qualquer isolamento de dados por projeto.

Uma organização de investigação clínica realiza vários ensaios simultâneos, cada um com o seu próprio papel de acesso. Marque cada tabela com o identificador do projeto. Os utilizadores veem apenas as linhas relativas ao projeto cuja função têm atualmente atribuída.

Configuração:

• As tabelas em clinical_trials.* têm uma coluna project_id marcada com a chave etiqueta governadaproject.
• Cada projeto tem um papel de acesso correspondente chamado role-<project> (por exemplo, role-alpha, role-beta).
• Os utilizadores têm a permissão Assumir apenas nas funções dos projetos em que trabalham.

Filtro de linha UDF:

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

Política:

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

Esta UDF correlaciona a identidade ativa com o valor da etiqueta project de cada linha, pelo que cláusulas direcionadas ao principal, como TO / EXCEPT, não conseguem expressar isso — essas têm como alvo os principais, e não o conteúdo da linha. Como explica a orientação sobre direcionamento por principal, prefira TO / EXCEPT para um âmbito simples por principal e reserve as funções de identidade dentro de uma UDF para casos como este, em que uma única regra depende tanto da identidade ativa como do conteúdo da linha.

Uma única política abrange todos os projetos: USING COLUMNS (project) transmite o valor da etiqueta project de cada linha para a UDF, pelo que não é necessária uma política separada para cada projeto. Para a forma geral desta técnica — gerar o acesso a linhas a partir de uma tabela de consulta em vez da correspondência de nomes de função — veja Usar tabelas de mapeamento para controlo dinâmico de acesso.

Comportamento:

• Um utilizador que age com a sua identidade de utilizador não vê quaisquer linhas em nenhuma tabela clinical_trials. current_user() devolve o seu nome de utilizador, que nunca corresponde ao role-* padrão de nomeação. Esta é a negação padrão pretendida.
• Um utilizador que assume role-alpha só vê linhas em que project_id é igual a alpha. Mudar para role-beta troca os dados visíveis sem ter de voltar a consultar mais nada.

Mascaramento de PII flexibilizado para utilizadores que desempenham uma função designada

Por defeito, as colunas de PII (SSN, email, telefone) aparecem mascaradas para todos. Para ver os valores brutos, o utilizador deve assumir explicitamente uma função designada com autorização para aceder a informações de identificação pessoal (PII). Os registos de auditoria registam o evento de assunção de funções, por isso "Precisava de ver PII reais" torna-se um opt-in auditável em vez de uma permissão ambiental.

Configuração:

• As colunas sensíveis são etiquetadas com a chave etiqueta governadapii (valores permitidos, como ssn, email, phone).
• É concedida aos utilizadores autorizados a visualizar dados PII em bruto uma função de acesso com o nome role-pii-cleared Assume.

Column mask UDF (estática — a política tem como alvo quais os princípios a mascarar):

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

Política:

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 EXCEPT cláusula exclui role-pii-cleared completamente da política, pelo que a UDF nunca é invocada quando esse papel é a identidade ativa. Veja Prefira TO/EXCEPT para a definição do alvo principal para obter orientações gerais sobre a definição do alvo principal através de TO / EXCEPT.

Comportamento:

• Um utilizador que utiliza a sua identidade de utilizador vê *** em todas as colunas de PII. Este é o estado predefinido para todos, incluindo os utilizadores que têm a permissão para assumir em role-pii-cleared.
• Após assumir role-pii-cleared, a política deixa de se aplicar à sessão, e o mesmo utilizador vê os valores brutos.
• Audite entradas do registo da sessão identity_metadata.run_as = role-pii-cleared, para que os revisores possam ver exatamente quando as PII foram desmascaradas e por quem.

Políticas de nível de sensibilidade que variam consoante o papel assumido

Os dados são classificados em níveis de sensibilidade (internal, confidential, restricted). Cada nível tem uma função de acesso correspondente, sendo que restricted implica também acesso a confidential e internal. Um filtro UDF de um único filtro de linha limita a visibilidade da linha ao comparar o nível de cada linha com o papel assumido pelo utilizador.

Configuração:

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

Filtro de linha UDF:

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

Política:

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 própria, esta UDF compara current_user() com cada nome de função, em vez de testar a associação com is_account_group_member(). Veja a nota acima para saber porque é que os testes de adesão não correspondem ao papel assumido. Consulte Considerações de desempenho para políticas de filtro de linhas e de máscara de coluna para conhecer as características de desempenho das funções identidade em UDFs.

Comportamento:

• Um utilizador que utiliza a sua identidade de utilizador não vê quaisquer linhas. O ramo ELSE FALSE abrange tudo o que não seja uma das três funções. Tal como no exemplo acima, relativo a cada projeto, este é o comportamento predefinido de recusa pretendido.
• Partindo do princípio de que role-sens-internal mostra apenas internal linhas.
• Partindo do princípio de que role-sens-confidential revela internal e confidential linhas.
• Partindo do princípio de que role-sens-restricted revela todas as linhas.

Os utilizadores assumem o nível mais alto de que precisam para a sessão; O filtro exclui automaticamente tudo acima desse nível sem exigir que o utilizador saiba quais as tabelas que contêm que classificações.

Atribuição de auditoria

Tanto as avaliações de políticas ABAC como as consultas subjacentes respeitam a atribuição RBAC run_as / run_by. As entradas do registo de auditoria registam identity_metadata.run_by como o utilizador que efetua a autenticação e identity_metadata.run_as como a função assumida, independentemente das políticas ABAC aplicadas durante a avaliação. Consulte a referência da tabela do sistema de registo de auditoria para o esquema completo do registo de auditoria.

Passos seguintes

• Acesso exclusivo do modelo: Aplique padrões para configurar acesso exclusivo usando um grupo local da conta ou um grupo sincronizado a partir do Microsoft Entra ID. Ver acesso exclusivo ao modelo.
• Mudar de funções: Assumir um papel usando o trocador de papéis, clusters dedicados de modo de acesso, a CLI, a API ou ferramentas de BI de terceiros. Consulte Mudar de função.
• Gerir permissões de «Assume»: Conceda ou revogue «Assume» a um grupo para que os utilizadores possam assumir a função correspondente. Consulte Gerir permissões num grupo.
• Revise os conceitos centrais do ABAC: Saiba como funcionam as etiquetas governadas, políticas e avaliação de políticas. Veja Controlo de acesso baseado em atributos no Unity Catalog.