Controle de entrada baseado em contexto

nota

A entrada baseada em contexto exige o Enterprise tier.

nota

Context-based ingress is generally available (GA), but some related features are in Beta:

• Políticas de entrada baseadas em contexto para conectividade privada de entrada : aplique políticas de acesso baseadas em contexto para Endpoint privados registrados. Habilite Entrada baseada em contexto: políticas de acesso privado do workspace para começar.
• Políticas de entrada baseadas em contexto para sua conta : aplique políticas de acesso ao console da conta, ao Genie One em nível de conta e às APIs da conta. As negações para essas políticas não são registradas nos logs. Habilite o Front-end Private Link para URLs personalizadas e conta para começar.
• Plataformas de parceiros como fonte de rede : inclua na lista de permissões 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 IP automaticamente. Habilite os recursos beta de entrada baseados em contexto na página de visualizações (previews) do console da account para começar.
• Acesso entre workspaces : controla quais workspaces de origem podem alcançar este workspace por tráfego serverless, usando as mesmas identidades e regras de permissão e negação de outras fontes de rede.

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.
• Plataformas de parceiros (Beta): 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.

Política de acesso privado (Beta):

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

Acesso entre workspaces (Beta): controla quais workspaces de origem podem acessar este workspace por tráfego serverless, usando as mesmas identidades e regras de permissão e negação de outras fontes de rede.

• Workspaces selecionados : Apenas os workspaces cujos IDs você listar.

Você também pode deixar esta política no modo de compatibilidade, caso em que ela não rege a entrada entre workspaces e os controles de rede pré-existentes do workspace se aplicam. Para configurar o acesso entre workspaces nos lados de entrada e saída, e para revisar suas limitações, consulte Acesso entre workspaces.

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 em nível de Workspace:

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

• API : Acesso programático por meio de APIs do Databricks, incluindo SQL endpoints (JDBC / ODBC). Você pode direcionar qualquer um dos seguintes:

  • Todas as APIs.
  • Um escopo de API específico, usando IN . Por exemplo, você pode especificar apps, painéis ou servindo modelo.
  • Todos os escopos de API, exceto os selecionados, usando NOT IN .

• 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 Runtime : conexões com instâncias de banco de dados do Lakebase. See Lakebase. Apenas a opção de identidade All users and service principals é suportada para este tipo de acesso.

Tipos de acesso a políticas em nível de account (Beta):

• Account UI : acesso do navegador a recursos de nível de account (por exemplo, o console da account e o Genie One 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 Apps runtime e Lakebase runtime , a única opção compatível é Todos os usuários e Service Principal .

Na política no nível da conta, a única opção compatível é **Todos os usuários e Service Principals**.

• 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 Service Principal do Databricks.

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 default no nível do workspace : Cada account tem uma política de entrada default no nível do workspace aplicada a todos os workspaces 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

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
• Rótulo da regra (da regra que negou a solicitação)
• 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.
• Acesso entre workspaces : controla quais workspaces de origem podem acessar um workspace por meio de tráfego serverless, além dos controles de rede de origem e de identidade nesta página. Consulte Acesso entre Workspace.
• Listas de acesso de IP de destinatário do OpenSharing : a entrada baseada em contexto não se aplica às listas de acesso de IP de destinatário do OpenSharing. Este é um controle separado para destinatários abertos que os provedores configuram por destinatário. Consulte Restringir o acesso do destinatário do OpenSharing usando listas de acesso IP (compartilhamento Databricks-para-Open).

dica

Para reduzir a complexidade, a Databricks recomenda usar a política de entrada baseada em contexto como o seu único mecanismo de política, em vez de manter também listas de acesso de IP. Se seus workspaces já tiverem listas de acesso de IP, consulte Migrar listas de acesso de IP de workspaces para entrada baseada em contexto.

• Listas de Acesso IP da Conta : avaliadas em conjunto com a política no nível da conta de entrada 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 no nível da account 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 no nível da conta, 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.

nota

O controle de entrada baseado em contexto não está disponível na AWS GovCloud. Use listas de acesso IP em vez disso.