Visão geral de rede para Base de Dados do Azure para PostgreSQL - Servidor Flexível

APLICA-SE A: Base de Dados do Azure para PostgreSQL - Servidor Flexível

Este artigo descreve conceitos de conectividade e networking para Base de Dados do Azure para PostgreSQL - Servidor Flexível.

Quando criar uma Base de Dados do Azure para PostgreSQL - Instância do Servidor Flexível (um servidor flexível), deve escolher uma das seguintes opções de networking: Acesso privado (integração VNet) ou acesso público (endereços IP permitidos).

Nota

Não é possível alterar a sua opção de rede após a criação do servidor.

Aplicam-se as seguintes características quer opte por utilizar o acesso privado ou a opção de acesso público:

  • As ligações de endereços IP permitidos precisam de autenticar para o servidor PostgreSQL com credenciais válidas.
  • A encriptação de ligação é aplicada para o tráfego da sua rede.
  • O servidor tem um nome de domínio totalmente qualificado (FQDN). Para a hostname propriedade em cadeias de ligação, recomendamos a utilização do FQDN em vez de um endereço IP.
  • Ambas as opções controlam o acesso ao nível do servidor, não no nível da base de dados ou da tabela. Utilizaria as propriedades de funções do PostgreSQL para controlar a base de dados, a tabela e outros acessos a objetos.

Nota

Como Base de Dados do Azure para PostgreSQL é um serviço de base de dados gerido, os utilizadores não têm acesso ao anfitrião ou ao OS para visualizar ou modificar ficheiros de configuração tais como pg_hba.conf. O conteúdo dos ficheiros é automaticamente atualizado com base nas definições de rede.

Acesso privado (Integração de VNet)

Pode implantar um servidor flexível na sua rede virtual Azure (VNet). As redes virtuais Azure fornecem comunicação de rede privada e segura. Os recursos numa rede virtual podem comunicar através de endereços IP privados que foram atribuídos nesta rede.

Escolha esta opção de networking se quiser as seguintes capacidades:

  • Conecte-se dos recursos Azure na mesma rede virtual ao seu servidor flexível utilizando endereços IP privados.
  • Utilize VPN ou Azure ExpressRoute para ligar de recursos não Azure ao seu servidor flexível.
  • Certifique-se de que o servidor flexível não tem nenhum ponto final público que seja acessível através da internet.

Diagrama que mostra como o espreitamento funciona entre redes virtuais, uma das quais 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.
  • As aplicações que são implementadas em diferentes sub-redes dentro da mesma rede virtual podem aceder diretamente a servidores flexíveis.
  • As aplicações que são implementadas numa rede virtual diferente (VNet-2) não têm acesso direto a servidores flexíveis. Tem de realizar um controlo de rede virtual para uma zona privada de DNS antes de poder aceder ao servidor flexível.

Conceitos de rede virtual

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

Aqui estão alguns conceitos a conhecer quando você está usando redes virtuais com servidores flexíveis PostgreSQL:

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

    O seu servidor flexível deve estar numa sub-rede delegada. Ou seja, apenas Base de Dados do Azure para PostgreSQL - As instâncias do Servidor Flexível podem usar essa sub-rede. Nenhum outro tipo de recurso do Azure pode estar na sub-rede delegada. Delega uma sub-rede atribuindo a sua propriedade de delegação como Microsoft.DBforPostgreSQL/flexibleServers. A menor gama CIDR que pode especificar para uma sub-rede é /28, que fornece catorze endereços IP, no entanto o primeiro e último endereço em qualquer rede ou sub-rede não pode ser atribuído a qualquer anfitrião individual. O Azure reserva cinco IPs a utilizar internamente pela rede Azure, que incluem dois IPs que não podem ser designados para hospedar, mencionados acima. Isto deixa-lhe onze endereços IP disponíveis para a gama CIDR /28, enquanto um único Servidor Flexível com funcionalidades de Alta Disponibilidade utiliza 4 endereços.

    Importante

    Os nomes são AzureFirewallManagementSubnetreservados GatewaySubnetAzureFirewallSubnetAzureBastionSubnetem Azure. Não use nenhum destes como o nome da sua sub-rede.

  • Grupo de segurança de rede (NSG). As regras de segurança nos NSGs permitem filtrar o tipo de tráfego de rede que pode fluir dentro e fora das sub-redes de rede virtuais e interfaces de rede. Para mais informações, consulte a visão geral do NSG.

    Os grupos de segurança de aplicações (ASGs) facilitam o controlo da segurança da Camada 4 utilizando NSGs para redes planas. Pode rapidamente:

    • Junte máquinas virtuais a um ASG ou remova máquinas virtuais de um ASG.
    • Aplicam dinamicamente regras a essas máquinas virtuais ou removem as regras dessas máquinas virtuais.

    Para mais informações, consulte a visão geral da ASG.

    Neste momento, não apoiamos NSGs onde um ASG faz parte da regra com Base de Dados do Azure para PostgreSQL - Servidor Flexível. Atualmente aconselhamos a utilização de uma fonte baseada em IP ou filtragem de destino num NSG.

    Importante

    Funcionalidades de alta disponibilidade de Base de Dados do Azure para PostgreSQL - Servidor Flexível requerem capacidade de enviar tráfego para as portas de destino 5432, 6432 dentro da sub-rede de rede virtual Azure onde Base de Dados do Azure para PostgreSQL - Servidor Flexível é implantado , bem como para o armazenamento de Azure para arquivo de registos. Se criar Grupos de Segurança de Rede (NSG) para negar o fluxo de tráfego de ou para o seu Base de Dados do Azure para PostgreSQL - Servidor Flexível dentro da sub-rede onde foi implantado, certifique-se de permitir que o tráfego para as portas de destino 5432 e 6432 dentro da sub-rede, e também para o armazenamento Azure, utilizando a etiqueta de serviço Azure Storage como destino.

  • DNS Privado integração de zona. A integração privada da zona de DNS permite-lhe resolver o DNS privado dentro da rede virtual atual ou qualquer rede virtual na região onde a zona privada de DNS está ligada.

Usando uma zona privada de DNS

Se utilizar o portal do Azure ou o CLI Azure para criar servidores flexíveis com uma rede virtual, uma nova zona privada de DNS é automaticamente fornecida para cada servidor na sua subscrição utilizando o nome do servidor que forneceu.

Se utilizar um API Azure, um modelo de Resource Manager Azure (modelo ARM) ou Terraform, crie zonas privadas de DNS que terminam com .postgres.database.azure.com. Utilize essas zonas enquanto configura servidores flexíveis com acesso privado. Por exemplo, use o formulário [name1].[name2].postgres.database.azure.com ou [name].postgres.database.azure.com. . Se optar por utilizar o formulário [name].postgres.database.azure.com, o nome não pode ser o nome que utiliza para um dos seus servidores flexíveis ou será mostrada uma mensagem de erro durante o provisionamento. Para mais informações, consulte as zonas privadas do DNS.

Ao utilizar o acesso à rede privada com a rede virtual Azure, fornecer a informação privada da zona DNS é obrigatório em várias interfaces, incluindo API, ARM e Terraform. Portanto, para novas criações de servidores flexíveis Base de Dados do Azure para PostgreSQL utilizando o acesso à rede privada com API, ARM ou Terraform, crie zonas privadas de DNS e use-as enquanto configura servidores flexíveis com acesso privado. Consulte mais informações sobre as especificações da API REST para Microsoft Azure. Se utilizar o portal do Azure ou Azure CLI para criar servidores flexíveis, pode fornecer um nome de zona de DNS privado que tinha criado anteriormente na mesma ou uma subscrição diferente ou uma zona de DNS privada predefinida é criada automaticamente na sua subscrição.

Utilizando o Portal Azure, CLI ou ARM, também pode alterar a Zona DNS privada da que forneceu ao criar o seu Base de Dados do Azure para PostgreSQL - Servidor Flexível para outra zona privada de DNS que existe a mesma ou subscrição diferente.

Importante

A capacidade de alterar a Zona de DNS privada a partir da que forneceu ao criar o seu Base de Dados do Azure para PostgreSQL - O Servidor Flexível para outra zona privada de DNS está atualmente desativada para servidores com funcionalidade de Alta Disponibilidade ativada.

Integração com um servidor DNS personalizado

Se estiver a utilizar um servidor DNS personalizado, tem de utilizar um reencaminhador DNS para resolver o FQDN de Base de Dados do Azure para PostgreSQL - Servidor Flexível. O endereço IP do reencaminhador deve ser de 168.63.129.16.

O servidor DNS personalizado deve estar dentro da rede virtual ou acessível através da definição do servidor DNS da rede virtual. Para saber mais, consulte a resolução Nome que utiliza o seu próprio servidor DNS.

DNS Privado zona e rede virtual de observação

DNS Privado as configurações da zona e o espreitamento de rede virtual são independentes uns dos outros. Se quiser ligar ao servidor flexível de um cliente que esteja alotado noutra rede virtual da mesma região ou de uma região diferente, tem de ligar a zona privada de DNS à rede virtual. Para mais informações, consulte Link the virtual network.

Nota

Apenas os nomes privados da zona DE DNS que terminam com postgres.database.azure.com podem ser ligados. O nome da zona DNS não pode ser o mesmo que o seu servidor flexível, caso contrário, a resolução de nomes falhará.

Cenários de rede virtual não suportados

Aqui ficam algumas limitações para trabalhar com redes virtuais:

  • Um servidor flexível implementado numa rede virtual não pode ter um ponto final público (nem IP público ou DNS).
  • Depois de um servidor flexível ser implementado numa rede virtual e numa sub-rede, não será possível movê-lo para outra rede virtual ou sub-rede. Não é possível mover a rede virtual para outro grupo de recursos ou subscrição.
  • O tamanho da sub-rede (espaços de endereços) não pode ser aumentado depois de os recursos existirem na mesma.
  • Um servidor flexível não suporta Azure Private Link. Em vez disso, utiliza a injeção de rede virtual para disponibilizar o servidor flexível dentro de uma rede virtual.

Importante

O Azure Resource Manager suporta a capacidade de bloquear recursos, como controlo de segurança. Os bloqueios de recursos são aplicados ao recurso e são eficazes em todos os utilizadores e funções. Existem dois tipos de bloqueio de recursos: CanNotDelete e ReadOnly. Estes tipos de bloqueio podem ser aplicados quer numa zona de DNS Privado, quer para um conjunto de registos individuais. A aplicação de um bloqueio de qualquer tipo contra DNS Privado Zone ou um conjunto de registos individuais pode interferir com a capacidade de Base de Dados do Azure para PostgreSQL - Serviço de Servidor Flexível para atualizar registos DNS e causar problemas durante operações importantes no DNS, tais como falha de Alta Disponibilidade do primário para o secundário. Por estas razões, certifique-se de que não está a utilizar a zona privada do DNS ou as fechaduras de gravação ao utilizar funcionalidades de Alta Disponibilidade com Base de Dados do Azure para PostgreSQL - Servidor Flexível.

Acesso público (endereços IP permitidos)

Ao escolher o método de acesso público, o seu servidor flexível é acedido através de um ponto final público através da internet. O ponto final público é um endereço DNS publicamente resolvível. A frase permitida endereços IP refere-se a uma série de endereços IP que escolhe dar permissão para aceder ao seu servidor. Estas permissões são chamadas regras de firewall.

Escolha esta opção de networking se quiser as seguintes capacidades:

  • Conecte-se a partir de recursos Azure que não suportam redes virtuais.
  • Conecte-se a partir de recursos fora do Azure que não estão ligados pela VPN ou Pela ExpressRoute.
  • Certifique-se de que o servidor flexível tem um ponto final público que é acessível através da internet.

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

  • Apenas os endereços IP que permite têm permissão para aceder ao seu servidor flexível PostgreSQL. Por predefinição, não são permitidos endereços IP. Pode adicionar endereços IP durante a criação do servidor ou depois.
  • O seu servidor PostgreSQL tem um nome DNS publicamente resolúvel.
  • O seu servidor flexível não está numa das suas redes virtuais Azure.
  • O tráfego de rede de e para o seu servidor não passa por uma rede privada. O tráfego usa as vias gerais da internet.

Regras da firewall

Se uma tentativa de ligação vier de um endereço IP que não permitiu através de uma regra de firewall, o cliente originário terá um erro.

Permitindo todos os endereços IP do Azure

Se um endereço IP de saída fixo não estiver disponível para o seu serviço Azure, pode considerar ativar ligações de todos os endereços IP para centros de dados Azure.

Importante

O Permitir o acesso público a partir de serviços e recursos Azure dentro da opção Azure configura a firewall para permitir todas as ligações a partir do Azure, incluindo ligações a partir das subscrições de outros clientes. Ao selecionar esta opção, certifique-se de que as permissões de início de s.a. e do utilizador limitam o acesso a apenas utilizadores autorizados.

Resolução de problemas de acesso público

Considere os seguintes pontos quando o acesso ao serviço Base de Dados do Azure para PostgreSQL não se comporta como espera:

  • As alterações à lista de admissões ainda não produziram efeitos. Pode haver um atraso de cinco minutos para que as alterações na configuração de firewall do servidor Base de Dados do Azure para PostgreSQL entrem em vigor.

  • A autenticação falhou. Se um utilizador não tiver permissões no servidor Base de Dados do Azure para PostgreSQL ou a palavra-passe estiver incorreta, a ligação ao servidor Base de Dados do Azure para PostgreSQL é negada. A criação de uma definição de firewall apenas proporciona aos clientes a oportunidade de tentarem ligar-se ao seu servidor. Cada cliente deve ainda fornecer as credenciais de segurança necessárias.

  • O endereço IP dinâmico do cliente está a impedir o acesso. Se tiver uma ligação à Internet com endereço IP dinâmico e estiver com dificuldades em passar pela firewall, experimente uma das seguintes soluções:

    • Peça ao seu fornecedor de serviços de internet (ISP) o intervalo de endereços IP atribuído aos computadores do seu cliente que acedam ao servidor Base de Dados do Azure para PostgreSQL. Em seguida, adicione o intervalo de endereço IP como regra de firewall.
    • Obtenha o endereço IP estático em vez dos computadores clientes e, em seguida, adicione o endereço IP estático como regra de firewall.
  • A regra de firewall não está disponível para o formato IPv6. As regras da firewall têm de estar no formato IPv4. Se especificar as regras de firewall no formato IPv6, obterá um erro de validação.

Nome do anfitrião

Independentemente da opção de networking que escolher, recomendamos que utilize sempre um FQDN como nome de anfitrião quando se ligar ao seu servidor flexível. O endereço IP do servidor não é garantido permanecer estático. A utilização do FQDN irá ajudá-lo a evitar alterações na sua cadeia de ligação.

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

TLS e SSL

Base de Dados do Azure para PostgreSQL - O Servidor Flexível impõe a ligação das aplicações do seu cliente ao serviço PostgreSQL utilizando a Segurança da Camada de Transporte (TLS). O TLS é um protocolo padrão da indústria que garante ligações de rede encriptadas entre o servidor da base de dados e as aplicações do cliente. TLS é um protocolo atualizado da Camada de Tomadas Seguras (SSL).

Base de Dados do Azure para PostgreSQL suporta o TLS 1.2 e mais tarde. No RFC 8996, a Task Force de Engenharia da Internet (IETF) declara explicitamente que os TLS 1.0 e TLS 1.1 não devem ser utilizados. Ambos os protocolos foram depreotados até ao final de 2019.

Todas as ligações recebidas que utilizem versões anteriores do protocolo TLS, como TLS 1.0 e TLS 1.1, serão negadas por predefinição.

Nota

Os certificados SSL e TLS certificam que a sua ligação está assegurada com protocolos de encriptação de última geração. Ao encriptar a sua ligação no fio, impede o acesso não autorizado aos seus dados durante o transporte. É por isso que recomendamos vivamente a utilização de versões mais recentes do TLS para encriptar as suas ligações para Base de Dados do Azure para PostgreSQL - Servidor Flexível. Embora não seja recomendado, se necessário, tem a opção de desativar o TLS\SSL para ligações a Base de Dados do Azure para PostgreSQL - Servidor Flexível, atualizando o require_secure_transport parâmetro do servidor para OFF. Também pode definir a versão TLS definindo ssl_min_protocol_version e ssl_max_protocol_version parâmetros do servidor.

Passos seguintes

  • Saiba como criar um servidor flexível utilizando a opção de acesso privado (integração VNet) no portal do Azure ou no Azure CLI.
  • Saiba como criar um servidor flexível utilizando a opção de acesso público (endereços IP permitidos) no portal do Azure ou no Azure CLI.