Cenário de região única - Link Privado e DNS na WAN Virtual do Azure

Link Privado do Azure

DNS do Azure

Firewall do Azure

WAN Virtual do Azure

Este artigo mostra como expor um recurso de PaaS sobre um ponto de extremidade privado para uma carga de trabalho específica em uma única região. No cenário, a topologia de rede é hub-spoke e o hub é um hub de WAN Virtual do Azure.

Importante

Este artigo faz parte de uma série sobre o Link Privado do Azure e o DNS do Azure na WAN Virtual e se baseia na topologia de rede definida no guia de cenário. Leia a página de visão geral primeiro para entender a arquitetura de rede base e os principais desafios.

Cenário

Figura 1: Cenário de região única para WAN Virtual com Link Privado e DNS do Azure - o desafio

Baixe um Arquivo Visio dessa arquitetura. Esta seção define o cenário e redefine o desafio para esse cenário (o desafio é o mesmo que o exemplo não funcional na página de visão geral). A arquitetura do cenário inicial baseia-se na topologia de rede inicial definida no guia de visão geral. A seguir estão as adições e alterações:

Há apenas uma região com um hub virtual.
Há uma conta de Armazenamento do Azure na região que tem o acesso à rede pública desabilitado. A suposição nesse cenário é que apenas uma carga de trabalho acessa a conta de armazenamento.
Inicialmente, há uma única rede virtual conectada ao hub virtual.
A rede virtual tem uma sub-rede de carga de trabalho que contém um cliente de máquina virtual (VM).
A rede virtual contém uma sub-rede de ponto de extremidade privada que contém um ponto de extremidade privado para a conta de armazenamento.

Resultado bem-sucedido

O cliente da Máquina Virtual do Azure pode se conectar à conta de Armazenamento do Azure por meio do ponto de extremidade privado da conta de armazenamento que está na mesma rede virtual, e todos os outros acessos à conta de armazenamento são bloqueados.

Impedimento

Você precisa de um registro DNS no fluxo DNS que seja capaz de resolver o FQDN (nome de domínio totalmente qualificado) da conta de armazenamento de volta para o endereço IP privado do ponto de extremidade privado. Conforme identificado na visão geral, o desafio com o cenário é duplo:

Não é possível vincular uma zona DNS privada que mantém os registros DNS necessários das contas de armazenamento a um hub virtual.
Você pode vincular uma zona DNS privada à rede de carga de trabalho, então você pode pensar que funcionaria. Infelizmente, a arquitetura de linha de base estipula que cada rede virtual conectada tenha servidores DNS configurados para apontar para usar o proxy DNS do Firewall do Azure.

Como você não pode vincular uma zona DNS privada a um hub virtual e a rede virtual está configurada para usar o proxy DNS do Firewall do Azure, os servidores DNS do Azure não têm nenhum mecanismo para resolver o (FQDN) da conta de armazenamento para o endereço IP privado do ponto de extremidade privado. O resultado é que o cliente recebe uma resposta DNS incorreta.

Fluxos DNS e HTTP

Vamos revisar os fluxos de solicitação DNS e HTTP resultantes para essa carga de trabalho. A revisão nos ajuda a visualizar o impedimento descrito anteriormente.

Figura 2: Cenário de região única para WAN Virtual com Link Privado e DNS do Azure - o desafio

Baixe um Arquivo Visio dessa arquitetura.

Fluxo DNS

A consulta DNS para stgworkload00.blob.core.windows.net do cliente é enviada para o servidor DNS configurado, que é o Firewall do Azure no hub regional emparelhado.
O Firewall do Azure faz proxy da solicitação para o DNS do Azure. Como não é possível vincular uma zona DNS privada a um hub virtual, o DNS do Azure não sabe como resolver o FQDN para o endereço IP privado do ponto de extremidade privado. Ele sabe como resolver o FQDN para o endereço IP público da conta de armazenamento, portanto, retorna o endereço IP público da conta de armazenamento.

Fluxo HTTP

Com o resultado DNS em mãos, o endereço IP público da conta de armazenamento, o cliente emite uma solicitação HTTP para stgworkload00.blob.core.windows.net.
A solicitação é enviada para o endereço IP público da conta de armazenamento. Esta solicitação falha por vários motivos:
- O NSG na sub-rede de carga de trabalho pode não permitir esse tráfego vinculado à Internet.
- O Firewall do Azure que está filtrando o tráfego de saída vinculado à Internet provavelmente não tem uma regra de aplicativo para dar suporte a esse fluxo.
- Mesmo que o NSG e o Firewall do Azure tenham permissões para esse fluxo de solicitação, a conta de armazenamento está configurada para bloquear todo o acesso à rede pública. A tentativa acaba violando nosso objetivo de permitir apenas o acesso à conta de armazenamento por meio do endpoint privado.

Solução - Estabelecer uma extensão de hub virtual para DNS

Uma solução para o desafio é que a equipe de rede corporativa implemente uma extensão de hub virtual para DNS. A única responsabilidade pela extensão de hub virtual DNS é habilitar equipes de carga de trabalho que precisam usar zonas DNS privadas em sua arquitetura dentro dessa topologia de hub de WAN virtual inicial.

A extensão DNS é implementada como uma rede virtual que é emparelhada para seu hub virtual regional. É possível vincular zonas DNS privadas a essa rede virtual. A rede virtual também contém um Resolvedor Privado de DNS do Azure que permite que serviços fora dessa rede virtual, como o Firewall do Azure, consultem e recebam valores de todas as zonas DNS privadas vinculadas. A seguir estão os componentes de uma extensão de hub virtual típica para DNS, juntamente com algumas alterações de configuração necessárias:

Uma nova rede virtual spoke que é emparelhada com o hub virtual da região. Esse spoke é configurado como qualquer outro spoke, o que significa que o servidor DNS padrão e as regras de roteamento forçam o uso do Firewall do Azure no hub regional.
Um recurso DNS Private Resolver é implantado com um ponto de extremidade de entrada na rede virtual spoke.
Um recurso de zona DNS privada chamado privatelink.blob.core.windows.net é criado.
- Essa zona contém um A registro que mapeia do nome do FQDN da conta de armazenamento para o endereço IP privado do ponto de extremidade privado da conta de armazenamento.
- A zona DNS privada está vinculada à rede virtual falada.
- Se o RBAC (controle de acesso baseado em função) permitir, você poderá usar o registro automático ou entradas gerenciadas por serviço para manter esses registros DNS. Caso contrário, você pode mantê-los manualmente.
No hub regional, o servidor DNS do Firewall do Azure é alterado para apontar para o ponto de extremidade de entrada do Resolvedor Privado de DNS.

O diagrama a seguir ilustra a arquitetura, juntamente com os fluxos DNS e HTTP.

Figura 3: Solução de trabalho para o cenário de região única para WAN Virtual com Link Privado e DNS

Baixe um Arquivo Visio dessa arquitetura.

Fluxo DNS para estabelecer uma extensão de hub virtual para DNS

A consulta DNS para stgworkload00.blob.core.windows.net do cliente é enviada para o servidor DNS configurado, que é o Firewall do Azure no hub regional emparelhado - 10.100.0.132 neste caso.

Figura 4: Configuração de servidores DNS para rede virtual de carga de trabalho
O Firewall do Azure faz proxy da solicitação para o Resolvedor Privado de DNS do Azure regional na extensão de hub - 10.200.1.4 neste caso, que é o endereço IP privado do ponto de extremidade de entrada do Resolvedor Privado de DNS.

Captura de ecrã da política do Firewall do Azure em que o Proxy DNS está habilitado e os servidores DNS estão definidos como Personalizado. A entrada aponta para o endereço IP privado do ponto de extremidade de entrada do Resolvedor Privado de DNS.

Figura 5: Configuração de DNS na política do Firewall do Azure
O Resolvedor Privado de DNS faz proxy da solicitação para o DNS do Azure. Como uma zona DNS privada está vinculada à rede virtual que contém o ponto de extremidade de entrada, o DNS do Azure pode usar registros nessas zonas DNS privadas vinculadas.

Figura 6: Links de rede virtual de zona DNS privada
O DNS do Azure consulta a zona DNS privada vinculada e resolve o FQDN de stgworkload00.blob.core.windows.net 10.1.2.4, que é o endereço IP do ponto de extremidade privado da conta de armazenamento. Essa resposta é fornecida ao DNS do Firewall do Azure, que retorna o endereço IP privado da conta de armazenamento para o cliente.

Figura 7: Zona DNS privada com o registro A para o ponto de extremidade privado da conta de armazenamento

Fluxo HTTP

Com o resultado DNS em mãos, o endereço IP privado da conta de armazenamento, o cliente emite uma solicitação HTTP para stgworkload00.blob.core.windows.neto .
A solicitação é enviada para o endereço IP privado (10.1.2.4) da conta de armazenamento. Essa solicitação é roteada com êxito, supondo que não haja restrições conflitantes nos Grupos de Segurança de Rede locais na sub-rede do cliente ou na sub-rede de ponto de extremidade privado. É importante entender que, embora o Firewall do Azure esteja protegendo o tráfego privado, a solicitação não é roteada pelo Firewall do Azure porque o ponto de extremidade privado está na mesma rede virtual que o cliente. Ou seja, nenhuma permissão do Firewall do Azure precisa ser feita para esse cenário.
Uma conexão privada com a conta de armazenamento é estabelecida por meio do serviço Private Link. A conta de armazenamento permite apenas acesso à rede privada e aceita a solicitação HTTP.

Extensão de hub virtual para considerações de DNS

Ao implementar a extensão para sua empresa, considere as seguintes diretrizes.

Implantar a extensão DNS não é uma tarefa para a equipe de carga de trabalho. Essa tarefa é uma função de rede corporativa e deve ser uma decisão de implementação tomada com esses indivíduos.
A extensão DNS e as zonas DNS privadas devem existir antes de adicionar qualquer serviço PaaS para o qual você deseja configurar registros DNS de ponto de extremidade privado.
A extensão de hub virtual é um recurso regional, evite o tráfego entre regiões e estabeleça uma extensão de hub por hub regional onde a resolução DNS de ponto de extremidade privado é esperada.

Rede virtual spoke

Seguindo o princípio de responsabilidade única, a rede virtual para a extensão DNS deve conter apenas os recursos necessários para a resolução DNS e não deve ser compartilhada com outros recursos.
A rede virtual para a extensão DNS deve seguir as mesmas diretrizes de configuração em Adicionando redes spoke.

Resolvedor Privado de DNS do Azure

Cada região deve ter uma extensão DNS de hub virtual com um Resolvedor Privado de DNS.
O Resolvedor Privado de DNS requer apenas um ponto de extremidade de entrada e nenhum ponto de extremidade de saída para esse cenário. O IP privado para o ponto de extremidade de entrada é o que está definido para o serviço DNS personalizado na política do Firewall do Azure (consulte a figura 5).
Para maior resiliência e maior manipulação de carga, você pode implantar várias instâncias do Resolvedor Privado de DNS por região, com o proxy DNS do Azure configurado com vários endereços IP para resolução por proxy.

Figura 8: Pontos de extremidade de entrada para o resolvedor privado de DNS
Siga as restrições de rede virtual para o Resolvedor Privado de DNS.
O Grupo de Segurança de Rede na sub-rede para o ponto de extremidade de entrada do Resolvedor Privado DNS só deve permitir o tráfego UDP de seu hub regional para a porta 53. Você deve bloquear todo o outro tráfego de entrada e saída.

Zona DNS privada

Como o Resolvedor Privado de DNS do Azure está resolvendo o DNS por meio do DNS do Azure, o DNS do Azure pode pegar todas as zonas DNS privadas vinculadas à rede virtual de sua sub-rede de entrada.

Vincule a zona DNS privada à extensão de hub virtual para rede virtual DNS.
Siga as orientações sobre como gerenciar zonas DNS privadas para pontos de extremidade privados.
Se você espera que os proprietários de recursos de PaaS gerenciem suas próprias entradas, configure o RBAC de acordo ou implemente uma solução como a do Link Privado e da integração DNS em escala.

Considerações sobre o cenário

Com uma extensão DNS de hub virtual bem gerenciada, vamos voltar à carga de trabalho e abordar alguns pontos adicionais para ajudar a alcançar os objetivos de resultado bem-sucedidos nesse cenário.

Conta de armazenamento

Definir acesso à rede pública: desabilitado em Conectividade de rede para garantir que a conta de armazenamento só possa ser acessada por meio de pontos de extremidade privados.
Adicione um ponto de extremidade privado a uma sub-rede de ponto de extremidade privada dedicada na rede virtual da carga de trabalho.
Envie o Diagnóstico do Azure para o Espaço de Trabalho do Log Analytics de carga de trabalho. Você pode usar os logs de acesso para ajudar a solucionar problemas de configuração.

Segurança de endpoint privado

Um requisito dessa solução é limitar a exposição dessa conta de armazenamento. Depois de remover o acesso público à Internet para seu recurso de PaaS, você deve abordar a segurança de rede privada.

Quando o Firewall do Azure está protegendo o tráfego privado em uma topologia de hub spoke de WAN Virtual, o Firewall do Azure tem como padrão negar a conectividade de fala para spoke. Essa configuração padrão impede que cargas de trabalho em outras redes spoke acessem pontos de extremidade privados (e outros recursos) na rede virtual de carga de trabalho. O tráfego totalmente dentro de uma rede virtual não é roteado pelo Firewall do Azure. Para controlar o acesso na rede virtual e adicionar proteção mais granular, considere as seguintes recomendações do NSG (grupo de segurança de rede).

Crie um grupo de segurança de aplicativo (ASG) para agrupar recursos que tenham necessidades de acesso de entrada ou saída semelhantes. Nesse cenário, use um ASG para as VMs cliente que precisam acessar o armazenamento e um para contas de armazenamento que são acessadas. Consulte Configurar um grupo de segurança de aplicativo (ASG) com um ponto de extremidade privado.
Verifique se a sub-rede que contém a VM de carga de trabalho tem um NSG.
Verifique se a sub-rede que contém os pontos de extremidade privados tem um NSG.

Regras NSG para sub-rede que contém VM de carga de trabalho

Além de quaisquer outras regras de rede que sua carga de trabalho exige, configure as regras a seguir.

Regras de saída:
- Permitir que a ASG de computação acesse a conta de armazenamento ASG.
- Permitir computação ASG para o hub regional Azure Firewall IP privado para UDP na porta 53.

*Figura 9: Regras NSG para sub-rede de carga de trabalho

Regras NSG para sub-rede que contém pontos de extremidade privados

É considerada prática recomendada expor pontos de extremidade privados em uma pequena sub-rede dedicada dentro da rede virtual de consumo. Um motivo é que você pode aplicar rotas definidas pelo usuário e diretivas de rede do Grupo de Segurança de Rede para pontos de extremidade privados para maior controle de tráfego e segurança.

Esse cenário permite que um grupo de segurança de rede altamente restritivo seja aplicado.

Regras de entrada:
- Permitir que a ASG de computação acesse a conta de armazenamento ASG
- Negar todo o outro tráfego
Regras de saída:
- Negar todo o tráfego

*Figura 10: Regras NSG para sub-rede de ponto de extremidade privado

Segurança de endpoint privado em ação

A imagem a seguir ilustra como seguir as considerações descritas pode fornecer segurança de defesa profunda. O diagrama mostra uma segunda rede virtual spoke com uma segunda VM. Essa carga de trabalho não é capaz de acessar o ponto de extremidade privado.

Figura 11: Solução de trabalho para cenário de região única para WAN Virtual com Link Privado e DNS

Baixe um Arquivo Visio dessa arquitetura.

Fluxo DNS

O fluxo DNS é exatamente o mesmo que no fluxo de solução.

O que é importante destacar, é que o FQDN resolve para o endereço IP privado, e não o endereço IP público. Esta resolução significa que todos os raios sempre recebem o endereço IP privado deste serviço. Outro cenário aborda como você pode usar essa abordagem para compartilhar um serviço de PaaS em várias cargas de trabalho de consumo. Para esse cenário de carga de trabalho única, isso não é uma preocupação.

Fluxo HTTP

Com o resultado DNS em mãos, o endereço IP privado da conta de armazenamento, o cliente emite uma solicitação HTTP para stgworkload00.blob.core.windows.neto .
A solicitação é enviada para o endereço IP privado da conta de armazenamento. Esta solicitação falha apropriadamente por vários motivos:
- O Firewall do Azure está configurado para proteger o tráfego privado, portanto, ele lida com a solicitação. A menos que o Firewall do Azure tenha uma regra de rede ou de aplicativo para permitir o fluxo, o Firewall do Azure bloqueia a solicitação.
- Você não precisa usar o Firewall do Azure no hub para proteger o tráfego privado. Por exemplo, se sua rede oferecer suporte a tráfego privado entre regiões, o NSG na sub-rede de ponto de extremidade privado ainda estará configurado para bloquear todo o tráfego que não seja as fontes ASG de computação dentro da rede virtual que hospeda a carga de trabalho.

Resumo

Este artigo apresenta um cenário no qual um cliente VM se conecta à conta de Armazenamento do Azure por meio do ponto de extremidade privado da conta de armazenamento. O ponto de extremidade está na mesma rede virtual que o cliente. Todos os outros acessos à conta de armazenamento são bloqueados. Esse cenário requer um registro DNS no fluxo DNS que seja capaz de resolver o FQDN (nome de domínio totalmente qualificado) da conta de armazenamento de volta para o endereço IP privado do ponto de extremidade privado.

A topologia de rede inicial para este cenário apresenta dois desafios:

Não é possível vincular uma zona DNS privada com os registros DNS necessários para a conta de armazenamento ao hub virtual.
Vincular uma zona DNS privada à sub-rede de carga de trabalho não funciona. A topologia de rede inicial requer que o servidor DNS padrão e as regras de roteamento forcem o uso do Firewall do Azure no hub regional.

A solução proposta é que a equipe de rede corporativa implemente uma extensão de hub virtual para DNS. Essa extensão permite que a equipe de rede corporativa exponha serviços DNS compartilhados a raios de carga de trabalho que os exijam.

Share via

Cenário de região única - Link Privado e DNS na WAN Virtual do Azure