Exija SSL, mantenha o SELinux ativado, monitore os logs e use uma versão atual do PostgreSQL .
Lado do servidor
Exigir SSL
Em postgresql.confset ssl=one verifique se você possui o arquivo de chave e o arquivo de certificação instalados adequadamente (consulte a documentação e os comentários em postgresql.conf).
Pode ser necessário comprar um certificado de uma CA se você deseja que ele seja confiável por clientes sem configuração especial no cliente.
Em pg_hba.confuso, algo como:
hostssl theuser thedatabase 1.2.3.4/32 md5
... possivelmente com "all" para usuário e / ou banco de dados e possivelmente com um filtro de endereço IP de origem mais amplo.
Limite de usuários que podem efetuar login, negar login remoto de superusuário
Não permita "todos" 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
Restrinja os direitos do (s) usuário (s) que podem efetuar login. Não dê a eles CREATEDBou CREATEUSERdireitos.
REVOKEà CONNECTdireita PUBLICem todos os seus bancos de dados e devolva-os apenas aos usuários / funções que devem poder acessar esse banco de dados. (Agrupe usuários em funções e conceda direitos a elas, em vez de diretamente a usuários individuais).
Verifique se os usuários com acesso remoto podem conectar-se apenas aos bancos de dados de que precisam e ter apenas direitos aos esquemas, tabelas e colunas dentro dos quais realmente precisam. Essa é uma boa prática para usuários locais também, é apenas uma segurança sensata.
Configuração do cliente
No PgJDBC, passe o parâmetrossl=true :
Para instruir o driver JDBC a tentar estabelecer uma conexão SSL, você deve adicionar o parâmetro da URL de conexão ssl = true.
... e instale o certificado do servidor no armazenamento confiável do cliente ou use um certificado de servidor confiável por uma das CAs no armazenamento confiável interno do Java, se você não quiser que o usuário precise instalar o certificado.
Ação em andamento
Agora, certifique-se de manter o PostgreSQL atualizado . O PostgreSQL teve apenas algumas falhas de segurança pré-autenticação, mas isso é mais que zero, portanto, fique atualizado. Seja como for, correções de bugs são coisas boas de se ter.
Adicione um firewall na frente se houver grandes blocos de rede / regiões das quais você sabe que nunca precisa acessar.
Conexões e desconexões de log (consulte postgresql.conf). Registre consultas, se possível. Execute um sistema de detecção de intrusão ou fail2ban ou similar na frente, se possível. Para fail2ban com postgres, há um guia prático aqui
Monitore os arquivos de log.
Paranoia de bônus
Passos extras para pensar ...
Exigir certificados de cliente
Se desejar, também é possível pg_hba.confexigir que o cliente apresente um certificado de cliente X.509 confiável pelo servidor. Ele não precisa usar a mesma autoridade de certificação que o certificado do servidor; você pode fazer isso com uma autoridade de certificação openssl homebrew. Um usuário JDBC precisa importar o certificado do cliente para seu Java Keystore keytoole, possivelmente, configurar algumas propriedades do sistema JSSE para apontar Java para seu keystore, para que não seja totalmente transparente.
Colocar a instância em quarentena
Se você quiser ser realmente paranóico, execute a instância do cliente em um contêiner / VM separado ou, pelo menos, em uma conta de usuário diferente, apenas com os bancos de dados necessários.
Dessa forma, se eles comprometem a instância do PostgreSQL, não avançam mais.
Use o SELinux
Eu não deveria ter que dizer isso, mas ...
Execute uma máquina com suporte ao SELinux, como o RHEL 6 ou 7, e não desligue o SELinux ou configure-o para o modo permissivo . Mantenha-o no modo de imposição.
Use uma porta não padrão
Segurança apenas pela obscuridade é estupidez. A segurança que usa um pouco de obscuridade depois que você faz as coisas sensatas provavelmente não fará mal.
Execute a página em uma porta não padrão para tornar a vida um pouco mais difícil para invasores 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 real do banco de dados. 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 embutido. A maioria dos servidores de aplicativos Java, Rails, etc. possui pool integrado. Mesmo assim, um proxy de pool no servidor é, na pior das hipóteses, inofensivo.