TLS può essere un'alternativa sicura alla VPN?

Sì ... e no ... e possibilmente sì di nuovo, se prendi precauzioni aggiuntive.

Perché non

Per quanto riguarda l'autenticità e la riservatezza, una connessione TLS è perfettamente adeguata. Ma non è l'unico motivo per cui la gente mette servizi come Postgres dietro una VPN. L'altro problema è che potresti non voler esporre il tuo database al pubblico.

L'autenticazione VPN funge da secondo ostacolo per gli autori di attacchi oltre all'autorizzazione integrata del database. Se postgres è compromesso o imperfetto in qualche modo, sei ancora abbastanza sicuro se la tua VPN è valida.

Ma se esponi il tuo database a Internet tramite una connessione TLS standard, chiunque può attaccarlo direttamente, sfruttando eventuali potenziali difetti nel protocollo nativo o autenticazione o consumando risorse in un attacco denial-of-service.

Come renderlo sicuro ancora

Tuttavia, esporre i servizi direttamente tramite TLS viene effettivamente eseguito in ambienti ad alta sicurezza con un avvertimento aggiuntivo: devi autenticare l'utente PRIMA di esporli al server di back-end.

Il modo più semplice per farlo è con i certificati client. Stai già configurando la tua CA per firmare il tuo certificato del server. Se lo usi anche per firmare i certificati client e richiedere un certificato client firmato per connettersi, hai effettivamente ristabilito la tua VPN per ogni connessione.

Configurare il server e il client per utilizzare i certificati client richiede una piccola quantità di lavoro, ma è ragionevole, in particolare rispetto a una suite VPN.

Una soluzione del genere è sicura quanto una VPN, meno complicata e più facile da implementare.

Sì, è un'opzione perfettamente ragionevole. È ciò che fa AWS RDS, Heroku Postgres, ecc.

Come qualsiasi software PostgreSQL potrebbe avere exploit remoti pre-autenticazione. Si dovrebbe tenere aggiornato sulle patch e avere un piano per l'aggiornamento alle nuove versioni. Esegui su una porta non predefinita e, se possibile, limita gli intervalli di indirizzi IP consentiti.

Ma alla fine non è troppo diverso da esporre qualcos'altro, come un server Apache.

Tuttavia :

• PostgreSQL è basato sulla sessione. Si aspetta che i clienti restino in giro e non gli piacciano se spariscono senza preavviso o smettono di rispondere a metà del lavoro. Non andrà in crash o fallirà, ma farà del lavoro non necessario e la connessione sparita potrebbe legare le risorse per un po '.

• A meno che non si stia facendo attenzione, il protocollo PostgreSQL esegue molti round trip. È possibile attenuarlo con le modalità batch di PgJDBC o nPgSQL e ho inviato una patch a libpq per aggiungere anche una modalità batch. Ma questa latenza danneggerà le prestazioni.

• PostgreSQL fa più lavoro pre-auth di alcuni sistemi, e le connessioni pre-autorizzazione contano contro il limite sul numero massimo di connessioni. Quindi è un po 'suscettibile a DoS.

I primi due problemi si applicano anche se stai usando una VPN, non sono unici per l'utilizzo basato su TLS.

Per questi motivi può valere la pena eseguire un server delle applicazioni vicino al database PostgreSQL e raggruppare le richieste di dati delle applicazioni in moduli strutturati con json / protobuf / qualsiasi richiesta e risposta. Questo è molto utile quando i client sono ampiamente dispersi e possono andare e venire a caso.

Se non hai intenzione di farlo, imposta brevi timeout su tutto in Pg, preparati a far fronte a nuovi tentativi, prova a utilizzare il batching e cerca di raggruppare il lavoro in query più grandi piuttosto che in molte piccole.

Quanto sono sensibili i dati? Non hai detto Ciò rende impossibile valutare quale sia il livello di rischio appropriato. Questo è fondamentale. "Abbastanza sicuro" è sempre relativo al rischio e al tuo budget per il progetto.

Sembra una di quelle situazioni che "dimostrano qualcosa non esiste". Logicamente, è impossibile da fare. Puoi provare solo quando esiste qualcosa . Quindi non ho intenzione di riuscirci. Ma a prescindere, darò una prova a convincerti che per i dati tipici, "l'accesso diretto sicuro ai database per gli utenti non fidati" in realtà non esiste.

La connessione è solo una parte del problema "accesso sicuro". Supponiamo che tu abbia gestito tutti gli exploit di downgrade della negoziazione e così via. Anche se la connessione è crittografata con una suite di crittografia TLS priva di bug correttamente configurata, quali dati sono gli utenti non fidati che inviano tramite o prima del canale crittografato, inclusi (come Craig Ringer menzionato) autenticazione? Stai sanificandolo prima che raggiunga il database?

La patch è ovviamente richiesta, ma non abbastanza da remoto. Per un database che potrebbe avere persone che lo sfruttano in qualsiasi momento, inclusi i dati di altri utenti nel database, probabilmente si vorrebbe DAM (controllo e controllo del database) e protezione IPS e DoS sensibile alle applicazioni. C'è una ragione per cui la migliore pratica consiste nel mettere il database dietro un gateway di qualche tipo, e non esporlo direttamente in questo modo.

L'esecuzione su una porta non predefinita è la sicurezza attraverso l'offuscamento. Non fermerà nessuno che sa come eseguire un port scanner e le impronte digitali, e sicuramente non chiunque stia prendendo di mira te. Dal momento che non ti fidi dei tuoi utenti, probabilmente dovresti pensare che uno stia prendendo di mira te.

Le limitazioni dell'intervallo IP non saranno di aiuto se non ti fidi di alcun IP utente. Gli host affidabili sono utili solo per consentire gli IP attendibili e bloccare il resto ... che nel tuo caso sembra bloccare ogni IP su Internet. Non molto utile.

Supponendo che tu abbia affrontato tutto ciò, ciò che vorrei suggerire sono le transazioni, i backup e la crittografia intensa dei dati di all'interno di ciascun utente con le proprie chiavi private che il tuo server non ha accesso a, in modo che anche se un utente malintenzionato compromettesse il database, una copia di dati di altri utenti sarebbe sostanzialmente inutile per l'aggressore. Avere un server di standby VM pronto per l'uso in qualsiasi momento, e non sarebbe male avere uno spazio di archiviazione separato in modo da poter cancellare periodicamente quella VM e portarne una nuova. Ciò non impedirebbe a qualcuno di possedere il server, ma contribuirebbe almeno a proteggere i dati stessi e offrirà una risposta e un ripristino rapidi.

Ma prima ancora di entrare nei dettagli specifici di PostgreSQL.

Come puoi vedere, una maggiore sicurezza diventa costosa e richiede molto tempo. Se i dati sono cat doodles sui tovaglioli, probabilmente non ne vale la pena. Saresti meglio servito da un diverso metodo di accesso.

La sicurezza del trasporto come TLS, VPN o SSH viene utilizzata per proteggere utenti fidati durante la connessione attraverso una rete non sicura . Non possono proteggere i sistemi da utenti non fidati.

Se si hanno utenti non fidati che hanno bisogno di accedere al database, il modo tradizionale per farlo in modo sicuro è quello di avvolgere il database in un livello applicazione. Il livello dell'applicazione implementa l'autenticazione (es. Nome utente / password, token segreti condivisi, certificati client), autorizzazioni, query e permessi predefiniti (es. "Chi è autorizzato a eseguire le query con quale parametro" o "chi è autorizzato a modificare quali dati con quali condizioni "), e il formato di output (es. JSON, CSV, HTML). Facoltativamente, il livello dell'applicazione può anche implementare l'interfaccia utente. Nella pratica moderna, si tratta in genere di un'applicazione Web basata su browser o di un'API Web.

In alcuni casi, è possibile implementarlo utilizzando procedure memorizzate e limitare gli utenti del database a consentire solo chiamate stored procedure, ma questo può essere piuttosto complicato quando si iniziano a richiedere complicati permessi e formati di output.