Rete isolata, accesso remoto, cloud: tre architetture a confronto

Un accesso remoto cifrato non è una rete isolata, e nessuna delle due è «andare sul cloud». Sono tre architetture con promesse diverse: la rete isolata non comunica con l'esterno, l'accesso remoto privato apre un canale controllato verso l'esterno, il cloud affida l'elaborazione a un servizio esterno. La differenza non sta nella qualità della cifratura, ma in quante porte esistono, chi può aprirle e da cosa dipende il funzionamento quotidiano.

I tre modelli e le loro promesse

Le tre architetture vengono spesso presentate con lo stesso linguaggio («i dati restano al sicuro»), ma rispondono a esigenze diverse. Conviene dar loro un nome preciso prima di confrontarle.

Rete interna isolata. Server, applicazioni e dati vivono dentro l'azienda, senza collegamenti verso l'esterno. La promessa è il massimo controllo del perimetro: ciò che non ha una via d'uscita non può uscire. Il prezzo è l'autonomia integrale: aggiornamenti, assistenza e fonti esterne vanno portati dentro con procedure deliberate.

Accesso remoto privato. L'elaborazione resta in sede, ma esiste un canale dedicato — per esempio una rete privata virtuale (VPN), cioè un tunnel cifrato tra due punti — che permette a una persona autorizzata di raggiungere il sistema da fuori. La promessa è la raggiungibilità senza spostare i dati: il canale è una porta in più nel perimetro, sorvegliata ma pur sempre una porta.

Dipendenza dal cloud. Parte dell'elaborazione avviene su servizi esterni, per esempio le interfacce di programmazione (API) di intelligenza artificiale di Azure o AWS. La promessa è potenza senza hardware in sede; il rovescio è una dipendenza operativa dalla connettività e dalla configurazione del fornitore, come descritto nell'articolo sul confronto tra AI locale nel CED e API cloud.

Perché «cifrato» non significa «isolato»

La cifratura protegge il contenuto di una comunicazione da chi la intercetta. Non risponde però ad altre tre domande: chi è autorizzato a usare il canale, cosa può fare una volta dentro, e cosa succede se le sue credenziali finiscono nelle mani sbagliate. Un tunnel VPN ben cifrato con una password rubata resta una porta aperta: l'attaccante non deve violare la cifratura, gli basta presentarsi con le chiavi giuste.

Aprire un canale verso l'esterno significa quindi accettare rischi residui concreti, da dichiarare e gestire:

• Identità del canale. Chi possiede il dispositivo o le credenziali di accesso? Un telefono smarrito o un account condiviso trasformano la porta controllata in una porta incustodita. Servono revoca rapida, autenticazione robusta e un elenco aggiornato degli autorizzati.
• Dipendenza dalla disponibilità. Se il canale viaggia su una rete mobile, la sua copertura e la sua continuità non dipendono da te. Occorre decidere in anticipo cosa deve funzionare anche quando il canale è assente.
• Ambito del canale. Cosa può attraversarlo: solo notifiche e approvazioni, oppure anche comandi operativi? Più il canale può fare, più vale la pena proteggerlo e documentarlo.
• Chiusura. Chi può chiudere il canale, con quale procedura e in quanto tempo? Un accesso che non si sa spegnere è un rischio permanente.

Anche il modello cloud ha i suoi rischi residui, di natura diversa. Dire «la risorsa è in Europa» non chiude la questione: nella documentazione di Microsoft su dati, privacy e sicurezza dei modelli Azure il luogo di elaborazione dipende dal tipo di distribuzione scelto (regionale, per zona dati o globale), e in quella di AWS sull'inferenza tra regioni di Amazon Bedrock dipende dal profilo di inferenza impostato, geografico o globale. La residenza europea è una configurazione da scegliere e verificare, non una proprietà automatica della nuvola.

Esempio illustrativo: il laboratorio e il responsabile fuori sede

Esempio illustrativo. Lo scenario seguente mostra un percorso di ragionamento; non racconta un caso avvenuto presso un cliente.

Un'azienda con un laboratorio analisi e un ufficio amministrativo valuta come far approvare gli interventi al responsabile IT anche quando non è in sede. La rete del laboratorio è separata da quella degli uffici; i dati dei referti non devono uscire dall'azienda. Sul tavolo ci sono le tre opzioni: nessun accesso esterno (isolamento pieno), un canale remoto privato per le sole notifiche e approvazioni, oppure spostare parte dell'analisi su API cloud in Europa.

La scelta ricade sul secondo modello: l'elaborazione resta sul server nel centro elaborazione dati (CED) aziendale e il canale remoto trasporta soltanto segnalazioni e decisioni. Restano però tre conseguenze da accettare in modo esplicito. Primo: se la rete mobile del canale ha un guasto nel weekend, il monitoraggio in sede continua, ma le notifiche arrivano in ritardo — e va deciso prima chi in sede è delegato a intervenire. Secondo: il telefono del responsabile diventa parte del perimetro di sicurezza, con blocco, revoca e sostituzione documentati. Terzo: il canale va elencato tra gli asset da proteggere, esattamente come un server.

In questa configurazione Cerberus sorveglia le regole del firewall e la separazione tra la rete del laboratorio e quella degli uffici: se una modifica apre un varco non previsto, la segnalazione arriva ai responsabili con regola, orario ed effetto sull'accesso. Hermes porta la segnalazione sull'app attraverso il collegamento VPN su connessione 5G cifrata proprietaria e raccoglie la decisione: ripristinare la separazione, mantenerla registrando il motivo, oppure approfondire il caso. L'approvazione arriva dal responsabile; l'assenza di risposta non autorizza alcun intervento attivo.

Come scegliere il modello giusto per ogni sede

Non esiste l'architettura migliore in assoluto: esiste quella coerente con ciò che la sede fa e con ciò che non può permettersi. Una checklist utile, sede per sede e processo per processo:

• Cosa non deve mai uscire? Se la risposta è «questi dati, in nessun caso», il perimetro di quei dati non deve avere vie d'uscita, né cloud né canali remoti che li trasportino.
• Chi deve raggiungere cosa, e da dove? Se un responsabile deve decidere da fuori sede, serve un canale remoto: meglio uno dichiarato e sorvegliato che una scorciatoia improvvisata. Definisci cosa il canale può trasportare — idealmente decisioni e notifiche, non i dati stessi.
• Cosa deve funzionare quando la connettività manca? Produzione, sicurezza fisica e processi critici devono avere un comportamento previsto in assenza di rete esterna. L'articolo sull'AI che funziona senza Internet in sede approfondisce cosa resta attivo e cosa degrada.
• Quali dipendenze esterne accetti? Ogni servizio esterno porta disponibilità, configurazione e condizioni del fornitore dentro la tua continuità operativa. Elencale per iscritto e assegna un proprietario a ciascuna.
• Quali evidenze conserverai? Per ogni canale aperto: chi è autorizzato, quando è stato usato, quali decisioni sono passate. Se fra sei mesi non puoi ricostruire chi ha attraversato il perimetro, il modello non è sotto controllo.

Spesso la risposta non è un solo modello, ma una combinazione: rete di produzione isolata, canale remoto privato per le approvazioni, cloud soltanto per i carichi che possono tollerarlo. L'importante è che i confini tra i tre modelli siano disegnati, non subiti.

Come OverZeus tiene distinti i tre modelli

Nel progetto OverZeus le tre architetture corrispondono a elementi separati, descritti nella pagina sull'installazione locale e l'uso di API:

• Operatività nel CED. Agenti e intelligenza artificiale lavorano sui server dell'azienda e possono operare senza collegamento a Internet: è il modello dell'elaborazione interna. Va precisato che in isolamento degradano aggiornamenti, fonti esterne di intelligence e assistenza remota, e che l'autonomia effettiva va dimostrata in prova (Shadow Mode), non assunta.
• Canale Hermes. L'app dei responsabili si collega direttamente al server locale tramite VPN, su connessione 5G cifrata proprietaria: è un accesso remoto privato, che richiede connettività e va distinto dall'operatività senza Internet. Hermes porta evidenze e spiegazione dell'intervento e raccoglie approvazioni o rifiuti; il canale è approfondito nell'articolo sul canale remoto tra CED e smartphone.
• API su Azure o AWS in Europa. In alternativa o in aggiunta, parte dell'analisi può usare servizi cloud in una regione europea concordata: è il modello con dipendenza esterna, da configurare e verificare come descritto sopra.

Attorno ai tre modelli lavorano quattro agenti. Cerberus sorveglia firewall e segmentazione e propone le correzioni consentite dalle policy: è lui a rendere visibile ogni nuovo varco nel perimetro. Hermes spiega gli interventi e raccoglie le decisioni dei responsabili attraverso il canale remoto. Ai confini operativi provvede Themis, che applica privilegi, approvazioni e limiti tramite controlli esterni al modello AI; delle tracce si occupa Mnemosyne, che conserva fonti, autorizzazioni ed esiti. Il passaggio a un intervento attivo richiede sempre l'approvazione prevista dal piano: il silenzio non autorizza.

Integrazioni, regione di elaborazione e dati condivisi vengono definiti insieme, in base alla modalità scelta. Prima di decidere, chiedi di vedere per iscritto — per qualsiasi fornitore, OverZeus compreso — l'elenco dei canali aperti, delle comunicazioni esterne in funzione normale e delle credenziali coinvolte.

Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.

Tutti gli articoli OverZeus