Perché evitare di inoltrare la porta 1433
Hai un SQL Server in ufficio. Qualcuno fuori da quella rete — un analista da remoto, uno strumento di reportistica in cloud, un'app che il team vuole costruire — deve leggerlo. La soluzione rapida che tutti suggeriscono: inoltrare la porta TCP 1433 dal router al server e aprirla nel firewall.
Funziona, ed è rapido. È anche quello che quasi ogni esperto di sicurezza ti dirà di non fare:
- La schermata di login diventa pubblica. Qualsiasi cosa su internet raggiunge SQL Server e prova ad autenticarsi. Scanner automatici cercano la 1433 aperta tutto il giorno, provando utenti come
sacon liste di password. - Il database diventa il tuo perimetro. Ogni patch arretrata e ogni login debole ora si raggiungono da fuori.
- Limitare per IP aiuta, ma è fragile. Restringere la 1433 agli IP di un fornitore riduce l'esposizione, ma quegli indirizzi cambiano e qualcuno deve tenere aggiornata la lista.
Quello che vuoi davvero è che qualcosa di esterno legga quel database senza nessuna porta in ingresso. Ci sono quattro modi per farlo.
Opzione 1: una VPN
Una VPN porta chi sta fuori "dentro" la tua rete. Una VPN client collega il portatile di una persona; una VPN site-to-site unisce due reti in modo permanente.
Ottimo per le persone. Un commercialista da remoto che usa SQL Server Management Studio è esattamente il caso per cui sono nate.
Non per gli strumenti SaaS. La maggior parte dei servizi cloud non può entrare nella tua VPN. E il gateway VPN di solito ascolta su una porta in ingresso: scambi un database esposto con un endpoint VPN esposto (molto più protetto, certo).
Opzione 2: un tunnel SSH tramite bastion host
Molti strumenti cloud offrono "connessione tramite tunnel SSH". Gestisci una piccola macchina Linux (bastion) a cui lo strumento si collega via SSH, e il traffico verso SQL Server passa da quella sessione.
Molto supportato, e SSH con chiavi è un protocollo noto e ben verificato.
Il problema: serve comunque una porta in ingresso — di solito la 22 — aperta su internet o agli IP del fornitore, su una macchina da aggiornare e monitorare. Per un ufficio senza indirizzo pubblico è una scelta debole, perché il bastion deve essere raggiungibile dall'esterno.
Opzione 3: un tunnel in uscita (Cloudflare Tunnel, ngrok, Tailscale)
I tunnel in uscita invertono la direzione: un piccolo servizio dentro la tua rete si collega verso l'esterno, e il traffico torna su quella connessione in uscita.
- Cloudflare Tunnel esegue
cloudflarednella tua rete, apre solo connessioni in uscita verso Cloudflare, e controlli chi accede con le sue policy di accesso. - ngrok apre una connessione in uscita e fornisce un endpoint pubblico che inoltra al servizio locale. Comodo per i test, ma senza controlli di accesso quell'endpoint è raggiungibile da internet.
- Tailscale crea una rete privata WireGuard tra i dispositivi registrati. Solo i membri della tua rete raggiungono SQL Server.
Nessuna regola in ingresso, nessun IP pubblico. Funzionano anche in un ufficio che non ha né l'una né l'altro.
Ma è accesso alla rete, non al database. Ciò che raggiunge il tunnel parla con SQL Server con i permessi del suo login. Policy, login e monitoraggio restano a te. E lo strumento SaaS dall'altra parte deve poter usare il tunnel, cosa che molti non sanno fare.
Opzione 4: un agente del fornitore che si collega verso l'esterno
Alcuni prodotti forniscono un proprio agente per questo caso. Lo installi su una macchina che vede il database; si collega al cloud del fornitore e il prodotto invia le query su quella connessione.
- Il gateway dati locale di Microsoft (on-premises data gateway) è il più noto. Gira su Windows, si collega in uscita ad Azure e serve Power BI, Power Apps, Power Automate e Logic Apps. Se il tuo team vive nell'ecosistema Microsoft, è la scelta naturale. (Lo confrontiamo nel dettaglio nella nostra guida alle alternative al gateway dati locale.)
- Il Connettore AgentUI fa lo stesso per app e dashboard di AgentUI, con un perimetro volutamente più stretto.
Perché è ordinato: nessuna porta in ingresso, nessun indirizzo pubblico, e l'agente serve solo i prodotti di quel fornitore, quindi non c'è un percorso di rete generico di cui preoccuparsi.
Il compromesso: ognuno serve solo i prodotti del proprio fornitore, e ti fidi dell'agente del fornitore: controlla cosa può e non può fare prima di installarlo.
A confronto
| Opzione | Apre una porta in ingresso? | Funziona senza IP pubblico? | Chi raggiunge il database | Ideale per |
|---|---|---|---|---|
| Inoltro della 1433 | Sì (1433) | No | Chiunque raggiunga la porta | Niente a lungo termine |
| VPN | Di solito, sul gateway | Dipende | Chiunque sia nella VPN | Persone con accesso completo |
| Tunnel SSH via bastion | Sì (22, sul bastion) | No | Chi ha una chiave del bastion | Strumenti cloud con tunnel SSH |
| Tunnel in uscita (Cloudflare Tunnel, Tailscale) | No | Sì | Chi la tua policy consente | Team che gestiscono policy di accesso |
| Agente del fornitore (gateway, Connettore AgentUI) | No | Sì | Solo i prodotti di quel fornitore | Usare gli strumenti di un fornitore sui dati |
Se l'obiettivo sono app e dashboard su quei dati
Se quello che vuoi davvero sono strumenti interni, report o dashboard sul database dell'ufficio, conta più il connettore del tunnel. È per questo che esiste il connettore SQL Server on-premise di AgentUI:
- Solo in uscita. Esce via HTTPS sulla porta 443. Nessuna regola in ingresso, nessuna modifica al firewall, nessun IP pubblico.
- Sola lettura. Girano solo query
SELECTeWITH, e ognuna viene annullata alla fine. - La password resta dov'è. È salvata solo su quel server (cifrata su Windows). AgentUI conserva solo un'impronta della chiave del connettore.
- Revocabile. Lo revochi in due clic; la chiave smette di funzionare entro 25 secondi.
- Limiti. Solo Microsoft SQL Server. Query su richiesta, fino a 1.000 righe e 30 secondi ciascuna. Non copia né sincronizza il database.
Si installa su Windows, macOS o Linux come servizio. Un caso tipico è SAP Business One su un server Windows. Se stai confrontando app builder su questo punto, abbiamo spiegato anche come Retool si collega a un SQL Server on-premise.
Quale scegliere?
- Una persona ha bisogno di accesso completo da casa: VPN.
- Uno strumento cloud supporta solo tunnel SSH: un bastion limitato agli IP del fornitore, da trattare come un server in più da mantenere.
- Il tuo team gestisce bene le policy di accesso e vuole una via generale: un tunnel in uscita come Cloudflare Tunnel o Tailscale.
- Vuoi che un solo prodotto legga i dati e nient'altro: l'agente in uscita di quel prodotto — il gateway Microsoft per la Power Platform, il Connettore AgentUI per le app AgentUI.
Se l'ultimo caso è il tuo, collega il tuo SQL Server con il Connettore AgentUI. Sola lettura, e lo revochi in due clic.