Architettura sicura per l'accesso remoto: WireGuard, VPN-HA, progettazione Bastion SSH e registrazione degli accessi nella pratica

L’accesso remoto in molti ambienti non è un „nice-to-have“, ma una realtà operativa: reperibilità, fornitori esterni, sedi distribuite, esercizio misto cloud e on‑prem. Allo stesso tempo l’accesso remoto è uno dei vettori di ingresso più comuni, perché oltrepassa confini che internamente vengono gestiti tramite segmentazione, zone di firewall e controlli d’identità. Una architettura di Remote-Access sicura è quindi meno uno strumento singolo e più un’interazione solida tra percorso di rete, identità, controllo e tracciabilità.

Questo contributo descrive un’architettura di riferimento praticabile composta da WireGuard (VPN leggera con primitive crittografiche moderne), VPN-HA (High Availability, ossia funzionamento ridondante con failover), SSH-Bastion-Design (Jump Host come punto di accesso controllato) e Access-Logging (registrazione di audit e sicurezza). Il focus è sul funzionamento operativo, i rischi comuni, i passaggi di verifica, la strategia di fallback e sul „perché“ delle misure – affinché l’architettura nella pratica non solo funzioni, ma sia anche auditabile e adatta alla gestione degli incidenti.

architettura sicura di Remote-Access: quadro delle minacce e assunzioni errate tipiche

Remote Access raramente fallisce per la crittografia, ma per le condizioni al contorno: reti troppo ampie, chiavi eccessivamente longeve, troppi obiettivi diretti e assenza di protocolli. Cause tipiche di incidenti di sicurezza e rilievi di audit:

• Reti VPN piatte: non appena un client è „in LAN“ raggiunge troppo. Il movimento laterale diventa semplice.
• Accessi admin diretti a server (SSH/RDP) senza punto di controllo centrale: difficili da indurire, difficili da registrare, difficili da bloccare.
• Identità non chiare: mancano associazioni dispositivo/utente, le chiavi vengono condivise, esistono account amministrativi locali in parallelo.
• HA senza considerazioni di sicurezza: il failover tramite Floating IPs o Anycast viene implementato, ma logging, stato e gestione delle chiavi si interrompono durante il cambio.
• Logging solo „per dopo“: senza correlazione (tempo, sorgente, destinazione, utente) i log in caso di incidente sono praticamente inutili.

Un principio importante: „VPN = interno“ è un Anti-Pattern. Una VPN è solo un canale di trasporto sicuro. La politica di accesso effettiva deve comunque basarsi su segmentazione, regole di firewall e controlli d’identità.

Obiettivo: componenti di un’architettura sicura di Remote-Access

Un obiettivo robusto prevede quattro livelli chiaramente separati:

• Transport: tunnel WireGuard tra client e gateway (crittografia, autenticazione dei peer).
• Controllo degli accessi: firewall/policy sul gateway e nelle reti di destinazione (Least Privilege, cioè i privilegi strettamente necessari).
• Punto di ingresso per amministratori: SSH-Bastion/Jump Host come percorso controllato verso le destinazioni amministrative.
• Tracciabilità: Access-Logging centralizzato, resistente alle manomissioni, correlabile; opzionale registrazione delle sessioni.

In aggiunta servono MFA (Multi‑Faktor‑Authentifizierung) per l’accesso iniziale, un chiaro Key-/Device-Lifecycle (Onboarding/Offboarding) e un piano di failover e rollback testato.

WireGuard nella pratica: segmentare con cura invece di „instradare tutto“

WireGuard è un protocollo VPN e una sua implementazione basata su un set ristretto di crittografia moderna e che opera come modulo kernel o vicino al sistema. Importante dal punto di vista amministrativo: WireGuard gestisce lo stato in modo minimale (nessuna «sessione» pesante come nei classici SSL-VPN) e si configura tramite peer fissi. Questo è stabile, ma facilita l’instradamento eccessivamente permissivo delle reti.

Indirizzamento e AllowedIPs: la leva di rischio più comune

In WireGuard AllowedIPs è contemporaneamente una definizione di routing e una specie di „ACL leggera“: quali reti di destinazione vengono instradate attraverso il tunnel (lato client) e quali intervalli di IP sorgente un peer „può avere“ (lato server). Possibili errori:

• 0.0.0.0/0 (Full Tunnel) per comodità: può andare bene, ma aumenta la dipendenza dalla VPN e rende la diagnosi dei guasti più complessa.
• Reti interne troppo grandi in AllowedIPs: consente l’accesso a sistemi non pensati per l’uso remoto.
• Sovrapposizione di IP con reti domestiche o reti di partner: provoca problemi di routing intermittenti.

È consolidato l’uso di un subnet VPN dedicato per gruppo di utenti o scopo (es. amministratori, account di servizio, fornitori terzi). In questo modo è possibile separare in modo pulito policy e logging.

Modello di configurazione: server WireGuard con ambito peer RESTrittivo

Di seguito un esempio di interfaccia server WireGuard (Linux). Il punto non è tanto la sintassi quanto il modello: rete VPN dedicata, hook per logging/firewall, niente „catch-all“.

# /etc/wireguard/wg0.conf
[Interface]
Address = 10.60.0.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY>

# Optional: beim Up/Down Firewall-Regeln setzen
PostUp = nft add rule inet filter forward iifname "wg0" oifname "lan0" ip daddr { 10.10.20.0/24 } tcp dport { 22, 3389 } accept
PostUp = nft add rule inet filter forward iifname "wg0" drop
PostDown = nft flush chain inet filter forward

[Peer]
# Admin-Laptop 01
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 10.60.0.10/32
PersistentKeepalive = 25

Importante: AllowedIPs sul lato server per peer solo /32 (un singolo IP di tunnel). Quali reti di destinazione sono raggiungibili è preferibile deciderlo tramite firewall/policy sul gateway e nei segmenti di destinazione – non tramite rotte „amichevoli“.

MTU, NAT e roaming: insidie operative tipiche

• Problemi di MTU: quando si lavora su DSL/PPPoE, LTE o attraverso ulteriori tunnel, la frammentazione può causare perdite silenziose di pacchetti. Sintomo: SSH si connette ma SFTP RESTa bloccato; RDP è lento. Contromisura: ridurre l’MTU sull’interfaccia WireGuard (spesso 1380 o 1420, a seconda del percorso) e testare con Ping/DF.
• NAT e reti variabili: i client mobili beneficiano di PersistentKeepalive, altrimenti le associazioni NAT si „addormentano“.

VPN-HA: Verfügbarkeit erhöhen, ohne Kontrolle zu verlieren

VPN High Availability significa: il guasto di un gateway non deve interrompere le operazioni remote. In pratica esistono tre approcci comuni, che incidono in modo diverso su logging, materiale delle chiavi e diagnostica.

Option A: Floating IP / VRRP (klassisch, gut nachvollziehbar)

Con VRRP (Virtual Router Redundancy Protocol, spesso tramite keepalived) una Floating IP viene assunta in caso di failover. Vantaggio: i client mantengono un endpoint stabile (DNS/IP). Svantaggi: è necessaria una sincronizzazione pulita dello stato/configurazione e bisogna considerare che, sebbene WireGuard sia a bassa dipendenza di stato, i peer e le chiavi devono essere configurati in modo identico.

Minimalbeispiel keepalived (Achtung: je nach Distribution/Netzwerksetup anpassen):

# /etc/keepalived/keepalived.conf
vrrp_instance VPN {
  state BACKUP
  interface eth0
  virtual_router_id 60
  priority 100
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass <STRONG_RANDOM>
  }
  virtual_ipaddress {
    203.0.113.10/32
  }
}

Stolperfallen bei Floating-IP-Setups:

• ARP/NDP-Caches: Bei IPv4/IPv6 kann es Minuten dauern, bis alle Netze den neuen Master sehen. Planen Sie GARP/Gratuitous Neighbor Advertisements ein.
• State in Firewalls: Stateful Firewalls/NAT können bestehende Flows verlieren. Das ist bei Admin-Zugriff oft akzeptabel, aber muss in Runbooks stehen.
• Logging-Identität: Wenn beide Nodes unter derselben VIP sichtbar sind, müssen Sie Node-IDs in Logs sauber mitschreiben (Hostnames, Agent-Tags).

Option B: DNS-Failover (einfach, aber zeitkritisch)

Il DNS-Failover con TTL breve può funzionare, ma in incidenti e a causa delle cache dei provider è inaffidabile. Per l’accesso amministrativo il DNS-Failover è spesso una seconda scelta, a meno che non disponiate di uno stack client controllato (es. notebook aziendali con resolver definito).

Option C: Anycast / Load Balancer (stark, aber konzeptionell anspruchsvoller)

Anycast o un bilanciatore posto a monte possono risolvere l’HA in modo elegante, ma introducono nuove questioni: il load balancing su UDP (WireGuard è UDP) deve funzionare correttamente, l’osservabilità diventa più complessa e nella distribuzione a L4 dovete pianificare correttamente la gestione dell’IP sorgente per logging e policy.

HA-Checkliste: was Sie vor dem Go-live testen sollten

• Failover sotto carico: sessioni SSH attive, connessioni simultanee, risoluzione DNS.
• Rejoin/Failback: il ritorno al nodo primario non deve oscillare (commutazioni frequenti).
• Deriva di configurazione: Peer/Policy/Regole del firewall devono essere versionate in modo identico (es. via Git e CI per i deploy delle configurazioni).
• Continuità dei log: entrambi i nodi inviano i log in modo centralizzato; l’orario/NTP è sincronizzato.

Design della SSH-Bastion: punto d’ingresso controllato invece di „SSH überall”

Un SSH-Bastion Host (anche Jump Host) è un server indurito che funge da unico punto d’ingresso SSH in un segmento amministrativo. Il vantaggio è operativo: si indurisce un nodo in modo approfondito, si fanno rispettare le identità, si aggregano le policy e si ottengono log coerenti. Allo stesso tempo si riduce la superficie d’attacco esposta: i sistemi target non devono essere raggiungibili direttamente dalla VPN.

Modello di rete e zone: così la bastion diventa efficace

La bastion appartiene tipicamente a una zona separata (z. B. „Admin-Access“ oder „Management“). Regole che hanno dato buoni risultati:

• I client VPN possono solo connettersi alla bastion (TCP/22) e, se necessario, a un Identity-/MFA-Proxy.
• Dalla bastion le destinazioni sono raggiungibili solo sulle porte di management (SSH, WinRM, RDP tramite gateway, Out-of-Band solo in caso di emergenza).
• L’accesso VPN diretto ai workload di produzione è evitato; le eccezioni sono documentate e strettamente regolamentate.

Indurimento della bastion: i principali interventi

Sulla bastion poche misure decidono spesso tra „auditabile“ e „speriamo che lo sia“. Elementi chiave:

• Niente SSH con password: esclusivamente Public-Key, idealmente con chiavi basate su hardware (FIDO2/PKCS#11) o certificati a breve durata.
• MFA prima dell’accesso SSH: ad es. tramite integrazione SSO/IdP o moduli PAM; è importante che una chiave rubata dal laptop da sola non sia sufficiente.
• Nessun account condiviso: ogni admin usa un’identità personale; sudo viene auditato.
• Regole di egress RESTrittive: la bastion non deve avere accesso libero a „Internet“, altrimenti, in caso di compromissione, diventa un punto di salto.
• Disciplina di patch e reboot: la bastion è Tier-0 per l’accesso amministrativo, quindi va aggiornata con priorità e vanno pianificate finestre di riavvio.

Configurazione SSH: impostazioni predefinite chiare, poche sorprese

Esempio di una configurazione sshd conservativa (Auszug). Obiettivo: divieti chiari, controllo deliberato del forwarding, log informativi. A seconda dell’ambiente questo può essere più RESTrittivo o più flessibile.

# /etc/ssh/sshd_config (Auszug)
Port 22
Protocol 2
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey

AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no
GatewayPorts no

ClientAliveInterval 300
ClientAliveCountMax 2
LogLevel VERBOSE

# Optional: nur definierte Gruppen
AllowGroups it-admins it-ops

Perché „LogLevel VERBOSE“? Così sshd scrive più contesto (p.es. Key-Fingerprint), utile nella forensics in caso di chiavi compromesse. Contemporaneamente dovete tenere sotto controllo il volume dei log e i requisiti di protezione dei dati (dati personali).

Trappole: SSH-Agent-Forwarding e Port-Forwarding

Molti amministratori usano l’agent-forwarding come funzione di comodità. Rischio: se la bastion viene compromessa, un attaccante può abusare dell’agent inoltrato. Altrettanto critico è il TCP-Forwarding (locale/remoto/dinamico), perché aggira le policy e crea tunnel inattesi. Un design sicuro di default è: Forwarding disabilitato per impostazione predefinita, ed eccezioni concesse in modo mirato per gruppo o host — incluse logging e data di scadenza.

Access-Logging: da „VPN acceso/spento“ a audit trail attendibili

Con Access-Logging molti intendono solo „chi si è connesso“. Per il funzionamento e l’incident response servono più informazioni: chi (identità), da dove (dispositivo/peer, rete di origine), quando (orario, fuso orario, correlazione), dove (sistema di destinazione/porta), e idealmente cosa (metadati di sessione o registrazione).

Quali fonti di log sono almeno necessarie

• WireGuard-Gateway: handshake del peer, pacchetti consentiti/negati (firewall), eventi dell’interfaccia.
• Bastion: SSH-Auth, sudo, avvio/fine della sessione; opzionale registrazione della sessione (TTY-Recording).
• Sistemi di destinazione: accessi riusciti e falliti, azioni privilegiate, eventualmente log RDP/WinRM.
• Identity Provider: eventi MFA, emissione token, modifiche a ruoli/gruppi.

Tecnicamente è essenziale che tutti i sistemi siano sincronizzati temporalmente (NTP/chrony). Senza timestamp coerenti la correlazione in SIEM/Log-Search è costosa e inaffidabile.

Inoltro centralizzato dei log: robusto contro il Backpressure

In esercizio il logging spesso fallisce a causa del „Backpressure“ (il destinatario dei log è lento o offline). Gli eventi vengono persi o i sistemi si bloccano. Sono consolidate soluzioni con agenti/forwarder dotati di coda (p. es. rsyslog con Disk-Queue). Esempio: rsyslog con queue persistente per un inoltro sicuro a un collector centrale (i dettagli TLS sono omessi, perché la PKI varia a seconda dell’ambiente).

# /etc/rsyslog.d/60-remote-access.conf
module(load="imjournal")

# Persistente Queue für Ausfälle des Collectors
action(type="omfwd"
       target="log-collector.intern"
       port="6514"
       protocol="tcp"
       StreamDriver="gtls"
       StreamDriverMode="1"
       StreamDriverAuthMode="anon"
       action.resumeRetryCount="-1"
       queue.type="LinkedList"
       queue.filename="q_remote_access"
       queue.maxdiskspace="2g"
       queue.saveonshutdown="on")

Nota: StreamDriverAuthMode=“anon“ è mostrato qui solo come segnaposto. In ambienti di produzione dovreste abilitare la verifica del certificato server e idealmente mTLS (autenticazione TLS reciproca), affinché i log non finiscano in mani sbagliate o vengano inviati a destinazioni errate.

Quali elementi dovrebbero essere correlabili come minimo in SIEM/sistema di ricerca

• VPN-Peer-IP ↔ dispositivo/utente (asset e identity mapping)
• Login sulla bastion ↔ login sull’host di destinazione (relazione di salto)
• sudo/azioni privilegiate ↔ Change-Tickets/Incident-Tickets (a livello processuale)
• tentativi falliti e anomalie (p. es. nuovi paesi, orari insoliti, nuove destinazioni)

Passaggi di implementazione: un piano di rollout pragmatico

Un errore frequente è il «Big Bang»: modificare simultaneamente VPN, Bastion e logging. Più stabile è un rollout iterativo che lasci opzioni di rollback.

Fase 1: Definire le basi di rete e delle policy

• Definire le subnet VPN (per Persona/Partner/Use-Case).
• Identificare i segmenti target (rete di management vs. rete applicativa vs. rete database).
• Progettare regole firewall: dal VPN solo alla Bastion; dalla Bastion solo alle porte di management.
• Pianificare la risoluzione dei nomi (DNS interno tramite tunnel, documentare chiaramente lo Split DNS).

Fase 2: Rendere il gateway WireGuard pronto per la produzione

• Versionare la configurazione (Git), rendere il deploy riproducibile.
• Monitoring: interfaccia up/down, raggiungibilità della porta UDP, drop di pacchetti, CPU/memoria.
• Testare e definire l’MTU; verificare il roaming con le reti mobili.

Fase 3: Introdurre la Bastion e ridurre l’accesso diretto

• Installare la Bastion in modalità hardened, accesso solo dalle subnet VPN.
• Riconfigurare i sistemi target in modo che SSH sia consentito solo dalla Bastion/rete di management.
• Testare i workflow amministrativi (scp/rsync/ansible), senza permettere bypass di forwarding.

Fase 4: Centralizzare i log di accesso e rispondere alle richieste di audit

• Attivare un log-forwarder con coda.
• Dashboard/interrogazioni: ‚Chi ha acceduto a quale host e quando?‘
• Definire retention e controllo d’accesso sui log (i log sono sensibili).

Passi di verifica e troubleshooting: quando non funziona come nel diagramma

Per l’accesso remoto dovreste avere un runbook breve che funzioni anche durante un incidente sotto stress. Sequenze pratiche di verifica:

1) Raggiungibilità e handshake (Gateway)

# WireGuard-Status
sudo wg show

# Interface-Details
ip -brief address show wg0
ip route show table main | grep -E "10.60.0.0/24|wg0"

Se mancano i handshake: verificare porta UDP/firewall, NAT/keepalive, chiavi errate, drift temporale (nei sistemi che legano meccanismi di autenticazione aggiuntivi).

2) Percorso e policy (Firewall/Segmentazione)

# Paketfilter prüfen (nftables Beispiel)
sudo nft list ruleset

# Drops im Kernel (je nach Setup)
sudo journalctl -k --since "15 min ago" | tail -n 200

Il sintomo ‚VPN connessa, ma destinazione non raggiungibile‘ è quasi sempre dovuto a policy/routing/MTU. Utilizzare trace (tcpdump) in due punti: su wg0 e sull’interfaccia di destinazione.

3) Login sulla Bastion e salto verso il target

# SSH-Auth-Events auf der Bastion
sudo journalctl -u ssh --since "30 min ago"

# sudo-Audit (Distribution abhängig)
sudo journalctl --since "30 min ago" | grep -i sudo | tail -n 50

Se il login sulla Bastion riesce ma il salto verso il target no: firewall del target (è consentita solo l’IP della Bastion?), DNS (nome target interno?), hostkeys/known_hosts (in caso di rebuild), e policy diverse per utenti/chiavi.

Strategia di rollback: tornare in sicurezza senza perdita di controllo

Una buona strategia di rollback non significa ‚tornare tutto com’era prima‘, ma smantellamento controllato in caso di malfunzionamenti:

• Break-Glass-Zugang (accesso d’emergenza): credenziali separate, registrate in modo rigoroso, testate regolarmente, conservate offline. L’obiettivo è la disponibilità durante l’incidente, non il comfort.
• Staged Rollback: prima disabilitare l’HA (single node più stabile), poi allentare le policy (a tempo), e solo infine bypassare la Bastion.
• Change-Flags: strutturare le regole firewall in modo da permettere attivazioni temporanee e tracciabili di eccezioni (con data di scadenza e riferimento al ticket).

Importante: le vie di fallback devono essere note al team in anticipo. In caso di emergenza altrimenti si generano workaround ad hoc che sopravvivono per mesi.

Decisioni di progettazione tipiche e loro effetti collaterali

Split Tunneling vs. Full Tunneling

Split Tunneling significa: solo le reti interne transitano tramite VPN, l’accesso a Internet rimane locale. Vantaggio: minore carico, minore dipendenza. Svantaggio: DNS e controlli di sicurezza risultano più difficili da far rispettare in modo coerente. Full Tunneling semplifica le policy di sicurezza centralizzate (proxy web, filtro DNS), ma aumenta l’impatto di un’interruzione del VPN. Decidete consapevolmente per gruppo di utenti, non a livello globale.

Device Binding und Schlüssel-Lifecycle

WireGuard lavora con coppie di chiavi. Operativamente dovete chiarire: come vengono emesse, ruotate e revocate le chiavi? Senza un ciclo di vita si generano «peers dimenticati». Requisiti minimi pratici:

• Assegnazione del peer a un asset (laptop/ID dispositivo) e a una persona.
• Processo di offboarding: rimuovere il peer, marcare i log, eventualmente bloccare le chiavi della bastion SSH.
• Rotazione: almeno in caso di perdita del dispositivo o cambio di ruolo, idealmente a intervalli periodici.

Access-Logging und Datenschutz

I log di accesso contengono dati personali (utenti, IP, orari) e in parte dati di contenuto (nel caso di session recording). Documentate: finalità, retention, accesso, analisi. Per i team di amministrazione è importante che le regole non siano «grigie»: politiche chiare prevengono discussioni successive durante un incidente.

Inquadramento rispetto a Zero Trust e PAM

Molte organizzazioni si muovono verso Zero Trust Network Access (ZTNA), cioè «non fidarsi mai implicitamente, verificare sempre in modo esplicito». WireGuard può farne parte, ma non sostituisce il livello di identità e policy. Una bastion è a sua volta un componente del Privileged Access Management (PAM), ossia la gestione degli accessi privilegiati con tracciabilità. Se in seguito introdurrete suite PAM o gateway ZTNA, beneficerete del lavoro preparatorio: segmentazione, punti di ingresso chiari e log puliti.

Conclusione: Remote Access è un sistema, non un singolo prodotto

Un’architettura di remote access sicura nasce quando trasporto (WireGuard), disponibilità (VPN-HA), controllo (bastion SSH) e tracciabilità (logging degli accessi) vengono pianificati insieme. Il beneficio operativo è tangibile: minore superficie di attacco esposta, autorizzazioni più chiare, percorsi di troubleshooting riproducibili e audit trail affidabili.

Se volete mantenere l’approccio pragmatico, iniziate con tre passi: separare le sottoreti VPN, istituire una bastion come unico punto di ingresso per gli amministratori e rendere i log centralmente correlabili. Successivamente il design scala – anche verso ZTNA o programmi PAM più ampi.

Per questo tema sono importanti anche Wireguard Vpn e Ssh Bastion Host. Il contributo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.