gerenciar solicitações de acesso

info

Visualização

Este recurso está em pré-visualização pública.

O recurso de solicitação de acesso permite que os usuários solicitem privilégios para objetos protegíveis no Unity Catalog. Esta página explica como configurar destinos de solicitação de acesso como administrador. Esses destinos determinam para onde as solicitações de acesso são enviadas quando os usuários solicitam acesso a objetos de dados.

O que são destinos de solicitação de acesso?

Quando os usuários solicitam acesso a um objeto em Unity Catalog (como uma tabela ou view), a solicitação é enviada para um ou mais destinos configurados. Os destinos podem ser qualquer um dos seguintes:

• endereços de e-mail

• Canal do Slack

• Microsoft Canal de equipes

• Ponto final do Webhook

• Um URL de redirecionamento (para o sistema de solicitação de acesso externo da sua organização)

  Somente um URL de redirecionamento pode ser configurado por objeto. Se um URL estiver definido, nenhum outro destino poderá ser definido e os usuários serão redirecionados para esse URL em vez de visualizar o formulário de solicitação no produto.

Solicitar permissões exatamente onde você trabalha no Databricks

Depois que os destinos são configurados, os usuários podem solicitar permissões de várias superfícies no produto: Catalog Explorer, editor SQL e notebooks, painéis AI/BI e Genie Spaces.

Explorador de Catálogos

Usuários com o privilégio BROWSE podem navegar na árvore de catálogos, abrir a página de um objeto e solicitar privilégios adicionais (como SELECT) a partir daí. Usuários também podem receber um URL direto para a página de um objeto e solicitar acesso da mesma superfície, mesmo sem BROWSE.

Editor SQL, notebooks e outras superfícies de autoria

Quando uma consulta ou comando falha com um erro INSUFFICIENT_PERMISSIONS, a mensagem de erro inclui uma opção Solicitar acesso que preenche previamente a solicitação com as tabelas referenciadas. Isso funciona onde quer que o erro surja, incluindo o editor SQL e os notebooks.

Dashboards de AI/BI

Quando um dashboard é executado sem credenciais incorporadas e um widget referencia conjuntos de dados que o visualizador não pode ler, o widget exibe um modal de **Solicitar acesso** para os conjuntos de dados ausentes.

Genie Spaces

Quando um Espaço Genie faz referência a tabelas para as quais o usuário não tem permissões, o espaço exibe um banner PERMISSION_DENIED com um modal de Solicitar acesso para as tabelas inacessíveis.

Como funcionam os destinos de solicitação de acesso

Os destinos de solicitação de acesso podem ser configurados na maioria dos objetos no Unity Catalog, incluindo metastores, catálogos, esquemas, tabelas, views, volumes, funções, modelos, credenciais de armazenamento, credenciais de serviço, locais externos e conexões.

Ao enviar uma solicitação, os usuários podem solicitar acesso para uma ou mais entidades. Isso inclui a si mesmos, a entidade de serviço, outros usuários ou grupos. A solicitação é encaminhada para os destinos configurados.

Se vários destinos estiverem configurados, a solicitação será enviada para todos eles. Se nenhum destino for configurado, os usuários não poderão solicitar acesso ao objeto. Por default, os objetos não têm um destino configurado. No entanto, como administrador do metastore e workspace , você pode habilitar destinos email default para entregar solicitações de acesso ao proprietário apropriado, mesmo quando nenhum destino estiver explicitamente configurado.

Se um URL de redirecionamento estiver configurado, os usuários são redirecionados para o URL e não veem o formulário de solicitação de acesso. Os administradores do workspace podem configurar destinos externos seguindo as instruções em Gerenciar destinos de notificação.

Comportamento de herança de destino

Ao configurar um destino em níveis superiores da hierarquia de objetos Unity Catalog , essa configuração também se aplica a todos os objetos filhos que ainda não possuem um destino definido. Por exemplo, se você configurar um destino em um catálogo, esse destino será herdado por todos os esquemas e objetos do catálogo, exceto aqueles que já possuem um destino.

Habilite destinos default email

O Databricks recomenda habilitar destinos de email default. Isso assegura que as solicitações de acesso sejam entregues mesmo quando nenhum destino é configurado manualmente. Quando ativado, as solicitações de objetos de catálogo são enviadas para o endereço de email do proprietário do catálogo, e as solicitações de objetos fora de um catálogo, como localizações externas, são enviadas para o endereço de email do proprietário do objeto.

dica

A ativação de destinos default email garante que as solicitações de acesso sejam entregues mesmo quando nenhum destino estiver configurado manualmente para um objeto. Esta é a maneira mais rápida de começar a receber e responder a solicitações em toda a sua metastore do Unity Catalog.

Para habilitar destinos de default, é necessário ser administrador do metastore e administrador d workspace.

1. No canto superior direito da sua página inicial do workspace, clique na sua foto de perfil e selecione Configurações .
2. Clique em Notificações .
3. Ative a opção "Habilitar destinos email default para solicitações de acesso em UC" .

Configure os destinos das solicitações de acesso em um objeto.

Para configurar destinos de solicitação de acesso em um objeto, você deve ser o proprietário do objeto, ter o privilégio MANAGE no objeto ou ser um administrador do metastore.

Você pode configurar destinos usando o Catalog Explorer, a API REST ou o Terraform.

Configurar destinos para objetos existentes

Catalog Explorer

1. Em Databricks workspace, clique em Catalog .

2. Selecione um objeto protegível.

3. Clique no menu kebab “ ” e selecione “gerenciar destinos de solicitações de acesso ”.

4. Selecione um ou mais destinos de email ou externos, ou configure uma URL de redirecionamento. Se um URL for selecionado, não poderão ser adicionados outros tipos de destino.

   

5. Clique em Atualizar .

REST API

Use a API de Destinos de Solicitação de Acesso para definir destinos em um recurso protegível. PATCH substitui os destinos no recurso protegível; caso nenhum tenha sido definido anteriormente, ele os cria.

Bash

curl -X PATCH \
  https://<workspace-url>/api/3.0/rfa/destinations \
  -H "Authorization: Bearer $DATABRICKS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "destinations": [
      { "destination_id": "data-access@example.com", "destination_type": "EMAIL" }
    ],
    "securable": {
      "type": "TABLE",
      "full_name": "main.sales.orders"
    }
  }'

Terraform

Use o recurso databricks_rfa_access_request_destinations.

Hcl

resource "databricks_rfa_access_request_destinations" "orders" {
  destinations = [
    {
      destination_id   = "data-access@example.com"
      destination_type = "EMAIL"
    }
  ]
  securable = {
    type      = "TABLE"
    full_name = "main.sales.orders"
  }
}

Configure os destinos ao criar um catálogo.

1. Em Databricks workspace, clique em Catalog .
2. Clique no ícone de mais. Em seguida, clique em Criar um catálogo .
3. Insira um nome para o seu catálogo e clique em Criar catálogo .
4. Na próxima janela modal, clique em Configurar catálogo .
5. Na seção "Solicitações de Acesso" , adicione, modifique ou remova destinos conforme necessário. O email do proprietário do catálogo é incluído como destino por default.

1. Clique em Avançar e, em seguida, clique em Salvar .

Os destinos são herdados na hierarquia de objetos Unity Catalog . Ao criar um esquema dentro de um catálogo que possui um destino de solicitação de acesso, o modal Criar um novo esquema menciona os destinos herdados:

Para modificar esses destinos no esquema, consulte Configurar destinos para objetos existentes.

Exemplos de solicitações de acesso

A seção a seguir mostra exemplos de solicitações de acesso enviadas para destinos diferentes.

e-mail

Os e-mails de solicitação de acesso são enviados a partir do endereço noreply@databricks.com.

Slack

Webhook (JSON)

JSON

{
  "requesterName": "<first-name> <last-name> (<email>)",
  "objectName": "<catalog>.<schema>.<table>",
  "objectType": "Table",
  "privileges": "SELECT",
  "principalName": "<group-name>",
  "onBehalfOf": "<group-name>",
  "onBehalfOfType": "Group",
  "comment": "My team needs access to run queries on this table.",
  "databricksWorkspaceUrl": "https:/<account>.databricks.com/explore/data/<catalog>/<schema>/<table>?o=<table-id>&activeTab=permissions&showGrantModal=true&requestedPrivileges=SELECT&groupId=<group-id>"
}

Para obter informações sobre como integrar webhooks com ferramentas comuns, consulte o seguinte:

• Enviar alerta para o Jira.
• Como integrar webhooks ao ServiceNow

Validação de permissões integrada

• Privilégios pré-requisito (USE CATALOG, USE SCHEMA) são verificados automaticamente quando um usuário solicita um privilégio como SELECT.
• Pré-requisitos ausentes geram solicitações adicionais encaminhadas para os aprovadores dos objetos pai.
• A validação também se aplica a solicitações enviadas em nome de outro usuário ou grupo.

Aprovar uma solicitação de acesso

Para aprovar uma solicitação de acesso, siga o link enviado para sua notificação de solicitação de acesso. O link abre uma caixa de diálogo modal no seu workspace que exibe o solicitante, o objeto e os privilégios solicitados.

Em seguida, selecione um dos seguintes métodos de aprovação:

• Adicione o principal ao (s) grupo (s) para adicionar o solicitante a um ou mais grupos existentes que tenham pelo menos um dos privilégios solicitados.

  

• Conceder privilégios ao principal para dar a ele acesso diretamente ao objeto. Também é possível selecionar predefinições de privilégios, como **Data Reader**, para conceder a um usuário um conjunto de privilégios.

  

Para um registro de cada solicitação de acesso e configuração de destino, consulte Eventos de solicitação de acesso na referência de log de auditoria.