Condividi tramite

Rete per carichi di lavoro SaaS in Azure

  • Articolo

La rete fornisce il backbone per il modo in cui i clienti accedono all'applicazione SaaS e consentono la comunicazione tra i componenti della soluzione. Il modo in cui si progetta la rete ha un effetto diretto sulla sicurezza, sulle operazioni, sui costi, sui costi, sulle prestazioni e sull'affidabilità della soluzione. Un approccio strutturato alla strategia di rete diventa ancora più importante man mano che l'ambiente cloud cresce.

Decidere una strategia e una topologia di distribuzione di rete

Le soluzioni SaaS hanno requisiti di rete univoci. Man mano che si esegue l'onboarding di più clienti e l'aumento dell'utilizzo, i requisiti di rete cambiano. La gestione della crescita può essere complessa a causa di risorse limitate, ad esempio intervalli di indirizzi IP. La progettazione della rete influisce sulla sicurezza e sull'isolamento dei clienti. La pianificazione della strategia di rete consente di gestire la crescita, migliorare la sicurezza e ridurre la complessità operativa.

Considerazioni relative alla progettazione

  • Pianificare la strategia di distribuzione di rete in base al modello di tenancy. Decidere se le risorse di rete verranno condivise tra i clienti, dedicate a un singolo cliente o a una combinazione. Questa scelta influisce sulle funzionalità, la sicurezza e l'isolamento dei clienti dell'applicazione.

    È comune condividere risorse di rete, ad esempio reti virtuali e profili frontdoor di Azure, tra più clienti. Questo approccio riduce i costi e il sovraccarico operativo. Semplifica anche la connettività. È possibile connettere facilmente le risorse di un cliente con risorse condivise, ad esempio account di archiviazione condivisi o un piano di controllo.

    Tuttavia, potrebbero essere necessarie risorse di rete dedicate per ogni cliente per stabilire sicurezza e conformità elevate. Ad esempio, per supportare un livello elevato di segmentazione di rete tra i clienti, si usano reti virtuali come limite. Le risorse dedicate potrebbero essere necessarie quando il numero di risorse di rete in tutti i clienti supera la capacità di una singola rete condivisa.

    Pianificare il numero di risorse di rete necessarie per ogni cliente considerando i requisiti immediati e futuri. I requisiti dei clienti e i limiti delle risorse di Azure potrebbero forzare risultati specifici. Risorse diverse potrebbero richiedere strategie di distribuzione diverse, ad esempio l'uso di reti separate per il peering di rete virtuale con reti virtuali di Azure di proprietà del cliente.

    Per altre informazioni sulla condivisione delle risorse in una soluzione SaaS, vedere Organizzazione delle risorse per carichi di lavoro SaaS.

  • Informazioni sulle topologie di rete. Le topologie di rete in genere rientrano in tre categorie:

    • Rete flat: una singola rete isolata con subnet per la segmentazione. Adatto quando si dispone di una singola applicazione multi-tenant con un layout di rete semplice. Le reti flat possono raggiungere i limiti delle risorse e richiedere più reti quando si ridimensionano, aumentando il sovraccarico e i costi. Se si prevede di ospitare più applicazioni o di usare indicatori di distribuzione dedicati all'interno della stessa rete virtuale, potrebbe essere necessario un layout di rete complesso.

    • Hub e spoke: una rete hub centralizzata con peering a reti spoke isolate. Adatto per scalabilità elevata e isolamento dei clienti, perché ogni cliente o applicazione ha un proprio spoke, comunicando solo con l'hub. È possibile distribuire rapidamente più spoke in base alle esigenze in modo che le risorse nell'hub possano essere usate da tutti gli spoke. La comunicazione transitiva o spoke-to-spoke tramite l'hub è disabilitata per impostazione predefinita, che consente di mantenere l'isolamento dei clienti nelle soluzioni SaaS.

    • Nessuna rete: usata per i servizi PaaS di Azure in cui è possibile ospitare carichi di lavoro complessi senza distribuire reti virtuali. Ad esempio, app Azure Servizio consente l'integrazione diretta con altri servizi PaaS tramite la rete backbone di Azure. Anche se questo approccio semplifica la gestione, limita la flessibilità nella distribuzione dei controlli di sicurezza e la possibilità di ottimizzare le prestazioni. Questo approccio può essere adatto per le applicazioni native del cloud. Man mano che la soluzione si evolve, aspettarsi di passare a una topologia hub-spoke nel tempo.

      Compromesso: complessità e sicurezza. L'avvio senza un limite di rete definito può ridurre il carico operativo della gestione di componenti di rete come gruppi di sicurezza, spazio indirizzi IP e firewall. Tuttavia, un perimetro di rete è essenziale per la maggior parte dei carichi di lavoro. In assenza di controlli di sicurezza di rete, affidarsi alla gestione avanzata delle identità e degli accessi per proteggere il carico di lavoro da traffico dannoso.

  • Comprendere in che modo l'architettura in più aree influisce sulle topologie di rete. In un'architettura in più aree che usano reti virtuali, la maggior parte delle risorse di rete viene distribuita separatamente in ogni area, perché i firewall, i gateway di rete virtuale e i gruppi di sicurezza di rete non possono essere condivisi tra aree.

Suggerimenti per la progettazione

Elemento consigliato Vantaggio
Decidere quali componenti di rete sono condivisi e quali componenti sono dedicati al cliente.

Condividere le risorse addebitate per ogni istanza, ad esempio Firewall di Azure, Azure Bastion e Frontdoor di Azure.		 Esperienza di supporto bilanciato tra i requisiti di sicurezza e isolamento, riducendo al contempo i costi e il carico operativo.
Iniziare con una topologia flat o nessun approccio di rete.

Prima di tutto esaminare i requisiti di sicurezza, poiché questi approcci offrono controlli di isolamento e traffico limitati.		 È possibile ridurre la complessità e il costo della soluzione usando topologie di rete più semplici.
Prendere in considerazione le topologie hub-spoke per esigenze complesse o quando si distribuiscono reti virtuali dedicate per cliente. Usare l'hub per ospitare risorse di rete condivise tra reti dei clienti. È possibile ridimensionare più facilmente e migliorare l'efficienza dei costi condividendo le risorse tramite la rete hub.

Progettare un perimetro di rete sicuro

Il perimetro di rete stabilisce il limite di sicurezza tra l'applicazione e altre reti, tra cui Internet. Documentando il perimetro di rete, è possibile distinguere tra diversi tipi di flussi di traffico:

  • Traffico in ingresso, che arriva alla rete da un'origine esterna.
  • Traffico interno, che passa tra i componenti all'interno della rete.
  • Traffico in uscita, che lascia la rete.

Ogni flusso comporta rischi e controlli diversi. Ad esempio, sono necessari più controlli di sicurezza per controllare ed elaborare il traffico in ingresso.

Importante

Come procedura consigliata generale, seguire sempre un approccio zero trust. Assicurarsi che tutto il traffico sia controllato e controllato, incluso il traffico interno.

I clienti potrebbero anche avere requisiti di conformità specifici che influenzano l'architettura. Ad esempio, se hanno bisogno di conformità SOC 2, devono implementare vari controlli di rete, tra cui un firewall, un web application firewall e gruppi di sicurezza di rete, per soddisfare i requisiti di sicurezza. Anche se non è necessario conformarsi immediatamente, considerare questi fattori di estendibilità durante la progettazione dell'architettura.

Fare riferimento a SE:06 Recommendations for networking and connectivity (Consigli su SE:06 per la rete e la connettività)

Considerazioni relative alla progettazione

  • Proteggere e gestire il traffico in ingresso. Esaminare questo traffico per individuare le minacce in ingresso.

    I firewall consentono di bloccare indirizzi IP dannosi e completare analisi avanzate, per proteggersi dai tentativi di intrusione. Tuttavia, i firewall possono essere costosi. Valutare i requisiti di sicurezza per determinare se è necessario un firewall.

    Le applicazioni Web sono vulnerabili ad attacchi comuni, ad esempio SQL injection, scripting tra siti e altre vulnerabilità principali di OWASP. Web application firewall di Azure protegge da tali attacchi ed è integrato con gateway applicazione e Frontdoor di Azure. Esaminare i livelli per questi servizi per comprendere quali funzionalità waf sono in quali prodotti.

    Gli attacchi DDoS rappresentano un rischio per le applicazioni con connessione Internet. Azure offre un livello di protezione di base senza costi. Protezione DDoS di Azure offre protezione avanzata apprendendo i modelli di traffico e modificando le protezioni di conseguenza, anche se sono a un costo. Se si usa Frontdoor, sfruttare le funzionalità DDoS predefinite.

    Oltre alla sicurezza, è anche possibile modificare il traffico in ingresso per migliorare le prestazioni dell'applicazione, usando la memorizzazione nella cache e il bilanciamento del carico.

    Prendere in considerazione l'uso di un servizio proxy inverso come Frontdoor di Azure per la gestione globale del traffico HTTP(S). In alternativa, usare gateway applicazione o altri servizi di Azure per il controllo del traffico in ingresso. Per altre informazioni sulle opzioni di bilanciamento del carico in Azure, vedere Opzioni di bilanciamento del carico.

  • Proteggere il traffico interno. Assicurarsi che il traffico tra l'applicazione e i relativi componenti sia sicuro per impedire l'accesso dannoso. Proteggere queste risorse e migliorare le prestazioni usando il traffico interno anziché il routing su Internet. collegamento privato di Azure viene comunemente usato per connettersi alle risorse di Azure tramite un indirizzo IP interno all'interno della rete. Per alcuni tipi di risorse, gli endpoint di servizio possono essere un'alternativa più conveniente. Se si abilita la connettività Internet pubblica per le risorse, comprendere come limitare il traffico usando indirizzi IP e identità dell'applicazione, ad esempio le identità gestite.

  • Proteggere il traffico in uscita. In alcune soluzioni esaminare il traffico in uscita per evitare l'esfiltrazione dei dati, in particolare per la conformità alle normative e i clienti aziendali. Usare i firewall per gestire ed esaminare il traffico in uscita, bloccando le connessioni a posizioni non autorizzate.

  • Pianificare la scalabilità orizzontale della connettività in uscita e SNAT. L'esaurimento delle porte SNAT (Network Address Translation) di origine può influire sulle applicazioni multi-tenant. Queste applicazioni richiedono spesso connessioni di rete distinte per ogni tenant e la condivisione delle risorse tra i clienti aumenta il rischio di esaurimento SNAT man mano che aumenta la base clienti. È possibile ridurre l'esaurimento SNAT usando gateway NAT di Azure, firewall come Firewall di Azure o una combinazione dei due approcci.

Suggerimenti per la progettazione

Elemento consigliato Vantaggio
Gestire un catalogo degli endpoint di rete esposti a Internet. Acquisire dettagli, ad esempio indirizzo IP (se statico), nome host, porte, protocolli usati e giustificazione per le connessioni.

Documentare come si prevede di proteggere ogni endpoint.		 Questo elenco costituisce la base della definizione del perimetro, consentendo di prendere decisioni esplicite sulla gestione del traffico attraverso la soluzione.
Comprendere le funzionalità del servizio di Azure per limitare l'accesso e migliorare la protezione.

Ad esempio, l'esposizione degli endpoint dell'account di archiviazione ai clienti richiede controlli aggiuntivi, ad esempio firme di accesso condiviso, firewall dell'account di archiviazione e l'uso di account di archiviazione separati per uso interno ed esterno.		 È possibile selezionare i controlli che soddisfano le esigenze di sicurezza, costi e prestazioni.
Per le applicazioni basate su HTTP(S), usare un proxy inverso, ad esempio Frontdoor di Azure o gateway applicazione. I proxy inversi offrono un'ampia gamma di funzionalità per miglioramenti delle prestazioni, resilienza, sicurezza e per ridurre la complessità operativa.
Esaminare il traffico in ingresso usando un web application firewall.

Evitare di esporre risorse basate sul Web, ad esempio un servizio app o un servizio Azure Kubernetes (servizio Azure Kubernetes) direttamente a Internet.		 È possibile proteggere in modo più efficace le applicazioni Web da minacce comuni e ridurre l'esposizione complessiva della soluzione.
Proteggere l'applicazione da attacchi DDoS.

Usare Frontdoor di Azure o Protezione DDoS di Azure a seconda dei protocolli usati dagli endpoint pubblici.		 Proteggere la soluzione da un tipo comune di attacco.
Se l'applicazione richiede connettività in uscita su larga scala, usare il gateway NAT o un firewall per fornire porte SNAT aggiuntive. È possibile supportare livelli più elevati di scalabilità.

Connettività tra reti

Per alcuni scenari, potrebbe essere necessario connettersi alle risorse esterne ad Azure, ad esempio i dati all'interno della rete privata o degli asset di un cliente in un provider di servizi cloud diverso in una configurazione multicloud. Queste esigenze possono complicare la progettazione della rete, richiedendo diversi approcci per implementare la connettività tra reti in base ai requisiti specifici.

Considerazioni relative alla progettazione

  • Identificare gli endpoint a cui l'applicazione necessita di connessione. L'applicazione potrebbe dover comunicare con altri servizi, ad esempio servizi di archiviazione e database. Documentare il proprietario, la posizione e il tipo di connettività. È quindi possibile scegliere il metodo appropriato per connettersi a questi endpoint. Gli approcci comuni includono:

    Posizione della risorsa Proprietario Opzioni di connettività da considerare
    Azure Customer
    • Endpoint privato (nei tenant di Microsoft Entra ID)
    • Peering di rete virtuale (tra i tenant di Microsoft Entra ID)
    • Endpoint di servizio (nei tenant di Microsoft Entra ID)
    Altro provider di servizi cloud ISV o cliente
    • VPN da sito a sito
    • ExpressRoute
    • Internet
    Locale ISV o cliente
    • VPN da sito a sito
    • ExpressRoute
    • Internet

    • collegamento privato e endpoint privato. Fornire connettività sicura a varie risorse di Azure, inclusi i servizi di bilanciamento del carico interni per le macchine virtuali. Abilitano l'accesso privato alla soluzione SaaS per i clienti, anche se presentano considerazioni relative ai costi.

      Compromesso: sicurezza e costi. Il collegamento privato garantisce che il traffico rimanga all'interno della rete privata ed è consigliato per la connettività di rete tra i tenant di Microsoft Entra. Tuttavia, ogni endpoint privato comporta costi, che possono essere aggiunti in base alle esigenze di sicurezza. Gli endpoint di servizio possono essere un'alternativa conveniente, mantenendo il traffico sulla rete backbone Microsoft fornendo al tempo stesso un certo livello di connettività privata.

    • Endpoint servizio. Instrada il traffico alle risorse PaaS tramite la rete backbone di Microsoft, proteggendo la comunicazione da servizio a servizio. Possono essere convenienti per applicazioni a larghezza di banda elevata, ma richiedono la configurazione e la gestione degli elenchi di controllo di accesso per la sicurezza. Il supporto per gli endpoint di servizio nei tenant di Microsoft Entra ID varia in base al servizio di Azure. Controllare la documentazione del prodotto per ogni servizio usato.

    • Il peering di rete virtuale connette due reti virtuali, consentendo alle risorse in una rete di accedere agli indirizzi IP nell'altro. Facilita la connettività alle risorse private in una rete virtuale di Azure. L'accesso può essere gestito usando i gruppi di sicurezza di rete, ma l'applicazione dell'isolamento può risultare complessa. È quindi importante pianificare la topologia di rete in base a specifiche esigenze dei clienti.

    • Le reti private virtuali (VPN) creano un tunnel sicuro attraverso Internet tra due reti, inclusi i provider di servizi cloud e le posizioni locali. Le VPN da sito a sito usano appliance di rete in ogni rete per la configurazione. Offrono un'opzione di connettività a basso costo, ma richiedono la configurazione e non garantiscono una velocità effettiva prevedibile.

    • ExpressRoute offre una connessione privata dedicata, ad alte prestazioni, tra Azure e altri provider di servizi cloud o reti locali. Garantisce prestazioni prevedibili ed evita il traffico Internet, ma comporta costi più elevati e richiede una configurazione più complessa.

  • Pianificare in base alla destinazione. Potrebbe essere necessario connettersi alle risorse in tenant di ID Microsoft Entra diversi, soprattutto se la risorsa di destinazione si trova nella sottoscrizione di Azure di un cliente. Prendere in considerazione l'uso di endpoint privati, una VPN da sito a sito o tramite il peering di reti virtuali. Per altre informazioni, vedere Peering di reti virtuali in diversi tenant di Microsoft Entra ID.

    Per connettersi alle risorse ospitate in un altro provider di servizi cloud, è comune usare la connettività Internet pubblica, una VPN da sito a sito o ExpressRoute. Per altre informazioni, vedere Connettività ad altri provider di servizi cloud.

  • Comprendere gli effetti della connettività nella topologia di rete. Una rete virtuale di Azure può avere un solo gateway di rete virtuale, che può connettersi a più posizioni tramite VPN da sito a sito o ExpressRoute. Esistono tuttavia limiti al numero di connessioni attraverso un gateway e l'isolamento del traffico dei clienti può risultare complesso. Per più connessioni a posizioni diverse, pianificare la topologia di rete di conseguenza, possibilmente distribuendo una rete virtuale separata per ogni cliente.

  • Comprendere le implicazioni per la pianificazione degli indirizzi IP. Alcuni approcci di connettività forniscono automaticamente nat (Network Address Translation), evitando problemi con indirizzi IP sovrapposti. Tuttavia, il peering di rete virtuale e ExpressRoute non eseguono NAT. Quando si usano questi metodi, pianificare attentamente le risorse di rete e le allocazioni di indirizzi IP per evitare intervalli di indirizzi IP sovrapposti e garantire una crescita futura. La pianificazione degli indirizzi IP può essere complessa, soprattutto quando ci si connette a terze parti come i clienti, quindi considerare potenziali conflitti con gli intervalli IP.

  • Informazioni sulla fatturazione in uscita di rete. Azure in genere fattura il traffico di rete in uscita quando esce dalla rete Microsoft o si sposta tra aree di Azure. Quando si progettano soluzioni multi-area o multicloud, è importante comprendere le implicazioni sui costi. Le scelte dell'architettura, ad esempio l'uso di Frontdoor di Azure o ExpressRoute, possono influire sulla modalità di fatturazione del traffico di rete.

Suggerimenti per la progettazione

Elemento consigliato Vantaggio
Preferire approcci di rete privata per la connessione tra reti per assegnare priorità alla sicurezza.

Prendere in considerazione solo il routing su Internet dopo aver valutato le implicazioni relative alla sicurezza e alle prestazioni associate.		 Il traffico privato attraversa un percorso di rete protetto, che consente di ridurre molti tipi di rischi per la sicurezza.
Quando ci si connette alle risorse dei clienti ospitate negli ambienti azure, usare collegamento privato, endpoint di servizio o peering di rete virtuale. È possibile mantenere il traffico sulla rete Microsoft, che consente di ridurre i costi e la complessità operativa rispetto ad altri approcci.
Quando ci si connette tra provider di servizi cloud o reti locali, usare VPN da sito a sito o ExpressRoute. Queste tecnologie forniscono connessioni sicure tra provider.

Distribuire in ambienti di proprietà dei clienti

Il modello aziendale potrebbe richiedere l'hosting dell'applicazione o dei relativi componenti all'interno dell'ambiente Azure di un cliente. Il cliente gestisce la propria sottoscrizione di Azure e paga direttamente il costo delle risorse necessarie per eseguire l'applicazione. Il provider di soluzioni è responsabile della gestione della soluzione, ad esempio la distribuzione iniziale, l'applicazione della configurazione e la distribuzione degli aggiornamenti all'applicazione.

In tali situazioni, i clienti spesso portano la propria rete e distribuiscono l'applicazione in uno spazio di rete che definiscono. Le applicazioni gestite di Azure offrono funzionalità per facilitare questo processo. Per altre informazioni, vedere Usare una rete virtuale esistente con applicazioni gestite di Azure.

Considerazioni relative alla progettazione

  • Intervalli di indirizzi IP e conflitti. Quando i clienti distribuiscono e gestiscono le reti virtuali, sono responsabili della gestione dei conflitti di rete e del ridimensionamento. Tuttavia, è consigliabile prevedere diversi scenari di utilizzo dei clienti. Pianificare le distribuzioni in ambienti con spazio di indirizzi IP minimo usando gli indirizzi IP in modo efficiente ed evitare intervalli di indirizzi IP hardcoded per evitare sovrapposizioni con intervalli di clienti.

    In alternativa, distribuire una rete virtuale dedicata per la soluzione. È possibile usare collegamento privato o peering di rete virtuale per consentire ai clienti di connettersi alle risorse. Questi approcci sono descritti in Connettività tra reti. Se sono stati definiti punti di ingresso e uscita, valutare NAT come approccio per eliminare i problemi causati dalle sovrapposizioni degli indirizzi IP.

  • Fornire l'accesso alla rete a scopo di gestione. Esaminare le risorse distribuite negli ambienti dei clienti e pianificare come accedervi per monitorare, gestire o riconfigurarle. Quando le risorse vengono distribuite con indirizzi IP privati in un ambiente di proprietà del cliente, assicurarsi di avere un percorso di rete per raggiungerle dalla propria rete. Si consideri come facilitare le modifiche delle applicazioni e delle risorse, ad esempio il push di una nuova versione dell'applicazione o l'aggiornamento di una configurazione delle risorse di Azure.

    In alcune soluzioni è possibile usare le funzionalità fornite dalle applicazioni gestite di Azure, ad esempio l'accesso JITE e la distribuzione degli aggiornamenti alle applicazioni. Se è necessario un maggiore controllo, è possibile ospitare un endpoint all'interno della rete del cliente a cui può connettersi il piano di controllo, fornendo l'accesso alle risorse. Questo metodo richiede risorse e sviluppo di Azure aggiuntive per soddisfare i requisiti di sicurezza, operativi e prestazioni. Per un esempio di come implementare questo approccio, vedere Esempio di aggiornamento di applicazioni gestite di Azure.

Suggerimenti per la progettazione

Elemento consigliato Vantaggio
Usare applicazioni gestite di Azure per distribuire e gestire le risorse distribuite dal cliente. Le applicazioni gestite di Azure offrono una gamma di funzionalità che consentono di distribuire e gestire le risorse all'interno della sottoscrizione di Azure di un cliente.
Ridurre al minimo il numero di indirizzi IP usati nello spazio di rete virtuale del cliente. I clienti hanno spesso una disponibilità limitata degli indirizzi IP. Riducendo al minimo il footprint e separando il ridimensionamento dall'utilizzo degli indirizzi IP, è possibile ampliare il numero di clienti che possono usare la soluzione e abilitare livelli di crescita più elevati.
Pianificare l'accesso alla rete per gestire le risorse negli ambienti dei clienti, valutare il monitoraggio, le modifiche alla configurazione delle risorse e gli aggiornamenti delle applicazioni. È possibile configurare direttamente le risorse gestite.
Decidere se si vuole distribuire una rete virtuale dedicata o integrarla con la rete virtuale esistente di un cliente. Pianificando in anticipo, si garantisce di poter soddisfare i requisiti dei clienti per l'isolamento, la sicurezza e l'integrazione con gli altri sistemi.
Disabilitare l'accesso pubblico nelle risorse di Azure per impostazione predefinita. Preferisce l'ingresso privato laddove possibile. Si ridurrà l'ambito delle risorse di rete che l'utente e i clienti devono proteggere.

Risorse aggiuntive

La multi-tenancy è una metodologia aziendale di base per la progettazione di carichi di lavoro SaaS. Questi articoli forniscono altre informazioni relative alla progettazione di rete:

Passaggio successivo

Informazioni sulle considerazioni sulla piattaforma dati per l'integrità dei dati e le prestazioni per i carichi di lavoro SaaS in Azure.

Area di progettazione: dati per carichi di lavoro SaaS in Azure