Controle de entrada baseado no contexto

Importante

Este recurso está no Public Preview.

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

Para configurar políticas de entrada, consulte Gerenciar políticas de entrada baseadas no contexto.

Visão geral do controle de ingresso baseado no contexto

O controle de entrada baseado no contexto funciona junto com listas de acesso IP e conectividade privada front-end para permitir que os administradores de conta definam regras de permissão e negação que combinam quem está chamando, de onde estão chamando e o que podem alcançar no Azure Databricks. Isso garante que apenas combinações confiáveis de identidade, tipo de solicitação e fonte de rede possam chegar ao seu espaço de trabalho. O controle de entrada baseado no contexto é configurado no nível da conta. Uma única política pode governar vários espaços de trabalho, garantindo uma aplicação consistente em toda a sua organização.

Usando a entrada baseada no contexto, você pode:

• Pare o acesso de redes não confiáveis exigindo um segundo fator, uma fonte de rede confiável, além de credenciais.
• Permita o acesso para clientes SaaS sem IPs de saída estáveis digitando a identidade em vez de intervalos de IP.
• Limite o acesso permitindo que fontes menos confiáveis usem apenas determinados escopos, como APIs do Databricks ou a interface do usuário do espaço de trabalho.
• Proteja a automação privilegiada: restrinja entidades de serviço de alto valor apenas a redes de alta confiança.
• Audite de forma eficaz: Capture registos de rejeição detalhados nas tabelas do sistema Unity Catalog para monitorizar solicitações bloqueadas.

Conceitos centrais de controle de ingresso baseados no 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 da Internet.
• IPs selecionados: endereços IPv4 específicos ou intervalos CIDR.

Tipos de acesso

As regras se aplicam a diferentes escopos de solicitação 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 espaço de trabalho.
• API: Acesso programático por meio das APIs do Databricks, incluindo endpoints SQL (JDBC / ODBC).
• Aplicativos: permitir ou negar acesso a implantações de aplicativos Databricks. Consulte Aplicativos Databricks. Somente a opção de identidade Todos os usuários e entidades de serviço é suportada para este tipo de acesso.

• Lakebase Compute: Conexões com instâncias de banco de dados Lakebase. Consulte Instâncias do Lakebase. Somente a opção de identidade Todos os usuários e entidades de serviço é suportada para este tipo de acesso.

Identidades

As regras podem destinar-se a diferentes tipos de identidade. Para os tipos de acesso Apps e Lakebase Compute , a única opção suportada é Todos os usuários e entidades de serviço.

• Todos os usuários e entidades de serviço: usuários humanos e automação.
• Todos os utilizadores: Apenas utilizadores humanos.
• Todas as entidades de serviço: somente identidades de automação.
• Identidades selecionadas: usuários específicos ou entidades de serviço escolhidas pelo administrador.

Avaliação de regras

• Negação padrão: no modo restrito, o acesso é negado, a menos que explicitamente permitido.
• Negar antes de permitir: se existirem ambos os tipos de regras, as regras de negação terão precedência.
• Política padrão: cada conta tem uma política de entrada padrão aplicada a todos os espaços de trabalho qualificados sem uma atribuição de política explícita.

Modos de imposição

As políticas de ingresso baseadas no contexto suportam dois modos:

• Aplicado a todos os produtos: as regras são aplicadas ativamente e as solicitações violadoras são bloqueadas.
• Modo de execução a 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.

Auditing

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

• Hora do evento
• ID do espaço de trabalho
• Tipo de pedido
• Identidade
• Origem da rede
• Tipo de acesso (NEGADO ou DRY_RUN_DENIAL)

Você pode consultar esses logs para validar se suas regras são aplicadas corretamente e para detetar tentativas de acesso inesperadas.

Relação com outros controlos

• Listas de acesso IP do espaço de trabalho: avaliadas antes que a política de entrada baseada no contexto permita uma solicitação. Ambos devem deferir o pedido. 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 computação sem servidor. Consulte Gerenciar políticas de rede.

• Conectividade privada (front-end): implementada juntamente com as políticas de entrada quando Permitir acesso à rede pública estiver habilitado. Se Permitir Acesso à Rede Pública estiver Desativado, todas as entradas públicas serão bloqueadas e as políticas de entrada não serão avaliadas. Veja Configurar Link Privado do Front-end.

Melhores práticas

• Comece com o modo de funcionamento a seco para observar os impactos sem interromper o acesso.
• Use regras baseadas em identidade sempre que possível para clientes SaaS que alternam IPs.
• Aplique regras de negação a entidades de serviço privilegiadas primeiro para limitar o raio de explosão.
• Mantenha os nomes das políticas claros e consistentes para uma manutenção a longo prazo.

Observação

Controle de entrada baseado em contexto não está disponível na região Azure Oeste da Índia.