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, baseando-se na identidade em vez de em intervalos de IP.
• Limite o acesso permitindo que fontes menos confiáveis usem apenas determinados escopos, como as APIs Databricks ou a interface do usuário do workspace.
• Proteja a automação privilegiada: Restrinja entidades de serviço Databricks de alto valor apenas a redes de alta confiança.
• Auditar com eficiência: capturar logs de negação detalhados em tabelas de sistema do Unity Catalog para monitorar requisiçõ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:

Política de acesso público:

• 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:

Tipos de acesso da política de workspace:

• 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.
• Tempo de execução de aplicativos : Permita ou negue acesso a implantações do Databricks Apps. See Databricks Apps. Somente a opção de identidade Todos os usuários e entidades de serviço é compatível com este tipo de acesso.

Identidades

As regras podem ter como destino diferentes tipos de identidade. Para os tipos de acesso Tempo de execução de aplicativos e compute Lakebase , a única opção compatível é Todos os usuários e entidades 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 de workspace default: cada account tem uma política de entrada de workspace default aplicada a todos os workspaces elegíveis 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

As solicitações negadas ou de execução de teste são registradas na tabela do sistema system.access.inbound_network. Caso não tenha acesso às tabelas do sistema, um administrador de metastore pode conceder as permissões. Consulte Conceder acesso às tabelas do sistema.

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 Workspace : Avaliadas juntamente com a política de ingresso baseada em contexto usando um AND lógico, sem sequência estrita entre as duas. Uma solicitação é permitida somente se a lista de acesso IP e a política de ingresso a permitirem. As listas de acesso IP do Workspace 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.

dica

Para reduzir a complexidade, o Databricks recomenda usar a política de ingresso baseada em contexto como sua única política, em vez de também manter listas de acesso IP.

• 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 de teste para observar os impactos sem interromper o acesso.
• Use regras baseadas em identidade sempre que possível para clientes SaaS que rotacionam IPs.
• Aplique as regras de negação primeiro às entidades de serviço privilegiadas do Databricks para limitar a área afetada.
• Mantenha os nomes das políticas claros e consistentes.

nota

O controle de entrada baseado em contexto não está disponível na região GCP Oriente Médio Central 2.