Esercitazione: Creare un'app a più livelli sicura in Servizio app di Azure

Molte applicazioni hanno più di un singolo componente. Ad esempio, potrebbe essere disponibile un front-end accessibile pubblicamente e si connette a un'API back-end o a un'app Web. Le risorse back-end possono connettersi a un database, a un account di archiviazione, a un insieme di credenziali delle chiavi, a un'altra macchina virtuale o a una combinazione di queste risorse. Questa architettura è la base di un'applicazione a più livelli. È importante progettare applicazioni di questo tipo per proteggere al massimo le risorse back-end.

Questa esercitazione descrive come distribuire un'applicazione a più livelli sicura con un'app Web front-end che si connette a un'altra app Web isolata dalla rete. Tutto il traffico viene isolato all'interno del Rete virtuale di Azure usando Rete virtuale integration e private endpoint. Per indicazioni più complete che includono altri scenari, vedere:

• Bilanciamento del carico delle applicazioni in più aree
• Modello di app Web affidabile per .NET

In questa esercitazione, imparerai a:

Prerequisiti

L'esercitazione usa due app di esempio Node.js ospitate in GitHub. Se ancora non si dispone di un account GitHub, è possibile crearne uno gratuitamente.

Se non si ha un account Azure, creare un account gratuito prima di iniziare.

Per completare questa esercitazione:

• Utilizzare l'ambiente Bash in Azure Cloud Shell. Per altre informazioni, vedere Introduzione ad Azure Cloud Shell.

  

• Se si preferisce eseguire i comandi di riferimento dell'interfaccia della riga di comando in locale, installare l'interfaccia della riga di comando di Azure. Per l'esecuzione in Windows o macOS, considerare l'esecuzione dell'interfaccia della riga di comando di Azure in un contenitore Docker. Per altre informazioni, vedere Come eseguire l’interfaccia della riga di comando di Azure in un contenitore Docker.

  • Se si usa un'installazione locale, accedere all'interfaccia della riga di comando di Azure con il comando az login. Per completare il processo di autenticazione, seguire la procedura visualizzata nel terminale. Per altre opzioni di accesso, vedere Eseguire l'autenticazione ad Azure con l'interfaccia della riga di comando di Azure.

  • Quando richiesto, al primo utilizzo installare l'estensione dell'interfaccia della riga di comando di Azure. Per altre informazioni sulle estensioni, vedere Usare e gestire le estensioni con l'interfaccia della riga di comando di Azure.

  • Eseguire az version per trovare la versione e le librerie dipendenti installate. Per eseguire l'aggiornamento alla versione più recente, eseguire az upgrade.

Esaminare l'architettura dello scenario

Questa esercitazione illustra come configurare un'architettura illustrata nel diagramma seguente. Lo scenario rappresenta una delle possibili configurazioni N-tier in App Service. È possibile usare i concetti trattati in questa esercitazione per creare app più complesse a più livelli.

• L'architettura ha una rete virtuale che contiene due subnet. Una subnet è integrata con l'app Web front-end e l'altra ha un endpoint privato per l'app Web back-end. La rete virtuale blocca tutto il traffico di rete in ingresso, ad eccezione del traffico destinato all'app front-end integrata.

• Un'app Web front-end è integrata nella rete virtuale e accessibile dalla rete Internet pubblica.

• Un'app Web back-end è accessibile solo tramite l'endpoint privato nella rete virtuale.

• Un endpoint privato si integra con l'app Web back-end e rende l'app Web accessibile tramite un indirizzo IP privato.

• Una zona DNS privato consente la risoluzione di un nome DNS all'indirizzo IP dell'endpoint privato.

Lo scenario in questa esercitazione offre il comportamento seguente:

• Il traffico pubblico verso l'app back-end viene bloccato.
• Il traffico in uscita da App Service viene instradato verso la rete virtuale e può raggiungere l'app di back-end.
• Il servizio app può eseguire la risoluzione DNS all'app back-end.

Creare le due app web

Sono necessarie due app Web del servizio app, una per il front-end e una per il back-end. Le app possono essere eseguite nella stessa località. Per configurare l'integrazione della rete virtuale e usare endpoint privati, usare almeno il livello Basic di Servizio app di Azure. Configurare l'integrazione della rete virtuale e altre impostazioni in un secondo momento.

1. Creare un gruppo di risorse per gestire tutte le risorse per questa esercitazione.

   Impostare il <resource-group> segnaposto sul nome del nuovo gruppo di risorse, ad esempio zava-resources. Impostare il placeholder <region-location> sull'area geografica del nuovo gruppo di risorse, ad esempio eastus.

   # Define variables for the resource group name and region location
   resourceGroupName=<resource-group>
   regionLocation=<region-location>
   
   # Create the resource group
   az group create --name $resourceGroupName --location $regionLocation
   

   Per altre informazioni, vedere il riferimento al comando az group create .

2. Crea un piano di App Service per le tue risorse.

   Imposta il placeholder <app-service-plan> sul nome del tuo nuovo piano di App Service, ad esempio zava-app-service-plan.

   L'esempio di esercitazione imposta il --sku parametro su P1V3 (Premium V3). È possibile usare questo valore o specificare uno SKU diverso. Lo SKU deve supportare le funzionalità di rete necessarie per questa esercitazione. Selezionare il livello Basic o superiore.

   # Define a variable for the App Service plan name
   appServicePlanName=<app-service-plan>
   
   # Create the App Service plan
   az appservice plan create --name $appServicePlanName --resource-group $resourceGroupName --is-linux --location $regionLocation --sku P1V3
   

   Per altre informazioni, vedere il riferimento al comando az appservice plan create .

3. Crea le applicazioni web frontend e backend.

   L'esempio di esercitazione crea due app di esempio Node.js, in cui la versione del linguaggio di runtime è NODE:24-lts. Se si preferisce usare le proprie app, impostare il valore del --runtime parametro <language-version> di conseguenza. È possibile eseguire il az webapp list-runtimes comando per l'elenco dei runtime disponibili:

   az webapp list-runtimes
   

   Imposta il segnaposto <frontend-app-name> con il nome della tua nuova app Web frontend, ad esempio zava-frontend-app. Il nome deve essere univoco a livello globale e deve essere costituito da caratteri validi (a-z, 0-9, -). Analogamente, impostare il <backend-app-name> segnaposto sul nome della nuova app Web back-end, ad esempio zava-backend-app.

   # Define variables for the App Service web app names
   frontendAppName=<frontend-app-name>
   backendAppName=<backend-app-name>
   
   # Create the web apps
   az webapp create --name $frontendAppName --resource-group $resourceGroupName --plan $appServicePlanName --runtime "NODE:24-lts"
   az webapp create --name $backendAppName  --resource-group $resourceGroupName --plan $appServicePlanName --runtime "NODE:24-lts"
   

   Per altre informazioni, vedere il riferimento al comando az webapp create .

Creare l'infrastruttura di rete

L'infrastruttura di rete virtuale è costituita dalle risorse seguenti:

• Istanza di Rete virtuale di Azure
• Una subnet per l'integrazione con la rete virtuale di App Service
• Un'altra subnet per l'endpoint privato
• Una zona Azure DNS privato
• Un endpoint privato

1. Creare una rete virtuale di Azure

   Impostare il <virtual-network-name> segnaposto sul nome della nuova rete virtuale, ad esempio zava-virtual-network. Il nome deve essere univoco a livello globale.

   # Define a variable for the virtual network name
   virtualNetworkName=<virtual-network-name>
   
   # Create the virtual network
   az network vnet create --resource-group $resourceGroupName --location $regionLocation --name $virtualNetworkName --address-prefixes 10.0.0.0/16
   

   Per altre informazioni, vedere il riferimento al comando az network vnet create .

2. Crea una subnet per l'integrazione della rete virtuale di App Service.

   Imposta il placeholder <network-integration-subnet> sul nome della tua nuova subnet che supporti l'integrazione con la rete virtuale, ad esempio zava-integration-subnet.

   Per Servizio app, è consigliabile che la subnet di integrazione della rete virtuale abbia almeno un blocco CIDR di /26. /24 è più che sufficiente. --delegations Microsoft.Web/serverfarmsspecifica che la subnet è delegata per l'integrazione della rete virtuale di Servizio app.

   # Define a variable for the integration subnet name
   networkIntegrationSubnet=<network-integration-subnet>
   
   # Create the subnet for virtual network integration
   az network vnet subnet create --resource-group $resourceGroupName --vnet-name $virtualNetworkName --name $networkIntegrationSubnet \
      --address-prefixes 10.0.0.0/24 --delegations Microsoft.Web/serverfarms \
      --disable-private-endpoint-network-policies false
   

   Per altre informazioni, vedere il riferimento al comando az network vnet subnet create .

3. Creare un'altra subnet per gli endpoint privati.

   Impostare il <private-endpoint-subnet> segnaposto sul nome della nuova subnet che supporta l'endpoint privato, ad esempio zava-endpoint-subnet.

   # Define a variable for the private endpoint subnet name
   privateEndpointSubnet=<private-endpoint-subnet>
   
   # Create the subnet for the private endpoint
   az network vnet subnet create --resource-group $resourceGroupName --vnet-name $virtualNetworkName --name $privateEndpointSubnet \
      --address-prefixes 10.0.1.0/24 \
      --disable-private-endpoint-network-policies true
   

   Per le subnet degli endpoint privati, è necessario disabilitare i criteri di rete degli endpoint privati impostando il --disable-private-endpoint-network-policies flag su true. Per altre informazioni, vedere i parametri facoltativi per il comando az network vnet subnet create .

   Note

   Il --private-endpoint-network-policies flag potrebbe presto sostituire il --disable-private-endpoint-network-policies flag.

4. Creare la zona Azure DNS privato.

   Impostare il segnaposto <private-zone-name> sul nome della nuova zona DNS privato, ad esempio zava-private.azurewebsites.net.

   # Define a variable for the Private DNS zone
   privateDNSZone=<private-zone-name>
   
   # Create the Private DNS zone
   az network private-dns zone create --resource-group $resourceGroupName --name $privateDNSZone
   

   Per altre informazioni, vedere il riferimento al comando az network vnet subnet create . Per altre informazioni sulla configurazione della zona DNS privata, vedere Configurazione della zona DNS del servizio Azure.

   Note

   Se si crea l'endpoint privato nel portale di Azure, viene creata automaticamente una zona Azure DNS privato per la configurazione. Per coerenza procedurale in questa esercitazione, creare separatamente l'endpoint privato e la zona DNS privato usando il interfaccia della riga di comando di Azure.

5. Collegare la zona DNS privato alla rete virtuale.

   Impostare il <dns-link-name> segnaposto sul nome del nuovo collegamento DNS, ad esempio zava-private-link.

   # Define a variable for the DNS link name
   dnsLinkName=<dns-link-name>
   
   # Create the link between the Private DNS zone and the virtual network
   az network private-dns link vnet create --resource-group $resourceGroupName --name $dnsLinkName --zone-name $privateDNSZone \
      --virtual-network $virtualNetworkName --registration-enabled False
   

   Per altre informazioni, vedere il riferimento al comando az network private-dns link vnet create .

6. Nella subnet dell'endpoint privato della tua rete virtuale, crea un endpoint privato per la tua app Web back-end.

   Imposta il segnaposto <private-endpoint-name> con il nome del nuovo endpoint privato per l'app Web di back-end, ad esempio zava-backend-endpoint. Impostare il <service-connection-name> segnaposto sul nome della nuova connessione al servizio, ad esempio zava-backend-connection.

   # Define variables for the private endpoint and service connection
   privateEndpointName=<private-endpoint-name>
   serviceConnectionName=<service-connection-name>
   
   # Get the resource ID of the backend web app
   resourceId=$(az webapp show --resource-group $resourceGroupName --name $backendAppName --query id --output tsv)
   
   # Create the private endpoint for the backend web app by using the resource ID
   az network private-endpoint create --resource-group $resourceGroupName --name $privateEndpointName --location $regionLocation \
      --connection-name $serviceConnectionName --private-connection-resource-id $resourceId \
      --group-id sites --vnet-name $virtualNetworkName --subnet $privateEndpointSubnet
   

   Per altre informazioni, vedere il riferimento al comando az network private-endpoint create .

7. Collegare l'endpoint privato alla zona DNS privato con un gruppo di zone DNS per l'endpoint privato dell'app Web back-end.

   Impostare il <dns-zone-group-name> segnaposto sul nome del nuovo gruppo di zone DNS, ad esempio zava-dns-zone-group. Il gruppo di zone DNS consente l'aggiornamento automatico della zona DNS privato quando viene aggiornato l'endpoint privato.

   # Define a variable for the DNS Zone group
   dnsZoneGroupName=<dns-zone-group-name>
   
   # Link the private endpoint to the Private DNS      
   az network private-endpoint dns-zone-group create --resource-group $resourceGroupName --endpoint-name $privateEndpointName \
      --name $dnsZoneGroupName --private-dns-zone $privateDNSZone --zone-name $privateDNSZone
   

   Per altre informazioni, vedere il riferimento al comando az network private-endpoint dns-zone-group create .

8. Verifica che l'accesso diretto all'endpoint privato sia negato.

   Quando si crea un endpoint privato per un'app di App Service, l'accesso pubblico viene disabilitato implicitamente. Se si tenta di accedere all'app Web back-end usando l'URL predefinito, l'accesso viene negato.

   In un browser immettere l'URL predefinito per l'app Web back-end, ad esempio <backend-app-name>.azurewebsites.net.

   Il messaggio del browser indica che l'accesso diretto è negato:

   

   Per altre informazioni sulle restrizioni di accesso di Servizio app con endpoint privati, vedere Restrizioni di accesso di Servizio app di Azure.

Configurare l'integrazione della rete virtuale

Dopo aver creato l'infrastruttura di rete virtuale, è possibile configurare l'integrazione della rete virtuale nell'app Web front-end. L'integrazione della rete virtuale consente al traffico in uscita di fluire direttamente nella rete virtuale. Per impostazione predefinita, solo il traffico IP locale definito nello spazio di indirizzi privati RFC-1918 > viene instradato alla rete virtuale. Questo livello di routing è necessario per abilitare gli endpoint privati.

Abilitare l'integrazione della rete virtuale nell'app Web front-end. Il comando seguente presuppone che la subnet e l'app Web si trovino nello stesso gruppo di risorse.

az webapp vnet-integration add --resource-group $resourceGroupName --name $frontendAppName --vnet $virtualNetworkName --subnet $networkIntegrationSubnet

Per altre informazioni, vedere il riferimento al comando az webapp vnet-integration add .

Per instradare tutto il traffico alla rete virtuale, vedere Gestire il routing di integrazione della rete virtuale. Il routing di tutto il traffico può essere usato anche se si vuole instradare il traffico Internet attraverso la rete virtuale, ad esempio tramite un Rete virtuale di Azure NAT o Firewall di Azure.

Abilitare la distribuzione nell'app Web back-end

Poiché l'app Web back-end non è accessibile pubblicamente, è necessario consentire allo strumento di distribuzione continua di raggiungere l'app rendendo il sito SCM accessibile pubblicamente da Internet. L'app Web principale può continuare a negare tutto il traffico.

1. Abilitare l'accesso pubblico per l'app Web back-end.

   az webapp update --resource-group $resourceGroupName --name $backendAppName --set publicNetworkAccess=Enabled
   

2. Impostare l'azione regola non corrispondente per l'app Web principale per negare tutto il traffico.

   Questa impostazione nega l'accesso pubblico all'app Web principale anche se l'impostazione generale di accesso alle app è impostata per consentire l'accesso pubblico.

   az resource update --resource-group $resourceGroupName --name $backendAppName --namespace Microsoft.Web \
      --resource-type sites --set properties.siteConfig.ipSecurityRestrictionsDefaultAction=Deny
   

3. Impostare l'azione regola non corrispondente per il sito di Gestione controllo servizi per consentire tutto il traffico.

   az resource update --resource-group $resourceGroupName --name $backendAppName --namespace Microsoft.Web \
      --resource-type sites --set properties.siteConfig.scmIpSecurityRestrictionsDefaultAction=Allow
   

Limitare l'accesso FTP e SCM

Poiché il sito SCM back-end è accessibile pubblicamente, è necessario bloccarlo con una maggiore sicurezza.

1. Disabilitare l'accesso FTP sia per l'app Web front-end che per l'app Web back-end:

   az resource update --resource-group $resourceGroupName --name ftp --namespace Microsoft.Web \
      --resource-type basicPublishingCredentialsPolicies --parent sites/<frontend-app-name> --set properties.allow=false
   
   az resource update --resource-group $resourceGroupName --name ftp --namespace Microsoft.Web \
      --resource-type basicPublishingCredentialsPolicies --parent sites/<backend-app-name> --set properties.allow=false
   

2. Disabilitare l'accesso di autenticazione di base alle porte WebDeploy e ai siti degli strumenti SCM/avanzati per entrambe le app Web:

   az resource update --resource-group $resourceGroupName --name scm --namespace Microsoft.Web \
      --resource-type basicPublishingCredentialsPolicies --parent sites/<frontend-app-name> --set properties.allow=false
   
   az resource update --resource-group $resourceGroupName --name scm --namespace Microsoft.Web \
      --resource-type basicPublishingCredentialsPolicies --parent sites/<backend-app-name> --set properties.allow=false
   

Quando si disabilita l'autenticazione di base nel servizio app, si limita l'accesso agli endpoint FTP e SCM agli utenti registrati con Microsoft Entra ID. Questa azione protegge ulteriormente le app. Per altre informazioni sulla disabilitazione dell'autenticazione di base, tra cui come testare e monitorare gli account di accesso, vedere Disabilitazione dell'autenticazione di base nel servizio app.

Configurare la distribuzione continua con GitHub Actions

Per questa procedura sono necessarie due app pronte per la distribuzione nel front-end del servizio app e nelle app back-end. Per accedere alle app Web, è necessario un service principal e una distribuzione continua con GitHub Actions.

Ottenere app Web per i test di distribuzione

I repository Azure Samples in GitHub forniscono app di esempio Node.js per la distribuzione.

1. In un browser web, vai all'app di esempio backend Node.js.

   Fai un fork del repository GitHub per avere una tua copia su cui apportare modifiche. Questo esempio compila un'app "Hello World". Distribuisci questa app nella tua app Web di back-end.

2. Ripetere lo stesso processo per l'app di esempio front-end Node.js.

   Fai un fork del repository GitHub per avere una tua copia su cui apportare modifiche. Questo esempio compila un'app Web che recupera e visualizza il contenuto di un URL. Distribuisci questa app nella tua app Web front-end.

Configurare l'entità di servizio

Ti serve un'entità servizio per la tua app Web front-end e la tua app Web back-end.

1. Creare un'entità principale del servizio.

   Imposta il segnaposto <service-principal-name> sul nome da assegnare al nuovo service principal, ad esempio zava-service-principal.

   Sostituire gli altri valori dei parametri <placeholder> con le informazioni relative alle proprie risorse.

   # Define a variable for the service principal name
   servicePrincipalName=<service-principal-name>
   
   # Link the private endpoint to the Private DNS 
   
    az ad sp create-for-rbac --name <service-principal-name> --role contributor --scopes \
      /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<frontend-app-name> \
      /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<backend-app-name>
   

   L'output è un oggetto JSON con le credenziali di assegnazione di ruolo che forniscono l'accesso alle app di Servizio app.

   {
     "appId": "00001111-aaaa-2222-bbbb-3333cccc4444",
     "displayName": "<service-principal-name>",
     "password": "0Aa!1Bb!2Cc!3Dd!4Ee!5Ff!6Gg!7Hh!8Ii!9Jj!",
     "tenantId": "aaaabbbb-6666-cccc-7777-dddd8888eeee"
   }
   

   Il JSON include la password del service principal, che è visibile solo in questo momento.

   Suggerimento

   È consigliabile concedere l'accesso minimo. In questo esempio l'ambito è limitato solo alle app, non all'intero gruppo di risorse.

2. Copia l'oggetto JSON così da avere una registrazione del nome dell'entità servizio.

3. Fornire le credenziali dell'entità servizio per l'operazione di accesso di Azure come parte del workflow di GitHub Action.

   Memorizza le credenziali come segreti di GitHub a cui fa riferimento il tuo flusso di lavoro.

   1. Nel browser, vai al repository forked della tua app back-end Node.js su GitHub.

   2. Passare a Impostazioni> Segreti disicurezza>e variabili>Azioni.

   3. Selezionare Nuovo segreto del repository e creare un segreto per ognuna delle impostazioni seguenti.

      Usa i valori dell'output JSON.

      Impostazione	valore	Esempio
      AZURE_CLIENT_ID	<application/client-id>	00001111-aaaa-2222-bbbb-3333cccc4444
      AZURE_TENANT_ID	<tenant-id>	aaaabbbb-6666-cccc-7777-dddd8888eeee
      AZURE_SUBSCRIPTION_ID	<subscription-id>	cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a

   4. Ripeti questo processo per il repository duplicato tramite fork della tua app frontend Node.js su GitHub.

Configurare la distribuzione continua con GitHub Actions

È possibile configurare la distribuzione continua con GitHub Actions.

1. Nel portale Azure, vai alla pagina Panoramica della tua app Web front-end.

2. Nel menu a sinistra selezionare Centro distribuzione>.

3. Nella scheda Settings impostare l'opzione Source su GitHub:

   

4. Se si esegue la distribuzione da GitHub per la prima volta, selezionare Autorizza e seguire le istruzioni di autorizzazione. Per eseguire la distribuzione da un repository utente diverso, selezionare Cambia account.

5. Dopo aver autorizzato l'account Azure con GitHub, selezionare Organization, Repository e Branch per configurare CI/CD per. Se non è possibile trovare un'organizzazione o un repository, potrebbe essere necessario abilitare altre autorizzazioni per GitHub. Per altre informazioni, vedere Gestire l'accesso utente ai repository dell'organizzazione.

   Impostazione	valore
   Organizzazione	<your-GitHub-organization>
   Repository	<forked-repository-name>
   Branch	principale

6. Selezionare Salva.

7. Ripeti questo processo per l'app web backend e il repository forkato corrispondente.

Convalidare le connessioni e l'accesso alle app

A questo momento è possibile controllare le connessioni e accedere alle app Web front-end e back-end.

1. Prova ad accedere direttamente all'app Web backend tramite il relativo URL, https://<backend-app-name>.azurewebsites.net.

   Verrà visualizzato il seguente messaggio del browser:

   

   Se è possibile raggiungere l'app, controllare la configurazione:

   • Verificare che l'endpoint privato sia configurato correttamente.

   • Verificare che le restrizioni di accesso per l'app siano impostate per negare tutto il traffico per l'app Web principale.

2. Ora prova ad accedere direttamente alla tua app Web frontend tramite il suo URL, https://<frontend-app-name>.azurewebsites.net.

   Quando la connessione ha esito positivo, viene visualizzata la pagina seguente:

   

3. Nella casella URL immettere l'URL dell'app Web back-end, https://<backend-app-name>.azurewebsites.nete selezionare Recupera.

   Se si configurano correttamente le connessioni, la pagina viene aggiornata per visualizzare il contenuto del messaggio dall'app Web back-end:

   

   Il traffico in uscita dall'app Web front-end passa attraverso la rete virtuale. L'app Web front-end si connette in modo sicuro all'app Web back-end tramite l'endpoint privato.

   Se si verifica un errore nelle connessioni, viene visualizzato il messaggio Errore 403 - Accesso negato nell'output.

Stabilire una sessione SSH e aprire una shell remota

Verificare che l'app Web front-end riesca a raggiungere l'app Web back-end attraverso il collegamento privato usando SSH per accedere a un'istanza front-end.

1. Stabilire una sessione SSH per il contenitore Web dell'app e aprire una shell remota nel browser:

   az webapp ssh --resource-group $resourceGroupName --name $frontendAppName
   

   Per altre informazioni, vedere le informazioni di riferimento sul comando az webapp ssh .

2. Dopo aver aperto la shell nel browser, verifica che l'app Web di back-end sia accessibile utilizzando l'indirizzo IP privato dell'app Web di back-end.

   Nei comandi seguenti sostituire i valori dei <placeholder> parametri con le informazioni per la propria risorsa.

   1. Eseguire il comando nslookup:

      nslookup <backend-app-name>.azurewebsites.net
      

   2. Eseguire il curl comando per convalidare di nuovo il contenuto del sito:

      curl https://<backend-app-name>.azurewebsites.net
      

   

   Il comando nslookup dovrebbe risolversi nell'indirizzo IP privato dell'app Web di back-end. L'indirizzo IP privato deve essere un indirizzo dalla rete virtuale.

   È possibile confermare l'indirizzo IP privato nel portale di Azure. Vai alla pagina Impostazioni>Rete della tua app Web back-end.

   

3. Ripeti gli stessi comandi nslookup e curl da un altro terminale (che non sia una sessione SSH sulle tue istanze frontend).

   

   Il nslookup comando restituisce l'indirizzo IP pubblico per l'app Web back-end. Poiché l'accesso pubblico all'app Web back-end è disabilitato, se si tenta di raggiungere l'indirizzo IP pubblico, viene visualizzato un errore di accesso negato. Questo errore indica che il sito non è accessibile dalla rete Internet pubblica, ovvero il comportamento previsto.

   Il nslookup comando non viene risolto nell'indirizzo IP privato perché l'indirizzo è risolvibile solo dall'interno della rete virtuale tramite la zona DNS privata. Solo l'app Web front-end si trova all'interno della rete virtuale. Se si tenta di eseguire il curl comando nell'app Web back-end dal terminale esterno, il codice HTML restituito contiene il messaggio Errore 403, Accesso negato - L'app Web che si è tentato di raggiungere ha bloccato l'accesso. Alcuni terminali visualizzano anche lo stesso CODICE HTML della pagina di errore restituita quando si tenta di accedere direttamente all'app Web back-end.

Pulire le risorse

Nei passaggi precedenti sono state create risorse di Azure in un gruppo di risorse. Se si ritiene che queste risorse non saranno necessarie in futuro, eliminare il gruppo di risorse eseguendo questo comando in Cloud Shell.

Sostituire il valore del <placeholder> parametro con le informazioni per la propria risorsa:

az group delete --name <resource-group>

Il completamento di questo comando può richiedere alcuni minuti.

Domande frequenti

In questa esercitazione è stata distribuita un'infrastruttura di base per supportare un'app Web a più livelli sicura. Il servizio app offre funzionalità che consentono di assicurarsi di eseguire applicazioni che seguono le procedure consigliate e le raccomandazioni per la sicurezza.

Questa sezione contiene le risposte alle domande frequenti che consentono di proteggere ulteriormente le app e distribuire e gestire le risorse in base alle procedure consigliate.

Eseguire la distribuzione con altri metodi rispetto a un'entità servizio

In questa esercitazione, hai disabilitato l'autenticazione di base. Non è possibile eseguire l'autenticazione con il sito SCM back-end usando un nome utente e una password oppure usando un profilo di pubblicazione. Tuttavia, anziché eseguire l'autenticazione usando un'entità servizio, è possibile usare le credenziali openID Connect .

Configura la distribuzione con GitHub Actions in App Service

Azure genera automaticamente un file del flusso di lavoro nel repository. I nuovi commit nel repository e nel branch selezionati vengono distribuiti automaticamente in modo continuo nella tua app di App Service. È possibile tenere traccia dei commit e delle distribuzioni nella scheda Logs in GitHub.

Un file del flusso di lavoro predefinito che usa un profilo di pubblicazione per l'autenticazione per Servizio app viene aggiunto al repository GitHub. È possibile visualizzare questo file passando alla directory <repo-name>/.github/workflows/.

Verificare l'accesso pubblico sicuro del sito SCM back-end

Quando si bloccano gli accessi FTP e SCM, è possibile assicurarsi che solo le identità supportate da Microsoft Entra possano accedere all'endpoint SCM, anche se l'endpoint è accessibile pubblicamente. Questa impostazione consente di rassicurare l'utente che l'app Web back-end è ancora sicura.

Eseguire la distribuzione senza un sito SCM back-end aperto

Se temi di consentire l'accesso pubblico al sito SCM o hai restrizioni dei criteri aziendali, prendi in considerazione altre opzioni di distribuzione di App Service, ad esempio l'esecuzione da un pacchetto ZIP.

Distribuisci questa architettura tramite un modello

Le risorse create in questa esercitazione possono essere distribuite usando un modello di Azure Resource Manager (modello arm) o Bicep. L'applicazione connessa a un file Bicep di un'app Web back-end consente di creare una soluzione applicativa sicura a più livelli.

Per informazioni su come distribuire modelli ARM e Bicep, vedere Distribuire file Bicep con l'interfaccia della riga di comando di Azure.

Contenuti correlati

• Integrate l'app con Rete virtuale di Azure
• Funzionalità di rete del servizio app
• Modello di app Web affidabile per .NET