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 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.

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:

• 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.

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 direcionar todas as APIs ou um escopo de API específico, como aplicativos, dashboard ou serviço de modelo.
• 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. Consulte instâncias do 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 no nível da conta:

• 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.

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.

• 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. Veja Configurar Inbound Link Privado para espaços de trabalho.
• 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.

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.