Controle de entrada baseado em contexto

Esta página oferece uma visão geral do controle de entrada baseado em contexto, incluindo seus conceitos centrais, modos de fiscalização, auditoria e como ele interage com outros controles de rede. Para configurar políticas, veja Gerenciar políticas de entrada baseadas em contexto. Para controle de saída sem servidor, consulte o que é controle de saída sem servidor?.

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 conta definam regras de permissão e negação que combinem ho está chamando, de onde eles estão chamando e o que eles podem alcançar em 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.

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.
• Permita o acesso a clientes SaaS sem IPs de saída estáveis com base na identidade, em vez de intervalos de IP.
• Limite o acesso permitindo que fontes menos confiáveis usem apenas determinados escopos, como APIs de Azure 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 Catálogo do Unity para monitorar as solicitações bloqueadas.

Políticas em nível de espaço de trabalho vs políticas em nível de conta

O controle de entrada baseado em contexto utiliza dois tipos de políticas. Políticas em nível de espaço de trabalho regem o acesso aos espaços de trabalho. Políticas em nível de conta regem o acesso a recursos em nível de conta, como o console de conta e o Genie One em nível de conta.

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

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:

Política de acesso público:

• Todos os IPs públicos: qualquer fonte de Internet pública.
• IPs selecionados: endereços IPv4 específicos ou intervalos CIDR.
• Plataformas parceiras (Beta): IPs que aplicativos de terceiros (Power BI, Tableau Cloud e plataforma dbt) usam para se conectar ao Azure Databricks. Azure Databricks gerencia e atualiza essas listas de IP automaticamente.

Política de acesso privado (Beta):

• Todos os pontos de extremidade privados registrados: qualquer ponto de extremidade privado registrado na conta.
• Pontos de extremidade privados selecionados: pontos de extremidade privados registrados específicos na conta.

• Link Privado do workspace do Azure: somente regras de negação na política do workspace. Nega o acesso a todos os databricks_ui_api endpoints.
• Todo o acesso privado: somente regras de negação na política do workspace. Nega o acesso a todos os databricks_ui_api e pontos de extremidade registrados.

Acesso entre espaços de trabalho (Beta): Controla quais espaços de trabalho de origem podem acessar este espaço de trabalho via tráfego sem servidor, usando as mesmas identidades e regras de permissão e negação que as usadas para outras fontes de rede.

• Espaços de trabalho selecionados: Apenas os espaços cujos IDs você listar.

Você também pode deixar essa política no modo de compatibilidade, caso em que ela não governa a entrada entre espaços de trabalho e os controles de rede pré-existentes do workspace se aplicam. Para configurar o acesso entre espaços de trabalho tanto no lado de entrada quanto no de saída, e para revisar suas limitações, veja Acesso entre espaços de trabalho.

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:

Tipos de acesso à política em nível de espaço de trabalho:

• UI do Workspace: Acesso ao Workspace via navegador.
• API: acesso programático via APIs do Azure Databricks, incluindo endpoints SQL (JDBC / ODBC). Você pode mirar em qualquer um dos seguintes objetivos:
  • Todas as APIs.
  • Um escopo específico de API, usando IN. Por exemplo, você pode especificar apps, dashboards ou servidores de modelos.
  • Todos os escopos da API, exceto os selecionados, usando NOT IN.
• Runtime dos Aplicativos: permita ou negue acesso a implantações de Aplicativos do Databricks. Consulte Os Aplicativos do Databricks. Somente a opção de identidade Todos os usuários e entidades de serviço é suportada nesse tipo de acesso.

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

Tipos de acesso à política em nível de conta (Beta):

• Interface da conta: acesso via navegador aos recursos em nível de conta (por exemplo, o console da conta e o Genie One em nível de conta).
• API da conta: acesso programático por meio de APIs de conta Azure Databricks.

Identidades

As regras podem ter como destino diferentes tipos de identidade. Para os tipos de acesso Runtime dos Aplicativos e Runtime do Lakebase, a única opção com suporte é Todos os usuários e entidades de serviço.

Na política de nível de conta, 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.

Avaliação de regra

• 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 que você defina exceções às suas regras de permissão.
• Política padrão em nível de workspace: cada conta possui uma política de entrada padrão em nível de workspace, aplicada a todos os workspaces elegíveis que não tenham uma política atribuída explicitamente.

Modos de imposição

As políticas de entrada baseadas em contexto habilitam dois modos:

• Aplicado a todos os produtos: o Azure Databricks aplica ativamente regras e bloqueia solicitações que as violam.
• Modo de simulação para todos os produtos: o Azure Databricks registra violações, mas não bloqueia solicitações. Use esse modo para avaliar o impacto da política antes de impor.

A Databricks recomenda iniciar no modo de simulação para observar o impacto da política antes de colocá-la em modo de aplicação.

Auditing

As solicitações negadas ou simuladas são registradas na system.access.inbound_network tabela do sistema. Se você não tiver acesso a tabelas do sistema, um administrador do metastore poderá conceder permissões a você. Veja Conceder acesso às tabelas do sistema.

Cada entrada de log inclui:

• Hora do evento
• ID do workspace
• Rótulo de regra (da regra que negou a solicitação)
• Tipo de solicitação
• Identidade
• Fonte de rede
• Tipo de acesso (NEGADO ou SIMULAÇÃO_NEGADA)

Consulte esses logs para verificar se suas regras funcionam conforme o esperado e para capturar tentativas de acesso inesperadas.

Relação com outros controles

• Listas de acesso IP do workspace: avaliadas em conjunto com a política de entrada baseada em contexto usando um AND lógico, sem sequência estrita entre os dois. Uma solicitação será permitida somente se tanto a lista de acesso IP quanto 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 computação sem servidor. Consulte Gerenciar políticas de rede.
• Acesso entre espaços de trabalho: Controla quais espaços de trabalho de origem podem acessar um espaço de trabalho por meio de tráfego serverless, além dos controles de origem da rede e de identidade nesta página. Veja Acesso entre espaços de trabalho.
• Listas de acesso de IP de destinatários OpenSharing: Entrada baseada em contexto não se aplica às listas de acesso de IP de destinatários do OpenSharing. Esses são um controle separado para destinatários abertos que os provedores configuram por destinatário. Confira Restringir o acesso do destinatário do OpenSharing usando listas de acesso de IP (compartilhamento Databricks-to-Open).

• Conectividade privada de front-end: para políticas de workspace e um determinado ponto de extremidade registrado, os pontos de extremidade permitidos na entrada baseada em contexto ou no ponto de extremidade privado databricks_ui_api são permitidos. 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 poderá acessar o Azure Databricks. Consulte Configurar link privado de entrada para workspaces.
• Permitir alternância de acesso à rede pública: quando Permitir acesso à rede pública estiver habilitado, as listas de acesso ip do workspace serão avaliadas. Caso contrário, todas as entradas públicas serão bloqueadas e as políticas de entrada pública do workspace não serão avaliadas.

Gerencie políticas de entrada baseadas em contexto

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

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

API e Terraform

Além do console da conta, você pode gerenciar políticas de entrada baseadas em contexto de forma programática:

• API REST: Use a API REST do Azure Databricks para gerenciar políticas de rede.
• Terraform: Use o provedor Terraform do Azure Databricks para gerenciar políticas de ingresso como infraestrutura como código.

Práticas recomendadas

• Comece com o modo de simulação para observar os impactos sem interromper o acesso.
• Use regras com base 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 a área afetada.
• Mantenha os nomes de políticas claros e consistentes.

Disponibilidade