Controle de entrada baseado no contexto

Esta página fornece uma visão geral do controlo de entrada baseado no contexto, incluindo os seus conceitos centrais, modos de fiscalização, auditoria e como interage com outros controlos de rede. Para configurar políticas, consulte Gerir políticas de entrada baseadas no contexto. Para controle de saída sem servidor, consulte O que é controle de saída sem servidor?.

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:

• Bloqueie o acesso a redes não confiáveis exigindo um segundo fator, uma fonte de rede confiável, além das credenciais.
• Permita o acesso a clientes SaaS sem endereços IP de saída estáveis, baseando-o na identidade em vez de em intervalos de endereços IP.
• Limite o acesso permitindo que fontes menos confiáveis usem apenas certos escopos, como APIs do Azure Databricks ou a interface do workspace.
• Proteja a automatização privilegiada: restrinja as identidades de serviço de elevado valor apenas às redes de elevada confiança.
• Auditar eficazmente: Capturar registos detalhados de recusas nas tabelas do sistema Unity Catalog para monitorizar pedidos bloqueados.

Políticas ao nível do espaço de trabalho vs políticas ao nível da conta

O controlo de entrada baseado no contexto utiliza dois tipos de políticas. As políticas ao nível do espaço de trabalho regulam o acesso aos espaços de trabalho. As políticas ao nível da conta regulam o acesso a recursos ao nível da conta, como a consola da conta e o Genie One ao nível da conta.

As políticas ao nível da conta estão em Beta. Para começar, ative Context-Based Ingress: Política de conta.

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:

Política de acesso público:

• Todos os IPs públicos: Qualquer fonte pública da Internet.
• IPs selecionados: endereços IPv4 específicos ou intervalos CIDR.
• Plataformas parceiras (Beta): IPs que aplicações de terceiros (Power BI, Tableau Cloud e plataforma dbt) usam para se ligar ao Azure Databricks. O Azure Databricks gere e atualiza automaticamente estas listas de IP.

Política de acesso privado (Beta):

• Todos os endpoints privados registados: Qualquer endpoint privado registado na conta.
• Pontos finais privados selecionados: Pontos finais privados específicos registados na conta.

• Azure workspace Private Link: Na política de espaço de trabalho apenas para negar as regras. Impede o acesso a todos os databricks_ui_api endpoints.
• Todo o acesso privado: apenas para regras de negação na política do espaço de trabalho. Nega o acesso a todos os databricks_ui_api e aos endpoints registados.

Acesso entre espaços de trabalho (Beta): Controla que espaços de trabalho de origem podem aceder a este espaço de trabalho através de tráfego sem servidor, usando as mesmas identidades e regras de permissão e negação que as outras fontes de rede.

• Espaços de trabalho selecionados: Apenas os espaços de trabalho cujos IDs lista.

Também pode deixar esta política em modo de compatibilidade, caso em que não regula a entrada entre espaços de trabalho e aplicam-se os controlos de rede pré-existentes do espaço de trabalho. Para configurar o acesso entre espaços de trabalho tanto do lado de entrada como do lado de saída, e para rever as suas limitações, veja Acesso entre espaços de trabalho.

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:

Tipos de acesso a políticas ao nível do espaço de trabalho:

• 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-se a qualquer um dos seguintes:
  • Todas as APIs.
  • Um âmbito específico de API, usando IN. Por exemplo, pode especificar aplicações, dashboards ou serviço de modelos.
  • Todos os escopos da API, exceto os selecionados, usando NOT IN.
• Tempo de execução das aplicações: Permitir ou negar o acesso às implementações de aplicações do 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.

• Ambiente de execução do Lakebase: Ligações a instâncias de bases de dados Lakebase. Ver Lakebase. Somente a opção de identidade Todos os usuários e entidades de serviço é suportada para este tipo de acesso.

Tipos de acesso a políticas ao nível da conta (Beta):

• Interface da conta: Acesso através do navegador a recursos ao nível da conta (por exemplo, a consola da conta e o Genie One ao nível da conta).
• API da conta: Acesso programático através das APIs de contas do Azure Databricks.

Identidades

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

Na política ao nível da conta, a única opção disponível é Todos os utilizadores 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.

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 ao nível do espaço de trabalho: Cada conta tem uma política de entrada padrão ao nível do espaço de trabalho aplicada a todos os espaços de trabalho elegíveis sem uma atribuição explícita de política.

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.

A Databricks recomenda começar no modo de simulação para observar o impacto da política antes de a colocar em aplicação obrigatória.

Auditing

As solicitações negadas ou de execução seca são registradas na tabela do system.access.inbound_network sistema. Se não tiveres acesso às tabelas do sistema, um administrador da metastore pode conceder-te permissões. Ver Conceder acesso às tabelas do sistema.

Cada entrada de log inclui:

• Hora do evento
• ID do espaço de trabalho
• Rótulo da regra (da regra que negou o pedido)
• 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 ao espaço de trabalho: Avaliadas juntamente com a política de entrada baseada no contexto usando um AND lógico, sem sequência estrita entre as duas. Um pedido só é permitido se tanto a lista de acesso IP como a política de entrada o permitirem. 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.
• Acesso entre espaços de trabalho: Controla que espaços de trabalho de origem podem aceder a um espaço de trabalho através de tráfego sem servidor, além dos controlos de origem da rede e de identidade nesta página. Consulte Acesso entre espaços de trabalho.
• Listas de acesso de IP de destinatários OpenSharing: A entrada baseada em contexto não se aplica às listas de acesso de IP de destinatários OpenSharing. Estes são um controlo separado para destinatários abertos que os fornecedores configuram por destinatário. Veja Restringir o acesso do destinatário do Open Sharing através de listas de acesso IP (Databricks-to-Open Sharing).

• Conectividade privada de front-end: Para as políticas do espaço de trabalho e um determinado ponto final registado, são permitidos os pontos finais autorizados quer no tráfego de entrada baseado no contexto quer no databricks_ui_api ponto final privado. No entanto, se a política de entrada baseada no contexto do workspace tiver uma regra de negação que bloqueie todos os endpoints databricks_ui_api, então nenhum endpoint databricks_ui_api pode aceder ao Azure Databricks. Consulte Configurar o Private Link de entrada para espaços de trabalho.
• Opção Permitir Acesso à Rede Pública: Quando Permitir Acesso à Rede Pública está Ativado, as listas de acesso IP do espaço de trabalho são avaliadas. Caso contrário, toda a entrada pública é bloqueada e as políticas de entrada pública do espaço de trabalho não são avaliadas.

Gerir políticas de entrada baseadas no contexto

Configure e anexe políticas ao nível que corresponde ao recurso que pretende proteger:

Para configurar regras públicas e privadas na política ao nível da conta que protege os recursos ao nível da conta, consulte Gerenciar políticas de entrada baseadas no contexto da conta.

API e Terraform

Além da consola da conta, pode gerir políticas de entrada baseadas no contexto de forma programática:

• API REST: Use a API REST do Azure Databricks para gerir políticas de rede.
• Terraform: Use o fornecedor Terraform do Azure Databricks para gerir políticas de entrada como infraestrutura como código.

Melhores práticas

• Comece com o modo de ensaio a seco para observar impactos sem interromper o acesso.
• Use regras baseadas na identidade sempre que possível para clientes SaaS que alternam os IPs.
• Aplicar primeiro regras de negação aos principais de serviço privilegiados para limitar a área afetada.
• Mantenha os nomes das apólices claros e consistentes.

Availability