La seguridad de los datos es un aspecto importante de toda plataforma de datos moderna. Con las arquitecturas basadas en microservicios convirtiéndose en un patrón común en todas las aplicaciones a gran escala, los mecanismos de autenticación basados en contraseñas existentes para la autenticación de usuarios son difíciles de gestionar a escala, por no hablar del hecho de que las contraseñas son difíciles de recordar o podrían ser descifradas. Como remedio, Couchbase Server 5.0 introdujo la autenticación por certificado X.509.
Servidor Couchbase 5.5 añade otras mejoras para soportar todos los servicios e interfaces incluyendo N1QL, Indexación, XDCR, Búsqueda, e incluso la Web UI de Couchbase y los endpoints REST.
¿Qué es la autenticación basada en certificados?
En pocas palabras, la "autenticación" es el proceso de verificar que un usuario es quien dice ser. En el mundo de la tecnología esto puede conseguirse de varias maneras. La autenticación basada en certificados permite a los usuarios acceder de forma segura a un servidor intercambiando un certificado digital en lugar de un nombre de usuario y una contraseña. Esto significa que el cliente no está enviando un nombre de usuario o contraseña al servidor que ayuda en evitar el phishing, el registro de pulsaciones y los ataques de intermediario (MITM), entre otros problemas habituales de la autenticación basada en contraseñas.
Intercambio TLS cliente-servidor que ilustra la autenticación mutua
La autenticación basada en certificados se construye aprovechando el estándar X.509 de infraestructura de clave pública (PKI). La autenticación por certificado ofrece una mayor seguridad al autenticar mutuamente tanto al cliente, utilizando una parte de confianza (la Autoridad de Certificación (CA)) como al servidor durante el handshake TLS. Dado que el certificado está firmado, sólo es posible conectarse al servidor real, y gestionar de forma centralizada los certificados utilizando la CA para su rotación o revocación.
Identificación del usuario en un certificado
Si te estás preguntando cómo funciona la autenticación de certificados x509, tiene que tener múltiples campos como fecha de caducidad, nombre CN, nombre san, etc. Dependiendo de su organización y sus políticas, se utilizarán diferentes campos para codificar el nombre/id de usuario. Por ejemplo:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
Certificado: Datos: Versión: 3 (0x2) Serie Número: 2 (0x2) Firma Algoritmo: sha1ConEncriptaciónRSA Emisor: O=www.freelan.org, OU=freelan Validez No Antes de: Abr 27 10:54:40 2012 GMT No En : Abr 25 10:54:40 2022 GMT Asunto: OU=freelan, CN=couchbase-bob/dirección de correo electrónico=bob@freelan.org Asunto Público Clave Información: Público Clave Algoritmo: rsaEncryption Público-Clave: (4096 bit) Módulo: ... ... |
Para identificar al usuario, Couchbase está configurado para analizar uno o más campos y extraer el usuario. Para ello se utiliza una ruta, un prefijo y un delimitador. La dirección ruta describe de qué parte del certificado debe obtenerse el nombre de usuario, la opción prefijo elimina el principio del nombre de usuario y el delimitador termina el nombre de usuario. En el ejemplo anterior, para extraer un usuario llamado "bob" que utilizarías:
1 2 3 |
"camino": "asunto.CN" "prefijo": "couchbase-" "delimitador": "/" |
Hay un límite máximo de 10 expresiones de ruta en Couchbase, sin que dos expresiones tengan los mismos campos de ruta y prefijo, y es obligatorio especificar todos los campos en la expresión. Couchbase prueba cada expresión de ruta en el certificado una por una en el orden especificado, y utiliza la primera que puede extraer con éxito una cadena de nombre de usuario no vacía. Si todas las expresiones de ruta no pueden extraer la cadena de usuario, los esfuerzos de autenticación con certificados X.509 también fallarán.
Configuración de Couchbase Server
En Couchbase Server 5.5, la autenticación basada en certificados está desactivada por defecto, confiando en su lugar en los métodos de autenticación local usuario/pass o LDAP/PAM.
Cuando "Require Client Certificate" está en "Enable", Couchbase Server aceptará el certificado suministrado e intentará autenticarse basándose en él. Si falla, Couchbase Server recurrirá a los métodos de autenticación usuario/pass o LDAP/PAM.
Cuando "Require Client Certificate" está configurado como "Obligatorio", se debe proporcionar un certificado X.509 o, de lo contrario, la autenticación fallará.
Estos ajustes también pueden suministrarse a través de la CLI o la API REST.
Autorizar al usuario
Una vez que un usuario se ha "autenticado" (es quien dice ser), aún necesita ser "autorizado", que es el proceso de determinar qué puede hacer.
En Couchbase Server esto se hace mediante asignar una o varias funciones a cada usuario.
Configuración de clientes para la autenticación basada en certificados
La función de autenticación basada en certificados X.509 es compatible con todos los clientes SDK. Sin embargo, sólo las versiones más recientes la admiten, por lo que debe consultar las notas de la versión de su SDK..
X.509 es el estándar oficial para certificados de clave pública y SSL/TLS se basa en este estándar. En su cliente, debe utilizar un certificado x.509 válido generado y firmado por la misma autoridad de certificación (CA) raíz que el servidor.
La mayoría de los navegadores web soportan la autenticación de cliente desde los primeros días de TLS. Puedes configurar el certificado del cliente en el almacén de certificados de tu navegador y ¡listo!
Todas las herramientas de Couchbase como couchbase-cli, y el shell N1QL también se están actualizando para soportar la autenticación X.509.
Conclusión
Aunque es un poco laborioso configurar este tipo de autenticación, es muy seguro y más sencillo de gestionar a escala. Por favor, descargar Couchbase Server 5.5 para probarlo. Esperamos sus comentarios.
Información útil. ¿Está MA-SSL soportado también en Couchbase server 4.5?
Hola Vidhya, ¡gracias por tu comentario!
MA-SSL no sería soportado antes de la versión 5.5 ya que no soportamos _autenticación_ vía certificados, sólo encriptación.
Espero que eso ayude.
Perry