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

Servizio app di Azure
Gateway applicazione di Azure
Archiviazione di Azure
database SQL di Azure
Collegamento privato di Azure
Rete virtuale di Azure
Monitoraggio di Azure

Questo articolo fornisce un'architettura di base per l'esecuzione di applicazioni Web in app Azure Servizio in una singola area. Illustra in dettaglio le linee guida 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.

Importante

Logo GitHubLe linee guida sono supportate da un'implementazione di esempio che illustra un'implementazione di base servizio app in Azure. Questa implementazione può essere usata come base per un ulteriore sviluppo di soluzioni nel primo passo verso la produzione.

Architettura

Diagramma che mostra un'architettura di base servizio app con ridondanza di zona e disponibilità elevata.

Figura 1: Architettura del servizio app Azure di base

Scaricare un file di Visio di questa architettura.

Componenti

  • Microsoft Entra ID è un servizio di gestione delle identità e degli accessi basato sul cloud. Fornisce un singolo piano di controllo delle identità per gestire autorizzazioni e ruoli per gli utenti che accedono all'applicazione Web. Si integra con servizio app e semplifica l'autenticazione e l'autorizzazione per le app Web.
  • gateway applicazione è un servizio di bilanciamento del carico 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, ad esempio SQL injection e scripting tra siti. WAF offre visibilità sul traffico da e verso l'applicazione Web, consentendo di monitorare e proteggere l'applicazione.
  • servizio app è una piattaforma completamente gestita per la creazione, la distribuzione e il ridimensionamento di applicazioni Web.
  • Azure Key Vault è un servizio che archivia e gestisce in modo sicuro segreti, chiavi di crittografia e certificati. Centralizza la gestione delle informazioni riservate.
  • Monitoraggio di Azure è un servizio di monitoraggio che raccoglie, analizza e agisce sui dati di telemetria nella distribuzione.
  • La rete virtuale di Azure è 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 fornisce la risoluzione dei nomi usando l'infrastruttura di Microsoft Azure. DNS privato zone consentono di eseguire il mapping del nome di dominio completo (FQDN) di un servizio all'indirizzo IP di un endpoint privato.
  • database SQL di Azure è un servizio di database relazionale gestito per i dati relazionali.

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

Diagramma che mostra una baseline servizio app'architettura 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.

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.

Subnet In ingresso In uscita
snet-AppGateway AppGw.In.Allow.ControlPlane: consenti l'accesso al piano di controllo in ingresso

AppGw.In.Allow443.Internet: consenti l'accesso HTTPS a Internet in ingresso
AppGw.Out.Allow.AppServices: consente l'accesso in uscita ad AppServicesSubnet

AppGw.Out.Allow.PrivateEndpoints: consente l'accesso in uscita a PrivateEndpointsSubnet

AppPlan.Out.Allow.AzureMonitor: consentire l'accesso in uscita a Monitoraggio di Azure
snet-PrivateEndpoints Regole predefinite: Consenti connessioni in ingresso dalla rete virtuale Regole predefinite: Consenti connessioni in uscita alla rete virtuale
snet-AppService Regole predefinite: Consenti connessioni in ingresso dalla rete virtuale AppPlan.Out.Allow.PrivateEndpoints: consente l'accesso in uscita a PrivateEndpointsSubnet

AppPlan.Out.Allow.AzureMonitor: consentire l'accesso in uscita a Monitoraggio di Azure

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 gruppo di sicurezza di rete 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:

Type Nome Intervallo di indirizzi
Rete virtuale Prefisso indirizzo 10.0.0.0/16
Subnet GatewaySubnet 10.0.1.0/24
Subnet AppServicesSubnet 10.0.0.0/24
Subnet PrivateEndpointsSubnet 10.0.2.0/27
Subnet AgentsSubject 10.0.2.32/27

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

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 posizioni fisicamente separate all'interno di 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

Archiviazione BLOB

  • L'Archiviazione con ridondanza della zona di Azure replica i dati in modo sincrono tra 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.

Scalabilità

La scalabilità consente alle applicazioni di gestire aumenti e riduzioni della domanda ottimizzando al contempo le prestazioni e i costi. 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

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.

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 transito

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.

Diagramma che mostra una linea di base servizio app flusso di crittografia.

  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. L'identità gestita elimina la necessità per gli sviluppatori di gestire 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.

Distribuzione

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.

Diagramma che mostra un'architettura di distribuzione servizio app di base.

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 app Impostazioni 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.

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

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
  • servizio app le app devono usare la versione più recente di TLS
  • 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