Il processo di patching non è abbastanza rapido? L’approccio zero trust come ultima linea di difesa

La velocità con cui aggiungi nuove funzionalità e l'evoluzione delle applicazioni aumentano in modo diretto la complessità dell'architettura. Questo ritmo incessante non è dovuto solo al desiderio di aggiungere funzionalità, ma è sempre più dettato dalla costante scoperta di nuove vulnerabilità. L'applicazione di patch a una singola dipendenza critica può innescare una serie di aggiornamenti necessari e modifiche all'architettura impreviste, poiché ogni prodotto e soluzione offre una miriade di opzioni di distribuzione e varie funzionalità da abilitare o disabilitare. Adattare questa complessità al tuo ambiente specifico rende difficile garantire che ogni componente sia distribuito secondo le procedure consigliate per il settore. I modelli convalidati colmano questa lacuna fornendo modelli di distribuzione pronti all'uso e ampiamente testati per vari scenari di utilizzo, riducendo la necessità di creare da zero architetture complesse e incentrate sulla sicurezza.

La scomoda verità sulla gestione delle vulnerabilità

Nel 2025 sono stati pubblicati oltre 40.000 nuovi CVE. Sono più di 100 ogni singolo giorno. Oggi, la generazione di codice malevolo basato sull'IA sta accelerando drasticamente il tempo che intercorre tra la divulgazione delle vulnerabilità e lo sfruttamento attivo sul campo. L’articolo intitolato "Chasing the holy grail " mostra come mirare a un punteggio di zero CVE a volte possa essere controproducente, se distrae da strategie di difesa più approfondite. Un componente "pulito" alle 9:00 potrebbe presentare una vulnerabilità appena divulgata entro le 17:00. Anche in assenza di CVE note, esistono le vulnerabilità sconosciute.

Il calcolo delle patch (l'idea errata che la sicurezza sia solo una questione di numeri e che meno CVE significhi meno rischi) non è applicabile agli ambienti aziendali che eseguono centinaia di carichi di lavoro containerizzati. A differenza delle architetture monolitiche tradizionali eseguite su un unico sistema operativo, gli ambienti containerizzati distribuiti introducono una complessità architetturale nettamente superiore. Innumerevoli microservizi e punti di contatto di rete offrono molte più opzioni di configurazione in cui qualcosa può andare storto, creando inavvertitamente una falla nella sicurezza. Cercare di risolvere tutto all'istante è un'impresa titanica che contrasta con una moderna strategia di sicurezza basata sul rischio. Ignora inoltre una verità fondamentale: indipendentemente dall'impegno nell'applicare gli aggiornamenti, ci sarà sempre un ritardo.

Cosa fare, quindi, nell'intervallo tra la divulgazione di una vulnerabilità e la distribuzione delle patch? La risposta risiede in un principio di sicurezza valido da anni, ma oggi più che mai fondamentale: l’architettura zero trust.

Cosa significa zero trust per il tuo cluster Red Hat OpenShift

L’approccio zero trust non è un prodotto che si installa. È una filosofia architetturale che presuppone che si sia già verificata una violazione, imponendo la verifica e l’autorizzazione esplicita di ogni interazione. Secondo lo standard NIST SP 800-207, l’approccio zero trust consiste nel rimuovere l'attendibilità implicita concessa alle risorse (asset, applicazioni o account utente) basata esclusivamente sulla loro posizione fisica o di rete. L'autenticazione e l'autorizzazione sono funzioni distinte eseguite prima di stabilire qualsiasi sessione verso una risorsa aziendale.

L'implementazione dello zero trust in Kubernetes e Red Hat OpenShift richiede un approccio multilivello che includa l'identità dei carichi di lavoro, la gestione dei segreti e il controllo degli accessi al runtime. In particolare nel dominio del networking, una delle implicazioni più critiche di questa filosofia è il superamento della configurazione di rete flat predefinita, in cui ogni pod può comunicare liberamente. Per impostazione predefinita, Kubernetes non applica restrizioni alla rete interna; è come lasciare aperta ogni porta di un edificio solo perché l'ingresso principale è protetto (ad esempio da un controller di ingresso del cluster, un gateway API o un firewall perimetrale). Tuttavia, affidarsi esclusivamente a questa difesa perimetrale è insufficiente per i moderni ambienti cloud native.

Secondo il modello zero trust, presupponiamo che si sia già verificata una violazione e che i malintenzionati siano già all'interno del tuo ambiente, che si tratti di utenti esterni che hanno aggirato il perimetro, di un componente della catena di distribuzione compromesso o di minacce interne che operano direttamente dall'interno. Implementando le restrizioni per le risorse di rete Kubernetes, creiamo una connessione di rete di default con autenticazione e autorizzazione esplicite per utilizzare la rete e raggiungere altre risorse collegate (Figura 1).

Dalla teoria alla pratica: il modello convalidato zero trust a più livelli (ZTVP)

Per mettere in pratica queste procedure consigliate, utilizziamo il Layered Zero Trust Validated Pattern (ZTVP). Un modello convalidato incorpora le best practice Infrastructure as Code (IaC) e l'automazione GitOps, riducendo drasticamente i tempi di configurazione per le distribuzioni OpenShift complesse progettate per la sicurezza e la scalabilità. Negli ultimi tre mesi, il progetto ZTVP ha fatto passi da gigante, ottenendo l'accreditamento Tested Tier.

Il modello riunisce più componenti in un'architettura zero trust coesa, distribuita con GitOps.

• Zero trust workload identity manager: fornisce ai carichi di lavoro identità crittografiche di breve durata basate sul progetto SPIFFE/SPIRE.
• HashiCorp Vault: archivia gli asset sensibili e i segreti del cluster in modo sicuro, integrandoli con ZTWIM per l'autenticazione JWT.
• Red Hat build of Keycloak: gestisce l'autenticazione degli utenti e l'identità federata.
• Red Hat Advanced Cluster Security for Kubernetes: funge da motore di sicurezza intelligente, fornendo monitoraggio unificato multi-cluster, controllo proattivo degli accessi, rilevamento di anomalie comportamentali in tempo reale e, nel nostro esempio, un analizzatore di policy di rete.

Policy di rete: l'ultima linea di difesa

Sebbene le policy di rete siano spesso considerate la base dell’approccio zero trust, non sono un principio in sé. Si tratta invece di un meccanismo architetturale proattivo utilizzato per applicare i risultati desiderati di un modello zero trust. Red Hat delinea quattro principi fondamentali dello zero trust e le policy di rete ben progettate supportano attivamente ognuno di essi.

• Microsegmentazione: regolando il traffico a livello dei singoli pod, le policy di rete suddividono intrinsecamente il cluster in segmenti granulari e sicuri.
• Accesso con privilegi minimi: un approccio di negazione predefinita garantisce che ai carichi di lavoro vengano concesse solo le autorizzazioni di rete strettamente necessarie al funzionamento.
• Deperimetralizzazione: i controlli di sicurezza vengono spostati dall'ingresso del cluster e applicati direttamente ai carichi di lavoro stessi.
• Ipotesi di violazione: eliminando preventivamente i percorsi di attacco laterali, sono già in atto regole rigide di ingresso e uscita per contenere il raggio d'azione nel momento in cui si verifica una compromissione.

Inoltre, un aspetto fondamentale delle policy di rete di Kubernetes è che risiedono su un piano di controllo separato rispetto ai pod applicativi che proteggono. Ciò significa che, anche se un utente malintenzionato riesce a violare un container e ottiene privilegi elevati nell'applicazione, non può ridefinire o aggirare i confini di rete che lo limitano. Per migliorare il profilo di sicurezza complessivo dell'ambiente interno e mettere in pratica questi principi, occorre definire policy di rete granulari che controllino il traffico sia in ingresso che in uscita a livello di pod.

• Policy di ingresso: controllano il traffico in entrata verso un pod, imponendo che un servizio accetti connessioni solo da sorgenti esplicitamente autorizzate. Se un pod vicino nel cluster è compromesso, una robusta policy di ingresso impedisce all'utente malintenzionato di accedere lateralmente ai tuoi carichi di lavoro sensibili.
• Policy in uscita: controllano il traffico in uscita da un pod. Il loro obiettivo è limitare rigorosamente le risorse esterne o interne che un pod può raggiungere. Se un pod viene compromesso, le policy in uscita neutralizzano la capacità di un utente malintenzionato di esfiltrare dati, eseguire ricognizioni di rete o scaricare payload dannosi da server di comando e controllo esterni.

La base della negazione predefinita

Sebbene definire regole specifiche di ingresso e uscita sia fondamentale, affidarsi solo ad esse lascia un vuoto pericoloso, esponendo a errori umani e attacchi ingannevoli. Per impostazione predefinita, Kubernetes opera su un modello che consente tutto, il che significa che ogni traffico non esplicitamente limitato è permesso. Se chi sviluppa dimentica di applicare una policy, quel pod resta completamente esposto. Ma il rischio va oltre i semplici errori. In un attacco alla supply chain, chi sviluppa potrebbe essere indotto a distribuire un componente di terze parti compromesso, senza accorgersi del payload dannoso nascosto o delle sue conseguenze.

Una policy di negazione predefinita inverte questo paradigma, passando da una blocklist a una allowlist. Il principio cardine dello zero trust impone che ogni singola interazione debba essere esplicitamente autorizzata, quindi ne consegue che nessun accesso può essere implicito. Bloccando rigorosamente tutto il traffico fin dall'inizio, un approccio di negazione predefinita crea un ambiente in cui un'omissione accidentale (o un container non autorizzato che tenta di comunicare con l'esterno) comporta il blocco sicuro della connessione. Ti costringe a concedere esplicitamente l'accesso fin dalla progettazione, trasformando una potenziale violazione catastrofica in un errore di distribuzione evidente e facilmente risolvibile.

L'approccio parte da una regola semplice ma efficace: nega tutto il traffico per impostazione predefinita. Ogni namespace riceve una NetworkPolicy di negazione predefinita che blocca tutto il traffico in ingresso e in uscita per ogni pod, a meno che non esista una policy di autorizzazione esplicita.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-in-namespace
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Se una NetworkPolicy ha come target un pod in un namespace, questo non ha più un accesso illimitato. Definendo una policy che blocca l'accesso per impostazione predefinita, ci si allinea a un approccio zero trust di negazione predefinita.

Perché questo è importante quando non puoi applicare le patch

Considera uno scenario aziendale che ricorda la famigerata crisi di Log4j o shock più recenti come la vulnerabilità React2Shell (CVE-2025-55182).

1. Una vulnerabilità critica di tipo RCE (Remote Code Execution) viene improvvisamente divulgata in una libreria onnipresente utilizzata dalla tua applicazione.
2. La vulnerabilità consente il controllo completo del server, se un utente malintenzionato invia una richiesta appositamente predisposta al servizio interessato.
3. Poiché la libreria è strettamente integrata nelle tue dipendenze, una patch convalidata non potrà essere testata e distribuita in produzione per diversi giorni.

L'impatto su un'organizzazione con policy di rete zero trust è minimo:

• un utente malintenzionato che compromette un pod può raggiungere facilmente il servizio vulnerabile in qualsiasi namespace (assenza di isolamento laterale).
  • Con le policy di rete ZTVP: l'utente malintenzionato non può raggiungere il servizio da un altro namespace (isolamento del namespace).
• Un utente malintenzionato può connettersi a qualsiasi porta esposta del servizio, comprese quelle critiche o di gestione (assenza di filtri a livello di porta).
  • Con le policy di rete ZTVP: l'utente malintenzionato non può connettersi alle porte non esplicitamente autorizzate (filtro a livello di porta).
• Un utente malintenzionato può stabilire liberamente connessioni in uscita per esfiltrare dati o creare canali di comando e controllo (C2) (assenza di restrizioni in uscita).
  • Con le policy di rete ZTVP: l'utente malintenzionato non può esfiltrare dati verso endpoint esterni (restrizioni in uscita).

Dimostrazione: eliminazione del percorso di attacco

Abbiamo creato un video dimostrativo in cui osserviamo come le policy di rete implementate correttamente eliminino i percorsi di attacco. Inizialmente, vediamo un ambiente senza un approccio di negazione predefinita, in cui un utente malintenzionato che sfrutta una vulnerabilità della supply chain può eseguire facilmente ricognizioni approfondite, cercando nella rete altri componenti senza patch da colpire. Poi vediamo che, una volta applicate policy di rete rigorose, la situazione cambia completamente.

Anche se un utente malintenzionato riesce a violare un pod, la sua capacità di analizzare la rete, cercare vulnerabilità o spostarsi lateralmente viene del tutto neutralizzata. Le policy lo limitano al container compromesso, contenendo la minaccia e facendoti guadagnare il tempo necessario per implementare le azioni correttive. Sebbene non siano l'unica misura di sicurezza in una strategia completa, stabilire confini di rete rigorosi è probabilmente il miglior punto di partenza per creare l'ultima linea di difesa.

Questa dimostrazione mostra come le policy di rete limitino un attacco al container compromesso, contenendo la minaccia e facendoti guadagnare il tempo necessario per implementare le azioni correttive.

Il quadro generale: difesa su più livelli

Le policy di rete sono solo uno dei livelli di una strategia completa. Il Layered Zero Trust Validated Pattern combina queste policy con le identità dei carichi di lavoro SPIFFE/SPIRE (utilizzando lo zero trust workload identity manager), i segreti gestiti da Vault, l'autenticazione centralizzata tramite un provider di identità (IdP) come la nostra build Red Hat predefinita di Keycloak e il monitoraggio del runtime di Red Hat Advanced Cluster Security for Kubernetes. Le policy di rete completano il quadro garantendo che, anche in caso di compromissione dell'identità, dei segreti o della sicurezza delle applicazioni, il livello di rete fornisca il contenimento necessario.

Ma come puoi sapere se le tue policy di rete funzionano davvero o se un container compromesso sta tentando ripetutamente di forzare i confini interni? Cosa succede quando del codice malevolo per cui non è stata ancora creata una correzione attiva una connessione negata?

In questa serie di blog cercheremo di rispondere a queste domande analizzando come il Layered Zero Trust Validated Pattern implementi le pratiche di sicurezza zero trust. Ecco cosa aspettarsi nei prossimi articoli.

• Difesa attiva con Red Hat Advanced Cluster Security for Kubernetes: implementazione del monitoraggio approfondito del runtime, scansione automatizzata delle policy di rete e avvisi in tempo reale come motore di sicurezza centrale.
• Identità e segreti: gestione più sicura delle identità dei carichi di lavoro con lo zero trust workload identity manager e l'integrazione con Vault.
• Catena di distribuzione: protezione end-to-end della supply chain del software, attraverso l’applicazione di firme ai contenuti e la verifica delle attività della pipeline, per garantire che solo il codice attendibile raggiunga il cluster.

Vuoi vederlo in azione? Non devi attendere il prossimo articolo per iniziare. Esplora il Layered Zero Trust Validated Pattern per scoprire l'architettura e prova personalmente la demo delle policy di rete.

Riferimenti

• NIST SP 800-207: Zero Trust Architecture
• NIST SP 800-207A: Zero Trust for Cloud-Native Applications
• CISA: Zero Trust Microsegmentation Guidance
• Layered Zero Trust Validated Pattern
• Validated Patterns
• Chasing the Holy Grail: Why Red Hat's Hummingbird Project aims for near-zero CVEs
• CVE Metrics