Con GraphQL arriva la potenza… la responsabilità dello sviluppatore per la sicurezza delle API

Questo è un guest post per la serie API di Computer Weekly Developer Network scritto da Shahar Binyamin, CEO e co-fondatore di mi rifiutola piattaforma di sicurezza e gestione GraphQL.

Binyamin scrive per intero come segue…

Gli sviluppatori si stanno rivolgendo sempre più a GraphQL per superare le carenze dell’API REST.

Gestire abilmente il linguaggio di query dei dati API open source consente agli sviluppatori di creare applicazioni più veloci e stabili (e con un controllo più diretto dei dati). Ma – e c’è sempre un ma – il movimento GraphQL guidato dagli sviluppatori sta anche appuntando compiti di sicurezza che tradizionalmente appartenevano a team dedicati alla sicurezza e DevOps nelle mani degli sviluppatori stessi.

Gli sviluppatori spesso non sono consapevoli del grado in cui GraphQL richiede loro di indossare un cappello di sicurezza e concentrarsi sul controllo degli accessi e sulle operazioni insieme ai loro compiti preferiti di, beh, la creazione di applicazioni interessanti.

Sicurezza e controllo olistico degli accessi

La distribuzione di GraphQL per le API richiede alle organizzazioni di adottare un nuovo paradigma orizzontale; le tradizionali separazioni tra sicurezza, DevOps e team di sviluppo non sono più presenti. In questa nuova relazione orizzontale, gli sviluppatori sono responsabili sia della sicurezza che dello sviluppo.

Sebbene siano disponibili molte guide per aiutare gli sviluppatori a installare le manopole e le funzionalità di sicurezza GraphQL corrette, l’implementazione di una strategia olistica di sicurezza e controllo degli accessi è la chiave del successo.

Per proteggere le API GraphQL, gli sviluppatori richiedono controlli di accesso basati su schema che funzionino con i controlli di accesso al database, nonché con i controlli di accesso per altre API (come REST e gRPC).

Una strategia olistica che integri questi controlli deve anche prendere in considerazione la limitazione della velocità e ulteriori protezioni contro lo scraping di dati. Inoltre, poiché i controlli di accesso sono scritti nel codice, e sono piuttosto soggetti a errori poiché lo schema è/sono in continua evoluzione, i team hanno anche bisogno degli strumenti CI/CD giusti per controllare continuamente il codice dello schema e proteggere gli sviluppatori dai propri errori.

Proteggere GraphQL significa anche andare oltre la tradizionale sicurezza delle API contestualizzando le richieste e le risposte API dei clienti, che forniscono preziose informazioni sulle superfici di attacco e sulla logica aziendale.

Avvertenza: evitare la sicurezza per offuscamento

Troppo spesso, gli sviluppatori che non conoscono i ruoli di sicurezza API che GraphQL impone loro adotteranno l’approccio ingenuo che è sicurezza per offuscamento.

L’idea è di disabilitare l’introspezione di GraphQL, con la consapevolezza che se lo schema non offre informazioni su quali query supporta, gli aggressori non saranno in grado di capirlo altrimenti.

Questo è un malinteso.

Binyamin: Una strategia olistica deve considerare la limitazione della velocità e ulteriori protezioni contro lo scraping di dati.

È stato radicato nella mancanza di consapevolezza delle superfici di attacco che le aziende introducono quando adottano GraphQL per le API. La sicurezza per offuscamento non fa nulla: gli aggressori sanno tutto ciò che devono sapere e possono comunque acquisire dati e creare fughe di dati a meno che non siano in atto adeguate protezioni di sicurezza e controllo degli accessi. La conoscenza di un sistema non deve pregiudicare o aumentare il rischio dell’intero sistema.

Scala attraverso una lente federata

Con la scalabilità dell’adozione di GraphQL, i team potrebbero trovarsi improvvisamente con dozzine di endpoint API GraphQL.

La scalabilità rende necessario dotare un architetto aziendale di un obiettivo federato che semplifica la supervisione e la protezione dell’intera implementazione. L’obiettivo è consentire a vari team di sviluppo di operare in modo produttivo e autonomoproteggendo tutti i dati a cui accedono tramite controlli olistici.

Le organizzazioni che raggiungono questo utilizzo su larga scala dell’API GraphQL devono anche introdurre l’osservabilità e gli avvisi a livello di query per proteggersi da chiamate API abusive.

Gli sviluppatori devono creare un ecosistema integrato e connesso in cui gli attacchi diretti a server o dati vengano rilevati e mitigati rapidamente. E mentre le iniezioni di GraphQL a livello di query sono rare, le misure di sicurezza devono essere pronte a difendere i sistemi con questo tipo di vulnerabilità.

Gli sviluppatori brillano come esperti di sicurezza

Troppi sviluppatori si precipitano in GraphQL per i suoi potenti vantaggi API, lasciando la sicurezza come un ripensamento. (Per molti versi, questa spinta adotta-primo-secondo sicuro è simile a ciò che accade con Kubernetes, con conseguenze simili.) GraphQL lo rende particolarmente pericoloso, perché quel ripensamento non viene poi affrontato da un team di sicurezza dedicato, ma deve essere gestito dagli stessi sviluppatori.

Abbracciando le migliori pratiche, tra cui una strategia olistica di sicurezza e controllo degli accessi, comprensione contestuale dell’attività delle API e un obiettivo federato per il controllo della sicurezza su larga scala, gli sviluppatori possono brillare nei loro ruoli di sicurezza e salvaguardare efficacemente i server e i dati dell’API GraphQL.

Leave a Comment

Your email address will not be published. Required fields are marked *