Entendiendo TLS dentro de Couchbase Server
En Parte 1 y Parte 2 de esta guía, explicamos la historia de TLS, los componentes involucrados y cómo funciona. En esta 3ª parte final de la guía combinamos todo esto y aprendemos cómo funciona TLS en Couchbase Server.
Certificados de clúster Couchbase
En Couchbase Server, un certificado de cluster vincula todo a una o más Autoridades de Certificación (CAs) de confianza; no maneja directamente la encriptación de la base de datos. En su lugar, establece una cadena de confianza para los certificados por nodo dentro del clúster.
Todas las partes confiantes en el despliegue de Couchbase Server deben tener el Certificado de Cluster instalado y de confianza. Igual que en el ejemplo anterior con el navegador web teniendo CAs raíz de confianza, en un despliegue de Couchbase cada Nodo de Couchbase Server y cada aplicación conectada usando uno de los SDKs debe confiar en el Certificado de Cluster. También se importa a Clusters de Servidores Couchbase adicionales que usan la característica de replicación entre centros de datos (XDCR) para replicar datos entre los clusters de forma segura.
En Couchbase Capella, nuestra oferta de Base de Datos como Servicio (DBaaS), todos los clusters usan la misma autoridad de certificación, y por lo tanto todos usan el mismo Certificado de Cluster. Y, desde principios de 2022, todos los SDKs oficiales de Couchbase lanzados desde entonces han incluido, por defecto, la confianza automática en el Certificado de Cluster de Capella.
Certificados de nodo para cifrado de red
Los Certificados de Nodo y las claves privadas por nodo son el componente principal responsable de la encriptación de red en Couchbase Server. Los Certificados de Nodo son creados por una Autoridad Certificadora (CA) de confianza y son firmados por la Clave Privada de la CA (también conocida como la Clave Privada asociada con la Clave Pública/Cert del Cluster).
Este es el proceso de creación de un Certificado de Nodo Couchbase.
-
- Se solicita una Solicitud de Firma de Certificado (CSR) a la Autoridad de Certificación con una Clave Pública de Nodo incrustada.
- Se crea el Certificado del Nodo, incluyendo la Clave Pública del Nodo incrustada y ésta se firma utilizando la Clave Privada del Cluster en el propio sistema CA.
- El certificado de nodo se devuelve al solicitante.
Estos certificados facilitan la comunicación segura entre nodos del servidor Couchbase y permiten la conectividad encriptada con nodos individuales del servidor Couchbase desde SDKs. Los puntos clave sobre los certificados de nodo incluyen:
Cifrado de nodo a nodo: Los certificados de nodo aseguran los canales de comunicación entre los nodos del servidor Couchbase, salvaguardando los datos mientras viajan dentro del clúster.
Conectividad SDK: Cuando los SDKs se conectan a nodos individuales del servidor Couchbase, los certificados de nodo aseguran que la comunicación está encriptada, manteniendo la confidencialidad de los datos.
Acceso a la interfaz gráfica de administración a través de HTTPS: Utilizando el certificado de nodo, los administradores pueden acceder de forma segura a la interfaz gráfica de usuario (GUI) del Servidor Couchbase a través de HTTPS.
Si miramos un ejemplo de cómo un SDK hace una conexión encriptada a un nodo del Servidor Couchbase, verás los varios componentes trabajando. Intencionalmente he omitido algunos detalles, para mantenerlo algo simple.
El SDK realizará estos pasos con cada Nodo del Servidor Couchbase a través del cluster con el que establezca una conexión TLS.
Ejemplo de configuración de TLS en Couchbase Server
En esta sección configuraremos la encriptación de red TLS en un cluster de 3 nodos de Couchbase Server, ejecutando la versión 7.2.0 en hosts Linux. También hay un cuarto host Linux utilizado como Autoridad de Certificación.
Clave privada de clúster + certificado
Inicie sesión en el host de la Autoridad de Certificación, aquí es donde crearemos el certificado de clúster.
Esto es sólo un host Linux que tiene instalada una versión actual de OpenSSL.
Primero crearemos un archivo de plantilla Couchbase que se utilizará más adelante para los certificados por nodo.
| Comando (sin salida) | ||
|
El siguiente paso será crear la Clave Privada de Cluster encriptada, denominada cluster_private.key.
Ejecute el siguiente comando, se le pedirá una frase de contraseña para cifrar esta clave.
La clave privada estará en formato PKCS8 (PKCS #8) y cifrada con el muy seguro 265 bit Estándar de cifrado avanzado (AES).
| Comando | ||
|
||
| Salida | ||
|
Puedes validar que es una clave privada encriptada, mirando al principio del archivo.
| Comando | ||
|
||
| Salida | ||
|
Ahora crearemos el certificado del clúster en formato PEM x.509. En nuestro caso, el certificado será autofirmado, lo que significa que no será avalado por ninguna otra autoridad. Esto significa que puede crearse directamente, basándose en la clave privada existente clave.casin ayuda de terceros.
Cuando creamos el certificado de clúster, válido durante 3650 días (10 años), tendrá una clave pública de clúster incrustada en el certificado que es el par correspondiente de la clave cluster_private.key realizada anteriormente. Tendrá que proporcionar la frase de contraseña que introdujo anteriormente para descifrar ahora la clave privada para este comando.
| Comando | ||
|
||
| Salida | ||
|
Ahora podemos imprimir el contenido del nuevo archivo cert (y ver también la clave pública).
| Comando | ||
|
||
| Salida | ||
|
Ahora tenemos el Certificado de Cluster (cluster_cert.pem), este archivo necesita ser copiado a cada Nodo del Servidor Couchbase en el cluster. También necesita ser añadido a cada aplicación desde la que operen los SDKs así como a cualquier host desde el que los administradores accedan a la UI, como el portátil de un administrador. No es un archivo sensible y sólo contiene información pública.
Clave privada del nodo + CSR
Los pasos de esta sección deberán repetirse para cada Nodo del Servidor Couchbase:
-
- Inicie sesión en el nodo del servidor Couchbase.
- Ejecute los siguientes comandos en un directorio temporal, inaccesible para otros usuarios del sistema.
Primero vamos a crear la clave privada del nodo1, en formato PKCS1 (PKCS #1)
| Comando | ||
|
||
| Salida | ||
|
A continuación vamos a crear la Solicitud de Firma de Certificado (CSR) para Nodo1, utilizando el comando nodo1 clave privada. Recuerde que en el CSR se incrustará una clave pública.
| Comando (Sin salida) | ||
Este CSR y su clave pública incrustada ya pueden verse y verificarse. |
| Comando | ||
|
||
| Salida | ||
|
Ahora copie el archivo CSR, cbnode1.csral sistema CA. Sólo contiene información pública y no es sensible.
Crear certificados de nodo
Inicie sesión en el sistema CA, ahora debería tener los archivos CSR para cada Nodo del Servidor Couchbase en el cluster localizado en el sistema CA, cbnode1.csr, cbnode2.csr, etc.
Para cada Nodo del Servidor Couchbase, necesitarás crear un archivo de plantilla. El archivo de plantilla creado anteriormente, cbserver.extserá personalizado para cada nodo. Ejecute este comando para cada Nodo del Servidor Couchbase, reemplazando el nombre de host DNS del Nodo del Servidor Couchbase y el nombre de archivo según sea necesario. Esto configurará el Subject Alternative Name (SAN) para que coincida con el nombre del Nodo Servidor Couchbase.
Si utiliza nombres de host para Couchbase Server, ejecute este comando:
| Comando (sin salida) | ||
|
Alternativamente, si utiliza direcciones IP sin nombres de host para Couchbase Server, ejecute esto:
| Comando (sin salida) | ||
Ahora deberías tener archivos de plantilla para cada Nodo del Servidor Couchbase en el cluster, cbnode1.ext, cbnode2.ext, cbnode3.ext, etc. |
Ahora generaremos los certificados, válidos por 3 meses, para cada Nodo del Servidor Couchbase. Estos estarán en formato PEM x.509. Ejecute este comando para cada nodo, cambiando los nombres de archivo. Cada vez que se ejecute, se te pedirá la contraseña de tu CA para encriptar los certificados. cluster_private.key antes.
| Comando | ||
|
||
| Salida | ||
|
Copie cada archivo de certificado de la Autoridad de Certificación a cada Nodo del Servidor Couchbase al que pertenezcan. Por ejemplo, copie nodo1_cert.pem en Couchbase Server Nodo 1 y nodo2_cert.pem en Couchbase Server Node 2.
Cargar los certificados en Couchbase Server
Estos pasos deberán realizarse en cada Nodo del Servidor Couchbase
Inicie sesión en el nodo del servidor Couchbase, debe tener una carpeta que tiene 3 archivos.
-
- Certificado Cluster, cluster_cert.pem
- Certificado (público) del nodo, nodo1_cert.pem
- Clave privada del nodo, cbnode1_private.key
Ya no necesita el archivo CSR creado anteriormente.
Ahora necesitas mover los archivos a la ubicación correcta, con la convención de nomenclatura correcta para Couchbase Server. Ten en cuenta que el mismo nombre de archivo de destino se utiliza en cada Nodo del Servidor Couchbase, pero cada nodo tiene archivos únicos para el archivo cadena.pem y pkey.key.
| Comando | ||
|
Ahora todos los archivos correctos están listos para ser importados a la configuración del Servidor Couchbase.
Empiece cargando el certificado del clúster:
| Comando | ||
|
||
| Salida | ||
|
A continuación cargue el Certificado de Nodo y la Clave Privada, y observe que no se imprimen advertencias:
| Comando | ||
|
||
| Salida | ||
|
Ahora puedes usar conexiones TLS a tu Cluster de Servidores Couchbase.
Confiar en el certificado del clúster
Admin portátil
Inicie sesión en el ordenador portátil de un administrador. En este caso estoy usando un Mac, pasos similares se pueden realizar para máquinas Windows y Linux.
| Comando en MacOS (sin salida) | ||
|
SDK de aplicaciones
Usaremos una aplicación Java para conectarnos a Couchbase Server, en este ejemplo apuntaremos la aplicación al Certificado de Cluster. Otra opción sería utilizar el almacén de confianza cacerts de la JVM, ya que el SDK confiará automáticamente en cualquier CA definida allí. Cada lenguaje de programación tendrá su propia forma preferida de confiar en un certificado CA.
|
1 2 3 |
Cadena connectionString = "couchbases://ejemplo.com" + "?security.trustCertificate=/ruta/a/cluster_cert.pem"; Grupo grupo = Grupo.conecte(connectionString, nombre de usuario, contraseña); |
Cargar la dirección UI encriptada por defecto para uno de los nombres de host de tu nodo desde un portátil de administrador. Esto debería cargar sin ninguna advertencia: https://node1.cb.acme.com:18091/
Del mismo modo, puede realizar conexiones cifradas TLS desde su aplicación a la base de datos.
Recuerde crear y desplegar nuevas claves/certificados por nodo antes de que expiren los 90 días siguiendo de nuevo estos pasos.
Temas avanzados de TLS
Aunque los pasos descritos hasta ahora son adecuados para la mayoría de las aplicaciones, Couchbase Server ofrece algunas capacidades adicionales para requisitos más complejos. Éstas están cubiertas en el blog Claves privadas encriptadas y multi-CA, mejoras de seguridad empresarial en Couchbase Server 7.1
Múltiples autoridades de certificación en Couchbase Server
En lugar de incluir un único certificado como certificado de clúster (cluster_cert.pem / ca.pem), se pueden concatenar varios certificados en el archivo. Esta es una gran opción para tener autoridades de certificación redundantes o para realizar la migración de una autoridad de certificación a otra sin ningún tiempo de inactividad.
Claves privadas de nodo cifradas
Al igual que hicimos con la clave privada del clúster, la clave privada (pkey.key) que reside en cada Nodo del Servidor Couchbase también puede ser opcionalmente encriptado con una frase de contraseña para que sólo sea legible por personas y sistemas que tengan la autoridad correcta para hacerlo.
Conclusión
Los certificados TLS y su correcta configuración son fundamentales para establecer comunicaciones seguras en Couchbase Server. Entender el papel de los certificados de cluster, la importancia de los certificados de nodo, y la implicación de las Autoridades de Certificación (CAs) capacita a los administradores para implementar medidas de seguridad robustas. Además, familiarizarse con los Subject Alternative Names (SAN) mejora la flexibilidad en el despliegue de certificados a través de múltiples dominios o subdominios. Siguiendo las pautas presentadas en esta guía, los administradores pueden fortificar la seguridad de sus despliegues de Couchbase y salvaguardar los datos sensibles de accesos no autorizados.
Gracias por seguir esta serie, esperamos que haya disfrutado de la visita guiada.
