Zero Trust nella pratica: come si comportano i sistemi quando qualcosa va storto

La maggior parte delle discussioni sulla sicurezza si concentra su come tenere fuori gli attaccanti. Molto meno spesso ci si chiede che cosa accada dopo che qualcosa è andato storto. Zero Trust non riguarda la prevenzione di ogni possibile fallimento. Riguarda la progettazione di sistemi che rimangano stabili quando emerge l’incertezza.

Le conversazioni sulla sicurezza iniziano quasi sempre dal perimetro. L’attenzione è rivolta a impedire l’ingresso degli attaccanti, a rafforzare l’involucro esterno di un sistema e a ridurre la probabilità di una prima compromissione. Firewall, meccanismi di autenticazione, connessioni cifrate e controlli di accesso dominano il dibattito. Tutto questo è necessario, ma evita silenziosamente una domanda più scomoda: che cosa succede quando, nonostante tutto, qualcosa fallisce?

L’esperienza dimostra che il fallimento non è un’anomalia. Le credenziali trapelano, le configurazioni divergono, le dipendenze cambiano e i sistemi evolvono più velocemente delle ipotesi su cui erano stati progettati. In ambienti reali, la questione non è se qualcosa andrà storto, ma quando. Il fattore decisivo non è l’errore iniziale in sé, ma il modo in cui il sistema reagisce una volta che quell’errore si è verificato.

È qui che diventa visibile la differenza tra le architetture tradizionali e il pensiero Zero Trust. Non come slogan e non come singolo prodotto, ma come un modo fondamentalmente diverso in cui un sistema si comporta di fronte all’incertezza.

Due modi di pensare la fiducia

I sistemi tradizionali sono generalmente costruiti attorno a un’idea semplice: il pericolo è all’esterno, la sicurezza all’interno. Una volta che una richiesta ha superato un confine – dopo una connessione VPN, un’autenticazione riuscita o l’ingresso in una rete interna – viene trattata come ampiamente affidabile. Il sistema presume che ciò che avviene all’interno sia per lo più benigno e che controlli eccessivi rallenterebbero soltanto le operazioni.

Zero Trust parte da una premessa diversa. Assume che la posizione, da sola, non abbia alcun significato e che una richiesta accettata in precedenza non giustifichi automaticamente la successiva. La fiducia non è uno stato permanente. È una decisione presa ripetutamente, basata sul contesto, sull’intento e sul comportamento osservato.

Questa distinzione può sembrare astratta, ma diventa molto concreta nel momento in cui qualcosa va storto.

Un punto di partenza realistico: una credenziale compromessa

Consideriamo una situazione tecnicamente ordinaria. Un attaccante ottiene accesso a una singola credenziale. Può trattarsi di una chiave API incorporata in un’applicazione, di un token di service account in un cluster Kubernetes o di un account utente con privilegi limitati. Questo non richiede competenze eccezionali né vulnerabilità rare. Le credenziali trapelano attraverso log, backup, configurazioni errate ed errori operativi quotidiani.

A questo stadio, l’incidente è ancora limitato. Un punto di ingresso, un’identità, un primo appiglio. Ciò che accade dopo dipende interamente da come il sistema è progettato per reagire.

Cosa accade in un’architettura tradizionale

In una configurazione convenzionale, quella credenziale viene accettata in larga misura così com’è. Se è valida, il sistema consente le azioni ad essa associate. Tali autorizzazioni sono spesso più ampie di quanto strettamente necessario, concesse in passato per semplificare le operazioni e raramente riesaminate. Con il tempo, diventano parte della normalità implicita del sistema.

Una volta all’interno, il movimento è spesso semplice. I servizi interni comunicano tra loro perché condividono una rete o un cluster. I database accettano connessioni perché si fidano delle richieste provenienti dall’interno. I sistemi di monitoraggio registrano l’attività, ma il comportamento operativo del sistema continua come se nulla di insolito stesse accadendo.

Dal punto di vista dell’attaccante, questo è un ambiente che premia la pazienza. C’è tempo per esplorare, per testare quali connessioni funzionano e per osservare come interagiscono i componenti. Il progresso non richiede di superare nuove difese, ma solo di seguire i percorsi che il sistema già mette a disposizione. Tutto appare normale perché, tecnicamente, lo è.

La caratteristica distintiva è la continuità della fiducia. Una volta concessa, tende a persistere.

Zero Trust inizia dopo il primo errore

Zero Trust non promette di prevenire la perdita iniziale di una credenziale. Non afferma di eliminare l’errore umano o la deriva di configurazione. Il suo valore emerge solo dopo il primo fallimento.

In un sistema orientato a Zero Trust, una credenziale compromessa non sblocca automaticamente un accesso esteso. Ogni richiesta effettuata con quell’identità viene valutata nel suo contesto. Il sistema non chiede soltanto chi stia effettuando la richiesta, ma anche che cosa viene richiesto, verso dove è diretta e se quel comportamento corrisponde a quanto previsto.

Se non esiste un’autorizzazione esplicita per quella combinazione, la richiesta fallisce. Non perché sia stato rilevato un attacco, ma perché non è stata stabilita alcuna giustificazione. Il progresso diventa condizionale anziché automatico.

Questo spostamento sottile ha conseguenze profonde. Il percorso dell’attaccante si restringe rapidamente. Invece di un’esplorazione senza limiti, incontra confini definiti da scopo, tempo e ambito.

Quando l’osservazione cambia il comportamento

Una differenza chiave tra i due modelli risiede nel modo in cui i sistemi rispondono alle anomalie. Negli ambienti tradizionali, l’attività insolita viene spesso semplicemente registrata per una revisione successiva. Vengono generati log, possono scattare avvisi, ma il comportamento operativo del sistema rimane invariato.

Zero Trust tratta l’osservazione come un input, non solo come una prova. Quando i sistemi di monitoraggio – spesso collettori centralizzati di log ed eventi come le piattaforme SIEM – rilevano comportamenti che deviano dai modelli stabiliti, queste informazioni alimentano direttamente i meccanismi di applicazione delle regole.

IF service=backend AND
   request_rate > baseline*5 AND
   destination not in allowed_service_map
THEN
   action = "tighten_policy_for_source"

Non è necessaria una certezza perfetta. Il sistema non deve etichettare l’attività come malevola. Deve solo riconoscere l’incertezza. Quando l’incertezza aumenta, la fiducia diminuisce.

In pratica, questo si manifesta spesso a livello di rete. Il traffico proveniente da una fonte con comportamento inatteso può essere limitato a un insieme più ristretto di destinazioni. Connessioni tecnicamente possibili non sono più consentite se non esplicitamente richieste. Il sistema si adatta, irrigidendo la propria postura senza intervento umano.

A differenza delle configurazioni tradizionali, in cui le anomalie coesistono con accessi invariati, Zero Trust consente all’osservazione di rimodellare il comportamento del sistema in tempo reale.

Dove i container rendono visibile la differenza

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
    spec:
      automountServiceAccountToken: false
      containers:
        - name: app
          image: example/app:1.0.0
          securityContext:
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            allowPrivilegeEscalation: false

Gli ambienti Kubernetes offrono una visione particolarmente chiara di questa distinzione, perché la fiducia è codificata direttamente nella configurazione. Kubernetes non è di per sé una piattaforma Zero Trust, ma fornisce i meccanismi per applicare – o ignorare – i principi di Zero Trust.

Consideriamo cosa accade quando un attaccante ottiene accesso a un container in esecuzione.

In molte configurazioni predefinite, il filesystem di un container è scrivibile. I processi vengono eseguiti con privilegi elevati all’interno del container. L’accesso di rete tra i pod non è limitato. I service account concedono automaticamente l’accesso all’API di Kubernetes. Dal punto di vista della sicurezza, questo riflette la stessa assunzione dei sistemi tradizionali: una volta all’interno, l’ambiente è in gran parte affidabile.

Un approccio Zero Trust affronta la situazione in modo diverso.

Quando il filesystem root di un container è montato in sola lettura, il sistema non presume più che il processo debba poter modificare il proprio ambiente. Anche se un attaccante riesce a eseguire codice all’interno del container, non può installare strumenti aggiuntivi, alterare i binari dell’applicazione né stabilire persistenza. Tutto ciò che fa esiste solo in memoria e scompare al riavvio del pod.

Eseguire i container come utenti non root rafforza ulteriormente questo confine. Il processo viene trattato come un’applicazione, non come un sistema operativo. Molte tecniche di sfruttamento comuni falliscono semplicemente perché i privilegi necessari non sono presenti.

Le policy di rete aggiungono un ulteriore livello. Invece di presumere che ogni pod possa comunicare con ogni altro, la comunicazione è consentita esplicitamente solo dove è necessaria. Un pod compromesso non diventa un trampolino verso l’intero cluster. Diventa un endpoint isolato con portata limitata.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-ingress-from-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

La restrizione dei percorsi di rete è spesso sufficiente per fermare il movimento laterale tra servizi, ma non affronta un’altra via di escalation comune: l’accesso al piano di controllo stesso. Negli ambienti Kubernetes, questo significa in genere l’API di Kubernetes. Se un pod compromesso può autenticarsi presso il server API, l’isolamento di rete da solo non è più sufficiente. L’attaccante può iniziare a enumerare risorse, leggere configurazioni o tentare di creare nuovi workload.

Per questo motivo, il pensiero Zero Trust si estende oltre il traffico tra servizi e include l’identità dei workload e l’accesso al piano di controllo.

apiVersion: v1

kind: Pod
metadata:
  name: job-no-k8s-api
spec:
  automountServiceAccountToken: false
  containers:
    - name: job
      image: example/job:1.0.0
      securityContext:
        runAsNonRoot: true
        readOnlyRootFilesystem: true

Anche l’accesso all’API di Kubernetes viene trattato con cautela. I pod che non hanno bisogno di interagire con il piano di controllo non ricevono credenziali per farlo. Questo elimina completamente uno dei percorsi di escalation più comuni.

Nessuna di queste misure rende gli attacchi impossibili. Li rende limitati.

Cambiare la forma del rischio

L’effetto più importante di Zero Trust non è la prevenzione, ma la trasformazione. In un’architettura tradizionale, un singolo errore può aprire un percorso di abuso ampio e persistente. In un sistema orientato a Zero Trust, lo stesso errore porta a un’opportunità ristretta, temporanea e fragile.

Dal punto di vista dell’attaccante, l’ambiente diventa ostile al progresso lento e metodico. Gli accessi scadono. I percorsi vengono bloccati. Le azioni che deviano dal comportamento previsto riducono, anziché ampliare, le opzioni disponibili. Ciò che avrebbe potuto essere un’esplorazione silenziosa diventa una corsa contro il tempo e la visibilità.

Questa non è una garanzia di sicurezza. È un cambiamento di dinamica.

Una conclusione onesta

Zero Trust non elimina le violazioni. Non sostituisce una progettazione accurata né operazioni disciplinate. Non promette un rilevamento perfetto né un controllo assoluto. Ciò che offre è una risposta predefinita diversa al fallimento.

I sistemi tradizionali tendono a preservare la fiducia finché non viene loro esplicitamente indicato di fare diversamente. I sistemi Zero Trust fanno l’opposto. Quando la certezza si erode, la fiducia si contrae.

In pratica, questa differenza determina spesso se un incidente rimane una perturbazione contenuta o cresce fino a diventare un fallimento sistemico. Non perché Zero Trust sia magico, ma perché allinea il comportamento del sistema alla realtà che i sistemi complessi falliscono – e che la resilienza inizia dal modo in cui reagiscono quando accade.