Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo explica como definir as configurações de conectividade no Azure Synapse Analytics, incluindo pools de SQL dedicados e pools de SQL sem servidor, quando aplicável.
Para obter cadeias de conexão para pools do Azure Synapse Analytics, confira Conectar-se ao SQL do Synapse.
As configurações de conectividade e a experiência do portal do Azure para pools de SQL dedicados diferem dependendo se o pool é implantado em um pool de SQL dedicado autônomo (antigo SQL DW) ou em um workspace do Azure Synapse Analytics. Por outro lado, os pools de SQL sem servidor só estão disponíveis em workspaces do Synapse e seguem as mesmas configurações de conectividade que os pools de SQL dedicados criados em um workspace.
- Pools de SQL dedicados e sem servidor em um workspace
- Pools de SQL dedicados autônomos (antigo SQL DW)
Acesso à rede pública
Observação
Essas configurações se aplicam a pools de SQL dedicados e pools de SQL sem servidor criados em um workspace do Azure Synapse. Essas instruções não se aplicam a pools de SQL dedicados associados a pools de SQL dedicados independentes (anteriormente SQL DW).
Você pode usar a funcionalidade de acesso à rede pública para permitir a conectividade de rede pública de entrada para o seu workspace do Azure Synapse.
- Quando o acesso à rede pública estiver desabilitado, você poderá se conectar ao seu workspace somente usando pontos de extremidade privados.
- Quando o acesso à rede pública estiver habilitado, você poderá se conectar ao seu workspace também de redes públicas. Você pode gerenciar esse recurso durante e após a criação do workspace.
Importante
Este recurso só está disponível para workspaces do Azure Synapse associados à rede virtual gerenciada do Azure Synapse Analytics. No entanto, você ainda pode abrir seus workspaces do Azure Synapse na rede pública, independentemente da associação dele com a VNET gerenciada.
Quando o acesso à rede pública estiver desabilitado, o acesso ao modo GIT no Synapse Studio e as confirmações de alterações não serão bloqueados, desde que o usuário tenha permissão suficiente para acessar o repositório Git integrado ou a ramificação Git correspondente. Entretanto, o botão publicar não funcionará porque o acesso ao modo dinâmico está bloqueado pelas configurações do firewall. Quando o acesso à rede pública está desativado, o tempo de integração auto-hospedado ainda pode comunicar com o Synapse. Atualmente, não apoiamos o estabelecimento de uma ligação privada entre um tempo de execução de integração auto-hospedado e o plano de controlo Synapse.
A seleção da opção Desabilitar não aplicará nenhuma regra de firewall que você possa configurar. Além disso, suas regras de firewall aparecerão esmaecidas na configuração de rede no portal do Azure Synapse. Suas configurações de firewall serão reaplicadas quando você habilitar novamente o acesso à rede pública.
Dica
Ao reverter para habilitado, aguarde algum tempo antes de editar as regras de firewall.
Configurar o acesso à rede pública ao criar o seu workspace
Selecione a guia Rede ao criar o workspace no portal do Azure.
Em rede virtual gerenciada, selecione Habilitar para associar seu workspace à rede virtual gerenciada e permitir o acesso à rede pública.
Em Acesso à rede pública, selecione Desabilitar para negar o acesso público ao seu workspace. Selecione Habilitar para permitir acesso público ao seu workspace.
Conclua o restante do fluxo de criação do workspace.
Configurar o acesso à rede pública ao criar o seu workspace
Selecione o seu workspace do Azure Synapse no portal do Azure.
Selecione Rede no painel de navegação à esquerda.
Selecione Desabilitado para negar o acesso público ao seu workspace. Selecione Habilitado para permitir o acesso público ao seu workspace.
Quando ela é desabilitada, o texto Regras de firewall é esmaecido para indicar que as regras de firewall não estão em vigor. As configurações de regra de firewall serão mantidas.
Selecione Salvar para salvar as alterações. Uma notificação confirmará que a configuração de rede foi salva com êxito.
Versão mínima do TLS
O ponto de extremidade de SQL sem servidor e o ponto de extremidade de desenvolvimento aceitam apenas TLS 1.2 e superior.
Desde dezembro de 2021, um nível mínimo de TLS 1.2 é necessário para pools de SQL dedicados gerenciados por workspace em novos workspaces do Synapse. Você pode aumentar ou diminuir esse requisito usando a API REST TLS mínima para novos espaços de trabalho do Synapse ou espaços de trabalho existentes, de modo que os usuários que não podem usar uma versão mais alta do cliente TLS nos espaços de trabalho possam se conectar. Os clientes também poderão aumentar a versão mínima de TLS para atender às suas necessidades de segurança.
Importante
O Azure começará a desativar as versões mais antigas do TLS (TLS 1.0 e 1.1) a partir de novembro de 2024. Use o TLS 1.2 ou superior. Após 31 de março de 2025, você não poderá mais definir a versão mínima do TLS para conexões de cliente do Azure Synapse Analytics abaixo de TLS 1.2. Após essa data, as tentativas de entrada de conexões que usam uma versão do TLS inferior a 1.2 falharão. Para obter mais informações, confira Anúncio: O suporte do Azure para TLS 1.0 e TLS 1.1 será encerrado.
Azure Policy
A política do Azure para impedir modificações nas configurações de rede no Espaço de trabalho do Synapse não está disponível no momento.
Política de Conexão
A política de conexão do SQL do Synapse no Azure Synapse Analytics é definida como Padrão. Você não pode alterar a política de conexão para pools de SQL dedicados ou sem servidor no Azure Synapse Analytics.
Logons para pools de SQL no Azure Synapse Analytics podem ocorrer em qualquer um dos endereços IP de Gateway individuais ou sub-redes de Gateway em uma região. Para garantir conectividade consistente, permita o tráfego de rede de e para todos os Endereços IP do Gateway individuais e sub-redes de Endereços IP do Gateway em uma região. Consulte os Intervalos de IP do Azure e as Marcas de Serviço – Nuvem Pública para obter uma lista dos endereços IP da sua região que devem ser permitidos.
-
Padrão: essa é a política de conexão em vigor em todos os servidores após a criação, a menos que você altere explicitamente a política de conexão para
ProxyouRedirect. A política padrão é:-
Redirectpara todas as conexões de cliente originadas dentro do Azure (por exemplo, de uma Máquina Virtual do Azure). -
Proxypara todas as conexões de cliente originadas de fora (por exemplo, da sua estação de trabalho local).
-
-
Redirecionar: Os clientes estabelecem conexões diretamente com o nó que hospeda o banco de dados, levando à latência reduzida e à taxa de transferência aprimorada. Para as conexões usarem esse modo, os clientes precisam:
- Permitir a comunicação de saída do cliente para todos os endereços IP do Azure SQL na região em portas que estão no intervalo de 11000 a 11999. Usar os Service Tags do SQL para facilitar o gerenciamento. Se você estiver usando o Link Privado, confira Usar a política de conexão Redirecionar com pontos de extremidade privados para saber os intervalos de portas a serem permitidos.
- Permitir comunicação de saída do cliente para os endereços IP do gateway do Banco de Dados SQL do Azure na porta 1433.
- Ao usar a política de conexão de redirecionamento, consulte os Intervalos de IP e Marcas de Serviço do Azure – Nuvem Pública para obter uma lista dos endereços IP da sua região que devem ser permitidos.
-
Proxy: Nesse modo, todas as conexões são roteadas por meio dos gateways do Banco de Dados SQL do Azure, resultando em um aumento na latência e uma redução na taxa de transferência. Para as conexões usarem esse modo, os clientes precisam permitir a comunicação de saída do cliente para endereços IP do gateway do Banco de Dados SQL do Azure na porta 1433.
- Ao usar a política de conexão proxy, permita os endereços IP da sua região na lista de endereços IP do Gateway.