Zero Trust Architecture - Never Trust Always Verify

Cos'e' Zero Trust

#

Zero Trust e' un modello di sicurezza basato sul principio "non fidarti mai, verifica sempre". A differenza del vecchio modello perimetrale dove tutto cio' che era dentro la rete era considerato fidato, Zero Trust tratta ogni utente, dispositivo e richiesta come potenzialmente ostile, indipendentemente da dove proviene.

Ogni richiesta di accesso viene autenticata, autorizzata e monitorata continuamente, indipendentemente dalla posizione nella rete.

TL;DR

#

1. Nel modello Edge (castle-and-moat) il perimetro e' la difesa: chi e' dentro e' trusted, chi e' fuori e' bloccato. Un attaccante che supera il perimetro si muove liberamente su tutta la rete interna.
2. Zero Trust inverte questa logica: nessuna zona e' implicitamente fidata. Ogni utente, dispositivo e richiesta viene verificata ogni volta, anche se si trova gia' dentro la rete aziendale.
3. Il risultato e' una superficie d'attacco drasticamente ridotta: anche se un attaccante entra, non puo' muoversi lateralmente perche' ogni hop richiede una nuova autorizzazione.

I 4 Principi Zero Trust per SY0-701

#

I principi Zero Trust descrivono come viene implementata la verifica continua in pratica. Ogni principio ha una keyword d'esame distinta.

Control Plane e Data Plane

#

Il modello Zero Trust separa fisicamente chi decide l'accesso (Control Plane) da chi lo esegue (Data Plane). Questa separazione e' il cuore dell'architettura e la trappola piu' frequente all'esame.

flowchart TD
    classDef ctrl fill:#1d3557,stroke:#457b9d,stroke-width:2px,color:#fff
    classDef data fill:#2a9d8f33,stroke:#2a9d8f,stroke-width:2px,color:#e9f5f4
    classDef user fill:#2b2d42,stroke:#8d99ae,stroke-width:2px,color:#fff
    classDef spacer fill:none,stroke:none,color:none

    USER["👤 Utente / Dispositivo"]:::user
    PEP["🛡️ PEP - Policy Enforcement Point"]:::data
    PA["📋 PA - Policy Administrator"]:::ctrl
    PE["🧠 PE - Policy Engine"]:::ctrl
    RES["✅ Risorsa Protetta"]:::user
    DENY["🚫 Accesso Negato"]:::user

    SP1[" "]:::spacer
    SP2[" "]:::spacer

    subgraph DATA_PLANE ["Data Plane (muscoli)"]
        SP1
        PEP
    end

    subgraph CTRL_PLANE ["Control Plane (cervello)"]
        SP2
        PE
        PA
    end

    SP1 ~~~ PEP
    SP2 ~~~ PE

    USER -->|1 - Richiesta di accesso| PEP
    PEP -->|2 - Chiede autorizzazione| PA
    PA -->|3 - Consulta il motore| PE
    PE -->|4 - Decisione: allow/deny| PA
    PA -->|5 - Istruisce il PEP| PEP
    PEP -->|6a - Accesso concesso| RES
    PEP -->|6b - Accesso negato| DENY

Microsegmentazione

#

La microsegmentazione e' la tecnica operativa che implementa il principio di Threat Scope Reduction. Divide la rete in zone minime, isolando ogni workload o applicazione.

Il principio e' semplice: invece di un unico perimetro esterno che protegge tutto, ogni risorsa ha il proprio perimetro. Un attaccante che compromette un segmento non puo' raggiungere gli altri senza una nuova autorizzazione esplicita.

flowchart LR
    classDef zone fill:#1d3557,stroke:#457b9d,stroke-width:2px,color:#fff
    classDef attk fill:#9b2226,stroke:#ae2012,stroke-width:2px,color:#fff
    classDef block fill:#2a9d8f33,stroke:#2a9d8f,stroke-width:2px,color:#e9f5f4
    classDef spacer fill:none,stroke:none,color:none

    ATK["⚠️ Attaccante (entra nel Segmento 1)"]:::attk
    SEG1["Segmento 1 - Web Server"]:::zone
    SEG2["Segmento 2 - App Server"]:::zone
    SEG3["Segmento 3 - Database"]:::zone
    WALL["🛡️ Verifica esplicita richiesta ad ogni hop"]:::block

    ATK -->|Compromette| SEG1
    SEG1 -->|Lateral movement bloccato| WALL
    WALL -.->|Non autorizzato| SEG2
    WALL -.->|Non autorizzato| SEG3

Dev parallel (Kubernetes): Zero Trust in Kubernetes si traduce in Network Policies che bloccano tutto il traffico est-ovest tra pod per default, con policy esplicite solo per i flussi autorizzati. Il default "tutto aperto" di una rete flat e' il modello Edge. Istio (service mesh) implementa il Control Plane (policy) e il Data Plane (envoy proxy) separati, con mTLS tra ogni coppia di pod. Nessun pod si fida implicitamente degli altri anche se condividono lo stesso cluster.

Continuous Verification

#

La continuous verification e' il principio operativo che rende Zero Trust diverso da un semplice modello con autenticazione forte. Non basta autenticarsi una volta: la fiducia viene rivalutata su ogni richiesta.

Tre livelli di verifica continua:

1. Identita': chi e' l'utente? Credenziali + MFA. La password corretta non basta se il comportamento e' anomalo (Adaptive Identity).
2. Device posture: il dispositivo e' conforme alle policy? OS aggiornato, antivirus attivo, disco cifrato?
3. Contesto: da dove si connette? A che ora? Da quale rete? Accede a una risorsa coerente con il suo ruolo?

Solo se tutti e tre i controlli passano, il PE concede l'accesso. E questo avviene per ogni singola richiesta, non una volta al login.

Dev parallel (PHP/Node): In un'app PHP/Node, Zero Trust si manifesta in ogni API che non si fida del caller per default: JWT validation su ogni request (non solo al login), RBAC granulare per ogni endpoint, audit log di ogni chiamata. Il session cookie "fidato" del vecchio web e' il paradigma Edge: ti autentichi una volta e poi sei trusted fino al logout. Zero Trust richiede di rivalutare ogni richiesta anche se la sessione e' valida.

Collegato a

#

• ids-ips - IDS/IPS monitora le anomalie nel traffico, complementare alla continuous verification di Zero Trust
• proxy - Forward e reverse proxy sono i punti fisici dove i PEP vengono implementati
• privileged-access-management - PAM applica Zero Trust agli accessi privilegiati (admin, root, service account)