Condividi tramite

Proteggere le API usando il gateway applicazione e Gestione API

Gestione API di Azure
Gateway applicazione di Azure

Le organizzazioni adottano sempre più approcci di progettazione API-first, affrontando minacce crescenti per le applicazioni Web. È necessaria una strategia di sicurezza completa per proteggere le API, soprattutto quando si espongono API basate sull'intelligenza artificiale e si implementano principi di architettura zero trust. Il modello di routing del gateway offre un approccio alla sicurezza api proteggendo il traffico di rete. Il gateway limita le posizioni di origine del traffico e la qualità del traffico, supportando regole di routing flessibili. Questo articolo descrive come usare app Azure lication Gateway e Azure Gestione API per proteggere l'accesso alle API.

Architecture

Questo articolo non illustra le piattaforme sottostanti dell'applicazione, ad esempio Ambiente del servizio app, Istanza gestita di SQL di Azure e servizio Azure Kubernetes. Queste parti del diagramma illustrano ciò che è possibile implementare come soluzione più ampia. Questo articolo illustra in modo specifico le aree ombreggiate, Gestione API e gateway applicazione.

Diagramma che mostra come il gateway applicazione e Gestione API proteggono le API.

Scaricare un file di Visio di questa architettura.

Workflow

  1. Il gateway applicazione riceve richieste HTTPS consentite dal gruppo di sicurezza di rete (NSG) della subnet.

  2. Web application firewall (WAF) nel gateway applicazione controlla la richiesta rispetto alle regole WAF, incluse le regole personalizzate per la corrispondenza geografica. Se la richiesta è valida, la richiesta procede.

  3. Il gateway applicazione configura un meccanismo proxy URL che invia la richiesta al pool back-end appropriato. Il comportamento di routing dipende dal formato URL della chiamata API:

    • Gli URL formattati come api.<some-domain>/external/* possono raggiungere il back-end per interagire con le API richieste.

    • Chiamate formattate come api.<some-domain>/* vai a un dead-end, denominato sinkpool, che è un pool back-end senza destinazione.

    • Una regola di routing a livello di gateway applicazione reindirizza gli utenti nel portal.<some-domain>/* portale per sviluppatori. Gli sviluppatori possono gestire LE API e le relative configurazioni da ambienti interni ed esterni. In alternativa, è possibile bloccare completamente il portale per sviluppatori.

  4. Il gateway applicazione accetta e proxy le chiamate interne dalle risorse nella stessa rete virtuale di Azure in api.<some-domain>/internal/*.

  5. A livello di Gestione API, le API accettano chiamate nei modelli seguenti:

    • api.<some-domain>/external/*
    • api.<some-domain>/internal/*

    In questo scenario Gestione API usa indirizzi IP pubblici e privati. Gli indirizzi IP pubblici supportano le operazioni di gestione sulla porta 3443 per il piano di gestione e per il traffico dell'API di runtime in configurazioni di rete virtuale esterne. Quando Gestione API invia una richiesta a un back-end pubblico con connessione Internet, viene visualizzato un indirizzo IP pubblico come origine della richiesta. Per altre informazioni, vedere Indirizzi IP di Gestione API in una rete virtuale.

Components

  • La rete virtuale di Azure consente a molti tipi di risorse di Azure di comunicare privatamente tra loro, internet e reti locali. In questa architettura il gateway applicazione esegue il tunneling del traffico Internet pubblico in questa rete privata.

  • Il gateway applicazione è un servizio di bilanciamento del carico del traffico Web che gestisce il traffico verso le applicazioni Web. Questo tipo di routing è noto come bilanciamento del carico del livello applicazione (OSI Layer 7). In questa architettura, il gateway fornisce routing e ospita un WAF per proteggersi da vettori di attacco comuni basati sul Web.

  • gestione API è una piattaforma ibrida di gestione multicloud per le API in tutti gli ambienti. La gestione API crea gateway API moderni e coerenti per i servizi back-end esistenti. In questa architettura Gestione API opera in modalità completamente privata per eseguire l'offload di problemi di taglio incrociato dal codice e dagli host DELL'API.

Alternatives

È possibile usare altri servizi per offrire un livello simile di protezione firewall e WAF:

  • Frontdoor di Azure offre protezione DDoS (Distributed Denial of Service) predefinita e bilanciamento del carico globale.

  • Firewall di Azure offre protezione a livello di rete e gestione centralizzata dei criteri di sicurezza.

  • Le soluzioni partner, ad esempio Barracuda WAF o altre soluzioni WAF, sono disponibili in Azure Marketplace.

Recommendations

Questa architettura è incentrata sull'implementazione dell'intera soluzione e sul test dell'accesso api dall'interno e dall'esterno della rete virtuale di Gestione API. Per altre informazioni sul processo di integrazione, vedere Integrare Gestione API in una rete virtuale interna usando il gateway applicazione.

Per comunicare con le risorse private nel back-end, posizionare il gateway applicazione e Gestione API nella stessa rete virtuale delle risorse o in una rete virtuale con peering.

  • Il modello di distribuzione interna privato consente a Gestione API di connettersi a una rete virtuale esistente, che lo rende raggiungibile dall'interno di tale contesto di rete. Per abilitare questa funzionalità, distribuire i livelli Developero Premium API Management per l'inserimento della rete virtuale classica. Per le opzioni di rete virtuale più recenti, usare i livelli Standard v2 o Premium v2 con funzionalità di integrazione o inserimento della rete virtuale.

  • Se i client operano in una sottoscrizione diversa o vengono gestiti con una directory ID Microsoft Entra diversa, usare Collegamento privato di Azure per il gateway applicazione per fornire connettività privata al gateway applicazione da reti virtuali client tra sottoscrizioni e aree.

  • Gestire i certificati del gateway applicazione in Azure Key Vault.

  • Per personalizzare le interazioni con i servizi, è possibile usare le voci nome canonico (CNAME).

Considerations

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.

Reliability

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'affidabilità.

Il gateway applicazione viene sempre distribuito in una configurazione a disponibilità elevata, indipendentemente dal numero di istanze. Per ridurre l'impatto di un malfunzionamento della zona, è possibile configurare il gateway applicazione per estendersi su più zone di disponibilità. Per altre informazioni, vedere Scalabilità automatica e disponibilità elevata.

Abilitare la ridondanza della zona per i componenti del servizio Gestione API per garantire resilienza e disponibilità elevata. La ridondanza della zona replica il gateway di Gestione API e il piano di controllo tra data center in zone fisicamente separate. Questa configurazione li rende resilienti agli errori della zona. Per supportare le zone di disponibilità, è necessario usare il livello Premium di Gestione API.

Gestione API supporta anche distribuzioni con più aree, che possono migliorare la disponibilità se un'area passa offline. Per altre informazioni, vedere Supporto per più aree. In questa topologia distribuire un gateway applicazione per ogni area perché il gateway applicazione è un servizio a livello di area.

Security

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

Per altre informazioni sulla sicurezza gateway applicazione, vedere Baseline di sicurezza di Azure per gateway applicazione.

Per altre informazioni sulla sicurezza Gestione API, vedere Baseline di sicurezza di Azure per Gestione API.

Implementare sempre le misure di sicurezza seguenti:

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.

Il costo di questa architettura dipende da diversi aspetti di configurazione:

  • Livelli di servizio: Prendere in considerazione i livelli Standard v2 e Premium v2 per Gestione API per migliorare l'efficienza e le prestazioni dei costi.

  • Scalabilità: I servizi allocano dinamicamente il numero di istanze per supportare una determinata domanda.

  • Durata runtime: I costi variano a seconda che l'architettura venga eseguita in modo continuo o solo poche ore ogni mese.

  • Trasferimento dei dati: Le distribuzioni di più aree comportano costi di trasferimento tra aree.

  • Elaborazione WAF: I costi dipendono dal numero di richieste e regole valutate.

Considerare le strategie di ottimizzazione dei costi seguenti:

Dopo aver valutato questi aspetti, usare il calcolatore prezzi di Azure per stimare i prezzi.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo mantengono in esecuzione nell'ambiente di produzione. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

Implementare il monitoraggio e l'osservabilità completi:

Efficienza delle prestazioni

L'efficienza delle prestazioni si riferisce alla capacità del carico di lavoro di ridimensionarsi per soddisfare in modo efficiente le esigenze degli utenti. Per altre informazioni, vedere Elenco di controllo per l'efficienza delle prestazioni.

Il gateway applicazione funge da punto di ingresso per questa architettura e la funzionalità web application firewall di Azure richiede potenza di elaborazione per ogni analisi delle richieste. Per consentire al gateway applicazione di espandere la capacità di calcolo su richiesta, abilitare la scalabilità automatica. Per altre informazioni, vedere Scalabilità automatica e ridondanza della zona nel gateway applicazione. Seguire le indicazioni della documentazione del prodotto per la configurazione dell'infrastruttura del gateway applicazione, incluso il dimensionamento corretto della subnet. Questo approccio garantisce che la subnet sia sufficientemente grande da supportare la scalabilità orizzontale completa.

Considerare le ottimizzazioni delle prestazioni seguenti per Gestione API:

Passaggi successivi

Per progettare API, seguire le linee guida per la progettazione di API Web valide. Per implementare le API, usare procedure consigliate per l'implementazione dell'API Web .