Perché un tunnel dedicato?
Le 9 ragioni tecniche e di conformità per cui Rela AI non usa la VPN aziendale dei nostri clienti — e cosa guadagnano con un peer WireGuard dedicato.
Perché non usiamo la tua VPN aziendale?
Quando negoziamo l'accesso a un nuovo cliente, la proposta più comune del team IT è "ti diamo le credenziali della nostra VPN aziendale". Ha senso dalla loro prospettiva: esiste già, è già configurata, sanno come gestirla. Ma se accettassimo, creeremmo diversi problemi tecnici e di compliance seri. Per questo esigiamo un tunnel dedicato all'infrastruttura OT. Ecco le 9 ragioni ordinate per gravità.
A cosa serve un tunnel dedicato
Perché Rela AI possa raggiungere il PLC del cliente senza attraversare la rete aziendale (IT) né mescolarsi con il traffico dei dipendenti. Il traffico entra in un punto, tocca solo la subnet OT, ed esce — con tracciabilità completa e revocabile all'istante.
Come funziona
WireGuard stabilisce un tunnel punto-a-punto con cifratura Curve25519, autenticazione a chiave asimmetrica, e routing controllato da allowed-ips. Limitiamo allowed-ips alla subnet OT del cliente; tutto il resto resta fuori dalla portata del tunnel. La chiave privata vive sul router del cliente e non esce mai da lì.
Le 9 ragioni
1. Isola IT da OT (IEC 62443 / Purdue Model)
Lo standard di cybersecurity industriale IEC 62443 (e il suo antenato ISA-99 / Purdue Model) richiede che l'accesso OT non condivida il percorso dell'accesso IT. Usare la VPN aziendale fa crollare quella separazione nel momento in cui arriva un pacchetto: audit morto, findable per gli auditor.
2. Principio del minimo privilegio
Un utente VPN aziendale tipico raggiunge l'intera rete: SharePoint, Jira, mail, stampanti, ERP e rete OT. Noi dobbiamo solo leggere il PLC. Ridurre il privilegio significa che una credenziale rubata colpisce una subnet, non l'intera azienda.
3. Ridurre il blast radius in caso di violazione
Se Rela AI subisce una violazione con le credenziali della tua VPN aziendale, l'attaccante raggiunge tutta la tua azienda. Con WireGuard isolato e allowed-ips=10.200.X.0/24, lo stesso attaccante raggiunge solo la subnet OT che hai già esposto di proposito. L'asimmetria di rischio gioca a tuo favore.
4. Conformità CISA / NIST SP 800-82
Le guide ufficiali di sicurezza industriale CISA e NIST (Special Publication 800-82) raccomandano esplicitamente:
"Remote vendor access to OT environments SHALL use dedicated, purpose-specific connections separated from general-purpose corporate remote access."
Traduzione: se auditano il tuo impianto, usare la VPN aziendale per un fornitore esterno è un findable.
5. MFA macchina-a-macchina è un antipattern
La tua VPN aziendale quasi sicuramente richiede MFA (push Duo, TOTP, SAML). È progettata per umani che approvano. Noi siamo una macchina che fa poll ogni 5 secondi. Le opzioni sono tutte cattive:
- Memorizzare il TOTP secret → la credenziale MFA diventa statica (rompe lo scopo dell'MFA).
- Usare flag di bypass nell'IdP → lacuna di audit per il tuo SOC.
- Disabilitare l'MFA per quell'utente → il tuo CISO dice no.
WireGuard è autenticazione a chiave asimmetrica ruotabile, pensata per le macchine fin dal giorno 1.
6. Allineamento Zero Trust
Lo standard che sostituisce "VPN aziendale + rete di fiducia" è Zero Trust (NIST SP 800-207). Filosofia: "never trust the network, always verify". WireGuard con peer esplicito + allowed-ips limitati è esattamente microsegmentazione. La VPN aziendale è l'antipattern che Zero Trust sta ritirando.
7. Custodia delle chiavi asimmetrica
| La tua VPN aziendale | WireGuard dedicato | |
|---|---|---|
| Chi detiene la tua credenziale? | Noi (user/pass in un secret) | Il tuo router (chiave privata locale) |
| Come la revochi? | Chiami il tuo IT | Rimuovi il peer sul router |
| Tempo di revoca | Ore (se c'è un ticket) | Secondi |
| Scade? | Sì, per policy di password | Mai (ruoti quando vuoi) |
| Possiamo accedere se ci congedi? | Solo se avvisano IT in tempo | Impossibile — la chiave resta nel tuo hardware |
8. Tracciabilità e compliance
Quando il tuo auditor SOC 2, ISO 27001 o IEC 62443 chiede "chi può raggiungere i tuoi PLC?", con VPN aziendale la risposta è:
"Rela AI ha un utente VPN, ma anche 400 dipendenti, 12 consulenti e qui c'è il log di 6 mesi tutto mescolato."
Impossibile dimostrare controllo.
Con WireGuard dedicato:
"Il peer
rela-aicon public keyabc…e allowed-ips10.200.7.0/24. Ultimo handshake 3 secondi fa. Ecco il log degli handshake degli ultimi 90 giorni."
L'auditor firma e se ne va.
9. Data leakage da full-tunnel
Se la tua VPN aziendale forza full-tunnel (tutto il traffico della stazione remota passa per la tua rete), il nostro traffico verso MongoDB Atlas, Gemini API, SendGrid, ecc. passerebbe per il tuo firewall aziendale. Questo:
- Ti rende responsabile di dati che non sono tuoi (privacy / GDPR).
- Espone metadata di tutti i nostri tenant al tuo SOC.
- Rompe SLA contrattuali con i nostri altri clienti.
Con WireGuard dedicato + allowed-ips limitato, solo il traffico alla subnet OT attraversa la tua rete. Il resto esce direttamente da Cloud Run a Internet.
Benefici
- Compliance garantita: IEC 62443 § 6.4, SOC 2 CC6.6, ISO 27001 A.9.2.
- Zero Trust allineato: soddisfa NIST SP 800-207.
- Costo zero di licensing: WireGuard è open source.
- Revoca in pochi secondi: senza dipendere da ticket IT.
- Tracciabilità per-peer: l'auditor vede esattamente chi può raggiungere cosa.
E se il mio IT vuole comunque usare la VPN aziendale?
Per le ragioni sopra, non lo supportiamo. Se il tuo IT insiste su un modello "voi vi connettete come client alla mia VPN aziendale", quello è fuori dal self-service e ricade in deployment custom con prezzo enterprise — richiede un tunnel IPsec IKEv2 site-to-site dedicato (non user/pass aziendale), e comunque raccomandiamo il modello standard.
Il percorso corretto è documentato in Configurazione e Setup.