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 API Architect, Security Architect e tecnici che gestiscono l'infrastruttura di un'applicazione e vogliono per esporre API sicure, scalabili ed efficienti.
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 per l'utilizzo di Web app and API Protection (WAAP), una soluzione di sicurezza completa che puoi utilizzare per aiutarti a proteggere le tue applicazioni e le tue API.
In questo documento si presuppone che tu abbia familiarità con networking, API e in Google Cloud.
Gestione delle API Apigee
Apigee è una piattaforma per lo sviluppo e la gestione di API. Di aggiungendo un livello proxy ai tuoi servizi, Apigee fornisce un'astrazione o un fac che ti aiuta a proteggere le API dei servizio di backend.
Gli utenti possono interagire con le applicazioni utilizzando OAuth 2.0 e un indirizzo IP consentito intervalli di tempo. Come mostrato nell'immagine seguente, gli utenti possono interagire con un'applicazione, e dati e 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 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 limitazione di frequenza, criteri di protezione dalle minacce e configurare TLS al backend del livello API.
Per aiutarti a gestire l'accesso per 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 Apigee criteri predefiniti per proteggere le 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. Ti consente di ispezionare e convalidare la richiesta payload per contribuire a proteggere il tuo backend da malintenzionati.
- Sicurezza. Aiuta a controllare l'accesso alle API.
Puoi collegare uno o più di questi criteri al livello proxy. Le seguenti che elenca il caso d'uso della sicurezza per ciascun criterio, classificati per tipo di criterio.
| Tipo di criterio | Nome del 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 consumatore. |
| 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 OpenAPI 3.0 specifica (JSON o YAML). |
| Protezione a livello di messaggio | Criteri di SOAPMessageValidation | Convalida i messaggi XML in base a uno schema a tua scelta. Convalida SOAP a fronte di un WSDL e determina se i messaggi JSON e XML vengono formato correttamente. |
| Protezione a livello di messaggio | Criterio JSONThreatProtection | Contribuisce a 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 | 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 | Criterio 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 i token web JSON Firme (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 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 per l'applicazione per il consumo. Un prodotto API raggruppa uno 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. definendo una o più API
in un'applicazione per sviluppatori, puoi limitare l'accesso ai proxy con
chiave API. Ad esempio, le app mobile utilizzate dai clienti possono
esegui 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 distribuiti nel data center e nel cloud provider. Le seguenti best practice per l'architettura mostrano come eseguire l'iterazione e migliorare la versione iniziale dell'architettura.
L'architettura iniziale è la seguente:
- I servizi di pagamento e account sono ospitati nel data center e 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 all'app di backend o di terze parti 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 i 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 Apigee come livello proxy (facade):
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 sistema, anziché inviare i dati tramite internet, può utilizzare Apigee come livello proxy per stabilire una connessione diretta (privata) nel 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 dell'applicazione, ad esempio una chiave, un token 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 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.
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 è parte dell'infrastruttura di bilanciamento del carico globale per Google Cloud. it fornisce funzionalità WAF (Web Application Firewall) e aiuta a prevenire dagli attacchi DDoS (Denial of Service). Può anche aiutarti a mitigare la minaccia per le applicazioni dai rischi elencati 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 automatizzano anche la configurazione dei criteri di Google Cloud Armor. Per maggiori informazioni su come configurare le regole in Google Cloud Armor, consulta Google Cloud Armor Guide illustrative.
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 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é l'Application Load Balancer esterno che la funzionalità sia abilitata. 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 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 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.
Usa 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. Offre inoltre WAF e API protezione dei dati.
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 richiesta nel diagramma precedente è il seguente:
- (1) Tutte le richieste HTTP(S) dei clienti e dei consumer delle API vengono inviate alla il 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 di un backend cloud.
- (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 le regole OWASP di Google Cloud Armor e gli attacchi DDoS protezione dei dati, 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 è è 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 richiesta nel diagramma precedente è il seguente:
- Il client invia la richiesta al bilanciatore del carico delle applicazioni esterno con le credenziali dell'applicazione, ad esempio una chiave, un token certificato.
- Poiché nel bilanciatore del carico delle applicazioni esterno è abilitato Google Cloud Armor, Google Cloud Armor e seleziona la richiesta. Applica e valuta tutte le regole configurate criteri. 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 come 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 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 dei data center privati tramite Cloud Interconnect.
- Apigee invia la richiesta a servizi di terze parti tramite Provisioning degli indirizzi IP Apigee NAT.
Usa Cloud CDN per la memorizzazione nella cache
Cloud CDN utilizza la rete globale di Google per offrire contenuti più vicino agli utenti, 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 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 anche le organizzazioni a gestire senza problemi i picchi stagionali di traffico ad esempio, i picchi che possono verificarsi durante le vacanze o il rientro a scuola in stagioni diverse. Questo approccio alla memorizzazione nella cache aiuta a migliorare l'affidabilità e esperienza in un ecosistema. Può anche aiutare a ridurre al minimo il carico del server web, calcolo e utilizzo 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. La il seguente diagramma mostra l'architettura di esempio iniziale di WAAP con 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 una richiesta al bilanciatore del carico delle applicazioni esterno con le credenziali dell'applicazione, ad esempio una chiave, un token o certificato.
- Cloud CDN controlla la cache con la chiave cache e restituisce la risposta se l'successo della cache è true.
- Se il successo della cache è false, Google Cloud Armor filtra la richiesta perché se sul bilanciatore del carico delle applicazioni esterno è abilitato Google Cloud Armor. Google Cloud Armor applica e valuta tutte le regole e i criteri configurati. Se presente 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 legittimo in entrata con punteggi di rischio. Per 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 ad Apigee.
- Apigee elabora la richiesta, esegue i criteri di sicurezza come descritti in Gestione delle API Apigee, e consente o rifiutano la richiesta. Può essere utilizzato anche per instradare la richiesta a backend diversi in base al client, alla richiesta o a entrambi e 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é 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 l'indirizzo IP Apigee NAT per eseguire il provisioning.
- Quando una risposta torna al client, Cloud CDN la memorizza nella cache in modo restituisce la risposta dalla cache per le chiamate future.
Passaggi successivi
- Scopri di più su Opzioni di provisioning Apigee.
- Informazioni Sicurezza delle API multilivello 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, esplora il Centro architetture cloud.