Le API sono diventate sempre più importanti nel modo in cui le aziende e i clienti accedono ai servizi, sia internamente che esternamente. Internamente, le API vengono usate per accedere alle applicazioni line-of-business, alle soluzioni predefinite e alle integrazioni di terze parti. Esternamente, più aziende cercano di essere produttivi e monetizzare le loro API. Tenendo presente questa tendenza, Gestione API diventa un componente centrale di un approccio standard di gestione, governance e pubblicazione di API sia a gruppi di destinatari interni che esterni.
Con l'aiuto di app Azure gateway, è ora possibile proteggere e limitare l'accesso delle API gestite tramite Azure Gestione API. Questo articolo descrive una soluzione in cui è possibile gestire le API interne ed esterne tramite una singola istanza di Gestione API. È possibile mantenere una postura sicura da esporre direttamente tramite Internet, ma è accessibile tramite un gateway applicazione.
Nota
Questa architettura viene usata come base delle linee guida per Azure Gestione API nelle zone di destinazione di Azure in Cloud Adoption Framework.
Architettura
Questo diagramma dell'architettura inizia con un riquadro che rappresenta l'ambito di una sottoscrizione, una zona DNS privato in cui verranno risolti i domini privati e l'ambito di una rete virtuale con nomi di rete virtuale APIM-CS. Nella parte superiore della sottoscrizione è presente una casella che indica che si tratta di un carico di lavoro locale. All'interno della casella è presente un'icona del server. Una pipe indica una connessione da sito a sito o Azure ExpressRoute si connette all'istanza di Gestione API nella sottoscrizione di Azure. Sette caselle più piccole aggiuntive sono all'interno della casella grande che mostra la sottoscrizione di Azure. Quattro delle caselle si trovano nella riga superiore e tre si trovano nella riga inferiore. Ogni casella singola rappresenta una subnet separata, con un gruppo di sicurezza di rete collegato. A sinistra è presente un indirizzo IP pubblico collegato al gateway di app Azure lication nella casella più a sinistra nella riga superiore. gateway applicazione si trova anche all'interno di una delle sette caselle più piccole, con la subnet denominata subnet app GW. A destra è presente un'altra casella contenente l'istanza di Gestione API, con la subnet denominata subnet di Gestione API. Accanto è la terza casella nella riga superiore, che contiene un endpoint privato per l'istanza di Funzioni di Azure nella subnet denominata PE subnet. La casella più a destra nella riga superiore è la subnet back-end che contiene App per le funzioni di Azure, il piano di servizio app Azure per la funzione e l'account di archiviazione associato all'app per le funzioni. Nella riga inferiore, a partire da sinistra, è una casella che contiene Azure Bastion nella subnet Bastion. La seconda casella contiene la macchina virtuale jumbox di gestione nella subnet Jump Box. L'ultima casella nella riga inferiore è l'agente DevOps contenuto nella subnet DevOps. Nella parte inferiore destra dell'immagine sono presenti tre risorse condivise con le rispettive icone. Da sinistra a destra sono riportate le caselle seguenti: insieme di credenziali delle chiavi, application insights e area di lavoro Log Analytics. Esistono due set di flussi di lavoro. Il primo flusso di lavoro è indicato in cerchi neri e l'altro flusso di lavoro è indicato in cerchi blu, che verrà spiegato nelle sezioni successive. Il flusso di lavoro nero indica l'accesso alle API disponibili esternamente. Il flusso inizia dall'utente che accede all'indirizzo IP pubblico. La freccia punta quindi alla direzione del gateway applicazione, dalla gateway applicazione all'endpoint privato e dall'endpoint privato all'app per le funzioni. Il flusso di lavoro blu inizia da un server locale, con una freccia che punta all'istanza di Gestione API, tramite un'icona della pipeline che indica una connessione da sito a sito o tramite ExpressRoute. Il resto del flusso è identico a quello descritto in precedenza: da Gestione API a endpoint privato e dall'endpoint privato alla funzione di Azure.
Questa architettura presuppone che i criteri siano applicati dall'acceleratore di zona di destinazione di Azure e che la struttura sia orientata verso il basso dal gruppo di gestione.
Scaricare un file di Visio di questa architettura.
Workflow
Scenario ibrido (cerchi blu)
Questo scenario richiede una connessione da sito a sito o Azure ExpressRoute all'ambiente locale.
- Un'applicazione locale richiede l'accesso a un'API interna gestita tramite Azure Gestione API.
- Gestione API si connette alle API back-end ospitate in Funzioni di Azure. Questa connessione avviene tramite un endpoint privato, disponibile tramite il piano Funzioni di Azure Premium ed è ospitato nella propria subnet.
- L'endpoint privato accede in modo sicuro all'API interna ospitata in Funzioni di Azure.
Scenario di accesso esterno (cerchi neri)
- Un'applicazione esterna accede a un indirizzo IP pubblico o a un FQDN personalizzato, collegato al gateway di app Azure lication.
- gateway applicazione funge da web application firewall, che richiede certificati PFX per la terminazione SSL.
- Gestione API si connette alle API back-end ospitate in Funzioni di Azure tramite un endpoint privato. Questo endpoint è disponibile tramite il piano Funzioni di Azure Premium ed è ospitato nella propria subnet.
- L'endpoint privato accede in modo sicuro all'API disponibile esternamente ospitata in Funzioni di Azure.
Componenti
L'architettura usa i componenti seguenti:
Azure Gestione API è un servizio gestito che consente di gestire i servizi in ambienti ibridi e multi-cloud. Gestione API funge da facciata per astrarre l'architettura back-end e fornisce controllo e sicurezza per l'osservabilità e l'utilizzo delle API per gli utenti interni ed esterni.
Funzioni di Azure è una soluzione serverless che consente di concentrarsi maggiormente sui blocchi di codice che possono essere eseguiti con una gestione minima dell'infrastruttura. Le funzioni possono essere ospitate in vari piani di hosting, mentre questa architettura di riferimento usa il piano Premium, a causa dell'uso di endpoint privati.
gateway app Azure lication è un servizio gestito che funge da servizio di bilanciamento del carico di livello 7 e web application firewall. In questo scenario, il gateway applicazione protegge l'istanza di Gestione API interna, che consente di usare la modalità interna ed esterna.
Le zone DNS di Azure DNS privato consentono di gestire e risolvere i nomi di dominio all'interno di una rete virtuale, senza dover implementare una soluzione DNS personalizzata. Una zona DNS privato può essere allineata a una o più reti virtuali tramite collegamenti di rete virtuale. A causa del Funzioni di Azure esposto su un endpoint privato usato da questa architettura di riferimento, è necessario usare una zona DNS privata.
Application Insights di Monitoraggiodi Azure consente agli sviluppatori di rilevare anomalie, diagnosticare i problemi e comprendere i modelli di utilizzo. Application Insights offre la gestione e il monitoraggio delle prestazioni applicative per le app Web live. Sono supportate diverse 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. Application Insights è incluso nell'ambito di questa architettura di riferimento per monitorare i comportamenti dell'applicazione distribuita.
Log Analytics di Monitoraggiodi Azure consente di modificare ed eseguire query di log con i dati nei log di Monitoraggio di Azure, facoltativamente dall'interno del portale di Azure. Gli sviluppatori possono eseguire query semplici per un set di record o usare Log Analytics per eseguire analisi avanzate. Possono quindi visualizzare i risultati. Log Analytics è configurato come parte di questa architettura di riferimento per aggregare tutti i log di monitoraggio per altre analisi e report.
Azure Macchine virtuali è una risorsa di elaborazione che può essere usata per ospitare molti carichi di lavoro diversi. In questa architettura di riferimento, le macchine virtuali vengono usate per fornire un server jumpbox di gestione, nonché un host per l'agente DevOps o gitHub runner.
Azure Key Vault è un servizio cloud che archivia e accede in modo sicuro ai segreti, che vanno dalle chiavi API e password ai certificati e alle chiavi crittografiche. Questa architettura di riferimento usa Azure Key Vault per archiviare i certificati SSL usati dal gateway applicazione.
Azure Bastion è un servizio distribuita come piattaforma di cui viene effettuato il provisioning all'interno della rete virtuale dello sviluppatore. Offre connettività RDP/SSH sicura e ininterrotta alle macchine virtuali dello sviluppatore dal portale di Azure, tramite TLS. Con Azure Bastion, le macchine virtuali non richiedono più un indirizzo IP pubblico per connettersi tramite RDP/SSH. Questa architettura di riferimento usa Azure Bastion per accedere all'agente DevOps o al server di esecuzione GitHub o al server jump box di gestione.
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é la 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. Questi possono essere usati per suddividere il processo e consentire ai team di sviluppo di distribuire le modifiche, in base all'API. Vengono eseguiti dagli strumenti di esecuzione DevOps.
Alternative
Per i servizi back-end a cui si connette l'istanza di Gestione API, sono disponibili diverse alternative, oltre a Funzioni di Azure, usate in questa implementazione di riferimento:
- servizio app Azure è un servizio completamente gestito basato su HTTP che compila, distribuisce e ridimensiona le app Web. Sono supportati tutti .NET, .NET Core, Java, Ruby, Node.js, PHP e Python. Le applicazioni possono essere eseguite e ridimensionate in ambienti basati su Windows o Linux.
- servizio Azure Kubernetes offre cluster Kubernetes completamente gestiti per un'esperienza integrata di integrazione continua e recapito continuo (CI/CD), governance e sicurezza.
- App per la logica di Azure è una piattaforma basata sul cloud che crea ed esegue flussi di lavoro automatizzati. Un'architettura di riferimento di esempio è disponibile in Basic Enterprise Integration in Azure.
- App Azure Container consente di eseguire microservizi e applicazioni in contenitori in una piattaforma serverless.
Per le distribuzioni in più aree, è consigliabile usare Frontdoor di Azure per offrire accesso rapido, affidabile e sicuro tra gli utenti e il contenuto Web statico e dinamico delle applicazioni.
Per altri esempi di come gateway applicazione può proteggere le API, vedere Proteggere le API con gateway applicazione e Gestione API.
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.
Affidabilità
L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.
- Distribuire almeno due unità di scala di Gestione API distribuite in due zone di disponibilità, per area. Questo metodo ottimizza la disponibilità e le prestazioni.
- Il peering reti virtuali offre prestazioni elevate in un'area, ma ha un limite di scalabilità di massimo 500 reti. Se sono necessari più carichi di lavoro da connettere, usare una progettazione hub spoke o una rete WAN virtuale di Azure.
Sicurezza
La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.
- Gestione API criteri di convalida sono disponibili per convalidare le richieste API e le risposte rispetto a uno schema OpenAPI. Queste funzionalità non sono una sostituzione di un Web Application Firewall, ma possono fornire 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.
- Distribuire Web application firewall (WAF) di Azure davanti a Gestione API per garantire la protezione dagli exploit e dalle vulnerabilità comuni delle applicazioni Web.
- Applicare valori denominati con i segreti di Key Vault per proteggere le informazioni riservate nei criteri di Gestione API.
- Usare gateway applicazione per l'accesso esterno di un'istanza di Gestione API interna per proteggere l'istanza di Gestione API e abilitare la connettività ibrida.
- Distribuire il gateway Gestione API in una rete virtuale per supportare la connettività ibrida e aumentare la sicurezza.
- Il peering reti virtuali offre prestazioni elevate in un'area, ma ha un limite di scalabilità di massimo 500 reti. Se sono necessari più carichi di lavoro da connettere, usare una progettazione hub spoke o una rete WAN virtuale di Azure.
Ottimizzazione dei costi
L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.
- A causa della necessità del supporto della zona di disponibilità e della rete virtuale, è stato selezionato il livello Premium di Gestione API, seguendo i prezzi per ogni area. Inoltre, in questo carico di lavoro, Funzioni di Azure è ospitato nel piano Premium, a causa della necessità di accesso alla rete virtuale.
- Per il modello di verifica o i 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 la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'eccellenza operativa.
- Gestione API configurazioni devono essere rappresentate come modelli arm ed è consigliabile adottare una mentalità basata su infrastruttura come codice.
- Usare un processo CI/CD per gestire, versione e aggiornare le configurazioni Gestione API.
- Creare probe di integrità personalizzati per convalidare lo stato dell'istanza di Gestione API. Usare l'URL
/status-0123456789abcdefper creare un endpoint di integrità comune per il servizio Gestione API nel gateway app. - I certificati aggiornati nell'insieme di credenziali delle chiavi vengono ruotati automaticamente in Gestione API, che viene aggiornato entro 4 ore.
- Distribuire almeno due unità di scala di Gestione API distribuite in due zone di disponibilità, per area. Questo metodo ottimizza la disponibilità e le prestazioni.
Distribuire lo scenario
Questa architettura è disponibile in GitHub. Contiene tutti i file di infrastruttura come codice necessari e le istruzioni di distribuzione.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autori principali:
- Pete Palermo | Senior Cloud Solution Architect
- Anthony Nevico | Senior Cloud Solution Architect
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
- Linee guida per Cloud Adoption Framework per Azure Gestione API nelle zone di destinazione di Azure
- CI/CD per Gestione API usando modelli di Resource Manager di Azure
- Introduzione alle Gestione API
- Gestire le API con Gestione API
- risorse Gestione API per iniziare
Vedere queste risorse chiave:
- Operazioni dell'API
- Documentazione di Gestione API di Azure
- Concetti chiave di Azure Gestione API
- gateway applicazione documentazione
Maggiori informazioni su questi servizi chiave:
- Panoramica di Funzioni di Azure
- Zone DNS privato di Azure
- Panoramica di app Azure lication Insights
- Panoramica di Azure Log Analytics
- Panoramica delle macchine virtuali di Azure
- Concetti di base di Azure Key Vault
- Panoramica di Azure Bastion