Migrar o Gateway de Aplicativo do Azure e o Firewall de Aplicativo Web do v1 para v2

Anunciamos a substituição do SKU do Gateway de Aplicativo V1 (Standard e WAF) em 28 de abril de 2023. O SKU V1 será desativado em 28 de abril de 2026. Para obter mais informações, consulte Migrar seus Gateways de Aplicativo da SKU V1 para a SKU V2 até 28 de abril de 2026.

O Gateway de Aplicativo do Azure e o Firewall do Aplicativo Web (WAF) V2 já oferecem recursos adicionais, como dimensionamento automático, disponibilidade, redundância de zona, maior desempenho, operações mais rápidas e taxa de transferência aprimorada em comparação com v1. Além disso, todos os novos recursos são lançados para o SKU V2. É altamente recomendável que você crie um plano de migração agora.

Os gateways V1 não são atualizados automaticamente para a V2. Use este guia de migração para ajudá-lo a planejar e realizar as migrações.

Há duas fases em uma migração:

1. Migrar a configuração
2. Migrar o tráfego de cliente

Este artigo ajuda principalmente com a migração de configuração. A migração de tráfego do cliente varia dependendo do ambiente. Algumas recomendações gerais são fornecidas neste artigo.

Pré-requisitos

• Uma conta do Azure com uma assinatura ativa. Crie uma conta gratuitamente.
• Um Gateway de Aplicativo V1 Standard existente.
• Verifique se você tem os módulos mais recentes do PowerShell ou se pode usar o Azure Cloud Shell no portal.
• Se você estiver executando o PowerShell localmente, também precisará executar o Connect-AzAccount para criar uma conexão com o Azure.
• Verifique se não há nenhum Gateway de aplicativo existente com o nome do AppGW V2 e o nome do Grupo de recursos fornecidos na assinatura V1. Isso regravará os recursos existentes.
• Se um endereço IP público for fornecido, verifique se ele está em um estado bem-sucedido. Se não for fornecido e AppGWResourceGroupName for fornecido, certifique-se de que o recurso IP público com o nome AppGWV2Name-IP não exista em um grupo de recursos com o nome AppGWResourceGroupName na assinatura V1.
• Verifique se nenhuma outra operação está planejada no gateway V1 ou nos recursos associados durante a migração.

Azure Cloud Shell

O Azure hospeda o Azure Cloud Shell, um ambiente de shell interativo que pode ser usado por meio do navegador. É possível usar o bash ou o PowerShell com o Cloud Shell para trabalhar com os serviços do Azure. É possível usar os comandos pré-instalados do Cloud Shell para executar o código neste artigo, sem precisar instalar nada no seu ambiente local.

Para iniciar o Azure Cloud Shell:

Opção	Exemplo/Link
Selecione Experimentar no canto superior direito de um bloco de código ou de comando. Selecionar Experimentar não copia automaticamente o código nem o comando para o Cloud Shell.
Acesse https://shell.azure.com ou selecione o botão Iniciar o Cloud Shell para abri-lo no navegador.
Selecione o botão Cloud Shell na barra de menus no canto superior direito do portal do Azure.

Para usar o Azure Cloud Shell:

1. Inicie o Cloud Shell.

2. Selecione o botão Copiar em um bloco de código (ou bloco de comando) para copiar o código ou o comando.

3. Cole o código ou comando na sessão do Cloud Shell selecionando Ctrl+Shift+V no Windows e no Linux, ou selecionando Cmd+Shift+V no macOS.

4. Pressione Enter para executar o código ou o comando.

Migração da configuração

Um script do Azure PowerShell é fornecido neste documento. Ele executa as seguintes operações para ajudá-lo com a configuração:

• Cria um novo gateway Standard_v2 ou WAF_v2 em uma sub-rede de rede virtual que você especificar.
• Copia diretamente a configuração associada ao gateway V1 Standard ou WAF no gateway Standard_V2 ou WAF_V2 recém-criado.

Baixando o script

Você pode baixar o script de migração da Galeria do PowerShell. Uma nova versão estável (versão 1.0.11) do script de migração está disponível, que inclui atualizações principais e correções de bugs. É recomendável usar essa versão estável.

Usando o script

Há duas opções para você dependendo da configuração e das preferências do ambiente do PowerShell local:

• Se você não tiver os módulos Az do Azure instalados ou não desinstalar os módulos Az do Azure, a melhor opção é usar a opção Install-Script para executar o script.
• Se precisar manter os módulos Az do Azure, o melhor a fazer é baixar o script e executá-lo diretamente.

Para determinar se você tem os módulos Az do Azure instalados, execute Get-InstalledModule -Name az. Se você não encontrar nenhum módulo Az instalado, poderá usar o método Install-Script.

Instalar usando o método Install-Script (recomendado)

Para usar essa opção, você não deve ter os módulos Az do Azure instalados no computador. Se estiverem instalados, o comando a seguir exibirá um erro. Você pode desinstalar os módulos Az do Azure ou usar a outra opção para baixar o script manualmente e executá-lo.

Execute o script com o seguinte comando para obter a versão mais recente:

Install-Script -Name AzureAppGWMigration -Force

Esse comando também instala os módulos Az necessários.

Instalar usando o script diretamente

Se você tiver alguns módulos do Az do Azure instalados e não puder desinstalá-los (ou não quiser desinstalá-los), poderá baixar manualmente o script usando a guia Download Manual no link de download do script. O script será baixado como um arquivo nupkg bruto. Para instalar o script a partir do arquivo nupkg, confira Download manual do pacote.

A versão 1.0.11 é a nova versão do script de migração que inclui as principais correções de bug. É recomendável usar essa versão estável.

Como verificar a versão do script baixado

Para verificar a versão do script baixado, as etapas são as seguintes:

• Extrair o conteúdo do pacote do NuGet.
• Abra o arquivo .PS1 na pasta e verifique o .VERSION na parte superior para confirmar a versão do script baixado

<#PSScriptInfo
.VERSION 1.0.10
.GUID be3b84b4-e9c5-46fb-a050-699c68e16119
.AUTHOR Microsoft Corporation
.COMPANYNAME Microsoft Corporation
.COPYRIGHT Microsoft Corporation. All rights reserved.

• Use a versão estável mais recente da Galeria do PowerShell

Como executar o script

Para executar o script:

1. Use Connect-AzAccount para se conectar ao Azure.

2. Use Import-Module Az para importar os módulos Az.

3. Execute o cmdlet Set-AzContext para definir o contexto ativo do Azure como a assinatura correta. Essa é uma etapa importante porque o script de migração pode limpar o grupo de recursos existente se ele não existir no contexto de assinatura atual.

   Set-AzContext -Subscription '<V1 application gateway SubscriptionId>'
   

4. Execute Get-Help AzureAppGWMigration.ps1 para examinar os parâmetros necessários:

   AzureAppGWMigration.ps1
    -resourceId <V1 application gateway Resource ID>
    -subnetAddressRange <subnet space you want to use>
    -appgwName <string to use to append>
    -AppGWResourceGroupName <resource group name you want to use>
    -sslCertificates <comma-separated SSLCert objects as above>
    -trustedRootCertificates <comma-separated Trusted Root Cert objects as above>
    -privateIpAddress <private IP string>
    -publicIpResourceId <public IP name string>
    -validateMigration -enableAutoScale
   

Parâmetros para o script:

• resourceId: [String]: Obrigatório: esse parâmetro é a ID de Recurso do Azure do seu gateway V1 ou WAF V1 padrão existente. Para localizar esse valor de cadeia de caracteres, navegue até o portal do Azure, selecione o recurso de gateway de aplicativo ou WAF e clique no link Propriedades para o gateway. A ID do Recurso está localizada nessa página.

  Você também pode executar os seguintes comandos do Azure PowerShell para obter a ID do Recurso:

  $appgw = Get-AzApplicationGateway -Name <V1 gateway name> -ResourceGroupName <resource group Name>
  $appgw.Id
  

• subnetAddressRange: [String]: Obrigatório: esse parâmetro é o espaço de endereço de IP que você alocou (ou quer alocar) em uma nova sub-rede que contém o seu novo gateway V2. O espaço de endereço deve ser especificado na notação CIDR. Por exemplo: 10.0.0.0/24. Você não precisa criar essa sub-rede com antecedência, mas o CIDR precisa fazer parte do espaço de endereço da VNET. O script o cria para você se ele não existir e, se existir, ele usa o existente (certifique-se de que a sub-rede esteja vazia, contenha apenas o gateway V2, se houver, e tenha IPs disponíveis suficientes).

• appgwName: [String]: Optional. Essa é uma cadeia de caracteres que você especifica para usar como o nome do novo gateway de Standard_V2 ou WAF_V2. Se esse parâmetro não for fornecido, o nome do gateway V1 existente será usado com o sufixo _V2 acrescentado.

• AppGwResourceGroupName: [Cadeia de caracteres]: Opcional. Nome do grupo de recursos em que você quer que os recursos do Gateway de Aplicativo V2 sejam criados (o valor padrão será <V1-app-gw-rgname>)

• sslCertificates: [PSApplicationGatewaySslCertificate]: Optional. Uma lista separada por vírgulas de objetos PSApplicationGatewaySslCertificate que você criou para representar os certificados TLS/SSL do seu gateway V1 deve ser carregada no novo gateway V2. Para cada um dos seus certificados TLS/SSL configurados para seu gateway Standard V1 ou WAF V1, você pode criar um novo objeto PSApplicationGatewaySslCertificate pelo comando New-AzApplicationGatewaySslCertificate mostrado aqui. Você precisa do caminho e da senha para o arquivo de certificado TLS/SSL.

  Esse parâmetro só será opcional se você não tiver ouvintes HTTPS configurados no seu gateway V1 ou WAF. Se tiver pelo menos uma configuração de ouvinte HTTPS, deverá especificar esse parâmetro.

  $password = ConvertTo-SecureString <cert-password> -AsPlainText -Force
  $mySslCert1 = New-AzApplicationGatewaySslCertificate -Name "Cert01" `
    -CertificateFile <Cert-File-Path-1> `
    -Password $password
  $mySslCert2 = New-AzApplicationGatewaySslCertificate -Name "Cert02" `
    -CertificateFile <Cert-File-Path-2> `
    -Password $password
  

  Você pode passar $mySslCert1, $mySslCert2 (separado por vírgula) no exemplo anterior como valores para esse parâmetro no script.

• sslCertificates de Keyvault: opcional. Você pode baixar os certificados armazenados no Azure Key Vault e passá-los para o script de migração. Para baixar o certificado como um arquivo PFX, execute o comando a seguir. Esses comandos acessam a SecretId e salvam o conteúdo como um arquivo PFX.

   $vaultName = ConvertTo-SecureString <kv-name> -AsPlainText -Force
   $certificateName = ConvertTo-SecureString <cert-name> -AsPlainText -Force
   $password = ConvertTo-SecureString <password> -AsPlainText -Force
  
   $pfxSecret = Get-AzKeyVaultSecret -VaultName $vaultName -Name $certificateName -AsPlainText
   $secretByte = [Convert]::FromBase64String($pfxSecret)
   $x509Cert = New-Object Security.Cryptography.X509Certificates.X509Certificate2
   $x509Cert.Import($secretByte, $null, [Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable)
   $pfxFileByte = $x509Cert.Export([Security.Cryptography.X509Certificates.X509ContentType]::Pkcs12, $password)
  
   # Write to a file
   [IO.File]::WriteAllBytes("KeyVaultcertificate.pfx", $pfxFileByte)
  

  Para cada certificado baixado do Keyvault, você pode criar um novo objeto PSApplicationGatewaySslCertificate pelo comando New-AzApplicationGatewaySslCertificate mostrado aqui. Você precisa do caminho e da senha para o arquivo de certificado TLS/SSL.

  //Convert the downloaded certificate to SSL object
  $password = ConvertTo-SecureString  <password> -AsPlainText -Force 
  $cert = New-AzApplicationGatewaySSLCertificate -Name <certname> -CertificateFile <Cert-File-Path-1> -Password $password 
  

• trustedRootCertificates: [PSApplicationGatewayTrustedRootCertificate]: Optional. Uma lista separada por vírgulas de objetos PSApplicationGatewayTrustedRootCertificate criada para representar os certificados Raiz Confiáveis para autenticação das instâncias de back-end do gateway v2.

  $certFilePath = ".\rootCA.cer"
  $trustedCert = New-AzApplicationGatewayTrustedRootCertificate -Name "trustedCert1" -CertificateFile $certFilePath
  

  Para criar uma lista de objetos PSApplicationGatewayTrustedRootCertificate, confira New-AzApplicationGatewayTrustedRootCertificate.

• privateIpAddress: [String]: Optional. Um endereço de IP privado específico que você quer associar ao seu novo gateway v2. Isso deve ser da mesma VNet que você aloca no seu novo gateway V2. Se isso não for especificado, o script alocará um endereço de IP privado no seu gateway V2.

• publicIpResourceId: [String]: Optional. O resourceId do recurso de endereço IP público (SKU padrão) existente na assinatura que você deseja alocar para o novo gateway V2. Se o nome do recurso de IP público for fornecido, verifique se ele existe no estado bem-sucedido. Se não for especificado, o script alocará um novo IP público no mesmo grupo de recursos. O nome é o nome do gateway V2 com -IP acrescentado. Se AppGWResourceGroupName for fornecido e um endereço IP público não for fornecido, verifique se o recurso IP público com o nome AppGWV2Name-IP não existe em um grupo de recursos com o nome AppGWResourceGroupName na assinatura V1.

• validateMigration: [switch]: Optional. Use esse parâmetro para habilitar o script para fazer algumas validações básicas de comparação de configuração após a criação do gateway V2 e a cópia de configuração. Por padrão, nenhuma validação é feita.

• enableAutoScale: [switch]: Optional. Use esse parâmetro para habilitar o script para habilitar o dimensionamento automático no novo gateway V2 depois que ele for criado. Por padrão, o dimensionamento automático está desabilitado. Você pode habilitá-lo manualmente mais tarde no gateway v2 recém-criado.

5. Execute o script usando os parâmetros apropriados. Isso pode levar de cinco a sete minutos para ser concluído.

   Exemplo

   AzureAppGWMigration.ps1 `
      -resourceId /subscriptions/8b1d0fea-8d57-4975-adfb-308f1f4d12aa/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv1appgateway `
      -subnetAddressRange 10.0.0.0/24 `
      -appgwname "MynewV2gw" `
      -AppGWResourceGroupName "MyResourceGroup" `
      -sslCertificates $mySslCert1,$mySslCert2 `
      -trustedRootCertificates $trustedCert `
      -privateIpAddress "10.0.0.1" `
      -publicIpResourceId "/subscriptions/8b1d0fea-8d57-4975-adfb-308f1f4d12aa/resourceGroups/MyResourceGroup/providers/Microsoft.Network/publicIPAddresses/MyPublicIP" `
      -validateMigration -enableAutoScale
   

Caveats\Limitations

• O novo gateway v2 tem novos endereços de IP públicos e privados. Não é possível mover os endereços de IP associados ao gateway v1 existente diretamente para o v2. Porém, você pode alocar um endereço de IP público ou privado existente (não alocado) no novo gateway V2.
• Você deve fornecer um espaço de endereço de IP para outra sub-rede na sua rede virtual em que seu gateway V1 está localizado. O script não pode criar o gateway V2 em uma sub-rede que já tenha um gateway V1. Se a sub-rede já tiver um gateway V2, o script ainda poderá funcionar, desde que haja espaço suficiente no endereço de IP disponível.
• Se você tiver um grupo de segurança de rede ou rotas definidas pelo usuário associadas à sub-rede de gateway V2, verifique se eles aderem aos Requisitos de NSG e Requisitos de UDR para uma migração bem-sucedida
• As políticas de ponto de extremidade de serviço de rede virtual atualmente não têm suporte em uma sub-rede do Gateway de Aplicativo.
• Para migrar uma configuração TLS/SSL, você deve especificar todos os certificados TLS/SSL usados no gateway V1.
• Se você tiver o modo FIPS habilitado para o gateway V1, ele não será migrado para o novo gateway V2. Não há suporte para o modo FIPS na V2.
• Se você tiver um gateway de IP Privado somente V1, o script gerará um endereço de IP público e privado no novo gateway V2. O gateway de IP Privado somente V2 está atualmente em versão prévia pública. Assim que estiver disponível para o público geral, os clientes poderão usar o script para transferir seu gateway V1 somente IP privado para um gateway V2 somente IP privado.
• A autenticação NTLM e Kerberos não tem suporte do Gateway de Aplicativo do Azure V2. O script não consegue detectar se o gateway está servindo esse tipo de tráfego e pode representar uma alteração significativa dos gateways V1 para V2, se executado.
• WAFv2 é criado no modo de configuração do WAF antigo; A migração para a política do WAF é necessária.

Migração de tráfego

Primeiro, verifique se o script criou com êxito um novo gateway V2 com a configuração exata migrada do gateway V1. Você pode fazer essa verificação no portal do Azure.

Também envie uma pequena quantidade de tráfego pelo gateway V2 como um teste manual.

Veja a seguir alguns cenários em que o gateway de aplicativo atual (Standard) pode receber tráfego do cliente e nossas recomendações para cada um:

• Uma zona DNS personalizada (por exemplo, contoso.com) que aponta para o endereço de IP de front-end (usando um registro A) associado ao gateway standard V1 ou WAF V1.

  Você pode atualizar seu registro DNS para apontar para o IP de front-end ou rótulo DNS associado ao seu gateway de aplicativo Standard_V2. Dependendo da TTL configurada no seu registro DNS, pode levar algum tempo para que todo o tráfego do cliente migre para o seu novo gateway V2.

• Uma zona DNS personalizada (por exemplo, contoso.com) que aponta para o rótulo DNS (por exemplo: myappgw.eastus.cloudapp.azure.com usando um registro CNAME) associado ao seu gateway V1.

  Você tem duas escolhas:

  • Se você usar endereços de IP públicos no seu gateway de aplicativo, poderá fazer uma migração granular controlada usando um perfil do Gerenciador de Tráfego para rotear incrementalmente o tráfego (método de roteamento de tráfego ponderado) no novo gateway V2.

    Você pode fazer isso adicionando os rótulos DNS dos gateways de aplicativo V1 e V2 no Perfil do Gerenciador de Tráfegoe ao CNAMEing do registro DNS personalizado (por exemplo, www.contoso.com) ao domínio do Gerenciador de Tráfego (por exemplo, contoso.trafficmanager.net).

  • Ou você pode atualizar seu registro DNS de domínio personalizado para apontar para o rótulo DNS do novo gateway de aplicativo V2. Dependendo da TTL configurada no seu registro DNS, pode levar algum tempo para que todo o tráfego do cliente migre para o seu novo gateway V2.

• Os clientes se conectam ao endereço IP de front-end do gateway de aplicativo.

  Atualize seus clientes para usar os endereços de IP associados ao gateway de aplicativo V2 recém-criado. Recomendamos que você não use endereços IP diretamente. Considere usar o rótulo de nome DNS (por exemplo, yourgateway.eastus.cloudapp.azure.com) associado ao gateway de aplicativo, que você pode fazer o registro CNAME para a própria zona DNS personalizada (por exemplo, contoso.com).

Considerações de preço

Os modelos de preços são diferentes nos SKUs do Gateway de Aplicativo V1 e V2. A V2 é cobrada com base no consumo. Consulte Preços do Gateway de Aplicativo antes de migrar para obter informações sobre preços.

Diretrizes de eficiência de custo

O SKU V2 vem com uma variedade de vantagens, como um aumento de desempenho de 5x, segurança aprimorada com a integração do Key Vault, atualizações mais rápidas de regras de segurança em WAF_V2, regras personalizadas do WAF, associações de política e proteção contra Bots. Ele também oferece alta escalabilidade, roteamento de tráfego otimizado e integração perfeita com os serviços do Azure. Esses recursos podem melhorar a experiência geral do usuário, evitar lentidão durante tempos de tráfego pesado e evitar violações de dados caras.

Há cinco variantes disponíveis no SKU V1 com base na camada e tamanho - Standard_Small, Standard_Medium, Standard_Large, WAF_Medium e WAF_Large.

Para mais dúvidas sobre preços, trabalhe com seu CSAM ou entre em contato com nossa equipe de suporte para obter assistência.

Perguntas comuns

Perguntas comuns sobre migração podem ser encontradas aqui

Próximas etapas

Saiba mais sobre o gateway de aplicativo V2