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 prodotti Google Cloud :
Questo documento è destinato ad architetti API, architetti della sicurezza e responsabili dell'ingegneria che gestiscono l'infrastruttura di un'applicazione e che vogliono esporre API sicure, scalabili e performanti.
Questo documento utilizza una serie di architetture di esempio per illustrare le best practice per l'utilizzo della gestione delle API Apigee. Questo documento illustra anche le best practice per l'utilizzo di Web App and API Protection (WAAP), una soluzione di sicurezza completa che puoi utilizzare per proteggere le tue applicazioni e le tue API.
Questo documento presuppone che tu abbia familiarità con il networking, le API e Google Cloud.
Gestione delle API Apigee
Apigee è una piattaforma per lo sviluppo e la gestione di API. Aggiungendo un livello proxy ai tuoi servizi, Apigee fornisce un'astrazione o una facciata che ti aiuta a proteggere le API servizio di backend.
Gli utenti possono interagire con le applicazioni utilizzando OAuth 2.0 e intervalli di indirizzi IP consentiti. 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 tramite indirizzo IP
- Applicazioni
- Chiavi API
- OAuth 2.0
- TLS
- Sviluppatori e partner
- SSO
- RBAC
- API
- OAuth 2.0
- OpenID Connect
- Quote
- Arresto di Spike
- Protezione dalle minacce
- team API
- RBAC IAM
- Logica federata
- Mascheramento dei dati
- Audit log
- Backend
- Networking privato
- Mutual TLS
- Controllo dell'accesso tramite indirizzo IP
Come mostrato nell'immagine precedente, puoi utilizzare diversi meccanismi di sicurezza in un'applicazione, ad esempio la chiave API o OAuth 2.0 con Transport Layer Security (TLS). Puoi anche aggiungere criteri di limitazione di frequenza, protezione dalle minacce e configurare TLS reciproco per il backend del livello API.
Per aiutarti a gestire l'accesso per un team API all'interno della piattaforma Apigee, Apigee disponecontrollo dell'accessoi basato sui ruoli (RBAC) e dell'accesso federato.
Ti consigliamo di utilizzare le norme predefinite di Apigee per proteggere le tue API. I criteri sono i seguenti:
- Gestione del traffico. Ti aiuta a configurare la memorizzazione nella cache, controllare le quote, mitigare gli effetti dei picchi e controllare il traffico API.
- Protezione a livello di messaggio. Consente di ispezionare e convalidare i payload delle richieste per proteggere il backend da utenti malintenzionati.
- Sicurezza. Ti aiuta a controllare l'accesso alle tue API.
Puoi allegare uno o più di questi criteri al tuo livello proxy. La seguente tabella elenca il caso d'uso per la sicurezza per ogni norma, suddiviso per tipo di norma.
| Tipo di criterio | Nome del criterio | Caso d'uso relativo alla sicurezza |
|---|---|---|
| Gestione del traffico | Norme SpikeArrest | Applica la limitazione di frequenza al numero di richieste inviate al backend. |
| Gestione del traffico | Criteri per le quote | Aiuta la tua organizzazione a imporre quote (il numero di chiamate API effettuate) per ogni consumer. |
| Gestione del traffico | Norme ResponseCache | Memorizza nella cache le risposte, riducendo il numero di richieste al backend. |
| Protezione a livello di messaggio | Norme OASValidation | Convalida le richieste o i messaggi di risposta in entrata in base a una specifica OpenAPI 3.0 (JSON o YAML). |
| Protezione a livello di messaggio | Norme SOAPMessageValidation | Convalida i messaggi XML in base a uno schema a tua scelta. Convalida i messaggi SOAP in base a un WSDL e determina se i messaggi JSON e XML sono formattati correttamente. |
| Protezione a livello di messaggio | Policy JSONThreatProtection | Consente di ridurre 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 XMLThreatProtection | Ti aiuta a risolvere le vulnerabilità XML e a mitigare il rischio di attacchi valutando i contenuti dei messaggi e rilevando i messaggi danneggiati o con errori di formato prima che possano essere analizzati. |
| Protezione a livello di messaggio | Norme RegularExpressionProtection | Valuta i contenuti in base alle espressioni regolari predefinite e li rifiuta se l'espressione è vera. |
| Sicurezza | Norme BasicAuthentication | Codifica e decodifica Base64 delle credenziali utente. |
| Sicurezza | Norme 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 di tipo 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 l'autenticazione e i controlli di integrità a livello di applicazione. |
| Sicurezza | Norme SAMLAssertion |
|
| Sicurezza | Criterio CORS | Consente di impostare le intestazioni CORS (Cross-Origin Resource Sharing) per le API utilizzate dalle applicazioni web. |
Ti consigliamo di utilizzare Cloud Armor per controllo dell'accesso basato su IP e dati geografici. Tuttavia, nei casi in cui non è possibile, puoi utilizzare 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 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 alla quota.
Utilizzi i prodotti API per controllare l'accesso alle tue API. Definendo 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 del call center possono eseguire operazioni come PUT o DELETE sull'endpoint /payments, ad esempio https://$DOMAIN/v1/payments/1234, per annullare
o invertire i pagamenti.
Architettura iniziale
Questa sezione descrive un esempio di architettura di microservizi con i servizi di cui è stato eseguito il deployment nel data center e nel provider di servizi cloud. Le seguenti best practice per l'architettura mostrano come puoi eseguire l'iterazione e migliorare l'architettura iniziale.
L'architettura iniziale è la seguente:
- I servizi di pagamento e account sono ospitati nel data center e il servizio di trasferimento di denaro è ospitato in Google Cloud.
- Il bilanciatore del carico delle applicazioni esterno controlla e configura il traffico in entrata ai servizi.
- Il bilanciatore del carico delle applicazioni esterno inoltra la richiesta al backend o al servizio di terze parti appropriato e gestisce l'handshake TLS.
Nello stato iniziale, l'architettura di esempio presenta i seguenti vincoli:
- È improbabile che venga scalato.
- È improbabile che protegga un sistema da attacchi dannosi
- Non riflette best practice coerenti per la sicurezza e la registrazione perché questi servizi sono 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 tuoi consumatori implementando un insieme standard di norme 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 viene sottoposto a provisioning in un progetto Google Cloud e il runtime viene sottoposto a provisioning e a peering in un progetto tenant utilizzando il peering di rete VPC. Per proteggere il tuo sistema, anziché inviare 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 descritto in Gestione delle API Apigee e consente o nega la richiesta. Apigee può essere utilizzato anche per instradare la richiesta a backend diversi in base al client, alla richiesta o a entrambi.
- 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 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 il provisioning dell'indirizzo IP NAT di Apigee.
Utilizzare Cloud Armor come livello WAF con Apigee
Puoi aggiungere Cloud Armor all'architettura per aumentare il perimetro di sicurezza. Cloud Armor fa parte dell'infrastruttura di bilanciamento del carico globale per Google Cloud. Fornisce funzionalità WAF (web application firewall) e contribuisce a prevenire gli attacchi DDoS (Distributed denial of service). Può anche aiutarti a mitigare la minaccia alle applicazioni derivante dai rischi elencati nell'OWASP Top 10.
Puoi configurare regole e criteri in 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 Cloud Armor. Per ulteriori informazioni su come configurare le regole in Cloud Armor, consulta le guide pratiche di Cloud Armor.
Il seguente diagramma mostra l'architettura di esempio con Apigee e Cloud Armor in posizione:
Il flusso di eventi in questa architettura è simile a quelli descritti in Utilizzare Apigee come livello proxy in precedenza in questo documento. Il flusso di richieste è 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.
- Cloud Armor filtra la richiesta perché il bilanciatore del carico delle applicazioni esterno lo ha abilitato. Applica e valuta tutte le regole e le norme configurate. Se una regola viene violata, Cloud Armor rifiuta la richiesta e restituisce un messaggio di errore e un codice di stato.
- Se non ci sono violazioni delle regole di 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 indirizzare la richiesta a backend diversi in base al client, alla richiesta o a entrambi.
- 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 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 il provisioning dell'indirizzo IP NAT di Apigee.
Utilizzare WAAP
Per migliorare ulteriormente il tuo profilo di sicurezza, puoi anche utilizzare WAAP, che riunisce Cloud Armor, reCAPTCHA e Apigee per 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 carichino le librerie reCAPTCHA per generare un token reCAPTCHA e inviarlo quando effettuano una richiesta.
Il seguente diagramma mostra il flusso di lavoro:
Il flusso di richieste nel diagramma precedente è il seguente:
- (1) Tutte le richieste HTTP(S) di clienti e consumer di API vengono inviate al bilanciatore del carico delle applicazioni esterno.
- (2) Il primo punto di contatto della soluzione WAAP è Cloud Armor.
- (2a) Se nessuna di queste regole viene attivata dai criteri 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, questa viene inoltrata al backend.
- (2b) Se la richiesta non è legittima, 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 Cloud Armor, la richiesta viene inoltrata ad Apigee per verificare la validità della richiesta API.
- (4) Apigee determina se le chiavi API o i token di accesso utilizzati nella richiesta sono validi. Se Apigee determina 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 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 Cloud Armor abilitato, Cloud Armor seleziona la richiesta. Applica e valuta tutte le regole e le norme configurate. Se viene violata una regola, Cloud Armor 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, Cloud Armor è integrato con reCAPTCHA. reCAPTCHA valuta il traffico in entrata e aggiunge punteggi di rischio al traffico legittimo. Per il traffico non legittimo, Cloud Armor può rifiutare la richiesta.
- Se non vengono rilevate violazioni delle regole 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 utilizzato anche per instradare la richiesta a backend diversi in base al client, alla richiesta o a entrambi.
- 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 l'indirizzo RFC 1918, che è un indirizzo IP interno, perché entrambi si trovano 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 il provisioning dell'indirizzo IP NAT Apigee.
Utilizzare Cloud CDN per la memorizzazione nella cache
Cloud CDN utilizza la rete globale di Google per distribuire i contenuti più vicino agli utenti, il che accelera i tempi di risposta per i tuoi siti web e le tue applicazioni. Cloud CDN offre anche funzionalità di memorizzazione nella cache che consentono di proteggere il backend restituendo la risposta dalla cache. Memorizzando nella cache i dati a cui si accede di frequente in un Google Front End (GFE) , che si trova al limite della rete Google, i dati vengono conservati il più vicino possibile agli utenti e consentono l'accesso più rapido possibile.
Cloud CDN aiuta anche le organizzazioni a gestire senza problemi i picchi stagionali di traffico, ad esempio quelli che potrebbero verificarsi durante le vacanze o il periodo di rientro a 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, l'utilizzo di risorse di calcolo e della rete. Per implementare questa architettura, devi abilitare Cloud CDN sul bilanciatore del carico che gestisce il traffico per Apigee.
Cloud CDN può essere utilizzato con una qualsiasi delle opzioni descritte in questo documento. Il diagramma seguente mostra l'architettura di esempio iniziale di WAAP con l'aggiunta di Cloud CDN.
Il flusso di richiesta 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 per l'applicazione, ad esempio una chiave, un token o un certificato.
- Cloud CDN controlla la cache con la chiave della cache e restituisce la risposta se ilsuccesso della cachee è vero.
- Se il successo della cache è falso, Cloud Armor filtra la richiesta perché Application Load Balancer esterno ha Cloud Armor abilitato. Cloud Armor applica e valuta tutte le regole e le policy configurate. Se una regola viene violata, la richiesta viene rifiutata con un messaggio di errore e un codice di stato.
- Cloud Armor è integrato con reCAPTCHA, che valuta il traffico in entrata legittimo con punteggi di rischio. Per il traffico non legittimo, Cloud Armor può rifiutare la richiesta.
- Se non vengono rilevate violazioni delle regole di 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ò anche essere utilizzato per instradare la richiesta a backend diversi in base al client, alla richiesta o a entrambi.
- 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 l'indirizzo RFC 1918, che è un indirizzo IP interno, perché si trovano 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 il provisioning dell'indirizzo IP NAT di Apigee.
- Quando una risposta torna 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 multilivello con Apigee e Cloud Armor.
- Scopri come fornire API globali ad alto rendimento con Apigee X e Cloud CDN.
- Leggi e poni domande nella community di Apigee.
- Esplora il repository Apigee su GitHub.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.