Considerazioni sulla topologia di rete e sulla connettività per l'acceleratore di zona di destinazione servizio app
Questo articolo fornisce considerazioni sulla progettazione e consigli per la topologia di rete e la connettività che è possibile applicare quando si usa l'acceleratore di zona di destinazione del servizio app Azure. La rete è fondamentale per quasi tutto in una zona di destinazione.
Le considerazioni sulla topologia di rete e sulla connettività per questa architettura dipendono dai requisiti dei carichi di lavoro ospitati e dai requisiti di sicurezza e conformità dell'organizzazione.
Considerazioni relative alla progettazione
Quando si distribuisce una soluzione servizio app in Azure, è necessario prendere in considerazione attentamente i requisiti di rete per assicurarsi che l'applicazione funzioni correttamente. Esistono diversi fattori chiave da considerare quando si pianifica una distribuzione:
Determinare i requisiti di rete per l'applicazione.
- Traffico in ingresso. Se l'app fornisce servizi basati sul Web, ad esempio un sito Web o un'API, probabilmente deve essere in grado di ricevere traffico in ingresso da Internet. Per assicurarsi che l'app possa accettare connessioni in ingresso, è necessario configurarla per l'ascolto sulle porte appropriate.
- Accesso ad altre risorse di Azure. Potrebbe essere necessario che l'app sia in grado di accedere alle risorse in Azure, ad esempio gli account di archiviazione o i database, usando l'endpoint privato. Queste risorse potrebbero trovarsi all'interno di una rete virtuale di Azure o di altri servizi di Azure.
- SSL/TLS. Per proteggere la comunicazione tra l'app e i relativi utenti, è necessario abilitare la crittografia SSL/TLS. In questo modo si garantisce che il traffico tra l'app e i relativi utenti sia crittografato, che consente di proteggere le informazioni riservate dall'intercettazione da parte di terze parti.
- Restrizioni IP. A seconda dei requisiti, potrebbe essere necessario consentire o bloccare l'accesso all'app da indirizzi IP o intervalli specifici. In questo modo è possibile garantire una maggiore sicurezza e limitare l'accesso all'app a utenti o posizioni specifiche.
Scegliere un livello di piano servizio app. Usare i requisiti di rete dell'applicazione per determinare il livello appropriato per il piano di servizio app. È consigliabile esaminare i vari livelli di piano servizio app e le relative funzionalità per determinare quale sia più adatto alle proprie esigenze.
servizio app servizio multi-tenant
Una soluzione multi-tenant servizio app condivide un singolo indirizzo IP in ingresso e più indirizzi IP in uscita con altre risorse servizio app in una singola unità di distribuzione. Questi indirizzi IP possono cambiare per diversi motivi. Se sono necessari indirizzi IP in uscita coerenti per una soluzione di servizio app multi-tenant, è possibile configurare un gateway NAT o usare l'integrazione della rete virtuale.
Se è necessario un indirizzo IP dedicato per la soluzione servizio app, è possibile usare un indirizzo assegnato dall'app, far fronte all'istanza servizio app con un gateway applicazione (a cui è assegnato un indirizzo IP statico) o usare un certificato SSL basato su IP per assegnare un indirizzo IP dedicato all'app tramite la piattaforma servizio app.
Quando è necessario connettersi da una soluzione servizio app a servizi locali, privati o con restrizioni IP, tenere presente quanto segue:
- In una distribuzione di servizio app multi-tenant, una chiamata servizio app può provenire da un'ampia gamma di indirizzi IP. Potrebbe essere necessaria l'integrazione della rete virtuale.
- È possibile usare servizi come Gestione API e gateway applicazione alle chiamate proxy tra limiti di rete. Questi servizi possono fornire un indirizzo IP statico, se necessario.
È possibile usare un endpoint privato o pubblico per una distribuzione di servizio app multi-tenant. Quando si usa un endpoint privato, l'esposizione pubblica alla soluzione servizio app viene eliminata. Se è necessario che l'endpoint privato della soluzione servizio app sia accessibile tramite Internet, è consigliabile usare gateway applicazione per esporre la soluzione servizio app.
Una distribuzione di servizio app multi-tenant espone un set di porte. Non è possibile bloccare o controllare l'accesso a queste porte in una distribuzione di servizio app multi-tenant.
Pianificare correttamente le subnet per l'integrazione della rete virtuale in uscita e prendere in considerazione il numero di indirizzi IP necessari. L'integrazione della rete virtuale dipende da una subnet dedicata. Quando si effettua il provisioning di una subnet di Azure, Azure riserva cinque indirizzi IP. Un indirizzo IP viene usato dalla subnet di integrazione per ogni istanza del piano servizio app. Quando si ridimensiona l'app a quattro istanze, ad esempio, vengono usati quattro indirizzi IP. Quando si aumenta o si aumentano le prestazioni, lo spazio degli indirizzi richiesto viene raddoppiato per un breve periodo di tempo. Ciò influisce sulle istanze supportate disponibili per una determinata dimensione della subnet.
Poiché non è possibile modificare le dimensioni di una subnet dopo l'assegnazione, è necessario usare una subnet sufficientemente grande per supportare la scalabilità che l'app potrebbe raggiungere. Per evitare problemi con la capacità della subnet, usare /26 con 64 indirizzi per l'integrazione della rete virtuale.
Se ci si connette a una soluzione di servizio app multi-tenant ed è necessario un indirizzo in uscita dedicato, usare un gateway NAT.
ambiente del servizio app (tenant singolo)
- Scegliere una progettazione di rete ambiente del servizio app: servizio di bilanciamento del carico esterno o interno. Usare una distribuzione esterna quando è necessario l'accesso diretto da Internet. Usare una distribuzione del servizio di bilanciamento del carico interno per esporre l'accesso solo dall'interno della rete virtuale in cui viene distribuito il ambiente del servizio app. Quest'ultima distribuzione offre un altro livello di sicurezza e controllo sull'accesso di rete alle app.
- servizio app in un ambiente del servizio app ottiene indirizzi IP statici e dedicati per la comunicazione in ingresso e in uscita, per la durata del ambiente del servizio app.
- Quando è necessario connettersi da un ambiente del servizio app a servizi locali, privati o con restrizioni IP, il ambiente del servizio app viene eseguito nel contesto di una rete virtuale.
- È possibile scegliere le dimensioni della subnet quando si distribuisce un ambiente del servizio app. Non è possibile modificare le dimensioni in un secondo momento. Si consiglia una dimensione di /24, che ha 256 indirizzi e può gestire un ambiente del servizio app di dimensioni massime e qualsiasi esigenza di ridimensionamento.
Suggerimenti per la progettazione
Le procedure consigliate seguenti si applicano a qualsiasi distribuzione di servizio app.
- Connessione a una soluzione servizio app:
- Implementare un web application firewall di Azure davanti alla soluzione servizio app. Usare Frontdoor di Azure, gateway applicazione o un servizio partner per fornire questa protezione basata su OWASP. È possibile usare Frontdoor di Azure o gateway applicazione per una singola area o per entrambe le aree. Se è necessario il routing del percorso nell'area, usare gateway applicazione. Se è necessario il bilanciamento del carico in più aree e Web Application Firewall, usare Frontdoor di Azure.
- Usando un endpoint privato per servizio app, è possibile accedere all'app tramite un endpoint privato basato sulla rete anziché un endpoint pubblico basato su Internet. Quando si usa un endpoint privato, è possibile limitare l'accesso all'app solo agli utenti nella rete virtuale, che offre un altro livello di sicurezza per l'app, costi di uscita dei dati ridotti e prestazioni migliorate.
- Usare le restrizioni di accesso per assicurarsi che la soluzione servizio app possa essere raggiunta solo da posizioni valide. Ad esempio, se una distribuzione di servizio app multi-tenant ospita LE API e viene anteriore da Gestione API, configurare una restrizione di accesso in modo che la soluzione servizio app sia accessibile solo da Gestione API.
- Connessione da una soluzione servizio app:
- Dove è necessaria la connettività privata ad altri servizi di Azure, usare collegamento privato di Azure se è supportata dai servizi.
- Usare gli strumenti predefiniti per risolvere i problemi di rete.
- Evitare l'esaurimento delle porte SNAT usando pool di connessioni. La creazione ripetuta di connessioni allo stesso host e alla stessa porta può causare tempi di risposta lenti, errori 5xx intermittenti, timeout o problemi di connessione all'endpoint esterno.
- Seguire le raccomandazioni descritte nella sezione Sicurezza di rete della baseline di sicurezza di Azure per servizio app.
L'obiettivo della topologia di rete e delle considerazioni sulla connettività per l'acceleratore di zona di destinazione servizio app consiste nel fornire un modello di alto livello per implementare un ambiente scalabile e resiliente per la distribuzione di servizio app. Questo modello è incentrato sull'architettura di rete e sulla connettività e consente di configurare in modo rapido ed efficiente una zona di destinazione in Azure per ospitare servizio app soluzioni.