Architettura di sicurezza a livelli, autenticazione enterprise-grade, monitoring continuo. Tutto quello che serve per dormire sonni tranquilli nel 2026.
Panoramica in 20 secondi
Quando un'azienda di logistica italiana integra il suo sistema di tracking con quello di cinque fornitori diversi, non può permettersi di perdere una singola comunicazione. Ma non può neanche permettersi un attacco che comprometta i dati dei clienti. Qui entra in gioco il primo livello di protezione: il perimetro esterno. Questo significa Web Application Firewall (WAF) che blocca gli attacchi più comuni come SQL injection e cross-site scripting, DDoS mitigation per assorbire i picchi di traffico malevolo, e geo-blocking per limitare l'accesso da aree geografiche inaspettate. La maggior parte degli attacchi non arriva neppure al tuo API gateway vero e proprio. Rimane intrappolata al perimetro. È come avere una ricezione che filtra i visitatori prima che entrino in azienda. Kong Enterprise e AWS API Gateway implementano questi controlli nativamente, ma la configurazione richiede una strategia: non basta accenderli, bisogna tarare le regole in base al profilo reale del tuo traffico, altrimenti blocchi anche i partner legittimi.
Il secondo livello è il trasporto dei dati. TLS 1.3 non è una raccomandazione, è un obbligo. Crittografa tutto quello che passa, punto. Ma TLS da solo non basta quando comunichi con dispositivi mobile che potrebbero essere compromessi. Qui interviene il certificate pinning: il tuo client mobile si fida solo del certificato specifico del tuo server, non di qualsiasi certificato valido secondo le autorità di certificazione. Se un attaccante compromette una CA (cosa rara ma succede), non riesce comunque a intercettare la comunicazione. Il terzo livello è l'autenticazione: chi sei veramente? Per le integrazioni web e mobile con pattern moderni, OAuth 2.0 con PKCE (Proof Key for Code Exchange) è lo standard. PKCE aggiunge uno strato di protezione contro gli attacchi di autorizzazione, soprattutto su reti non sicure come il Wi-Fi pubblico. Per le comunicazioni machine-to-machine tra aziende (B2B puro), mTLS è la scelta giusta: non solo il client autentica il server, ma il server autentica il client tramite certificati digitali. Non ci sono password da rubare, non ci sono token da esporre. Ancora più importante: i certificati scadono, vengono ruotati, tracciati. Se un certificato viene compromesso, puoi revocare l'accesso in pochi minuti.
Il quarto livello è l'autorizzazione: sei autenticato, ma hai il diritto di leggere questi dati specifici? Role-Based Access Control (RBAC) con JWT scope funziona bene per scenari semplici, dove gli utenti appartengono a ruoli chiari (amministratore, lettore, editore). Ma le aziende moderne hanno esigenze più complesse. Attribute-Based Access Control (ABAC) permette politiche fine-grained: un utente può leggere solo le fatture del cliente che gestisce, solo se è il mese di reporting, solo se la richiesta viene da una IP autorizzata. Il rate limiting adattivo completa il quadro: protegge i tuoi sistemi backend da overflow di traffico, ma non penalizza i partner legittimi che magari hanno un picco stagionale. Azure APIM e NGINX Plus offrono algoritmi di throttling sofisticati che capiscono il comportamento normale e tollerano le deviazioni ragionevoli.
Immagina di lavorare con HubSpot per gestire i lead dei clienti. Il tuo team ha già scritto codice che si aspetta una certa struttura di risposta dalle API di HubSpot. Un giorno HubSpot cambia il formato di una risposta, e il tuo sistema crolla. Non è colpa tua, non è colpa loro: manca un contratto. La versioning semantica delle API risolve questo. Ogni volta che pubblichi una nuova versione della tua API, incrementi il numero di versione in modo prevedibile (v1, v2, v3). I vecchi client continuano a usare v1 finché non sono pronti per v2. Questo significa che quando aggiorni un'API B2B, i tuoi partner italiani e europei non si trovano il codice rotto il lunedì mattina. Ma la versioning non basta: devi avere un contratto scritto. OpenAPI 3.1 è lo standard di fatto. È un documento che descrive ogni endpoint, ogni parametro, ogni risposta. Dalla stessa sorgente di verità puoi generare automaticamente gli SDK (Software Development Kit) in Python, Java, Node.js, C#, proprio come fa Zucchetti con i suoi servizi cloud per le PMI italiane. I tuoi partner scaricano l'SDK, lo integrano nel loro progetto, e sanno esattamente cosa aspettarsi.
Quando qualcosa va storto — e prima o poi va storto — non puoi perdere ore a capire dove il problema è saltato fuori. Distributed tracing con OpenTelemetry è la risposta. Una richiesta entra nel tuo API gateway, viene loggata con un ID univoco, passa attraverso il tuo servizio di autenticazione, arriva al backend, interroga il database, genera una risposta. OpenTelemetry traccia tutto questo percorso in tempo reale. Se la richiesta rallenta, vedi esattamente dove: se è il database che è lento, o la rete, o il tuo servizio. Un'azienda che gestisce pagamenti ha scoperto che le loro API B2B erano lente per un partner specifico, non per tutti. Con OpenTelemetry hanno visto che il partner stava inviando richieste malformate che il validatore rifiutava, ma il rifiuto non era istantaneo. Il tempo perso era nel parsing di XML malformato. È un dettaglio che senza distributed tracing avrebbero cercato nei log per settimane. La documentazione interattiva è ugualmente critica: un developer portal integrato nel tuo API gateway, con endpoint sandbox dove i partner possono testare senza rischiare di modificare dati reali, documentazione che si genera da OpenAPI, esempi di codice eseguibile. Quando il developer partner di un cliente di Oracle NetSuite ha accesso a tutto questo, integra l'API in tre giorni invece di tre settimane.
Non basta dire "la nostra API ha il 99% di uptime". Devi misurarlo, comunicarlo, e rispondere se non lo raggiungi. Un SLA (Service Level Agreement) è un impegno legale: gli endpoint rispondono in meno di 500 millisecondi nel 99% dei casi, disponibilità garantita del 99.95% ogni mese, se scendo sotto pago una penalità. Questo non è per paura di perdere clienti, ma per allinearsi con le esigenze reali. Se il tuo partner usa la tua API per servizio al cliente finale, sa che se il tuo servizio crolla, il suo crolla. L'SLA lo protegge. Per le API che scambiano dati personali (anche il nome e l'email dei clienti), il GDPR richiede accountability: documenti cosa fai con i dati, chi vi ha accesso, quanto tempo li conservi. Se il partner è in UE, rientra nel GDPR. Se qualcuno fa una richiesta di cancellazione dati (right to be forgotten), devi cancellare i dati del partner immediatamente, e il partner a sua volta deve cancellare i dati che ha copiato. La NIS2, la nuova direttiva europea sulla cybersicurezza in vigore dal 2025, aggiunge obblighi ancora più stringenti se la tua API appartiene a un'infrastruttura critica (energia, trasporti, telecom, sanità). Devi riportare i breach entro 24 ore, mantenere log dettagliati, fare penetration test almeno una volta l'anno. HashiCorp Vault o Azure Key Vault risolvono un problema concreto: dove memorizzi le credenziali (password, token, chiavi private) che il tuo sistema usa per autenticarsi verso altre API? Non in chiaro nel codice sorgente, per l'amor di Dio. In un vault: un sistema centralizzato, crittografato, che ruota automaticamente i segreti, che registra chi ha accesso e quando. Se un dipendente che non dovrebbe più accedere al sistema partner mantiene un'API key memorizzata in chiaro nel suo laptop, il danno è fatto. Con un vault, le credenziali scadono, vengono ruotate, e il dipendente semplicemente non riesce più a fare nulla.
OAuth 2.0 con PKCE per web e mobile, mTLS per machine-to-machine B2B puro, API key automaticamente ruotate per sistemi legacy. Nessuna password in chiaro, nessun token esposto. Controllo granulare di chi accede e da dove.
Web Application Firewall blocca gli attacchi al perimetro, DDoS mitigation assorbe i picchi malevoli, TLS 1.3 crittografa tutto, certificate pinning protegge i client mobile da CA compromesse. Non entra neanche un attacco.
Throttling intelligente che protegge il backend senza penalizzare i partner legittimi, Role-Based Access Control per ruoli semplici, Attribute-Based Access Control per politiche complesse (leggi solo le fatture del cliente che gestisci). Italy Soft progetta architetture di API gateway sicuri che si adattano alla complessità reale delle integrazioni B2B aziendali.
Versioning delle API previene breaking changes ai partner, OpenAPI 3.1 genera SDK automaticamente, OpenTelemetry traccia ogni richiesta in tempo reale per debug cross-system, SLA espliciti con uptime target e penalty garantiscono accountability.
Italy Soft
In 30 minuti di audit gratuito analizziamo i tuoi processi e calcoliamo il ROI concreto. Nessun impegno.