Controle de entrada baseado no contexto

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 controlo de acesso de entrada baseado no contexto funciona juntamente com listas de acesso IP e conectividade privada do frontend para permitir que os administradores da conta definam regras de permissão e negação que combinam quem está a aceder, de onde estão a aceder e o que podem aceder 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 múltiplos espaços de trabalho.

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 certos escopos como APIs Azure Databricks ou a interface 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 aplicam-se a diferentes escopos de pedidos recebidos. Cada âmbito representa uma categoria de pedidos recebidos que pode permitir ou recusar:

• Interface do usuário do espaço de trabalho: acesso do navegador ao espaço de trabalho.
• API: Acesso programático através de APIs Azure Databricks, incluindo endpoints SQL (JDBC / ODBC). Pode direcionar todas as APIs ou um âmbito específico de API, como aplicações, dashboards ou servidor de modelos.
• 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: Utilizadores específicos ou principais de serviço escolhidos 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: As regras de recusa permitem-te definir exceções às tuas regras de permite.
• 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 entrada baseadas no contexto permitem dois modos:

• Aplicado para todos os produtos: Azure Databricks aplica ativamente regras e bloqueia pedidos que violem.
• Modo de ensaio para todos os produtos: Azure Databricks regista violações mas não bloqueia pedidos. Utilize este modo para avaliar o impacto da política antes de a impor.

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)

Consulta estes registos para verificar se as tuas regras funcionam como esperado e para detetar tentativas inesperadas de acesso.

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 Ligação Privada de Entrada.

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 primeiro as regras de bloqueio às identidades de serviço privilegiadas para limitar o âmbito afetado.
• Mantenha os nomes das apólices claros e consistentes.