Questo articolo offre una panoramica della distribuzione di applicazioni sicure usando l'ambiente del servizio app Azure. Per limitare l'accesso alle applicazioni da Internet, vengono usati il servizio gateway di app Azure lication 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 comunemente distribuito in settori come banche e assicurazioni, in cui i clienti sono consapevoli della sicurezza a livello di piattaforma oltre alla 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 è necessaria una maggiore sicurezza.
- 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
- Le richieste HTTP/HTTPS raggiungono inizialmente il gateway applicazione.
- Facoltativamente (non illustrato nel diagramma), è possibile abilitare l'autenticazione Di Microsoft Entra per l'app Web. Dopo che il traffico raggiunge il gateway applicazione, all'utente verrà richiesto di fornire le credenziali per l'autenticazione con l'applicazione.
- Le richieste utente passano attraverso il servizio di bilanciamento del carico interno (ILB) dell'ambiente, che a sua volta indirizza il traffico all'app Web Expenses.
- L'utente procede quindi alla creazione di una nota spese.
- 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.
- La nota spese creata viene archiviata nel database SQL di Azure.
- Per facilitare la distribuzione continua, il codice viene archiviato nell'istanza di Azure DevOps.
- La macchina virtuale di compilazione ha installato l'agente Azure DevOps, consentendo alla macchina virtuale di compilazione di eseguire il pull dei bit per l'app Web da distribuire nella ambiente del servizio app (poiché 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 dedicato completamente isolato per l'esecuzione dell'applicazione su larga scala. Inoltre, poiché il ambiente del servizio app e i carichi di lavoro eseguiti in esso si trovano dietro una rete virtuale, offre anche un livello aggiuntivo di sicurezza e isolamento. Il requisito di scalabilità elevata e isolamento ha portato alla selezione dei ambiente del servizio app ILB.
- Questo carico di lavoro usa il piano tariffario isolato servizio app, quindi l'applicazione viene eseguita in un ambiente dedicato privato in un data center di Azure usando processori più veloci, archiviazione SSD e doppio rapporto tra memoria e core rispetto allo standard.
- L'app Web e l'app per le API dei servizi app di Azure ospitano applicazioni Web e API conformi ai principi REST. Queste app e API sono ospitate nel piano di servizio Isolato, che offre anche scalabilità automatica, domini personalizzati e così via, ma in un livello dedicato.
- Il gateway applicazione di Azure è un servizio di bilanciamento del carico del traffico Web che opera al livello 7 e che gestisce il traffico verso l'applicazione Web. Offre l'offload SSL, che rimuove un sovraccarico aggiuntivo dai server Web che ospitano l'app Web per decrittografare nuovamente il traffico.
- Web application firewall (WAF) è una funzionalità del gateway applicazione. L'abilitazione del Web application firewall nel gateway applicazione consente di potenziare il livello di sicurezza. Il Web application firewall usa le regole OWASP per proteggere l'applicazione Web da attacchi quali scripting intersito, hijack della sessione e SQL injection.
- Il database SQL di Azure è stato selezionato perché la maggior parte dei dati in questa applicazione è di tipo relazionale e alcuni sono costituiti da 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. Connessione ions possono essere stabilite anche con data center locali tramite ExpressRoute o da sito a sito. In questo caso, nella rete virtuale viene abilitato un endpoint di servizio per garantire che il flusso dei dati avvenga solo tra la rete virtuale di Azure e l'istanza di 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
Un ambiente del servizio app può eseguire normali app Web in Windows o, come in questo esempio, le app Web distribuite all'interno dell'ambiente che 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 l'hosting di applicazioni multi-contenitore 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. Tuttavia, è necessaria una conoscenza significativa della piattaforma Kubernetes per supportarla e gestirla, quindi l'hosting di alcune applicazioni Web in contenitori a istanza singola potrebbe non essere l'opzione migliore.
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 l'esecuzione di altri modelli di dati, ad esempio MongoDB, Cassandra, dati Graph o una semplice archiviazione tabelle.
Considerazioni
Quando si gestiscono certificati in ambiente del servizio app il bilanciamento del carico interno, è necessario tenere presenti alcune considerazioni. È necessario generare un certificato concatenato a una radice attendibile senza richiedere una richiesta di firma del certificato generata dal server in cui verrà archiviato il certificato. Con Internet Information Services (IIS), ad esempio, il primo passaggio consiste nel generare una richiesta di firma del certificato dal server IIS e quindi inviarla all'autorità di emissione del certificato SSL.
Non è possibile emettere una richiesta di firma del certificato dal servizio di bilanciamento del carico interno (ILB) di un ambiente del servizio app. Il modo per gestire questa limitazione consiste nell'usare la procedura con caratteri jolly.
La procedura con caratteri jolly consente di usare la prova della proprietà del nome DNS anziché una richiesta di firma del certificato. Se si è proprietari di uno spazio dei nomi DNS, è possibile inserire un record TXT DNS speciale, la procedura con caratteri jolly verifica che il record sia presente e, se trovato, sa che si è proprietari del server DNS perché si 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 il servizio di bilanciamento del carico interno ambiente del servizio app usare il certificato SSL rilasciato internamente e come caricare la CA interna nell'archivio radice attendibile.
Durante il provisioning del ambiente del servizio app, prendere in considerazione 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
- nomeambienteservizioapp.p.azurewebsites.net
Inoltre, il nome di dominio personalizzato usato per le app e il nome di dominio usato dal servizio di bilanciamento del carico interno ambiente del servizio app non possono sovrapporsi. Per un ambiente del servizio app il bilanciamento del carico interno con il nome di dominio contoso.com, non è possibile usare nomi di dominio personalizzati per le app, ad esempio:
- www.contoso.com
- abcd.def.contoso.com
- abcd.contoso.com
Scegliere un dominio per il ambiente del servizio app il bilanciamento del carico interno che non è in conflitto con i nomi di dominio personalizzati. Per questo esempio è possibile usare qualcosa di simile a contoso-internal.com per il dominio dell'ambiente, perché non è in conflitto con i nomi di dominio personalizzati che terminano con .contoso.com.
Un altro punto da considerare è DNS. Per consentire alle applicazioni all'interno del ambiente del servizio app di comunicare tra loro, ad esempio un'applicazione Web per comunicare con un'API, è necessario configurare DNS per la rete virtuale che contiene l'ambiente. È possibile usare il proprio DNS o le zone private di DNS di Azure.
Disponibilità
- Durante la creazione dell'applicazione cloud valutare la possibilità di applicare i modelli di progettazione tipici per la disponibilità.
- Esaminare le considerazioni sulla disponibilità riportate in relazione all'architettura di riferimento per applicazioni Web del servizio app appropriata.
- Per altre considerazioni sulla disponibilità, vedere l'elenco di controllo per la disponibilità nel Centro architetture di Azure.
Scalabilità
- Informazioni sul funzionamento della scalabilità in ambiente del servizio app.
- Esaminare le procedure consigliate per la scalabilità automatica delle app cloud.
- Durante la creazione di un'applicazione cloud tenere presenti i modelli di progettazione tipici per la scalabilità.
- Esaminare le considerazioni sulla scalabilità riportate in relazione all'architettura di riferimento per applicazioni Web del servizio app appropriata.
- Per altri articoli sulla scalabilità, vedere l'elenco di controllo per l'efficienza delle prestazioni disponibile nel Centro architetture di Azure.
Sicurezza
- Esaminare la panoramica del pilastro della sicurezza.
- Esaminare le considerazioni sulla sicurezza riportate in relazione all'architettura di riferimento per applicazioni Web del servizio app appropriata.
- Valutare la possibilità di seguire un ciclo di vita di sviluppo sicuro per consentire agli sviluppatori di creare software più sicuro e di soddisfare requisiti di conformità agli standard di sicurezza riducendo al contempo i costi di sviluppo.
- Esaminare l'architettura di progetto per la conformità PCI DSS di Azure.
- Protezione DDoS di Azure, in combinazione con le procedure consigliate per la progettazione di applicazioni, offre funzionalità avanzate di mitigazione DDoS per difendersi meglio dagli attacchi DDoS. È consigliabile abilitare Protezione DDOS di Azure in qualsiasi rete virtuale perimetrale.
Resilienza
- Prendere in considerazione l'uso della scalabilità distribuita geografica con ambiente del servizio app per una maggiore resilienza e scalabilità.
- Esaminare i modelli di progettazione tipici per la resilienza e valutare la possibilità di implementarli, quando opportuno.
- In Centro architetture di Azure sono disponibili diverse procedure consigliate per il servizio app.
- Valutare la possibilità di usare la replica geografica attiva per il livello dati e l'archiviazione con ridondanza geografica per le immagini e le code.
- Per una discussione più approfondita sulla resilienza, vedere l'articolo corrispondente in Centro architetture di Azure.
Distribuire lo scenario
Per distribuire questo scenario, seguire questa esercitazione dettagliata che illustra come distribuire manualmente ogni componente. Selezionare ambiente del servizio app v3 anziché v2 quando si segue l'esercitazione. Questa esercitazione fornisce anche un'applicazione .NET di esempio che esegue una semplice applicazione Contoso per la compilazione di note spese.
Prezzo
Esplorare il costo di esecuzione di questo scenario. Nel calcolatore dei costi sono preconfigurati tutti i servizi. Per vedere in che modo i prezzi cambiano per un caso d'uso specifico, modificare le variabili appropriate in modo che corrispondano al traffico previsto.
Sono stati forniti tre profili di costo di esempio in base alla quantità di traffico che si prevede di ottenere:
- 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 riduce al minimo i costi, ma garantisce comunque il supporto del contratto di servizio e una 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 vengono stimati 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 su larga scala, nell'ordine di milioni di utenti al mese, con il trasferimento di terabyte di dati. A questo livello di utilizzo, sono necessarie app Web di livello Premium ad alte prestazioni distribuite in più aree frontali da Gestione traffico. I dati sono costituiti dai componenti seguenti: archiviazione, database e rete CDN, tutti configurati per terabyte di dati.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Faisal Mustafa | Senior Customer Engineer
Passaggi successivi
- Esercitazione sulla procedura dettagliata per la distribuzione
- Integrare l'ambiente del servizio app con bilanciamento del carico interno con il gateway applicazione di Azure
- Integrare le app Web con il gateway applicazione di Azure
- Scalabilità geografica distribuita con ambiente del servizio app