Controle de entrada baseado em contexto

Esta página fornece uma visão geral do controle de entrada baseado em 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 em contexto.

Visão geral do controle de entrada baseado em contexto

O controle de entrada baseado em contexto funciona juntamente com listas de acesso IP e conectividade privada de front-end para permitir que os administradores de contas definam regras de permissão e negação que combinem 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 alcançar seu workspace. O controle de entrada baseado em contexto é configurado no nível da conta. Uma única política pode controlar vários workspaces, garantindo uma imposição consistente em toda a sua organização.

Usando a entrada baseada em contexto, você pode:

• Interrompa o acesso de redes não confiáveis exigindo um segundo fator, uma fonte de rede confiável, além de credenciais.
• Permitir o acesso para clientes SaaS sem IPs de saída estáveis baseando-se na 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 workspace.
• Proteger a automação privilegiada: restrinja entidades de serviço de alto valor apenas a redes de alta confiança.
• Auditar efetivamente: capture logs detalhados de negação nas tabelas do sistema do Unity Catalog para monitorar solicitações bloqueadas.

Conceitos principais de controle de entrada baseados em contexto

Fontes de rede

Uma fonte de rede define a origem das solicitações. Os tipos compatíveis incluem:

• Todos os IPs públicos: qualquer fonte de Internet pública.
• IPs selecionados: endereços IPv4 específicos ou intervalos CIDR.

Tipos de acesso

As regras se aplicam a escopos de solicitação de entrada diferentes. Cada escopo representa uma categoria de solicitações de entrada que você pode permitir ou negar:

• UI do Workspace: Acesso ao Workspace via navegador.
• API: acesso programático por meio das APIs do Databricks, incluindo os pontos de extremidade SQL (JDBC/ODBC).
• Aplicativos: permitir ou negar acesso a implantações do Databricks Apps. Consulte Os Aplicativos do Databricks. Somente a opção de identidade Todos os usuários e entidades de serviço é suportada para esse tipo de acesso.

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

Identidades

As regras podem ter como destino diferentes tipos de identidade. Para os tipos de acesso de aplicativos e Lakebase Compute, a única opção com suporte é 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 usuários: somente usuários 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 regra

• 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 têm precedência.
• Política padrão: cada conta tem uma política de entrada padrão aplicada a todos os workspaces qualificados sem uma atribuição de política explícita.

Modos de imposição

As políticas de entrada baseadas em contexto dão suporte a dois modos:

• Aplicado para todos os produtos: as regras são aplicadas ativamente e as solicitações que violem as regras 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 workspace
• Tipo de solicitação
• Identidade
• Fonte de rede
• Tipo de acesso (NEGADO ou DRY_RUN_DENIAL)

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

Relação com outros controles

• Listas de acesso IP do workspace: Avaliadas antes que a política de entrada baseada em contexto permita uma requisição. Ambos devem permitir a solicitação. 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 computação sem servidor. Consulte Gerenciar políticas de rede.

• Conectividade privada de front-end: imposta junto com políticas de entrada quando Permitir Acesso à Rede Pública está Habilitado. Se Permitir acesso à rede pública estiver desabilitado, todas as entradas públicas serão bloqueadas e as políticas de entrada não serão avaliadas. Consulte Configurar Front-end Link Privado.

Práticas recomendadas

• Comece com o modo de execução seca 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 às entidades de serviço privilegiadas primeiro para limitar o raio de explosão.
• Mantenha os nomes das políticas claros e consistentes para a sustentabilidade a longo prazo.