Gerenciar políticas de entrada baseadas em contexto do workspace
Esta página mostra aos administradores de contas como criar uma política de rede no nível do workspace, configurar suas regras de entrada para acesso público, privado e entre workspaces, e anexá-la a workspaces.
Para obter uma visão geral do controle de entrada baseado em contexto, incluindo modos de imposição, auditoria, como a entrada interage com outros controles de rede e as opções de API e Terraform, consulte Context-based ingress control. Para o controle de saída serverless, consulte What is serverless egress control?.
Requisitos
- Você deve ser um administrador de account.
- Sua conta do Databricks deve estar no nível Enterprise.
Para aplicar sua política de rede de entrada em conexões que podem ter origem em qualquer lugar do mundo, o Databricks distribui a configuração da sua política para a infraestrutura de aplicação em todas as regiões do Databricks, incluindo regiões onde você não possui um workspace.
Acessar políticas de rede
Use uma política de rede para definir regras de entrada e saída para um ou mais workspaces. Para gerenciar políticas de rede em sua account:
- No account console, clique em Security .
- Clique na tab Rede.
- Em Políticas , clique em Controle de entrada e saída com base em contexto .
As políticas no nível do workspace são definidas em Workspace level policies .
The default workspace-level policy applies to any workspace without another network policy. Databricks doesn't recommend modifying its ingress rules. Instead, create a new policy and attach it to specific workspaces.
Criar uma política de rede do workspace
- Detalhes da política de rede.
- Insira um Policy name .
- Clique na guia Ingress . Para definir regras de saída, consulte Definir regras de saída.
- Selecione um modo de acesso à rede (para o acesso à rede pública e o acesso à rede privada):
- Allow access from all sources : Permitir acesso irrestrito de entrada pela internet.
- Restringir o acesso com base no contexto da solicitação : Negue o acesso de entrada por default e permita o acesso apenas por meio de Regras de permissão explícitas.

Configurar regras de entrada
Quando você usa o modo de acesso restrito:
- A política nega o acesso por default.
- A política concede acesso somente quando uma solicitação corresponde a uma regra Allow explícita.
- Deny rules are exceptions to Allow rules . For example, you can allow a broad network range while denying access to specific identities within that range. If a request matches both an allow rule and a deny rule, the request is denied.
Para configurar uma regra de permissão ou de bloqueio:
-
Click Add rule acima the Allow rules or Deny rules lists.
-
Selecione um tipo de acesso:
-
Workspace UI : Permitir acesso à IU do Workspace.
-
API : Permitir ou negar o acesso às APIs do Databricks. Opcionalmente, selecione escopos de API específicos para restringir a regra, escolhendo IN para corresponder apenas aos escopos selecionados ou NOT IN para corresponder a todos os escopos de API, exceto eles. Os escopos de API só podem ser especificados em regras de permissão, não em regras de negação:
- All APIs : aplica-se a todas as chamadas de API do Databricks.
- Apps : aplica-se a Endpoint da API do Databricks Apps.
- Dashboard : aplica-se aos da API de Endpoint do Databricks.
- Servindo modelo : Aplica-se a APIs de servindo modelo.
-
Apps runtime : permitir o acesso a implantações do Databricks Apps.
-
-
Selecione um tipo de identidade:
- All users and service principals : Permitir acesso a usuários e service principals.
- Todos os usuários : permitir acesso apenas aos usuários no workspace.
- All Service Principal : Allow access only to Service Principal in the Workspace.
- Identidades selecionadas : permitir o acesso apenas a usuários específicos ou Service Principal. Escolha as identidades na lista Assuntos .
Para os tipos de acesso Lakebase runtime e Apps runtime , o único tipo de identidade compatível é All users and service principals . Outras opções de identidade não podem ser selecionadas.
-
Selecione uma fonte de rede. As fontes disponíveis dependem de você estar configurando o acesso público, privado ou entre workspaces, conforme descrito nas seções a seguir.
-
Clique em Salvar .
You can define multiple allow and deny rules to control access based on client identity, client network source, or access scope (access type).
Acesso à rede pública
Para acesso à rede pública, selecione uma das seguintes origens de rede:
- Todos os IPs públicos : Permitir acesso de todos os IPs públicos.
- IPs selecionados : permitir o acesso apenas de IPs específicos. Insira os IPs separados por vírgulas.
Beta
Partner platforms as a network source is in Beta.
Selecione Plataformas de parceiros para colocar na allowlist os IPs que aplicativos de terceiros (Power BI, Tableau Cloud e plataforma dbt) usam para se conectar ao Databricks. O Databricks gerencia e atualiza essas listas de IPs automaticamente.
Para Regras de negação com IPs selecionados, escolha uma das seguintes opções:
- IN : Nega o acesso de IPs que estão na origem de rede especificada.
- NOT IN : nega o acesso a partir de IPs que não estão na origem de rede especificada.
Acesso entre Workspace
Beta
Cross-workspace access is in Beta.
O acesso entre workspaces controla quais workspaces de origem podem acessar este workspace por meio de tráfego serverless, usando as mesmas identidades e regras de permissão e negação que outras origens de rede. Selecione Workspaces selecionados como a origem de rede e liste os IDs de workspace a serem permitidos.
Se você deixar a política no modo de compatibilidade, ela não regerá o acesso de entrada entre Workspace e os controles de rede pré-existentes do Workspace se aplicarão. Para configurar o acesso entre Workspace nos lados de entrada e saída, e para revisar suas limitações, consulte Configure o acesso de entrada entre Workspace.
Definir o modo de imposição
O modo de execução de teste permite que você teste sua política e monitore conexões de entrada sem bloquear nenhum acesso. Quando o modo de execução de teste está habilitado, as solicitações que violam a política são registradas, mas não bloqueadas. Para detalhes, consulte Modos de imposição.
- Defina o modo de aplicação de políticas como Aplicado para todos os produtos ou Modo de execução de teste para todos os produtos .
- Clique em Criar .

Anexar uma política a workspaces
Se você atualizou sua política default com configurações adicionais, elas serão aplicadas automaticamente aos workspaces que não tiverem uma política de rede existente.
Para associar seu workspace a uma política diferente, siga estes passos:
- No console da conta, clique em Workspaces .
- Selecione um workspace.
- Em Política de rede , clique em Atualizar política de rede .
- Select the desired network policy from the list.
- Clique em Aplicar política .

Policy changes, such as creating, updating, or attaching, typically take 10 to 15 minutes to take effect. During this window, enforcement might be inconsistent as the change propagates. Allow for this delay before relying on updated policies.
Configurar usando a API ou o Terraform
Além do console da conta, você pode configurar políticas de entrada baseadas em contexto usando a API REST do Databricks ou o Terraform. Consulte API e Terraform.
Verificar logs de recusa
Os logs de negação são armazenados na tabela system.access.inbound_network no Unity Catalog. Para acessar os logs de negação, verifique se o esquema de acesso está habilitado no metastore do seu Unity Catalog. Consulte Habilitar tabelas do sistema. Para obter os campos capturados em cada entrada, consulte Auditoria.
Use uma query SQL como o exemplo a seguir para view eventos de negação. If dry-run logs are enabled, the query returns both denial logs and dry-run logs, which you can distinguish using the access_type column. Denial logs have a DROP value, while dry-run logs show DRY_RUN_DENIAL .
O exemplo a seguir recupera logs das últimas 2 horas:
SELECT *
FROM system.access.inbound_network
WHERE event_time >= CURRENT_TIMESTAMP() - INTERVAL 2 HOUR
ORDER BY event_time DESC;
Os logs podem não aparecer imediatamente. Pode haver um atraso de vários minutos entre o momento do acesso e a exibição dos logs de negação.
Limitações
O controle de entrada baseado em contexto não está disponível na região GCP Middle East Central 2.