DALL·E 2024 02 26 20.31.45 Imagine a 1024x1024 pixels illustration that visualizes the configuration of SSL TLS certificates in PostgreSQL showing the PostgreSQL logo alongside

Certificados TLS y SSL en PostgreSQL

En el mundo digital de hoy, la seguridad de los datos es más importante que nunca.

Con la creciente preocupación por la privacidad y la integridad de la información, asegurarse de que nuestras bases de datos estén protegidas contra accesos no autorizados se ha convertido en una prioridad absoluta.

PostgreSQL, siendo uno de los sistemas de gestión de bases de datos más populares y confiables, ofrece mecanismos robustos para la seguridad de la información.

Entre estos, la configuración de certificados SSL y TLS destaca como una medida esencial para garantizar comunicaciones seguras.

En el artículo de hoy:

  • Desciframos los conceptos de SSL (Secure Sockets Layer) y TLS (Transport Layer Security), su importancia, y cómo estos protocolos protegen los datos que viajan a través de las redes.
  • Exploraremos qué es un certificado digital y el papel vital que juega en la autenticación y el cifrado, asegurando que solo los ojos autorizados puedan ver los datos sensibles.
  • También desentrañaremos el misterio de la ‘capa trust-chain’, o cadena de confianza, que es fundamental para establecer una conexión de confianza entre el servidor y el cliente

¡Empezamos!

TLS, SSL, Certificados y la capa trust-chain

TLS y SSL

TLS (Transport Layer Security), anteriormente llamado SSL (Secure Socket Layer), es un protocolo para el cifrado y la protección de las comunicaciones de red. Tiene 2 funciones principales:

  • Cifrado / descifrado de comunicación + comprobación de integridad
  • Usar certificados para verificar las identidades de ambas partes.

Certificados

También llamado Certificado X509 v3 o simplemente Certificado X509. Es una estructura de datos que contiene información de validez, emisor, extensión, propósito y otra información personalizada.

Se utiliza principalmente para representar la identidad de una entidad y garantizar la confianza. Tiene tres tipos básicos:

  • Autoridad de certificación: También llamado certificado CA o raíz CA. (IdenTrust, DigiCert, GlobalSign, Let’s Encrypt, etc. son CA comunes. También puede ser autofirmado para fines de prueba).
  • Certificado CA intermedio.
  • Certificado de entidad: Es el certificado real utilizado para la comunicación. Se intercambian durante el handshake de TLS.

En la mayoría de los casos, el servidor solo envía su certificado de entidad al cliente para su verificación.

No obstante, se puede dar la situación en la que el cliente también debe enviar su certificado al servidor para verificar. A esto lo llamamos verificación mutua.

Trust Chain

Es uno de los criterios para determinar si un certificado de entidad se puede confiar o no.

Si pudiéramos «establecer» un camino desde este certificado hasta la raíz CA de confianza, entonces el certificado se puede confiar (siempre que no haya caducado).

Este «camino» describe cuántos «firmantes» están involucrados en la emisión de este certificado. Este camino también se llama cadena de confianza.

Ejemplos

Consideremos esta configuración de certificados, donde los certificados de cliente y servidor están firmados por la CA intermedia 1 y 2, ambas emitidas por una CA raíz común.

image 7

Caso 1 – No confianza

Si un cliente y un servidor de PostgreSQL tienen las siguientes configuraciones de certificado, no se confiarán entre sí, porque cada extremo no puede establecer un camino confiable hasta la CA raíz común.

image 8

Caso 2 – Confianza

Si un cliente y un servidor de PostgreSQL tienen la siguiente configuración de certificado, pueden confiar entre sí, porque ambos extremos pueden establecer un camino confiable hasta la CA raíz común:

Certificado de cliente -> CA intermedia 1 -> CA raíz

Certificado de servidor -> CA intermedia 2 -> CA raíz

image 9

Caso 3 – Certificado de entidad intermedia combinada

Hay un caso en el que tanto el cliente como el servidor de PostgreSQL solo tienen el certificado CA raíz configurado como «anchor de confianza».

No tienen ningún certificado CA intermedio configurado, muy probablemente porque ni siquiera saben cuántos hay.

Para garantizar la confianza, podemos agregar de manera alternativa los certificados CA intermedios en el mismo archivo de certificado de entidad (indicado por la línea discontinua debajo) y enviarlo al otro par.

image 10

Esto es importante porque el cliente o el servidor pueden usar el certificado CA intermedio recibido para construir el camino hasta la CA raíz común, y por lo tanto, en el caso siguiente, tanto el cliente como el servidor pueden confiar entre sí.

Únete a la lista de emails para no perderte nada

No tengo ningún producto, publicidad, ni nada que venderte. De hecho, aún no tengo nada que hacer con estos emails. Pero si te interesa estar en contacto o no perderte las próximas actualizaciones en el futuro… Ya sabes 😉

    ¿Quieres trabajar con nosotros?

    Ya sea que necesites mejorar el rendimiento de consultas existentes, planificar y ejecutar migraciones de datos críticas, diseñar bases de datos desde cero o mantener un entorno de base de datos estable, estamos aquí para ayudarte.

    Trabajamos con una amplia variedad de sistemas de gestión de bases de datos (DBMS) y estamos comprometidos en proporcionar soluciones adaptadas a tus necesidades específicas. Puedes consultar nuestra lista completa de servicios aquí.

    Confía en nosotros para optimizar tus bases de datos y liberar tiempo y recursos para que puedas concentrarte en lo que realmente importa: hacer crecer tu negocio.

    ¡Contáctanos hoy mismo y descubre cómo podemos ayudarte a lograr un rendimiento óptimo en tu entorno de bases de datos!


    Comentarios

    Deja una respuesta

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *