SaaS, Integrazioni e AI: JP Morgan Suona l'Allarme (E Conferma i Nostri Sospetti)

Quando il Gigante Sputa il Rospo (Era Ora!)

Nell'articolo precedente, ci siamo messi qui a distinguere il Real Cloud dalla fuffa cosmica, dal Fake Cloud e dal solito "computer di qualcun altro" con lo sticker sopra? A me sembrava quasi un esercizio di stile utile a sgranchire le dita sulla tastiera e a mettere un punto fermo ai pensieri di ogni giorno, un lamento tra addetti ai lavori stanchi del marketing tossico. Bene, tenetevi forte, non sono il solo a pensarlo: il problema è molto più profondo, sistemico e pericoloso. 

E la notizia non è tanto il problema in sé, quanto chi l'ha appena messo nero su bianco con una lettera aperta che ha fatto allarme ma fa anche molto awareness sui "rischi correlati"; la mano che ha scritto questa lettera è di Patrick Opet, il Chief Information Security Officer di JPMorgan Chase (non propriamente un'IT Company).

Si, questa JPMorgan Chase

Non capita tutti i giorni che un CISO di quel calibro prenda carta e penna (virtuale, si capisce) per denunciare pubblicamente le fondamenta scricchiolanti su cui poggia gran parte dell'ecosistema SaaS moderno e, di conseguenza, l'economia globale. Non che ci volesse JPM per capire che la baracca rischia di crollare – molti di noi lo mormorano (o lo urlano) da anni nelle trincee dell'IT e della cybersecurity – ma quando il monito arriva da uno dei più grandi "clienti" del mondo, forse, forse, qualcuno inizia ad ascoltare (NdR: si dai fatemi fare il tragico come sempre, almeno a casa mia).

Opet non usa mezzi termini: 

il modello di delivery SaaS, combinato con le moderne pratiche di integrazione via API e protocolli come OAuth, sta creando vulnerabilità sostanziali. E l'attuale corsa sfrenata verso l'Intelligenza Artificiale? Sta semplicemente gettando litri di benzina su un incendio che già covava sotto la cenere (semi-cit.). 

Vediamo perché (e perché le sue parole dovrebbero farci drizzare le antenne, non solo annuire).

Ah, dimenticavo, SaaS, *aaS, et similiar hanno un unico comune denominatore: third-party supplier (e relativi rischi ma ci arriviamo articolo dopo articolo ;-) )

La Diagnosi (Impietosa) di JPM: Anatomia di un Ecosistema Fragile

La lettera di Opet è un j'accuse lucido e articolato. Mette in fila i peccati originali (e quelli più recenti) del nostro moderno modo di costruire e consumare software. Smontiamoli:

• Rischio Concentrato = Rischio Sistemico: Sembrava una buona idea, no? Consolidare tutto su pochi, grandi provider SaaS e PaaS. Efficienza! Innovazione rapida! Peccato che, come sottolinea JPM, questo crei anche singoli punti di failure (SPOF) di portata potenzialmente catastrofica. Oggi, un incidente serio presso uno dei soliti noti (pensate ad AWS, Azure, GCP, ma anche Salesforce, Microsoft 365, Okta...) non colpisce solo una manciata di aziende: può paralizzare catene di approvvigionamento globali, infrastrutture critiche, l'intera economia. Abbiamo costruito bastioni digitali su fondamenta condivise, dimenticandoci che basta una crepa in quelle fondamenta per far tremare tutti. Efficiente, sì. Resiliente? Molto meno.
• La Feature Vince (Quasi) Sempre sulla Sicurezza: Questa è musica per le orecchie di chiunque abbia provato a far passare una misura di sicurezza "non funzionale" in un ciclo di sviluppo agile spinto al massimo. JPM lo dice chiaro: la competizione feroce spinge i vendor a dare priorità al rilascio rapido di nuove feature piuttosto che alla sicurezza robusta. Risultato? Software rilasciato in fretta e furia, senza sicurezza adeguata by design o by default. La security diventa un afterthought, qualcosa da "avvitare sopra" (bolted-on) invece che "integrare dentro" (built-in). Si accumula debito tecnico e di sicurezza, creando opportunità costanti per gli attaccanti. Una situazione, dice Opet, "insostenibile" per il sistema economico. Vi suona familiare? (La domanda è retorica...)
• Architetture di Sicurezza: La Grande Regressione: Questo è forse il punto tecnicamente più devastante sollevato da JPM. Per decenni abbiamo costruito architetture basate su segmentazione rigorosa: reti separate, livelli di accesso (tiered access), terminazione di protocolli ai perimetri, isolamento logico tra risorse interne fidate ed esterne non fidate. API e siti web erano interfacce controllate, separate dai sistemi core. Oggi, invece, le moderne pratiche di integrazione (spesso spinte dalla comodità del SaaS e dalla necessità di far "parlare" tutto con tutto) hanno smantellato questi confini. Protocolli come OAuth e l'abuso di API permettono interazioni dirette e spesso poco controllate tra servizi di terze parti (il SaaS di turno, il nuovo tool AI, oppure l'enterprise app con un botto di autorizzazioni a...) e le risorse interne più sensibili (email aziendale, dati clienti, sistemi core). JPM la chiama, senza mezzi termini, una "regressione architetturale" che mina principi fondamentali di sicurezza e crea un "single-factor explicit trust" (mi fido di te perché hai un token valido, senza troppe domande) tra internet e la rete privata. Addio fossati e ponti levatoi, benvenute autostrade dirette verso i gioielli di famiglia.

L'AI come Benzina sul Fuoco (Il Rischio al Quadrato)

E se questo quadro non fosse già abbastanza preoccupante, arriva l'AI. JPM sottolinea come la "crescita esplosiva" di servizi basati su AI, automazione e agenti intelligenti stia amplificando e distribuendo rapidamente tutti i rischi appena descritti.

Perché? Semplice:

• Più Integrazioni = Più Superficie d'Attacco: Ogni nuovo tool AI, ogni agente che deve accedere ai dati aziendali per "imparare" o "agire", richiede nuove integrazioni. Spesso, queste integrazioni richiedono accessi privilegiati per essere davvero utili. Ogni connessione aggiunta, costruita su quelle fondamenta già fragili, è un potenziale punto di ingresso.
• Accessi Opachi e Rischi Nascosti: Come evidenzia JPM, spesso questi tool ottengono accessi senza consenso esplicito e granulare, o attraverso dipendenze da altri fornitori (fourth-party risk) che sono completamente invisibili al cliente finale. Chi controlla davvero cosa può fare quell'LLM integrato nel CRM? Quali dati "vede" per addestrarsi o rispondere? E i servizi esterni che lui stesso potrebbe chiamare a nostra insaputa? La domanda retorica dell'opinione che hai raccolto è perfetta: "Do you truly know what OpenAI, Copilot, Gemini, or Claude can access?" (La risposta, spesso, è un preoccupante "non proprio" per non dire "anche no").
• Velocità e Scalabilità (del Rischio): L'automazione e l'AI non accelerano solo i processi legittimi, ma anche la potenziale propagazione di un incidente. Un token rubato, un'API vulnerabile, un agente AI compromesso possono portare a danni su scala molto più vasta e rapida rispetto al passato.

La metafora è fin troppo calzante: stiamo costruendo grattacieli di intelligenza artificiale su fondamenta di sabbie mobili SaaS (questa l'ho già sentita).

La Chiamata alle Armi (Secondo JPM... e il Buon Senso)

Di fronte a questa diagnosi, JPM non si limita a lamentarsi, ma lancia una "call to action" chiara, rivolta sia ai provider che ai clienti. Tradotta per noi, suona più o meno così:

1. Sicurezza NON Opzionale: Basta slogan "Secure by Design". I provider devono integrare la sicurezza by default (opt-out, non opt-in), fornire prove continue e dimostrabili che i controlli funzionano (non solo il bollino annuale della compliance), essere trasparenti sui rischi e dare ai clienti gli strumenti per gestirli. Fornitori avvisati... (speriamo che ascoltino, ma non tratteniamo il respiro).
2. Modernizzare le Difese, Non Solo le Applicazioni: Le vecchie mura perimetrali non reggono più l'urto delle integrazioni moderne. Servono controlli robusti sulle connessioni: autenticazione e autorizzazione granulari (least privilege reale), monitoring avanzato del traffico API, detection di comportamenti anomali, politiche di accesso dinamiche e context-aware. Bisogna difendere le autostrade, non solo il castello.
3. Trasparenza Radicale: Pretendere dai vendor (e verificare!) chiarezza su quali dati accedono, perché, come li proteggono e quali altri servizi (fourth-party) utilizzano a loro volta. Il buon senso, è merce rara.
4. Riprendere il Controllo (Quando Possibile): JPM menziona opzioni come confidential computing, customer self-hosting, e bring your own cloud. Non sono soluzioni semplici né economiche, ma indicano una direzione: cercare modi per mantenere il controllo sui propri dati e sulle proprie chiavi anche quando si usano servizi esterni. La sovranità digitale non è gratis.
5. Il Potere del "NO": Forse l'arma più efficace. Iniziare a rifiutare integrazioni e servizi che non offrono garanzie di sicurezza adeguate, anche se sembrano convenienti o se il marketing/business preme. Far capire che la sicurezza è un requisito non negoziabile.

Conclusione: Sveglia! (Prima che il Castello Crolli)

La lettera di Patrick Opet è un sasso nello stagno. Non rivela verità sconosciute a chi lavora nel campo, ma ha il merito enorme di portare il problema all'attenzione del grande pubblico e, soprattutto, di dargli l'autorevolezza di uno dei più grandi "consumatori" di tecnologia al mondo. È una validazione potente per anni di preoccupazioni espresse a mezza voce.

Ma non basta che JPM suoni l'allarme. La responsabilità è collettiva, ma anche individuale. Spetta a noi, professionisti dell'IT e della cybersecurity, manager, architetti:

• Eseguire una due diligence spietata su ogni SaaS, ogni API, ogni integrazione.
• Pretendere sicurezza robusta e trasparenza dai nostri fornitori.
• Fare scelte architetturali consapevoli, comprendendo i rischi intrinseci dei modelli di integrazione moderni.
• Spingere per l'adozione di controlli più forti.

Abbiamo passato l'ultimo decennio a costruire un ecosistema digitale incredibilmente potente ma anche terribilmente fragile, sedotti dalla promessa di velocità e integrazione totale. Ora ci stiamo caricando sopra il peso massimo dell'Intelligenza Artificiale. Prima che sia troppo tardi, forse è davvero il momento di fermarsi a controllare seriamente le fondamenta, tappare le crepe più grosse e, magari, smettere di costruire piani ulteriori su palafitte che scricchiolano. Altrimenti, non avremo nemmeno più bisogno dello zainetto di pelle per portarci via le macerie.

Source: An open letter to third-party suppliers - By Patrick Opet, Chief Information Security Officer