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 è rivolto ad API Architect, Security Architect e responsabili tecnici che gestiscono l'infrastruttura di un'applicazione e vogliono esporre API sicure, scalabili ed efficienti.
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 best practice per l'utilizzo della Web app and API Protection (WAAP), una soluzione di sicurezza completa che puoi usare per proteggere applicazioni e API.
In questo documento si 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 un'interfaccia che ti aiuta a proteggere le API dei tuoi servizio di backend.
Gli utenti possono interagire con le applicazioni utilizzando OAuth 2.0 e con intervalli di indirizzi IP consentiti. Come mostrato nell'immagine seguente, gli utenti possono interagire con un'applicazione e i dati e i servizi sono 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 per picco
- 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 una limitazione di frequenza, criteri di protezione dalle minacce e configurare TLS reciproco al backend del tuo livello API.
Per aiutarti a gestire l'accesso per un team API all'interno della piattaforma Apigee, Apigee offre controllo dell'accesso basato sui ruoli (RBAC) e l'accesso federato.
Ti consigliamo di utilizzare i criteri predefiniti Apigee per proteggere le tue API. Le norme sono le seguenti:
- Gestione del traffico. Consente di configurare la memorizzazione nella cache, controllare le quote, mitigare gli effetti dei picchi e controllare il traffico delle API.
- Protezione a livello di messaggio. Consente di ispezionare e convalidare i payload delle richieste per contribuire a proteggere il backend da utenti malintenzionati.
- Sicurezza. Aiuta a controllare l'accesso alle API.
Puoi collegare uno o più di questi criteri al livello proxy. Nella tabella seguente sono elencati i casi d'uso relativi alla sicurezza per ciascun criterio, classificati per tipo di criterio.
| Tipo di criterio | Nome criterio | Caso d'uso della sicurezza |
|---|---|---|
| Gestione del traffico | Criterio di SpikeArrest | Applica la limitazione 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 consumer. |
| Gestione del traffico | Criterio diResponseCache | 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 rispetto 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 a fronte di un WSDL e determina se i messaggi JSON e XML sono formati correttamente. |
| Protezione a livello di messaggio | Criterio JSONThreatProtection | Aiuta a mitigare il rischio di attacchi a livello di contenuto consentendoti di specificare limiti sulle 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 il contenuto dei messaggi e rilevando i messaggi corrotti o non corretti prima che possano essere analizzati. |
| Protezione a livello di messaggio | Criterio RegularExpressionProtection | Valuta i contenuti in base a espressioni regolari predefinite e li rifiuta se l'espressione è true. |
| 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. Consente solo alle applicazioni con chiavi API approvate e 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 i token di accesso. |
| 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 l'autenticazione e i controlli di integrità a livello di applicazione. |
| Sicurezza | Criterio SAMLAssertion |
|
| Sicurezza | Criterio CORS | Consente di impostare le intestazioni di condivisione delle risorse tra origini (CORS) per le API utilizzate dalle applicazioni web. |
Ti consigliamo di utilizzare Google Cloud Armor percontrollo dell'accessoi basato su indirizzi IP e dati geografici. Tuttavia, nei casi in cui non sia possibile, puoi utilizzare il criterio AccessControl. Per aiutarti a proteggere le connessioni da Apigee al tuo backend, Apigee fornisce anche la gestione degli archivi chiavi, che consente di configurare l'archivio chiavi e l'archivio chiavi per gli handshake TLS.
Puoi utilizzare Apigee per creare prodotti API che ti consentono di raggruppare le operazioni API e renderle disponibili agli sviluppatori di applicazioni per il consumo. 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 tramite metodi HTTP e 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 app mobile utilizzate dai clienti possono eseguire un'operazione POST solo sull'endpoint /v1/payments, in questo caso https://$DOMAIN/v1/payments. In un altro esempio, le applicazioni dei call center utilizzate dal personale dei call center possono eseguire operazioni come PUT o DELETE sull'endpoint /payments, ad esempio https://$DOMAIN/v1/payments/1234, per ripristinare o annullare 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 cloud provider. Le seguenti best practice per l'architettura mostrano come eseguire l'iterazione e migliorare l'architettura iniziale.
L'architettura iniziale è la seguente:
- I servizi di pagamento 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.
- L'Application Load Balancer 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 sia scalabile.
- È improbabile proteggere un sistema da attacchi dannosi
- Non riflette best practice coerenti per la sicurezza e il logging 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 criteri di sicurezza in tutte le API. Questa sezione illustra le best practice per l'utilizzo di Apigee al fine di proteggere le API.
Usa Apigee come livello proxy
Il seguente diagramma mostra l'architettura iniziale con l'aggiunta del livello proxy (facade) Apigee:
Il provisioning di Apigee viene eseguito in un progetto Google Cloud e viene eseguito il provisioning e il peering del runtime in un progetto tenant utilizzando il peering di rete VPC. Per contribuire a proteggere il tuo sistema, invece di inviare i dati attraverso internet, puoi utilizzare Apigee come livello proxy per stabilire una connessione diretta (privata) al tuo data center utilizzando Cloud Interconnect.
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.
- Il bilanciatore del carico instrada la richiesta ad Apigee.
- Apigee elabora la richiesta, esegue i criteri di sicurezza descritti nella 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. Le comunicazioni tra Apigee e il servizio di trasferimento di denaro possono avvenire su un indirizzo RFC 1918 (indirizzo IP interno) perché si trovano all'interno della 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 il provisioning degli indirizzi IP Apigee NAT.
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 aiuta a prevenire gli attacchi DDoS (Distributed Denial of Service). Inoltre, può aiutarti a mitigare la minaccia per le applicazioni dai rischi elencati nella pagina 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 illustrative di Google Cloud Armor.
Il seguente diagramma mostra l'architettura di esempio con Apigee e Google Cloud Armor:
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 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.
- Google Cloud Armor filtra la richiesta perché è abilitata nel bilanciatore del carico delle applicazioni esterno. Applica e valuta tutte le regole e i criteri configurati. Se una qualsiasi regola viene violata, Google Cloud Armor rifiuta la richiesta e ti fornisce un messaggio di errore e un codice di stato.
- Se non si verificano violazioni delle regole di Google Cloud Armor, l'Application Load Balancer esterno instrada la richiesta ad Apigee.
- Apigee elabora la richiesta, esegue i criteri di sicurezza e consente o rifiuta la richiesta. Può anche essere utilizzato per instradare la richiesta a backend diversi in base al client, alla richiesta oppure a entrambi il client e la richiesta.
- Apigee inoltra la richiesta ai backend GKE direttamente tramite indirizzi IP interni. Le comunicazioni tra Apigee e il servizio di trasferimento di denaro possono avvenire su un indirizzo RFC 1918 (indirizzo IP interno) perché si trovano all'interno della 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 il provisioning degli indirizzi IP Apigee NAT.
Usa WAAP
Per migliorare ulteriormente il tuo profilo di sicurezza, puoi anche utilizzare WAAP, che riunisce Google Cloud Armor, reCAPTCHA e Apigee per proteggere il tuo sistema da attacchi DDoS e bot. Offre 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.
Questo diagramma seguente mostra il flusso di lavoro:
Il flusso di richiesta 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 della 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 backend.
- (2b) Se la richiesta non è legittima, Google Cloud Armor può rifiutare la richiesta e inviare un codice di risposta 403 all'utente.
- (3b) Per qualsiasi richiesta API, dopo la valutazione delle regole OWASP di Google Cloud Armor e della protezione DDoS, 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, 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 richiesta 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é Google Cloud Armor è abilitato per il bilanciatore del carico delle applicazioni esterno, Google Cloud Armor seleziona la richiesta. Applica e valuta tutte le regole e i criteri configurati. Se una qualsiasi regola viene violata, Google 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, 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 si verificano violazioni delle regole di Google Cloud Armor, l'Application Load Balancer esterno instrada la richiesta API ad Apigee.
- Apigee elabora la richiesta, esegue i criteri di sicurezza e consente o rifiuta 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. Le comunicazioni tra Apigee e il servizio di trasferimento di denaro possono 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 dei data center privati tramite Cloud Interconnect.
- Apigee invia la richiesta a servizi di terze parti tramite il provisioning degli indirizzi IP Apigee NAT.
Usa Cloud CDN per la memorizzazione nella cache
Cloud CDN utilizza la rete globale di Google per fornire i contenuti più vicino agli utenti, accelerando i tempi di risposta per i tuoi siti web e le 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 Google Front End (GFE) , che si trova sul perimetro della rete Google, i dati vengono conservati il più vicino possibile agli utenti e consentono l'accesso più rapido possibile.
Inoltre, Cloud CDN aiuta le organizzazioni a gestire senza problemi i picchi stagionali di traffico, ad esempio quelli che potrebbero verificarsi durante le festività o il rientro a scuola. Questo approccio alla memorizzazione nella cache migliora l'affidabilità e l'esperienza utente in un ecosistema. Può anche aiutare a ridurre al minimo il carico del server web, il computing e l'uso 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 qualsiasi opzione descritta in questo documento. Il seguente diagramma 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 cache e restituisce la risposta se il successo della cache è vero.
- Se il successo della cache è false, 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 una regola viene violata, la richiesta viene rifiutata con un messaggio di errore e un codice di stato.
- Google Cloud Armor è integrato con reCAPTCHA, che valuta il traffico in entrata legittimo con punteggi di rischio. Se il traffico non è legittimo, Google Cloud Armor può rifiutare la richiesta.
- Se non si verificano 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 descritti nella 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 oppure sia al client che alla richiesta.
- Apigee inoltra la richiesta ai backend GKE direttamente tramite indirizzi IP interni. Le comunicazioni tra Apigee e il servizio di trasferimento di denaro possono 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 dei data center privati tramite Cloud Interconnect.
- Apigee invia la richiesta a servizi di terze parti tramite il provisioning degli indirizzi IP Apigee NAT.
- Quando una risposta torna al client, Cloud CDN la memorizza nella cache in modo da poter restituire la risposta dalla cache per le chiamate future.
Passaggi successivi
- Scopri di più sulle opzioni di provisioning Apigee.
- Scopri di più sulla sicurezza delle API multilivello con Apigee e Google Cloud Armor.
- Scopri come fornire API globali ad alte prestazioni con Apigee X e Cloud CDN.
- Leggi e fai domande nella community Apigee.
- Esplora il Repository Apigee su GitHub.
- Per altre architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.