Compartilhar via

Implementando uma arquitetura de segurança em camadas com Ambientes do Serviço de Aplicativo

  • Artigo

Importante

Este artigo é sobre o Ambiente do Serviço de Aplicativo v1. O Ambiente do Serviço de Aplicativo v1 e v2 foi desativado em 31 de agosto de 2024. Há uma nova versão do Ambiente de Serviço de Aplicativo que é mais fácil de usar e é executado na infraestrutura mais avançada. Para saber mais sobre a nova versão, comece com Introdução ao Ambiente do Serviço de Aplicativo. Se você estiver usando o Ambiente do Serviço de Aplicativo v1, siga as etapas neste artigo para migrar para a nova versão.

Desde 31 de agosto de 2024, o SLA (Contrato de Nível de Serviço) e os Créditos de Serviço deixaram de se aplicar às cargas de trabalho do Ambiente do Serviço de Aplicativo v1 e v2 que continuam em produção, já que são produtos desativados. A desativação do hardware do Ambiente do Serviço de Aplicativo v1 e v2 foi iniciada, o que poderá afetar a disponibilidade e o desempenho de aplicativos e dados.

Você precisa executar a migração para o Ambiente do Serviço de Aplicativo v3 imediatamente. Caso contrário, aplicativos e recursos poderão ser excluídos. Tentaremos migrar automaticamente qualquer Ambiente do Serviço de Aplicativo v1 e v2 restantes com base no melhor esforço usando o recurso de migração in-loco. No enanto, a Microsoft não afirma ou garante a disponibilidade do aplicativo após a migração automática. Talvez seja necessário realizar a configuração manual para concluir a migração e otimizar a escolha de SKU do Plano do Serviço de Aplicativo para atender às suas necessidades. Se a migração automática não for viável, os recursos e dados de aplicativos associados serão excluídos. Recomendamos fortemente que você tome uma atitude agora para evitar esses cenários extremos.

Se você precisar de mais tempo, podemos oferecer um período de carência único de 30 dias para a realização da migração. Para saber mais e solicitar o período de carência, confira a visão geral do período de carência, acesse o portal do Azure e visite a lâmina Migração para cada um dos Ambientes do Serviço de Aplicativo.

Para obter as informações mais atualizadas sobre a desativação do Ambiente do Serviço de Aplicativo v1/v2, consulte a Atualização de desativação do Ambiente do Serviço de Aplicativo v1 e v2.

Como os Ambientes do Serviço de Aplicativo fornecem um ambiente de runtime isolado implantado em uma rede virtual, os desenvolvedores podem criar uma arquitetura de segurança em camadas fornecendo diferentes níveis de acesso à rede para cada camada de aplicativo físico.

Um desejo comum é ocultar os back-ends de API do acesso à Internet geral e só permitir que as APIs sejam chamadas por aplicativos Web upstream. Os NSGs (grupos de segurança de rede) podem ser usados em sub-redes contendo Ambientes do Serviço de Aplicativo para restringir o acesso público aos aplicativos da API.

O diagrama abaixo mostra uma arquitetura de exemplo com um aplicativo baseado em API Web implantado em um Ambiente do Serviço de Aplicativo. Três instâncias de aplicativos Web separados, implantadas em três Ambientes do Serviço de Aplicativo separados, fazem chamadas de back-end para o mesmo aplicativo da API Web.

Arquitetura conceitual

O sinal de adição verde indica que o grupo de segurança de rede na sub-rede contendo “apiase” permite chamadas recebidas de aplicativos Web upstream, bem como chamadas de si mesmo. No entanto, o mesmo grupo de segurança de rede nega explicitamente o acesso ao tráfego de entrada geral da Internet.

O restante deste artigo explica as etapas necessárias para configurar o grupo de segurança de rede na sub-rede contendo “apiase”.

Determinando o comportamento de rede

Para saber quais regras de segurança de rede são necessárias, você precisa determinar quais clientes de rede terão permissão para acessar o Ambiente do Serviço de Aplicativo que contém o aplicativo de API e quais clientes são bloqueados.

Como os NSGs (grupos de segurança de rede) são aplicados às sub-redes e os Ambientes do Serviço de Aplicativo são implantados em sub-redes, as regras contidas em um NSG se aplicam a todos os aplicativos em execução em um Ambiente do Serviço de Aplicativo. Usando a arquitetura de exemplo deste artigo, depois que um grupo de segurança de rede for aplicado à sub-rede contendo "apiase", todos os aplicativos em execução no Ambiente do Serviço de Aplicativo "apiase" estarão protegidos pelo mesmo conjunto de regras de segurança.

  • Determine o endereço IP de saída dos autores da chamada upstream: qual é ou quais são os endereços IP dos autores da chamada upstream? Esses endereços precisão receber explicitamente a permissão de acesso no NSG. Como as chamadas entre os Ambientes do Serviço de Aplicativo são consideradas chamadas da “Internet”, o endereço IP de saída atribuído a cada um dos três Ambientes do Serviço de Aplicativo upstream precisa receber permissão de acesso no NSG para a sub-rede “apiase”. Para obter mais informações sobre como determinar o endereço IP de saída para aplicativos executados em um Ambiente do Serviço de Aplicativo, confira o artigo de Visão geral da Arquitetura de rede.
  • O aplicativo de API de back-end precisará chamar a si mesmo? Um ponto sutil e às vezes negligenciado é o cenário em que o aplicativo de back-end precisa chamar a si mesmo. Se um aplicativo de API de back-end em um Ambiente do Serviço de Aplicativo precisar chamar a si mesmo, isso também será tratado como uma chamada da “Internet”. Na arquitetura de exemplo, isso também requer a permissão de acesso do endereço IP de saída do Ambiente do Serviço de Aplicativo “apiase”.

Configurando o Grupo de Segurança de Rede

Depois que o conjunto de endereços IP de saída forem conhecidos, a próxima etapa é criar um grupo de segurança de rede. Os grupos de segurança de rede podem ser criados para as redes virtuais baseadas no Resource Manager e redes virtuais clássicas. Os exemplos a seguir mostram a criação e a configuração de um NSG em uma rede virtual clássica usando o PowerShell.

Para a arquitetura de exemplo, como os ambientes estão localizados no Centro Sul dos EUA, um NSG vazio é criado nessa região:

New-AzureNetworkSecurityGroup -Name "RestrictBackendApi" -Location "South Central US" 
-Label "Only allow web frontend and loopback traffic"

Primeiro uma regra de permissão explícita é adicionada para a infraestrutura de gerenciamento do Azure, como observado no artigo sobre o tráfego de entrada dos Ambientes do Serviço de Aplicativo.

#Open ports for access by Azure management infrastructure
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW AzureMngmt" 
-Type Inbound -Priority 100 -Action Allow -SourceAddressPrefix 'INTERNET' -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '454-455' -Protocol TCP

Em seguida, duas regras foram adicionadas para permitir chamadas HTTP e HTTPS do primeiro Ambiente do Serviço de Aplicativo upstream (“fe1ase”).

#Grant access to requests from the first upstream web front-end
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTP fe1ase" 
-Type Inbound -Priority 200 -Action Allow -SourceAddressPrefix '65.52.xx.xyz'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '80' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTPS fe1ase" 
-Type Inbound -Priority 300 -Action Allow -SourceAddressPrefix '65.52.xx.xyz'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '443' -Protocol TCP

Repita o procedimento para o segundo e terceiro Ambientes do Serviço de Aplicativo upstream (“fe2ase” e “fe3ase”).

#Grant access to requests from the second upstream web front-end
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTP fe2ase" 
-Type Inbound -Priority 400 -Action Allow -SourceAddressPrefix '191.238.xyz.abc'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '80' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTPS fe2ase" 
-Type Inbound -Priority 500 -Action Allow -SourceAddressPrefix '191.238.xyz.abc'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '443' -Protocol TCP

#Grant access to requests from the third upstream web front-end
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTP fe3ase" 
-Type Inbound -Priority 600 -Action Allow -SourceAddressPrefix '23.98.abc.xyz'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '80' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTPS fe3ase" 
-Type Inbound -Priority 700 -Action Allow -SourceAddressPrefix '23.98.abc.xyz'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '443' -Protocol TCP

Por fim, conceda acesso ao endereço IP de saída do Ambiente do Serviço de Aplicativo da API de back-end para que ele possa chamar de volta a si mesmo.

#Allow apps on the apiase environment to call back into itself
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTP apiase" 
-Type Inbound -Priority 800 -Action Allow -SourceAddressPrefix '70.37.xyz.abc'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '80' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTPS apiase" 
-Type Inbound -Priority 900 -Action Allow -SourceAddressPrefix '70.37.xyz.abc'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '443' -Protocol TCP

Nenhuma outra regra de segurança de rede é necessária, pois cada NSG tem um conjunto de regras padrão que bloqueia o acesso de entrada da Internet por padrão.

A lista completa das regras no grupo de segurança de rede é mostrada. Observe como a última regra, que é realçada, bloqueia o acesso de entrada de todos os autores da chamada diferentes dos chamadores, exceto os chamadores aos quais o acesso foi concedido explicitamente.

Configuração do NSG

A etapa final é aplicar o NSG à sub-rede que contém o Ambiente do Serviço de Aplicativo “apiase”.

#Apply the NSG to the backend API subnet
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityGroupToSubnet 
-VirtualNetworkName 'yourvnetnamehere' -SubnetName 'API-ASE-Subnet'

Com o NSG aplicado à sub-rede, somente três Ambientes do Serviço de Aplicativo upstream e o Ambiente do Serviço de Aplicativo contendo o back-end da API têm permissão para realizar chamadas no ambiente de “apiase”.

Informações sobre grupos de segurança de rede.

Noções básicas sobre endereços IP de saída e Ambientes do Serviço de Aplicativo.

Portas de rede usadas pelos Ambientes do Serviço de Aplicativo.

Observação

Se você deseja começar com o Serviço de Aplicativo do Azure antes de se inscrever em uma conta do Azure, acesse Experimentar o Serviço de Aplicativo, em que você pode criar imediatamente um aplicativo Web inicial de curta duração no Serviço de Aplicativo. Nenhum cartão de crédito é exigido, sem compromissos.