Approfondimento: DeepGate

Approfondimento: DeepGate

Il problema che risolve

L'accesso amministrativo remoto è il punto in cui la maggior parte delle infrastrutture cede. Non perché i protocolli siano debolmente protetti, ma per due dinamiche organizzative: i servizi di gestione restano raggiungibili da Internet per comodità, e le regole di accesso concesse per un intervento non vengono revocate quando l'intervento finisce.

La prima produce una superficie di attacco permanente, censita in continuo dalle scansioni automatiche. La seconda produce un firewall che, dopo qualche anno, contiene decine di eccezioni di cui nessuno sa più giustificare l'esistenza. DeepGate affronta entrambe.

Parte 1 — Il modello

Fiducia zero applicata alla rete

Il principio è che nessun indirizzo sia affidabile per definizione. Chi deve raggiungere un servizio si autentica, e solo dopo il firewall apre il passaggio dal suo indirizzo verso quel servizio specifico. Chi non è autorizzato non trova la porta chiusa: non trova la porta.

Ne derivano tre proprietà rilevanti:

• I servizi protetti non sono visibili. Le porte restano chiuse a chi non è autorizzato, quindi non compaiono nelle scansioni automatiche. Un servizio che non appare in una scansione non entra nelle liste di bersagli.
• L'autorizzazione è puntuale. I permessi si definiscono per servizio e per host: un fornitore che deve lavorare su un singolo server ottiene quel server, non la rete.
• L'apertura si chiude da sola. Ogni autorizzazione ha una durata. È la proprietà che elimina strutturalmente il problema delle regole dimenticate.

Perché non è una VPN

La differenza non è di implementazione ma di modello, e determina quali problemi ciascuna soluzione risolve.

La copertura di qualsiasi protocollo è ciò che distingue DeepGate da un reverse proxy applicativo: SSH, RDP, pannelli di gestione, database, interfacce IPMI. È la ragione per cui DeepGate e WebGate non sono alternative ma complementi — il primo protegge l'accesso amministrativo, il secondo l'accesso applicativo web.

Cosa fa la piattaforma, oggi

Va distinto ciò che DS001 espone da ciò che il servizio fa.

L'attivazione non comporta costi aggiuntivi se l'organizzazione ha già un resource pool attivo.

Il confine con il modulo Firewall

Il modulo Firewall, annunciato per ottobre 2026, coprirà regole di ingresso e uscita, NAT 1:1, port forwarding, reti private e utenti VPN gestiti dal pannello. Non sostituirà DeepGate: sono livelli diversi. Il Firewall gestirà la politica di rete complessiva; DeepGate gestisce l'accesso autenticato e temporaneo a servizi specifici.

Nel frattempo, per l'accesso remoto ai servizi interni, DeepGate copre già l'esigenza che si risolverebbe con una VPN, e senza il client.

Parte 2 — Operatività

Playbook — Onboarding di un fornitore esterno

Il caso d'uso su cui DeepGate rende più della VPN.

1. Definire l'ambito prima di scrivere la richiesta: quale host, quale servizio, quale porta, quale protocollo. Il modello di DeepGate è per servizio e per host, quindi una richiesta formulata a livello di rete va comunque tradotta in permessi puntuali, e farlo in autonomia accorcia la lavorazione.
2. Definire la finestra temporale. Non «accesso al server X», ma «accesso al server X dal giorno Y per Z giorni»: le autorizzazioni si chiudono da sole, quindi la durata è un parametro della richiesta, non un'aggiunta facoltativa.
3. Verificare in Network quali altre macchine condividono il segmento dell'host di destinazione: serve a confermare che l'accesso puntuale sia effettivamente sufficiente.
4. Aprire un ticket nella categoria FIREWALL, VPN & PORTE indicando chi accede, a quali host e servizi, su quali porte e protocolli, e per quanto tempo.
5. Consultare la tabella degli accessi nella sezione DeepGate per verificare la configurazione applicata.
6. Al termine dell'intervento verificare che l'autorizzazione sia effettivamente decaduta, anziché darlo per assunto.

Playbook — Sostituzione di un accesso permanente esistente

Quando si eredita un'infrastruttura con porte amministrative esposte.

1. Censire i servizi di gestione raggiungibili dall'esterno e, per ciascuno, chi ha bisogno di raggiungerlo e con quale frequenza.
2. Distinguere gli accessi ricorrenti da quelli occasionali: i primi diventano autorizzazioni con durata lunga e rinnovabile, i secondi autorizzazioni brevi richieste all'occorrenza.
3. Aprire un ticket per configurare gli accessi DeepGate corrispondenti, prima di chiudere le esposizioni esistenti.
4. Verificare che ciascun utente riesca ad accedere tramite il nuovo percorso.
5. Solo allora richiedere la chiusura delle esposizioni dirette, con un ticket separato che le elenchi puntualmente.
6. Annotare l'intervento nel diario delle attività delle macchine coinvolte: è il registro che consente di ricostruire il cambiamento a distanza di mesi.

L'ordine conta: chiudere prima di aver verificato il nuovo percorso produce un'interruzione operativa e, tipicamente, una riapertura d'urgenza che vanifica il lavoro.

Come formulare una richiesta efficace

Una richiesta si lavora rapidamente quando contiene, in forma di elenco: identità o gruppo che deve accedere, host di destinazione con il codice VM, servizio e porta, protocollo, durata, e il motivo dell'accesso. Il motivo non è burocrazia: è ciò che permette al team di proporre un ambito più stretto se quello richiesto è più ampio del necessario.

Cosa verificare periodicamente

Il primo controllo è quello che DeepGate rende semplice e che con un firewall tradizionale tende a non farsi mai: la tabella degli accessi è un elenco leggibile, non una configurazione da interpretare.

Punti aperti

Il manuale utente descrive il modello e le proprietà del servizio, ma non documenta la sintassi delle regole, i formati accettati per l'identificazione degli utenti autorizzati, la durata predefinita delle aperture né il comportamento al rinnovo di un'autorizzazione scaduta. Sono informazioni che il team fornisce in fase di configurazione: conviene chiederle nel primo ticket di attivazione e conservarle, perché condizionano il modo in cui si formulano le richieste successive.

Vedi anche

• Security · Approfondimento: WebGate · Reti