Controle de entrada baseado em contexto

info

Visualização

Este recurso está em Pré-visualização Pública.

nota

Este recurso requer o plano Enterprise.

Esta página fornece uma visão geral do controle de entrada baseado em contexto. Para controle de saída serverless , consulte O que é controle de saída serverless ?.

Para configurar políticas de entrada, consulte gerenciar context-based ingress policies.

Visão geral do controle de entrada baseado em contexto

O controle de entrada baseado em contexto funciona em conjunto com listas de acesso IP e conectividade privada de front-end para permitir que os administradores account definam regras de permissão e negação que combinam quem está chamando, de onde está chamando e o que pode acessar no Databricks. Isso garante que apenas combinações confiáveis de identidade, tipo de solicitação e origem da rede possam acessar seu workspace. O controle de entrada baseado em contexto é configurado no nível account . Uma única política pode reger vários espaços de trabalho.

Usando o ingresso baseado em contexto, você pode:

• Impeça o acesso de redes não confiáveis exigindo um segundo fator, uma fonte de rede confiável, além das credenciais.
• Permitir acesso para clientes SaaS sem IPs de saída estáveis por chave de identidade em vez de intervalos de IP.
• Limite o acesso permitindo que fontes menos confiáveis usem apenas determinados escopos, como APIs Databricks ou a interface do usuário workspace .
• Proteja a automação privilegiada : restrinja o acesso de alto valor à entidade de serviço Databricks apenas a redes de alta confiança.
• Audite com eficiência : capture logs de negação detalhados nas tabelas do sistema Unity Catalog para monitorar solicitações bloqueadas.

Conceitos básicos de controle de entrada baseado em contexto

Fontes de rede

Uma fonte de rede define a origem das solicitações. Os tipos suportados incluem:

• Todos os IPs públicos : qualquer fonte pública de internet.
• IPs selecionados : endereços IPv4 específicos ou intervalos CIDR.

Tipos de acesso

As regras se aplicam a diferentes escopos de solicitações recebidas. Cada escopo representa uma categoria de solicitações recebidas que você pode permitir ou negar:

• interface do usuário do espaço de trabalho : acesso do navegador ao workspace.

• API : Acesso programático através APIs Databricks , incluindo endpoint SQL (JDBC / ODBC). Você pode segmentar todas APIs ou um escopo API específico, como aplicativos, painel ou servindo modelo.

• Aplicativos : permitir ou negar acesso a implantações de aplicativos do Databricks. Veja Aplicativos Databricks. Somente a opção Todos os usuários e identidade da entidade de serviço é suportada para esse tipo de acesso.

• Lakebase compute : Conexões com instâncias de banco de dados Lakebase. Veja instâncias do Lakebase. Somente a opção Todos os usuários e identidade da entidade de serviço é suportada para esse tipo de acesso.

Identidades

As regras podem ter como alvo diferentes tipos de identidade. Para os tipos de acesso de computação Apps e Lakebase , a única opção suportada é Todos os usuários e entidade de serviço .

• Todos os usuários e a entidade de serviço Databricks : tanto usuários humanos quanto automatizados.
• Todos os usuários : somente usuários humanos.
• Todos Databricks entidade de serviço : apenas identidades de automação.
• Identidades selecionadas : Usuários específicos ou entidade de serviço Databricks escolhida pelo administrador.

Avaliação de regras

• negação padrão : No modo restrito, o acesso é negado, a menos que seja explicitamente permitido.
• Negar antes de permitir : As regras de negação permitem definir exceções às suas regras de permissão.
• política padrão : cada account tem uma política de entrada default aplicada a todos os espaços de trabalho qualificados sem uma atribuição de política explícita.

Modos de execução

As políticas de entrada baseadas em contexto permitem dois modos:

• Aplicado a todos os produtos : Databricks aplica ativamente as regras e bloqueia solicitações que as violam.
• Modo de execução a seco para todos os produtos : Databricks logs as violações, mas não bloqueia as solicitações. Use este modo para avaliar o impacto da política antes de aplicá-la.

nota

Uma política de rede suporta apenas um modo de aplicação por vez.

Auditoria

Solicitações negadas ou de execução a seco são registradas na tabela do sistema system.access.inbound_network . Cada entrada de log inclui:

• Horário do evento
• ID do workspace
• Tipo de solicitação
• Identidade
• Fonte de rede
• Tipo de acesso (DENIED ou DRY_RUN_DENIAL)

Consulte esses logs para verificar se suas regras funcionam conforme o esperado e para detectar tentativas de acesso inesperadas.

Relação com outros controles

• listas de acesso IP do espaço de trabalho : avaliadas antes que a política de entrada baseada em contexto permita uma solicitação. Ambos devem permitir a solicitação. As listas de acesso IP do espaço de trabalho podem restringir ainda mais o acesso, mas não podem ampliá-lo.

• controle de saída sem servidor : complementa as políticas de entrada controlando o tráfego de rede de saída da compute serverless . Consulte gerenciamento de políticas de rede.

• Conectividade privada de front-end : aplicada juntamente com as políticas de entrada quando o acesso público habilitado é True . Se o acesso público habilitado for Falso , toda a entrada pública será bloqueada e as políticas de entrada não serão avaliadas. Veja gerenciar configurações de acesso privado.

Melhores práticas

• Comece com o modo de execução a seco para observar impactos sem interromper o acesso.
• Use regras baseadas em identidade sempre que possível para clientes SaaS que rotacionam IPs.
• Aplique primeiro as regras de negação à entidade de serviço Databricks com privilégios elevados para limitar a área afetada.
• Mantenha os nomes das políticas claros e consistentes.