Condividi tramite

Architettura della Landing Zone di Azure API Management

Gestione API di Azure
Gateway applicazione di Azure
Funzioni di Azure
.NET

Le API sono diventate sempre più integrali per il modo in cui le organizzazioni e i clienti accedono ai servizi, sia all'interno dei sistemi interni che attraverso canali esterni. Internamente, le API facilitano l'accesso alle applicazioni line-of-business (LoB), alle soluzioni proprietarie e alle integrazioni dei partner. Esternamente, un numero crescente di organizzazioni si concentra sul miglioramento della produttività e sulla generazione di ricavi attraverso la monetizzazione delle API. Data questa tendenza, Azure API Management funge da elemento fondamentale nella governance standardizzata, nella pubblicazione e nella supervisione delle API sia per gli stakeholder interni che per gli stakeholder esterni.

Azure Application Gateway funge da checkpoint di sicurezza per le API. Invece di consentire agli utenti di connettersi direttamente tramite Internet, si instrada tutto il traffico attraverso un gateway applicazione. Questa configurazione aggiunge controlli di accesso aggiuntivi per proteggere le API. Con questo approccio, è possibile usare una singola istanza di Gestione API per supportare le API interne all'interno dell'organizzazione e le API esterne all'esterno dell'organizzazione, mantenendo al tempo stesso tutte le API esposte pubblicamente protette dietro il gateway.

Nota

Questa architettura funge da base per le linee guida per API Management in una zona di atterraggio Azure nel Cloud Adoption Framework per Azure.

Architettura

Il diagramma mostra un'architettura di base sicura per Gestione API.

Scaricare un file Visio di questa architettura.

Questa architettura presuppone che i criteri siano applicati dall'implementazione di riferimento della zona di destinazione Azure e che la struttura sia guidata verso il basso dal gruppo di gestione.

Flusso di lavoro

  • Gli indirizzi IP pubblici vengono assegnati a un gateway applicazione, che funge da punto di ingresso per il traffico esterno. Tale endpoint espone le API tramite un dominio personalizzato.

  • Il gateway applicativo viene distribuito nella propria subnet e protetto da policy di Web Application Firewall (WAF) per ispezionare e filtrare le richieste in ingresso.

  • Il traffico viene indirizzato dal gateway dell'applicazione all'API Management (Premium), che risiede in una subnet di API Management separata. L'istanza di Gestione API è configurata in modalità interna, che impedisce l'accesso pubblico diretto.

  • Gli endpoint privati vengono usati per connettere in modo sicuro la Gestione delle API ai server di applicazioni back-end esposti solo alla rete virtuale. API Management si connette periodicamente anche alle dipendenze, come ad esempio Azure Key Vault. In genere, tutta questa connettività privata avviene tramite gli endpoint in una subnet di endpoint privato dedicata.

  • Log Analytics aree di lavoro e Application Insights sono integrate per la registrazione, il monitoraggio e la telemetria.

Componenti

  • Gestione API è un servizio gestito che consente di gestire i servizi in ambienti ibridi e multicloud. Fornisce controllo e sicurezza per l'osservabilità e l'utilizzo delle API da parte di utenti interni ed esterni. In questa architettura, la gestione delle API funge da facciata per astrarre l'architettura back-end.

  • Application Gateway è un servizio gestito che funge da load balancer di layer 7 e WAF. Il Application Gateway protegge l'istanza interna di gestione delle API, che consente l'uso di modalità sia interne che esterne. In questa architettura, la Gestione delle API protegge le API e l'Application Gateway aggiunge funzionalità complementari, come il WAF.

  • Zone DNS (Domain Name System) private sono una funzionalità di Azure DNS che consente di gestire e risolvere i nomi di dominio all'interno di una rete virtuale senza dover implementare una soluzione DNS personalizzata. Una zona DNS privata può essere allineata a una o più reti virtuali tramite collegamenti di rete virtuale. In questa architettura è necessaria una zona DNS privata per garantire una risoluzione dei nomi corretta all'interno della rete virtuale.

  • Application Insights è un servizio estendibile di gestione delle prestazioni delle applicazioni che consente agli sviluppatori di rilevare anomalie, diagnosticare i problemi e comprendere i modelli di utilizzo. Application Insights offre la gestione e il monitoraggio estensibile delle prestazioni delle applicazioni per le applicazioni web live. Sono supportate varie piattaforme, tra cui .NET, Node.js, Java e Python. Supporta le app ospitate in Azure, in locale, in un ambiente ibrido o in altri cloud pubblici. In questa architettura Application Insights monitora i comportamenti dell'applicazione distribuita.

  • Log Analytics è uno strumento di analisi dei dati basato sul cloud che consente di modificare ed eseguire query di log sui dati nei log Azure Monitor, facoltativamente dall'interno del portale di Azure. Gli sviluppatori possono eseguire query semplici per recuperare i record o usare Log Analytics per l'analisi avanzata, quindi visualizzare i risultati. In questa architettura Log Analytics aggrega tutti i log delle risorse della piattaforma per l'analisi e la creazione di report.

  • Azure Key Vault è un servizio cloud che archivia e accede in modo sicuro ai segreti. Questi segreti variano da chiavi API e password a certificati e chiavi crittografiche. In questa architettura, Key Vault archivia i certificati SSL (Secure Sockets Layer) usati dal gateway applicazione.

Alternative

Per i servizi back-end a cui si connette l'istanza di Gestione API, sono disponibili diverse alternative:

  • Azure App Service è un servizio basato su HTTP completamente gestito che compila, distribuisce e ridimensiona le app Web. Supporta .NET, .NET Core, Java, Ruby, Node.js, PHP e Python. Le applicazioni possono essere eseguite e ridimensionate in ambienti basati su Windows o Linux.

  • Azure Kubernetes Service (AKS) è un'offerta Kubernetes gestita che offre cluster completamente gestiti. Consente un'integrazione continua e una consegna continua (CI/CD) integrate, insieme a una governance e sicurezza integrate.

  • Azure Logic Apps è una piattaforma basata sul cloud che crea ed esegue flussi di lavoro automatizzati. Per altre informazioni, vedere un'architettura di riferimento di esempio.

  • Azure Container Apps è un servizio contenitore serverless completamente gestito che consente di eseguire microservizi e applicazioni in contenitori in una piattaforma serverless.

Per le distribuzioni con più aree, è consigliabile usare Azure Front Door per fornire accesso rapido, affidabile e sicuro tra gli utenti e il contenuto Web statico e dinamico delle applicazioni.

Per altri esempi di come il gateway applicazione può proteggere le API, vedere Proteggere le API con il gateway applicazione e Gestione API.

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 maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

  • Distribuire almeno due unità di scala di Gestione API distribuite in due o più zone di disponibilità in ogni area. Monitorare le metriche della capacità ed effettuare il provisioning di unità di capacità sufficienti in modo che sia possibile continuare a funzionare anche se le unità in una zona di disponibilità vengono perse.

  • È consigliabile usare il livello Premium perché supporta le zone di disponibilità e le distribuzioni con più aree. Questa funzionalità significa che i servizi possono continuare a essere eseguiti anche in caso di arresto di un'area o di una zona. Queste funzionalità consentono di proteggere l'applicazione durante interruzioni o emergenze.

  • Per il ripristino di emergenza, configurare Gestione API con un'identità gestita assegnata dall'utente anziché un'identità assegnata dal sistema. Se si ridistribuisce o si elimina la risorsa, l'identità e le relative autorizzazioni rimangono invariate, in modo da poter ripristinare l'accesso più facilmente. Usare Azure Pipelines per automatizzare i backup. Decidere se è necessario distribuire i servizi in più aree per migliorare l'affidabilità.

  • Il peering di rete virtuale offre prestazioni elevate all'interno di un'area, ma ha un limite di scalabilità di 500 reti. Se è necessario connettere più carichi di lavoro, usare una progettazione hub-spoke o Azure Virtual WAN.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

  • I criteri di convalida di Gestione API convalidano le richieste API e le risposte rispetto a uno schema OpenAPI. Queste funzionalità non sono una sostituzione di un WAF, ma possono fornire una protezione aggiuntiva da alcune minacce. L'aggiunta di criteri di convalida può avere implicazioni sulle prestazioni, pertanto è consigliabile usare i test di carico delle prestazioni per valutarne l'impatto sulla velocità effettiva dell'API.

  • Microsoft Defender per le API fornisce protezione, rilevamento e risposta completi del ciclo di vita per le API pubblicate in Gestione API. Una funzionalità chiave consiste nel rilevare gli sfruttamenti delle 10 principali vulnerabilità dell'API del progetto Open Web Application Security Project (OWASP), tramite osservazioni di anomalie durante l'esecuzione, utilizzando rilevamenti basati su apprendimento automatico e su regole.

  • Le aree di lavoro di Gestione API consentono di organizzare e isolare le API. Questo approccio semplifica il controllo degli utenti autorizzati ad accedervi e gestirli. Ogni area di lavoro può avere un proprio set di autorizzazioni, quindi è possibile limitare l'accesso solo alle persone o ai team che ne hanno bisogno. Questa separazione riduce il rischio di modifiche accidentali o accessi non autorizzati e supporta un ambiente API più sicuro.

  • Usare i segreti Key Vault come valori denominati nei criteri di Gestione API per proteggere le informazioni riservate nei criteri di Gestione API.

  • Usare il gateway applicazione per l'accesso esterno di un'istanza di Gestione API interna per proteggere l'istanza di Gestione API, difendersi da exploit e vulnerabilità comuni di applicazioni Web tramite WAF e abilitare la connettività ibrida.

  • Distribuire il gateway di Gestione API in una rete virtuale per supportare la connettività ibrida e una maggiore sicurezza.

  • Il peering di rete virtuale migliora le prestazioni in un'area e abilita la comunicazione privata tra reti virtuali.

  • Quando si usa un WAF, si introduce un livello che controlla il traffico in ingresso per individuare comportamenti dannosi. Questa protezione consente di bloccare le minacce comuni, ad esempio SQL injection e scripting tra siti. Il gateway applicativo e la protezione dal distributed denial-of-service (DDoS) consentono di evitare che traffico e connessioni eccessivi sopraffacciano l'istanza di Gestione delle API. Per ulteriori informazioni, vedere Proteggere le API utilizzando il gateway applicativo e Gestione API.

  • Gli endpoint privati per Azure Functions consentono di connettersi in modo sicuro alle app per le funzioni tramite un indirizzo IP privato all'interno della rete virtuale. Questa configurazione impedisce l'esposizione delle funzioni alla rete Internet pubblica, riducendo così il rischio di accesso non autorizzato. In questa architettura gli endpoint privati assicurano che solo le risorse attendibili all'interno della rete possano accedere Azure Functions.

Gestione dei criteri di Gestione API dietro un proxy inverso

Il gateway applicazione con Web Application Firewall (WAF) viene posizionato davanti alla gestione API e gestisce tutto il traffico API prima di raggiungere l'istanza interna di Gestione API. Lo scopo consiste nell'aggiungere un livello di sicurezza a livello di edge che controlla, filtra e instrada le richieste client, mentre Gestione API è incentrata sulla governance api, la trasformazione e l'integrazione back-end.

Tuttavia, questa topologia a più livelli presenta implicazioni comportamentali per determinati criteri di Gestione API: quando la terminazione TLS, le decisioni di routing o le trasformazioni di intestazione/connessione si verificano al limite del gateway applicazione, il motore dei criteri di Gestione API potrebbe non visualizzare i dettagli della richiesta client originale previsti. Ciò può comportare un comportamento diverso rispetto a quando Gestione API viene esposto direttamente. Per esempio:

  • Filtro basato su IP client: i criteri, come ip-filter in cui è possibile consentire o negare il traffico in base agli indirizzi IP di origine, adesso vedranno l'indirizzo IP privato dell'Application Gateway come origine, non l'indirizzo del client effettivo. Di conseguenza, i ip-filter criteri devono essere pianificati attentamente e gestiti per garantire che il traffico corretto venga filtrato.

  • Presupposti di ordinamento e contesto dei criteri: i criteri di Gestione API prevedono l'esecuzione su richieste con determinate intestazioni, nomi host o caratteristiche di richiesta. Se il Gateway applicazione riscrive le intestazioni dei header (per il routing, i domini personalizzati o l'offload SSL), il contesto su cui si basano le policy di Gestione delle API downstream potrebbe non corrispondere a quanto definito in tali policy. Ciò può causare il disallineamento dei criteri di routing, della convalida o della logica di trasformazione all'interno della Gestione delle API con l'intenzione del cliente.

Il gateway applicativo e la Gestione delle API diventano due livelli di applicazione delle regole, e la visualizzazione delle richieste in ingresso da parte della Gestione delle API è un passo rimosso dal contesto originale del cliente. È necessario evitare di usare criteri in Gestione API che dipendono dagli attributi client non elaborati, a meno che tali attributi non vengano mantenuti end-to-end e che potrebbero dover creare criteri personalizzati basati sui dati disponibili nella richiesta HTTP.

Per altre indicazioni su come mantenere i dati, ad esempio le intestazioni host, vedere Mantenere il nome host HTTP originale tra un proxy inverso e l'applicazione Web back-end.

Ottimizzazione dei 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 l'ottimizzazione dei costi.

  • Questa distribuzione usa il piano Premium per supportare le funzionalità della zona di disponibilità e della rete virtuale. Se non sono necessarie istanze dedicate, è anche possibile usare Flex Consumption, che supporta sia l'accesso alla rete che le zone di disponibilità. Esaminare il calcolatore dei prezzi per questa implementazione.

  • Per la prova dei concetti o dei prototipi, è consigliabile usare altri livelli di Gestione API, ad esempio Developer o Standard.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo mantengono in esecuzione nell'ambiente di produzione. Per ulteriori informazioni, vedere Lista di controllo per la revisione del design per l'Eccellenza Operativa.

  • Rappresentare le configurazioni di Gestione API come modelli di Azure Resource Manager e adottare un approccio IaC (Infrastructure as Code).

  • Usare un processo CI/CD per gestire, versionare e aggiornare le configurazioni della gestione delle API.

  • Creare sondi di integrità personalizzati per aiutare a convalidare lo stato dell'istanza di Gestione API. Usare l'URL /status-0123456789abcdef per creare un endpoint di integrità comune per il servizio Gestione API nel gateway applicativo.

  • I certificati aggiornati nel Key Vault si ruotano automaticamente in API Management, riflettendo le modifiche entro quattro ore.

  • Se si usa uno strumento DevOps, ad esempio Azure DevOps o GitHub, gli agenti ospitati nel cloud o gli strumenti di esecuzione operano su Internet pubblico. Poiché Gestione API in questa architettura è impostata su una rete interna, è necessario usare un agente DevOps che ha accesso alla rete virtuale. L'agente DevOps consente di distribuire criteri e altre modifiche alle API nell'architettura. È possibile usare questi modelli CI/CD per separare il processo in parti in modo che i team di sviluppo possano distribuire le modifiche per ogni API. I runner DevOps avviano i modelli per gestire queste singole distribuzioni.

Distribuire questo scenario

Questa architettura è disponibile in GitHub. Contiene tutti i file IaC necessari e le istruzioni di deployment.

Collaboratori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autori principali:

Per visualizzare i profili di LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi