Governance della sicurezza delle API: evidenze ISO 27001 per il 2026

Il rilievo di audit sulle API che arriva prima della violazione

Maria, CISO di una società fintech SaaS in rapida crescita, apre un’e-mail del lead auditor tre settimane prima della valutazione annuale. Il messaggio è diretto:

“Condurremo un riesame approfondito del vostro quadro di gestione del rischio ICT di terze parti e del relativo allineamento a DORA, NIS2 e GDPR, con un focus specifico sul vostro ecosistema API. Vi chiediamo di fornire inventario, modello di autenticazione, evidenze di limitazione della frequenza delle richieste e copertura del logging per le API di produzione e dei partner.”

Due giorni dopo, l’audit interno invia un secondo messaggio:

“Abbiamo individuato 47 endpoint API pubblici non presenti nell’inventario degli asset. Quattro accettano chiavi API senza evidenze di rotazione. Un’integrazione con un partner non prevede limitazione della frequenza delle richieste. Il logging è incoerente tra i servizi di produzione. Vi chiediamo di fornire entro venerdì le evidenze ISO 27001, GDPR e NIS2.”

Non c’è alcuna nota di ransomware. Nessuna violazione pubblica. Nessun reclamo dei clienti. Ma il rilievo è grave perché espone una lacuna di governance che gli attaccanti già sfruttano. Le API sono ormai il vero perimetro. Collegano pagamenti, onboarding, identità, portali clienti, servizi dei fornitori, app mobili, workload cloud, piattaforme di analisi e motori di rischio esternalizzati.

Un quasi incidente rende il problema ancora più difficile da ignorare. Uno sviluppatore junior, sotto pressione, ha esposto su Internet un’API di staging priva di autenticazione. Conteneva dati cliente realistici e pseudonimizzati. Il red team l’ha trovata per primo, ma la direzione ha posto la domanda inevitabile: cos’altro è esposto?

Nel 2026, la governance della sicurezza delle API non è soltanto una checklist per sviluppatori. CISO, responsabili della conformità, auditor interni e consigli di amministrazione devono dimostrare che le API sono conosciute, assegnate a un titolare, autenticate, monitorate, soggette a limitazione della frequenza delle richieste, testate, valutate sotto il profilo del rischio e incluse nella segnalazione degli incidenti. Le stesse evidenze devono spesso soddisfare aspettative di assurance allineate a ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 e COBIT.

La maggior parte delle organizzazioni dispone già di strumenti tecnici: gateway API, provider di identità, piattaforme SIEM, WAF, log cloud, service mesh, pipeline CI/CD e sistemi di ticketing. Ciò che spesso manca è la narrativa di controllo. Quali API rientrano nell’ambito di applicazione? Chi approva le nuove API? Quali log dimostrano i fallimenti di autenticazione? Quale registro mostra le dipendenze da API di terze parti? Perché i limiti di frequenza sono diversi per API cliente, API amministrative e API machine-to-machine?

L’approccio di Clarysec consiste nel trattare la governance della sicurezza delle API come un sistema di evidenze di conformità trasversale, non come un’attività ingegneristica una tantum. Se un’API può esporre dati, modificare un processo aziendale, autenticare un utente, attivare un pagamento, chiamare un fornitore o supportare un servizio regolamentato, deve rientrare nel modello di evidenze del SGSI.

Perché la governance delle API è ora una questione da consiglio di amministrazione

NIS2 rende la governance della cibersicurezza una responsabilità dell’organo di gestione. Article 20 richiede agli organi di gestione di approvare le misure di gestione dei rischi di cibersicurezza, sovrintendere alla loro attuazione e ricevere formazione per comprendere i rischi di cibersicurezza e il loro impatto sui servizi. Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, comprese analisi dei rischi, politiche di sicurezza, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione e sviluppo sicuri, gestione delle vulnerabilità, valutazione dell’efficacia, igiene informatica, crittografia, controllo degli accessi, gestione degli asset e autenticazione a più fattori o autenticazione continua ove appropriato.

Per la governance delle API, ciò significa che API pubbliche, API dei partner, API amministrative e API interne di microservizi possono rientrare nell’erogazione di servizi regolamentati. NIS2 può applicarsi a fornitori di servizi di cloud computing, fornitori di servizi di data center, reti di distribuzione dei contenuti, prestatori di servizi fiduciari, reti e servizi di comunicazione elettronica accessibili al pubblico e prestatori di servizi di gestione ICT quali MSP e MSSP, in funzione di settore, dimensioni, criticità e classificazione dello Stato membro.

DORA aggiunge la prospettiva del settore finanziario. Si applica dal 17 gennaio 2025 e stabilisce requisiti uniformi per la gestione del rischio ICT, la segnalazione degli incidenti connessi all’ICT, i test di resilienza operativa digitale, la condivisione delle informazioni e la gestione del rischio ICT di terze parti. Article 5 richiede all’organo di gestione di definire, approvare, sovrintendere e mantenere la responsabilità ultima del quadro di gestione del rischio ICT. Article 8 richiede identificazione, classificazione e documentazione delle funzioni aziendali supportate dall’ICT, dei patrimoni informativi, degli asset ICT, delle dipendenze, dei processi supportati da terze parti, degli asset critici, degli inventari e del rischio ICT legacy.

In termini di API, un’API di disposizione di pagamento, un’API di scoring antifrode, un’API di onboarding cliente o un’API KYC esternalizzata non è un semplice endpoint. È un asset ICT e una dipendenza a supporto di una funzione aziendale.

GDPR completa il quadro. Le API che trasmettono identificativi, dati degli account, ID dei dispositivi, telemetria comportamentale, dati biometrici, dati relativi alla salute o profili finanziari possono trattare dati personali. Il principio di accountability del GDPR richiede ai titolari del trattamento di dimostrare la conformità a liceità, limitazione delle finalità, minimizzazione dei dati, limitazione della conservazione, integrità e riservatezza. Article 32 richiede la sicurezza del trattamento, mentre Articles 33 e 34 dipendono da evidenze affidabili quando si verifica una violazione dei dati personali.

Il consiglio di amministrazione non ha bisogno di packet capture, ma deve avere fiducia nel fatto che l’organizzazione sappia quali API sono rilevanti, quali dati trattano, da quali fornitori dipendono, come viene prevenuto l’abuso, come vengono rilevati gli incidenti e come può essere dimostrata la conformità.

Partire dall’inventario delle API

La maggior parte dei fallimenti sulle API nasce da fallimenti di inventario. Un backend mobile dismesso continua a funzionare in produzione. Un’integrazione temporanea con un partner diventa permanente. Una funzione cloud espone un nuovo endpoint. Un’API interna diventa raggiungibile da Internet dopo una modifica del load balancer. Nulla di tutto questo compare nella CMDB, quindi nulla riceve un riesame dell’autenticazione, standard di logging, soglie di limitazione della frequenza delle richieste, valutazione del fornitore o classificazione della conservazione.

La prima domanda di audit è di solito semplice: “Posso vedere il vostro inventario delle API?”

Clarysec considera l’inventario delle API parte dell’inventario degli asset del SGSI. In Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, fase Controlli in azione, passaggio 22, la guida al controllo ISO/IEC 27002:2022 5.9 spiega:

“Nessuna organizzazione può proteggere ciò che non sa di avere. Il controllo 5.9 formalizza questo principio fondamentale, richiedendo l’istituzione e il mantenimento di un inventario aggiornato di tutte le informazioni e degli asset associati rilevanti per il SGSI.”

Lo stesso passaggio include asset logici come “account utente, credenziali, chiavi, licenze software, API” e asset connessi ai servizi come piattaforme SaaS e archiviazione esternalizzata. Zenith Blueprint definisce l’inventario “il sistema nervoso centrale del vostro SGSI” perché informa il provisioning degli accessi, la cifratura, il backup, il logging, la classificazione e la conservazione.

La Politica di gestione degli asset aziendale di Clarysec Politica di gestione degli asset trasforma questo principio in un requisito di governance:

“Il responsabile degli asset IT deve mantenere un inventario degli asset completo e centralizzato che copra tutti gli asset informativi utilizzati dall’organizzazione o connessi ad essa.”

Dalla sezione “Requisiti di applicazione della politica”, clausola di policy 6.1.1.

Per le PMI, la Politica di gestione degli asset per PMI di Clarysec Politica di gestione degli asset per PMI include esplicitamente asset digitali rilevanti per le API:

“Credenziali e servizi digitali: nomi di dominio, certificati digitali, chiavi API, account e-mail, accessi cloud”

Dalla sezione “Ambito di applicazione”, clausola di policy 2.2.4.

Questa formulazione è importante. In molti audit, l’endpoint API appare in un gateway, il token in un vault per i segreti, il certificato in un account cloud e il flusso di dati in una registrazione privacy. Un inventario delle API difendibile li collega.

In Zenith Controls: The Cross-Compliance Guide Zenith Controls, il controllo ISO/IEC 27002:2022 5.9, Inventario delle informazioni e degli altri asset associati, è classificato come controllo preventivo a supporto di riservatezza, integrità e disponibilità. Il suo concetto di cibersicurezza è Identify, la sua capacità operativa è Gestione degli asset e i suoi domini di sicurezza sono governance, ecosistema e protezione. Questo aiuta gli auditor a considerare l’inventario delle API come un controllo preventivo di governance, non come un’attività amministrativa di mera tenuta documentale.

Dimostrare che ogni identità API è intenzionale

Una volta creato l’inventario, la domanda successiva è prevedibile: chi o che cosa può chiamare queste API?

Le API moderne autenticano utenti umani, app mobili, account di servizio, job CI/CD, sistemi partner, workload, bot, integrazioni, pipeline di dati e piattaforme di terze parti. Chiavi API deboli, token bearer a lunga durata, assenza di mutual TLS, scope OAuth eccessivamente privilegiati e segreti codificati direttamente nel codice creano tutti esposizione in sede di audit.

Zenith Blueprint, fase Controlli in azione, passaggio 19, affronta il controllo ISO/IEC 27002:2022 8.5, Autenticazione sicura:

“L’autenticazione è la prima e più critica linea di difesa tra un attore della minaccia e i vostri sistemi, dati e servizi. Se l’autenticazione è debole, tutto il resto, cifratura, monitoraggio, segmentazione, può essere aggirato.”

Lo stesso passaggio evidenzia l’autenticazione machine-to-machine. Chiavi, certificati e token devono essere protetti con rigore, le credenziali non devono essere incorporate nel codice e per l’archiviazione sicura e la rotazione devono essere utilizzati strumenti di gestione dei segreti o vault.

La Politica sui requisiti di sicurezza delle applicazioni aziendale di Clarysec Politica sui requisiti di sicurezza delle applicazioni porta questo requisito direttamente nella governance delle API:

“Tutte le interfacce di programmazione delle applicazioni (API), i microservizi e le integrazioni esterne devono essere protetti mediante:”

Dalla sezione “Requisiti di governance”, clausola di policy 5.3.

Specifica quindi:

“Applicazione dell’autenticazione forte, come OAuth 2.0 e mutual TLS”

Dalla sezione “Requisiti di governance”, clausola di policy 5.3.1.

Per le organizzazioni più piccole, la Politica sui requisiti di sicurezza delle applicazioni per PMI di Clarysec Politica sui requisiti di sicurezza delle applicazioni per PMI fornisce la base di riferimento:

“Controlli di autenticazione: le applicazioni devono applicare l’autenticazione forte, inclusi requisiti minimi di robustezza delle password, blocco dell’account dopo tentativi non riusciti e timeout di sessione.”

Dalla sezione “Requisiti di applicazione della politica”, clausola di policy 6.1.1.2.

Per le API, questi requisiti devono essere convertiti in un pacchetto di evidenze sull’autenticazione:

1. Inventario delle API filtrato per API esposte a Internet, rivolte ai partner, amministrative e interne.
2. Matrice di autenticazione che mostri OAuth 2.0, mTLS, richieste firmate, autorizzatori del gateway o identità del service mesh.
3. Registro dei client e degli scope OAuth con titolare, finalità, scadenza, approvazione e data dell’ultimo riesame.
4. Evidenze di gestione dei segreti relative ad archiviazione, accesso, rotazione e revoca.
5. Riesame degli accessi API privilegiati per endpoint amministrativi e account di servizio di produzione.
6. Log di autenticazione non riuscita e regole di allerta.
7. Risultati dei test per scenari di token mancante, token scaduto, audience errata, scope errato e replay.

In Zenith Controls, il controllo ISO/IEC 27002:2022 8.5, Autenticazione sicura, è mappato come controllo preventivo a supporto di riservatezza, integrità e disponibilità. Il suo concetto di cibersicurezza è Protect, la sua capacità operativa è Gestione delle identità e degli accessi e il suo dominio di sicurezza è Protezione.

NIS2 Article 21 supporta questo approccio tramite controllo degli accessi, crittografia e autenticazione a più fattori o continua ove appropriato. DORA si aspetta che le entità finanziarie mantengano controlli che proteggano autenticità, integrità, disponibilità e riservatezza. GDPR Article 32 trasforma un’autenticazione API debole in un tema di sicurezza del trattamento, soprattutto quando sono esposti dati personali.

Trattare la limitazione della frequenza delle richieste come evidenza di resilienza

L’autenticazione forte è necessaria, ma non sufficiente. Un client autenticato può comunque abusare di un’API. Gli attaccanti usano le API per credential stuffing, enumerazione, scraping, token spraying, bombardamento delle reimpostazioni password, abuso transazionale e denial-of-service.

La limitazione della frequenza delle richieste era considerata in passato una funzionalità di prestazione. Nel 2026 è evidenza di sicurezza, privacy e resilienza.

La Politica sui requisiti di sicurezza delle applicazioni di Clarysec stabilisce:

“Limitazione della frequenza delle richieste e prevenzione degli abusi”

Dalla sezione “Requisiti di governance”, clausola di policy 5.3.2.

Zenith Blueprint, fase Controlli in azione, passaggio 20, per il controllo ISO/IEC 27002:2022 8.26, Requisiti di sicurezza delle applicazioni, spiega che i requisiti di sicurezza delle applicazioni devono essere precisi e azionabili. Chiede se un’applicazione debba essere resiliente ad attacchi di injection, accessi brute-force o tentativi di denial-of-service. Fornisce anche l’esempio specifico delle API: una nuova API dovrebbe includere la validazione dei token di accesso e la sanitizzazione degli input, e osserva che le piattaforme esposte pubblicamente possono richiedere validazioni più rigorose, analisi del comportamento degli utenti e limitazione della frequenza delle richieste.

Una registrazione difendibile sulla limitazione della frequenza delle richieste deve spiegare non solo che esiste il controllo, ma anche perché sono state selezionate determinate soglie, chi ha approvato le eccezioni e come vengono monitorate le allerte.

Per NIS2, questo supporta sviluppo sicuro, valutazione dell’efficacia, continuità operativa e prevenzione degli incidenti. Per DORA, la limitazione della frequenza delle richieste si collega alla gestione del rischio ICT, al rilevamento delle anomalie, ai test di resilienza e alla continuità delle funzioni critiche o importanti. Per GDPR, supporta la minimizzazione dei dati e la protezione contro accessi eccessivi o illeciti, soprattutto quando lo scraping delle API potrebbe esporre dati personali.

Rendere il logging il livello delle evidenze

Quando si verifica un incidente API, la prima vera domanda non è “Avete un SIEM?”. È “Potete ricostruire che cosa è accaduto?”

I log delle API devono acquisire fallimenti di autenticazione, dinieghi di autorizzazione, claim dei token, identità del client, origine, endpoint, metodo, esito della richiesta, modifiche amministrative, accessi a dati ad alto rischio, eventi di limitazione della frequenza delle richieste, volumi anomali, modifiche di configurazione ed errori rilevanti per la sicurezza. Devono inoltre evitare di registrare segreti, token bearer o dati personali non necessari.

Zenith Blueprint, fase Controlli in azione, passaggio 19, per il controllo ISO/IEC 27002:2022 8.15, Logging, afferma:

“Il logging è la linfa vitale di qualsiasi ambiente IT sicuro. Senza di esso, gli incidenti restano invisibili, l’accountability si indebolisce e le relazioni di causa-effetto svaniscono nel nulla.”

Spiega inoltre che il logging riguarda la tracciabilità e che i log utili devono essere archiviati in modo sicuro, monitorati, riesaminati e protetti contro la manomissione.

La Politica sui requisiti di sicurezza delle applicazioni per PMI di Clarysec richiede:

“Registrazione di audit: le applicazioni devono registrare gli eventi di autenticazione (accessi, disconnessioni e tentativi non riusciti), l’accesso ai dati e le modifiche amministrative.”

Dalla sezione “Requisiti di applicazione della politica”, clausola di policy 6.1.1.7.

La Politica di logging e monitoraggio per PMI di Clarysec Politica di logging e monitoraggio per PMI stabilisce la categoria di governance del logging:

“Tipi di log richiesti”

Dalla sezione “Requisiti di governance”, clausola di policy 5.4.

Per le API ospitate nel cloud, la Politica di utilizzo del cloud aziendale di Clarysec Politica di utilizzo del cloud rafforza il requisito:

“I log devono acquisire:”

Dalla sezione “Requisiti di applicazione della politica”, clausola di policy 6.5.2.

In Zenith Controls, il controllo ISO/IEC 27002:2022 8.15, Logging, è mappato come controllo di rilevamento a supporto di riservatezza, integrità e disponibilità. Il suo concetto di cibersicurezza è Detect, la sua capacità operativa è la gestione degli eventi di sicurezza delle informazioni e i suoi domini di sicurezza sono Protezione e Difesa. Questo rende il logging il ponte tra policy e prova.

NIS2 Article 23 richiede una segnalazione per fasi degli incidenti significativi: preallarme entro 24 ore dalla conoscenza, notifica dell’incidente entro 72 ore, relazioni intermedie se richieste e relazione finale entro un mese dalla notifica. Per i prestatori di servizi fiduciari interessati nella fornitura di servizi fiduciari, è richiesta la notifica entro 24 ore dalla conoscenza.

DORA Articles 17 to 19 richiedono la gestione degli incidenti connessi all’ICT con indicatori di allerta precoce, classificazione di gravità e criticità, escalation, logging, follow-up dell’analisi della causa radice e segnalazione degli incidenti ICT gravi tramite relazioni iniziali, intermedie e finali. Anche la valutazione delle violazioni GDPR dipende dai log per determinare se siano stati consultati dati personali, quali interessati siano stati coinvolti e se si attivino obblighi di notifica.

Costruire un pacchetto di evidenze API in cinque giorni lavorativi

L’obiettivo di uno sprint rapido non è correggere tutta la sicurezza delle API in una settimana. L’obiettivo è creare una base di riferimento difendibile, identificare le lacune e avviare il trattamento del rischio.

Giorno 1: istituire il registro delle API

Esportare le route da gateway API, service mesh, load balancer cloud, funzioni serverless, repository OpenAPI e manifest di deployment CI/CD. Normalizzarle in un unico registro delle API con endpoint, ambiente, titolare, processo aziendale, classificazione dei dati, indicatore di dati personali, metodo di autenticazione, limite di frequenza, stato del logging, dipendenza da fornitore, criticità e data dell’ultimo riesame.

Utilizzare la clausola 6.1.1 della Politica di gestione degli asset e il passaggio 22 di Zenith Blueprint come riferimento di governance.

Giorno 2: classificare le lacune di autenticazione

Creare una matrice di autenticazione. Segnalare le API che utilizzano chiavi API statiche, token a lunga durata, assenza di validazione dell’audience, assenza di validazione dello scope, mTLS mancante per integrazioni con partner, account di servizio condivisi o assenza di evidenze di rotazione.

Mappare le risultanze alla clausola 5.3.1 della Politica sui requisiti di sicurezza delle applicazioni e al passaggio 19 di Zenith Blueprint. Registrare ogni lacuna come rischio con un titolare, un percorso di trattamento e una data obiettivo.

Giorno 3: dimostrare limitazione della frequenza delle richieste e controlli anti-abuso

Per API pubbliche, partner e amministrative, acquisire policy del gateway, regole WAF, controlli bot, impostazioni delle quote e soglie di allerta. Dove i controlli sono assenti, registrare controlli compensativi o trattamento del rischio aperto.

Utilizzare la clausola 5.3.2 della Politica sui requisiti di sicurezza delle applicazioni come autorità della policy. Per le API critiche, collegare le soglie all’impatto sul servizio, al danno per il cliente e alle aspettative di resilienza DORA o NIS2.

Giorno 4: validare la copertura del logging

Campionare i log delle API ad alto rischio. Confermare che i log acquisiscano autenticazione riuscita, autenticazione non riuscita, diniego di autorizzazione, accesso ai dati, modifica amministrativa, evento di limitazione della frequenza delle richieste, identità dell’origine e correlation ID. Verificare sincronizzazione temporale, conservazione, controllo degli accessi e protezione contro la manomissione.

Se i log contengono token, segreti o dati personali eccessivi, aprire attività di remediation privacy e sicurezza.

Giorno 5: consegnare il pacchetto di risposta all’audit

Consegnare un set di evidenze conciso:

• Esportazione dell’inventario delle API e sintesi delle titolarità.
• Registro dei rischi API con piano di trattamento del rischio.
• Matrice di autenticazione ed evidenze di riesame dei token.
• Evidenze di limitazione della frequenza delle richieste ed eccezioni approvate.
• Report di copertura del logging e screenshot dei cruscotti SIEM.
• Playbook di classificazione degli incidenti per abuso delle API.
• Mappatura di conformità trasversale verso viste di audit allineate a ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 e COBIT.

Il passaggio importante è che ogni elemento di evidenza abbia una narrativa di controllo. Il registro delle API supporta la gestione degli asset. L’autenticazione supporta il controllo degli accessi. I limiti di frequenza supportano sicurezza delle applicazioni e resilienza. I log supportano rilevamento, risposta agli incidenti e accountability.

Mappatura di conformità trasversale per la governance delle API

L’errore più grande è costruire set di evidenze separati per ogni quadro di riferimento. La governance delle API funziona meglio come un unico modello di controllo con più viste regolatorie.

ISO/IEC 27001:2022 fornisce il sistema di gestione che tiene insieme le evidenze. Le clausole da 4.1 a 4.4 richiedono all’organizzazione di definire contesto e campo di applicazione del SGSI, incluse parti interessate, obblighi legali, normativi e contrattuali, nonché interfacce o dipendenze con altre organizzazioni. Le clausole da 5.1 a 5.3 assegnano l’accountability all’alta direzione. Le clausole da 6.1.1 a 6.1.3 creano il processo di valutazione del rischio, trattamento del rischio e Dichiarazione di Applicabilità. La clausola 8.1 richiede pianificazione operativa e controllo, incluso il controllo sui processi, prodotti o servizi esternalizzati rilevanti per il SGSI.

Per la governance delle API, ciò significa che un’API di pagamento di terze parti, un’API di identità cloud o un’API di rilevamento frodi esternalizzata non è fuori dal perimetro di conformità perché esterna. È un’interfaccia e una dipendenza che devono essere incluse nell’ambito di applicazione, valutate sotto il profilo del rischio e controllate.

NIST CSF 2.0 aggiunge una vista esecutiva utile. La sua funzione GOVERN aiuta le organizzazioni a definire aspettative degli stakeholder, obblighi legali, propensione al rischio e rischio della catena di fornitura. L’approccio dei Profili supporta un Profilo corrente, un Profilo target, un piano delle lacune prioritizzato e un ciclo di miglioramento continuo. È esattamente così che dovrebbe operare uno sprint di governance delle API.

COBIT 2019 può supportare la prospettiva di gestione collegando i controlli API a obiettivi di governance, titolarità dei controlli, continuità dei servizi, monitoraggio della sicurezza, reporting dei rischi e tracciamento delle problematiche. La chiave non è forzare le API dentro un singolo quadro di riferimento, ma dimostrare che un unico modello di evidenze risponde a più domande di assurance.

Come gli auditor testano la governance delle API

Un programma solido anticipa la prospettiva dell’auditor. Le stesse evidenze saranno testate in modo diverso a seconda del quadro di riferimento.

Clarysec raccomanda la triangolazione delle evidenze. Non mostrare soltanto la policy. Mostrare la policy, le evidenze di attuazione e le evidenze operative.

Ad esempio:

• Policy: le API devono usare OAuth 2.0 o mTLS ove appropriato.
• Configurazione: la route del gateway API mostra la validazione JWT e l’audience consentita.
• Evidenza operativa: i tentativi con token non validi sono registrati nei log e le allerte sono attive.
• Evidenza di riesame: il riesame del client OAuth è stato completato con approvazione del titolare.
• Evidenza di rischio: un’eccezione per API legacy dispone di controlli compensativi e di una scadenza di trattamento.

Questo è molto più solido di una risposta basata solo su screenshot.

Insidie comuni nella governance delle API

Il problema più comune non è che le API siano completamente prive di sicurezza. È che la sicurezza è incoerente.

Un team usa correttamente gli scope OAuth, un altro usa una chiave API condivisa. Un servizio registra nei log l’accesso ai dati, un altro registra solo errori del server. Un’integrazione con partner usa mTLS, un’altra si affida a un token bearer a lunga durata. Esistono limiti di frequenza per gli endpoint pubblici, ma non per le API cliente autenticate dove può verificarsi scraping. La CMDB elenca l’applicazione, ma non le sue API, i token, i certificati, le categorie di dati o i fornitori.

Le insidie ricorrenti includono:

• Shadow API distribuite tramite funzioni serverless o route temporanee di test.
• Chiavi API archiviate in variabili CI/CD senza rotazione documentata.
• Logging che acquisisce token, segreti o dati personali non necessari.
• Assenza di correlation ID tra log di gateway, applicazione e database.
• Eccezioni ai limiti di frequenza concesse informalmente a grandi clienti.
• API dei partner prive di clausole contrattuali per la notifica degli incidenti o il diritto di audit.
• Assenza di classificazione degli incidenti specifica per API per enumerazione, scraping o abuso dei token.
• Assenza di mappatura tra flussi di dati API e registrazioni dei trattamenti GDPR.
• Test di sicurezza concentrati sull’interfaccia web mentre le API restano non testate.
• Reporting al consiglio che mostra “sicurezza delle applicazioni” senza metriche di rischio specifiche per le API.

Sono problemi risolvibili, ma solo se l’organizzazione tratta la governance delle API come un dominio di controllo gestito.

Trasformare la sicurezza delle API in governance pronta per l’audit

Se il prossimo audit richiede evidenze sulla sicurezza delle API, non iniziare raccogliendo screenshot casuali. Parti dalla narrativa di controllo.

Clarysec può aiutarti a costruirla con:

• Zenith Blueprint Zenith Blueprint per strutturare l’attuazione su inventario degli asset, autenticazione sicura, requisiti di sicurezza delle applicazioni e logging.
• Zenith Controls Zenith Controls per mappare controlli ISO/IEC 27002:2022 come 5.9, 8.5, 8.15 e 8.26 rispetto alle aspettative di conformità trasversale e alle prospettive di audit.
• Politiche Clarysec, incluse Politica di gestione degli asset Politica di gestione degli asset, Politica sui requisiti di sicurezza delle applicazioni Politica sui requisiti di sicurezza delle applicazioni, Politica di utilizzo del cloud Politica di utilizzo del cloud, Politica di gestione degli asset per PMI Politica di gestione degli asset per PMI, Politica sui requisiti di sicurezza delle applicazioni per PMI Politica sui requisiti di sicurezza delle applicazioni per PMI e Politica di logging e monitoraggio per PMI Politica di logging e monitoraggio per PMI.

Un passo successivo pratico è eseguire uno Sprint Clarysec sulle evidenze di governance delle API: inventariare le API, classificare l’autenticazione, verificare la limitazione della frequenza delle richieste, validare il logging, mappare le dipendenze da terze parti e produrre un pacchetto di evidenze pronto per ISO 27001 con viste di audit allineate a NIS2, DORA, GDPR, NIST CSF 2.0 e COBIT.

Le API sono il punto in cui logica di business, dati dei clienti e dipendenze da terze parti si incontrano. Nel 2026 meritano più della protezione tecnica. Hanno bisogno di una governance in grado di reggere un audit, supportare una risposta all’autorità di regolamentazione e aiutare i team a rilevare gli abusi prima dei clienti.