¿Puede TLS ser una alternativa segura a VPN?

Sí ... y no ... y posiblemente sí otra vez, si toma precauciones adicionales.

Por qué no

En cuanto a la autenticidad y la confidencialidad, una conexión TLS es perfectamente adecuada. Pero esa no es la única razón por la que las personas ponen servicios como Postgres detrás de una VPN. El otro problema es que es posible que no desee exponer su base de datos al público.

La autenticación VPN sirve como una segunda barrera para los atacantes además de la autenticación incorporada en su base de datos. Si postgres está comprometido o es defectuoso de alguna manera, todavía es razonablemente seguro si su VPN se mantiene.

Pero si expone su base de datos a Internet a través de una conexión TLS estándar, cualquier persona puede atacarla directamente, explotar cualquier falla potencial en el protocolo o autenticación nativa, o consumir recursos en un ataque de denegación de servicio.

Cómo hacerlo seguro de nuevo

Pero la exposición de servicios directamente a través de TLS se realiza en entornos de alta seguridad con una advertencia adicional: debe autenticar al usuario ANTES de exponerlos al servidor backend.

La forma más sencilla de hacerlo es con certificados de cliente. Ya está configurando su propia CA para firmar su certificado de servidor. Si lo usa para firmar también certificados de clientes, y requiere un certificado de cliente firmado para poder conectarse, entonces ha restablecido efectivamente su VPN por conexión.

La configuración del servidor y el cliente para usar certificados de clientes requiere una pequeña cantidad de trabajo, pero está bien dentro de lo razonable, particularmente en comparación con una suite VPN.

Tal solución es tan segura como una VPN, menos complicada y más fácil de implementar.

Sí, es una opción perfectamente razonable. Es lo que hace AWS RDS, Heroku Postgres, etc.

Como cualquier software, PostgreSQL podría tener ataques remotos de autenticación previa. Debe mantenerse actualizado sobre los parches y tener un plan para actualizar a las nuevas versiones. Ejecute en un puerto no predeterminado y, si es posible, limite los rangos de direcciones IP permitidos.

Pero al final no es muy diferente a exponer algo más, como un servidor apache.

Sin embargo :

• PostgreSQL está basado en la sesión. Espera que los clientes se queden y no les gusta si desaparecen sin previo aviso o dejan de responder a la mitad del trabajo. No se estrellará ni fallará, pero hará un trabajo innecesario y la conexión desaparecida puede atar los recursos por un tiempo.

• A menos que sea bastante cuidadoso, el protocolo PostgreSQL realiza muchos viajes de ida y vuelta. Puedes mitigar esto con los modos de proceso por lotes de PgJDBC o nPgSQL, y también envié un parche a libpq para agregar un modo de proceso por lotes. Pero esta latencia afectará el rendimiento.

• PostgreSQL realiza más trabajos de autenticación previa que algunos sistemas, y las conexiones de autorización previa cuentan contra el límite en el número máximo de conexiones. Así que es algo susceptible a DoS.

Los dos primeros problemas también se aplican si estás usando una VPN, no son exclusivos del uso basado en TLS.

Por estos motivos, puede valer la pena ejecutar un servidor de aplicaciones cercano a la base de datos PostgreSQL y agrupar las solicitudes de datos de aplicaciones en formularios estructurados con las solicitudes y respuestas de json / protobuf / any. Esto es más útil cuando los clientes están muy dispersos y pueden ir y venir al azar.

Si no va a hacer eso, establezca tiempos de espera cortos en todo en Pg, prepárese para hacer frente a los reintentos, intente usar lotes e intente agrupar el trabajo en consultas más grandes en lugar de en muchas pequeñas.

¿Qué tan sensibles son los datos? Usted no dijo Eso hace que sea imposible calcular cuál es el nivel apropiado de riesgo. Eso es crucial. "Lo suficientemente seguro" siempre es relativo al riesgo y su presupuesto para el proyecto.

Esto suena como una de esas situaciones de "probar que algo no existe". Lógicamente, eso es imposible de hacer. Solo puedes probar cuando algo existe existe. Así que no voy a tener éxito. Pero, de todos modos, intentaré convencerlo de que para datos típicos, "el acceso directo seguro a las bases de datos para usuarios no confiables" realmente no existe.

La conexión es solo una parte del problema del "acceso seguro". Supongamos que ha tratado con todas las posibles vulnerabilidades de negociación, así como otras. Incluso si la conexión está cifrada con un conjunto criptográfico TLS libre de errores que está correctamente configurado, ¿qué datos son los usuarios no confiables que envían a través de o antes del canal cifrado, incluido (como Craig Ringer mencionado) autenticación? ¿Lo estás limpiando antes de que llegue a la base de datos?

Obviamente, se requieren parches, pero no lo suficientemente remotos. Para una base de datos que podría tener personas explotándola en cualquier momento, incluidos los datos de otros usuarios en la base de datos, probablemente querría DAM (auditoría y monitoreo de la base de datos) y protección de IPS y DoS para aplicaciones. Hay una razón por la que la mejor práctica es poner la base de datos detrás de una puerta de enlace de algún tipo, y no exponerla directamente de esa manera.

La ejecución en un puerto no predeterminado es la seguridad a través de la ofuscación. No detendrá a nadie que sepa cómo ejecutar un escáner de puertos y la toma de huellas dactilares, y definitivamente no a nadie que lo esté apuntando. Dado que no confías en tus usuarios, probablemente deberías asumir que uno está apuntando a ti.

Las limitaciones del rango de IP tampoco serán útiles si no confías en ninguna IP de usuario. Los hosts de confianza son útiles solo para permitir IP confiables y bloquear el resto ... que en su caso suena como bloquear todas las IP en Internet. No es muy útil.

Suponiendo que haya manejado todo eso, lo que sugeriría es transacciones, copias de seguridad y cifrado enérgico de los datos de cada usuario dentro de la base de datos con sus propias claves privadas que su servidor no tiene acceso a, por lo que incluso si un usuario malintencionado comprometiera la base de datos, un volcado de datos de otros usuarios sería básicamente inútil para el atacante. Tenga una VM de servidor en espera lista para funcionar en todo momento, y no estaría de más tener un almacenamiento separado para que pueda deshacerse periódicamente de esa VM y abrir una nueva. Eso no evitaría que alguien sea el propietario del servidor, pero al menos ayudaría a proteger los datos en sí y ofrecería una rápida respuesta y recuperación de incidentes.

Pero eso es incluso antes de que entres en los detalles específicos de PostgreSQL.

Como puede ver, una seguridad más fuerte se vuelve costosa y consume mucho tiempo. Si los datos son garabatos de gato en servilletas, probablemente no valga la pena. Le serviría un mejor método de acceso.

La seguridad de transporte, como TLS, VPN o SSH, se usa para asegurar usuarios de confianza cuando se conecta a través de una red que no es de confianza . No pueden proteger los sistemas de usuarios que no son de confianza.

Si tiene usuarios que no son de confianza y necesitan acceso a la base de datos, la forma tradicional de hacerlo de manera segura es envolver la base de datos en una capa de aplicación. La capa de aplicación implementa autenticación (por ejemplo, nombre de usuario / contraseña, tokens secretos compartidos, certificados de cliente), autorizaciones, consultas y permisos predefinidos (por ejemplo, "quién tiene permiso para ejecutar qué consultas con qué parámetro" o "quién tiene permiso para modificar qué datos bajo qué condiciones "), y el formato de salida (por ejemplo, JSON, CSV, HTML). Opcionalmente, la capa de aplicación también puede implementar la interfaz de usuario. En la práctica moderna, esto suele ser una aplicación web basada en navegador o una API web.

En algunos casos, puede implementar esto utilizando procedimientos almacenados y restringir los usuarios de su base de datos para que solo puedan llamar a procedimientos almacenados, pero esto puede ser bastante complicado cuando comienza a necesitar permisos complicados y formatos de salida.