Questo documento descrive le best practice che possono aiutarti a proteggere i tuoi applicazioni e API mediante la gestione delle API Apigee e i seguenti prodotti Google Cloud:
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 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'aggiunzione di un livello di proxy ai tuoi servizi, Apigee fornisce un'astrazione o una facade che ti aiuta a proteggere le API dei servizi 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.
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 per 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 mostra l'immagine precedente, è possibile usare diversi meccanismi di sicurezza in una come Chiave API o OAuth 2.0 con Transport Layer Security (TLS). Puoi anche aggiungere limiti di frequenza, criteri di protezione dalle minacce e configurare TLS mutuale nel backend del livello API.
Per aiutarti a gestire l'accesso di un team dedicato alle API all'interno della piattaforma Apigee, Apigee dispone di controllo dell'accesso basato sui ruoli (RBAC) e dell'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 la richiesta payload per contribuire a proteggere il tuo backend da 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 della sicurezza |
|---|---|---|
| Gestione del traffico | Criterio di SpikeArrest | Applica il limite di frequenza al numero di richieste inviate al backend. |
| Gestione del traffico | Criteri per le quote | Consente alla tua organizzazione di applicare le quote (il numero di chiamate API effettuate) per ogni 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 | Criteri di 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 | Criteri 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 | Criterio XMLThreatProtection | Aiuta a risolvere le vulnerabilità XML e a mitigare il rischio di attacchi valutando i contenuti dei messaggi e rilevando quelli corrotti o non corretti prima di poter 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 | Criterio VerifyAPIKey | Applica la verifica e la convalida delle chiavi API in fase di runtime. Solo consente alle applicazioni con chiavi API approvate associate ai tuoi prodotti API di accedere alle tue API. |
| Sicurezza | Criterio OAuthV2 | Esegue operazioni sui tipi di autorizzazione OAuth 2.0 per generare e convalidare l'accesso di token. |
| Sicurezza | Criteri di JWS e JWT | Genera, verifica e decodifica i token web JSON (JWT) e le firme web JSON (JWS). |
| Sicurezza | Criterio HMAC | Calcola e verifica il codice HMAC (Hash-based Message Authentication Code) per di autenticazione e controlli di integrità a livello di applicazione. |
| Sicurezza | Criterio SAMLAssertion |
|
| Sicurezza | Criterio CORS | Consente di impostare la condivisione delle risorse tra origini (CORS). 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, nei casi in cui impossibile, puoi usare il criterio AccessControl. 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 percorsi delle risorse che possono essere a cui si accede su quel proxy. Un'operazione può anche limitare l'accesso tramite metodi HTTP per quota.
Puoi utilizzare i prodotti basati su 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 per call center
utilizzate dal personale dei call center possono eseguire operazioni come PUT o DELETE su
l'endpoint /payments, ad esempio https://$DOMAIN/v1/payments/1234, per ripristinare
o invertire 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 puoi eseguire l'iterazione e migliorare l'architettura iniziale.
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 il traffico in entrata nei 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.
Nello stato iniziale, l'architettura di esempio ha 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):
Viene eseguito il provisioning di Apigee in un progetto Google Cloud e del runtime e è in peering in un progetto tenant utilizzando il peering di rete VPC. Per 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:
- Il client invia la richiesta al bilanciatore del carico delle applicazioni esterno con le credenziali per l'applicazione, ad esempio una chiave, un token o un certificato.
- Il bilanciatore del carico instrada la richiesta ad Apigee.
- Apigee elabora la richiesta, esegue i criteri di sicurezza come descritti in Gestione delle API Apigee, e consente o rifiutano la richiesta. Apigee può essere utilizzato anche per il routing a backend diversi in base al client, alla richiesta o a entrambi al cliente e alla richiesta.
- Apigee inoltra la richiesta ai backend GKE direttamente tramite gli indirizzi IP interni. La comunicazione tra Apigee e il trasferimento di denaro può avvenire su un indirizzo RFC 1918 (indirizzo IP interno) perché sono all'interno della rete in peering.
- Apigee invia la richiesta ai backend del data center privato tramite Cloud Interconnect.
- Apigee invia la richiesta ai servizi di terze parti tramite il provisioning dell'indirizzo IP NAT di Apigee.
Utilizza 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:
Il flusso di eventi in questa architettura è simile a quello discusso in Utilizzare Apigee come livello proxy in precedenza in questo documento. Il flusso di richieste viene eseguito che segue:
- Il client invia la richiesta al bilanciatore del carico delle applicazioni esterno con le credenziali dell'applicazione, ad esempio una chiave, un token certificato.
- Google Cloud Armor filtra la richiesta perché il bilanciatore del carico delle applicazioni esterno lo ha attivato. Applica e valuta tutte le regole e i criteri configurati. Se una qualsiasi regola viene violata, Google Cloud Armor rifiuta la richiesta e fornisce un messaggio di errore e un codice di stato.
- Se non sono presenti violazioni delle regole di Google Cloud Armor, il bilanciatore del carico delle applicazioni esterno instrada la richiesta ad Apigee.
- Apigee elabora la richiesta, esegue i criteri di sicurezza e consente o nega la richiesta. Può essere utilizzato anche per instradare la richiesta a a backend diversi in base al client, alla richiesta o sia al client che la richiesta.
- Apigee inoltra la richiesta direttamente ai backend GKE tramite indirizzi IP interni. La comunicazione tra Apigee e il trasferimento di denaro può avvenire su un indirizzo RFC 1918 (indirizzo IP interno) perché si trovano nella rete in peering.
- Apigee invia la richiesta ai backend dei data center privati tramite Cloud Interconnect.
- Apigee invia la richiesta a servizi di terze parti tramite l'indirizzo IP Apigee NAT per eseguire il provisioning.
Utilizzare WAAP
Per migliorare ulteriormente il tuo profilo di sicurezza, puoi anche usare WAAP, che offre Google Cloud Armor, reCAPTCHA e Apigee per proteggere il tuo sistema contro 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 un sito web e applicazioni per dispositivi mobili. Puoi impostare le applicazioni in modo che carichino librerie reCAPTCHA per generare un token reCAPTCHA e inviarlo quando viene eseguito invia una richiesta.
Questo diagramma seguente mostra il flusso di lavoro:
Il flusso di richieste nel diagramma precedente è il seguente:
- (1) Tutte le richieste HTTP(S) dei clienti e dei consumer di API vengono inviate alla il 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 dai criteri 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, la richiesta viene inoltrata al di un backend cloud.
- (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 determina che la richiesta non è è legittimo, Apigee 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.
Il flusso di richieste nel diagramma precedente è il seguente:
- Il client invia la richiesta al bilanciatore del carico delle applicazioni esterno con le credenziali per l'applicazione, ad esempio una chiave, un token o un certificato.
- 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 qualsiasi regola viene violata, Google Cloud Armor la rifiuta la richiesta. con un messaggio di errore e un codice di stato.
- 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.
- Se non ci sono violazioni delle regole di Google Cloud Armor, il bilanciatore del carico delle applicazioni esterno instrada la richiesta API ad Apigee.
- Apigee elabora la richiesta, esegue i criteri di sicurezza e consente o nega la richiesta. Apigee può essere usato anche per instradare la richiesta a backend diversi in base al client, alla richiesta o sia al client che la richiesta.
- Apigee inoltra la richiesta ai backend GKE direttamente tramite gli indirizzi IP interni. La comunicazione tra Apigee e il trasferimento di denaro può avvenire su un indirizzo RFC 1918, che è un indirizzo IP interno, perché sono entrambi all'interno della rete in peering.
- Apigee invia la richiesta ai backend del data center privato tramite Cloud Interconnect.
- Apigee invia la richiesta a servizi di terze parti tramite Provisioning degli indirizzi IP Apigee NAT.
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 Google Front End (GFE) , che si trova sul perimetro della rete Google, mantiene i dati il più vicino possibile per gli 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, il calcolo e l'utilizzo della rete del server web. Per implementare questa architettura, devi abilitare Cloud CDN sul bilanciatore del carico che gestisce il traffico per Apigee.
Cloud CDN può essere utilizzato con qualsiasi opzione discussa in questo documento. La il seguente diagramma mostra l'architettura di esempio iniziale di WAAP con aggiunta di Cloud CDN.
Il flusso di richieste mostrato nel diagramma precedente è il seguente:
- 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.
- Cloud CDN controlla la cache con la chiave cache e restituisce la risposta se l'successo della cache è true.
- 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.
- Google Cloud Armor è integrato con reCAPTCHA, che valuta il traffico legittimo in entrata con punteggi di rischio. Per traffico non legittimo, Google Cloud Armor può rifiutare la richiesta.
- Se non ci sono violazioni delle regole di Google Cloud Armor, il bilanciatore del carico delle applicazioni esterno instrada la richiesta ad Apigee.
- 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.
- 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.
- Apigee invia la richiesta ai backend del data center privato tramite Cloud Interconnect.
- Apigee invia la richiesta ai servizi di terze parti tramite il provisioning dell'indirizzo IP NAT di Apigee.
- 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
- Scopri di più sulle opzioni di provisioning di Apigee.
- Scopri di più sulla sicurezza delle API a più livelli con Apigee e Google Cloud Armor.
- Scopri come effettuare la pubblicazione API globali ad alte prestazioni con Apigee X e Cloud CDN.
- Leggi e fai domande nel Community Apigee.
- Esplora il Repository Apigee su GitHub.
- Per altre architetture di riferimento, diagrammi e best practice, visita il Centro architetture di Google Cloud.