sicurezza
Approfondimento: WebGate
Protezione applicativa a fiducia zero: perché agire prima dell'applicazione, autenticazione via codice email e riconoscimento del dispositivo, permessi per dominio, rollout in modalità osservazione.
Aggiornato il 03 settembre 2026
Approfondimento: WebGate
Il problema che risolve
Le aree di amministrazione dei siti web sono un bersaglio permanente, e la protezione tipica sta dentro l'applicazione: un plugin, un modulo, una configurazione applicativa. Questo introduce una dipendenza fragile. Il plugin può essere disattivato da un aggiornamento; un'applicazione compromessa può disabilitare la propria protezione; una vulnerabilità nel codice che precede il controllo lo rende irrilevante.
WebGate sposta il controllo fuori dall'applicazione, a livello di web server: il traffico viene valutato prima di raggiungere il codice applicativo. Un sito compromesso non può disattivare ciò che sta a monte di sé.
Il secondo problema che affronta è di usabilità. La protezione classica di un'area amministrativa è la lista di indirizzi IP autorizzati, che funziona finché tutti lavorano da una sede fissa e smette di funzionare con IP dinamici, connessioni mobili e lavoro da remoto — a quel punto la lista viene allargata fino a perdere significato.
Parte 1 — Il modello
Autorizzazione per identità, non per indirizzo
L'accesso non si basa sull'indirizzo di rete ma sull'identità: chi è autorizzato riceve un codice via email e il suo dispositivo resta riconosciuto. Il meccanismo funziona da qualsiasi rete, anche con IP dinamico e da mobile, senza VPN e senza client.
Il cambio di paradigma ha una conseguenza organizzativa importante: i permessi si esprimono in una forma che chi non è tecnico può verificare. «Possono accedere gli indirizzi del dominio azienda.it, più due consulenti nominali, con scadenza a fine progetto» è una regola leggibile e auditabile, a differenza di un elenco di indirizzi IP.
La revoca ha effetto su tutti i siti in pochi secondi. È la proprietà che rende praticabile la gestione delle uscite dal personale: un'unica azione anziché una revisione sito per sito.
La modalità osservazione
È l'elemento che distingue un rollout riuscito da un'interruzione di servizio. Prima di bloccare, WebGate registra chi verrebbe bloccato e su quali percorsi. La protezione si attiva quando i dati confermano che nulla si rompe, non prima.
Il valore è concreto: in qualsiasi sito con qualche anno di vita esistono accessi legittimi che nessuno ricorda — un'integrazione, un job schedulato, un webhook, un collaboratore esterno con un'utenza dimenticata. Attivare un blocco senza averli censiti significa scoprirli uno alla volta, sotto pressione, dai reclami.
La struttura della sezione
WebGate è, insieme a Identity, il modulo con la ripartizione dei permessi più definita: la consultazione di tutte e cinque le schede è aperta a ogni ruolo, incluso Viewer; creazione, modifica ed eliminazione sono riservate a Manager e Operator. Un Viewer può quindi verificare chi è autorizzato senza poter alterare le autorizzazioni: è una separazione utile per chi ha compiti di controllo.
Condizioni di attivazione
I primi dieci siti in test sono gratuiti, e non c'è costo aggiuntivo se è già attiva una managed app. Il servizio è descritto in catalogo come reverse proxy applicativo con SSL automatico, routing per path e host e protezione integrata.
Parte 2 — Operatività
Playbook — Rollout su un sito esistente
- Verificare nella scheda Domini la configurazione già presente, per evitare sovrapposizioni con quanto si vuole aggiungere.
- Predisporre l'elenco degli utenti che devono accedere, distinguendo il personale interno — che conviene autorizzare per dominio di posta — dai consulenti, da autorizzare nominalmente e con scadenza.
- Attivare la modalità osservazione dalla scheda Impostazioni.
- Lasciare raccogliere i dati per un periodo rappresentativo: deve includere i giorni e le fasce orarie di maggiore attività, ed è meglio una settimana piena che tre giorni lavorativi.
- Analizzare i risultati dalla scheda Panoramica: per ogni accesso rilevato, stabilire se è legittimo e a chi corrisponde.
- Integrare le autorizzazioni mancanti nella scheda Utenti autorizzati.
- Ripetere l'osservazione per un periodo breve, per confermare che l'elenco sia completo.
- Disattivare l'osservazione e rendere effettiva la protezione.
- Comunicare il cambiamento agli utenti: al primo accesso riceveranno un codice via email, e senza preavviso lo interpreteranno come un malfunzionamento.
Playbook — Esposizione di una nuova applicazione
Quattro informazioni sono sufficienti, e sono esattamente i parametri con cui si configura un reverse proxy con controllo degli accessi:
Con ruolo Manager o Operator la configurazione si esegue dalle schede Server e Domini. Altrimenti si apre un ticket in categoria WEB HOSTING, fornendo le quattro informazioni nel primo messaggio per evitare uno scambio di chiarimenti.
Playbook — Uscita di una persona dall'organizzazione
- Rimuovere l'autorizzazione dalla scheda Utenti autorizzati: la revoca propaga su tutti i siti in pochi secondi.
- Se la persona era coperta da un'autorizzazione per dominio di posta, aggiungere un'eccezione puntuale anziché rimuovere il dominio.
- Verificare le altre aree: chiavi SSH nella sezione Identity, autorizzazioni DeepGate, credenziali condivise eventualmente visualizzate. WebGate copre l'accesso web, non l'intera superficie.
- Rimuovere l'utenza dalla sezione Organizzazione.
Il confine con DeepGate
Non sono alternative, e sceglierne uno per il problema dell'altro produce lavoro inutile.
Un'infrastruttura completa usa entrambi: WebGate per ciò che gli utenti raggiungono via browser, DeepGate per ciò che gli amministratori raggiungono via protocolli di gestione.
Punti aperti
Il manuale descrive il modello, la struttura delle schede e i permessi per ruolo, ma non documenta la durata del riconoscimento del dispositivo, il comportamento su richieste non interattive come API e webhook — che non possono ricevere un codice via email — né la sintassi delle regole di routing per path e host. Sono aspetti da chiarire con il team prima di proteggere un'applicazione che riceve traffico automatizzato, perché determinano se serve un'eccezione per quel traffico.