TLS, la entrada de red y los privilegios SQL responden a preguntas distintas
Cifrar una conexión, admitir un origen y conceder una tabla son tres decisiones. Recórralas en orden antes de preguntar si TLS puede sustituir a una VPN.
Alguien propone entregar a un cliente un inicio de sesión de PostgreSQL para que una solicitud de gastos viaje cifrada de extremo a extremo. Un administrador de bases de datos necesita una sesión SQL real, y otra persona propone en su lugar un formulario web. Ambas propuestas resuelven el problema equivocado, porque ninguna partió de la operación que el cliente realiza realmente. Recorra las tres decisiones en orden y la pregunta sobre si TLS puede sustituir a una VPN se responde sola.
Empiece por la operación que necesita el cliente
Anote qué debe lograr el cliente. Enviar una solicitud, leer una fila de un informe y ejecutar una consulta ad hoc son tres operaciones distintas con tres perfiles de riesgo distintos.
Después anote quién hace la petición. Un cliente, un agente de soporte y un administrador no son intercambiables aunque toquen la misma tabla. La diferencia decide cuánto del lenguaje de consultas debería ver alguna vez el cliente.
El par de respuestas decide la interfaz. Todo lo posterior es implementación, y la mayoría de las discusiones sobre cifrado son en realidad discusiones sobre qué interfaz se eligió.
Tres controles, tres decisiones
TLS autenticado protege la conexión y decide qué identidades TLS se aceptan. La entrada de red decide qué orígenes pueden llegar siquiera al proceso que escucha. La autorización de la base de datos decide qué objetos y acciones puede usar un rol.
Ninguno de los tres sustituye a los demás, lo que la tabla hace explícito.
| Control | What it decides | What it leaves open |
|---|---|---|
| Authenticated TLS | Connection protection and which TLS identities are accepted | Which tables a database user may touch |
| Restricted network entry | Which sources reach the listener | Whether an authenticated user should run a given statement |
| Database authorization | Which objects and actions a role may use | Whether the connection arrived by an approved path |
Lea la fila en la que se apoya antes de quitar otra. La mayoría de estos diseños fallan porque un control se supuso en lugar de configurarse.
El SQL directo mantiene al mando la política de la base de datos
Con una conexión directa aprobada, conserve tanto la verificación de la identidad del servicio como la política de acceso prevista. Activar TLS pone a disposición las conexiones cifradas; no rechaza las no cifradas salvo que la configuración de acceso lo exija mediante entradas hostssl.
Esa distinción merece comprobarse en la configuración en ejecución y no en una plantilla. Un servidor que ofrece TLS y acepta texto plano no es el diseño que la mayoría cree haber desplegado. Lea las reglas de acceso y vea qué entradas lo exigen realmente. Esa única comprobación separa un servidor capaz de cifrar de uno solo cifrado.
Use roles solo con los privilegios que el trabajo necesita, y revise la propiedad, la pertenencia heredada y los permisos concedidos de forma amplia. El modelo de privilegios de PostgreSQL es el límite de autoridad para los objetos de la base de datos.
Una VPN puede restringir qué dispositivos llegan al servicio antes de que ocurra la autenticación de la base de datos, y una pasarela de acceso puede hacer algo parecido. Ninguna de las dos elimina la necesidad de mantener el componente expuesto, gestionar credenciales y limitar el uso de recursos.
Los certificados de cliente son una credencial, no una ACL
Un certificado de cliente puede añadir un requisito en el momento de la conexión. El parámetro clientcert puede exigir un certificado de confianza y, en el modo más estricto, una relación entre el nombre del certificado y el usuario de la base de datos.
Eso es una credencial más fuerte. No es una lista de autorización, y no hace invisible el servidor, porque el componente que acepta la conexión sigue procesando tráfico de red y un saludo. Tratar un certificado como una lista de acceso deja intactos los permisos reales. También tiende a ampliar la distribución de certificados, lo que crea el problema siguiente.
Un certificado fuerte unido a un rol con privilegios excesivos produce un administrador bien autenticado. Revise el rol antes de celebrar el certificado.
Elija la interfaz más estrecha cuando encaje
Para una solicitud de gastos, un punto final de aplicación que acepta la solicitud, aplica las reglas de negocio y devuelve el resultado permitido de ese usuario representa la operación mejor que una cuenta SQL general.
La aplicación usa después su propia identidad restringida en la base de datos, y el cliente nunca recibe un lenguaje de consultas como funcionalidad. Esa es una superficie más pequeña con menos formas de equivocarse.
Esta es una opción de diseño y no la afirmación de que el código de aplicación sea automáticamente más seguro. Ese código tiene que autenticar a sus llamantes, autorizar cada acción y validar su entrada, y sus propios permisos en la base de datos siguen importando.
El SQL directo sigue siendo correcto para personas y herramientas cuyo trabajo aprobado lo requiere. Cualifique ese diseño con roles, alcance de red y límites operativos, y deje que los demás clientes mantengan la interfaz más estrecha. Mezclar las dos poblaciones en un solo rol es donde empiezan las discusiones.