Richiede SSL, mantieni SELinux acceso, monitora i log e usa una versione PostgreSQL corrente .
Lato server
Richiedi SSL
Nel postgresql.confset ssl=one assicurati di avere il file di chiavi e il file di certificato installati correttamente (vedere i documenti e i commenti in postgresql.conf).
Potrebbe essere necessario acquistare un certificato da un'autorità di certificazione se si desidera che sia attendibile dai client senza un'installazione speciale sul client.
In pg_hba.confuso qualcosa come:
hostssl theuser thedatabase 1.2.3.4/32 md5
... possibilmente con "tutto" per l'utente e / o il database e possibilmente con un filtro dell'indirizzo IP di origine più ampio.
Limitare gli utenti che possono accedere, negare l'accesso remoto da superutente
Non consentire "tutto" agli utenti, se possibile; non si desidera consentire gli accessi da superutente in remoto se è possibile evitarne la necessità.
Limitare i diritti degli utenti
Limitare i diritti degli utenti che possono accedere. Non concederli CREATEDBo CREATEUSERdiritti.
REVOKEil CONNECTdiritto PUBLICsu tutti i tuoi database, quindi restituiscilo solo agli utenti / ruoli che dovrebbero essere in grado di accedere a quel database. (Raggruppare gli utenti in ruoli e concedere diritti ai ruoli, anziché direttamente ai singoli utenti).
Assicurarsi che gli utenti con accesso remoto possano connettersi solo ai DB di cui hanno bisogno e disporre solo dei diritti su schemi, tabelle e colonne di cui hanno effettivamente bisogno. Questa è una buona pratica anche per gli utenti locali, è solo una sicurezza ragionevole.
Configurazione del client
In PgJDBC, passa il parametrossl=true :
Per indicare al driver JDBC di provare a stabilire una connessione SSL, è necessario aggiungere il parametro URL di connessione ssl = true.
... e installa il certificato del server nel truststore del client, oppure usa un certificato del server considerato attendibile da una delle autorità di certificazione nel truststore incorporato di Java se non desideri che l'utente debba installare il certificato.
Azione in corso
Ora assicurati di mantenere aggiornato PostgreSQL . PostgreSQL ha avuto solo un paio di buchi di sicurezza pre-autorizzazione, ma questo è più di zero, quindi tieniti aggiornato. Dovresti comunque, le correzioni dei bug sono cose carine da avere.
Aggiungi un firewall davanti se ci sono blocchi / regioni di grandi dimensioni da cui sai di non aver mai bisogno di accedere.
Registra connessioni e disconnessioni (vedi postgresql.conf). Log query se pratico. Esegui un sistema di rilevamento delle intrusioni o fail2ban o simile di fronte, se pratico. Per fail2ban con Postgres, c'è un comodo how-to qui
Monitorare i file di registro.
Paranoia bonus
Passaggi extra a cui pensare ...
Richiedi certificati client
Se lo si desidera, è possibile utilizzare anche pg_hba.confper richiedere che il client presenti un certificato client X.509 considerato attendibile dal server. Non è necessario utilizzare la stessa CA del cert del server, è possibile farlo con una CA openssl homebrew. Un utente JDBC deve importare il certificato client nel proprio keytoolarchivio chiavi Java e possibilmente configurare alcune proprietà del sistema JSSE in modo che punti Java al proprio archivio chiavi, quindi non è totalmente trasparente.
Metti in quarantena l'istanza
Se vuoi essere davvero paranoico, esegui l'istanza per il client in un container / VM separato, o almeno con un altro account utente, con solo il database oi database richiesti.
In questo modo se compromettono l'istanza PostgreSQL non otterranno più.
Usa SELinux
Non avrei dovuto dirlo, ma ...
Esegui una macchina con supporto SELinux come RHEL 6 o 7 e non spegnere SELinux o impostarlo in modalità permissiva . Mantieni la modalità di applicazione.
Utilizzare una porta non predefinita
La sicurezza solo per l' oscurità è stupidità. La sicurezza che usa un po 'di oscurità dopo aver fatto le cose sensibili probabilmente non farà male.
Esegui Pg su una porta non predefinita per rendere la vita un po 'più difficile per gli attaccanti automatizzati.
Metti un proxy davanti
Puoi anche eseguire PgBouncer o PgPool-II davanti a PostgreSQL, fungendo da pool di connessioni e proxy. In questo modo è possibile lasciare che il proxy gestisca SSL, non l'host del database reale. Il proxy può essere su una macchina o macchina virtuale separata.
L'uso dei proxy di pool di connessioni è generalmente una buona idea con PostgreSQL, a meno che l'app client non abbia già un pool integrato. La maggior parte dei server di applicazioni Java, Rails, ecc. Hanno un pool incorporato. Anche allora, un proxy di pooling lato server è nella peggiore delle ipotesi innocuo.