Gestão automática de identidades
O gerenciamento automático de identidades permite adicionar usuários e grupos do seu provedor de identidade ao Databricks de forma integrada e sem problemas. Ao usar Microsoft Entra ID, a entidade de serviço e os grupos aninhados também são sincronizados. Quando o gerenciamento automático de identidades está ativado, você pode pesquisar diretamente no espaço de trabalho federado de identidades por usuários e grupos e adicioná-los ao seu workspace. O Databricks usa seu provedor de identidade como fonte de registro, portanto, quaisquer alterações nas associações de grupo são respeitadas no Databricks.
Os usuários também podem compartilhar painéis com qualquer usuário ou grupo em seu provedor de identidade. Quando compartilhados, esses usuários e membros de grupos são adicionados automaticamente à account Databricks ao fazerem login. Eles não são adicionados como membros ao workspace onde o painel está localizado. Os usuários que não têm acesso ao workspace recebem acesso a uma cópia somente para viewde um painel publicado com permissões de dados compartilhados. Para obter mais informações sobre compartilhamento de dashboard, consulte Compartilhar um dashboard.
O provisionamento just-in-time (JIT) está sempre ativado quando o gerenciamento automático de identidade está habilitado e não pode ser desativado. Os novos usuários são provisionados automaticamente no Databricks após o primeiro login. Consulte Provisionamento automático de usuários (JIT).
O gerenciamento automático de identidades não é compatível com espaços de trabalho que não utilizam federação de identidades. Para obter mais informações sobre federação de identidades, consulte Federação de identidades.
Com a visualização do recurso Lista de controle de atributos de identidade habilitada, a gestão automática de identidades também sincroniza um conjunto fixo de atributos de identidade, como title, department e costCenter, do seu provedor de identidade para os usuários da account Databricks. Esses atributos estão em Beta. Para obter mais informações, consulte Atributos de identidade.
Status de Usuário, Entidade de Serviço e Grupo
Quando o gerenciamento automático de identidades está ativado, os usuários e grupos do seu provedor de identidade ficam visíveis no console account e na página de configurações de administração workspace . Ao usar Microsoft Entra ID, a entidade de serviço também fica visível. O status deles reflete a atividade e o estado deles entre seu provedor de identidade e o Databricks:
Status | Significado |
|---|---|
Inativo: Sem uso | Para usuários e entidade de serviço: identidade no provedor de identidade que ainda não fez login no Databricks . Para grupos: o grupo não foi adicionado a um workspace. |
Ativas | O recurso Identidade está ativo no Databricks. |
Ativo: Removido de [IdP] | Anteriormente ativo no Databricks, mas excluído do provedor de identidade. O Databricks desativa automaticamente esses usuários durante a próxima sincronização de identidades. Não consigo log in ou autenticar-me nas APIs. |
Desativado | A identidade foi desativada no provedor de identidade ou o Databricks desativou automaticamente a identidade após a exclusão do provedor de identidade. Não consigo log in ou autenticar-me nas APIs. |
Negado | A identidade foi adicionada à lista de bloqueio de acesso account . O Databricks define a identidade como inativa. Não consigo log in, usar access tokens pessoal ou aparecer em diálogos de compartilhamento. Consulte Negar acesso de identidades à sua account. |
O rótulo de status Ativo: Removido de [IdP] inclui o nome do seu provedor de identidade. Por exemplo, Ativo: removido do EntraID .
Como prática recomendada de segurança, Databricks recomenda revogar access tokens pessoal para usuários desativados e ativos: removidos do [IdP] . Quando os usuários são excluídos do provedor de identidade, Databricks desativa automaticamente suas contas, mas não revoga automaticamente tokens.
Identidades gerenciadas por meio de gerenciamento automático de identidades são exibidas como Externas no Databricks. Identidades externas não podem ser atualizadas usando a interface do usuário do Databricks.
compartilhamento e atribuição de permissões
Quando o gerenciamento automático de identidades está ativado, você pode selecionar usuários do seu provedor de identidade ao compartilhar ou atribuir permissões em todo Databricks. Ao usar Microsoft Entra ID, a entidade de serviço também está disponível.
Para grupos, o comportamento de compartilhamento varia de acordo com o tipo de ativo:
- Ativos no nível da account: os grupos estão disponíveis ao compartilhar ou atribuir permissões a ativos no nível da account, como Databricks Apps, objetos do Unity Catalog, dashboards de AI/BI, Genie Agents e atribuição de workspace.
- Ativos em nível de espaço de trabalho: Para compartilhar ativos em nível workspace(como Notebook, Job, SQL Warehouse, alertas e arquivos) com grupos, os administradores workspace devem primeiro adicionar o grupo diretamente ao workspace.
Gerenciamento automático de identidade versus provisionamento SCIM
Quando o gerenciamento automático de identidades está ativado, todos os usuários, grupos e associações de grupos são sincronizados do seu provedor de identidade para o Databricks, tornando o provisionamento SCIM desnecessário. Se você mantiver o provisionamento SCIM em execução em paralelo, SCIM continuará gerenciando as identidades que foram adicionadas usando o provisionamento SCIM . Não gerencia identidades que não foram adicionadas usando o provisionamento SCIM .
A Databricks recomenda o uso do gerenciamento automático de identidades. A tabela abaixo compara o recurso de gerenciamento automático de identidade com o recurso de provisionamento SCIM .
Recursos | Gestão automática de identidades | Provisionamento SCIM |
|---|---|---|
Sincronizar usuários | ✓ | ✓ |
Grupos de sincronização | ✓ | ✓ (Apenas para membros diretos) |
Sincronizar grupos aninhados | ✓ (Somente para ID Microsoft Entra) | |
Sincronizar entidade de serviço | ✓ (Somente para ID Microsoft Entra) | |
Disponível por default no Databricks | ✓ | |
Requer federação de identidades | ✓ |
Como a gestão automática de identidades corresponde a identidades
Quando a gestão automática de identidades sincroniza uma identidade, ela corresponde essa identidade ao usuário, Service Principal ou grupo correto no seu provedor de identidade. A informação que o Databricks usa para encontrar a correspondência depende de como a sincronização é acionada.
O seguinte descreve a correspondência para o Microsoft Entra ID. O Databricks aplica o mesmo princípio a todos os provedores de identidade: ele faz a correspondência com base em um identificador estável do provedor de identidade quando um está disponível e, caso contrário, faz a correspondência com base no nome de usuário do Databricks. O nome principal do usuário (UPN), o email e os detalhes de convidado B2B abaixo são específicos do Microsoft Entra ID.
Correspondência durante o login
Quando um usuário faz login por meio do Single Sign On, o Databricks recebe um token do seu provedor de identidade. Quando o token inclui o Object ID do usuário, o Databricks faz a correspondência com base no Object ID, que é um identificador estável e exclusivo. Esta é a correspondência mais confiável.
Se o token de entrada inclui o ID do objeto depende da sua configuração de Single Sign On. O Databricks recomenda configurar seu aplicativo de Single Sign On para incluir a ID de objeto nas declarações de token, para que o login possa corresponder ao identificador estável. Quando os tokens não incluem uma ID de objeto, o Databricks recorre ao nome de usuário no token e corresponde ao usuário do Microsoft Entra ID por UPN ou email, conforme descrito em Correspondência por nome de usuário.
Correspondência por nome de usuário
Alguns fluxos não incluem um token de login, como a criação ou atualização de um contexto de permissão, a autenticação de access token pessoal, as ações do console da account e a sincronização de identidade em segundo plano. Nesses fluxos, o Databricks faz a correspondência com base no nome de usuário do Databricks. O sistema pesquisa o ID do Microsoft Entra em busca de um usuário cujo nome principal de usuário (UPN) ou email seja igual ao nome de usuário do Databricks e dá preferência a uma correspondência de UPN em vez de uma correspondência de email.
Por exemplo, se um usuário do Databricks tiver o nome de usuário alice@contoso.com, o Databricks primeiro procura um usuário do Microsoft Entra ID com o UPN alice@contoso.com. Se nenhum UPN corresponder, ele procura um usuário cujo e-mail seja alice@contoso.com.
Correspondência ao resolver e criar usuários
Ao compartilhar um objeto com uma identidade do Microsoft Entra ID que ainda não está no Databricks, ou quando a API Resolve User (resolveByExternalId) é chamada, o Databricks tenta primeiro encontrar uma correspondência com um usuário existente do Databricks por UPN ou email. Caso nenhum usuário corresponda, o Databricks cria um sob demanda e define o nome de usuário com base em como o usuário existe no Microsoft Entra ID:
- Usuários criados em seu tenant: o Databricks usa o UPN como nome de usuário. Por exemplo, um usuário do Microsoft Entra ID com o UPN
bob@contoso.comtorna-se um usuário do Databricks com o nome de usuáriobob@contoso.com. - Usuários convidados ou sincronizados por meio de colaboração B2B (convidados): o Databricks prefere o e-mail como nome de usuário e recorre ao UPN quando o objeto convidado não possui e-mail. Por exemplo, um convidado cujo UPN é
carol_fabrikam.com#EXT#@contoso.onmicrosoft.come cujo email écarol@fabrikam.comtorna-se um usuário do Databricks com o nome de usuáriocarol@fabrikam.com.
Casos que o gerenciamento automático de identidade não consegue resolver.
Algumas configurações de provedores de identidade impedem que o Databricks identifique com precisão o usuário pretendido. Configure suas identidades para evitar os seguintes casos.
Vários usuários possuem o mesmo email.
Se mais de um usuário com ID Microsoft Entra tiver um email igual ao nome de usuário do Databricks e nenhum deles tiver um UPN correspondente, o Databricks não conseguirá determinar a qual usuário você se refere. O sistema seleciona um deles sem ordem garantida, portanto, pode sincronizar o usuário errado, e as sincronizações podem alternar entre os usuários correspondentes ao longo do tempo.
Por exemplo, um usuário do Databricks tem o nome de usuário dana@contoso.com. No Microsoft Entra ID, dois usuários têm o e-mail dana@contoso.com: uma conta de membro cujo UPN é d.lee@fabrikam.com e uma conta de convidado cujo UPN é dana_contoso.com#EXT#@fabrikam.onmicrosoft.com. O nome de usuário corresponde ao e-mail de ambos os usuários, mas não corresponde a nenhum dos UPNs, portanto o Databricks não consegue diferenciá-los e identifica um deles arbitrariamente.
Para evitar esse caso, certifique-se de que o UPN do usuário pretendido do Microsoft Entra ID seja igual ao nome de usuário do Databricks e não mantenha vários objetos do Microsoft Entra ID que compartilhem um e-mail.
O nome de usuário vem de um tenant diferente
Um usuário convidado pode iniciar sessão com um token que carrega um nome de usuário de seu tenant de origem, enquanto o objeto convidado em seu tenant não possui nem um UPN nem um email que seja igual a esse nome de usuário. No login, isso ainda funciona, porque a correspondência baseada em tokens resolve o usuário a partir da ID de objeto em vez do nome de usuário. Fluxos sem um token correspondem ao nome de usuário do Databricks, portanto, não conseguem encontrar o objeto convidado para sincronizar, e a resolução ou o compartilhamento podem criar um usuário do Databricks com um nome de usuário inesperado.
Por exemplo, um usuário do Databricks tem o nome de usuário erin@fabrikam.com, herdado do tenant principal do usuário. Em seu tenant, o objeto convidado tem o UPN erin_fabrikam.com#EXT#@contoso.onmicrosoft.com e nenhum e-mail correspondente. Um login baseado em token resolve este usuário pelo ID do objeto, mas como nem o UPN nem o e-mail são iguais a erin@fabrikam.com, a correspondência baseada no nome de usuário não encontra nenhum usuário.
Para evitar esse problema, certifique-se de que o e-mail do objeto convidado seja igual ao nome de usuário do Databricks.
Como funciona a sincronização de membros de grupos
Quando o gerenciamento automático de identidades está ativado, Databricks atualiza as associações de grupos de usuários do seu provedor de identidade durante atividades que acionam verificações de autenticação e autorização, como logins em navegadores, autenticação por tokens ou execução de tarefas. Isso garante que as permissões baseadas em grupos no Databricks permaneçam sincronizadas com as alterações feitas no seu provedor de identidade.
Quando Databricks atualiza as associações de grupo, ele busca as associações de grupo transitivas (aninhadas) do seu provedor de identidade. Isso significa que, se um usuário for membro do Grupo A e o Grupo A for membro do Grupo B, o Databricks reconhecerá o usuário como membro de ambos os grupos. Databricks só busca informações sobre membros de grupos que foram adicionados ao Databricks. Não sincroniza nem reconstrói a hierarquia completa do grupo pai a partir do seu provedor de identidade.
A sincronização de grupos aninhados requer um ID Microsoft Entra. O Okta não suporta a sincronização de grupos aninhados.
Databricks atualiza as associações de grupo em diferentes programas, dependendo da atividade:
- Logins de navegador : as associações a grupos são sincronizadas se tiverem se passado mais de 5 minutos desde a última sincronização.
- Outras atividades (por exemplo, autenticação de token ou execução de jobs): o Databricks atualiza as associações de grupo com base em quanto tempo atrás a última sincronização ocorreu:
- Menos de 10 minutos : Nenhuma refresh ocorre.
- 10 a 40 minutos : o Databricks aciona um refresh assíncrono em segundo plano. A solicitação que aciona o refresh pode ainda usar as associações de grupo anteriores. As associações atualizadas aplicam-se a solicitações subsequentes.
- Mais de 40 minutos : o Databricks atualiza as associações de grupo antes de concluir a solicitação.
Grupos aninhados e entidade de serviço
Quando o gerenciamento automático de identidades está ativado, os membros de grupos aninhados herdam as permissões dos grupos de provisionamento. As permissões atribuídas a um grupo principal aplicam-se a todos os utilizadores e entidades de serviço que pertencem ao grupo, incluindo os que foram adicionados diretamente ao grupo e os que pertencem através de associações a grupos aninhados. No entanto, grupos aninhados e entidades de serviço em um grupo não são automaticamente referenciáveis na account, com exceção do compartilhamento do painel.
A sincronização da entidade de serviço e a sincronização de grupos aninhados exigem um ID Microsoft Entra. Okta não suporta entidade de serviço ou sincronização de grupo aninhado.
Visibilidade de grupo aninhado
Os grupos aninhados são visíveis no Databricks. Considere um grupo filho, Group-C, que é membro de um grupo pai, Group-P. Se você adicionar Group-P a um workspace, todas as identidades em Group-P e Group-C terão acesso ao workspace. Nas interfaces de administração account e administração workspace , Group-C aparece como membro dentro de Group-P na página de detalhes dos membros do grupo. Apenas o primeiro nível de aninhamento aparece na página de detalhes do grupo.
Considerações sobre grupos aninhados
- Acesso ao espaço de trabalho: Grupos aninhados e entidades de serviço não precisam ser adicionados diretamente a um workspace para obter acesso. Se um grupo principal for adicionado a um workspace, todos os membros desse grupo poderão acessar o workspace.
- Ativos no nível da account: os grupos estão disponíveis ao compartilhar ou atribuir permissões a ativos no nível da account, como Databricks Apps, objetos do Unity Catalog, dashboards de AI/BI, Genie Agents e atribuição de workspace.
- Limites de grupo de contas e entidade de serviço: Grupos aninhados e entidades de serviço que não são provisionamento direto para a account não são contabilizados nos limites de grupo account . Apenas os grupos que são explicitamente provisionados para a account contam para os limites.
Por exemplo, em seu provedor de identidade, você tem a seguinte estrutura de grupos:
Marketing-All(grupo parental)Marketing-US(grupo de crianças)Marketing-EU(grupo de crianças)Marketing-APAC(grupo de crianças)
Se um administrador workspace adicionar Marketing-All ao seu workspace:
- Acesso concedido: Todos os membros de
Marketing-Alle todos os seus grupos filhos (Marketing-US,Marketing-EU,Marketing-APAC) podem acessar o workspace. Por exemplo, usuários e entidade de serviço emMarketing-APACpodem autenticar e usar o workspace. - Provisionamento de conta: Apenas
Marketing-Allé provisionamento para a account Databricks e conta para os limites do grupo account . Os grupos filhos não contam para os limites, a menos que você os provisione explicitamente. - O nível de conta ativo:
Marketing-Alle todos os seus grupos filhos (Marketing-US,Marketing-EU,Marketing-APAC) estão disponíveis ao compartilhar ou atribuir permissões ao nível accountativo, como painéis e objetos no Unity Catalog.
Ativar o gerenciamento automático de identidades
Para obter instruções de configuração, consulte o guia do seu provedor de identidade:
- Configure o Microsoft Entra ID para gerenciamento automático de identidade.
- Configure o Okta para gerenciamento automático de identidades.
Desativar o gerenciamento automático de identidade
Quando o gerenciamento automático de identidade está desativado:
- Usuários e entidade de serviço permanecem: eles mantêm o acesso, mas não estão mais sincronizados com seu provedor de identidade. Após desativar o gerenciamento automático de identidade, você pode remover ou desativar manualmente usuários e entidades de serviço no console account .
- Grupos perdem membros: Os grupos permanecem no Databricks, mas todos os membros do grupo são removidos.
- Sem sincronização com o provedor de identidade: alterações no seu provedor de identidade (como remoções de usuários ou atualizações de grupos) não são refletidas no Databricks.
- Sem herança de permissões: Usuários gerenciados pelo gerenciamento automático de identidade não podem herdar permissões de grupos pai. Isso afeta modelos de permissão aninhados baseados em grupos.
Se você planeja desativar o gerenciamento automático de identidades, Databricks recomenda configurar o provisionamento SCIM antecipadamente como fallback. O SCIM pode então assumir a sincronização de identidade e grupo.
- Como administrador da conta, faça login no console da conta.
- Na barra lateral, clique em Segurança .
- Na tab Provisionamento de usuários , alterne a opção Gerenciamento automático de identidade para Desativado .
Negar acesso de identidades à sua account
A lista de bloqueio de acesso account controla quais identidades do seu provedor de identidade têm permissão para acessar sua account Databricks . Os administradores de contas podem adicionar usuários, grupos ou entidades de serviço específicos à lista de bloqueio para impedir o acesso deles. A inclusão em uma lista de bloqueio é transitiva — se você bloquear um grupo, todos os membros, incluindo aqueles em grupos aninhados, também serão bloqueados.
Para obter instruções de configuração e uma descrição completa do comportamento da lista de bloqueio, consulte Negar acesso de identidades à sua account.
Auditar eventos de gerenciamento automático de identidade
Quando o gerenciamento automático de identidades está ativado, você pode usar logs de auditoria para rastrear as operações de identidade realizadas pelo processo de gerenciamento automático de identidades.
tags log de auditoria para eventos de gerenciamento automático de identidade
O gerenciamento automático de identidades utiliza eventos de log de auditoria existentes, mas adiciona tags para identificar operações realizadas automaticamente pelo processo de sincronização de identidades:
- endpoint: "autoUserCreation" - Indica que o evento foi emitido pelo processo de gerenciamento automático de identidade. Esta tag aparece em operações de usuário (
add,activateUser,deactivateUser,updateUser), operações de grupo (createGroup,updateGroup,removeGroup) e operações de associação de grupo (addPrincipalToGroup,removePrincipalFromGroup). - groupMembershipType: "IdentityProvider" - Aparece nas operações de associação de grupo (
addPrincipalToGroup,removePrincipalFromGroup) para indicar que a associação de grupo foi sincronizada do seu provedor de identidade.
Consultar eventos de auditoria de gerenciamento automático de identidade
Você pode consultar a tabela system.access.audit para rastrear operações automáticas de gerenciamento de identidade. Por exemplo:
Rastrear usuários criados pelo gerenciamento automático de identidade:
SELECT
request_params.targetUserName,
event_time
FROM
system.access.audit
WHERE
action_name = "add"
AND request_params.endpoint = "autoUserCreation"
Acompanhe as associações de grupo sincronizadas do seu provedor de identidade:
SELECT
request_params.targetGroupName,
request_params.targetUserName,
event_time
FROM
system.access.audit
WHERE
action_name IN ("addPrincipalToGroup", "removePrincipalFromGroup")
AND request_params.groupMembershipType = "IdentityProvider"
Para obter mais informações sobre a tabela system.access.audit , consulte a referência da tabela do sistema log de auditoria.
Comportamentos e limitações conhecidos
Esta seção descreve comportamentos que podem não ser imediatamente óbvios ao trabalhar com gerenciamento automático de identidade.
Criação de grupo e atribuição de workspace
Quando o gerenciamento automático de identidades sincroniza grupos do seu provedor de identidades, ele os cria automaticamente no nível account . Esses eventos aparecem nos logs de auditoria como tags createGroup operações com endpoint: "autoUserCreation". A criação de grupos no nível da conta é automática, mas a atribuição workspace é um processo manual separado. Os membros de um grupo sincronizado só obtêm acesso workspace depois que um administrador account atribui o grupo a um workspace. O gerenciamento automático de identidades controla a participação em grupos, e o administrador controla o acesso workspace .
A sincronização do nome do grupo não é proativa
Renomear um grupo no seu provedor de identidade não atualiza imediatamente o nome do grupo no Databricks. O nome do grupo só é sincronizado quando um administrador account abre a página de detalhes do grupo no console account . Até então, o grupo mantém seu nome anterior no Databricks.
O gerenciamento automático de identidades não remove as associações sincronizadas com o SCIM.
O gerenciamento automático de identidades não remove as associações de grupo que foram originalmente sincronizadas usando o provisionamento SCIM. Isso foi feito propositalmente para evitar a quebra de tarefas e permissões existentes que dependem dessas associações. Para remover associações SCIM obsoletas, use a API SCIM para limpá-las manualmente.
Provisionamento do principal de serviço no primeiro uso
Ao usar Microsoft Entra ID, adicionar um grupo que contém entidade de serviço ao Databricks não provisiona essa entidade de serviço. Provisionamento de Databricks entidade de serviço apenas no primeiro uso, como autenticação de tokens ou execução de Job. Até que uma entidade de serviço autentique ou execute um Job, ele não aparece no Databricks.
Grupos aninhados e Service Principal por meio da API e do Terraform.
Esta seção aplica-se somente ao uso do Microsoft Entra ID. Okta não suporta sincronização de grupo aninhado ou entidade de serviço.
Grupos aninhados e entidades de serviço que não são provisionados diretamente para a account Databricks são visíveis na interface do usuário do console account , mas não podem ser recuperados ou gerenciados por meio das APIs Databricks ou Terraform. Para gerenciá-los programaticamente, provisione-os explicitamente para a account.
As permissões são transferidas ao migrar do SCIM para o gerenciamento automático de identidade.
Ao migrar do provisionamento SCIM para o gerenciamento automático de identidades, os grupos permanecem os mesmos objetos internos do Databricks. As permissões Unity Catalog , as atribuições workspace e outras configurações são transferidas automaticamente. Você não perde nenhuma permissão durante a migração.