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 a casa e alle integrazioni di terze parti. Esternamente, più aziende cercano di essere produttivi e monetizzare le loro API. Con questa tendenza, Gestione API diventa un componente centrale per un approccio standard di gestione, gestione e pubblicazione di API sia interne che esterne.
Con l'aiuto di gateway applicazione di Azure, è ora possibile proteggere e limitare l'accesso alle API gestite tramite Azure Gestione API. Questo articolo descrive una soluzione in cui è possibile gestire api interne ed esterne tramite una singola istanza di Gestione API. È possibile mantenere un comportamento sicuro da esporre direttamente tramite Internet, ma è accessibile tramite un gateway applicazione.
Nota
Questa architettura viene usata come base dell'acceleratore di zona di destinazione di Azure Gestione API nell'Cloud Adoption Framework.
Architettura
Questo diagramma dell'architettura inizia con una casella 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 APIM-CS. Nella parte superiore della sottoscrizione è una casella che indica che è un carico di lavoro locale. Nella 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 sono all'interno della grande casella che mostra la sottoscrizione di Azure. Quattro delle caselle sono nella riga superiore e tre sono nella riga inferiore. Ogni singola casella rappresenta una subnet separata, con un gruppo di sicurezza di rete collegato. Dalla parte sinistra più a sinistra è presente un indirizzo IP pubblico associato a gateway applicazione di Azure nella casella più a sinistra nella riga superiore. gateway applicazione vive anche all'interno di una delle sette caselle più piccole, con la subnet denominata subnet app GW. A destra è un'altra casella contenente l'istanza di Gestione API, con la subnet denominata subnet APIM. Accanto a esso è la terza casella nella riga superiore, che contiene un endpoint privato per l'istanza di Funzioni di Azure nella subnet denominata SUBNET PE. 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 di 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 è DevOps Agent contenuta nella subnet DevOps. In basso a destra dell'immagine sono tre risorse condivise con le rispettive icone. Da sinistra a destra, sono 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 nei 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 è lo stesso descritto in precedenza: da Gestione API a endpoint privato e da endpoint privato a Funzione di Azure.
Questa architettura presuppone che i criteri siano presenti dall'acceleratore di zona di destinazione di Azure e che la struttura venga guidata verso il basso dal gruppo di gestione.
Scaricare un file di Visio di questa architettura.
Flusso di lavoro
Scenario ibrido (cerchi blu)
Questo scenario richiede una connessione da sito a sito o da 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 nome di dominio completo personalizzato, collegato a gateway applicazione di Azure.
- 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. La gestione API funge da facciata per astrarre l'architettura back-end e fornisce il controllo e la sicurezza per l'osservabilità e l'utilizzo delle API per utenti interni ed esterni.
Funzioni di Azure è una soluzione serverless che consente di concentrarsi su blocchi di codice che possono essere eseguiti con la 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 applicazione di Azure è 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 interna dell'APIM, che consente di usare la modalità interna ed esterna.
Le zone DNS di AzureDNS 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.
Monitoraggio di AzureApplication Insights consente agli sviluppatori di rilevare anomalie, diagnosticare i problemi e comprendere i modelli di utilizzo. Application Insights offre funzionalità estendibili per la gestione delle prestazioni delle applicazioni e il monitoraggio per le app 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. Application Insights è incluso nell'ambito di questa architettura di riferimento per monitorare i comportamenti dell'applicazione distribuita.
Monitoraggio di AzureLog Analytics consente di modificare ed eseguire query di log con dati nei log di Monitoraggio di Azure, facoltativamente dall'interno dell'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 ulteriori analisi e report.
Azure Macchine virtuali è una risorsa di calcolo 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 da chiavi API e password a certificati e chiavi crittografiche. Questa architettura di riferimento usa Azure Key Vault per archiviare i certificati SSL usati dal gateway applicazione.
Azure Bastion è un servizio come piattaforma di cui è stato effettuato il provisioning all'interno della rete virtuale dello sviluppatore. Fornisce connettività RDP/SSH sicura alle macchine virtuali dello sviluppatore tramite TLS, dal portale di Azure. 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 runner 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 i runner 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 interrompere il processo e consentire ai team di sviluppo di distribuire modifiche, per API. Vengono eseguiti dai runner DevOps.
Alternativi
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 di Azure è un servizio basato su HTTP completamente gestito che compila, distribuisce e ridimensiona le app Web. .NET, .NET Core, Java, Ruby, Node.js, PHP e Python sono tutti supportati. 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 distribuzione continua (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 Integrazione aziendale di base 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 fornire accesso rapido, affidabile e sicuro tra gli utenti e il contenuto Web statico e dinamico delle applicazioni.
Per vedere 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 set di set di guide 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 max 500 reti. Se è necessario connettere più carichi di lavoro, usare una progettazione hub spoke o una rete WAN virtuale di Azure.
Sicurezza
La sicurezza offre garanzie contro attacchi intenzionali e l'abuso dei dati e dei sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.
- Gestione API i criteri di convalida sono disponibili per convalidare le richieste e le risposte dell'API 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, quindi è consigliabile usare i test di carico delle prestazioni per valutarne l'impatto sulla velocità effettiva dell'API.
- Distribuire Azure Web application firewall (WAF) davanti a Gestione API per garantire la protezione dagli exploit e dalle vulnerabilità comuni delle applicazioni Web.
- Applicare valori denominati con segreti 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 una maggiore sicurezza.
- Il peering reti virtuali offre prestazioni elevate in un'area, ma ha un limite di scalabilità di max 500 reti. Se è necessario connettere più carichi di lavoro, 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à di supporto per la zona di disponibilità e la 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 lo 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 distribuita 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.
Autori di contributi
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai collaboratori seguenti.
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
- Questa stessa architettura viene usata come base dell'acceleratore di zona di destinazione di Azure Gestione API nel Cloud Adoption Framework.
- CI/CD per Gestione API usando modelli di Resource Manager di Azure
- Introduzione a Gestione API
- Gestire le API con Gestione API
- risorse Gestione API per iniziare
Vedere queste risorse chiave:
- Acceleratore della zona di destinazione di Azure
- Operazioni dell'API
- Documentazione di Azure Gestione API
- Concetti chiave di Azure Gestione API
- Documentazione del gateway applicazione
- Acceleratore di zona di destinazione di Azure Gestione API
Altre informazioni su questi servizi chiave:
- Panoramica di Funzioni di Azure
- Zone di DNS privato di Azure
- Panoramica di applicazione Azure Insights
- Panoramica di Azure Log Analytics
- Panoramica delle macchine virtuali di Azure
- Concetti relativi ad Azure Key Vault
- Panoramica di Azure Bastion