Le 10 principali minacce API di OWASP

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

Questo documento descrive i vari approcci che puoi utilizzare all'interno di Apigee per risolvere le vulnerabilità di sicurezza identificate da OWASP. Per ulteriori approcci documentati per Apigee, consulta OWASP Top 10 2021 mitigation options on Google Cloud.

Introduzione

OWASP è una community aperta dedicata ad aiutare le organizzazioni a sviluppare, acquistare e gestire applicazioni e API affidabili. Tramite il progetto di sicurezza delle API OWASP, OWASP pubblica i rischi per la sicurezza più critici per le applicazioni web e le API REST e fornisce suggerimenti per far fronte a tali rischi.

In questo documento vengono illustrati gli approcci per la protezione dagli attacchi più comuni basati su API, identificati dalle dieci principali minacce alla sicurezza delle API nel 2019 dall'OWASP. Un tema comune tra le principali minacce evidenziate nell'elenco più recente è causato dal posizionamento improprio dei controlli di autenticazione e autorizzazione, come l'affidamento al filtraggio dei dati restituiti da una richiesta API all'interno delle app client, mediante l'anti-pattern di affidarsi all'app client in uso per eseguire l'applicazione forzata del controllo dell'accesso.

Con la crescita dell'ecosistema delle API che continua a un ritmo rapido, gli abusi e gli usi impropri delle API che comportano l'esfiltrazione di dati da parte di utenti malintenzionati stanno purtroppo diventando uno dei vettori d'attacco più comuni di oggi. La sicurezza continua a essere una priorità fondamentale per Apigee, con una serie di nuove funzionalità come Advanced API Ops, che include funzionalità di reporting sulla sicurezza e rilevamento di anomalie. Tuttavia, la progettazione e l'implementazione corretta delle funzionalità di sicurezza di Apigee è fondamentale per ridurre la probabilità di attacchi riusciti alle tue API.

Le applicazioni consumer dovrebbero essere considerate non attendibili, o "pubbliche", in quanto non hai il controllo della piattaforma su cui viene eseguita l'app. Supponiamo che qualsiasi app pubblica possa e sarà compromessa, pertanto non può essere considerata attendibile per applicare il controllo dell'accesso (API1, API5), filtrare i dati delle risposte (API6) o archiviare in modo sicuro client secret (API2) come chiavi API o token di accesso. Ecco alcuni consigli che emergono dall'esame dei primi 10 OWASP del 2019:

  • Determina il tipo di app client che utilizzeranno le tue API (SPA, per dispositivi mobili o basate su browser) e progetta i pattern di autenticazione, autorizzazione e sicurezza appropriati.
  • Utilizza sempre i flussi OAuth o OpenID Connect "client pubblico" (è vivamente consigliato l'uso di PKCE)
  • Pensa alla logica di business della tua app, definisci prima la specifica OpenAPI e progetta i proxy API per filtrare tutti i dati di risposta dal backend all'interno di Apigee. Non affidarti mai alla logica del codice dell'app downstream per eseguire questa operazione.
  • Filtra tutte le richieste di dati contenenti PII specifiche dell'utente per consentire solo i dati del tuo backend che appartengono all'utente che ha inviato la richiesta.

API1:2019 Autorizzazione a livello di oggetto inaccessibile

Descrizione minaccia

La convalida dell'autorizzazione insufficiente di una richiesta di accesso a un oggetto consente a un utente malintenzionato di eseguire un'azione non autorizzata riutilizzando un token di accesso. Questa minaccia è causata da una configurazione errata delle convalide delle autorizzazioni. Apigee fornisce criteri VerificationApiKey, OAuth e token web JSON (JWT), che aiutano a proteggere da questa vulnerabilità, ma è fondamentale che questi criteri siano configurati correttamente per prevenire questa minaccia.

Per prevenire questa minaccia, è importante che i team di sviluppo delle applicazioni e sicurezza collaborino strettamente. L'autorizzazione è per natura un argomento complesso e un'autorizzazione efficace e granulare richiede una profonda comprensione della logica di business dell'applicazione.

Ci sono due aspetti principali da considerare dal punto di vista dell'implementazione di Apigee:

  • Integrità dei token di accesso
  • Applicazione forzata del controllo dell'accesso

Integrità del token di accesso

È fondamentale verificare che il token fornito dal client richiedente non sia stato manomesso, utilizzando il flusso OAuth o OpenID Connect corretto insieme al meccanismo di firma o convalida delle credenziali appropriato. Apigee supporta tutti i flussi OAuth di uso comune.

I criteri di verifica dei token di accesso di Apigee includono:

Applicazione del controllo dell'accesso

Una volta verificata la validità del token di accesso, è fondamentale implementare i criteri di applicazione del controllo dell'accesso per valutare ogni richiesta API in entrata in base ai diritti di accesso del token di autorizzazione.

Apigee offre due meccanismi principali per verificare e applicare i criteri di autorizzazione:

  • Interne: utilizzo di flussi condizionali per valutare le richieste di accesso in base alle rivendicazioni estratte come variabili di flusso da un token di autorizzazione
  • Delegato: utilizzo di un callout di servizio a una soluzione di gestione degli accessi di terze parti

L'approccio interno (illustrato nella figura sopra) è consigliato quando il modello di controllo dell'accesso è relativamente semplice. Ad esempio, se le attestazioni estratte da un token di accesso possono essere utilizzate per valutare e autorizzare direttamente una richiesta di oggetto API.

Utilizza le variabili di flusso disponibili per i criteri OAuth o JWT per valutare le richieste di accesso utilizzando istruzioni di flusso condizionali.

L'approccio delegato (illustrato nella figura sopra) è consigliato quando le attestazioni estratte da un token di accesso non possono essere utilizzate direttamente per autorizzare una richiesta API a un oggetto di backend o per tipi di flusso OAuth più complessi che richiedono una chiamata separata a un server di autorizzazione per ottenere un token di accesso.

Utilizzando le norme relative ai callout del servizio, è possibile richiedere a un servizio di terze parti una decisione relativa alle norme di autorizzazione oppure ottenere ulteriori informazioni sulle rivendicazioni relative all'agente richiedente per prendere una decisione sul controllo degli accessi utilizzando un flusso condizionale.

API2:2019 Interrotto dell'autenticazione dell'utente

Descrizione minaccia

I criteri di autenticazione degli utenti implementati in modo errato consentono a utenti malintenzionati di rubare l'identità di utenti legittimi sfruttando problemi di implementazione nelle implementazioni dell'autenticazione. Alcuni principi di autenticazione da tenere a mente durante l'implementazione di approcci di autenticazione includono:

  • Autentica sempre sia lo user agent (l'app) sia l'utente che ha inviato la richiesta.
  • Utilizza i pattern di autenticazione e autorizzazione delegati ed evita di passare le password direttamente all'interno di una richiesta API
  • Convalida sempre la firma delle credenziali di accesso e assicurati che tutte le credenziali di accesso utilizzate abbiano una data di scadenza definita
  • Previeni gli attacchi di forza bruta impostando le quote e utilizzando Apigee Sense per rilevare e rispondere agli attacchi di forza bruta basati su bot

In un paradigma outside-in, la progettazione delle API si basa sui casi d'uso dei consumatori per i dati piuttosto che sulla struttura dei dati esistenti nei sistemi di backend e la sicurezza è un elemento fondamentale durante la progettazione delle API per i consumatori esterni. I sistemi di backend tradizionalmente non sono realizzati con implementazioni di autenticazione sufficientemente efficaci per l'esposizione alle reti pubbliche. È qui che Apigee, insieme a una soluzione di gestione di identità e accessi, può offrire soluzioni solide per la protezione da questa minaccia.

Ci sono alcuni elementi importanti da considerare qui, che tratteremo entrambi nelle sezioni successive:

  • Progettazione della sicurezza: utilizzo completo delle funzionalità di Apigee per l'implementazione dei pattern di autenticazione
  • Governance: garantire che venga utilizzato in modo coerente l'uso corretto dei pattern di autenticazione progettati in tutti i prodotti API pubblicati
  • Sicurezza operativa: capacità di rilevare comportamenti sospetti o anomali e tentativi di aggirare i proxy API autenticati mediante forza bruta o di forza bruta.

Progettazione di sistemi di sicurezza

L'obiettivo della progettazione della sicurezza è implementare correttamente i flussi di autenticazione e l'integrazione con strumenti di identità di terze parti. La progettazione della sicurezza è una fase critica che inizia con la comprensione del tipo corretto di flusso di autenticazione delegato da utilizzare in base al tipo di app che utilizzerà i tuoi endpoint API. Il passaggio successivo consiste nella definizione, insieme al team di gestione delle identità, dei pattern di integrazione da implementare con la tua soluzione di identità.

Le RFC OpenID Connect e OAuth forniscono un ampio numero di flussi di autenticazione e autorizzazione delegati, nonché gli attori coinvolti in questi flussi. Si tratta di un argomento complesso e non sorprende che l'autenticazione inaccessibile sia una delle principali minacce dell'API OWASP. Fornire una guida completa sulla corretta implementazione degli standard di identità non rientra nell'ambito di questo documento, tuttavia Apigee dispone di molte risorse aggiuntive per comprendere meglio i flussi OAuth, come questo ebook e il webcast, nonché l'implementazione di esempio.

Criteri di autenticazione

I criteri di Apigee che aiutano a risolvere i problemi di identità e autenticazione includono:

Gestione del traffico

Le seguenti funzionalità di gestione del traffico di Apigee contribuiscono a proteggerti dagli attacchi di forza bruta:

  • Il criterio Arresto di picchi, per impostare un limite di frequenza medio mobile complessivo su un proxy API
  • Criteri per le quote, per impostare limiti di frequenza granulari per i proxy API in base a quote definite da chiavi app, sviluppatori o quote prodotto API
  • Criteri di memorizzazione nella cache, per la memorizzazione nella cache dei token di accesso archiviati in base ai tempi di scadenza definiti, nonché la possibilità di invalidate le credenziali memorizzate nella cache (ad esempio, in una situazione in cui un token di accesso valido viene compromesso)

Governance

La sicurezza è un processo continuo, non un progetto "impostato" e una delle principali cause delle violazioni della sicurezza è l'errata configurazione. Una volta definiti i flussi di autenticazione, i pattern di integrazione delle identità e i criteri di gestione del traffico relativi all'autenticazione, è fondamentale che siano implementati in modo corretto e coerente.

Apigee offre una serie di funzionalità e strumenti per garantire l'integrità dell'implementazione e prevenire errori di configurazione.

Controllo degli accessi basato sui ruoli (RBAC)

Che tu sia una grande azienda o una piccola startup, la necessità di evitare errori di configurazione inizia assicurando che solo le persone e i team giusti possano accedere e modificare le configurazioni dei proxy API. I programmi API sono supportati da team multidisciplinari all'interno della tua organizzazione. È assolutamente essenziale che a ogni team vengano concesse solo le autorizzazioni necessarie per svolgere il proprio lavoro nell'ambito del tuo percorso API.

Apigee offre le funzionalità per gestire l'accesso basato sui ruoli fornendo le funzionalità necessarie per assegnare agli utenti ruoli predefiniti o creare ruoli personalizzati in base ai team API. La definizione e la gestione corretta dell'assegnazione dei ruoli è fondamentale per consentirti di scalare in modo sicuro il tuo programma API. Puoi inoltre utilizzare la federazione per l'integrazione con la directory aziendale esistente e per ridurre la necessità di gestire un secondo set di credenziali di amministratore in Apigee.

Flussi condivisi

I flussi condivisi ti consentono di definire criteri e risorse in un oggetto riutilizzabile che può essere implementato attraverso i proxy API. Ad esempio, potresti aver progettato in modo collaborativo con i tuoi team di sicurezza più pattern di progettazione dell'autenticazione basati sul tipo di app che utilizza un'API. Uno sviluppatore di API non deve essere un esperto di identità per riutilizzarlo; deve semplicemente conoscere il flusso condiviso corretto da aggiungere alla configurazione proxy API esistente utilizzando il criterio Callout flusso.

Figura: i flussi condivisi sono pacchetti riutilizzabili di criteri e logica condizionale che consentono di mantenere un pattern composto.

Reporting sulla sicurezza

Dopo aver verificato che solo le persone giuste nella tua organizzazione possono modificare i tuoi pattern di autenticazione e aver definito i flussi di autenticazione condivisi, devi assicurarti che i proxy API sviluppati dai team API utilizzino questi pattern di autenticazione in modo coerente.

La nuova funzionalità Operazioni API avanzate di Apigee include report di sicurezza avanzati, che consentono ai team operativi e di sicurezza di visualizzare facilmente i report su tutti i proxy API e si concentra sulla conformità ai criteri di sicurezza come l'utilizzo di flussi condivisi. Reporting, logging e avvisi sono un elemento chiave della sicurezza delle API che verrà discusso più dettagliatamente nella sezione API10: logging insufficiente, ma, dal punto di vista della prevenzione dei rischi di autenticazione non funzionanti, sono estremamente utili per garantire il rispetto degli standard di autenticazione definiti implementati come flussi condivisi.

Sicurezza operativa

Una volta che le API sono in produzione, utilizzando i pattern di autenticazione corretti con la gestione di base del traffico, il team SecOps deve anche essere in grado di monitorare e rispondere alle attività sospette, che spesso iniziano con tentativi di compromissione delle credenziali di autenticazione.

Apigee Sense

Apigee Sense protegge le API dal traffico di richieste indesiderate, inclusi gli attacchi di client dannosi. Apigee Sense analizza il traffico delle richieste API, identificando i pattern che potrebbero rappresentare richieste indesiderate. Utilizzando questa analisi, puoi identificare i clienti che inviano richieste indesiderate e intervenire per consentire, bloccare o segnalare queste richieste. Le funzionalità future di Sense includeranno la possibilità di attivare automaticamente la verifica reCAPTCHA in caso di traffico sospetto.

Con Apigee Sense puoi proteggere le tue API da pattern di richiesta che includono:

  • Comportamento automatico che si integra con il comportamento umano
  • Tentativi persistenti dallo stesso IP
  • Percentuali di errori insoliti
  • Richieste client sospette
  • Scansione dei dati
  • Attacchi di forza bruta di autenticazione e raccolta chiave
  • Serie di attività
  • Modelli geografici

Operazioni API avanzate

Sebbene Sense sia stato progettato specificamente per rilevare e rispondere a minacce simili a bot, Advanced API Ops include sia la definizione di rilevamento di anomalie sia la definizione di avvisi avanzati.

Il rilevamento di anomalie funziona applicando i modelli di intelligenza artificiale (IA) e machine learning (ML) ai dati storici delle API. Il rilevamento delle anomalie può quindi generare avvisi in tempo reale per scenari a cui non hai nemmeno pensato per migliorare la produttività e ridurre il tempo medio di risoluzione (MTTR) dei problemi relativi all'API.

Advanced API Ops si basa sul meccanismo di avviso di monitoraggio delle API esistente per aggiungere i seguenti tipi di avvisi avanzati:

  • Avvisi totali sul traffico. Genera un avviso quando il traffico cambia di una percentuale specificata in un intervallo di tempo. Ad esempio, puoi generare un avviso quando il traffico aumenta del 5% o più per un'ora o diminuisce del 10% o più per una settimana
  • Avvisi di anomalie. Edge rileva i problemi di traffico e prestazioni invece di doverli predeterminare autonomamente. Puoi quindi generare un avviso per queste anomalie
  • Avvisi di scadenza TLS. Genera una notifica quando un certificato TLS sta per scadere

API3:2019 Esposizione eccessiva dei dati

Descrizione minaccia

Un'API pubblicata potrebbe esporre più dati del necessario, basandosi sull'app client per eseguire i filtri necessari. Se un utente malintenzionato esegue query direttamente sull'API sottostante, potrà accedere ai dati sensibili.

Uno dei principi di progettazione "outside-in" di Apigee per la progettazione delle API è la parsimonia dei dati. Collabora con i tuoi sviluppatori e designer UX per esporre i dati solo tramite le API necessarie all'interno della UI della tua app. I sistemi di backend non sono stati creati per pattern di utilizzo pubblico, quindi una delle prime attività della progettazione API first con Apigee è ridurre i dati esposti al minimo necessario per fornire un ottimo prodotto API per clienti e sviluppatori.

Un altro dei principi di progettazione di Apigee è la riusabilità. A parte i problemi di sicurezza, fare affidamento su un'app per filtrare i dati forniti da un'API comporta il requisito di trasferire tale logica di filtro su ogni piattaforma per cui si sviluppa un'app.

Dal punto di vista della sicurezza, questa minaccia deriva dalla delega dell'applicazione dell'autorizzazione a un'app, spesso tuttavia su una piattaforma o un sistema operativo su cui non hai alcun controllo. Abbiamo già esaminato in API1 e API2 l'importanza di implementare correttamente l'autenticazione e l'autorizzazione per evitare accessi ai dati non autorizzati.

Le sezioni successive spiegano come:

  • Riscrivi richieste e risposte ai servizi di backend per ridurre al minimo l'esposizione dei dati
  • Implementa la gestione dei guasti per impedire a messaggi di errore dettagliati di esporre informazioni sensibili sull'ambiente a utenti malintenzionati per i tuoi servizi di backend

Riscrittura di risposte e richieste

In genere, i sistemi di backend non sono progettati per l'utilizzo in app pubbliche o su reti pubbliche non attendibili. Apigee Edge è stato progettato per consentirti di eseguire il deployment di prodotti basati su API pubbliche proteggendo i tuoi backend da un'esposizione eccessiva dei dati.

Per farlo, Apigee utilizza tre criteri chiave:

  • Assegna messaggio
  • Callout di codice
  • Gestione dei guasti

Assegna criterio relativo ai messaggi

Il criterio Assegna messaggio modifica o crea nuovi messaggi di richiesta e risposta durante il flusso del proxy API. Il criterio consente di eseguire le seguenti azioni sui messaggi:

  • Aggiungi nuovi parametri di modulo, intestazioni o parametri di query a un messaggio.
  • Copia le proprietà esistenti da un messaggio a un altro
  • Rimuovi intestazioni, parametri di query, parametri di modulo e/o payload dei messaggi da un messaggio
  • Imposta il valore delle proprietà esistenti in un messaggio

Con Assegna messaggio, in genere puoi aggiungere, modificare o rimuovere le proprietà della richiesta o della risposta. Tuttavia, puoi anche utilizzare Assegna messaggio per creare una richiesta o un messaggio di risposta personalizzato e passarlo a una destinazione alternativa, come descritto in Creare messaggi di richiesta personalizzati.

Riscrittura complessa con codice personalizzato

Per regole complesse di gestione e riscrittura dei dati la cui complessità va oltre la capacità del criterio Assegna messaggio, puoi utilizzare linguaggi procedurali come JavaScript, Java o Python. Puoi aggiungere codice personalizzato a un proxy API e quindi chiamarlo dai criteri aggiunti al flusso del proxy. Il supporto per il codice procedurale è progettato per semplificare l'implementazione della gestione complessa di variabili di flusso, errori e corpi di richiesta e risposta.

Con il codice procedurale puoi:

  • Crea o manipola valori corporei complessi, ad esempio valori di richieste e risposte.
  • Riscrivi gli URL, ad esempio per mascherare un URL dell'endpoint di destinazione.

Apigee Edge include un criterio separato per i linguaggi supportati: criterio JavaScript, criterio callout Java e criteri Python Script.

Gestione dei guasti

Apigee ti consente di eseguire una gestione personalizzata delle eccezioni utilizzando un criterio di tipo Alza errori. Il criterio Genera errore, che è una variante del criterio Assegna messaggio, consente di generare una risposta di errore personalizzata in risposta a una condizione di errore.

Flussi condivisi

I flussi condivisi possono essere utilizzati per applicare la standardizzazione dei messaggi di errore. Ad esempio, gli stessi criteri configurati che rilevano un codice di errore HTTP specifico dal backend possono essere utilizzati per riscrivere la risposta di errore in modo che restituisca un messaggio di errore generico.

API4:2019 Mancanza di risorse e limitazione di frequenza

Descrizione minaccia

Non implementando criteri di limitazione della frequenza, gli utenti malintenzionati possono sovraccaricare il backend con attacchi denial of service.

Questa minaccia può essere facilmente affrontata utilizzando le seguenti funzionalità di Apigee:

  • Criteri per le quote e i picchi di arresto come controlli preventivi per applicare limiti di traffico alle richieste API in entrata
  • Apigee Sense per rilevare e rispondere in modo dinamico agli attacchi basati su bot
  • Monitoraggio e avvisi avanzati delle API come controlli di rilevamento da avvisare in caso di attacchi DDoS in corso.

Limitazione della frequenza con i criteri Quote e Spike Arrest

Apigee offre due criteri per la limitazione della frequenza:

  • L'arresto di picchi fornisce un criterio generale, definito a livello di proxy API, per la limitazione della frequenza del numero complessivo di richieste in entrata a un backend
  • Le quote forniscono uno strumento di criteri granulare per applicare i criteri per le quote, a livello di proxy API o a livello di prodotto API

Arresto con picchi

Il criterio Spike Arrest protegge dai picchi di traffico. Questo criterio limita il numero di richieste elaborate da un proxy API e inviate a un backend, proteggendo da ritardi nelle prestazioni e tempi di inattività, utilizzando un valore medio mobile definibile all'interno del criterio.

Quote

Il criterio Quota consente di configurare il numero di messaggi di richiesta consentiti da un proxy API in un determinato periodo di tempo, ad esempio minuto, ora, giorno, settimana o mese. Puoi impostare la quota in modo che sia la stessa per tutte le app che accedono al proxy API oppure puoi impostare la quota in base a:

  • Il prodotto che contiene il proxy API
  • L'app che richiede l'API
  • Lo sviluppatore dell'app
  • Molti altri criteri

Questa norma è più granulare rispetto all'arresto con Spike e in genere dovrebbe essere utilizzata contemporaneamente.

Rilevamento dei bot con Apigee Sense

Con Apigee Sense puoi intervenire per consentire, bloccare o segnalare esplicitamente le richieste provenienti da client, intervalli IP o organizzazioni di sistemi autonomi, in base ai client o alle località che presentano comportamenti dannosi o sospetti. Apigee Edge applica queste azioni alle richieste prima che i proxy API le elaborino. Ad esempio, un intervallo IP o un client specifico che presenta un comportamento di "indovina bruta" può essere rilevato, quindi bloccato o segnalato.

Rilevamento delle minacce con Advanced API Ops Monitoring

Utilizza un avviso sul traffico per generare una notifica quando il traffico per un ambiente, un proxy o una regione cambia di una determinata percentuale in un intervallo di tempo. Questa funzionalità può generare dinamicamente un avviso quando il traffico si discosta in modo significativo dalla velocità effettiva prevista, come nel caso di un attacco DDoS. Questi avvisi possono essere facilmente inviati a una soluzione di logging e monitoraggio di terze parti.

API5:2019 Autorizzazione a livello di funzione inaccessibile

Descrizione minaccia

Questa minaccia è una variante di API1 e una vulnerabilità di autorizzazione. Con questa minaccia, un utente malintenzionato può eseguire azioni inviando richieste a funzioni a cui non è autorizzato ad accedere. Ad esempio, un utente malintenzionato potrebbe essere in grado di modificare o eliminare dati che sono autorizzati a leggere solo se un endpoint API non convalida il verbo della richiesta HTTP, sostituendo GET con PUT o DELETE. Oppure, se non implementi un controllo degli accessi sufficientemente restrittivo sul percorso dell'URI di una risorsa API, un endpoint API potrebbe consentire a un utente malintenzionato di visualizzare i dati di un altro utente semplicemente modificando il percorso in una richiesta.

Questo tipo di minaccia evidenzia il valore dell'utilizzo di Apigee come livello di mediazione e astrazione, poiché molti sistemi di backend, non progettati per l'accesso pubblico, potrebbero per impostazione predefinita fornire un singolo endpoint per l'esecuzione di più funzioni della logica di business, incluse funzionalità amministrative ad alto rischio.

Gli elementi concettuali per ridurre le probabilità di questa minaccia sono generalmente suddivisi in:

  • Cosa viene protetto? Pensa alla tua strategia di prodotto basata su API e implementa la segmentazione logica delle funzionalità quando utilizzi le best practice RESTful per progettare i percorsi e le risorse esposti dai proxy API, dai prodotti e dalle funzionalità delle app Apigee.
  • Chi accede alle risorse dell'API? Definisci gli utenti tipo di alto livello e implementa i diritti di accesso predefiniti del "privilegio minimo" utilizzando alcune delle funzionalità di autenticazione e autorizzazione di Apigee come descritto in API1 e API2.
  • Come vengono applicati i criteri di accesso? Utilizza flussi condizionali ed errori per convalidare il percorso dell'URL e il verbo di tutte le richieste API.

Figura: questo diagramma mostra come verrà applicata l'autorizzazione a livello di funzione in Apigee, utilizzando gli ambiti forniti all'interno di un token di accesso come diritti.

Segmentazione logica con proxy API, prodotti e app

Apigee fornisce un toolkit altamente flessibile per consentire la segmentazione logica delle risorse API. In questo modo, i proxy API possono essere raggruppati in un numero qualsiasi di prodotti API, che a loro volta vengono utilizzati dagli sviluppatori di app, che sono in grado di registrare le app che utilizzano i tuoi prodotti API. I criteri di accesso possono essere definiti a uno di questi livelli.

Tuttavia, per implementare efficaci autorizzazioni e segmentazione funzionale, è fondamentale definire una strategia di prodotto API. Parte di questo processo essenziale e continuo è la definizione di "chi" e "cosa" dei tuoi prodotti API, esaminando le risorse API dal punto di vista del cliente e dello sviluppatore e poi definendo a livello di risorsa percorso e verbo HTTP quali tipi di richieste saranno consentite.

Figura: le risorse API in bundle in un prodotto API possono provenire da una o più API, quindi puoi combinare le risorse per creare livelli di consumo e limiti di autorizzazione.

Controllo dell'accesso a livello di funzione con ambiti OAuth e attestazioni JWT

Sebbene gli approcci all'autorizzazione considerati sopra per l'autorizzazione degli oggetti inaccessibili API1:2019 indirizzino un controllo dell'accesso granulare a livello di oggetto, è altrettanto importante gestire un controllo dell'accesso granulare a livello di funzione. L'utente che ha inviato la richiesta è autorizzato a richiedere questo percorso dell'URL? Questo tipo di criterio viene spesso definito in base all'utente tipo (cliente, dipendente, amministratore, sviluppatore interno o di terze parti).

Per ridurre il rischio di errori di configurazione, ti consigliamo di collaborare con il team addetto alla sicurezza per assicurarti che le asserzioni relative all'utente richiedente siano contenute nel token di accesso, con l'utilizzo di ambiti OAuth o attestazioni JWT.

Richiedi convalida con flussi condizionali

A livello di base, una chiamata API REST comprende quanto segue:

  • Un endpoint
  • Una risorsa
  • Un verbo d'azione
  • Un numero qualsiasi di attributi di richiesta aggiuntivi, come i parametri di ricerca

Il tipo di attacco descritto in questa minaccia è generalmente causato dall'insufficienza di filtri di una richiesta API, che consente così a un utente malintenzionato di eseguire azioni non autorizzate o l'accesso a una risorsa protetta. Oltre alla logica condizionale che consente di filtrare le richieste in base a token di accesso o attestazioni, Apigee consente l'implementazione di una logica di filtro in base alla richiesta stessa.

Dopo aver compreso e definito chiaramente la logica di business di un prodotto API, quali funzioni sono consentite dalle tue API, il passaggio successivo consiste nel limitare le richieste che non rientrano in questo processo attraverso queste funzionalità del prodotto Apigee:

  • Logica condizionale e criteri di aumento degli errori per limitare i percorsi delle risorse o i verbi in qualsiasi passaggio nella configurazione dei flussi proxy
  • Criteri di protezione dalle minacce JSON e XML per proteggerti da attacchi basati sui contenuti utilizzando payload di richieste JSON o XML in formato non corretto

API6:2019 Assegnazione di massa

Descrizione minaccia

I dati non filtrati forniti tramite API alle app client consentono agli utenti malintenzionati di indovinare le proprietà degli oggetti tramite le richieste oppure di utilizzare convenzioni di denominazione degli endpoint per ottenere indizi su dove eseguire modifiche non autorizzate o accedere alle proprietà degli oggetti dati archiviati nel backend.

Questa minaccia si verifica quando dati non filtrati (in genere in formato JSON o XML) vengono inviati a un client, consentendo a un utente malintenzionato di indovinare i dettagli di implementazione sottostanti dei sistemi di backend, nonché i nomi delle proprietà degli elementi di dati riservati. Il risultato di questo tipo di attacco potrebbe consentire a un utente malintenzionato di leggere o manipolare dati inappropriati oppure, nei casi peggiori, potrebbe favorire vulnerabilità nell'esecuzione del codice da remoto.

Questo tipo di minaccia viene generalmente coinvolto in due aspetti:

  • La prospettiva di progettazione delle API. Non affidarti mai alla logica dell'applicazione per eseguire il filtraggio dei dati lato client, poiché le app possono essere sfruttate da utenti malintenzionati ed essere considerate attendibili. Progetta sempre lo schema dei dati dell'API in modo da esporre solo i dati minimi necessari per abilitare un servizio API
  • Il punto di vista dell'implementazione delle API. Implementa il filtro dei dati e la convalida dello schema per impedire l'esposizione involontariamente di dati riservati a un'applicazione client

Dal punto di vista dei prodotti Apigee, offriamo diverse funzionalità utili per garantire un'implementazione solida del filtro dei dati delle API.

Criterio di filtro delle specifiche OpenAPI

Il criterio OASValidation (OpenAPI Specification Validation) consente di convalidare una richiesta o un messaggio di risposta in entrata rispetto a una specifica OpenAPI 3.0 (JSON o YAML). Questo criterio consente di:

  1. Progetta la tua API creando una specifica OpenAPI (OAS)
  2. Implementa la logica di mediazione, sicurezza e memorizzazione nella cache necessaria per esporre in modo sicuro un prodotto API dal tuo backend con Apigee
  3. Convalida le richieste in arrivo in base allo schema dei dati definito nelle specifiche OAS, inclusi basepath, verb, request message policy e parameters

Norme di convalida dei messaggi SOAP

I criteri di convalida dei messaggi SOAP consentono di convalidare le richieste basate su XML mediante la convalida di un messaggio XML in base a uno schema XSD o di un messaggio SOAP a fronte di una definizione WSDL. Inoltre, puoi utilizzare il criterio di convalida dei messaggi per confermare che il payload di un messaggio JSON o XML sia corretto, inclusa la verifica di quanto segue in un messaggio XML o JSON:

  • C'è un solo elemento principale
  • I contenuti non contengono caratteri illegali
  • Oggetti e tag sono nidificati correttamente
  • I tag di inizio e fine corrispondono

Errore di configurazione della sicurezza API7:2019

Descrizione minaccia

La configurazione errata della sicurezza è in genere il risultato di configurazioni predefinite non sicure, configurazioni incomplete o ad hoc, spazio di archiviazione sul cloud aperto, intestazioni HTTP configurate in modo errato, metodi HTTP non necessari, condivisione delle risorse tra origini (CORS) permissiva e messaggi di errore dettagliati contenenti informazioni sensibili. Gli utenti malintenzionati spesso tentano di trovare difetti senza patch, endpoint comuni o file e directory non protetti per ottenere accesso non autorizzato o conoscenza del sistema che vogliono attaccare. Gli errori di configurazione della sicurezza non solo possono esporre dati utente sensibili, ma anche dettagli del sistema che potrebbero comportare la compromissione completa del server. Inoltre, altri casi d'uso di vulnerabilità per errori di configurazione della sicurezza potrebbero includere:

  • TLS non configurato correttamente
  • Messaggi di errore con le analisi dello stack
  • Sistemi senza patch
  • Spazio di archiviazione esposto o pannelli di gestione dei server

Esistono vari passaggi che le organizzazioni possono intraprendere per affrontare e mitigare le sfide relative agli errori di configurazione della sicurezza, tra cui:

  1. Stabilire e standardizzare i processi di protezione e applicazione delle patch
  2. Sviluppare la governance sull'ecosistema delle API
  3. Limitazione dell'accesso amministrativo e abilitazione di controllo e avvisi

Flussi condivisi e hook di flusso

Apigee supporta il concetto di flusso condiviso che consente agli sviluppatori di API di combinare criteri e risorse in un gruppo riutilizzabile. Acquisendo le funzionalità riutilizzabili in un unico posto, un flusso condiviso ti aiuta a garantire coerenza, ridurre i tempi di sviluppo e gestire più facilmente il codice. Puoi includere un flusso condiviso all'interno di singoli proxy API oppure puoi fare un passo in più e inserire flussi condivisi in hook di flusso per eseguire automaticamente la logica di flusso condiviso per ogni proxy API di cui è stato eseguito il deployment nello stesso ambiente di un flusso condiviso.

Reporting sulla sicurezza delle API

Mentre le organizzazioni si sforzano di sviluppare un framework di governance, Apigee fornisce funzionalità relative ai report sulla sicurezza delle API che aiutano i team operativi con la visibilità di cui hanno bisogno gli attributi di sicurezza delle API per:

  • Garantisci il rispetto dei criteri di sicurezza e dei requisiti di configurazione
  • Proteggi i dati sensibili da abusi interni ed esterni
  • Identifica, diagnostica e risolvi in modo proattivo gli incidenti di sicurezza

I report sulla sicurezza di Apigee forniscono insight approfonditi per i team operativi al fine di garantire il rispetto dei criteri e dei requisiti di configurazione, proteggere le API da abusi interni ed esterni e identificare e risolvere rapidamente gli incidenti di sicurezza.

Con i report sulla sicurezza, gli amministratori della sicurezza possono comprendere rapidamente in che modo sono configurati i proxy API per la sicurezza e le condizioni di runtime che potrebbero influire sulla sicurezza dei proxy. Utilizzando queste informazioni, puoi modificare la configurazione per assicurarti di disporre del livello di sicurezza appropriato per ogni proxy.

Monitoraggio delle API

Apigee offre una piattaforma completa di monitoraggio delle API che integra le funzionalità di reporting sulla sicurezza. API Monitoring consente alle organizzazioni di rilevare in modo proattivo il traffico delle API e i problemi di prestazioni. Il monitoraggio delle API Apigee funziona in combinazione con Apigee Edge per il cloud pubblico per fornire insight contestuali in tempo reale sulle prestazioni delle API, diagnosticare rapidamente i problemi e facilitare le azioni correttive per la continuità aziendale.

Figura: il monitoraggio delle API Apigee offre un'ampia gamma di strumenti per monitorare, esaminare e intervenire sui problemi. Sfrutta le migliori funzionalità di intelligence disponibili in Google Cloud Platform.

Apigee Sense

Apigee Sense aiuta a proteggere le API dal traffico di richieste indesiderate, inclusi gli attacchi di client dannosi. Apigee Sense analizza il traffico delle richieste API, identificando i pattern che potrebbero rappresentare richieste indesiderate.

Utilizzando questa analisi, le organizzazioni possono identificare i clienti che fanno richieste indesiderate e intervenire per consentire, bloccare o segnalare tali richieste. Con Apigee Sense è possibile proteggere le API da pattern di richiesta che includono:

  • Comportamento automatico che si integra con il comportamento umano
  • Tentativi persistenti dallo stesso IP
  • Percentuali di errori insoliti
  • Richieste client sospette
  • Scansione dei dati
  • Raccolta di chiavi
  • Serie di attività
  • Modelli geografici

API8:2019 Iniezione

Descrizione minaccia

L'inserimento non attendibile di dati, ad esempio SQL, NoSQL, XML Parser, ORM, LDAP, comandi del sistema operativo e JavaScript, nelle richieste API può comportare l'esecuzione di comandi non intenzionali o l'accesso non autorizzato ai dati. Gli utenti malintenzionati forniscono all'API dati dannosi tramite qualsiasi vettore di inserimento disponibile, come input diretto, parametri, servizi integrati e così via, aspettandosi che vengano inviati a un interprete. Gli utenti malintenzionati possono individuare facilmente questi difetti quando esaminano il codice sorgente utilizzando strumenti di analisi delle vulnerabilità e fuzzer. Un inserimento riuscito può portare alla divulgazione di informazioni, con ripercussioni sulla riservatezza e sulla perdita di dati o, in alcuni casi, anche causare attacchi DoS.

Le best practice per mitigare gli errori/gli attacchi di inserimento includono la definizione rigorosa dei dati di input come schemi, tipi, pattern di stringhe, l'esecuzione di convalida degli input, controlli dei limiti e applicazione in fase di runtime. La piattaforma Apigee consente di convalidare i dati in entrata utilizzando filtri per consentire solo valori validi per ciascun parametro di input.

Apigee Edge, agendo come server per le richieste API in entrata, controlla che la struttura del payload rientri in un intervallo accettabile, noto anche come controllo dei limiti. Puoi configurare un proxy API in modo che la routine di convalida dell'input trasformi l'input per rimuovere sequenze di caratteri rischiose e sostituirle con valori sicuri.

Norme per la protezione delle espressioni regolari

Il criterio RegularExpressionProtection estrae le informazioni da un messaggio (ad esempio, URI Path, Query Param, Header, Form Param, Variabile, XML Payload o JSON Payload) e valuta tali contenuti rispetto a espressioni regolari predefinite. Se una qualsiasi espressione regolare specificata restituisce true, il messaggio viene considerato una minaccia e viene rifiutato. Un'espressione regolare, abbreviata come regex, è un insieme di stringhe che specificano un pattern in una stringa. Le espressioni regolari consentono di valutare i pattern in modo programmatico. Le espressioni regolari possono essere utilizzate, ad esempio, per valutare un indirizzo email e assicurarsi che sia strutturato correttamente.

L'uso più comune di RegularExpressionProtection è la valutazione di payload JSON e XML per rilevare contenuti dannosi.

Nessuna espressione regolare può eliminare tutti gli attacchi basati sui contenuti e dovrebbero essere combinati più meccanismi per consentire una difesa in profondità. Questa sezione descrive alcuni pattern consigliati per impedire l'accesso ai contenuti.

Esistono diversi altri approcci per convalidare l'input disponibile con la piattaforma Apigee:

Convalida tipi di contenuti

Il tipo di contenuti fa riferimento ai contenuti di un file trasferiti tramite HTTP e classificati in base a una struttura in due parti. Apigee consiglia di convalidare i tipi di contenuti per le richieste e le risposte utilizzando la logica condizionale, come spiegato di seguito.

Reporting sulla sicurezza delle API

Mentre le organizzazioni si sforzano di sviluppare un framework di governance, Apigee fornisce funzionalità relative ai report sulla sicurezza delle API, che aiutano e offrono ai team operativi la visibilità di cui hanno bisogno per proteggere le API, fornendo ai team operativi la visibilità di cui hanno bisogno gli attributi di sicurezza delle API per:

  • Garantisci il rispetto dei criteri di sicurezza e dei requisiti di configurazione.
  • Protezione dei dati sensibili da comportamenti illeciti interni ed esterni.
  • Identifica, diagnostica e risolve in modo proattivo gli incidenti di sicurezza.

API9:2019 Gestione impropria delle risorse

Descrizione della minaccia

Una gestione dell'ambiente e una segregazione dell'ambiente insufficienti consentono a utenti malintenzionati di accedere a endpoint API non protetti. La mancanza di misure di salvaguardia della governance causa anche un'esposizione non necessaria di risorse deprecate.

Questa minaccia può essere affrontata sfruttando le capacità mature di Apigee per gestire l'intero ciclo di vita delle API, consentendo di creare un modello di governance completo che consente la collaborazione tra i team e, allo stesso tempo, applicare la separazione delle responsabilità tra gli stakeholder per la sicurezza e gli sviluppatori di API. I confini e i controlli possono essere configurati e gestiti utilizzando:

Organizzazioni, ambienti e revisioni: sistemi di protezione virtuali e fisici che garantiscono l'isolamento e un processo di promozione sicuro attraverso contesti di runtime.

Controllo degli accessi basato sui ruoli: solo le persone necessarie nei team API disporranno delle autorizzazioni per gestire le modifiche alla configurazione e anche il processo di promozione.

Documentazione sulla gestione dei segmenti di pubblico per l'API: dopo aver pubblicato un'API nel portale per gli sviluppatori, puoi limitare la visibilità della documentazione gestendo i segmenti di pubblico di destinazione.

Flow Hook: puoi applicare criteri e pattern globali che possono essere gestiti come sistemi di protezione con privilegi che non possono essere modificati dagli sviluppatori di API.

Report sulla sicurezza: gli stakeholder per la sicurezza hanno una visibilità end-to-end delle API pubblicate e della loro configurazione di supporto. Il rispetto dei criteri di sicurezza globali può essere controllato e valutato in base al profilo di rischio per ogni endpoint API pubblicato.

Organizzazioni e ambienti

Gli artefatti, gli utenti e le funzionalità di configurazione in Apigee possono limitare l'ambito a organizzazioni e/o ambienti specifici. Ciò significa che la piattaforma dispone di sistemi di protezione predefiniti che possono essere posizionati attorno alle API e alla loro configurazione di supporto.

Organizzazioni: un'organizzazione è il tenant di primo livello in Apigee. Consente di avere una separazione completa per traffico, configurazione e utenti. Come best practice per la governance, dovresti considerare la presenza di organizzazioni di produzione e non di produzione separate. Questa pratica evita in modo efficace di combinare dati di produzione, utenti e traffico con ambienti inferiori.

Ambienti: le API in Apigee possono essere promosse in più stati di deployment, ogni stato è collegato a un contesto di esecuzione. Il contesto dell'ambiente non viene mantenuto durante il processo di promozione, pertanto evita di esporre la configurazione sensibile a utenti senza privilegi.

Revisioni: le revisioni consentono di promuovere facilmente API e singole funzionalità nei vari ambienti.

Controllo degli accessi basato sui ruoli

Al fine di mitigare API9, è imperativo avere una chiara definizione e separazione dei compiti tra gli stakeholder per la sicurezza e gli sviluppatori di API. Come indicato in precedenza in questo documento, Apigee offre funzionalità flessibili di controllo dell'accesso basato sui ruoli che consentono di assegnare autorizzazioni a ruoli personalizzati. Per questa minaccia specifica, è possibile limitare i ruoli in modo da avere privilegi limitati per organizzazione, ambiente o autorizzazioni di configurazione più granulari. Come prassi preferita, valuta la possibilità di limitare i privilegi per modificare lo stato di deployment delle API attraverso gli ambienti e anche per assicurarti che gli sviluppatori non siano in grado di accedere o modificare le librerie di sicurezza globali (hook di flusso). Questi ruoli limitati eviteranno modifiche non richieste ai criteri di sicurezza globali che hanno un'ampia copertura sugli endpoint legacy e pubblicati attualmente.

Documentazione sulla gestione dei segmenti di pubblico per l'API

Un portale per gli sviluppatori è un componente fondamentale per il successo della tua strategia API; ti consente di avere un inventario completo di tutta la documentazione relativa alle tue API, inclusi host/endpoint, risorse, operazioni, schemi di payload e altro ancora. In Apigee puoi raggruppare le tue API utilizzando i costrutti dei prodotti API. I prodotti API sono definiti da pacchetti di risorse e operazioni che rientrano nello stesso contesto aziendale e di sicurezza (ad es. piano di servizio, dominio aziendale, categoria, gerarchia aziendale e così via).

Con il portale integrato per sviluppatori di Apigee, puoi pubblicare prodotti basati su API e limitare la visibilità dei contenuti pubblicati gestendo segmenti di pubblico di destinazione. Questa funzionalità è conforme a una strategia di segmentazione dei contenuti in linea con i requisiti aziendali e di sicurezza.

Ganci di flusso

Le procedure di promozione e rilascio delle API devono sempre includere processi di certificazione e conformità della sicurezza. Per essere efficaci, i team API che utilizzano gli strumenti appropriati dovrebbero essere in grado di creare sistemi di protezione che garantiscano la separazione delle responsabilità e garantiscano cicli di rilascio agili.

Apigee ti consente di migliorare gli obblighi di governance della sicurezza applicando criteri globali tramite flow hook. Questi criteri globali possono essere gestiti come sistemi di protezione privilegiati che non possono essere modificati dagli sviluppatori di API, garantendo così la separazione delle responsabilità e promuovendo anche l'agilità applicando la sicurezza predefinita e, per estensione, fornendo la conformità della sicurezza per tutte le API distribuite in un determinato ambiente di esecuzione.

Figura: i guardrail con privilegi possono essere configurati in Apigee tramite hook di flusso e flussi condivisi. Gli stakeholder della sicurezza sono responsabili del mantenimento dei criteri globali relativi alla sicurezza. Queste funzionalità garantiscono la separazione delle responsabilità e promuovono cicli di vita di sviluppo agili.

Reporting sulla sicurezza

I controlli di sicurezza hanno lo scopo di valutare e testare i criteri di sicurezza volti a proteggere i dati e gli obiettivi aziendali dell'organizzazione. Le API sono interfacce pubbliche o private standardizzate che devono essere protette da un modello di governance della sicurezza completo e, allo stesso tempo, verificabile.

In Apigee hai accesso a report sulla sicurezza specializzati che aiutano a garantire il rispetto dei criteri definiti e consentono ai tuoi team di sicurezza di intervenire sulla base di insight completi su:

Traffico runtime: una panoramica completa per gli insight sul traffico delle API su: server di destinazione, host virtuali, configurazione TLS, modifiche al traffico per ambiente e altro ancora.

Configurazione: funzionalità di controllo per la configurazione dei proxy API che offre visibilità end-to-end su tutti i criteri applicati a livello di proxy API, nonché sullo spettro di applicazione dei flussi condivisi collegati a livello di organizzazione o proxy.

Attività utente: monitora le operazioni sensibili eseguite dagli utenti della piattaforma. Analizza le attività sospette visualizzando in dettaglio le attività sospette.

API10:2019 Logging e monitoraggio insufficienti

Descrizione della minaccia

Logging, monitoraggio e avvisi insufficienti consentono di non rilevare gli attacchi in corso, pertanto dovrebbe essere necessaria una strategia per ottenere insight sugli eventi critici che hanno un impatto sulla tua attività.

Le strategie di gestione di eventi e logging per le API dovrebbero prendere in considerazione le seguenti best practice:

  • Criterio di gestione dei log: documenta e applica le regole per standardizzare e controllare le Preferenze di lettura dei log, i livelli dei log, l'integrità dei log, il repository centralizzato e altro ancora
  • Norme per la gestione degli eventi: garantiscono che ogni evento deve essere tracciabile fino alla sua fonte. Inoltre, gli eventi devono poter essere classificati in base alla criticità e all'impatto sull'attività
  • Report e controlli: gli stakeholder interessati alla sicurezza e alle operazioni devono essere in grado di accedere a log ed eventi e di reagire di conseguenza in tempo reale. Inoltre, i cicli di rinforzo possono essere eseguiti dagli stakeholder per regolare i pattern di rilevamento in base ai dati storici

Apigee fornisce gli strumenti necessari per creare una strategia completa di gestione degli eventi e del logging. Gli strumenti includono:

Criterio di logging dei messaggi: crea flussi di log in base ai dati di traffico o ai metadati provenienti dal traffico API. Hai la flessibilità di decidere le Preferenze di lettura dei flussi sfruttando la logica condizionale e i modelli di messaggi.

Suite operativa di Google Cloud: sfrutta l'integrazione immediata negli strumenti di monitoraggio e logging altamente scalabili di Google.

Norme sui callout di servizio: aggiunge il supporto per i flussi di log che richiedono endpoint HTTP per inviare eventi.

Analytics: accedi ai metadati storici sul traffico e analizzali con report predefiniti e/o personalizzati. Crea e gestisci gli avvisi in base alle tendenze e comprendi le anomalie del traffico.

Monitoraggio delle API: come descritto in precedenza, questo strumento fornisce funzionalità di avviso che possono essere attivate in base a eventi critici. I log di traffico possono essere ulteriormente analizzati e utilizzati per intervenire.