Controle de entrada baseado em contexto

info

Visualização

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

info

Visualização

A política de entrada baseada em contexto no nível da conta está em Beta.

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.

Política de acesso privado:

• Todos os endpoints privados registrados : Qualquer endpoint privado registrado na account.
• Endpoints privados selecionados : endpoints privados registrados específicos na account.

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.

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

account-policy Tipos de acesso:

• IU da account : acesso do navegador a recursos de nível de account (por exemplo, o console da account e o Genie de nível de account).
• API da conta : Acesso programático por meio das APIs da conta Databricks.

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 .

Em account-policy, a única opção suportada é 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.

nota

Limitação de Prévia Beta

account-policy as recusas ainda não são registradas.

:::

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.

• Listas de acesso IP da conta : Avaliadas em conjunto com a entrada baseada em contexto account-policy usando um AND lógico, sem uma sequência estrita entre os dois. Uma solicitação é permitida somente se tanto a lista de acesso IP quanto o account-policy a permitirem. Listas de acesso IP da conta podem restringir ainda mais o acesso, mas não podem ampliá-lo.
• Configuração de acesso privado: alternância de acesso público : Aplicada em conjunto com as políticas de entrada quando Acesso público habilitado é Verdadeiro . Se Acesso público habilitado for Falso , todo o ingresso público será bloqueado e as políticas de entrada não serão avaliadas. Consulte Gerenciar configurações de acesso privado.
• Conectividade privada de front-end :
  • Para que o tráfego seja permitido, tanto as configurações de acesso privado quanto a entrada baseada em contexto devem permitir o endpoint. Por default, a entrada baseada em contexto é definida como Permitir acesso de todos os endpoints privados , o que adia a decisão de acesso para a configuração de acesso privado do workspace. Se você quiser configurar políticas de acesso privado baseadas em contexto, certifique-se de que seu workspace tenha uma configuração de acesso privado anexada, com todos os endpoints privados registrados permitidos (veja mais abaixo). Isso vai adiar a decisão de acesso para a política de entrada baseada em contexto do seu workspace.
  • Para a política da account, a entrada baseada em contexto é a única fonte de verdade para a política 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.