Requerir SSL, mantener SELinux activado, monitorear los registros y usar una versión actual de PostgreSQL .
Lado del servidor
Requerir SSL
En postgresql.confconjunto ssl=ony asegúrese de tener su archivo de claves y su archivo de certificados instalados adecuadamente (vea los documentos y los comentarios en postgresql.conf).
Es posible que deba comprar un certificado de una CA si desea que los clientes confíen en él sin una configuración especial en el cliente.
En pg_hba.confuso algo como:
hostssl theuser thedatabase 1.2.3.4/32 md5
... posiblemente con "todos" para usuario y / o base de datos, y posiblemente con un filtro de dirección IP de origen más amplio.
Limite a los usuarios que pueden iniciar sesión, denegar el inicio de sesión de superusuario remoto
No permita "todos" para los usuarios si es posible; no desea permitir inicios de sesión de superusuario de forma remota si puede evitar la necesidad de hacerlo.
Limitar los derechos de los usuarios.
Restrinja los derechos de los usuarios que pueden iniciar sesión. No les dé derechos CREATEDBni CREATEUSERderechos.
REVOKEel CONNECTderecho desde PUBLICtodas sus bases de datos, luego devuélvalas solo a los usuarios / roles que deberían poder acceder a esa base de datos. (Agrupe a los usuarios en roles y otorgue derechos a los roles, en lugar de directamente a los usuarios individuales).
Asegúrese de que los usuarios con acceso remoto solo puedan conectarse a las bases de datos que necesitan, y solo tengan derechos sobre los esquemas, tablas y columnas que realmente necesitan. Esta es una buena práctica para los usuarios locales también, es solo una seguridad sensata.
Configuración del cliente
En PgJDBC, pase el parámetrossl=true :
Para indicar al controlador JDBC que intente establecer una conexión SSL, debe agregar el parámetro URL de conexión ssl = true.
... e instale el certificado del servidor en el almacén de confianza del cliente, o use un certificado de servidor en el que confíe una de las CA en el almacén de confianza incorporado de Java si no desea que el usuario tenga que instalar el certificado.
Acción en curso
Ahora asegúrese de mantener PostgreSQL actualizado . PostgreSQL solo ha tenido un par de agujeros de seguridad previos a la autenticación, pero eso es más que cero, así que manténgase actualizado. De todos modos, deberías tener correcciones de errores.
Agregue un firewall al frente si hay grandes bloques de red / regiones de los que sabe que nunca necesita acceder.
Registro de conexiones y desconexiones (ver postgresql.conf). Registro de consultas si es práctico. Ejecute un sistema de detección de intrusos o fail2ban o similar al frente si es práctico. Para fail2ban con postgres, hay un procedimiento práctico aquí
Monitorear los archivos de registro.
Bonus paranoia
Pasos adicionales para pensar ...
Requerir certificados de cliente
Si lo desea, también puede utilizar pg_hba.confpara exigir que el cliente presente un certificado de cliente X.509 en el que confíe el servidor. No necesita usar la misma CA que el certificado del servidor, puede hacerlo con una CA homebrew openssl. Un usuario JDBC necesita importar el certificado del cliente en su Java Keystore keytooly posiblemente configurar algunas propiedades del sistema JSSE para apuntar Java a su almacén de claves, por lo que no es totalmente transparente.
Poner en cuarentena la instancia
Si desea ser realmente paranoico, ejecute la instancia para el cliente en un contenedor / VM separado, o al menos bajo una cuenta de usuario diferente, con solo las bases de datos que requieren.
De esa forma, si comprometen la instancia de PostgreSQL, no avanzarán más.
Use SELinux
No debería tener que decir esto, pero ...
Ejecute una máquina con soporte SELinux como RHEL 6 o 7, y no apague SELinux ni lo configure en modo permisivo . Manténgalo en modo obligatorio.
Use un puerto no predeterminado
La seguridad solo por oscuridad es estupidez. La seguridad que usa un poco de oscuridad una vez que haya hecho las cosas sensibles probablemente no le hará daño.
Ejecute Pg en un puerto no predeterminado para hacer la vida un poco más difícil para los atacantes automáticos.
Pon un proxy al frente
También puede ejecutar PgBouncer o PgPool-II frente a PostgreSQL, actuando como un grupo de conexiones y proxy. De esa manera, puede dejar que el proxy maneje SSL, no el host de la base de datos real. El proxy puede estar en una máquina virtual o máquina separada.
El uso de servidores proxy de agrupación de conexiones es generalmente una buena idea con PostgreSQL de todos modos, a menos que la aplicación cliente ya tenga un grupo integrado. La mayoría de los servidores de aplicaciones Java, Rails, etc. tienen agrupación integrada. Incluso entonces, un proxy de agrupación del lado del servidor es, en el peor de los casos, inofensivo.