Exigir SSL, manter o SELinux ativado, monitorar os logs e usar uma versão atual do PostgreSQL .
Lado do servidor
Requer SSL
Em postgresql.conf set ssl=on e certifique-se de ter seu arquivo-chave e certfile instalado adequadamente (consulte os documentos e os comentários em postgresql.conf ).
Talvez seja necessário comprar um certificado de uma autoridade de certificação se você quiser que a confiança seja de clientes sem uma configuração especial no cliente.
Em pg_hba.conf use algo como:
hostssl theuser thedatabase 1.2.3.4/32 md5
... possivelmente com "todos" para usuário e / ou banco de dados, e possivelmente com um filtro de endereço IP de origem mais amplo.
Limite os usuários que podem efetuar login, negar login de superusuário remoto
Não permita "all" para os usuários, se possível; você não deseja permitir logins de superusuário remotamente se puder evitar a necessidade.
Limitar direitos dos usuários
Restringir os direitos do (s) usuário (s) que podem efetuar login. Não atribua a eles CREATEDB ou CREATEUSER direitos.
REVOKE the CONNECT de PUBLIC em todos os seus bancos de dados, em seguida, devolva apenas os usuários / funções que devem poder acessar esse banco de dados. (Agrupe usuários em funções e conceda direitos a funções, em vez de diretamente a usuários individuais).
Certifique-se de que os usuários com acesso remoto só possam se conectar aos DBs de que precisam e tenham apenas direitos sobre os esquemas, tabelas e colunas que realmente precisam. Esta é uma boa prática para os usuários locais também, é apenas uma segurança sensata.
Configuração do cliente
Em PgJDBC, passe o parâmetro ssl=true :
To instruct the JDBC driver to try and establish a SSL connection you must add the connection URL parameter ssl=true.
... e instale o certificado do servidor no armazenamento confiável do cliente ou use um certificado de servidor que seja de confiança de uma das CAs no armazenamento confiável integrado do Java, se você não quiser que o usuário tenha que instalar o certificado. / p>
Ação contínua
Agora certifique-se de manter o PostgreSQL atualizado . O PostgreSQL possui apenas algumas brechas de segurança anteriores à autenticação, mas isso é mais do que zero, portanto, mantenha-se atualizado. Você deve, de qualquer forma, correções de bugs são coisas legais para ter.
Adicione um firewall na frente se houver grandes netblocks / regiões de que você sabe que não precisa acessar.
Registrar conexões e desconexões (consulte postgresql.conf ). Log de consultas, se for prático. Execute um sistema de detecção de intrusão ou fail2ban ou similar na frente, se for prático. Para o fail2ban com postgres, há um prático como:
Monitore os arquivos de log.
Paranoia bônus
Passos extras para pensar ...
Requer certificados de cliente
Se desejar, você também pode usar pg_hba.conf para exigir que o cliente apresente um certificado de cliente X.509 confiável pelo servidor. Ele não precisa usar o mesmo CA como o certificado do servidor, você pode fazer isso com um homebrew openssl CA. Um usuário do JDBC precisa importar o certificado do cliente em seu keystore Java com keytool e, possivelmente, configurar algumas propriedades do sistema JSSE para apontar o Java em seu keystore, portanto, não é totalmente transparente.
Coloque em quarentena a instância
Se você quiser ser realmente paranóico, execute a instância do cliente em um contêiner / VM separado, ou pelo menos com uma conta de usuário diferente, apenas com os bancos de dados de que eles precisam.
Dessa forma, se eles comprometerem a instância do PostgreSQL, eles não irão avançar mais.
Use o SELinux
Eu não tenho que dizer isso, mas ...
Execute uma máquina com suporte ao SELinux, como RHEL 6 ou 7, e não desligue o SELinux ou configure-o para o modo permissivo . Mantê-lo em modo de execução.
Use uma porta não padrão
Segurança por somente obscuridade é estupidez. Segurança que usa um pouco de obscuridade uma vez que você tenha feito as coisas sensatas provavelmente não vai doer.
Execute a Pg em uma porta não padrão para tornar a vida um pouco mais difícil para atacantes automatizados.
Coloque um proxy na frente
Você também pode executar o PgBouncer ou o PgPool-II na frente do PostgreSQL, atuando como um pool de conexão e proxy. Dessa forma, você pode deixar o proxy manipular o SSL, não o host do banco de dados real. O proxy pode estar em uma VM ou máquina separada.
O uso de proxies de pool de conexão geralmente é uma boa idéia com o PostgreSQL, a menos que o aplicativo cliente já tenha um pool integrado. A maioria dos servidores de aplicativos Java, Rails, etc, tem pool integrado. Mesmo assim, um proxy de pool do lado do servidor é, na pior das hipóteses, inofensivo.