Connettersi in modo sicuro alle risorse back-end da un ambiente del servizio app
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.
Poiché un ambiente del servizio app viene sempre creato in una rete virtuale di Azure Resource Manager o in una rete virtuale creata con il modello di distribuzione classica, le connessioni in uscita da un ambiente del servizio app ad altre risorse back-end possono transitare esclusivamente tramite la rete virtuale. 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).
Ad esempio, potrebbe essere in esecuzione un'istanza di SQL Server in un cluster di macchine virtuali con la porta 1433 bloccata. In base all'elenco di controllo di accesso definito per l'endpoint, potrebbe essere consentito solo l'accesso da altre risorse nella stessa rete virtuale.
Oppure, gli endpoint sensibili potrebbero essere eseguiti in locale ed essere connessi ad Azure tramite connessioni da sito a sito o connessioni Azure ExpressRoute. Di conseguenza, solo le risorse nelle reti virtuali connesse ai tunnel da sito a sito o ExpressRoute possono accedere agli endpoint locali.
Per tutti questi scenari, le app in esecuzione in un ambiente del servizio app possono connettersi in modo sicuro ai vari server e risorse. Se il traffico in uscita dalle app viene eseguito in un ambiente del servizio app a endpoint privati nella stessa rete virtuale o connesso alla stessa rete virtuale, scorrerà solo la rete virtuale. Il traffico in uscita verso endpoint privati non scorrerà la rete Internet pubblica.
Un problema si applica al traffico in uscita da un ambiente del servizio app agli endpoint all'interno di una rete virtuale. ambiente del servizio app non è in grado di raggiungere gli endpoint delle macchine virtuali che si trovano nella stessa subnet del ambiente del servizio app. Questa limitazione in genere non dovrebbe essere un problema, se le ambiente del servizio app vengono distribuite in una subnet riservata per l'uso esclusivo dal ambiente del servizio app.
Nota
Sebbene in questo articolo si faccia riferimento alle app Web, è applicabile anche ad app per le API e app per dispositivi mobili.
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. Nella parte superiore del pannello di gestione ambiente del servizio app nel portale selezionare l'icona Riavvia per attivare un riavvio in sequenza dell'ambiente, che fa sì che l'ambiente rilevi la nuova configurazione DNS.
È 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 di ambiente del servizio app avrà esito negativo. All'altra estremità di un gateway VPN, se è presente un server DNS personalizzato non raggiungibile o non disponibile, anche il processo di creazione del ambiente del servizio app avrà esito negativo.
Connessione a un'istanza di SQL Server
Una configurazione di SQL Server comune prevede un endpoint in ascolto sulla porta 1433:
È possibile usare due approcci per limitare il traffico a questo endpoint:
Limitazione dell'accesso con un elenco di controllo di accesso di rete
È possibile proteggere la porta 1433 usando un elenco di controllo di accesso di rete. L'esempio seguente aggiunge alle autorizzazioni di assegnazione gli indirizzi client provenienti dall'interno di una rete virtuale e blocca l'accesso a tutti gli altri client.
Tutte le applicazioni eseguite in ambiente del servizio app, nella stessa rete virtuale di SQL Server, possono connettersi all'istanza di SQL Server. Usare l'indirizzo IP interno della rete virtuale per la macchina virtuale di SQL Server.
La stringa di connessione di esempio seguente fa riferimento all'instanza di SQL Server usando l'indirizzo IP privato.
Server=tcp:10.0.1.6;Database=MyDatabase;User ID=MyUser;Password=PasswordHere;provider=System.Data.SqlClient
Anche se la macchina virtuale ha anche un endpoint pubblico, i tentativi di connessione di usare l'indirizzo IP pubblico verranno rifiutati a causa dell'ACL di rete.
Limitazione dell'accesso con un gruppo di sicurezza di rete
In alternativa, per proteggere l'accesso è possibile usare un gruppo di sicurezza di rete. I gruppi di sicurezza di rete possono essere applicati alle singole macchine virtuali o a una subnet contenente macchine virtuali.
Prima di tutto, è necessario creare un gruppo di sicurezza di rete:
New-AzureNetworkSecurityGroup -Name "testNSGexample" -Location "South Central US" -Label "Example network security group for an app service environment"
La limitazione dell'accesso solo al traffico interno della rete virtuale è semplice con un gruppo di sicurezza di rete. Le regole predefinite in un gruppo di sicurezza di rete consentono l'accesso solo da altri client di rete nella stessa rete virtuale.
Di conseguenza, il blocco dell'accesso a SQL Server è semplice. È sufficiente applicare un gruppo di sicurezza di rete con le regole predefinite alle macchine virtuali che eseguono SQL Server o alla subnet contenente le macchine virtuali.
L'esempio seguente mostra come applicare un gruppo di sicurezza di rete alla subnet contenente le macchine virtuali:
Get-AzureNetworkSecurityGroup -Name "testNSGExample" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName 'testVNet' -SubnetName 'Subnet-1'
Il risultato finale è un set di regole di sicurezza che bloccano l'accesso esterno, consentendo al tempo stesso l'accesso interno alla rete virtuale:
Attività iniziali
Per iniziare a usare gli ambienti del servizio app, vedere Introduzione all'ambiente del servizio app
Per informazioni dettagliate su come controllare il traffico in ingresso all'ambiente del servizio app, vedere Controllo del traffico in ingresso a 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.