Tutorial: acesso exclusivo ao modelo com RBAC

Use role-based access control (RBAC) para aplicar acesso exclusivo aos datasets que devem permanecer separados uns dos outros. Quando cada dataset só pode ser acessado através de sua função designada, usuários e agentes de AI devem assumir essa função para acessá-lo. Para acessar outro dataset, eles devem trocar de função, para que uma única query não possa combinar dados entre casos de uso, projetos, ensaios clínicos ou clientes. Combinar datasets que devem permanecer separados às vezes é chamado de join tóxico .

Cenário

Um pesquisador trabalha em dois ensaios clínicos em um workspace. Ele precisa ter acesso a ambos os ensaios, mas seu trabalho em um ensaio não deve usar os dados do outro ensaio. Você configura uma função separada para cada ensaio, testa queries permitidas e negadas, e restringe o compartilhamento de ativos de workspace criados como cada função.

O pesquisador permanece atribuído ao Workspace e pode entrar no Workspace como si mesmo. Para exigir uma função para entrada no workspace, consulte Tutorial: exigir que os usuários assumam uma função para acesso ao workspace.

O exemplo usa dois tipos de grupos. Estes são rótulos explicativos, não terminologia formal do Databricks:

• Função de acesso : Um grupo vazio que mantém permissões sobre os dados de um trial. Você cria role-study-1 e role-study-2. Mantenha-os vazios. Os membros herdam as permissões de um grupo, portanto um membro pode ler os dados sem assumir uma função.
• Grupo de membros : trial-researchers, cujos membros têm permissão para assumir ambas as funções de acesso. Ele detém a permissão de Assumir, não permissões nos dados de teste. Um grupo de membros é opcional. Você também pode conceder a permissão de Assumir diretamente a usuários individuais ou Service Principal do Databricks.

O pesquisador pode alternar entre funções, mas cada função só pode ler a tabela do seu próprio estudo:

No diagrama, o grupo Estudo 1 corresponde a role-study-1 e o grupo Estudo 2 corresponde a role-study-2.

Pré-requisitos

• Um workspace habilitado para o Unity Catalog com RBAC habilitado. Veja Habilitar RBAC.
• Permissões de administrador de account ou administrador de workspace para criar funções, conceder a permissão Assumir e gerenciar atribuições de workspace. Consulte Quem pode gerenciar grupos?.
• Permissões de administrador do workspace para configurar direitos, acesso ao compute e restrições de compartilhamento.
• Um catálogo de teste existente com armazenamento gerenciado, acessível a partir do workspace. O administrador que cria os dados deve ser o proprietário do catálogo. Este tutorial usa trials com novos esquemas study_1 e study_2. Use um catálogo sem permissões amplas que dariam ao pesquisador ou a qualquer uma das funções acesso a ambos os datasets. Consulte Criar catálogos.
• Um SQL warehouse com Can use concedido ao proprietário do catálogo que cria os datasets de teste. A pessoa que concede acesso ao warehouse precisa de permissões de administrador de workspace ou Can gerenciar no warehouse.
• Um grupo account contendo os pesquisadores, chamado trial-researchers neste exemplo. Um dos seus membros participa da validação usando o seu próprio sign-in. Este pesquisador não deve ser um administrador, proprietário de catalog ou membro de um grupo com acesso amplo a dados.
• Uma pasta de workspace para o notebook de teste de cada função. O admin do workspace configura o acesso a essas pastas no passo 3.
• Para o passo 8, um leitor de auditoria configurado como descrito em Verificar atribuição de auditoria.

Substitua seus próprios nomes de catálogo, grupo e workspace por toda parte. Use dados de teste fictícios e novos esquemas e funções para que a limpeza não afete outras cargas de trabalho.

o passo 1: Criar os datasets de teste

Se qualquer esquema já existir, escolha um novo nome de esquema em vez de substituir objetos existentes.

Como proprietário do catálogo, abra o editor de SQL, selecione o warehouse de teste e execução:

SQL

CREATE SCHEMA trials.study_1;
CREATE SCHEMA trials.study_2;

CREATE TABLE trials.study_1.patient_info (
  participant_id STRING,
  outcome STRING
) USING DELTA;

CREATE TABLE trials.study_2.patient_info (
  participant_id STRING,
  outcome STRING
) USING DELTA;

INSERT INTO trials.study_1.patient_info VALUES ('study-1-a', 'improved');
INSERT INTO trials.study_2.patient_info VALUES ('study-2-a', 'unchanged');

Os IDs dos participantes e os resultados são fictícios. Execute as duas queries para verificar se as tabelas existem e se o warehouse pode lê-las:

SQL

SELECT * FROM trials.study_1.patient_info LIMIT 100;
SELECT * FROM trials.study_2.patient_info LIMIT 100;

Cada query retorna uma única linha do seu estudo.

O passo 2: Criar as funções de acesso e conceder permissão de assume

O procedimento principal usa grupos locais de account para as funções de acesso. Os grupos locais de account são úteis quando criar um grupo no Databricks é mais simples do que solicitar um novo grupo ao seu provedor de identidade. O grupo de membros pode ser local de account ou sincronizado a partir do seu provedor de identidade, conforme mostrado neste diagrama:

Crie a primeira função vazia usando um dos métodos:

Account console

1. Como administrador da conta, faça login no console da conta.
2. Na barra lateral, clique em Gerenciamento de usuários .
3. Na guia Grupos , clique em Adicionar grupo .
4. Insira role-study-1. Não adicione membros.
5. Clique em Confirmar .
6. Atribua o grupo ao workspace de teste com Acesso ao workspace e Acesso ao Databricks SQL . Consulte Atribuir um grupo a um workspace.

Workspace admin settings

1. Como administrador do Workspace, log in no Workspace de teste.
2. Clique em seu nome de usuário na barra superior e selecione Configurações .
3. Clique na guia Identidade e acesso .
4. Ao lado de Grupos , clique em Gerenciar .
5. Clique em Adicionar grupo e, em seguida, em Adicionar novo .
6. Insira role-study-1 e selecione acesso ao Workspace e acesso ao Databricks SQL . O passo 3 explica por que este tutorial usa ambos.
7. Clique em Adicionar . Não adicione membros.

Isso também atribui o grupo ao workspace e concede a você a permissão Gerenciar nele.

Conceder a permissão Assume aos pesquisadores

Antes de atribuir os privilégios de dados da função, conceda aos pesquisadores permissão para assumi-la:

Account console

1. Como um administrador account, abra User management > Groups no console account e selecione role-study-1.
2. Clique em Permissões e depois em Conceder acesso .
3. Selecione trial-researchers, selecione Assume e clique em Salvar .

Workspace admin settings

1. Como um administrador do workspace com permissão de Gerenciar na função, abra Configurações > Identidade e acesso no workspace de teste.
2. Ao lado de Grupos , clique em Gerenciar e selecione role-study-1.
3. Clique em Permissões e depois em Conceder acesso .
4. Selecione trial-researchers, selecione Assume e clique em Salvar .

Repita os passos para criar a função e conceder a permissão Assumir para role-study-2. Ambas as funções permanecem vazias. Veja Escolher ou criar uma função para orientação sobre nomeação e criação de grupos baseada em API.

O passo 3: Configurar acesso ao workspace e ao compute

Você atribuiu ambas as funções ao workspace de teste no Passo 2. Como administrador do workspace, verifique se ambas as funções e trial-researchers têm os dois direitos de acesso, incluindo grupos que já foram atribuídos:

• Acesso ao workspace : Concede acesso aos principais recursos do workspace, como notebooks, jobs, modelos e pipelines. Este tutorial usa notebooks para verificar os controles de compartilhamento.
• Acesso ao Databricks SQL : Concede acesso aos recursos do Databricks SQL, incluindo painéis, queries e SQL Warehouse. Este tutorial usa o editor SQL para verificar o acesso aos dados.

Para todos os direitos de acesso e como gerenciá-los, consulte Direitos de acesso.

Se trial-researchers não estiver atribuído, atribua-o ao workspace. Consulte Atribuir um grupo a um workspace.

Mantenha os pesquisadores atribuídos para que eles possam entrar como suas identidades de usuário e alternar de volta após usar uma função.

Conceda a cada grupo acesso ao SQL warehouse:

1. Na barra lateral do workspace, clique em SQL Warehouses .
2. Abra a caixa de diálogo Permissões do warehouse.
3. Adicione cada grupo com Pode usar e, em seguida, salve.

Crie uma pasta de teste separada para cada função em um local do workspace sem acesso herdado amplo. Conceda role-study-1 Pode gerenciar em sua pasta e role-study-2 Pode gerenciar na outra pasta. As funções usam essas pastas para criar notebooks no passo 7. Consulte Gerenciar objetos do workspace e ACLs de pasta.

O passo 4: Conceder a cada função acesso ao seu estudo

Como proprietário do catálogo, execução:

SQL

GRANT USE CATALOG ON CATALOG trials TO `role-study-1`;
GRANT USE SCHEMA ON SCHEMA trials.study_1 TO `role-study-1`;
GRANT SELECT ON TABLE trials.study_1.patient_info TO `role-study-1`;

GRANT USE CATALOG ON CATALOG trials TO `role-study-2`;
GRANT USE SCHEMA ON SCHEMA trials.study_2 TO `role-study-2`;
GRANT SELECT ON TABLE trials.study_2.patient_info TO `role-study-2`;

Não conceda privilégios de trial-data ao trial-researchers. Seus membros recebem a permissão Assume em vez disso.

Revise o acesso direto e herdado antes de testar:

• O pesquisador não deve ter nenhuma outra concessão ou associação a um grupo que permita a leitura de qualquer tabela como sua identidade de usuário.
• Nenhum grupo pai dá a qualquer função acesso a dados do outro estudo.
• Verifique os grants de catálogo e esquema, bem como os grants de tabela. Um grant SELECT em nível de catálogo ou de esquema aplica-se a objetos filhos atuais e futuros e pode tornar ambas as tabelas acessíveis. Consulte Herança de privilégios.

Use a Permissões tab do Catalog Explorer para inspecionar concessões no catálogo, ambos os esquemas e ambas as tabelas. Consulte Gerenciar privilégios no Unity Catalog. Se as concessões compartilhadas impedirem essa configuração, use um catálogo de teste isolado ou um workspace. A remoção de uma concessão compartilhada pode interromper usuários e funções não relacionados.

O passo 5: Restringir o compartilhamento de ativos de workspace pertencentes à função

Sem uma restrição de compartilhamento, um usuário agindo como uma função pode compartilhar ativos do workspace que a função possui. Defina a restrição para ambas as funções:

1. Como administrador do workspace, clique no seu nome de usuário e selecione Settings .
2. Clique em Avançado .
3. Encontre Restringir compartilhamento para grupos e clique no botão editar.
4. Adicione role-study-1 e role-study-2. Mantenha todos os grupos que já estão na lista.
5. Clique em Salvar .

Essa restrição aplica-se enquanto estiver atuando como uma função restrita. Ele controla o compartilhamento de ativos do workspace que a função possui. Ele não controla privilégios em objetos do Unity Catalog e não bloqueia todas as formas de copiar dados. Consulte Controles de compartilhamento de ativos do workspace.

O passo 6: Verificar acesso aos dados como cada identidade

Um de seus pesquisadores conclui essas verificações usando seu próprio login:

1. Entre no workspace de teste e verifique se seu nome de usuário aparece abaixo do nome do workspace.

2. Abra o editor SQL e selecione o warehouse de teste.

3. Execução cada query separadamente:

   SQL

   SELECT * FROM trials.study_1.patient_info LIMIT 100;
   SELECT * FROM trials.study_2.patient_info LIMIT 100;

   Ambas as query falham com erros de permissão.

4. Clique no nome do workspace na barra superior, passe o cursor sobre o workspace atual e selecione role-study-1 no alternador de funções.

5. Depois que o workspace recarregar, verifique o nome da função, abra o SQL editor, selecione o mesmo warehouse e repita ambas as queries. Apenas a query do Estudo 1 é bem-sucedida.

6. Alterne para role-study-2 e repita as query. Somente a query do Estudo 2 é bem-sucedida.

7. Volte para o seu nome de usuário e repita as verificações. Ambas as query foram negadas novamente.

Identidade ativa	Estudar 1 query	Estudo 2 query
Identidade de usuário do pesquisador	Erro de permissão	Erro de permissão
role-study-1	Devolve study-1-a	Erro de permissão
role-study-2	Erro de permissão	Devolve study-2-a

Identidade ativa	Estudar 1 query	Estudo 2 query
Identidade de usuário do pesquisador	Erro de permissão	Erro de permissão
role-study-1	Devolve study-1-a	Erro de permissão
role-study-2	Erro de permissão	Devolve study-2-a

Uma tabela ausente, um warehouse indisponível ou um erro de autenticação não demonstra acesso exclusivo. As verificações do proprietário do catálogo no passo 1 estabelecem que ambas as tabelas existem. Se uma query inesperada for bem-sucedida, revise as permissões e associações do passo 4 antes de continuar.

Para outras maneiras de assumir uma função, consulte Alternar funções RBAC. Alternar funções nesse navegador não altera um perfil ou conexão da CLI do Databricks autenticado separadamente.

o passo 7: Verificar o compartilhamento de ativos do Workspace

O mesmo pesquisador repete estas verificações para cada função:

1. Assuma a função usando o alternador de funções.
2. Em Workspace , clique com o botão direito do mouse na pasta de teste da função e selecione Criar > Notebook .
3. Dê ao notebook o nome do estudo. Você não precisa executar código nele.
4. Verifique se a função é proprietária do novo notebook e tente compartilhá-lo. O compartilhamento fica indisponível enquanto você atua como a função restrita, mesmo com Pode Gerenciar no ativo.

Use um notebook criado enquanto atua como a role, e não um que seja de propriedade do pesquisador. Consulte Criar um notebook e Verificar a restrição.

O passo 8: Verificar atribuição de auditoria

Como leitor de auditoria, faça a execução desta query. Substitua <workspace-id> pelo ID do workspace de teste:

SQL

SELECT event_time, service_name, action_name,
       identity_metadata.run_by, identity_metadata.run_by_display_name,
       identity_metadata.run_as, identity_metadata.run_as_display_name
FROM system.access.audit
WHERE workspace_id = '<workspace-id>'
  AND identity_metadata.run_as_display_name IN ('role-study-1', 'role-study-2')
  AND event_date >= current_date() - INTERVAL 1 DAY
ORDER BY event_time DESC;

Encontre os eventos para as query de teste do pesquisador e a criação de Notebooks. identity_metadata.run_by identifica o pesquisador que iniciou cada evento, e run_as identifica a função usada para autorização. A query filtra em run_as_display_name, o nome legível por humanos da função. Os dados de auditoria são atualizados ao longo do dia, portanto, um evento recente pode não aparecer imediatamente. Consulte Referência de metadados de identidade.

Opcional: Gerenciar as roles de acesso no seu provedor de identidade

Use esta alternativa quando sua organização mantém o gerenciamento do ciclo de vida do grupo em seu provedor de identidade. Sincronize um grupo de função de acesso vazio e um grupo de membros com o Databricks por meio do provisionamento SCIM (System for Cross-domain Identity Management). Consulte Sincronizar usuários e grupos do seu provedor de identidade usando SCIM.

Mantenha cada função de acesso vazia em seu provedor de identidade. Adicionar membros lá sincroniza essas associações com o Databricks, onde os membros herdam privilégios de dados sem assumir a função.

Começar com novos grupos de provedores de identidade

Para usar novos grupos de provedor de identidade em vez das funções local-account no passo 2, conclua os passos:

1. Em seu provedor de identidade, crie um grupo vazio para cada função de acesso.
2. Identifique ou crie o grupo de membros contendo os pesquisadores.
3. Sincronize as roles de acesso e o grupo de membros com sua account Databricks.
4. Conceda ao grupo de membros a permissão Assume em cada role de acesso usando o procedimento no Passo 2.

Reutilizar um grupo de provedores de identidade existente

Se um grupo sincronizado do seu provedor de identidade já tiver os privilégios de dados desejados no Databricks, você poderá manter essas concessões reutilizando o grupo como uma função de acesso:

1. Crie um novo grupo de membros no seu provedor de identidade. Por exemplo, se o grupo existente for clinical-trial-1-ds, crie clinical-trial-1-ds-members.
2. Mova todos os membros do grupo existente para o novo grupo de membros, deixando o grupo existente vazio.
3. Sincronize ambos os grupos com o Databricks e verifique se a função de acesso não possui membros.
4. Conceda ao novo grupo de membros a permissão Assumir na função de acesso. Revise outras concessões ou associações que ainda possam dar aos pesquisadores acesso permanente aos dados.

O grupo existente mantém seus privilégios de dados e permissões de workspace. Você não precisa recriar essas concessões, mas verifique se elas correspondem ao limite de estudo pretendido. Planeje a alteração da associação com os proprietários do grupo porque os usuários perdem as permissões herdadas quando saem do grupo original.

Concluir a configuração e as verificações do workspace

Atribua tanto as roles de acesso quanto o grupo de membros ao workspace e configure os direitos e o acesso ao compute conforme o Passo 3. Para exigir a assunção de uma role para entrar no workspace, consulte Tutorial: Exigir que os usuários assumam uma role para acessar o workspace.

Para novas funções de acesso, conceda acesso aos dados como no Passo 4 e acesso aos ativos do workspace como no Passo 3. Para grupos reaproveitados, revise as concessões existentes em vez de substituí-las.

Verifique se o grupo de membros tem a permissão Assumir em cada função de acesso. Todos os seus membros podem então assumir essa função.

Configure restrições de compartilhamento e repita as verificações de dados, compartilhamento e auditoria dos passos 5 a 8 usando seus nomes de grupo de provedor de identidade e datasets.

Limpar

Para um teste temporário, remova apenas os recursos e concessões criados para este tutorial:

1. Como proprietário do catálogo, verifique se as duas tabelas contêm apenas os dados de teste do tutorial e execução:

   SQL

   DROP TABLE trials.study_1.patient_info;
   DROP TABLE trials.study_2.patient_info;
   DROP SCHEMA trials.study_1 RESTRICT;
   DROP SCHEMA trials.study_2 RESTRICT;

   Os drops de esquema falham se outros objetos permanecerem. Não faça drop de um catálogo ou esquema existente usado por outras workloads.

2. Como administrador do workspace, remova os notebooks e pastas de teste. Revise quaisquer outros ativos de propriedade das funções antes de removê-los.

3. Revogue os grants da permissão Assume e as permissões de recurso criadas para o teste, incluindo os grants de catálogo e warehouse. Remova as atribuições de workspace apenas para teste, preservando o acesso existente dos pesquisadores.

4. Remova as funções de teste de Restringir compartilhamento para grupos , mantendo as outras entradas intactas.

5. Exclua roles vazias recém-criadas somente após verificar se nenhuma carga de trabalho ou ativo ainda as utiliza. Para grupos sincronizados, faça alterações de ciclo de vida em seu provedor de identidade para que a sincronização não recrie grupos excluídos. Mantenha os grupos de membros existentes e seus usuários.

Se você reaproveitou um grupo existente, planeje um rollback separado que restaure suas associações e atribuições originais. Não use a limpeza de test-resource para excluir um modelo de acesso existente.

Próximos passos

• • Gerenciar a permissão de Assumir
  • Gerencie quem pode assumir uma função usando a IU ou a API.
• • Alternar funções RBAC
  • Use o alternador de função, compute dedicado, CLI do Databricks, API ou ferramentas de BI de terceiros.
• • Controle o compartilhamento de ativos do workspace com o RBAC
  • Revise como os controles de compartilhamento de ativos do workspace se aplicam a funções e grupos aninhados.
• • Padrões de uso combinado
  • Aplique filtros de linha ou máscaras de coluna nas tabelas às quais uma função pode acessar.
• • role-based access control (RBAC) limitations
  • Verifique o suporte a recursos, problemas conhecidos e restrições da API de gerenciamento de grupos.