Acceleratore di zona di destinazione di Azure Gestione API

Gestione API
Gateway applicazione
Integrazione con gli strumenti di sviluppo
Funzioni
.NET Core

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 ad applicazioni line-of-business, soluzioni predefinite e integrazioni di terze parti. Esternamente, più aziende sembrano essere produttive e monetizzare le loro API. Tenendo presente questa tendenza, Gestione API diventa un componente centrale per un approccio standard di gestione, governance 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 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 dell'acceleratore di zona di destinazione di Azure Gestione API nel Cloud Adoption Framework.

Architettura

Diagramma che mostra l'architettura dell'acceleratore di zona di destinazione Gestione API.

Questo diagramma dell'architettura inizia con un riquadro completo 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 apiM-CS. Nella parte superiore della sottoscrizione è presente una casella che indica che si tratta di un carico di lavoro locale. La casella contiene 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, c'è un indirizzo IP pubblico collegato a gateway applicazione di Azure 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 del gateway app. A destra è presente un'altra casella contenente l'istanza di Gestione API, con la subnet denominata 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 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 è 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 disponibili le caselle seguenti: Insieme di credenziali delle chiavi, Application Insights e area di lavoro Log Analytics. Sono disponibili 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 verranno spiegati 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, dal 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 da endpoint privato a Funzione di Azure.

Questa architettura presuppone che i criteri siano applicati 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 Azure ExpressRoute all'ambiente locale.

  1. Un'applicazione locale richiede l'accesso a un'API interna gestita tramite Azure Gestione API.
  2. 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 e ospitato nella propria subnet.
  3. L'endpoint privato accede in modo sicuro all'API interna ospitata in Funzioni di Azure.

Scenario di accesso esterno (cerchi neri)

  1. Un'applicazione esterna accede a un indirizzo IP pubblico o a un nome di dominio completo personalizzato, collegato a gateway applicazione di Azure.
  2. gateway applicazione funge da web application firewall, che richiede certificati PFX per la terminazione SSL.
  3. 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.
  4. 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 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 di Gestione API interna, 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.

  • Application Insights di Monitoraggio di Azure consente agli sviluppatori di rilevare anomalie, diagnosticare i problemi e comprendere i modelli di utilizzo. Application Insights offre funzionalità estendibili di gestione delle prestazioni delle applicazioni e monitoraggio per le app Web attive. 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 Monitoraggio di 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 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 dalla gateway applicazione.

  • Azure Bastion è un servizio distribuita 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 di esecuzione GitHub o al server jump box di gestione.

Se si usa uno strumento DevOps, ad esempio Azure DevOps o GitHub, gli agenti o gli strumenti di esecuzione ospitati nel cloud operano su Internet pubblico. Poiché gestione API in questa architettura è impostata su una rete interna, è necessario usare un agente DevOps che abbia accesso alla rete virtuale. L'agente DevOps consente di distribuire criteri e altre modifiche alle API nell'architettura. Questi modelli CI/CD 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.

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 completamente gestito basato su HTTP 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 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 Contenitore di Azure 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 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 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-0123456789abcdef per 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:

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

Passaggi successivi

Vedere queste risorse chiave:

Altre informazioni su questi servizi chiave: