Best practice per la protezione di applicazioni e API utilizzando Apigee

Last reviewed 2024-03-19 UTC

Questo documento descrive le best practice che possono aiutarti a proteggere le tue applicazioni e le tue API utilizzando la gestione delle API Apigee e i seguenti Google Cloud prodotti:

Questo documento è rivolto ad architetti API, architetti della sicurezza e responsabili dell'ingegneria che gestiscono l'infrastruttura di un'applicazione e vogliono esporre API sicure, scalabili e performanti.

Questo documento utilizza una serie di architetture di esempio per dimostrare le best practice per l'utilizzo della gestione delle API Apigee. Questo documento illustra inoltre le migliori pratiche per l'utilizzo di Web App and API Protection (WAAP), una soluzione di sicurezza completa che puoi utilizzare per proteggere le tue applicazioni e API.

Questo documento presuppone che tu abbia familiarità con la rete, le API e Google Cloud.

Gestione delle API Apigee

Apigee è una piattaforma per lo sviluppo e la gestione di API. Con l'aggiunta di un livello di proxy ai tuoi servizi, Apigee fornisce un'astrazione o una facade che ti aiuta a proteggere le API dei servizio di backend.

Gli utenti possono interagire con le applicazioni utilizzando OAuth 2.0 e intervalli di indirizzi IP inclusi nella lista consentita. Come mostrato nell'immagine seguente, gli utenti possono interagire con un'applicazione e i dati e i servizi vengono esposti in un flusso bidirezionale.

Punti di sicurezza tra l'interazione dell'utente con un'applicazione e il backend.

I punti di sicurezza sono i seguenti:

  • Utenti:
    • OAuth 2.0
    • Controllo dell'accesso agli indirizzi IP
  • Applicazioni
    • Chiavi API
    • OAuth 2.0
    • TLS
  • Sviluppatori e partner
    • SSO
    • RBAC
  • API
    • OAuth 2.0
    • OpenID Connect
    • Quote
    • Arresto di picco
    • Protezione dalle minacce
  • Team API
    • RBAC IAM
    • Logica federata
    • Mascheramento dei dati
    • Audit log
  • Backend
    • Networking privato
    • Mutual TLS
    • Controllo dell'accesso agli indirizzi IP

Come mostrato nell'immagine precedente, in un'applicazione puoi utilizzare diversi meccanismi di sicurezza, ad esempio l'API key o OAuth 2.0 con Transport Layer Security (TLS). Puoi anche aggiungere limitazione di frequenza, criteri di protezione dalle minacce e configurare TLS mutuale nel backend del livello API.

Per aiutarti a gestire l'accesso per un team API all'interno della piattaforma Apigee, Apigee offre controllo dell'accesso basato su ruoli (RBAC) e l'accesso federato.

Ti consigliamo di utilizzare i criteri predefiniti di Apigee per proteggere le tue API. Le norme sono le seguenti:

  • Gestione del traffico. Ti aiuta a configurare la memorizzazione nella cache, a controllare le quote, a mitigare gli effetti degli picchi e a controllare il traffico API.
  • Protezione a livello di messaggio. Ti consente di ispezionare e convalidare i payload delle richieste per proteggere il tuo backend da utenti malintenzionati.
  • Sicurezza. Ti aiuta a controllare l'accesso alle tue API.

Puoi associare uno o più di questi criteri al livello proxy. La tabella seguente elenca il caso d'uso di sicurezza per ogni criterio, classificato in base al tipo di criterio.

Tipo di criterio Nome del criterio Caso d'uso relativo alla sicurezza
Gestione del traffico Criterio SpikeArrest Applica il limite di frequenza al numero di richieste inviate al backend.
Gestione del traffico Criteri per le quote Aiuta la tua organizzazione ad applicare le quote (il numero di chiamate API effettuate) per ciascun consumatore.
Gestione del traffico Norme di ResponseCache Memorizza nella cache le risposte, riducendo il numero di richieste al backend.
Protezione a livello di messaggio Norme di OASValidation Convalida le richieste in entrata o i messaggi di risposta in base a una specifica OpenAPI 3.0 (JSON o YAML).
Protezione a livello di messaggio Norme relative a SOAPMessageValidation Convalida i messaggi XML in base a uno schema a tua scelta. Convalida i messaggi SOAP rispetto a un WSDL e determina se i messaggi JSON e XML sono formattati correttamente.
Protezione a livello di messaggio Norme di JSONThreatProtection Contribuisce ad attenuare il rischio di attacchi a livello di contenuti consentendoti di specificare limiti per le strutture JSON come array e stringhe.
Protezione a livello di messaggio Norme di XMLThreatProtection Ti aiuta ad affrontare le vulnerabilità XML e a ridurre il rischio di attacchi valutando i contenuti dei messaggi e rilevando i messaggi danneggiati o con formato non corretto prima che possano essere analizzati.
Protezione a livello di messaggio Norme relative a RegularExpressionProtection Valuta i contenuti in base a espressioni regolari predefinite e li rifiuta se l'espressione è vera.
Sicurezza Criterio BasicAuthentication Base64 codifica e decodifica le credenziali utente.
Sicurezza Norme relative a VerifyAPIKey Applica la verifica e la convalida delle chiavi API in fase di esecuzione. Consente solo alle applicazioni con chiavi API approvate associate ai tuoi prodotti API di accedere alle tue API.
Sicurezza Norme OAuthV2 Esegue operazioni sui tipi di concessione OAuth 2.0 per generare e convalidare i token di accesso.
Sicurezza Criteri JWS e JWT Genera, verifica e decodifica i token web JSON (JWT) e le firme web JSON (JWS).
Sicurezza Norma HMAC Calcola e verifica il codice HMAC (Hash-based Message Authentication Code) per la verifica dell'integrità e dell'autenticazione a livello di applicazione.
Sicurezza Criterio SAMLAssertion
  • Convalida i messaggi in arrivo che contengono un'affermazione SAML firmata digitalmente.
  • Genera asserzioni SAML per le richieste XML in uscita.
Sicurezza Criterio CORS Ti consente di impostare le intestazioni CORS (Cross-Origin Resource Sharing) per le API utilizzate dalle applicazioni web.

Ti consigliamo di utilizzare Google Cloud Armor per controllo dell'accesso basato su indirizzi IP e dati geografici. Tuttavia, se non è possibile, puoi utilizzare il criterio di controllo dell'accesso. Per aiutarti a proteggere le connessioni da Apigee al tuo backend, Apigee fornisce anche la gestione del keystore, che ti consente di configurare il keystore e il truststore per gli handshake TLS.

Puoi utilizzare Apigee per creare prodotti API che ti consentono di raggruppare le operazioni dell'API e renderle disponibili per l'utilizzo da parte degli sviluppatori di applicazioni. Un prodotto API raggruppa una o più operazioni. Un'operazione specifica un proxy API e i percorsi delle risorse a cui è possibile accedere su quel proxy. Un'operazione può anche limitare l'accesso in base ai metodi HTTP e in base alla quota.

Utilizzi i prodotti API per controllare l'accesso alle tue API. Se definisci uno o più prodotti API in un'applicazione per sviluppatori, puoi limitare l'accesso ai proxy con una chiave API. Ad esempio, le applicazioni mobile utilizzate dai clienti possono eseguire solo un'operazione POST sull'endpoint /v1/payments, in questo caso https://$DOMAIN/v1/payments. In un altro esempio, le applicazioni dei call center impiegate dal personale possono eseguire operazioni come PUT o DELETE sull'endpoint /payments, ad esempio https://$DOMAIN/v1/payments/1234, per annullare o accreditare nuovamente i pagamenti.

Architettura iniziale

Questa sezione descrive un esempio di architettura di microservizi con i servizi impiegati nel data center e nel provider cloud. Le seguenti best practice relative all'architettura mostrano come eseguire l'iterazione e migliorare l'architettura iniziale.

Esempio di architettura di microservizi con i servizi impiegati nel data center e nel provider cloud.

L'architettura iniziale è la seguente:

  • I servizi di pagamenti e account sono ospitati nel data center, mentre il servizio di trasferimento di denaro è ospitato in Google Cloud.
  • Il bilanciatore del carico delle applicazioni esterno controlla e configura l'ingresso ai servizi.
  • Il bilanciatore del carico delle applicazioni esterno inoltra la richiesta al servizio di backend o di terze parti appropriato e gestisce l'handshake TLS.

Nel suo stato iniziale, l'architettura di esempio presenta i seguenti vincoli:

  • È improbabile che possa essere scalato.
  • È improbabile che protegga un sistema da attacchi dannosi
  • Non riflette best practice coerenti per la sicurezza e la registrazione perché questi servizi vengono sviluppati e gestiti da team diversi all'interno dell'organizzazione.

Best practice relative all'architettura

Apigee può aggiungere valore e semplificare l'esposizione dei tuoi servizi ai consumatori implementando un insieme standard di criteri di sicurezza in tutte le API. Questa sezione illustra le best practice per l'utilizzo di Apigee per proteggere le tue API.

Utilizzare Apigee come livello proxy

Il seguente diagramma mostra l'architettura iniziale con l'aggiunta di Apigee come livello proxy (facciata):

Apigee come livello proxy.

Il provisioning di Apigee viene eseguito in un progetto Google Cloud, mentre il provisioning e il peering del runtime vengono eseguiti in un progetto tenant utilizzando il peering di rete VPC. Per contribuire a proteggere il tuo sistema, anziché inviare i dati tramite internet, puoi utilizzare Apigee come livello proxy per stabilire una connessione diretta (privata) al tuo data center utilizzando Cloud Interconnect.

Il flusso di richiesta è il seguente:

  1. Il client invia la richiesta all'Application Load Balancer esterno con le credenziali per l'applicazione, ad esempio una chiave, un token o un certificato.
  2. Il bilanciatore del carico instrada la richiesta ad Apigee.
  3. Apigee elabora la richiesta, esegue i criteri di sicurezza come descritto in Gestione delle API Apigee e consente o nega la richiesta. Apigee può essere utilizzato anche per instradare la richiesta a diversi backend in base al client, alla richiesta o a entrambi.
  4. Apigee inoltra la richiesta ai backend GKE direttamente tramite gli indirizzi IP interni. La comunicazione tra Apigee e il servizio di trasferimento di denaro può avvenire tramite un indirizzo RFC 1918 (indirizzo IP interno) perché si trovano all'interno della rete con peering.
  5. Apigee invia la richiesta ai backend del data center privato tramite Cloud Interconnect.
  6. Apigee invia la richiesta ai servizi di terze parti tramite il provisioning dell'indirizzo IP NAT di Apigee.

Utilizzare Google Cloud Armor come livello WAF con Apigee

Puoi aggiungere Google Cloud Armor all'architettura per aumentare il perimetro di sicurezza. Google Cloud Armor fa parte dell'infrastruttura di bilanciamento del carico globale per Google Cloud. Fornisce funzionalità di web application firewall (WAF) e contribuisce a prevenire gli attacchi denial of service (DDoS) distribuiti. Inoltre, può aiutarti a mitigare la minaccia per le applicazioni rappresentata dai rischi elencati nel documento OWASP Top 10.

Puoi configurare regole e criteri in Google Cloud Armor per valutare ogni chiamata effettuata dal client che raggiunge il bilanciatore del carico delle applicazioni esterno. Puoi anche automatizzare la configurazione dei criteri di Google Cloud Armor. Per ulteriori informazioni su come configurare le regole in Google Cloud Armor, consulta le guide pratiche di Google Cloud Armor.

Il seguente diagramma mostra l'architettura di esempio con Apigee e Google Cloud Armor implementati:

Architettura con Google Cloud Armor.

Il flusso di eventi in questa architettura è simile a quello descritto in Utilizzare Apigee come livello proxy all'inizio di questo documento. Il flusso di richieste è il seguente:

  1. Il client invia la richiesta all'Application Load Balancer esterno con le credenziali per l'applicazione, ad esempio una chiave, un token o un certificato.
  2. Google Cloud Armor filtra la richiesta perché il bilanciatore del carico delle applicazioni esterno lo ha attivato. Applica e valuta tutte le regole e le norme configurate. Se una regola viene violata, Google Cloud Armor rifiuta la richiesta e fornisce un messaggio di errore e un codice di stato.
  3. Se non sono presenti violazioni delle regole di Google Cloud Armor, il bilanciatore del carico delle applicazioni esterno instrada la richiesta ad Apigee.
  4. Apigee elabora la richiesta, esegue i criteri di sicurezza e consente o nega la richiesta. Può essere utilizzato anche per instradare la richiesta a diversi backend in base al client, alla richiesta o a entrambi.
  5. Apigee inoltra la richiesta ai backend GKE direttamente tramite indirizzi IP interni. La comunicazione tra Apigee e il servizio di trasferimento di denaro può avvenire tramite un indirizzo RFC 1918 (indirizzo IP interno) perché si trovano all'interno della rete con peering.
  6. Apigee invia la richiesta ai backend del data center privato tramite Cloud Interconnect.
  7. Apigee invia la richiesta ai servizi di terze parti tramite il provisioning dell'indirizzo IP NAT di Apigee.

Utilizzare WAAP

Per migliorare ulteriormente il tuo profilo di sicurezza, puoi anche utilizzare WAAP, che riunisce Google Cloud Armor, reCAPTCHA e Apigee per contribuire a proteggere il tuo sistema da attacchi DDoS e bot. Fornisce inoltre protezione WAF e API.

Consigliamo WAAP per i casi d'uso aziendali in cui le chiamate API vengono effettuate da un sito web e da applicazioni mobile. Puoi impostare le applicazioni in modo che caricino le librerie reCAPTCHA per generare un token reCAPTCHA e inviarlo quando fanno una richiesta.

Il seguente diagramma mostra il flusso di lavoro:

Flusso di richiesta per WAAP.

Il flusso di richieste nel diagramma precedente è il seguente:

  • (1) Tutte le richieste HTTP(S) dei clienti e dei consumer delle API vengono inviate al bilanciatore del carico delle applicazioni esterno.
  • (2) Il primo punto di contatto per la soluzione WAAP è Google Cloud Armor.
  • (2a) Se nessuna di queste regole viene attivata dalle norme di Google Cloud Armor, viene inviata una richiesta all'API reCAPTCHA per valutare se il traffico in entrata è una richiesta legittima o meno.
  • (3a) Se si tratta di una richiesta legittima, viene inoltrata al backend.
  • (2b) Se la richiesta non è legittima, Google Cloud Armor può rifiutarla e inviare all'utente un codice di risposta 403.
  • (3b) Per qualsiasi richiesta API, dopo la valutazione delle regole OWASP e della protezione DDoS di Google Cloud Armor, la richiesta viene inoltrata ad Apigee per verificare la sua validità.
  • (4) Apigee determina se le chiavi API o i token di accesso utilizzati nella richiesta sono validi. Se Apigee stabilisce che la richiesta non è legittima, può inviare un codice di risposta 403.
  • (5) Se la richiesta è legittima, Apigee la inoltra al backend.

Il seguente diagramma mostra l'architettura di WAAP con Google Cloud Armor, reCAPTCHA e Apigee per le richieste API.

Flusso di richieste per WAAP con Google Cloud Armor, reCAPTCHA e Apigee.

Il flusso di richieste nel diagramma precedente è il seguente:

  1. Il client invia la richiesta all'Application Load Balancer esterno con le credenziali per l'applicazione, ad esempio una chiave, un token o un certificato.
  2. Poiché il bilanciatore del carico delle applicazioni esterno ha attivato Google Cloud Armor, è quest'ultimo a selezionare la richiesta. Applica e valuta tutte le regole e le norme configurate. Se una regola viene violata, Google Cloud Armor rifiuta la richiesta con un messaggio di errore e un codice di stato.
  3. Per le chiamate al sito web, ad esempio l'invio di un modulo per una pagina di accesso, Google Cloud Armor è integrato con reCAPTCHA. reCAPTCHA valuta il traffico in entrata e aggiunge punteggi di rischio al traffico legittimo. Per il traffico non legittimo, Google Cloud Armor può rifiutare la richiesta.
  4. Se non ci sono violazioni delle regole di Google Cloud Armor, il bilanciatore del carico delle applicazioni esterno instrada la richiesta API ad Apigee.
  5. Apigee elabora la richiesta, esegue i criteri di sicurezza e consente o nega la richiesta. Apigee può essere utilizzato anche per instradare la richiesta a diversi backend in base al client, alla richiesta o a entrambi.
  6. Apigee inoltra la richiesta ai backend GKE direttamente tramite gli indirizzi IP interni. La comunicazione tra Apigee e il servizio di trasferimento di denaro può avvenire tramite l'indirizzo RFC 1918, che è un indirizzo IP interno, perché entrambi si trovano nella rete con peering.
  7. Apigee invia la richiesta ai backend del data center privato tramite Cloud Interconnect.
  8. Apigee invia la richiesta ai servizi di terze parti tramite il provisioning dell'indirizzo IP NAT di Apigee.

Utilizzare Cloud CDN per la memorizzazione nella cache

Cloud CDN utilizza la rete globale di Google per fornire contenuti più vicini agli utenti, il che accelera i tempi di risposta dei tuoi siti web e delle tue applicazioni. Cloud CDN offre anche funzionalità di memorizzazione nella cache che ti aiutano a proteggere il backend restituendo la risposta dalla cache. Memorizzando nella cache i dati a cui si accede di frequente in un elemento di front-end di Google (GFE), che si trova all'estremità della rete di Google, mantiene i dati il più vicino possibile agli utenti e consente l'accesso più rapido possibile.

Cloud CDN aiuta inoltre le organizzazioni a gestire senza problemi i picchi stagionali del traffico, ad esempio quelli che si verificano durante le festività o il periodo di inizio della scuola. Questo approccio alla memorizzazione nella cache contribuisce a migliorare l'affidabilità e l'esperienza utente in un ecosistema. Può anche contribuire a ridurre al minimo il carico del server web, le risorse di calcolo e l'utilizzo della rete. Per implementare questa architettura, devi attivare Cloud CDN sul bilanciatore del carico che gestisce il traffico per Apigee.

Cloud CDN può essere utilizzato con qualsiasi opzione discussa in questo documento. Il seguente diagramma mostra l'architettura di esempio iniziale di WAAP con l'aggiuntivo di Cloud CDN.

Flusso di richieste con Cloud CDN.

Il flusso di richieste mostrato nel diagramma precedente è il seguente:

  1. Il client utilizza le librerie reCAPTCHA per ottenere un token e invia la richiesta al bilanciatore del carico delle applicazioni esterno con le credenziali dell'applicazione, ad esempio una chiave, un token o un certificato.
  2. Cloud CDN controlla la cache con la chiave della cache e restituisce la risposta se l'hit della cache è true.
  3. Se l'hit della cache è falso, Google Cloud Armor filtra la richiesta perché il bilanciatore del carico delle applicazioni esterno ha Google Cloud Armor abilitato. Google Cloud Armor applica e valuta tutte le regole e i criteri configurati. Se viene violata una regola, la richiesta viene rifiutata con un messaggio di errore e un codice di stato.
  4. Google Cloud Armor è integrato con reCAPTCHA, che valuta il traffico in entrata legittimo con punteggi di rischio. Per il traffico non legittimo, Google Cloud Armor può rifiutare la richiesta.
  5. Se non ci sono violazioni delle regole di Google Cloud Armor, il bilanciatore del carico delle applicazioni esterno instrada la richiesta ad Apigee.
  6. Apigee elabora la richiesta, esegue i criteri di sicurezza come descritto in Gestione delle API Apigee e consente o nega la richiesta. Può essere utilizzato anche per instradare la richiesta a diversi backend in base al client, alla richiesta o a entrambi.
  7. Apigee inoltra la richiesta ai backend GKE direttamente tramite gli indirizzi IP interni. La comunicazione tra Apigee e il servizio di trasferimento di denaro può avvenire tramite l'indirizzo RFC 1918, che è un indirizzo IP interno, perché si trovano all'interno della rete con peering.
  8. Apigee invia la richiesta ai backend del data center privato tramite Cloud Interconnect.
  9. Apigee invia la richiesta ai servizi di terze parti tramite il provisioning dell'indirizzo IP NAT di Apigee.
  10. Quando una risposta viene restituita al client, Cloud CDN la memorizza nella cache in modo da poterla restituire dalla cache per le chiamate future.

Passaggi successivi