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 prodotti Google Cloud:

Questo documento è destinato agli architetti delle API, agli architetti della sicurezza e ai responsabili tecnici che gestiscono l'infrastruttura di un'applicazione e vogliono esporre API sicure, scalabili ed efficaci.

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 protezione di app web e API (WAAP), una soluzione di sicurezza completa che puoi utilizzare per proteggere le tue applicazioni e le tue API.

Questo documento presuppone la conoscenza di networking, API e Google Cloud.

Gestione delle API Apigee

Apigee è una piattaforma per lo sviluppo e la gestione di API. Aggiungendo un livello proxy ai servizi, Apigee fornisce un'astrazione o un'estensione 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 consentiti. Come mostrato nell'immagine seguente, gli utenti possono interagire con un'applicazione e dati e servizi sono 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 con picchi
    • 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, 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 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 di Apigee per proteggere le tue API. Le norme sono le seguenti:

  • Gestione del traffico. Aiuta a configurare la memorizzazione nella cache, controllare le quote, attenuare 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 proteggere il backend da malintenzionati.
  • Sicurezza. Ti aiuta a controllare l'accesso alle tue API.

Puoi collegare uno o più di questi criteri al livello proxy. La seguente tabella elenca i casi d'uso della sicurezza per ciascun criterio, classificati per tipo di criterio.

Tipo di criterio Nome del criterio Caso d'uso sulla sicurezza
Gestione del traffico <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-crypt-href="wwJSt9qVSU86+j+K5hdeMDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8IABOMtQ Applica la limitazione di frequenza al numero di richieste inviate al backend.
Gestione del traffico <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-crypt-href="yfev46B745dkygzs/X3PYjuonRA/XAWCehsxho1ekoeCtp+MpvBtrackWLink-NeoeCtp+MpvBtrackWDFs8Fs8FA Aiuta la tua organizzazione ad applicare le quote (il numero di chiamate API effettuate) per ogni consumer.
Gestione del traffico criterio Memorizza nella cache le risposte, riducendo il numero di richieste al backend.
Protezione a livello di messaggio criterio 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 criterio 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 hanno il formato corretto.
Protezione a livello di messaggio <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="gJQUlh/pVJ3nw/DE2jI8yjuonRA/XAWCehsxho1ekoeCtp+MpvB2trackQFs82FOM Contribuisce a ridurre il rischio di attacchi a livello di contenuto consentendo di specificare limiti sulle strutture JSON come array e stringhe.
Protezione a livello di messaggio <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="Ev6aAOEX4vzZEHynKB7CyzuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8LFOGOMTQ Aiuta ad affrontare le vulnerabilità XML e a mitigare il rischio di attacchi valutando i contenuti dei messaggi e rilevando messaggi corrotti o in formato non corretto prima di poter essere analizzati.
Protezione a livello di messaggio <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadataposition" l10n-encrypted-href="gJQUlh/pVJ3nw/DE2jI8yjuonRA/XAWCehsxho1ekoeCtp+MpvB2Dtrackilbody2Q Valuta i contenuti in base a espressioni regolari predefinite e li rifiuta se l'espressione è vera.
Sicurezza <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="r3pD7LpDHbEckDP2z0dAEDuonRA/XAWCehsxho1ekoeCtp+MpvAutenticazioneB2DQFs8FAs8FA Base64 codifica e decodifica le credenziali utente.
Sicurezza <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-crypt-href="sNIOJtAt5FZdwfenZs4WsDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8metadata-position"criterioFZdwfenZs4WsDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFsbbiDWEOM Applica la verifica e la convalida delle chiavi API in fase di runtime. Consente solo le applicazioni con chiavi API approvate associate ai prodotti <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="408dbk6WV0fWZ26OogAdmO6/+F4vggx0AzbtracknRBncBKef5
Sicurezza <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-crypt-href="1Tp726mCvkMuEnFlF5rt4zuonRA/XAWCehsxho1ekoeCtp+MpvB2trackE48yFs8FA Esegue operazioni sui tipi di autorizzazione OAuth 2.0 per generare e convalidare i token di accesso.
Sicurezza <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="sNIOJtAt5FZdwfenZs4WsDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8QOMtp+MpvB2DFs8FANOMtp Genera, verifica e decodifica i token JWT (JSON Web Tokens) e le firme web JSON (JWS).
Sicurezza <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-crypt-href="uT7Wlj+BBoD8kfn3kHjQDDuonRA/XAWCehsxho1ekoeCtp+MpvB2DQM4practices8VFoD8kfn3kHjQDDuonRA/XAWCehsxho1ekoeCtp+MpvB2DQMFs8V Calcola e verifica il codice HMAC (Hash-based Message Authentication Code) per l'autenticazione e i controlli di integrità a livello di applicazione.
Sicurezza <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-crypt-href="sNIOJtAt5FZdwfenZs4WsDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFsbbil5/FAOM
  • Convalida i messaggi in arrivo che contengono un'asserzione SAML con firma digitale.
  • Genera asserzioni SAML per le richieste XML in uscita.
Sicurezza <atrack-type="bestpractices" l10n-attrs-original-order="href,CORStrack-type,track-name,track-metadata-position" l10n-encrypted-href="uT7Wlj+BBoD8kfn3kHjQDDuonRA/XAWCehsxho1ekoeCtp+MpvtrackB2DQFs8FAspositiondtrackB2DQFs8FA Ti consente di impostare <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="h61XYN2JabzN6Gs65pqwthXSVh+mabqTVA5/45yLR2rpnjkRTZBLB1hposition attraverso le risorse web-origin.

Ti consigliamo di utilizzare Google Cloud Armor per controllo dell'accesso basato su indirizzi 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 dell'archivio chiavi, che ti consente di configurare l'archivio chiavi e l'archivio di attendibilità per gli handshake TLS.

Puoi utilizzare Apigee per creare prodotti API che ti consentono di raggruppare le operazioni API e di renderle disponibili per l'uso 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ò limitare l'accesso anche tramite metodi HTTP e 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 un'operazione POST solo sull'endpoint /v1/payments, in questo caso https://$DOMAIN/v1/payments. In un altro esempio, le applicazioni di call center utilizzate dal personale dei call center possono eseguire operazioni come PUT o DELETE sull'endpoint /payments, come https://$DOMAIN/v1/payments/1234, per annullare 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.

Esempio di architettura di microservizi con servizi distribuiti in data center e cloud provider.

L'architettura iniziale è la seguente:

  • I servizi per 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 presenta i seguenti vincoli:

  • È improbabile che venga scalata.
  • È improbabile che protegga 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 consumatori implementando un insieme standard di criteri di sicurezza su tutte le API. Questa sezione illustra le best practice per l'utilizzo di Apigee per proteggere le tue API.

Usa Apigee come livello proxy

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

Apigee come livello proxy.

Viene eseguito il provisioning di Apigee in un progetto Google Cloud, mentre viene eseguito il provisioning del runtime e ne viene eseguito il peering in un progetto tenant mediante il peering di rete VPC. Per proteggere il 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:

  1. Il client 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. Il bilanciatore del carico instrada la richiesta ad Apigee.
  3. Apigee elabora la richiesta, esegue i criteri di sicurezza come descritto 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 sia al client sia alla richiesta.
  4. 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), poiché si trova all'interno della rete in peering.
  5. Apigee invia la richiesta ai backend dei data center privati tramite Cloud Interconnect.
  6. Apigee invia la richiesta ai servizi di terze parti tramite il provisioning degli indirizzi IP di 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 di Google Cloud. Fornisce funzionalità web application firewall (WAF) e aiuta a prevenire gli attacchi DDoS (Distributed Denial of Service). Può anche aiutarti a mitigare la minaccia alle applicazioni dai rischi elencati in OWASP Top 10.

Puoi configurare regole e criteri in Google Cloud Armor per valutare ogni chiamata effettuata dal client che contatta l'Application Load Balancer 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 attivi:

Architettura con Google Cloud Armor.

Il flusso degli eventi in questa architettura è simile a quello discusso in Utilizzare Apigee come livello proxy in precedenza in questo documento. Ecco il flusso di richiesta:

  1. Il client 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. Google Cloud Armor filtra la richiesta perché è abilitato dal bilanciatore del carico delle applicazioni esterno. Applica e valuta tutte le regole e i criteri configurati. Se una regola viene violata, Google Cloud Armor rifiuta la richiesta e restituisce un messaggio di errore e un codice di stato.
  3. Se non sono presenti violazioni delle regole di Google Cloud Armor, l'Application Load Balancer esterno instrada la richiesta ad Apigee.
  4. 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 o sia al client che alla richiesta.
  5. Apigee inoltra la richiesta direttamente ai backend GKE tramite indirizzi IP interni. La comunicazione tra Apigee e il servizio di trasferimento di denaro può avvenire su un indirizzo RFC 1918 (indirizzo IP interno) perché si trova all'interno della rete in peering.
  6. Apigee invia la richiesta ai backend dei data center privati tramite Cloud Interconnect.
  7. Apigee invia la richiesta ai servizi di terze parti tramite il provisioning degli indirizzi IP di Apigee NAT.

Utilizza WAAP

Per migliorare ulteriormente il tuo profilo di sicurezza, puoi anche utilizzare WAAP, che riunisce Google Cloud Armor, reCAPTCHA Enterprise e Apigee per proteggere il tuo sistema da bot e attacchi DDoS. 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 Enterprise per generare un token reCAPTCHA Enterprise e inviarlo quando effettuano una richiesta.

Il seguente diagramma mostra il flusso di lavoro:

Flusso di richiesta per WAAP.

Il flusso di richiesta nel diagramma precedente è il seguente:

  • (1) Tutte le richieste HTTP(S) da parte di clienti e consumer di 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 dai criteri di Google Cloud Armor, viene inviata una richiesta all'API reCAPTCHA Enterprise 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 aver valutato le regole OWASP di Google Cloud Armor e la 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 Enterprise e Apigee per le richieste API.

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

Il flusso di richiesta nel diagramma precedente è il seguente:

  1. Il client 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. Poiché il bilanciatore del carico delle applicazioni esterno ha Google Cloud Armor abilitato, Google Cloud Armor seleziona la richiesta. Applica e valuta tutte le regole e i criteri configurati. 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 come l'invio di un modulo per una pagina di accesso, Google Cloud Armor è integrato con reCAPTCHA Enterprise. reCAPTCHA Enterprise 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 sono presenti 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 rifiuta la richiesta. Apigee può anche essere utilizzato per instradare la richiesta a backend diversi in base al client, alla richiesta o sia al client sia alla richiesta.
  6. 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 all'interno della rete in peering.
  7. Apigee invia la richiesta ai backend dei data center privati tramite Cloud Interconnect.
  8. 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 contenuti più vicino agli utenti, velocizzando i tempi di risposta per siti web e 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 sul perimetro della rete Google, mantiene i dati il più vicini possibile agli utenti e consente l'accesso più rapido possibile.

Cloud CDN aiuta inoltre le organizzazioni a gestire senza problemi i picchi stagionali di traffico, ad esempio i picchi che possono verificarsi durante le festività o il rientro a scuola. Questo approccio alla memorizzazione nella cache contribuisce a migliorare l'affidabilità e l'esperienza utente in un ecosistema. Inoltre, consente di ridurre al minimo il carico, le risorse di calcolo e l'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. Il seguente diagramma mostra l'architettura di esempio iniziale di WAAP con l'aggiunta di Cloud CDN.

Flusso di richiesta con Cloud CDN.

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

  1. Il client utilizza le librerie reCAPTCHA Enterprise per ricevere 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.
  2. Cloud CDN controlla la cache con la chiave cache e restituisce la risposta se l'hit della cache è vero.
  3. Se l'hit della cache è false, Google Cloud Armor filtra la richiesta perché nel bilanciatore del carico delle applicazioni esterno è abilitato Google Cloud Armor. 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.
  4. Google Cloud Armor è integrato con reCAPTCHA Enterprise, 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 sono presenti 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 nella gestione delle API Apigee e consente o nega la richiesta. Può essere utilizzato anche per instradare la richiesta a backend diversi in base al client, alla richiesta o sia al client sia alla richiesta.
  7. 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 trova all'interno della rete in peering.
  8. Apigee invia la richiesta ai backend dei data center privati tramite Cloud Interconnect.
  9. Apigee invia la richiesta ai servizi di terze parti tramite il provisioning degli indirizzi IP di Apigee NAT.
  10. Quando una risposta torna al client, Cloud CDN la memorizza nella cache in modo che possa restituire la risposta dalla cache per le chiamate future.

Passaggi successivi