Come controllare il traffico in ingresso a un ambiente del servizio app

  • Articolo

Importante

Questo articolo riguarda ambiente del servizio app v1. ambiente del servizio app v1 verrà ritirato il 31 agosto 2024. È disponibile una nuova versione di ambiente del servizio app che è più facile da usare e che viene eseguita su un'infrastruttura più potente. Per altre informazioni sulla nuova versione, iniziare con l'introduzione alla ambiente del servizio app. Se si usa attualmente ambiente del servizio app v1, seguire la procedura descritta in questo articolo per eseguire la migrazione alla nuova versione.

A partire dal 29 gennaio 2024, non è più possibile creare nuove risorse ambiente del servizio app v1 usando uno dei metodi disponibili, inclusi i modelli ARM/Bicep, il portale di Azure, l'interfaccia della riga di comando di Azure o l'API REST. È necessario eseguire la migrazione a ambiente del servizio app v3 prima del 31 agosto 2024 per evitare l'eliminazione delle risorse e la perdita di dati.

Panoramica

Un ambiente del servizio app può essere creato o in una rete virtuale di Azure Resource Manager o in una rete virtuale del modello di distribuzione classica. È possibile definire una nuova rete virtuale e una nuova subnet al momento della creazione di un ambiente del servizio app. È invece possibile creare un ambiente del servizio app in una rete virtuale preesistente e in una subnet preesistente. A partire da giugno 2016, le edizione Standard possono essere distribuite anche in reti virtuali che usano intervalli di indirizzi pubblici o spazi di indirizzi RFC1918 (indirizzi privati). Per altre informazioni, vedere Come creare un oggetto A edizione Standard v1 da un modello.

Creare sempre un ambiente del servizio app all'interno di una subnet. Una subnet fornisce un limite di rete che può essere usato per bloccare il traffico in ingresso dietro dispositivi e servizi upstream. Questa configurazione consente solo a specifici indirizzi IP upstream di accettare il traffico HTTP e HTTPS.

Il traffico in ingresso e in uscita diretto verso e proveniente da una subnet è controllato tramite un gruppo di sicurezza di rete. Per controllare il traffico in ingresso, creare regole di sicurezza di rete in un gruppo di sicurezza di rete. Assegnare quindi al gruppo di sicurezza di rete la subnet contenente il ambiente del servizio app.

Dopo aver assegnato un gruppo di sicurezza di rete a una subnet, il traffico in ingresso alle app nel ambiente del servizio app è consentito o bloccato in base alle regole di autorizzazione e negazione definite nel gruppo di sicurezza di rete.

Nota

Sebbene in questo articolo si faccia riferimento alle app Web, è applicabile anche ad app per le API e app per dispositivi mobili.

Porte di rete in ingresso usate in un ambiente del servizio app

Prima di bloccare il traffico di rete in ingresso con un gruppo di sicurezza di rete, conoscere il set di porte di rete obbligatorie e facoltative usate da un ambiente del servizio app. Il blocco accidentale del traffico ad alcune porte può comportare una perdita di funzionalità nell'ambiente del servizio app.

L'elenco seguente contiene le porte usate da un ambiente del servizio app. Tutte le porte sono di tipo TCP, se non indicato diversamente in modo chiaro:

  • 454: porta necessaria usata dall'infrastruttura di Azure per la gestione e la gestione di ambiente del servizio app tramite TLS. Non bloccare il traffico verso questa porta. Questa porta è sempre associata all'indirizzo VIP pubblico di un ambiente del servizio app.
  • 455: porta necessaria usata dall'infrastruttura di Azure per la gestione e la gestione di ambiente del servizio app tramite TLS. Non bloccare il traffico verso questa porta. Questa porta è sempre associata all'indirizzo VIP pubblico di un ambiente del servizio app.
  • 80: porta predefinita per il traffico HTTP in ingresso alle app in esecuzione nei piani di servizio app in un ambiente del servizio app. In un ambiente del servizio app abilitato al bilanciamento del carico interno, questa porta è associata all'indirizzo ILB dell'ambiente.
  • 443: porta predefinita per il traffico TLS in ingresso alle app eseguite nei piani servizio app in un ambiente del servizio app. In un ambiente del servizio app abilitato al bilanciamento del carico interno, questa porta è associata all'indirizzo ILB dell'ambiente.
  • 21: canale di controllo per il servizio FTP. Questa porta può essere bloccata in modo sicuro se FTP non viene usato. In un ambiente del servizio app abilitato al bilanciamento del carico interno, questa porta è associata all'indirizzo ILB per un ambiente.
  • 990: canale di controllo per il servizio FTPS. Questa porta può essere bloccata in modo sicuro se FTPS non viene usato. In un ambiente del servizio app abilitato al bilanciamento del carico interno, questa porta è associata all'indirizzo ILB per un ambiente.
  • 10001-10020: canali di dati per il servizio FTP. Come per il canale di controllo, queste porte possono essere bloccate in modo sicuro se FTP non viene usato. In un ambiente del servizio app abilitato al bilanciamento del carico interno, questa porta può essere associata all'indirizzo ILB dell'ambiente.
  • 4016: porta usata per il debug remoto con Visual Studio 2012. Questa porta può essere bloccata in modo sicuro se la funzionalità non viene usata. In un ambiente del servizio app abilitato al bilanciamento del carico interno, questa porta è associata all'indirizzo ILB dell'ambiente.
  • 4018: porta usata per il debug remoto con Visual Studio 2013. Questa porta può essere bloccata in modo sicuro se la funzionalità non viene usata. In un ambiente del servizio app abilitato al bilanciamento del carico interno, questa porta è associata all'indirizzo ILB dell'ambiente.
  • 4020: porta usata per il debug remoto con Visual Studio 2015. Questa porta può essere bloccata in modo sicuro se la funzionalità non viene usata. In un ambiente del servizio app abilitato al bilanciamento del carico interno, questa porta è associata all'indirizzo ILB dell'ambiente.
  • 4022: usato per il debug remoto con Visual Studio 2017. Questa porta può essere bloccata in modo sicuro se la funzionalità non viene usata. In un ambiente del servizio app abilitato al bilanciamento del carico interno, questa porta è associata all'indirizzo ILB dell'ambiente.
  • 4024 Usato per il debug remoto con Visual Studio 2019. Questa porta può essere bloccata in modo sicuro se la funzionalità non viene usata. In un ambiente del servizio app abilitato al bilanciamento del carico interno, questa porta è associata all'indirizzo ILB dell'ambiente.
  • 4026: usato per il debug remoto con Visual Studio 2022. Questa porta può essere bloccata in modo sicuro se la funzionalità non viene usata. In un ambiente del servizio app abilitato al bilanciamento del carico interno, questa porta è associata all'indirizzo ILB dell'ambiente.

Requisiti per DNS e connettività in uscita

Per un corretto funzionamento dell'ambiente del servizio app, è necessario l'accesso in uscita ai vari endpoint. Un elenco completo degli endpoint esterni usati da un ambiente del servizio app è disponibile nella sezione "Requisiti della connettività di rete" dell'articolo Configurazione di rete per ExpressRoute .

Gli ambienti del servizio app richiedono un'infrastruttura DNS valida configurata per la rete virtuale. Se la configurazione DNS viene modificata dopo la creazione di un ambiente del servizio app, gli sviluppatori possono forzare un ambiente del servizio app a selezionare la nuova configurazione DNS. Se si attiva un riavvio dell'ambiente in sequenza usando l'icona Riavvia , l'ambiente seleziona la nuova configurazione DNS. (L'oggetto L'icona di riavvio si trova nella parte superiore del pannello di gestione ambiente del servizio app, nel portale di Azure.

È inoltre consigliabile configurare in anticipo tutti i server DNS personalizzati nella rete virtuale prima di creare un ambiente del servizio app. Se la configurazione DNS di una rete virtuale viene modificata durante la creazione di un ambiente del servizio app, il processo di creazione ambiente del servizio app avrà esito negativo. Analogamente, se è presente un server DNS personalizzato che non è raggiungibile o non è disponibile nell'altra estremità di un gateway VPN, anche il processo di creazione ambiente del servizio app avrà esito negativo.

Creazione di un gruppo di sicurezza di rete

Per i dettagli sul funzionamento dei gruppi di sicurezza di rete, vedere le informazioni seguenti. L'esempio di Gestione dei servizi di Azure seguente illustra le evidenziazioni dei gruppi di sicurezza di rete. Nell'esempio viene configurato e applicato un gruppo di sicurezza di rete a una subnet contenente un ambiente del servizio app.

Nota: i gruppi di sicurezza di rete possono essere configurati graficamente usando il portale di Azure o tramite Azure PowerShell.

I gruppi di sicurezza di rete vengono inizialmente creati come un'entità autonoma associata a una sottoscrizione. Poiché i gruppi di sicurezza di rete vengono creati in un'area di Azure, creare il gruppo di sicurezza di rete nella stessa area del ambiente del servizio app.

Il comando seguente illustra la creazione di un gruppo di sicurezza di rete:

New-AzureNetworkSecurityGroup -Name "testNSGexample" -Location "South Central US" -Label "Example network security group for an app service environment"

Dopo aver creato il gruppo di sicurezza di rete, vengono aggiunte una o più regole di sicurezza di rete. Poiché il set di regole può cambiare nel tempo, è necessario spaziare lo schema di numerazione usato per le priorità delle regole. Questa procedura semplifica l'inserimento di regole aggiuntive nel tempo.

Nell'esempio seguente una regola concede in modo esplicito l'accesso alle porte di gestione necessarie all'infrastruttura di Azure per gestire e gestire un ambiente del servizio app. Tutto il traffico di gestione passa tramite TLS ed è protetto da certificati client. Anche se le porte sono aperte, sono inaccessibili da qualsiasi entità diversa dall'infrastruttura di gestione di Azure.

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "ALLOW AzureMngmt" -Type Inbound -Priority 100 -Action Allow -SourceAddressPrefix 'INTERNET'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '454-455' -Protocol TCP

Quando si blocca l'accesso alla porta 80 e 443 per "nascondere" un ambiente del servizio app dietro dispositivi o servizi upstream, ricordare l'indirizzo IP upstream. Ad esempio, se si usa un web application firewall (WAF), waf avrà un proprio indirizzo IP o indirizzi. Il WAF li usa quando si esegue il proxy del traffico verso un ambiente del servizio app downstream. È necessario usare questo indirizzo IP nel parametro SourceAddressPrefix di una regola di sicurezza di rete.

Nell'esempio seguente, il traffico in ingresso da un indirizzo IP upstream specifico è consentito in modo esplicito. L'indirizzo 1.2.3.4 è usato come segnaposto per l'indirizzo IP di un firewall per applicazioni Web upstream. Modificare il valore in modo che corrisponda all'indirizzo usato dal dispositivo o dal servizio upstream corrente.

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT HTTP" -Type Inbound -Priority 200 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '80' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT HTTPS" -Type Inbound -Priority 300 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '443' -Protocol TCP

Se si vuole il supporto FTP, usare le regole seguenti come modello per concedere l'accesso alle porte del canale dati e alla porta di controllo FTP. Poiché FTP è un protocollo con stato, potrebbe non essere possibile instradare il traffico FTP tramite un firewall HTTP/HTTPS tradizionale o un dispositivo proxy. In questo caso, è necessario impostare SourceAddressPrefix su un valore diverso, ad esempio l'intervallo di indirizzi IP di sviluppatori o computer di distribuzione in cui sono in esecuzione i client FTP.

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT FTPCtrl" -Type Inbound -Priority 400 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '21' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT FTPDataRange" -Type Inbound -Priority 500 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '10001-10020' -Protocol TCP

Nota: l'intervallo delle porte dei canali di dati per FTP potrebbero variare durante il periodo di anteprima del servizio.

Se si usa la funzionalità di debug remoto con Visual Studio, usare le regole seguenti per concedere l'accesso. È disponibile una regola separata per ogni versione supportata di Visual Studio perché ogni versione usa una porta diversa per il debug remoto. Come per l'accesso FTP, il traffico di debug remoto potrebbe non transitare correttamente attraverso un dispositivo proxy o un firewall per applicazioni Web tradizionale. È quindi possibile impostare SourceAddressPrefix sull'intervallo di indirizzi IP dei computer di sviluppo che eseguono Visual Studio.

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT RemoteDebuggingVS2012" -Type Inbound -Priority 600 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '4016' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT RemoteDebuggingVS2013" -Type Inbound -Priority 700 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '4018' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT RemoteDebuggingVS2015" -Type Inbound -Priority 800 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '4020' -Protocol TCP

Assegnazione di un gruppo di sicurezza di rete a una subnet

Un gruppo di sicurezza di rete ha una regola di sicurezza predefinita che nega l'accesso a tutto il traffico esterno. Quando si combina questa regola con le regole di sicurezza di rete precedenti, solo il traffico proveniente da intervalli di indirizzi di origine associati a un'azione Consenti sarà in grado di inviare traffico alle app eseguite in un ambiente del servizio app.

Dopo che un gruppo di sicurezza di rete viene popolato con regole di sicurezza, assegnarlo alla subnet contenente il ambiente del servizio app. Il comando di assegnazione fa riferimento a due nomi: il nome della rete virtuale in cui è il ambiente del servizio app e il nome della subnet in cui è stato creato il ambiente del servizio app.

L'esempio seguente illustra l'assegnazione di un gruppo di sicurezza di rete a una subnet e a una rete virtuale:

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName 'testVNet' -SubnetName 'Subnet-test'

L'assegnazione è un'operazione a esecuzione prolungata e il completamento può richiedere alcuni minuti. Una volta completata l'assegnazione del gruppo di sicurezza di rete, solo il traffico in ingresso corrispondente alle regole Consenti raggiungerà correttamente le app nel ambiente del servizio app.

Per completezza, l'esempio seguente illustra come rimuovere e annullare l'associazione del gruppo di sicurezza di rete dalla subnet:

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Remove-AzureNetworkSecurityGroupFromSubnet -VirtualNetworkName 'testVNet' -SubnetName 'Subnet-test'

Considerazioni speciali su IP SSL esplicito

Se un'app è configurata con un indirizzo IP-SSL esplicito (applicabile solo a A edizione Standard che hanno un indirizzo VIP pubblico), anziché usare l'indirizzo IP predefinito del ambiente del servizio app, il traffico HTTP e HTTPS passa nella subnet su porte diverse dalle porte 80 e 443.

Per trovare la singola coppia di porte usata da ogni indirizzo IP-SSL, passare al portale e visualizzare il pannello dell'esperienza utente dei dettagli del ambiente del servizio app. Selezionare Tutti gli indirizzi IP delle impostazioni>. Il pannello Indirizzi IP mostra una tabella di tutti gli indirizzi IP-SSL configurati in modo esplicito per il ambiente del servizio app. Il pannello mostra anche la coppia di porte speciale usata per instradare il traffico HTTP e HTTPS associato a ogni indirizzo IP-SSL. Usare questa coppia di porte per i parametri DestinationPortRange durante la configurazione delle regole in un gruppo di sicurezza di rete.

Quando un'app in un A edizione Standard è configurata per l'uso di IP-SSL, i clienti esterni non vedranno o devono preoccuparsi del mapping speciale della coppia di porte. Il traffico verso le app transiterà normalmente all'indirizzo IP SSL configurato. La conversione alla coppia di porte speciale avviene automaticamente internamente, durante la fase finale del traffico di routing nella subnet che contiene l'A edizione Standard.

Attività iniziali

Per iniziare a usare le ambiente del servizio app, vedere Introduzione alle ambiente del servizio app.

Per altre informazioni, vedere Connessione sicura alle risorse back-end da un ambiente del servizio app.

Nota

Per iniziare a usare il servizio app di Azure prima di registrarsi per ottenere un account Azure, andare a Prova il servizio app, dove è possibile creare un'app Web iniziale temporanea nel servizio app. Non è necessario fornire una carta di credito né impegnarsi in alcun modo.