Use RBAC com ABAC

info

Visualização

RBAC está em Pré-lançamento público. ABAC está disponível ao público geral. Esta página descreve como os dois funcionam em conjunto.

Role-based access control (RBAC) e controle de acesso baseado em atributos (ABAC) no Unity Catalog são controles complementares projetados para funcionar juntos. Eles respondem a perguntas diferentes:

• O RBAC controla a identidade que um usuário assume em uma sessão. Um usuário assume uma função para atuar com as permissões dessa função, em vez das suas próprias. Utilize o RBAC para conceder a um usuário vários conjuntos de permissões distintos, que ele alterna explicitamente — por exemplo, separando o acesso entre estudos clínicos, projetos ou níveis de sensibilidade.
• O ABAC controla quais dados a identidade ativa pode ver, linha por linha ou coluna por coluna. As políticas se anexam aos dados por meio de tags governadas e se aplicam a qualquer identidade que execute a query. Use o ABAC para filtragem ou mascaramento consistente em muitas tabelas impulsionadas por atributos de dados.

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

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
current_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 membro do grupo (um grupo local do workspace ou um grupo de contas 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 membro do grupo de nível de account.	O mesmo que is_member: retorna true somente com base nas associações de grupo da função assumida, e não nas do usuário subjacente.

Função	Quando o usuário age como sua identidade de usuário.	Quando o usuário assume uma função
current_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 membro do grupo (um grupo local do workspace ou um grupo de contas 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 membro do grupo de nível de account.	O mesmo que is_member: retorna true somente com base nas associações de grupo da função assumida, e não nas do usuário subjacente.

As políticas ABAC que se referem a essas funções são avaliadas em relação à **função assumida**, e não ao usuário. 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. Como resultado, assumir uma função altera o comportamento de políticas e views existentes que foram construídas em torno da identidade por usuário.

nota

Uma função não é automaticamente um membro de si mesma. Quando um usuário assume a função G, current_user() retorna G, mas is_member('G') e is_account_group_member('G') retornam false, a menos que G tenha sido explicitamente adicionado como membro de si mesmo. Para corresponder à função assumida em uma política, compare com current_user() em vez de testar a participação com is_member ou is_account_group_member.

Armadilha comum: views de segurança em nível de linha construídas em current_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 current_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 = current_user()
    AND p.facility_id = facility_id
);

Quando o mesmo usuário assume uma função, current_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 nenhuma linha 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

A seguir, estão exemplos de como os clientes usam RBAC e ABAC em conjunto para resolver problemas reais de controle de acesso. Estes são pontos de partida, não receitas exaustivas.

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

A filtragem de linhas por projeto é uma necessidade comum em pesquisa de ensaios clínicos, marketing de contratos, consultoria de clientes e outras configurações onde uma equipe trabalha em vários projetos isolados. O exemplo a seguir utiliza ensaios clínicos, mas o padrão se generaliza para qualquer isolamento de dados por projeto.

Uma organização de pesquisa clínica executa diversos testes concorrentes, cada um em sua própria função de acesso. Tag cada tabela com o identificador do projeto. Os usuários veem apenas as linhas do projeto cuja função eles assumiram atualmente.

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 permissão para assumir somente as funções dos projetos em que trabalham.

Filtro de linha UDF:

SQL

CREATE FUNCTION project_match(project_id STRING) RETURNS BOOLEAN
DETERMINISTIC
RETURN current_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);

Esta UDF correlaciona a identidade ativa com o valor da tag project de cada linha, então cláusulas de direcionamento de principal como TO / EXCEPT não podem expressá-lo — elas direcionam principais, não o conteúdo da linha. Conforme a orientação de direcionamento de principal explica, prefira TO / EXCEPT para escopo de principal simples e reserve funções de identidade dentro de uma UDF para casos como este, onde uma única regra depende tanto da identidade ativa quanto do conteúdo da linha.

Uma única política cobre todos os projetos: USING COLUMNS (project) passa o valor da project tag de cada linha para a UDF, então você não precisa de uma política separada por projeto. Para a forma geral desta técnica — direcionando o acesso à linha de uma tabela de pesquisa em vez de correspondência de nome de função — consulte Usar tabelas de mapeamento para controle de acesso dinâmico.

Comportamento:

• Um usuário agindo como sua identidade de usuário não vê nenhuma linha em nenhuma tabela clinical_trials. current_user() retorna seu nome de usuário, que nunca corresponde ao padrão de nomenclatura role-*. Este é o default-deny pretendido.
• Um usuário que assume role-alpha vê apenas as linhas onde project_id é igual a alpha. Alternar para role-beta swap os dados visíveis sem consultar novamente nada mais.

Mascaramento de PII flexibilizado para usuários que atuam como uma função designada.

Por default, as colunas de PII (SSN, email, phone) aparecem mascaradas para todos. Para ver os valores brutos, o usuário deve assumir explicitamente uma função designada aprovada para PII. Os Logs de auditoria registram o evento de assunção de função, portanto "I needed to look at real PII" torna-se uma opção de adesão auditável, em vez de uma permissão ambient.

Configuração:

• Colunas confidenciais são marcadas com a key pii da tag governada (valores permitidos como ssn, email, phone).
• Uma função de acesso chamada role-pii-cleared recebe permissão de assunção para os usuários que estão autorizados a visualizar PII bruta.

UDF de máscara de coluna (estática — a política visa quais entidades mascarar):

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 PII. Este é o estado default para todos, incluindo usuários que têm permissão de Assumir 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.
• As entradas de Logs de auditoria para o registro de sessão identity_metadata.run_as = role-pii-cleared, para que os revisores possam ver exatamente quando as PII foram reveladas e por quem.

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 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:

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, esta UDF compara current_user() com cada nome de função em vez de testar a associação com is_account_group_member(). Consulte a observação acima para entender 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 agindo como sua identidade de usuário vê nenhuma linha . A branch ELSE FALSE corresponde a qualquer coisa que não seja uma das três funções. Como no exemplo por projeto acima, esta é a negação default intencional.
• 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 mais alto de que precisam para a sessão; o filtro exclui automaticamente tudo acima desse nível sem exigir que o usuário saiba quais tabelas contêm quais classificações.

Atribuição de auditoria

Ambas as avaliações de política ABAC e as queries subjacentes respeitam a atribuição RBAC run_as / run_by. As entradas de log de auditoria registram identity_metadata.run_by como o usuário autenticador e identity_metadata.run_as como a função assumida, independentemente de quais políticas ABAC foram aplicadas durante a avaliação. Consulte Referência da tabela do sistema de log de auditoria para o esquema completo do log de auditoria.

Próximos passos

• **Acesso exclusivo ao modelo**: Aplique padrões para configurar acesso exclusivo usando um grupo local da account ou um grupo sincronizado do seu provedor de identidade. Consulte Acesso exclusivo de modelo.
• Switch roles : Assuma uma função usando o role switcher, clusters de modo de acesso dedicado, a CLI, a API ou ferramentas de BI de terceiros. Consulte Switch roles.
• **Gerenciar permissões de Assumir**: Conceda ou revogue a permissão de Assumir em um grupo para que os usuários possam assumir a função correspondente. Consulte Gerenciar permissões em um grupo.
• Revisar os Conceitos Fundamentais de ABAC : Saiba como as tags governadas, políticas e a avaliação de políticas funcionam. Ver controle de acesso baseado em atributos no Unity Catalog.