Blog Zscaler
Ricevi gli ultimi aggiornamenti dal blog di Zscaler nella tua casella di posta
IscrivitiWorkload cloud: previsioni sulla sicurezza informatica per il 2024
Nel 2023, il mercato della sicurezza sul cloud è stato caratterizzato da transizioni dirompenti che hanno interessato ogni ambito dell'ecosistema (fornitori, prodotti e infrastruttura), generando cambiamenti molto significativi. Guardando al 2024, se da un lato la sicurezza informatica per i workload (VM, container, servizi) sul cloud pubblico continuerà a evolversi, dall'altro i clienti continueranno a ricercare un equilibrio tra l'adozione aggressiva del cloud e la conformità alle esigenze di sicurezza dell'azienda. In questo contesto, CIO e CISO richiederanno ai propri team di realizzare una piattaforma di sicurezza in grado di consolidare i prodotti separati e indipendenti in un'unica soluzione, supportare più cloud (AWS, Azure e GCP) e implementare l'automazione per favorire la scalabilità delle operazioni di sicurezza. Di conseguenza, vedremo l'architettura zero trust farsi strada negli ambiti della sicurezza dei workload cloud, della protezione dei dati in tempo reale e dell'applicazione centralizzata delle policy. Ecco le cinque principali tendenze che crediamo si svilupperanno nel 2024.
1. Aumenterà il movimento laterale delle minacce, che dagli ambienti on-premise raggiungeranno i cloud
Il cloud è il luogo in cui si dirigono le risorse più preziose delle organizzazioni, ovvero le applicazioni e i dati. Gli aggressori impiegano tecniche sempre più innovative che implicano la compromissione della rete on-premise di un'organizzazione e il movimento laterale verso il suo dominio cloud. Queste tecniche sono sempre più popolari tra gli autori delle minacce, in quanto vi sono incoerenze tra gli ambienti on-premise e gli ambienti cloud pubblici.
Un attacco spiegato nel dettaglio dal team di ricerca Microsoft Security (fonte: MERCURY and DEV-1084: Destructive Attack on Hybrid Environment) esemplifica questa tendenza. Gli autori delle minacce hanno dapprima compromesso due account con privilegi, quindi li hanno sfruttati per manipolare l'agente Connect di Azure Active Directory (Azure AD). Due settimane prima della distribuzione del ransomware, gli aggressori hanno utilizzato un account compromesso e con privilegi elevati per ottenere l'accesso al dispositivo su cui era installato l'agente Azure AD Connect. Possiamo affermare con certezza che gli autori delle minacce hanno poi utilizzato lo strumento AADInternals per estrarre le credenziali di un account Azure AD con privilegi in testo in chiaro, usandole successivamente per passare dall'ambiente on-premise preso di mira all'ambiente Azure AD target.
Fig. La compromissione si sposta dall'ambiente on-premise al cloud pubblico
2. I servizi serverless estenderanno considerevolmente la superficie di attacco
Le funzioni serverless aumentano significativamente la semplicità, consentendo agli sviluppatori di concentrarsi esclusivamente sulla scrittura e sulla distribuzione del codice, senza preoccuparsi dell'infrastruttura sottostante. L'adozione di architetture basate su microservizi continuerà a favorire l'uso delle funzioni serverless grazie alla loro riusabilità e alla capacità di accelerare lo sviluppo delle applicazioni. Tuttavia, le funzioni serverless sono accompagnate anche da significativi rischi per la sicurezza, in quanto interagiscono con varie sorgenti di input ed eventi, spesso richiedendo chiamate HTTP o API per avviare azioni. Inoltre, dato che impiegano risorse cloud come archivi BLOB o storage a blocchi, impiegano code per sequenziare le interazioni con altre funzioni e connettersi con i dispositivi. Questi punti di contatto estendono la superficie di attacco, perché molti di essi usano formati di messaggi non attendibili e non dispongono di un monitoraggio o di un controllo adeguati per assicurare una protezione standardizzata a livello applicativo.
Fig. Le funzioni serverless possono accedere all'intero stack di servizi aggiuntivi, creando una superficie di attacco molto estesa
3. Nell'ambito della protezione del cloud pubblico, le policy di sicurezza basate sull'identità verranno rielaborate
Man mano che i workload iniziano a proliferare sui cloud pubblici, ogni CSP avrà le sue funzionalità specifiche relative all'identità. A differenza degli utenti, non esiste un anello (Active Directory) per domarli tutti. In relazione ai workload, i reparti IT continueranno a gestire profili di identità scollegati tra ambienti locali, cloud privati e cloud pubblici. Detto questo, nel 2024 i team di sicurezza continueranno ad avere a che fare con diversi attributi dei workload per scrivere le proprie policy di sicurezza, e le astrazioni di livello superiore (come i tag definiti dall'utente) inizieranno a loro volta a essere adottate in modo più esteso. Questo favorirà la coerenza tra la sicurezza informatica e altre funzioni di gestione delle risorse (fatturazione, controlli degli accessi, autenticazione, reportistica) per i workload cloud.
Fig. I tag definiti dall'utente verranno utilizzati per implementare l'architettura zero trust per la protezione dei workload sul cloud
4. Le aziende valuteranno e distribuiranno piattaforme di sicurezza fornite attraverso il cloud che supporteranno più cloud pubblici
L'assunzione di personale qualificato e la creazione di architetture specializzate per proteggere tutti i cloud pubblici imporrà ai team di sicurezza l'onere di ricercare soluzioni più efficienti per soddisfare le loro esigenze. Le aziende valuteranno gli strumenti dei CSP, come ad esempio le soluzioni firewall sul cloud, ma ricercheranno sempre più architetture in grado di centralizzare le definizioni, l'applicazione e le correzioni delle policy di sicurezza sul cloud. Solo quando la prevenzione informatica viene fornita attraverso un'unica piattaforma centralizzata, la difesa può essere applicata a tutti i workload, e non solo a una selezione di essi.
5. La propensione dei CIO a diversificare le loro scelte tra AWS, Azure e GCP determinerà l'implementazione di strumenti di sicurezza in grado di estendersi agli ambienti multicloud.
In relazione alle best practice per quanto riguarda i fornitori, i CIO cercano di diversificare i propri portafogli di infrastrutture cloud. Questo consente loro di ridurre la dipendenza da un unico fornitore, di integrare l'infrastruttura ereditata da fusioni e acquisizioni e di sfruttare i servizi migliori offerti da diversi cloud pubblici, come Google Cloud BigQuery per l'analisi dei dati, AWS per le app mobili e Oracle Cloud per l'ERP.
Fig. Il framework di responsabilità condivisa di AWS per la protezione delle risorse cloud. [FONTE]
Ogni fornitore di servizi cloud predica il concetto della "responsabilità condivisa" in relazione alla sicurezza informatica, facendo gravare sul cliente l'onere di implementare un'infrastruttura di sicurezza per le proprie risorse cloud. I reparti IT più esperti si assicureranno di scegliere una piattaforma di sicurezza informatica in grado di supportare più ambienti cloud pubblici. I clienti non possono adottare strumenti di sicurezza distinti per ogni singolo cloud pubblico, e cercheranno invece un'unica piattaforma in grado di soddisfare tutte le loro esigenze.
La distribuzione dei workload sul cloud pubblico non è una tendenza nuova nel mondo aziendale, ma il tema della loro sicurezza sul cloud sta diventando sempre più scottante. Anche se non ci sono ancora risposte chiare, emergono alcuni trend su ciò su cui i clienti si concentreranno nel corso del 2024, come ad esempio lo zero trust, un approccio che fornisce vantaggi immediati a breve termine e un solido framework per supportare la sicurezza dei workload cloud in futuro. Vuoi saperne di più sullo zero trust applicato ai workload cloud? Fai clic qui per scoprire le prospettive di Zscaler.
Questo articolo fa parte di una serie di articoli che contengono visioni prospettiche su accessi e sicurezza per il 2024. Il prossimo articolo di questa serie tratterà le previsioni nel campo dello zero trust.
Dichiarazioni prospettiche
Questo articolo contiene dichiarazioni che si basano sulle assunzioni e le ipotesi del nostro management e sulle informazioni attualmente a sua disposizione. Parole ed espressioni che indicano l'incertezza associata al verificarsi di eventi o risultati futuri, come "potenzialmente", "si ritiene", "si stima", "si prevede, "si intende", altri verbi come "continuare", "progettare", "pianificare", o l'uso di verbi come "potrebbe", "dovrebbe", indicano visioni prospettiche che includono, a titolo esemplificativo ma non esaustivo, affermazioni riguardanti: le previsioni sullo stato del settore della sicurezza informatica nel 2024 e sulla nostra capacità di capitalizzare tali opportunità di mercato, i vantaggi attesi e l'incremento dell'adozione sul mercato dei modelli "as-a-service" e dell'architettura zero trust per contrastare le minacce informatiche, e le opinioni sulla capacità dell'IA e del machine learning di ridurre i tempi di rilevamento e risposta alle minacce e di identificarle/fermarle proattivamente. Tali visioni prospettiche sono soggette alle disposizioni "safe harbor" create dal Private Securities Litigation Reform Act del 1995, e pertanto sono sottoposte a una serie di rischi, incertezze e ipotesi e a un numero significativo di fattori potrebbe far sì che i risultati reali differiscano in modo materiale dalle dichiarazioni rilasciate in questo articolo, includendo, ma senza limitazioni, i rischi per la sicurezza e gli sviluppi sconosciuti a Zscaler al momento della stesura di questo articolo, nonché le ipotesi alla base delle nostre previsioni sul settore della sicurezza informatica per il 2024.
I rischi e le incertezze specifici del business di Zscaler sono esposti nella nostra più recente Relazione trimestrale nel modulo 10-Q, depositata presso la Securities and Exchange Commission ("SEC") il 7 dicembre 2022 e disponibile sul nostro sito web all'indirizzo ir.zscaler.com e sul sito web della SEC all'indirizzo www.sec.gov. Qualsiasi dichiarazione prospettica contenuta in questo comunicato si basa sulle informazioni limitate attualmente a disposizione di Zscaler in data odierna, le quali sono soggette a modifiche, e Zscaler non si impegna ad aggiornare alcuna dichiarazione prospettica rilasciata in questo articolo, anche nel caso in cui si rendano disponibili nuove informazioni in futuro, salvo nei casi previsti dalla legge.
Questo post è stato utile?
![dots pattern](/_next/image?url=%2Fassets%2Fimages%2Fcta_bgpattern.png&w=1920&q=75)
Ricevi gli ultimi aggiornamenti dal blog di Zscaler nella tua casella di posta
![](/_next/image?url=%2Fassets%2Fimages%2Floading.webp&w=256&q=75)
Inviando il modulo, si accetta la nostra Informativa sulla privacy.