Applicazione Web con ridondanza della zona a disponibilità elevata di base

Questa architettura di base si basa sull'architettura di base dell'applicazione Web ed estenderla per fornire indicazioni dettagliate per la progettazione di un'applicazione Web sicura, con ridondanza della zona e a disponibilità elevata in Azure. L'architettura espone un endpoint pubblico tramite app Azure lication Gateway con Web Application Firewall. Instrada le richieste al servizio app Azure tramite collegamento privato. L'applicazione servizio app usa l'integrazione della rete virtuale e collegamento privato per comunicare in modo sicuro con i servizi PaaS di Azure, ad esempio Azure Key Vault e database SQL di Azure.

Architettura

Figura 1: Architettura del servizio app Azure di base

Scaricare un file di Visio di questa architettura.

Componenti

Molti componenti di questa architettura sono gli stessi dell'architettura dell'applicazione Web di base. Nell'elenco seguente vengono evidenziate solo le modifiche apportate all'architettura di base.

• Gateway applicazione è un load balancer di livello 7 (HTTP/S) e gestione traffico Web. Usa il routing basato sul percorso URL per distribuire il traffico in ingresso tra zone di disponibilità e esegue l'offload della crittografia per migliorare le prestazioni dell'applicazione.
• Web Application Firewall (WAF) è un servizio nativo del cloud che protegge le app Web da exploit comuni come SQL injection e cross-site scripting. WAF offre visibilità sul traffico da e verso l'applicazione Web, consentendo di monitorare e proteggere l'applicazione.
• Azure Key Vault è un servizio cloud che archivia e gestisce in modo sicuro informazioni sensibili, come segreti, chiavi di crittografia e certificati. Centralizza la gestione delle informazioni riservate.
• Azure Rete virtuale è un servizio che consente di creare reti virtuali private isolate e sicure in Azure. Per un'applicazione Web in servizio app, è necessaria una subnet di rete virtuale per usare endpoint privati per la comunicazione sicura di rete tra le risorse.
• Collegamento privato consente ai client di accedere ai servizi PaaS (Platform as a Service) di Azure direttamente da reti virtuali private senza usare indirizzi IP pubblici.
• DNS di Azure è un servizio di hosting per i domini DNS che offre la risoluzione dei nomi usando l'infrastruttura di Microsoft Azure. Le zone di DNS privato consentono di eseguire il mapping del nome di dominio completo (FQDN) di un servizio all'indirizzo IP di un endpoint privato.

Rete

La sicurezza di rete è alla base dell'architettura di base delle servizio app s (vedere la figura 2). Da un livello elevato, l'architettura di rete garantisce quanto segue:

1. Un singolo punto di ingresso sicuro per il traffico client
2. Il traffico di rete viene filtrato
3. I dati in transito vengono crittografati end-to-end con TLS
4. L'esfiltrazione dei dati viene ridotta al minimo mantenendo il traffico in Azure tramite l'uso di collegamento privato
5. Le risorse di rete sono raggruppate logicamente e isolate l'una dall'altra tramite la segmentazione di rete

Flussi di rete

Figura 2: Architettura di rete dell'applicazione del servizio di base app Azure

Di seguito sono riportate le descrizioni del flusso in ingresso del traffico Internet verso l'istanza di servizio app e il flusso dal servizio app ai servizi di Azure.

Flusso in entrata

1. L'utente invia una richiesta all'indirizzo IP pubblico gateway applicazione.
2. Le regole WAF vengono valutate. Le regole WAF influiscono positivamente sull'affidabilità del sistema proteggendoli da vari attacchi, ad esempio xss (cross-site scripting) e SQL injection. app Azure lication Gateway restituisce un errore al richiedente se una regola WAF viene violata e l'elaborazione si arresta. Se non viene violata alcuna regola WAF, gateway applicazione instrada la richiesta al pool back-end, che in questo caso è la servizio app dominio predefinito.
3. La zona privatelink.azurewebsites.net DNS privata è collegata alla rete virtuale. La zona DNS ha un record A che esegue il mapping dell'servizio app dominio predefinito all'indirizzo IP privato del servizio app endpoint privato. Questa zona DNS privata collegata consente a DNS di Azure di risolvere il dominio predefinito nell'indirizzo IP dell'endpoint privato.
4. La richiesta viene instradata a un'istanza di servizio app tramite l'endpoint privato.

servizio app al flusso dei servizi PaaS di Azure

1. servizio app effettua una richiesta al nome DNS del servizio di Azure richiesto. La richiesta potrebbe essere ad Azure Key Vault per ottenere un segreto, Archiviazione di Azure per ottenere un file ZIP di pubblicazione, database SQL di Azure o qualsiasi altro servizio di Azure che supporta collegamento privato. La funzionalità di integrazione della rete virtuale servizio app indirizza la richiesta tramite la rete virtuale.
2. Come nel passaggio 3 del flusso in ingresso, la zona DNS privata collegata ha un record A che esegue il mapping del dominio del servizio di Azure all'indirizzo IP privato dell'endpoint privato. Anche in questo caso, questa zona DNS privata collegata consente a DNS di Azure di risolvere il dominio nell'indirizzo IP dell'endpoint privato del servizio.
3. La richiesta viene instradata al servizio tramite l'endpoint privato.

Ingresso a servizio app

gateway applicazione è una risorsa a livello di area che soddisfa i requisiti di questa architettura di base. gateway applicazione è un servizio di bilanciamento del carico scalabile, regionale, di livello 7 che supporta funzionalità come web application firewall e offload TLS. Quando si implementano gateway applicazione per l'ingresso in servizi di app Azure, tenere presente quanto segue.

• Distribuire gateway applicazione e configurare un criterio WAF con un set di regole gestito da Microsoft. Usare la modalità prevenzione per attenuare gli attacchi Web, che potrebbero causare la mancata disponibilità di un servizio di origine (servizio app nell'architettura).
• Implementare la crittografia TLS end-to-end.
• Usare gli endpoint privati per implementare l'accesso privato in ingresso al servizio app.
• Valutare la possibilità di implementare la scalabilità automatica per gateway applicazione per adattarsi facilmente ai flussi di traffico dinamici.
• Prendere in considerazione l'uso di un numero minimo di istanze di scalabilità non inferiore a tre e usare sempre tutte le zone di disponibilità supportate dall'area. Anche se gateway applicazione viene distribuito in modo a disponibilità elevata, anche per una singola istanza di scalabilità, la creazione di una nuova istanza in caso di errore può richiedere fino a sette minuti. La distribuzione di più istanze in zone di disponibilità garantire che, in caso di errore, un'istanza sia in esecuzione durante la creazione di una nuova istanza.
• Disabilitare l'accesso alla rete pubblica nel servizio app per garantire l'isolamento della rete. In Bicep questa operazione viene eseguita impostando publicNetworkAccess: 'Disabled' in proprietà/siteConfig.

Passare da servizio app ai servizi di Azure

Questa architettura usa l'integrazione della rete virtuale per il servizio app, in particolare per instradare il traffico agli endpoint privati attraverso la rete virtuale. L'architettura di base non consente a tutto il routing del traffico di forzare tutto il traffico in uscita attraverso la rete virtuale, solo il traffico interno, ad esempio il traffico associato per gli endpoint privati.

I servizi di Azure che non richiedono l'accesso da Internet pubblico devono avere endpoint privati abilitati ed endpoint pubblici disabilitati. Gli endpoint privati vengono usati in tutta questa architettura per migliorare la sicurezza consentendo al servizio app di connettersi ai servizi collegamento privato direttamente dalla rete virtuale privata senza usare indirizzi IP pubblici.

In questa architettura, database SQL di Azure, Archiviazione di Azure e Key Vault tutti hanno endpoint pubblici disabilitati. I firewall del servizio di Azure vengono usati solo per consentire il traffico da altri servizi di Azure autorizzati. È consigliabile configurare altri servizi di Azure con endpoint privati, ad esempio Azure Cosmos DB e Cache Redis di Azure. In questa architettura Monitoraggio di Azure non usa un endpoint privato, ma potrebbe.

L'architettura di base implementa una zona DNS privata per ogni servizio. La zona DNS privata contiene un record A che esegue il mapping tra il nome di dominio completo del servizio e l'indirizzo IP privato dell'endpoint privato. Le zone sono collegate alla rete virtuale. DNS privato gruppi di zone assicurarsi che i record DNS di collegamento privato vengano creati e aggiornati automaticamente.

Quando si implementano l'integrazione della rete virtuale e gli endpoint privati, tenere presente quanto segue.

• Usare le linee guida per la configurazione della zona DNS dei servizi di Azure per la denominazione delle zone DNS private.
• Configurare i firewall del servizio per garantire che l'account di archiviazione, l'insieme di credenziali delle chiavi, database SQL e altri servizi di Azure possano essere connessi solo a privato.
  • Impostare la regola di accesso di rete predefinita dell'account di archiviazione per negare tutto il traffico.
  • Abilitare Key Vault per collegamento privato.
  • Negare l'accesso alla rete pubblica ad Azure SQL.

Segmentazione e sicurezza della rete virtuale

La rete in questa architettura include subnet separate per il gateway applicazione, i componenti di integrazione servizio app e gli endpoint privati. Ogni subnet ha un gruppo di sicurezza di rete che limita il traffico in ingresso e in uscita per tali subnet solo a ciò che è necessario. Nella tabella seguente viene illustrata una visualizzazione semplificata delle regole del gruppo di sicurezza di rete aggiunte alla baseline a ogni subnet. La tabella assegna il nome e la funzione della regola.

Quando si implementano la segmentazione e la sicurezza della rete virtuale, tenere presente quanto segue.

• Abilitare la protezione DDoS per la rete virtuale con una subnet che fa parte di un gateway applicazione con un indirizzo IP pubblico.
• Aggiungere un NSG a ogni subnet laddove possibile. È consigliabile usare le regole più rigide che abilitano la funzionalità completa della soluzione.
• Usare i gruppi di sicurezza delle applicazioni. I gruppi di sicurezza delle applicazioni consentono di raggruppare gruppi di sicurezza di rete, semplificando la creazione di regole per ambienti complessi.

Un esempio di schema di subnet virtuale può essere:

Informazioni di riferimento su Azure-Samples\app-service-baseline-implementation

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.

L'architettura di base servizio app s è incentrata sulla ridondanza di zona per i servizi a livello di area chiave. Le zone di disponibilità sono località separate fisicamente entro un'area. Forniscono ridondanza di zona per i servizi di supporto quando due o più istanze vengono distribuite nelle aree di supporto. Quando un'area riscontra tempi di inattività, le altre zone potrebbero comunque non essere interessate.

L'architettura garantisce anche istanze sufficienti dei servizi di Azure per soddisfare la domanda. Le sezioni seguenti forniscono indicazioni sull'affidabilità per i servizi chiave nell'architettura. In questo modo, le zone di disponibilità consentono di ottenere affidabilità offrendo disponibilità elevata e tolleranza di errore.

Gateway applicazione

Distribuire app Azure lication Gateway v2 in una configurazione con ridondanza della zona. Prendere in considerazione l'uso di un numero minimo di istanze di scalabilità non inferiore a tre per evitare il tempo di avvio da sei a sette minuti per un'istanza di gateway applicazione in caso di errore.

Servizi app

• Distribuire almeno tre istanze di servizio app con il supporto della zona di disponibilità.
• Implementare gli endpoint di controllo integrità nelle app e configurare la funzionalità di controllo integrità servizio app per reindirizzare le richieste da istanze non integre. Per altre informazioni sul controllo integrità di servizio app, vedere Monitorare le istanze di servizio app usando il controllo integrità. Per altre informazioni sull'implementazione degli endpoint di controllo integrità nelle applicazioni ASP.NET, vedere Controlli di integrità in ASP.NET Core.
• Capacità di overprovisioning per poter gestire gli errori della zona.

Database SQL

• Distribuire utilizzo generico, Premium o Business Critical del database SQL di Azure con ridondanza della zona abilitata. I livelli Utilizzo generico, Premium e Business Critical supportano la ridondanza della zona nel database SQL di Azure.
• Configurare i backup del database SQL per l'uso dell'archiviazione con ridondanza della zona (ZRS) o dell'archiviazione con ridondanza geografica della zona.Configure SQL DB backups to use zone-redundant storage (ZRS) or geo-zone-redundant storage (GZRS).

Archiviazione BLOB

• Archiviazione con ridondanza della zona di Azure replica i dati in modo sincrono in tre zone di disponibilità nell'area. Creare account di archiviazione con ridondanza della zona standard o archiviazione con ridondanza geografica della zona standard per assicurarsi che i dati vengano replicati tra zone di disponibilità.
• Creare account di archiviazione separati per distribuzioni, asset Web e altri dati in modo da poter gestire e configurare gli account separatamente.

Efficienza prestazionale

L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere Panoramica del pilastro dell'efficienza delle prestazioni.

Le sezioni seguenti illustrano la scalabilità per i componenti chiave di questa architettura.

Gateway applicazione

• Implementare la scalabilità automatica per gateway applicazione per aumentare o ridurre le prestazioni per soddisfare la domanda.
• Impostare il numero massimo di istanze su un numero superiore alla necessità prevista. Verranno addebitati solo i costi per le unità di capacità usate.
• Impostare un numero minimo di istanze in grado di gestire piccoli picchi di traffico. È possibile usare l'utilizzo medio delle unità di calcolo per calcolare il numero minimo di istanze.
• Seguire le indicazioni sul dimensionamento della subnet gateway applicazione.

Servizio app

• Usare piani Standard o superiori con tre o più istanze di lavoro per la disponibilità elevata.
• Abilitare la scalabilità automatica per assicurarsi che sia possibile aumentare e ridurre le prestazioni per soddisfare la domanda.
• È consigliabile aprire un ticket di supporto per aumentare il numero massimo di ruoli di lavoro a due volte il numero di istanze se il servizio app usa costantemente la metà del numero massimo di istanze. Per impostazione predefinita, il numero massimo di istanze è fino a 30 per un piano premium servizio app e 10 per un piano Standard.
• Valutare la possibilità di distribuire più timbri dell'applicazione quando il servizio app inizia a raggiungere i limiti superiori.
• Scegliere il piano di servizio app Azure appropriato che soddisfi i requisiti del carico di lavoro.
• Aggiungere Rete CDN di Azure al servizio app Azure per gestire il contenuto statico.
• Considera ambiente del servizio app se i vicini rumorosi sono un problema.

SQL Server

Il ridimensionamento delle risorse del database è un argomento complesso al di fuori dell'ambito di questa architettura. Quando si ridimensiona il database, prendere in considerazione le risorse seguenti.

• Ridimensionare dinamicamente le risorse del database con tempi di inattività minimi
• Aumento del numero di istanze con il database SQL di Azure
• Usare le repliche di sola lettura per l'offload dei carichi di lavoro di query di sola lettura

Altre linee guida per la scalabilità

• Esaminare i limiti e le quote delle sottoscrizioni per assicurarsi che i servizi vengano ridimensionati per la domanda.
• Prendere in considerazione la memorizzazione nella cache per i tipi di dati seguenti per migliorare le prestazioni e la scalabilità:
  • Dati di transazione semistatici.
  • Stato sessione.
  • Output HTML. Può essere utile nelle applicazioni che eseguono il rendering di output HTML complesso.

Sicurezza

L'architettura di base servizio app è incentrata sulle raccomandazioni di sicurezza essenziali per l'app Web. Comprendere il funzionamento della crittografia e dell'identità a ogni livello è fondamentale per proteggere il carico di lavoro.

Servizio app

• Disabilitare i metodi di autenticazione locale per le distribuzioni del sito FTP e SCM
• Disattivare il debug remoto.
• Usare la versione più recente di TLS.
• Abilitare Microsoft Defender per servizio app.
• Usare le versioni più recenti di piattaforme, linguaggi di programmazione, protocolli e framework supportati.
• Prendere in considerazione ambiente del servizio app se è necessario un isolamento superiore o un accesso di rete sicuro.

Crittografia

Un'app Web di produzione deve crittografare i dati in transito tramite HTTPS. Il protocollo HTTPS si basa su Transport Layer Security (TLS) e usa chiavi pubbliche e private per la crittografia. È necessario archiviare un certificato (X.509) in Key Vault e consentire al gateway applicazione di recuperare la chiave privata. Per i dati inattivi, alcuni servizi crittografano automaticamente i dati e altri consentono di personalizzare.

Dati in movimento

Nell'architettura di base i dati in transito vengono crittografati dall'utente all'app Web in servizio app. Il flusso di lavoro seguente descrive il funzionamento della crittografia a livello generale.

1. L'utente invia una richiesta HTTPS all'app Web.
2. La richiesta HTTPS raggiunge il gateway applicazione.
3. Il gateway applicazione usa un certificato (X.509) in Key Vault per creare una connessione TLS sicura con il Web browser dell'utente. Il gateway applicazione decrittografa la richiesta HTTPS in modo che il web application firewall possa esaminarlo.
4. Il gateway applicazione crea una connessione TLS con servizio app per crittografare nuovamente la richiesta utente. servizio app fornisce il supporto nativo per HTTPS, quindi non è necessario aggiungere un certificato a servizio app. Il gateway applicazione invia il traffico crittografato a servizio app. servizio app decrittografa il traffico e l'app Web elabora la richiesta.

Quando si configura la crittografia dei dati in transito, tenere presente quanto segue.

• Creare o caricare il certificato in Key Vault. La crittografia HTTPS richiede un certificato (X.509). È necessario un certificato di un'autorità di certificazione attendibile per il dominio personalizzato.
• Archiviare la chiave privata nel certificato in Key Vault.
• Seguire le indicazioni in Concedere alle applicazioni l'autorizzazione per accedere a un insieme di credenziali delle chiavi di Azure usando il controllo degli accessi in base al ruolo di Azure e le identità gestite per le risorse di Azure per fornire gateway applicazione accesso alla chiave privata del certificato. Non usare i criteri di accesso di Key Vault per fornire l'accesso. I criteri di accesso consentono solo di concedere autorizzazioni generali non solo a valori specifici.
• Abilitare la crittografia end-to-end. servizio app è il pool back-end per il gateway applicazione. Quando si configura l'impostazione back-end per il pool back-end, usare il protocollo HTTPS sulla porta back-end 443.

Dati inattivi

• Crittografare i dati sensibili in database SQL di Azure usando Transparent Data Encryption. Transparent Data crittografa l'intero database, i backup e i file di log delle transazioni e non richiede alcuna modifica all'applicazione Web.
• Ridurre al minimo la latenza di crittografia del database. Per ridurre al minimo la latenza di crittografia, posizionare i dati da proteggere nel proprio database e abilitare solo la crittografia per tale database.
• Informazioni sul supporto della crittografia predefinito. Archiviazione di Azure crittografa automaticamente i dati inattivi usando la crittografia lato server (AES a 256 bit). Monitoraggio di Azure crittografa automaticamente i dati inattivi usando chiavi gestite da Microsoft .

Gestione delle identità e degli accessi

La baseline di servizio app configura l'autenticazione e l'autorizzazione per le identità utente (utenti) e le identità del carico di lavoro (risorse di Azure) e implementa il principio dei privilegi minimi.

Identità utente

• Usare il meccanismo di autenticazione integrata per servizio app ("EasyAuth"). EasyAuth semplifica il processo di integrazione dei provider di identità nell'app Web. Gestisce l'autenticazione all'esterno dell'app Web, quindi non è necessario apportare modifiche significative al codice.
• Configurare l'URL di risposta per il dominio personalizzato. È necessario reindirizzare l'app Web a https://<application-gateway-endpoint>/.auth/login/<provider>/callback. Sostituire <application-gateway-endpoint> con l'indirizzo IP pubblico o il nome di dominio personalizzato associato al gateway applicazione. Sostituire <provider> con il provider di autenticazione in uso, ad esempio "aad" per Microsoft Entra ID. È possibile usare la documentazione di Front di Azure per configurare questo flusso con gateway applicazione o Configurazione di gateway applicazione.

Identità dei carichi di lavoro

• Usare l'identità gestita per le identità del carico di lavoro. Identità gestita elimina la necessità che gli sviluppatori gestiscano le credenziali di autenticazione.
• Usare le identità gestite assegnate dall'utente. Un'identità assegnata dal sistema può causare l'esito negativo delle distribuzioni dell'infrastruttura come codice in base alle race condition e all'ordine delle operazioni. È possibile usare le identità gestite assegnate dall'utente per evitare alcuni di questi scenari di errore di distribuzione. Per altre informazioni, vedere Informazioni sulle identità gestite per le risorse di Azure.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'eccellenza operativa.

La distribuzione per l'applicazione di base servizio app segue le linee guida in CI/CD per Azure App Web con Azure Pipelines. Oltre a queste indicazioni, l'architettura di base servizio app s tiene conto che l'applicazione e l'account di archiviazione di distribuzione sono protetti dalla rete. L'architettura nega l'accesso pubblico alle servizio app. Ciò significa che non è possibile eseguire la distribuzione dall'esterno della rete virtuale. La linea di base illustra come distribuire il codice dell'applicazione all'interno della rete virtuale usando agenti di distribuzione self-hosted. Le indicazioni sulla distribuzione seguenti sono incentrate sulla distribuzione del codice dell'applicazione e sulla mancata distribuzione di modifiche all'infrastruttura o al database.

Figura 3: Distribuzione di applicazioni del servizio app Azure

Flusso di distribuzione

1. Come parte della pipeline di versione, la pipeline invia una richiesta di processo per gli agenti self-hosted nella coda dei processi. La richiesta di processo è che l'agente carichi l'artefatto di compilazione del file ZIP di pubblicazione in un account Archiviazione di Azure.

2. L'agente di distribuzione self-hosted preleva la nuova richiesta di processo tramite il polling. Scarica il processo e l'artefatto di compilazione.

3. L'agente di distribuzione self-hosted carica il file ZIP nell'account di archiviazione tramite l'endpoint privato dell'account di archiviazione.

4. La pipeline continua e un agente gestito preleva un processo successivo. L'agente gestito effettua una chiamata dell'interfaccia della riga di comando per aggiornare l'appSetting WEBSITE_RUN_FROM_PACKAGE al nome del nuovo file ZIP di pubblicazione per lo slot di staging.

   az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip
   

5. app Azure Servizio esegue il pull del nuovo file ZIP di pubblicazione dalla risorsa di archiviazione tramite l'endpoint privato dell'account di archiviazione. L'istanza di staging viene riavviata con il nuovo pacchetto perché WEBSITE_RUN_FROM_PACKAGE è stato impostato su un nome file diverso.

6. La pipeline riprende ed esegue eventuali smoke test o attende l'approvazione. Se i test superano o approvano, la pipeline scambia gli slot di staging e di produzione.

Indicazioni per la distribuzione

Di seguito vengono evidenziate le linee guida principali per la distribuzione per l'architettura di base.

• Usare l'esecuzione dal pacchetto per evitare conflitti di distribuzione. Quando si esegue l'app direttamente da un pacchetto in app Azure Service, i file nel pacchetto non vengono copiati nella directory wwwroot. Il pacchetto ZIP viene invece montato direttamente come directory wwwroot di sola lettura. In questo modo si eliminano i conflitti di blocco dei file tra distribuzione e runtime e si garantisce che solo le app completamente distribuite siano in esecuzione in qualsiasi momento
• Includere i numeri di versione nei file ZIP del pacchetto distribuito. L'aggiornamento dell'appSetting WEBSITE_RUN_FROM_PACKAGE al pacchetto di distribuzione con un nome di file diverso causa servizio app di selezionare automaticamente la nuova versione e riavviare il servizio.
• Usare slot di distribuzione per distribuzioni di codice resilienti.
• Prendere in considerazione l'uso di una combinazione di agenti gestiti e self-hosted.
  • Usare agenti self-hosted per caricare il file ZIP del pacchetto nell'account di archiviazione tramite l'endpoint privato. L'agente avvia la comunicazione con la pipeline tramite il polling , quindi non è necessario aprire la rete per una chiamata in ingresso.
  • Usare agenti gestiti per gli altri processi nella pipeline.
• Automatizzare le distribuzioni dell'infrastruttura con infrastruttura distribuita come codice (IaC).
• Convalidare continuamente il carico di lavoro per testare le prestazioni e la resilienza dell'intera soluzione usando servizi come Test di carico di Azure e Azure Chaos Studio.

Impostazione

Le applicazioni richiedono sia valori di configurazione che segreti. Usare le indicazioni seguenti per la gestione di configurazione e segreti.

• Non controllare mai segreti come password o chiavi di accesso nel controllo del codice sorgente.
• Usare Azure Key Vault per archiviare i segreti.
• Usare servizio app configurazione per la configurazione dell'applicazione. Se è necessario esternalizzare la configurazione dalla configurazione dell'applicazione o richiedere il supporto dei flag di funzionalità, è consigliabile usare app Azure Configurazione.
• Usare i riferimenti a Key Vault nella configurazione di servizio app per esporre in modo sicuro i segreti nell'applicazione.
• Creare impostazioni dell'app che si attaccano a uno slot e non vengono scambiate se sono necessarie impostazioni di produzione e gestione temporanea diverse. Durante lo scambio di uno slot di distribuzione, le impostazioni dell'app vengono scambiate per impostazione predefinita.
• Impostare le variabili di ambiente locali per lo sviluppo locale o sfruttare le funzionalità della piattaforma dell'applicazione. servizio app configurazione espone le impostazioni dell'app come variabili di ambiente. Visual Studio, ad esempio, consente di impostare le variabili di ambiente nei profili di avvio. Consente anche di usare Impostazioni app e segreti utente per archiviare le impostazioni e i segreti dell'applicazione locale.

Monitoraggio

Il monitoraggio è la raccolta e l'analisi dei dati dai sistemi IT. L'obiettivo del monitoraggio è l'osservabilità a più livelli per tenere traccia dell'integrità e della sicurezza delle app Web. L'osservabilità è un facet chiave dell'architettura di base servizio app.

Per monitorare l'app Web, è necessario raccogliere e analizzare metriche e log dal codice dell'applicazione, dall'infrastruttura (runtime) e dalla piattaforma (risorse di Azure). Per altre informazioni, vedere Log attività di Azure, log delle risorse di Azure e log applicazioni.

Monitorare la piattaforma

Il monitoraggio della piattaforma è la raccolta di dati dai servizi di Azure nell'architettura. Considerare le indicazioni seguenti relative al monitoraggio della piattaforma.

• Aggiungere un'impostazione di diagnostica per ogni risorsa di Azure. Ogni servizio di Azure ha un set diverso di log e metriche che è possibile acquisire. Usare la tabella seguente per individuare le metriche e i log da raccogliere.

  Risorsa di Azure	Metriche e descrizioni dei log
  Gateway applicazione	gateway applicazione metriche e descrizioni dei log
  Web application firewall	Metriche e descrizioni dei log di Web application firewall
  Servizio app	servizio app metriche e descrizioni dei log
  Database SQL di Azure	database SQL di Azure descrizione delle metriche e dei log
  Cosmos DB	Metriche e descrizioni dei log di Azure Cosmos DB
  Insieme di credenziali delle chiavi di	Metriche e descrizioni dei log di Key Vault
  Archiviazione BLOB	Archiviazione BLOB di Azure metriche e descrizioni dei log
  Application Insights	Metriche e descrizioni dei log di Application Insights
  Indirizzo IP pubblico	Metriche e descrizioni dei log degli indirizzi IP pubblici

• Comprendere il costo della raccolta di metriche e log. In generale, maggiore è la metrica e i log raccolti, maggiore è il costo. Per altre informazioni, vedere Calcoli e opzioni dei costi di Log Analytics e Prezzi per l'area di lavoro Log Analytics.

• Creare avvisi. È consigliabile creare avvisi per tutte le risorse di Azure nell'architettura e configurare Azioni per risolvere i problemi. Selezionare regole di avviso comuni e consigliate per iniziare con e modificare nel tempo in base alle esigenze. Per altre informazioni, vedi:

  • Panoramica degli avvisi di Monitoraggio di Azure
  • avvisi di gateway applicazione
  • avvisi servizio app
  • avvisi di database SQL di Azure
  • Avvisi di archiviazione BLOB
  • Avvisi dell'insieme di credenziali delle chiavi

Gateway applicazione

gateway applicazione monitora l'integrità delle risorse nel pool back-end. Usare i log di accesso gateway applicazione per raccogliere informazioni come il timestamp, il codice di risposta HTTP e il percorso URL. Per altre informazioni, vedere gateway applicazione probe di integrità predefinito e log di diagnostica e integrità back-end.

Servizio app

servizio app include strumenti di monitoraggio integrati e predefiniti che è consigliabile abilitare per migliorare l'osservabilità. Se l'app Web dispone già di funzionalità di telemetria e monitoraggio ("strumentazione in-process"), deve continuare a funzionare su servizio app.

• Abilitare la strumentazione automatica. servizio app dispone di un'estensione di strumentazione che è possibile abilitare senza modifiche al codice. Si ottiene la visibilità del monitoraggio delle prestazioni delle applicazioni . Per altre informazioni, vedere Monitorare le prestazioni del servizio app Azure.
• Abilitare la traccia distribuita. La strumentazione automatica offre un modo per monitorare i sistemi cloud distribuiti tramite traccia distribuita e un profiler prestazioni.
• Usare la strumentazione basata su codice per i dati di telemetria personalizzati. app Azure lication Insights supporta anche la strumentazione basata su codice per i dati di telemetria dell'applicazione personalizzati. Aggiungere Application Insights SDK al codice e usare l'API di Application Insights.
• Abilitare i log servizio app. La piattaforma servizio app supporta quattro log aggiuntivi che è necessario abilitare per supportare la risoluzione dei problemi. Questi log sono i log applicazioni, i log del server Web, i messaggi di errore dettagliati e la traccia delle richieste non riuscite.
• Usare la registrazione strutturata. Aggiungere una libreria di registrazione strutturata al codice dell'applicazione. Aggiornare il codice per usare coppie chiave-valore e abilitare i log delle applicazioni in servizio app per archiviare questi log nell'area di lavoro Log Analytics.
• Attivare il controllo integrità servizio app. Il controllo integro reindirizza le richieste da istanze non integre e sostituisce le istanze non integre. Il piano di servizio app deve usare due o più istanze per il funzionamento dei controlli di integrità.

Database

• Informazioni dettagliate sul database utente. Per i database SQL di Azure, è necessario configurare SQL Insights in Monitoraggio di Azure. Database Insights usa viste a gestione dinamica per esporre i dati necessari per monitorare l'integrità, diagnosticare i problemi e ottimizzare le prestazioni. Per altre informazioni, vedere Monitoraggio database SQL di Azure con Monitoraggio di Azure.
• Se l'architettura include Cosmos DB, non è necessario abilitare o configurare elementi per l'uso delle informazioni dettagliate di Cosmos DB.

Governance

Le app Web traggono vantaggio dalle Criteri di Azure applicando decisioni relative all'architettura e alla sicurezza. Criteri di Azure può rendere impossibile (1) distribuire (negare) o (2) facilmente rilevare (controllare) la deviazione della configurazione dallo stato desiderato preferito. Ciò consente di intercettare le distribuzioni IaC (Infrastructure as Code) o portale di Azure modifiche che deviano dall'architettura concordata. È consigliabile inserire tutte le risorse nell'architettura in Criteri di Azure governance. Usare criteri predefiniti o iniziative di criteri, se possibile, per applicare la topologia di rete essenziale, le funzionalità del servizio, la sicurezza e le decisioni di monitoraggio, ad esempio:

• servizio app disabilitare l'accesso alla rete pubblica
• Il servizio app deve usare l'integrazione della rete virtuale
• servizio app usare collegamento privato di Azure per connettersi ai servizi PaaS
• servizio app devono essere disabilitati i metodi di autenticazione locale per le distribuzioni del sito FTP e SCM
• servizio app deve essere disattivato il debug remoto
• Le app del servizio app devono usare la versione TLS più recente
• Microsoft Defender per servizio app deve essere abilitato
• Web Application Firewall (WAF) deve essere abilitato per il gateway applicazione

Vedere altri criteri predefiniti per i servizi chiave, ad esempio componenti di gateway applicazione e di rete, servizio app, Key Vault e Monitoraggio. È possibile creare criteri personalizzati o usare criteri della community (ad esempio dalle zone di destinazione di Azure) se i criteri predefiniti non soddisfano completamente le esigenze. Preferisce i criteri predefiniti quando sono disponibili.

Passaggi successivi

Risorse correlate

• Guida alla collegamento privato in rete WAN virtuale
• Aumentare le prestazioni di un'app nel Servizio app di Azure
• Eseguire la migrazione di servizio app al supporto della zona di disponibilità
• Ridimensionamento gateway applicazione v2 e WAF v2