Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo descrive come distribuire applicazioni sicure usando l'ambiente del servizio app. Questa architettura usa gateway applicazione di Azure e Web application firewall di Azure per limitare l'accesso alle applicazioni Da Internet. Questo articolo illustra anche come integrare l'integrazione continua e la distribuzione continua (CI/CD) con gli ambienti del servizio app usando Azure DevOps.
I settori come le banche e le assicurazioni usano spesso questa soluzione perché i clienti apprezzano sia la sicurezza a livello di piattaforma che a livello di applicazione. Per illustrare questi concetti, l'applicazione di esempio seguente consente agli utenti di inviare i report spese.
Architettura
Scaricare un file di Visio di questa architettura.
Flusso di dati
Il flusso di dati seguente corrisponde al diagramma precedente:
Le richieste HTTP e HTTPS raggiungono il gateway dell'applicazione.
Facoltativamente, l'autenticazione di Microsoft Entra è abilitata per l'app Web. Dopo che il traffico raggiunge il gateway applicazione, all'utente viene richiesto di fornire le credenziali per l'autenticazione con l'applicazione. Il diagramma non mostra questo passaggio.
Le richieste degli utenti passano attraverso il servizio di bilanciamento del carico interno (ILB) dell'ambiente, che instrada il traffico all'applicazione web delle spese.
L'utente crea una nota spese.
Nell'ambito della creazione del report spese, l'app per le API distribuita viene richiamata per recuperare il nome e il messaggio di posta elettronica del manager dell'utente.
Il sistema archivia la nota spese nel database SQL di Azure.
Per facilitare la distribuzione continua, il codice viene archiviato nell'istanza di Azure DevOps.
La macchina virtuale di build include l'agente di Azure DevOps. Questo agente consente alla VM di build di recuperare gli artefatti dell'app web e usarli per distribuire l'app web nell'ambiente App Service. La macchina virtuale di compilazione si trova in una subnet all'interno della stessa rete virtuale dell'ambiente del servizio app.
Componenti
L'ambiente del servizio app offre un ambiente completamente isolato e dedicato per eseguire in modo sicuro l'applicazione su larga scala. Sia l'ambiente del servizio app che i relativi carichi di lavoro si trovano dietro una rete virtuale, quindi la configurazione aggiunge un ulteriore livello di sicurezza e isolamento. Questo scenario usa un ambiente servizio app ILB con bilanciamento del carico interno (ILB) per soddisfare la necessità di elevata scalabilità e isolamento.
Questo carico di lavoro usa il piano tariffario Isolato di App Service. L'applicazione viene eseguita in un ambiente dedicato privato in un data center di Azure che usa processori più veloci e archiviazione SSD (Solid State Drive) e offre le massime funzionalità di scalabilità orizzontale.
Le funzionalità app Web e app per le API del servizio app ospitano applicazioni Web e API RESTful. Queste app e API sono ospitate nel piano di servizio Isolato, che fornisce anche la scalabilità automatica, i domini personalizzati e altre funzionalità in un livello dedicato.
Il gateway applicativo è un bilanciamento del carico del traffico web a livello 7 che gestisce il traffico verso l'applicazione web. Fornisce l'offload SSL (Secure Sockets Layer), che rimuove il sovraccarico di decrittografia del traffico dai server Web che ospitano l'applicazione.
Web application firewall è una funzionalità del gateway applicazione che migliora la sicurezza. Il web application firewall usa regole OWASP (Open Worldwide Application Security Project) per proteggere l'applicazione Web da attacchi, ad esempio script tra siti, hijack di sessione e sql injection.
Il database SQL archivia i dati dell'applicazione. La maggior parte dei dati è relazionale, con alcuni dei dati archiviati come documenti e BLOB.
Rete virtuale di Azure offre varie funzionalità di rete in Azure. È possibile eseguire il peering di reti virtuali e stabilire connessioni con data center locali tramite ExpressRoute o una rete privata virtuale da sito a sito (VPN). Questo scenario consente a un endpoint di servizio nella rete virtuale di garantire che i dati vengano trasmessi solo tra la rete virtuale di Azure e l'istanza del database SQL.
Azure DevOps supporta lo sviluppo agile aiutando i team a collaborare durante gli sprint e fornendo strumenti per creare pipeline di compilazione e versione.
Una macchina virtuale di compilazione di Azure consente all'agente installato di scaricare la rispettiva compilazione e distribuire l'applicazione web nell'ambiente.
Alternative
Un ambiente del servizio app può eseguire normali app Web in Windows o, come in questo esempio, app Web eseguite come contenitori Linux distribuiti all'interno dell'ambiente. Questo scenario usa un ambiente del servizio app per ospitare queste applicazioni in contenitori a istanza singola. Quando si progetta la soluzione, prendere in considerazione le alternative seguenti:
App Azure Container è una piattaforma serverless che riduce il sovraccarico dell'infrastruttura e consente di risparmiare costi durante l'esecuzione di applicazioni in contenitori. Elimina la necessità di gestire la configurazione del server, l'orchestrazione dei contenitori e i dettagli di distribuzione. Container Apps offre tutte le risorse server aggiornate necessarie per mantenere le applicazioni stabili e sicure.
Il servizio Azure Kubernetes è un progetto open source e una piattaforma di orchestrazione progettata per ospitare applicazioni multicontainer complesse che in genere usano un'architettura basata su microservizi. Il servizio AKS (Azure Kubernetes Service) è una piattaforma gestita da Azure che semplifica il provisioning e la configurazione di un cluster Kubernetes. È necessario avere una conoscenza significativa della piattaforma Kubernetes per supportarla e gestirla, quindi l'hosting di poche applicazioni Web in contenitori a istanza singola potrebbe non essere l'opzione migliore.
Usare l'alternativa seguente per il livello dati:
- Azure Cosmos DB è un'opzione valida se la maggior parte dei dati è in formato non relazionale.
Potenziali casi d'uso
Si consideri questa soluzione per i casi d'uso seguenti:
- Creare un'app Web di Azure che richiede sicurezza aggiuntiva.
- Fornire tenancy dedicata anziché piani di servizio app tenant condivisi.
- Usare Azure DevOps con un ambiente del servizio app con carico bilanciato internamente .
Gestire le decisioni di progettazione TLS e DNS
Le impostazioni DNS (Domain Name System) per il suffisso di dominio predefinito dell'ambiente del servizio app non limitano la raggiungibilità delle applicazioni a tali nomi. La funzionalità di suffisso di dominio personalizzato per un Ambiente Servizio App ILB consente di usare il proprio suffisso di dominio per accedere alle applicazioni ospitate nell'Ambiente Servizio App.
Un suffisso di dominio personalizzato definisce un dominio radice usato dall'ambiente del servizio app. Per un ambiente del servizio app ILB, il dominio radice predefinito è appserviceenvironment.net. Un Ambiente del Servizio App con bilanciamento del carico interno è interno alla rete virtuale di un cliente, così i clienti possono usare un dominio radice oltre al dominio predefinito allineato con l'ambiente della rete virtuale. Ad esempio, Contoso Corporation potrebbe usare un dominio radice predefinito di internal.contoso.com per le app che devono essere risolvibili e raggiungibili solo all'interno della rete virtuale di Contoso. È possibile raggiungere un'app in questa rete virtuale accedendo a APP-NAME.internal.contoso.com.
Il suffisso di dominio personalizzato si applica all'ambiente del servizio app. Questa funzionalità è diversa da un'associazione di dominio personalizzata in una singola istanza del servizio app.
Se il certificato usato per il suffisso di dominio personalizzato contiene una voce Nome alternativo soggetto (SAN) per *.scm.CUSTOM-DOMAIN, il sito di Gestione controllo del codice sorgente (SCM) diventa raggiungibile da APP-NAME.scm.CUSTOM-DOMAIN. È possibile accedere a SCM solo tramite dominio personalizzato usando l'autenticazione di base. L'accesso Single Sign-On è disponibile solo quando si usa il dominio radice predefinito.
Quando si gestiscono i certificati in un Ambiente di Servizio App con ILB, tenere presenti i fattori seguenti:
Archiviare un certificato valido SSL o TLS (Transport Layer Security) in un insieme di credenziali di Azure nel formato .PFX.
Assicurarsi che il certificato sia inferiore a 20 KB.
Usare un certificato wildcard SSL per il nome di dominio personalizzato selezionato.
Configurare un'identità gestita assegnata dal sistema o assegnata dall'utente per l'ambiente del servizio app. L'identità gestita esegue l'autenticazione sul Key Vault di Azure, dove risiede il certificato SSL o TLS.
L'ambiente App Service applica le modifiche del certificato entro 24 ore dopo la rotazione nel key vault.
Accesso di rete ad Azure Key Vault
È possibile accedere al key vault pubblicamente o tramite un endpoint privato raggiungibile dalla subnet in cui è distribuito l'ambiente del servizio app.
Se si usa l'accesso pubblico, è possibile proteggere il Key Vault per accettare solo il traffico dall'indirizzo IP in uscita dell'Ambiente del Servizio App.
L'ambiente del servizio app utilizza l'indirizzo IP in uscita della piattaforma come indirizzo di origine quando accede al Key Vault. È possibile trovare questo indirizzo IP nella pagina Indirizzi IP nel portale di Azure.
Configurazione DNS
Per accedere alle applicazioni nell'ambiente del servizio app usando il suffisso di dominio personalizzato, configurare il proprio server DNS o configurare DNS in una zona DNS privata di Azure per il dominio personalizzato. Per altre informazioni, vedere Configurazione DNS.
Proteggere il nome host predefinito univoco
La funzionalità secure unique default hostname offre una soluzione a lungo termine per proteggere le risorse da voci DNS fluttuanti e takeover del sottodominio. Se si abilita questa funzionalità per le risorse del servizio app, nessuno all'esterno dell'organizzazione può ricreare le risorse con lo stesso nome host predefinito. Questa protezione impedisce agli attori malintenzionati di sfruttare voci DNS pendenti e di prendere il controllo di sottodomini. Per altre informazioni, vedere Proteggere i nomi host predefiniti univoci.
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che è possibile usare per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.
Affidabilità
L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'affidabilità.
Prendere in considerazione l'uso della scalabilità distribuita geograficamente con App Service Environments per una maggiore resilienza e scalabilità.
Esaminare i modelli di progettazione tipici per la resilienza e implementarli dove appropriato.
È consigliabile usare la replica geografica attiva per il livello dati e l'archiviazione con ridondanza geografica per immagini e code.
Per altre informazioni, vedere le risorse seguenti:
Disponibilità
È consigliabile applicare i modelli di progettazione tipici per la disponibilità quando si compila l'applicazione cloud.
Esaminare le considerazioni sulla disponibilità nell'architettura di riferimento dell'applicazione web dell'App Service appropriata.
Per altre considerazioni sulla disponibilità, vedere Guide all'affidabilità per servizio.
Sicurezza
La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per la sicurezza.
Esaminare le considerazioni sulla sicurezza nell'appropriata architettura di riferimento dell'applicazione web di App Service.
Prendere in considerazione il processo Security Development Lifecycle (Ciclo di vita dello sviluppo della sicurezza ) per aiutare gli sviluppatori a creare software più sicuro e a soddisfare i requisiti di conformità della sicurezza riducendo al contempo i costi di sviluppo.
Usare protezione DDoS di Azure e procedure consigliate per la progettazione di applicazioni per migliorare la protezione dagli attacchi DDoS (Distributed Denial of Service). Abilitare Protezione DDoS nelle reti virtuali perimetrali.
Ottimizzazione costi
L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per Ottimizzazione costi.
Esplorare il costo di esecuzione di questo scenario. I profili di costo di esempio seguenti sono basati sul traffico previsto. Tutti i servizi sono preconfigurati nel calcolatore dei costi.
Distribuzione di piccole dimensioni: questo esempio di prezzi rappresenta i componenti per un'istanza minima a livello di produzione che serve alcuni migliaia di utenti ogni mese. L'app usa una singola istanza piccola di un'app Web isolata. Ogni componente aggiuntivo viene ridimensionato a un livello Basic per ridurre al minimo i costi garantendo al tempo stesso il supporto del contratto di servizio e una capacità sufficiente per gestire un carico di lavoro a livello di produzione.
Distribuzione media: questo esempio di prezzi rappresenta i componenti per una distribuzione di dimensioni moderate che serve circa 100.000 utenti ogni mese. Un'istanza del servizio app isolata con dimensioni moderate gestisce il traffico. Il gateway applicativo e la capacità del database SQL aumentano per supportare il carico di lavoro aggiuntivo.
Distribuzione di grandi dimensioni: questo esempio di prezzi rappresenta i componenti per un'applicazione su larga scala che serve milioni di utenti ogni mese e sposta terabyte di dati. Questo livello di utilizzo richiede app Web di livello isolato e ad alte prestazioni distribuite in più regioni e gestite da Gestione traffico di Azure. La stima include Traffic Manager e istanze aggiuntive del Gateway delle Applicazioni e della Rete Virtuale. La capacità del database SQL aumenta per supportare il carico di lavoro aggiunto.
Per visualizzare i prezzi per un caso d'uso specifico, modificare le variabili appropriate in modo che corrispondano al traffico previsto.
Efficienza delle prestazioni
L'efficienza delle prestazioni si riferisce alla capacità del carico di lavoro di ridimensionarsi per soddisfare in modo efficiente le esigenze degli utenti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.
Informazioni su come funziona la scalabilità negli App Service Environments.
Esaminare le procedure consigliate per la scalabilità automatica delle app cloud.
Comprendere i modelli di progettazione tipici per la scalabilità quando si compila un'applicazione cloud.
Rivedere le considerazioni sulla scalabilità nell'appropriata architettura di riferimento dell'applicazione web di App Service.
Collaboratori
Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.
Autore principale:
- Nicholas McCollum | Ingegnere Capo per i Clienti
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
- Integra il tuo ambiente del Servizio App ILB con un gateway applicazione di Azure
- Scalabilità geografica distribuita con ambienti del servizio app