Applicazioni Web gestite in modo sicuro

Questo articolo offre una panoramica della distribuzione di applicazioni sicure usando l'ambiente del servizio app. Per limitare l'accesso alle applicazioni da Internet, vengono usati il servizio Gateway applicazione di Azure e Web Application Firewall di Azure . Questo articolo fornisce anche indicazioni su integrazione continua e recapito continuo (CI/CD) per gli ambienti del servizio app con Azure DevOps.

Questo scenario viene in genere distribuito in settori come quello bancario e assicurativo, in cui i clienti sono consapevoli della sicurezza a livello di piattaforma oltre che della sicurezza a livello di applicazione. Per illustrare questi concetti, si userà un'applicazione che consente agli utenti di inviare note spese.

Potenziali casi d'uso

Prendere in considerazione questo scenario per i casi d'uso seguenti:

• Creazione di un'app Web di Azure in cui è richiesto un livello di sicurezza aggiuntivo.
• Offerta di una tenancy dedicata, invece di piani di servizio app per tenant condivisi.
• Uso di Azure DevOps con un ambiente del servizio applicazioni con bilanciamento del carico interno( ILB).

Architettura

Scaricare un file di Visio di questa architettura.

Flusso di dati

1. Le richieste HTTP/HTTPS raggiungono inizialmente il gateway applicazione.
2. Facoltativamente (non illustrato nel diagramma), è possibile che l'autenticazione di Microsoft Entra sia abilitata per l'app Web. Quando il traffico raggiunge per la prima volta il gateway applicazione, all'utente viene richiesto di specificare le credenziali per l'autenticazione con l'applicazione.
3. Le richieste utente transitano dal servizio di bilanciamento del carico interno (ILB) dell'ambiente, che a sua volta indirizza il traffico verso l'app Web Expenses.
4. L'utente procede quindi alla creazione di una nota spese.
5. Durante la creazione della nota spese viene richiamata l'app per le API distribuita per recuperare il nome e l'indirizzo di posta elettronica del responsabile dell'utente.
6. La nota spese creata viene archiviata nel database SQL di Azure.
7. Per facilitare la distribuzione continua, il codice viene archiviato nell'istanza di Azure DevOps.
8. Nella macchina virtuale di compilazione è installato l'agente Azure DevOps, che consente alla macchina virtuale di compilazione di eseguire il pull dei componenti relativi all'app Web da distribuire nell'ambiente del servizio app, dal momento che la macchina virtuale di compilazione viene distribuita in una subnet all'interno della stessa rete virtuale.

Componenti

• L'ambiente del servizio app offre un ambiente completamente isolato e dedicato per l'esecuzione sicura dell'applicazione su larga scala. Inoltre, dal momento che l'ambiente del servizio app e i carichi di lavoro in esecuzione in tale ambiente sono protetti da una rete virtuale, offre anche un livello aggiuntivo di sicurezza e isolamento. Il requisito di scalabilità elevata e isolamento è il motivo che ha portato alla selezione dell'ambiente del servizio app ILB.
• Questo carico di lavoro usa il piano tariffario del servizio app isolato, quindi l'applicazione viene eseguita in un ambiente dedicato privato in un data center di Azure usando processori più veloci, archiviazione SSD (Solid State Drive) e raddoppia il rapporto tra memoria e core rispetto allo standard.
• App Web del servizio app di Azure e app per le API ospitano applicazioni Web e API RESTful. Queste app e queste API sono ospitate nel piano di servizio isolato, che offre anche scalabilità automatica, domini personalizzati e altre funzionalità, ma in un livello dedicato.
• Il gateway applicazione di Azure è un servizio di bilanciamento del carico del traffico Web che opera al livello 7 che gestisce il traffico verso l'applicazione Web. Offre l'offload SSL per rimuovere dai server Web che ospitano l'app Web il sovraccarico aggiuntivo associato alla ripetizione della decrittografia del traffico.
• Web Application Firewall è una funzionalità del gateway applicazione. L'abilitazione del Web application firewall nel gateway applicazione migliora ulteriormente la sicurezza. Il firewall dell'applicazione Web utilizza le regole dell'Open Worldwide Application Security Project (OWASP) per proteggere l'applicazione Web da attacchi quali cross-site scripting, dirottamenti di sessione e SQL injection.
• Il database SQL di Azure è stato selezionato perché la maggior parte dei dati in questa applicazione è dati relazionali, con alcuni dati come documenti e BLOB.
• Rete di Azure offre diverse funzionalità di rete in Azure e le reti possono essere sottoposte a peering con altre reti virtuali in Azure. È anche possibile stabilire connessioni con data center locali tramite ExpressRoute o da sito a sito. In questo caso, un endpoint di servizio è abilitato nella rete virtuale per assicurarsi che i dati vengano trasmessi solo tra la rete virtuale di Azure e l'istanza del database SQL.
• Azure DevOps viene usato per aiutare i team a collaborare durante gli sprint, usando funzionalità che supportano lo sviluppo Agile e per creare pipeline di compilazione e versione.
• È stata creata una macchina virtuale di compilazione di Azure in modo che l'agente installato possa eseguire il pull della rispettiva compilazione e distribuire l'app Web nell'ambiente.

Alternative

L'ambiente del servizio app può eseguire app Web normali in Windows. In alternativa, come in questo esempio, le app Web distribuite all'interno dell'ambiente vengono eseguite come contenitori Linux. È stato selezionato un ambiente del servizio app per ospitare queste applicazioni in contenitori a istanza singola. Sono disponibili alternative. Quando si progetta la soluzione, esaminare le considerazioni seguenti.

• Azure Service Fabric: se l'ambiente è principalmente basato su Windows e i carichi di lavoro sono principalmente basati su .NET Framework e non si sta valutando la riprogettazione in .NET Core, usare Service Fabric per supportare e distribuire contenitori di Windows Server. Service Fabric supporta inoltre le API di programmazione C# o Java ed è possibile effettuare il provisioning dei cluster in Windows o Linux per lo sviluppo di microservizi nativi.
• Il servizio Azure Kubernetes è un progetto open source e una piattaforma di orchestrazione più adatta per ospitare applicazioni multicontainer complesse che in genere usano un'architettura basata su microservizi. Il servizio Azure Kubernetes è un servizio gestito di Azure che consente di eliminare le complessità associate al provisioning e alla configurazione di un cluster Kubernetes. È però comunque necessaria una buona conoscenza della piattaforma Kubernetes per supportarlo e gestirlo, di conseguenza l'hosting di un certo numero di applicazioni Web in contenitori a istanza singola potrebbe non essere l'opzione più adatta.

Altre opzioni per il livello dati includono:

• Azure Cosmos DB: se la maggior parte dei dati è in formato non relazionale, Azure Cosmos DB è un'ottima alternativa. Questo servizio offre una piattaforma per eseguire altri modelli di dati come MongoDB, Cassandra, dati Graph o un semplice archivio tabelle.

Gestire le decisioni di progettazione TLS e DNS

Quando si gestiscono i certificati nell'ambiente del servizio app ILB, è necessario tenere presenti alcune considerazioni. È necessario generare un certificato concatenato a una radice attendibile senza una richiesta di firma del certificato generata dal server in cui verrà inserito il certificato. Con Internet Information Services (IIS), ad esempio, il primo passaggio consiste nel generare una richiesta di firma del certificato (CSR) dal server IIS e quindi inviarla all'autorità emittente del certificato SSL.

Non è possibile emettere una CSR dal load balancer interno (ILB) di un ambiente del servizio app. Il modo per gestire questa limitazione consiste nell'usare la procedura con caratteri jolly.

Con la procedura di caratteri speciali è possibile usare la prova della proprietà del nome DNS invece di una richiesta di firma del certificato. Se si è proprietari di uno spazio dei nomi DNS, è possibile inserire uno speciale record TXT DNS. La procedura caratteri jolly verifica la presenza di tale record, che identifica l'utente come proprietario del server DNS perché dispone del record corretto. In base a queste informazioni, rilascia un certificato registrato con una radice attendibile e che quindi può essere caricato nel servizio di bilanciamento del carico interno. Non è necessario eseguire alcuna operazione con i singoli archivi certificati nelle app Web perché è presente un certificato SSL con radice attendibile nel servizio di bilanciamento del carico interno.

Se si desidera eseguire chiamate sicure tra i servizi in esecuzione in un ambiente del servizio app il servizio con bilanciamento del carico interno o rilasciato internamente, effettuare chiamate sicure. Un'altra soluzione da considerare su come rendere l'ambiente del servizio app ilB funziona con il certificato SSL rilasciato internamente e come caricare la CA interna nell'archivio radice attendibile.

Durante il provisioning dell'ambiente del servizio app, considerare le limitazioni seguenti quando si sceglie un nome di dominio per l'ambiente. I nomi di dominio non possono essere:

• net
• azurewebsites.net
• p.azurewebsites.net
• nameofthease.p.azurewebsites.net

Inoltre, il nome di dominio personalizzato usato per le app e il nome di dominio usato dall'ambiente del servizio app non possono sovrapporsi. Per un ambiente del servizio app ILB con nome di dominio contoso.com, non è possibile usare nomi di dominio personalizzati per le app come:

• www.contoso.com
• abcd.def.contoso.com
• abcd.contoso.com

Per l'ambiente del servizio app ILB scegliere un dominio che non sarà in conflitto con tali nomi di dominio personalizzati. Per questo esempio è possibile usare un nome simile a contoso-internal.com per il dominio dell'ambiente del servizio app perché non è in conflitto con nomi di dominio personalizzati che terminano con .contoso.com.

Un altro punto da considerare è il DNS. Per consentire alle applicazioni all'interno dell'ambiente del servizio app di comunicare tra loro, ad esempio a un'applicazione Web di comunicare con un'API, è necessario aver configurato DNS per la rete virtuale che contiene l'ambiente del servizio app. È possibile usare il proprio DNS o le zone private di DNS di Azure.

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à geografica distribuita con ambienti del servizio app per una maggiore resilienza e scalabilità.
• Esaminare i modelli di progettazione tipici per la resilienza e prendere in considerazione l'implementazione di questi modelli, se appropriato.
• È possibile trovare diverse procedure consigliate per il servizio app nel Centro architetture di Azure.
• È consigliabile usare la replica geografica attiva per il livello dati e l'archiviazione con ridondanza geografica per immagini e code.
• Per una discussione più approfondita sulla resilienza, vedere l'articolo pertinente nel Centro architetture di Azure.

Disponibilità

• È consigliabile applicare i modelli di progettazione tipici per la disponibilità durante la compilazione dell'applicazione cloud.
• Esaminare le considerazioni sulla disponibilità nell'architettura di riferimento dell'applicazione Web del servizio app appropriata.
• Per altre considerazioni sulla disponibilità, vedere l'elenco di controllo per la disponibilità nel Centro architetture di Azure.

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'architettura di riferimento dell'applicazione Web del servizio app appropriata.
• Prendere in considerazione la possibilità di seguire un processo sicuro del ciclo di vita di sviluppo 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.
• Esaminare l'architettura del progetto per la conformità a PCI DSS di Azure.
• Protezione DDoS di Azure, combinata con le procedure consigliate per la progettazione delle applicazioni, offre funzionalità avanzate di mitigazione DDoS per offrire una maggiore difesa dagli attacchi DDoS. È consigliabile abilitare Protezione DDoS di Azure in qualsiasi rete virtuale perimetrale.

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. Nel calcolatore dei costi sono preconfigurati tutti i servizi. Per verificare la variazione dei prezzi per un determinato caso d'uso, modificare le variabili appropriate in base al traffico previsto.

Sono stati definiti tre profili di costo di esempio in base alla quantità di traffico prevista.

• Small: questo esempio di prezzi rappresenta i componenti necessari per un'istanza minima a livello di produzione che gestisce alcuni migliaia di utenti al mese. L'app usa una singola istanza di un'app Web standard, sufficiente per abilitare la scalabilità automatica. Ognuno degli altri componenti viene ridimensionato a un livello Basic che consente di ridurre al minimo il costo, garantendo comunque un supporto con contratto di servizio (SLA) e capacità sufficiente per gestire un carico di lavoro a livello di produzione.
• Medium: questo esempio di prezzi rappresenta i componenti necessari per una distribuzione di dimensioni moderate. In questo caso si stimano circa 100.000 utenti nel corso di un mese. Il traffico previsto viene gestito in una singola istanza del servizio app con un livello Standard moderato. Al calcolatore vengono anche aggiunti livelli moderati di servizi cognitivi e di ricerca.
• Large: questo esempio di prezzi rappresenta un'applicazione destinata a scalabilità elevata, in base all'ordine di milioni di utenti al mese, spostando terabyte di dati. Questo livello di utilizzo richiede app Web di livello Premium con prestazioni elevate, distribuite in più aree e gestite da Gestione traffico. I dati sono costituiti dai componenti seguenti: archivi, database e rete CDN, tutti configurati per terabyte di dati.

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 sul funzionamento della scalabilità negli ambienti del servizio app.
• Esaminare le procedure consigliate per la scalabilità automatica delle app cloud.
• Quando si compila un'applicazione cloud, tenere presente i modelli di progettazione tipici per la scalabilità.
• Esaminare le considerazioni sulla scalabilità nell'architettura di riferimento dell'applicazione Web del servizio app appropriata.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

• Faisal Mustafa | Senior Customer Engineer

Passaggi successivi

• Integrare l'ambiente del servizio app con bilanciamento del carico interno con il gateway applicazione di Azure
• Scalabilità geografica distribuita con ambienti del servizio app

Risorse correlate

• Architettura di riferimento dell'applicazione Web del servizio app
• distribuzione aziendale a disponibilità elevata con l'ambiente dei servizi app