Per proteggere un'API che tratta dati regolamentati, modellate chi potrebbe abusarne, verificate l'autorizzazione su ogni oggetto e ogni campo, raccogliete e restituite meno dati possibile, e tenete segreti e log di audit sotto stretto controllo. Nella pratica le debolezze che contano di più sono le lacune nelle autorizzazioni e le risposte che espongono troppi dati, non una cifratura difettosa.
Partite da un modello delle minacce sui dati, non sul framework
Prima di scegliere gli strumenti, mettete per iscritto che cosa espone l'API e chi potrebbe abusarne. Per una banca si tratta di dati su conti e transazioni; per un'azienda dell'energia o dei servizi di pubblica utilità possono essere dati di misura dei contatori, contratti dei clienti e letture operative provenienti dalla rete.
Un modello delle minacce utile è breve. Elenca i dati sensibili, ogni chiamante che può raggiungerli, le azioni che ogni chiamante deve poter compiere e che cosa succede se uno di loro viene compromesso. Quel documento guida poi ciascuno dei controlli descritti qui sotto, e dice a chi revisiona che cosa testare.
- Quali dati sono personali, riservati o regolamentati, e dove sono conservati.
- Ogni consumatore dell'API: servizi interni, partner, app mobili e amministratori.
- Che cosa ogni consumatore è autorizzato a leggere, modificare o avviare.
- L'impatto di un token trapelato, di un insider malintenzionato o di un sistema partner compromesso.
Autenticate ogni chiamante, poi autorizzate ogni oggetto
Usate un protocollo standard come OAuth 2.0 con OpenID Connect per gli utenti, e token di breve durata o TLS reciproco (mutual TLS) per le chiamate tra servizi. Evitate le chiavi API condivise di lunga durata, perché nessuno può sapere quale sistema le ha usate né revocarle senza bloccare gli altri.
L'autenticazione dimostra solo chi sta chiamando. La prima voce dell'OWASP API Security Top 10 è la broken object level authorization, cioè l'autorizzazione difettosa a livello di oggetto: un utente valido cambia un identificativo nella richiesta e legge il record di qualcun altro. Verificate lato server la proprietà o l'appartenenza al tenant per ogni oggetto, ogni funzione e ogni campo sensibile, e non fidatevi mai di un identificativo o di un ruolo inviato dal client.
Date a ogni client e a ogni servizio solo i privilegi minimi necessari
Il principio del privilegio minimo limita i danni quando qualcosa va storto. Rilasciate credenziali separate per ogni consumatore, limitate i token a operazioni specifiche e tenete gli endpoint di amministrazione su un percorso separato con controlli più severi.
Applicate la stessa regola sotto l'API. L'account di servizio che legge i dati dei contatori non deve poterli cancellare, e un job di reportistica deve collegarsi con un ruolo di database in sola lettura. Rivedete i permessi a scadenze regolari, perché un accesso concesso per un'attività occasionale tende a restare per sempre.
Raccogliete meno, restituite meno e conservate per meno tempo
La minimizzazione dei dati è sia un principio del GDPR sia un controllo di sicurezza efficace: un dato mai conservato non può trapelare. Chiedetevi per ogni campo se il servizio ne ha davvero bisogno, ed eliminate o pseudonimizzate ciò che non serve.
Applicate la stessa disciplina alle risposte. Definite schemi di risposta espliciti invece di serializzare interi oggetti del database, mascherate identificativi come i numeri di conto dove il valore completo non serve, e fissate periodi di conservazione perché i record vecchi vengano cancellati. Documentate la base giuridica di ogni finalità del trattamento e firmate accordi sul trattamento dei dati con ogni fornitore che li gestisce. Queste sono pratiche di ingegneria, non consulenza legale: coinvolgete il vostro responsabile della protezione dei dati (DPO) o il vostro legale per la valutazione giuridica.
Validate ogni input e limitate ciò che un chiamante può consumare
Considerate ostile ogni richiesta finché non è stata validata. Imponete uno schema per ogni endpoint, rifiutate i campi sconosciuti e usate query parametrizzate, così un input non diventa mai parte di un comando al database.
Diversi rischi OWASP per le API derivano da limiti mancanti più che da codice difettoso. Applicate un rate limit per client, limitate la dimensione delle pagine e dei payload, e proteggete i flussi di business sensibili, come pagamenti o modifiche contrattuali, dagli abusi automatizzati. Se l'API recupera URL remoti per conto dei chiamanti, limitate le destinazioni per prevenire la server-side request forgery (SSRF).
Tenete i segreti fuori da codice, immagini e log
Password dei database, chiavi di firma e credenziali dei partner devono stare in un secret manager dedicato, essere iniettate a runtime e ruotate a scadenze regolari. Nella pipeline di build analizzate repository e immagini dei container alla ricerca di segreti, e considerate compromesso qualsiasi segreto che arrivi nel controllo di versione.
Separate i segreti per ambiente, così una credenziale di test trapelata non apre mai la produzione. Limitate chi può leggere i segreti in produzione e registrate ogni accesso.
Registrate i log per l'audit e progettate per avere meno incidenti
Gli ambienti regolamentati devono poter rispondere a posteriori a una domanda semplice: chi ha avuto accesso a quali dati, quando e tramite quale client. Registratelo per ogni lettura e scrittura sensibile, conservate i log dove chi gestisce l'applicazione non può modificarli, e tenete i dati personali fuori dai messaggi di log.
Affiancate ai log allarmi sui comportamenti insoliti, come un client che legge molti più record del solito, e un piano di risposta agli incidenti già testato. Tramite Sopra Steria i nostri ingegneri hanno costruito API sicure per dati sensibili di servizi di pubblica utilità, nel rispetto di vincoli normativi, e hanno guidato lo sviluppo di uno strumento di supervisione operativa in cui l'applicazione rigorosa degli standard di sicurezza è andata di pari passo con un minor numero di incidenti in produzione. SDK Enterprises applica oggi le stesse pratiche ai progetti dei clienti.
Punti chiave
- Un modello delle minacce sui dati, breve e scritto, deve guidare ogni controllo di sicurezza dell'API.
- Verificate l'autorizzazione lato server per ogni oggetto, funzione e campo sensibile, non solo al login.
- Il privilegio minimo vale allo stesso modo per token, account di servizio e ruoli di database.
- La minimizzazione dei dati riduce sia l'esposizione rispetto al GDPR sia l'impatto di qualsiasi violazione.
- I log di audit devono mostrare chi ha avuto accesso a che cosa e quando, senza far trapelare a loro volta dati personali.
Domande frequenti
Basta HTTPS per proteggere un'API?
No. TLS protegge i dati in transito, ma molte violazioni delle API coinvolgono chiamanti autenticati che raggiungono dati che non dovrebbero vedere. Controlli di autorizzazione, validazione degli input, rate limit e log di audit restano indispensabili.
Che cos'è la broken object level authorization?
È una falla per cui l'API verifica che un chiamante abbia effettuato l'accesso, ma non che il record richiesto gli appartenga. Cambiando un identificativo nell'URL o nel corpo della richiesta si espongono così i dati di altri utenti. La correzione è una verifica lato server della proprietà o dell'appartenenza al tenant per ogni oggetto.
Il GDPR prescrive controlli di sicurezza specifici per le API?
Il GDPR richiede misure tecniche e organizzative adeguate al rischio, senza imporre strumenti specifici. Controlli come la limitazione degli accessi, la minimizzazione, la pseudonimizzazione e i log sono modi comuni per soddisfare questo requisito, e i vostri consulenti legali dovrebbero confermare che cosa si applica al vostro caso.