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

Importante

Este artigo é sobre o Ambiente do Serviço de Aplicativo v1. O Ambiente do Serviço de Aplicativo v1 e v2 foi desativado a partir de 31 de agosto de 2024. Há uma nova versão do Ambiente do Serviço de Aplicativo que é mais fácil de usar e é executada em uma infraestrutura mais poderosa. Para saber mais sobre a nova versão, comece com a 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.

A partir de 31 de agosto de 2024, o Contrato de Nível de Serviço (SLA) e os Créditos de Serviço não se aplicam mais às cargas de trabalho do Ambiente do Serviço de Aplicativo v1 e v2 que continuam em produção, pois são produtos desativados. A desativação do hardware do Ambiente do Serviço de Aplicativo v1 e v2 começou, e isso pode afetar a disponibilidade e o desempenho de seus aplicativos e dados.

Você deve concluir a migração para o Ambiente do Serviço de Aplicativo v3 imediatamente ou seus aplicativos e recursos podem ser excluídos. Tentaremos migrar automaticamente qualquer Ambiente do Serviço de Aplicativo restante v1 e v2 com base no melhor esforço usando o recurso de migração in-loco, mas a Microsoft não faz nenhuma reivindicação ou garantia sobre a disponibilidade do aplicativo após a migração automática. Talvez seja necessário executar 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, seus recursos e dados de aplicativos associados serão excluídos. Exortamo-lo vivamente a agir agora para evitar qualquer um destes cenários extremos.

Se você precisar de tempo adicional, podemos oferecer um período de carência único de 30 dias para que você conclua sua migração. Para obter mais informações e solicitar esse período de carência, revise a visão geral do período de carência e vá para o portal do Azure e visite a folha Migração para cada um dos seus 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 tempo de execução 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 back-ends de API do acesso geral à Internet e permitir que as APIs sejam chamadas apenas por aplicativos Web upstream. Os NSGs (grupos de segurança de rede) podem ser usados em sub-redes que contêm Ambientes do Serviço de Aplicativo para restringir o acesso público a aplicativos de API.

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

Os sinais de adição verdes indicam que o grupo de segurança de rede na sub-rede que contém "apiase" permite chamadas de entrada dos 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 descreve as etapas necessárias para configurar o grupo de segurança de rede na sub-rede que contém "apiase".

Determinando o comportamento da 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 estão bloqueados.

Como os NSGs (grupos de segurança de rede) são aplicados a 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 executados em um Ambiente do Serviço de Aplicativo. Usando a arquitetura de exemplo para este artigo, assim que um grupo de segurança de rede for aplicado à sub-rede que contém "apiase", todos os aplicativos executados no Ambiente do Serviço de Aplicativo "apiase" serão protegidos pelo mesmo conjunto de regras de segurança.

• Determine o endereço IP de saída dos chamadores upstream: Qual é o endereço IP ou endereços dos chamadores upstream? Esses endereços precisam ter acesso explícito no NSG. Como as chamadas entre Ambientes do Serviço de Aplicativo são consideradas chamadas "Internet", o endereço IP de saída atribuído a cada um dos três Ambientes do Serviço de Aplicativo upstream precisa ter acesso permitido 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, consulte o artigo Visão geral da arquitetura de rede.
• O aplicativo de API back-end precisará se chamar? Um ponto às vezes negligenciado e sutil é o cenário em que o aplicativo back-end precisa se chamar. Se um aplicativo de API back-end em um Ambiente do Serviço de Aplicativo precisar chamar a si mesmo, ele também será tratado como uma chamada "Internet". Na arquitetura de exemplo, isso requer permitir o acesso a partir do endereço IP de saída do Ambiente do Serviço de Aplicativo "apiase" também.

Configurando o Grupo de Segurança de Rede

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

Para a arquitetura de exemplo, os ambientes estão localizados no Centro-Sul dos EUA, portanto, 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, conforme observado no artigo sobre tráfego de entrada para 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 são 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

Enxaguar e repetir para o segundo e terceiro ambientes upstream do Serviço de Aplicativo ("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 para 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, porque cada NSG tem um conjunto de regras padrão que bloqueiam o acesso de entrada da Internet, por padrão.

A lista completa de 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 chamadores, exceto os chamadores aos quais o acesso é explicitamente concedido.

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, apenas os três Ambientes do Serviço de Aplicativo upstream e o Ambiente do Serviço de Aplicativo que contém o back-end da API têm permissão para chamar o ambiente "apiase".

Links e Informações Extras

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.

Nota

Se pretender começar a utilizar o App Service do Azure antes de se inscrever numa conta do Azure, aceda a Experimentar o App Service, onde pode criar de imediato uma aplicação Web de arranque de curta duração no App Service. Sem cartões de crédito; sem compromissos.