Visão geral da rede – Banco de Dados do Azure para PostgreSQL – Servidor flexível (versão preliminar)

Este artigo descreve os conceitos de conectividade e rede para o Banco de Dados do Azure para PostgreSQL - Servidor flexível. A opção de implantação do Servidor está atualmente em versão preliminar.

Ao criar uma instância do Servidor flexível do Banco de Dados do Azure para PostgreSQL (um servidor flexível), você precisa escolher uma das seguintes opções de rede: Acesso privado (integração VNet) ou Acesso público (endereços IP permitidos) .

Observação

Não é possível alterar a opção de rede depois que o servidor é criado.

As seguintes características se aplicam se você escolher usar o acesso privado ou a opção de acesso público:

  • As conexões de endereços IP permitidos precisam ser autenticadas no servidor PostgreSQL com credenciais válidas.
  • A criptografia de conexão está imposta ao tráfego da sua rede.
  • O servidor tem um FQDN (nome de domínio totalmente qualificado). Para a propriedade hostname em cadeias de conexão, é recomendável usar o FQDN em vez de um endereço IP.
  • As duas opções controlam o acesso no nível do servidor, não no nível do banco de dados ou da tabela. Você usaria as propriedades de funções do PostgreSQL para controlar o banco de dados, a tabela e o acesso a outros objetos.

Observação

Como o Banco de Dados do Azure para PostgreSQL é um serviço de banco de dados gerenciado, os usuários não recebem acesso de host ou de sistema operacional para exibir ou modificar arquivos de configuração, como pg_hba.conf. O conteúdo dos arquivos é atualizado automaticamente com base nas configurações de rede.

Acesso privado (integração da VNet)

Você pode implantar um servidor flexível em sua Rede Virtual do Azure (VNet). As redes virtuais do Azure fornecem comunicação de rede privada e segura. Os recursos em uma rede virtual podem se comunicar por meio de endereços IP privados que tiverem sido atribuídos nessa rede.

Escolha esta opção de rede se você deseja as seguintes funcionalidades:

  • Conectar-se a partir de recursos do Azure na mesma rede virtual com seu servidor flexível usando endereços IP privados.
  • Usar uma VPN ou o Azure ExpressRoute para se conectar ao seu servidor flexível a partir de recursos não Azure.
  • Verifique se o servidor flexível não tem nenhum ponto de extremidade público acessível pela Internet.

Diagrama que mostra como funciona o emparelhamento entre redes virtuais quando uma dessas redes inclui um servidor flexível.

No diagrama anterior:

  • Os servidores flexíveis são injetados na sub-rede 10.0.1.0/24 da rede virtual VNet-1.
  • Os aplicativos implantados em sub-redes diferentes na mesma rede virtual podem acessar os servidores flexíveis diretamente.
  • Os aplicativos implantados em uma rede virtual diferente (VNet-2) não têm acesso direto aos servidores flexíveis. É necessário executar o emparelhamento de rede virtual para uma zona DNS privada para que eles possam acessar o servidor flexível.

Conceitos de rede virtual

Uma rede virtual do Azure contém um espaço de endereços IP privado configurado para o uso. A rede virtual deve estar na mesma região do Azure que o servidor flexível. Para saber mais sobre redes virtuais do Azure, consulte Visão geral da Rede Virtual do Azure.

Estes são alguns conceitos que você deve conhecer ao usar redes virtuais com servidores flexíveis PostgreSQL:

  • Sub-rede delegada. Uma rede virtual contém sub-redes. As sub-redes permitem segmentar a rede virtual em espaços de endereço menores. Os recursos do Azure são implantados em sub-redes específicas dentro de uma rede virtual.

    O seu servidor flexível precisa estar uma sub-rede delegada. Ou seja, somente instâncias do Banco de Dados PostgreSQL do Azure - Servidor flexível podem usar essa sub-rede. Nenhum outro tipo de recurso do Azure pode estar na sub-rede delegada. Para delegar uma sub-rede, você precisa atribuir a propriedade de delegação dessa rede como Microsoft.DBforPostgreSQL/flexibleServers.

    Importante

    Os nomes AzureFirewallSubnet,AzureFirewallManagementSubnet,AzureBastionSubnet e GatewaySubnet estão reservados no âmbito do Azure. Não use nenhum desses nomes como o nome da sua sub-rede.

  • NSG (grupo de segurança de rede) . As regras de segurança em grupos de segurança de rede permitem filtrar o tipo de tráfego de rede que pode fluir para dentro e para fora das sub-redes da rede virtual e dos adaptadores de rede. Para obter mais informações, confira a Visão geral dos grupos de segurança de rede.

    Os ASGs (grupos de segurança de aplicativo) facilitam o controle da segurança da camada 4 usando os grupos de segurança de rede em redes simples. É possível rapidamente:

    • Unir máquinas virtuais a um ASG ou remover máquinas virtuais de um ASG.
    • Aplicar regras a essas máquinas virtuais ou remover regras dessas máquinas virtuais de maneira dinâmica.

    Para obter mais informações, confira a Visão geral dos ASGs.

    Neste momento, não oferecemos suporte ao uso de grupos de segurança de rede com o Banco de Dados do Azure para PostgreSQL – Servidor flexível nos casos em que um ASG faça parte da regra. Atualmente, recomendados o uso de filtros de origem ou destino baseados em IP em um grupo de segurança de rede.

    Importante

    Recursos de alta disponibilidade do Banco de Dados do Azure para PostgreSQL - o servidor flexível requer a capacidade de enviar\receber tráfego para as portas de destino 5432, 6432 na sub-rede da rede virtual do Azure em que o Banco de Dados do Azure para PostgreSQL - servidor flexível está implantado, bem como ao armazenamento do Azure para arquivamento de log. Se você criar Grupos de segurança de rede (NSG) para negar o fluxo de tráfego de ou para o Banco de Dados do Azure para PostgreSQL – Servidor flexível na sub-rede em que ele foi implantado, precisará permitir o tráfego para as portas de destino 5432 e 6432 na sub-rede e também para o armazenamento do Azure usando a marca de serviço Armazenamento do Azure como destino.

  • Integração de zona DNS privada. A integração de zona DNS privada do Azure permite que você resolva o DNS privado na rede virtual atual ou em qualquer rede virtual emparelhada na região à qual a zona de DNS privado esteja vinculada.

Usar uma zona DNS privada

Se você usar o portal do Azure ou o CLI do Azure para criar servidores flexíveis com uma rede virtual, uma nova zona DNS privada será automaticamente provisionada para cada servidor em sua assinatura, usando o nome do servidor que você fornecer.

Se for usar uma API do Azure, um modelo do Azure Resource Manager (modelo do ARM) ou o Terraform, crie zonas DNS privadas que terminem com postgres.database.azure.com. Use essas zonas ao configurar servidores flexíveis com acesso privado. Para saber mais, confira a Visão geral de zonas DNS privadas.

Ao usar o acesso à rede privada com a rede virtual do Azure, é obrigatório fornecer as informações de zona DNS privadas em várias interfaces, incluindo API, ARM e Terraform. Portanto, para a criação do novo Banco de Dados do Azure para PostgreSQL de servidor flexível usando o acesso à rede privada com API, ARM ou Terraform, crie zonas DNS privadas e use-as ao configurar servidores flexíveis com acesso privado. Veja mais informações sobre as especificações da API REST para o Microsoft Azure. Se você usar o portal do Azure ou a CLI do Azure para criar servidores flexíveis, poderá fornecer um nome de zona DNS privada que você criou anteriormente no mesmo ou em uma assinatura diferente ou uma zona DNS privada padrão será criada automaticamente em sua assinatura.

Integração com um servidor DNS personalizado

Se estiver usando um servidor DNS personalizado, você deverá usar um encaminhador de DNS para resolver o FQDN do Banco de Dados do Azure para PostgreSQL – Servidor flexível. O endereço IP do encaminhador deve ser 168.63.129.16.

O servidor de DNS personalizado deve estar dentro da rede virtual, ou ser acessível por meio da configuração do servidor DNS da rede virtual. Para obter mais informações, consulte Resolução de nome usando seu próprio servidor DNS.

Zonas DNS privadas e emparelhamento de rede virtual

As configurações de zona DNS privada e o emparelhamento de redes virtuais são independentes um do outro. Se você deseja se conectar ao servidor flexível de um cliente provisionado em outra rede virtual da mesma região ou de uma região diferente, será necessário vincular a zona DNS privada à rede virtual. Para saber mais, confira Vincular rede virtual.

Observação

Apenas nomes de zonas DNS privadas que terminam com postgres.database.azure.com podem ser vinculados.

Cenários de rede virtual sem suporte

Aqui estão algumas limitações ao se trabalhar com redes virtuais:

  • Um servidor flexível implantado em uma rede virtual não pode ter um ponto de extremidade público (ou um endereço IP ou DNS públicos).
  • Depois que o servidor flexível for implantado em uma rede virtual e uma sub-rede, você não poderá movê-lo para outra rede virtual ou sub-rede. Não é possível mover a rede virtual para outro grupo de recursos ou assinatura.
  • Não é possível aumentar o tamanho da sub-rede (espaços de endereços) depois que já houver recursos na sub-rede.
  • Servidores flexíveis não oferecem suporte ao Link Privado do Azure. Em vez disso, é usada uma injeção de rede virtual para tornar o servidor flexível disponível em uma rede virtual.

Acesso público (endereços IP permitidos)

Quando você escolhe o método de acesso público, seu servidor flexível é acessado na internet por meio de um ponto de extremidade público. O ponto de extremidade público é um endereço DNS que poderia ser resolvido publicamente. A frase endereços IP permitidos refere-se a um intervalo de IPs que você escolhe para conceder permissão de acesso ao seu servidor. Essas permissões são chamadas regras de firewall.

Escolha esta opção de rede se você deseja ter as seguintes funcionalidades:

  • Conectar-se a partir de recursos do Azure que não têm suporte a redes virtuais.
  • Conectar-se a partir de recursos de fora do Azure que não estão conectados por uma VPN ou pelo ExpressRoute.
  • Verifique se o servidor flexível tem um ponto de extremidade público acessível pela Internet.

As características do método de acesso público incluem:

  • Somente os endereços IP que você autorizar terão permissão para acessar o servidor flexível PostgreSQL. Por padrão, nenhum endereço IP está permitido. Você pode adicionar endereços IP durante a criação do servidor ou posteriormente.
  • O servidor PostgreSQL tem um nome DNS que pode ser resolvido publicamente.
  • O servidor flexível não está em uma das redes virtuais do Azure.
  • O tráfego de rede de e para o servidor não passa por uma rede privada. O tráfego usa os caminhos gerais da Internet.

Regras de firewall

Se uma tentativa de conexão vier de um endereço IP que você não permitiu por meio de uma regra de firewall, o cliente de origem receberá um erro.

Permitir todos os endereços IP do Azure

Se um endereço IP de saída fixo não estiver disponível para o serviço do Azure, você pode pensar em habilitar conexões de todos os endereços IP para os datacenters do Azure.

Importante

A opção permitir acesso público dos serviços e recursos do Azure no Azure configura o firewall para permitir todas as conexões do Azure, incluindo conexões das assinaturas de outros clientes. Se selecionar essa opção, verifique se as permissões de logon e de usuário limitam o acesso somente a usuários autorizados.

Solução de problemas de acesso público

Considere os seguintes pontos quando o acesso ao serviço do Banco de Dados do Azure para PostgreSQL não se comportar conforme o esperado:

  • As alterações à lista de permitidos ainda não entraram em vigor: . Pode haver um atraso de até cinco minutos para que as alterações na configuração do firewall do servidor do Banco de Dados do Azure para PostgreSQL entrem em vigor.

  • Falha na autenticação. Se um usuário não tiver permissões no servidor do Banco de Dados do Azure para PostgreSQL, ou se a senha usada estiver incorreta, a conexão com o Banco de Dados do Azure para PostgreSQL será negada. A criação de uma configuração de firewall apenas oferece aos clientes a oportunidade de tentarem se conectar ao seu servidor. O cliente ainda deve fornecer as credenciais de segurança necessárias.

  • O endereço IP dinâmico do cliente está impedindo o acesso. Se você tiver uma conexão com a Internet com endereçamento IP dinâmico e estiver tendo problemas para acessar o firewall, tente uma das seguintes soluções:

    • Peça ao seu Provedor de serviços de Internet (ISP) o intervalo de endereços IP atribuído aos computadores clientes que acessarão o servidor do Banco de Dados do Azure para PostgreSQL. Em seguida, adicione o intervalo de endereços IP como uma regra de firewall.
    • Obtenha o endereçamento IP estático para os computadores cliente e adicione os endereços IP estáticos como uma regra de firewall.
  • A regra de firewall não está disponível para o formato IPv6. As regras de firewall devem estar no formato IPv4. Se forem especificadas regras de firewall no formato IPv6, será exibido um erro de validação.

Nome do host

Qualquer que seja a opção de rede escolhida, é recomendável usar sempre um FQDN (nome de domínio totalmente qualificado) como nome do host ao se conectar ao servidor flexível. Não há garantia de que o endereço IP do servidor permanecerá estático. Usar o FQDN ajudará você a evitar fazer alterações na cadeia de conexão.

Um exemplo que usa um FQDN como nome de host é hostname = servername.postgres.database.azure.com. Sempre que possível, evite usar hostname = 10.0.0.4 (um endereço privado) ou hostname = 40.2.45.67 (um endereço público).

TLS e SSL

O Banco de Dados do Azure para PostgreSQL - Servidor flexível impõe o uso do protocolo TLS para conectar os aplicativos clientes ao serviço do PostgreSQL. O TLS é um protocolo padrão do setor que garante conexões de rede criptografadas entre o servidor de banco de dados e os aplicativos cliente. O TLS é um protocolo atualizado do protocolo SSL.

O Banco de Dados do Azure para PostgreSQL oferece suporte a ao TLS 1.2 e posterior. Na RFC 8996, a IETF (Internet Engineering Task Force) declara explicitamente que o TLS 1.0 e o TLS 1.1 não devem ser usados. Ambos os protocolos foram preteridos no final de 2019.

Todas as conexões de entrada que usarem versões anteriores do protocolo TLS, como o TLS 1.0 e TLS 1.1, serão negadas por padrão.

Observação

Certificados SSL e TLS certificam que sua conexão é protegida com protocolos de criptografia de ponta. Ao criptografar a conexão na rede, você impede o acesso não autorizado aos seus dados em trânsito. É por isso que é altamente recomendável usar versões mais recentes do TLS para criptografar suas conexões com o Banco de Dados do Azure para PostgreSQL – Servidor flexível. Embora não seja recomendado, se necessário, você tem a opção de desabilitar TLS\SSL para conexões com o Banco de Dados do Azure para PostgreSQL – Servidor Flexível atualizando o parâmetro do servidor require_secure_transport para OFF. Você também pode definir a versão do TLS definindo ssl_min_protocol_version e ssl_max_protocol_version como parâmetros do servidor.

Próximas etapas