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

Importante

Questo articolo riguarda l'ambiente del servizio app v1. L'ambiente del servizio app v1 e v2 è stato ritirato il 31 agosto 2024. È disponibile una nuova versione dell'ambiente del servizio app più facile da usare, che viene eseguita in un'infrastruttura più potente. Per altre informazioni sulla nuova versione, vedere Introduzione all'ambiente del servizio app. Se al momento si usa l'ambiente del servizio app v1, seguire la procedura descritta in questo articolo per eseguire la migrazione alla nuova versione.

A partire dal 31 agosto 2024, il Contratto di servizio e i crediti di servizio non si applicano più ai carichi di lavoro dell'ambiente del servizio app v1 e v2 che continuano a essere in produzione, perché sono prodotti ritirati. È stata avviata la dismissione dell'hardware dell'ambiente del servizio app v1 e v2, il che può influire sulla disponibilità e sulle prestazioni di app e dati.

È necessario completare immediatamente la migrazione all'ambiente del servizio app v3 oppure è possibile che le app e le risorse vengano eliminate. Si tenterà con il massimo impegno di eseguire automaticamente la migrazione di qualsiasi ambiente del servizio app v1 e v2 rimanente usando la funzionalità di migrazione sul posto, ma Microsoft non dichiara né garantisce la disponibilità delle applicazioni dopo la migrazione automatica. Può essere necessario eseguire una configurazione manuale per completare la migrazione e ottimizzare la scelta di SKU del piano di servizio app in base a specifiche esigenze. Se la migrazione automatica non è fattibile, le risorse e i dati delle app associati verranno eliminati. È consigliabile agire tempestivamente per evitare uno di questi scenari estremi.

Se è necessario più tempo, è possibile usufruire di un periodo di tolleranza di 30 giorni una tantum per completare la migrazione. Per altre informazioni e per richiedere questo periodo di tolleranza, vedere la panoramica del periodo di tolleranza, quindi passare al portale di Azure e visitare il pannello Migrazione per ogni ambiente del servizio app.

Per le informazioni più aggiornate sul ritiro dell'ambiente del servizio app v1/v2, vedere l'Aggiornamento sul ritiro dell'ambiente del servizio app v1 e v2.

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. In alternativa, è possibile creare un ambiente del servizio app in una rete virtuale e in una subnet preesistenti. A partire da giugno 2016, gli ambienti del servizio app (ASE) possono essere distribuiti in reti virtuali che usano intervalli di indirizzi pubblici o spazi di indirizzi RFC1918 (indirizzi privati). Per altre informazioni, vedere Come creare un ASEv1 da un modello.

Creare sempre un ambiente del servizio app con 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 l'ambiente del servizio app.

Dopo aver assegnato un gruppo di sicurezza di rete a una subnet, il traffico in ingresso alle app nell'ambiente del servizio app è consentito o bloccato in base alle regole di consenso o rifiuto 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 tramite un gruppo di sicurezza di rete, è importante conoscere le 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.

Di seguito è riportato un elenco delle porte usate da un ambiente del servizio app. Tutte le porte sono di tipo TCP, se non indicato diversamente in modo chiaro:

• 454: porta obbligatoria usata dall'infrastruttura di Azure per la gestione e la manutenzione degli ambienti del servizio app tramite TLS. Non bloccare il traffico indirizzato a questa porta. Questa porta è sempre associata all'indirizzo VIP pubblico di un ambiente del servizio app.
• 455: porta obbligatoria usata dall'infrastruttura di Azure per la gestione e la manutenzione degli ambienti del servizio app tramite TLS. Non bloccare il traffico indirizzato a 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 in esecuzione nei piani del 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 sicurezza se non si usa FTP. 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 sicurezza se non si usa FTPS. 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 sicurezza se non si usa FTP. 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 sicurezza, se non si usa questa funzionalità. 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 sicurezza, se non si usa questa funzionalità. 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 sicurezza, se non si usa questa funzionalità. In un ambiente del servizio app abilitato al bilanciamento del carico interno, questa porta è associata all'indirizzo ILB dell'ambiente.
• 4022: porta usata per il debug remoto con Visual Studio 2017. Questa porta può essere bloccata in sicurezza, se non si usa questa funzionalità. In un ambiente del servizio app abilitato al bilanciamento del carico interno, questa porta è associata all'indirizzo ILB dell'ambiente.
• 4024: porta usata per il debug remoto con Visual Studio 2019. Questa porta può essere bloccata in sicurezza, se non si usa questa funzionalità. In un ambiente del servizio app abilitato al bilanciamento del carico interno, questa porta è associata all'indirizzo ILB dell'ambiente.
• 4026: porta usata per il debug remoto con Visual Studio 2022. Questa porta può essere bloccata in sicurezza, se non si usa questa funzionalità. 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 alla selezione automatica della nuova configurazione DNS. Se si attiva un riavvio dell'ambiente in sequenza usando l'icona Riavvia, l'ambiente seleziona la nuova configurazione DNS. L'icona Riavvia si trova nella parte superiore della pagina di gestione dell'ambiente del servizio app nel portale di Azure.

È anche consigliabile che i server DNS personalizzati nella rete virtuale vengano configurati in anticipo 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 dell'ambiente del servizio app ha esito negativo. Analogamente, se esiste un server DNS personalizzato non raggiungibile o non disponibile nell'altra estremità di un gateway VPN, il processo di creazione dell’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 seguente di gestione dei servizi di Azure illustra le evidenziazioni dei gruppi di sicurezza di rete. Nell'esempio viene configurato e applicato un gruppo di sicurezza di rete a una subnet che contiene un ambiente del servizio app.

Nota: i gruppi di sicurezza di rete possono essere configurati in modalità grafica con 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 dell'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 potrebbe cambiare nel tempo, è necessario distanziare lo schema di numerazione usato per le priorità delle regole. Questa procedura semplifica l'inserimento di altre regole nel tempo.

L'esempio seguente illustra una regola che concede in modo esplicito l'accesso alle porte necessarie all'infrastruttura di Azure per la gestione e la manutenzione dell'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 alle porte 80 e 443 per "nascondere" un ambiente del servizio app dietro dispositivi o servizi upstream, è necessario conoscere l'indirizzo IP upstream. Ad esempio, se si usa un WAF (Web Application Firewall), questo ha uno o più indirizzi IP. Il WAF li usa quando esegue il proxy del traffico a 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 desidera il supporto FTP, usare le regole seguenti come un modello per concedere l'accesso alla porta di controllo FTP e alle porte dei canali di dati. Poiché FTP è un protocollo con stato, potrebbe non essere possibile instradare il traffico FTP attraverso un dispositivo proxy o un firewall HTTP/HTTPS tradizionale. In questo caso è necessario impostare SourceAddressPrefix su un valore diverso, ad esempio l'intervallo di indirizzi IP di computer di sviluppo o 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. Esiste una regola separata per ogni versione supportata di Visual Studio, dal momento che 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 include 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 potrà essere inviato alle app eseguite in un ambiente del servizio app.

Una volta popolato un gruppo di sicurezza di rete con regole di sicurezza, assegnarlo alla subnet contenente l'ambiente del servizio app. Il comando di assegnazione fa riferimento a due nomi: il nome della rete virtuale in cui si trova l'ambiente del servizio app e il nome della subnet in cui è stato creato l'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 nell'ambiente del servizio app.

Per completezza, l'esempio seguente illustra come rimuovere e dissociare il 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 agli ambienti del servizio app con indirizzo VIP pubblico) anziché usare l'indirizzo IP predefinito dell'ambiente del servizio app, il traffico HTTP e HTTPS transita nella subnet tramite porte diverse dalle porte 80 e 443.

Per trovare la singola coppia di porte usata da ogni indirizzo IP-SSL, accedere al portale e visualizzare il pannello UX dei dettagli dell'ambiente del servizio app. Selezionare Tutte le impostazioni>Indirizzi IP. Il pannello indirizzi IP mostra una tabella di tutti gli indirizzi IP-SSL configurati in modo esplicito per l'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 quando si configurano le regole in un gruppo di sicurezza di rete.

Quando un'app in un ambiente del servizio app (ASE) è configurata in modo da usare IP SSL, ai clienti esterni non verrà visualizzato il mapping della coppia di porte e non dovranno preoccuparsi di questo aspetto. Il traffico verso le app transiterà normalmente all'indirizzo IP SSL configurato. La conversione a una coppia di porte specifica avviene internamente in modo automatico durante l'ultima parte del routing del traffico nella subnet contenente l'ambiente del servizio app (ASE).

Introduzione

Per iniziare a usare gli ambienti del servizio app, vedere Introduzione all'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.