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

Azure Private Link

Azure DNS

Azure Firewall

Azure Virtual WAN

Este artigo mostra como expor um recurso PaaS em um ponto de extremidade privado a 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 WAN Virtual do Azure.

Importante

Este artigo faz parte de uma série sobre o Azure Private Link e o DNS do Azure na WAN Virtual e baseia-se 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 básica 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 desta arquitetura. Esta seção define o cenário e redefine o desafio para esse cenário (o desafio é o mesmo que o exemplo que não funciona 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. Seguem-se os aditamentos 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 nome de domínio totalmente qualificado (FQDN) 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 mantenha as contas de armazenamento necessárias aos registros DNS a um hub virtual.
Você pode vincular uma zona DNS privada à rede de carga de trabalho, então você pode pensar que isso 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 analisar o DNS e os fluxos de solicitação 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

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de DNS

A consulta DNS do stgworkload00.blob.core.windows.net 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. Este pedido não é bem sucedido por várias razões:
- 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. Em última análise, a tentativa viola o nosso objetivo de permitir apenas o acesso à conta de armazenamento através do endpoint privado.

Solução - Estabeleça 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 as equipes de carga de trabalho que precisam usar zonas DNS privadas em sua arquitetura dentro dessa topologia de hub WAN virtual inicial.

A extensão DNS é implementada como uma rede virtual falada que é emparelhada para seu hub virtual regional. É possível ligar zonas DNS privadas a esta 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 falada que é emparelhada com o hub virtual da região. Este 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 privado chamado privatelink.blob.core.windows.net é criado.
- Esta zona contém um A registro que mapeia do nome 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á ligada à rede virtual falada.
- Se o controle de acesso baseado em função (RBAC) permitir, você poderá usar o registro automático ou entradas gerenciadas por serviço para manter esses registros DNS. Se não, 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 DNS Private Resolver.

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

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

Transfira um ficheiro do Visio desta arquitetura.

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

A consulta DNS do stgworkload00.blob.core.windows.net 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 o 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 DNS Private Resolver.

Captura de ecrã da política da Firewall do Azure onde o Proxy DNS está ativado 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 DNS Private Resolver.

Figura 5: Configuração de DNS na política de Firewall do Azure
O DNS Private Resolver 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 da 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 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.net.
O pedido é enviado para o endereço IP privado (10.1.2.4) da conta de armazenamento. Essa solicitação é rotada com êxito, assumindo que não há restrições conflitantes nos Grupos de Segurança de Rede locais na sub-rede do cliente ou na sub-rede do 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 através 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 orientações.

Implantar a extensão DNS não é uma tarefa para a equipe de carga de trabalho. Esta tarefa é uma função de rede empresarial 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, evita tráfego entre regiões e estabelece uma extensão de hub por hub regional onde a resolução DNS de ponto de extremidade privada é esperada.

Rede virtual Spoke

Seguindo o princípio da 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 .

Azure DNS Private Resolver

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 este 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 de Firewall do Azure (consulte a figura 5).
Para maior resiliência e maior processamento de carga, você pode implantar várias instâncias do DNS Private Resolver por região, com o proxy DNS do Azure configurado com vários endereços IP para resolução por proxie.

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

Zona DNS Privado

Como o Resolvedor Privado de DNS do Azure está resolvendo DNS por meio do DNS do Azure, o DNS do Azure pode pegar quaisquer 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 PaaS gerenciem suas próprias entradas, configure o RBAC de acordo ou implemente uma solução como a da integração de Link Privado e DNS em escala.

Considerações sobre o cenário

Com uma extensão DNS de hub virtual bem gerenciada, vamos voltar para a 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: desativado 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 da 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 desta solução é limitar a exposição desta conta de armazenamento. Depois de remover o acesso público à Internet para o seu recurso 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 da WAN Virtual, o Firewall do Azure assume como padrão negar a conectividade spoke-to-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 por meio do Firewall do Azure. Para controlar o acesso dentro da 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 contendo VM de carga de trabalho

Além de quaisquer outras regras de rede que sua carga de trabalho exija, configure as seguintes regras.

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

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

Regras NSG para sub-redes que contêm pontos de extremidade privados

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

Esse cenário permite a aplicação de um grupo de segurança de rede altamente restritivo.

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

*Figura 10: Regras NSG para sub-rede de ponto final 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 rede virtual de segundo raio 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

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de DNS

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

O que é importante destacar, é que o FQDN resolve para o endereço IP privado, e não para o endereço IP público. Esta resolução significa que todos os raios recebem sempre o endereço IP privado deste serviço. Outro cenário aborda como você pode usar essa abordagem para compartilhar um serviço PaaS em várias cargas de trabalho consumidoras. 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.net.
A solicitação é enviada para o endereço IP privado da conta de armazenamento. Este pedido falha adequadamente por muitas razões:
- 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 aplicativo em vigor 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 na 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. Este 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 exigem.

Partilhar via

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