A cura di Giovanni Masi
La nuova frontiera della sicurezza aziendale non si gioca più dentro un perimetro riconoscibile. I sistemi critici si muovono tra cloud pubblici, ambienti privati, piattaforme SaaS, supply chain software e servizi di intelligenza artificiale. In questo scenario, difendere significa prima di tutto governare: sapere dove sono i dati, quali vulnerabilità sono davvero sfruttate, quali identità possono accedere ai workload e quali decisioni possono essere automatizzate senza perdere controllo. Multicloud governance, Threat Intelligence e SOC agentico non sono quindi tre capitoli separati della trasformazione digitale. Sono tre livelli della stessa architettura difensiva.
Il multicloud ha spostato il perimetro nel punto più difficile da controllare
Il multicloud è spesso entrato nelle organizzazioni per stratificazione più che per scelta organica. Un team ha adottato un provider per l’analisi dei dati, un altro ha scelto servizi gestiti per applicazioni legacy, altri ancora hanno cercato acceleratori per l’AI, strumenti di sicurezza o regioni più adatte a esigenze normative. Il risultato è una potenza infrastrutturale notevole, ma anche una superficie di esposizione più ampia, fatta di identità replicate, policy non omogenee, log distribuiti e modelli di costo difficili da comparare.
La governance serve a evitare che questa flessibilità diventi frammentazione. Non riguarda soltanto il bilanciamento dei carichi di lavoro in base a prezzo e prestazioni, ma la capacità di associare ogni workload a requisiti di rischio, conformità, sovranità del dato, continuità operativa e costo di uscita. Le regole europee del Data Act, applicabili dal 12 settembre 2025, hanno rafforzato l’attenzione sulla portabilità e sul passaggio tra servizi cloud, confermando che la dipendenza da un fornitore non è più solo una questione tecnica o contrattuale, ma un tema di autonomia strategica.
Anche l’evoluzione cloud native spinge nella stessa direzione. La diffusione di Kubernetes come strato operativo per applicazioni e workload di AI ha reso più concreta l’idea di portabilità, ma non l’ha resa automatica. Container, API e infrastruttura come codice aiutano a replicare ambienti, applicare controlli prima del rilascio e ridurre errori manuali. Senza standard comuni su logging, cifratura, tagging, gestione delle chiavi e identità, però, il multicloud resta un mosaico di piattaforme che reagiscono in modo diverso allo stesso evento di sicurezza.
L’intelligence trasforma il rumore in priorità operative
La crescita della superficie d’attacco rende impraticabile una difesa basata sulla stessa urgenza per ogni segnale. Le organizzazioni ricevono migliaia di alert, advisory, indicatori e notifiche di vulnerabilità. La Threat Intelligence nasce per dare un ordine a questa massa di informazioni, distinguendo tra rischio teorico e rischio operativo. Un CVE con punteggio elevato non ha lo stesso peso se colpisce un asset isolato o un servizio esposto a Internet, se è già sfruttato in attacchi reali o se riguarda un settore osservato da gruppi attivi.
Il valore dell’intelligence sta nella contestualizzazione. Un indirizzo IP sospetto è un dato; la sua associazione a una campagna ransomware è un’informazione; la valutazione che quella campagna stia prendendo di mira organizzazioni simili, sfruttando una tecnologia presente nell’ambiente aziendale, diventa intelligence. È questo passaggio a rendere più difendibile il patching, più mirato il threat hunting e più efficace la pianificazione della risposta agli incidenti.
I report più recenti descrivono un quadro in cui vulnerabilità, identità e sistemi di bordo restano punti critici. Mandiant ha segnalato per il 2025 un uso persistente degli exploit come vettore iniziale, insieme a una crescente attenzione degli attaccanti verso dispositivi di rete, ambienti di virtualizzazione, token OAuth e servizi SaaS. Verizon, nel DBIR 2026, continua a descrivere un quadro in cui elemento umano, social engineering, phishing, credenziali sottratte e sfruttamento di vulnerabilità software restano componenti centrali delle violazioni, senza ridurre il fenomeno a un solo vettore dominante.
Cataloghi come il Known Exploited Vulnerabilities della CISA sono diventati strumenti indispensabili proprio perché aiutano a dare precedenza alle falle osservate in attacchi reali, non soltanto a quelle valutate come gravi in astratto.
In un ambiente multicloud, questa capacità di prioritarizzazione è ancora più importante. La stessa vulnerabilità può avere impatti diversi a seconda della regione, dell’esposizione pubblica, dei privilegi collegati all’identità di servizio e delle dipendenze tra piattaforme. L’intelligence efficace non resta in un portale separato: alimenta la gestione delle vulnerabilità, aggiorna le regole del SOC, orienta la rotazione delle credenziali, suggerisce controlli sulle configurazioni cloud e fornisce al management una lettura del rischio comprensibile anche fuori dai team tecnici.
Il SOC agentico nasce dove la velocità umana non basta più
Se la Threat Intelligence stabilisce che cosa conta, il SOC deve trasformare quella conoscenza in azione. Qui entra in gioco il modello agentico. I Security Operations Center tradizionali hanno già usato automazione e piattaforme SOAR per eseguire playbook, arricchire alert e aprire ticket. Il limite emerge quando gli incidenti non seguono schemi prevedibili. Un attacco moderno può combinare abuso di credenziali, movimento laterale, configurazioni cloud deboli, endpoint compromessi e attività su servizi SaaS. In questi casi, un flusso rigido rischia di fermarsi proprio quando servirebbe adattamento.
Il SOC agentico introduce agenti AI capaci di interrogare strumenti diversi, formulare ipotesi, confrontare indicatori, generare query, sintetizzare evidenze e proporre percorsi di risposta. Le architetture descritte da Google Cloud per le security operations prevedono sistemi multi-agente che orchestrano SIEM, feed di Threat Intelligence, piattaforme CSPM ed EDR, includendo approvazioni human-in-the-loop. Microsoft, con Security Copilot agents, colloca la stessa logica dentro workflow di sicurezza e IT operations, con agenti che gestiscono attività ripetitive e ad alto volume su cloud, identità, data security e rete.
La promessa non è sostituire l’analista, ma ridurre il tempo tra segnale e contenimento. Un agente può arricchire un alert con intelligence esterna, verificare se un asset è esposto, controllare la cronologia dei processi su un endpoint, cercare anomalie nelle identità e preparare un report leggibile. Può farlo in parallelo e con una disciplina documentale superiore a quella di molte procedure manuali, purché il sistema sia progettato per distinguere evidenza, inferenza e raccomandazione.
L’autonomia senza tracciabilità diventa un rischio aggiuntivo
Il punto più delicato è l’autonomia. In un contesto operativo maturo, un agente può chiudere un falso positivo a basso rischio o proporre una regola di rilevamento. Quando però l’azione riguarda la quarantena di un server, la revoca di privilegi, il blocco di un account amministrativo o l’isolamento di un workload produttivo, la decisione deve restare soggetta a soglie, policy e approvazioni esplicite. La velocità non può cancellare la responsabilità.
Questo principio collega direttamente SOC agentico e multicloud governance. Ogni agente deve avere identità, permessi e limiti chiari. Un componente incaricato di raccogliere prove non dovrebbe poter eseguire azioni di contenimento ad alto impatto. Le integrazioni con plugin, API e sistemi esterni aumentano il contesto disponibile, ma ampliano anche la superficie d’attacco. OWASP colloca prompt injection, gestione insicura degli output, supply chain dei modelli e plugin deboli tra i rischi principali delle applicazioni basate su LLM. In un SOC, questi rischi non sono astratti: un prompt malevolo, dati contaminati o privilegi eccessivi possono alterare un’indagine o produrre una risposta operativa sbagliata.
Il modello Zero Trust offre un riferimento utile perché sposta il controllo dalla posizione di rete all’identità di utenti, servizi e applicazioni. NIST SP 800-207A applica questa logica agli ambienti cloud native, multicloud e ibridi, richiedendo policy granulari valide indipendentemente dal luogo in cui gira il servizio. È lo stesso principio che dovrebbe guidare gli agenti AI difensivi: accessi minimi, verifiche continue, tracciabilità delle azioni, log centralizzati e possibilità di ricostruire perché una decisione è stata presa, su quali dati e con quale autorizzazione.
La resilienza passa dall’allineamento tra sicurezza, costi e responsabilità
La maturità non si misura dal numero di provider cloud o dalla quantità di agenti AI introdotti nel SOC. Si misura dalla capacità di collegare infrastruttura, intelligence, automazione e responsabilità organizzativa. Un multicloud ben governato rende più visibili dati, identità e dipendenze. Una Threat Intelligence integrata riduce la dispersione e concentra gli sforzi sulle minacce realmente rilevanti. Un SOC agentico, se controllato, accelera triage, indagine e contenimento senza trasformarsi in una scatola nera.
Anche la dimensione economica entra nel disegno. La FinOps Foundation, nel rapporto 2026, descrive FinOps come una disciplina sempre più proattiva e ormai estesa oltre la sola spesa cloud, con l’AI in cima all’agenda. Questo passaggio è importante perché le scelte di sicurezza e resilienza hanno costi diretti: log retention più lunga, telemetria su dispositivi di rete, backup isolati, ambienti ridondati, strumenti di osservabilità e capacità computazionale per agenti AI. Tagliare questi costi senza valutarne l’impatto può ridurre la capacità di risposta proprio quando gli attaccanti colpiscono identità, hypervisor, backup e servizi di bordo.
La direzione più solida è quindi una cybersecurity governata come sistema, non come somma di strumenti. Il board deve ricevere scenari e impatti, i team tecnici devono ottenere indicatori e priorità, gli analisti devono poter controllare il ragionamento degli agenti, procurement e legale devono valutare lock-in, residenza dei dati e clausole di uscita. In questa convergenza si trova il punto di collegamento tra i tre temi: il multicloud definisce il terreno operativo, la Threat Intelligence spiega dove arriva il rischio, il SOC agentico prova a rispondere alla velocità necessaria.
La difesa futura sarà probabilmente più automatizzata, ma non per questo meno umana. Richiederà specialisti capaci di progettare limiti, interpretare evidenze, correggere modelli, aggiornare policy e assumersi responsabilità sulle decisioni critiche. Le organizzazioni che otterranno valore non saranno quelle che delegheranno tutto all’AI, né quelle che useranno più provider senza una strategia. Saranno quelle capaci di trasformare distribuzione, conoscenza e automazione in una catena di comando verificabile, resiliente e proporzionata al rischio reale.
Bibliografia
- Google Cloud Architecture Center, Agentic AI use case: Orchestrate security operations workflows
- Google Cloud Threat Intelligence, M-Trends 2026: Data, Insights, and Strategies From the Frontlines
- Microsoft Learn, Microsoft Security Copilot agents overview
- Verizon Business, 2026 Data Breach Investigations Report
- CISA, Known Exploited Vulnerabilities Catalog
- ENISA, Threat Landscape
- MITRE, ATT&CK Knowledge Base
- NIST, SP 800-207A: A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments
- FinOps Foundation, State of FinOps 2026 Report
- Cloud Native Computing Foundation, The Annual Cloud Native Survey: The Infrastructure of AI’s Future
- European Commission, Data Act
- OWASP Foundation, Top 10 for Large Language Model Applications