OpenZiti

OpenZiti è una piattaforma di networking zero‑trust open‑source che rende i servizi di rete invisibili agli utenti non autorizzati. Ogni connessione, provenga da un utente, un servizio, un dispositivo o un carico di lavoro, viene autenticata con un'identità crittografica, autorizzata tramite policy e crittografata end‑to‑end.

OpenZiti funziona sia con applicazioni esistenti (usando tunnelers leggeri senza necessità di modifiche al codice) sia con nuove applicazioni (usando SDK embedded per il modello zero‑trust più forte). Ciò lo rende pratico sia per ambienti brownfield che per sviluppo greenfield.

Creato e sponsorizzato da NetFoundry. Concesso in licenza Apache 2.0.

Indice dei contenuti

• Casi d’uso
• Funzionalità principali
• Tre modelli di deployment
• Primi passi
• Architettura
• Zero Trust, Servizi Oscuri e Crittografia End‑to‑End
• SDK
• Community e Supporto
• Contribuire
• Adottanti
• Soluzione Gestita

Casi d’uso

OpenZiti ti permette di estendere lo zero‑trust ovunque per qualsiasi caso d’uso, inclusi carichi di lavoro e flussi di lavoro non umani, attraverso più reti e terze parti. Di seguito alcuni casi d’uso comuni.

Sostituire le VPN

Fornisci accesso sicuro ai servizi interni senza client VPN, problemi di split tunnelling o colli di bottiglia dei concentratori. Ogni servizio è autorizzato individualmente. Niente problema del tipo “una volta dentro, puoi raggiungere tutto”.

API e Servizi Oscuri

Rendi API e servizi invisibili a Internet. Zero porte in ascolto significa zero superficie d’attacco. I client autorizzati si connettono tramite OpenZiti; tutti gli altri non vedono nulla.

IoT e Identità Non Umana

Dai a ogni dispositivo, sensore e macchina un’identità crittografica unica. Il modello di identità di OpenZiti funziona per carichi di lavoro non umani esattamente come per utenti umani, fornendo autenticazione forte per le connessioni machine‑to‑machine che costituiscono la maggior parte del traffico di rete moderno.

Carichi di Lavoro Zero Trust

Rendi sicura la comunicazione tra carichi di lavoro attraverso cloud e ambienti diversi. I servizi si autenticano a vicenda con identità crittografica, non con posizione di rete. Niente segreti condivisi, niente allowlist IP, niente autorità ambientale.

AI Agentica

Rendi sicura la comunicazione agente‑servizio e agente‑agente con identità crittografica per ogni partecipante AI. I server MCP, gli endpoint strumentali e gli LLM privati rimangono oscuri, senza porte in ascolto né URL pubblici. Gli agenti si autenticano con identità forti e uniche e raggiungono solo le risorse consentite dalla policy, così i flussi di lavoro autonomi ottengono l’accesso necessario senza autorità ambientale su tutto il resto.

Connettività Multi‑Cloud e Ibrida

Un’unica rete overlay su AWS, Azure, GCP, datacenter on‑prem e perimetri. Niente strumenti di rete specifici del cloud, niente tunnel VPN tra ambienti, niente complessi accordi di peering.

Accesso a Servizi Self‑Hosted

Accedi da qualsiasi luogo a servizi self‑hosted o home lab come Nextcloud, Home Assistant, server multimediali e ambienti di sviluppo. Niente porte del router aperte, niente DNS dinamico, niente dipendenza da servizi di tunnel di terze parti. Controlli l’intero percorso.

Kubernetes e Servizi tra Cluster

Connetti servizi tra cluster Kubernetes senza complesse regole di ingresso, sidecar di service mesh o tunnel VPN tra cluster. Funziona anche al di fuori di Kubernetes, supportando la connessione di servizi k8s a VM, bare metal, dispositivi IoT o qualsiasi altra cosa sull’overlay.

Funzionalità principali

Tre modelli di deployment

OpenZiti supporta tre modelli zero‑trust. Possono essere combinati in una singola rete ed è possibile migrare tra di essi nel tempo.

Accesso di Rete

Distribuisci un edge router OpenZiti in una zona di rete fiduciaria. Il traffico entra nell’overlay da client autenticati ed esce nella rete privata dove risiedono i servizi.

• Modifiche al codice: Nessuna
• Agente sull’host del servizio: Nessuno
• Modello di sicurezza: Accesso basato sull’identità al confine di rete. Simile a un gateway, ma con identità crittografica e trasporto crittografato.

Accesso dall’Host

Esegui un tunneler OpenZiti sullo stesso host del tuo servizio. Il tunneler gestisce identità, autenticazione e crittografia. Il servizio deve solo accettare connessioni da localhost.

• Modifiche al codice: Nessuna
• Setup: Installa il tunneler, registra l’identità
• Modello di sicurezza: Confine di fiducia al livello del sistema operativo host. Il servizio è oscuro per la rete e raggiungibile solo tramite il tunneler.

Accesso dall’Applicazione (Il più forte)

Incorporare un SDK OpenZiti direttamente nelle applicazioni client e/o server. L’applicazione stessa possiede l’identità crittografica e crittografa il traffico in‑process. Non esistono porte in ascolto, nemmeno su localhost.

• Modifiche al codice: Sì
• Modello di sicurezza: Il più forte. Crittografia end‑to‑end in‑process. Completamente oscuro. Identità al livello applicativo, non di rete o host.

Da dove iniziare: Molti team iniziano con l’Accesso dall’Host (tunnelers) per i servizi esistenti. Si installa in pochi minuti senza modifiche al codice. Per nuovi sviluppi o carichi di lavoro ad alta sicurezza, l’Accesso dall’Applicazione (SDK) fornisce la postura zero‑trust più forte.

Primi passi

Le seguenti guide rapide mostrano come configurare una rete OpenZiti locale per sviluppo, test e apprendimento. Per deployment in produzione, consulta la documentazione del prodotto su https://netfoundry.io/docs/openziti/category/deployments/.

Guida rapida con Docker

Il modo più veloce per avere una rete OpenZiti locale funzionante:

wget https://get.openziti.io/dock/all-in-one/compose.yml
docker compose up

Questo avvia un controller, un edge router e la console Ziti in un unico stack compose. La console è disponibile su https://localhost:1280/zac/. Da qui puoi creare identità, definire servizi e configurare policy di accesso.

Vedi la guida rapida all‑in‑one Docker per tutti i dettagli, incluse opzioni di storage, variabili d’ambiente e uso da riga di comando.

Guida rapida con la CLI

Scarica l’ultimo binario ziti da GitHub Releases, quindi:

ziti edge quickstart

Questo avvia una rete di sviluppo locale: controller, router e un’identità amministratore predefinita. Ideale per test e apprendimento.

Per aggiungere la Ziti Admin Console (ZAC) a un controller in esecuzione:

ziti ops console download --location /opt/openziti/console
ziti ops console configure /path/to/controller.yml --all --location /opt/openziti/console
# riavvia il controller, poi apri https://<indirizzo-controller>/zac/

Oppure servi ZAC localmente senza toccare la configurazione del controller:

ziti run console --version latest
# apre https://127.0.0.1:8443. puntalo a qualsiasi controller dal browser

Approfondisci

Architettura

La rete overlay di OpenZiti funziona sopra l’infrastruttura esistente: qualsiasi rete IP, qualsiasi cloud, qualsiasi combinazione. I componenti principali:

Controller

Il controller è il piano di gestione. Si occupa di:

• Gestione delle identità: emette e verifica identità crittografiche (certificati x509) per ogni partecipante alla rete
• Applicazione delle policy: definisce quali identità possono accedere a quali servizi, attraverso quali edge router
• Stato della rete: tiene traccia di router, servizi e topologia; fornisce una API REST e una console di amministrazione web per la gestione

Edge Router

Gli edge router formano il piano dati, una maglia mesh che trasporta il traffico crittografato tra gli endpoint.

• Router pubblici sono raggiungibili da Internet, fungendo da punti di ingresso alla rete
• Router privati (“oscuri”) sono distribuiti all’interno di reti private con sole connessioni in uscita

I router si scoprono automaticamente, formano connessioni mesh e usano il routing intelligente per selezionare il percorso migliore in base a latenza, throughput e costi.

Endpoint: SDK e Tunnelers

Gli endpoint sono il modo in cui applicazioni e utenti si connettono alla rete OpenZiti:

• SDK (Go, C, Python, Node.js, Java, Swift, C#): incorporano lo zero‑trust direttamente nella tua applicazione. L’app stessa possiede l’identità e gestisce la crittografia. Niente sidecar, niente agente, niente porte in ascolto.

• Tunnelers (Linux, Windows, macOS, iOS, Android): app leggere che forniscono connettività OpenZiti a software non modificato. Il traffico viene intercettato e instradato attraverso l’overlay in modo trasparente. Nessuna modifica al codice richiesta.

Zero Trust, Servizi Oscuri e Crittografia End‑to‑End

Zero Trust e Segmentazione delle Applicazioni

Ogni partecipante (es. utente, servizio, dispositivo, carico di lavoro) in una rete OpenZiti porta con sé un’identità crittografica unica basata su certificati x509. Quando viene tentata una connessione, OpenZiti verifica:

1. L’identità è valida e registrata
2. Esiste una policy che concede a quell’identità l’accesso al servizio richiesto
3. La connessione avviene attraverso un edge router autorizzato

Se uno qualsiasi dei controlli fallisce, la connessione viene negata. Se l’accesso viene successivamente revocato, le connessioni attive vengono terminate immediatamente. Non esiste fiducia implicita basata sulla posizione di rete. Essere sulla stessa LAN non concede più accesso che essere su Internet, a meno che la policy non lo permetta esplicitamente.

Questo modello fornisce segmentazione zero‑trust delle applicazioni: ogni servizio è autorizzato indipendentemente. Ottenere accesso a un servizio non concede accesso a nessun altro.

Servizi Oscuri

Un servizio “oscuro” non ha porte aperte. Non ascolta su alcuna interfaccia di rete per connessioni in entrata. Invece, il servizio (o un tunneler al suo fianco) effettua una connessione in uscita verso un edge router OpenZiti e si registra. I client lo raggiungono solo attraverso il fabric OpenZiti, dopo autenticazione e autorizzazione.

Cosa significa in pratica:

• Gli scanner di porte non trovano nulla: non ci sono porte in ascolto da scoprire
• Nessuna superficie d’attacco: non puoi sfruttare ciò che non puoi raggiungere
• Resistenza a DDoS: non esiste un endpoint pubblico da inondare
• Invisibile agli utenti non autorizzati: solo le identità con policy corrispondente sanno persino dell’esistenza del servizio
• Compatibile con NAT e firewall: tutte le connessioni sono in uscita, quindi CG‑NAT, doppio NAT e firewall restrittivi non sono un problema

Anche gli edge router possono essere oscuri. I router privati effettuano solo connessioni in uscita, quindi non sono necessarie regole firewall in entrata nella tua rete privata.

Crittografia End‑to‑End

Con gli SDK OpenZiti, il traffico è crittografato dall’applicazione mittente a quella ricevente usando libsodium per il percorso dati e mTLS per l’autenticazione dell’identità. Anche se router o reti intermedie vengono compromessi, il traffico non può essere decifrato o manomesso.

Con i tunnelers, la crittografia copre il percorso dal tunneler al tunneler (o dal tunneler all’SDK), fornendo crittografia macchina‑macchina senza modifiche all’applicazione.

SDK

Incorpora il networking zero‑trust direttamente nelle tue applicazioni:

Tutti gli SDK sono elencati nell’organizzazione GitHub OpenZiti.

Sicurezza

OpenZiti è un progetto incentrato sulla sicurezza. La divulgazione responsabile delle vulnerabilità ci aiuta a proteggere la piattaforma e i suoi utenti.

Segnalare una vulnerabilità: Se scopri un problema di sicurezza, consulta la nostra Vulnerability Disclosure Policy per i dettagli completi. I problemi sensibili vanno segnalati a [email protected]. I problemi non sensibili possono essere segnalati come issue GitHub nel repository appropriato. Dovresti ricevere una risposta entro 7 giorni.

Come gestiamo le vulnerabilità: Il nostro Product Security Incident Response Process descrive come le vulnerabilità segnalate vengono triaged, documentate e risolte, inclusa la coordinazione delle release CVE con le correzioni.

Porto sicuro: OpenZiti e NetFoundry non intraprenderanno azioni legali contro chiunque ricerchi e segnali vulnerabilità in buona fede. Incoraggiamo la ricerca sulla sicurezza e attribuiamo i risultati segnalati ai loro autori negli advisory e nelle note di rilascio.

Community e Supporto

OpenZiti ha una comunità attiva e in crescita:

• Forum Discourse: Fai domande, condividi progetti, ottieni aiuto dalla comunità e dai manutentori
• YouTube: Tutorial, demo e approfondimenti
• Blog: Aggiornamenti del progetto e articoli tecnici
• Twitter/X: Notizie e annunci

Contribuire

Il progetto OpenZiti accoglie contributi di codice, documentazione, segnalazioni di bug e feedback.

Repository Principali

Compilare dai sorgenti

Vedi il tutorial di sviluppo locale per le istruzioni di compilazione.

Documentazione per sviluppatori

• Panoramica per sviluppatori
• Sviluppo locale
• Deployment locale
• PKI del controller
• Note di rilascio

Adottanti

OpenZiti è utilizzato in produzione da organizzazioni come DeltaSecure (SOC gestito), Resulticks (automazione marketing), Chirp Wireless (IoT/telecom), GIGO Dev (ambienti di sviluppo cloud), OSMIT (IT gestito/conformità GDPR) e progetti open‑source come zrok e BlueBubbles.

Vedi l’elenco completo: ADOPTERS.md. Usi OpenZiti? Ci piacerebbe aggiungerti — apri un issue o invia una PR.

Soluzione Gestita

Per il networking zero‑trust senza gestire la propria infrastruttura, NetFoundry fornisce una rete OpenZiti completamente gestita e distribuita globalmente come servizio, con SLA, supporto enterprise e un fabric globale di edge router.

OpenZiti è sviluppato e reso open‑source da NetFoundry, Inc.