Controle de entrada baseado em contexto

info

Beta

Este recurso está em Beta.

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 junto com listas de acesso IP e conectividade privada de front-end para permitir que administradores account definam regras de permissão e negação que combinam quem está ligando, de onde está ligando e o que pode ser alcançado no Databricks. Isso garante que somente combinações confiáveis de identidade, tipo de solicitação e origem de rede possam acessar seu workspace. O controle de entrada baseado em contexto é configurado no nível account . Uma única política pode governar vários espaços de trabalho, garantindo uma aplicação consistente em toda a sua organização.

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 entidades de serviço de alto valor somente 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 de entrada. Cada escopo representa uma categoria de solicitações de entrada que você pode permitir ou negar:

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

• API : Acesso programático por meio de APIs Databricks , incluindo endpoint SQL (JDBC / ODBC).

• 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 entidade de serviço : Usuários humanos e automação.
• Todos os usuários : somente usuários humanos.
• Todas as entidades de serviço : apenas identidades de automação.
• Identidades selecionadas : Usuários específicos ou entidade de serviço 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 : se ambos os tipos de regras existirem, as regras de negação terão precedência.
• 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 oferecem suporte a dois modos:

• Aplicado a todos os produtos : as regras são aplicadas ativamente e as solicitações que as violam são bloqueadas.
• Modo de execução seco para todos os produtos : as violações são registradas, mas as solicitações não são bloqueadas, permitindo que você avalie o impacto da política com segurança.

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)

Você pode consultar esses logs para validar se suas regras foram aplicadas corretamente 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 regras de negação à entidade de serviço privilegiada primeiro para limitar o raio de explosão.
• Mantenha os nomes das políticas claros e consistentes para manutenção a longo prazo.