Modifica

Condividi tramite

Applicazioni Web gestite in modo sicuro

Servizio app di Azure
Gateway applicazione di Azure
database SQL di Azure
Gateway VPN di Azure
Web application firewall di Azure

Questo articolo offre una panoramica della distribuzione di applicazioni sicure tramite l'Ambiente del servizio app. Per limitare l'accesso alle applicazioni da Internet, si usano il servizio gateway applicazione e Azure Web Application Firewall. 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 app con bilanciamento del carico interno (ILB).

Architettura

Diagramma con l'architettura dello scenario di esempio per secure ILB ambiente del servizio app Deployment.

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 dedicato completamente isolato per l'esecuzione 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 di servizio app isolato, di conseguenza l'applicazione viene eseguita in un ambiente privato e dedicato in un data center di Azure usando macchine virtuali della serie DV2 con processori più veloci, archiviazione SSD e un rapporto memoria-core raddoppiato rispetto al livello Standard.
  • L'app Web e l'app per le API del servizio app di Azure ospitano applicazioni Web e API conformi ai principi REST. 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 e 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 è 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. È anche possibile stabilire connessioni 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 consente ai team di collaborare nel corso di numerosi sprint, usando funzionalità che supportano lo sviluppo agile e di creare pipeline di conversione e di versione.
  • È stata creata una VM di compilazione di Azure per consentire all'agente installato di eseguire il pull della rispettiva build e distribuire l'app Web nell'ambiente del servizio app.

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 è basato prevalentemente su Windows e i carichi di lavoro sono basati principalmente su .NET Framework e non si intende ancora valutare la possibilità di passare a un'architettura basata su .NET Core, usare Service Fabric per supportare e distribuire contenitori 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. È 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 costituisce una valida alternativa. Questo servizio offre una piattaforma per eseguire altri modelli di dati come MongoDB, Cassandra, dati Graph o un semplice archivio tabelle.

Considerazioni

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 di creazione di certificati 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 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 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 server DNS oppure usare le zone private di DNS di Azure.

Disponibilità

Scalabilità

Sicurezza

Resilienza

Distribuire lo scenario

Per distribuire questo scenario, è possibile seguire il tutorial dettagliato 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.

Prezzi

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 a livello di produzione minimo che serve alcune 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 indicativi di una distribuzione di medie dimensioni. 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 su larga scala, nell'ordine di milioni di utenti al mese, con il trasferimento di 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.

Collaboratori

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

Autore principale:

  • Faisal Mustafa | Senior Customer Engineer

Passaggi successivi