Mecánica de certificados

1. Introducción

Este documento define los requisitos de dominios y certificados SSL/TLS necesarios para desplegar la plataforma Anjana Data en distintos modelos de despliegue (SaaS Full, SaaS híbrido, On-Premise o IaaS/PaaS), incluyendo:

• Tipos de certificados aceptados.

• Dominios requeridos según el modelo de despliegue.

• Responsabilidades del cliente.

• Estándares técnicos mínimos (CA, claves, formatos).

• Procedimiento seguro de entrega e instalación.

2. Conceptos clave

• CA (Certificate Authority): Entidad que emite y firma certificados digitales verificando la identidad del solicitante.

• CSR (Certificate Signing Request): Solicitud de firma que contiene la clave pública y la información del dominio a certificar.

• Certificado autofirmado: Certificado firmado por su propio emisor, no verificado por una CA pública.

• Certificado wildcard: Certificado que cubre un conjunto de subdominios bajo el mismo dominio principal (por ejemplo, *.entorno.anjanadata.net).

• Truststore / Keystore: Almacén de confianza donde se guardan las CAs de confianza. Los emisores de los certificados son validados contra esta lista de CAs.

• Fullchain: certificado del(los) dominio(s) final(es) + certificados intermedios. Toda la cadena de certificados desde el certificado perteneciente al dominio que se emite hasta el certificado raíz de la entidad certificadora.

3. Modelos de despliegue

3.1. On-Premise, IaaS, PaaS

El cliente tiene instalada toda la plataforma Anjana Data en su infraestructura, incluyendo:

• Core

• Microservicios

• Máquina de Plugins

3.2. SaaS Híbrido

El Core y los microservicios se ejecutan en SaaS de Anjana Data SL, y esta se encarga de gestionar íntegramente los certificados, dominios (así como su ciclo de vida) exclusivamente para su infraestructura.
El cliente tiene instalada en su infraestructura únicamente la Máquina de Plugins. El cliente es responsable de gestionar íntegramente los certificados, dominios asociados a la máquina (así como su ciclo de vida).

3.3. Full SaaS

Anjana Data Platform se encuentra íntegramente instalada en infraestructura de Anjana Data SL, y es esta quien gestiona íntegramente los certificados, dominios y ciclo de vida.
Los certificados están firmados bajo el dominio corporativo anjanadata.net.

4. Requisitos de dominios y certificados por modelo

4.1. On-Premise, IaaS y PaaS

Para este tipo de despliegue se requiere un (1) certificado wildcard por cada entorno habilitado para el dominio base unificado.

Ejemplo:

4.2. SaaS Híbrido

El cliente es únicamente responsable de la Máquina de Plugins On-Premise, IaaS o PaaS. Se requiere un (1) certificado wildcard por cada entorno habilitado para este componente.

Ejemplo:

5. Limitación y requisito del certificado Wildcard

5.1. Aclaración: Requisito del certificado wildcard

Anjana Data SL no gestiona por defecto certificados firmados por entidades no reconocidas; se utilizan certificados de tipo wildcard (*.dominio.cliente.com) pero no un certificado para el dominio raíz (*.cliente.com). Nos basamos en la siguiente normativa.

• Arquitectura de Anjana Data Platform: La plataforma se basa en microservicios, donde cada servicio se expone en su propio subdominio (ej. kerno1server.anjana.cliente.com, horus1server.anjana.cliente.com, …).

• Limitación del Certificado Raíz: Un certificado wildcard emitido solo para el dominio raíz (ej. *.cliente.com) no da cobertura a los subdominios que se monten sobre el dominio de Anjana Data Platform.

• Función del Wildcard: Un certificado wildcard estándar (ej. *.anjana.cliente.com) está diseñado para cubrir un solo nivel de subdominios, que es exactamente la arquitectura que utiliza Anjana Data Platform.

5.2. Riesgo de exposición de clave privada

Entregar el par (.crt + .key) de un wildcard raíz como *.cliente.com implica que cualquiera con acceso a la clave privada podría:

• Suplantar cualquier subdominio del cliente.

• Levantar servidores falsos (login.cliente.com, api.cliente.com…) sin detección.

• Realizar ataques Man-in-the-Middle y phishing indistinguibles de los originales.

5.3. Violación de principios de segregación de responsabilidades

Entregar certificados corporativos raíz a un proveedor:

• Cede parte de la identidad digital de la organización.

• Rompe el principio de separación de roles y seguridad por diseño.

• Permitiría técnicamente interceptar, descifrar o alterar tráfico fuera del alcance del proyecto.

Por ello, Anjana Data SL solo acepta certificados cuyo ámbito sea exclusivamente el entorno destinado al despliegue.

5.4. Cumplimiento y auditoría

Ceder wildcards de dominio raíz constituye típicamente:

• Una no conformidad grave de seguridad en auditorías como ISO 27001 o SOC2 salvo que exista un acuerdo contractual específico que lo justifique.

• Un incumplimiento de controles de gestión de claves.

• Una violación de los principios de Least Privilege y Controlled Key Material.

6. Criterios de aceptación

6.1. CAs Públicas Recomendadas

Los certificados deben ser emitidos por una autoridad certificadora pública reconocida, en caso contrario se podrían producir problemas de confianza e interconexión. Algunos ejemplos de CAs públicas son:

• Let's Encrypt

• Microsoft

• Google

• Amazon

• DigiCert

• GlobalSign

• Otras…

6.2. Especificaciones y Nomenclatura

Para estandarizar el despliegue y evitar confusiones, el cliente debe generar y proporcionar los dos archivos de certificado (por cada entorno) con los nombres exactos que se especifican a continuación:

• anjana-fullchain.pem

  • Contenido: El Certificado de Cadena Completa (Fullchain). Este archivo debe contener el certificado del servidor (para *.dominio.com) concatenado con todos los certificados intermedios de la Autoridad Certificadora (CA).

• anjana-privkey.pem

  • Contenido: La Clave Privada (Private Key).

  • Formato: Debe ser PEM (RSA 2048-bit o superior) y no debe estar protegida por contraseña.

6.3. Responsabilidades del cliente

En modalidades en las que el cliente tenga desplegado algún servicio de Anjana Data Platform en su infraestructura (OnPremise, IaaS, PaaS o SaaS Híbrido), será responsabilidad del cliente:

• Gestionar el ciclo de vida de los certificados asociados a los componentes desplegados en su infraestructura.

• Almacenar de forma segura los certificados asociados a los componentes desplegados en su infraestructura.

• Integrar los certificados en los diferentes componentes de la plataforma desplegados en su infraestructura de acuerdo a la documentación oficial.

6.4. Consideraciones adicionales

• Los certificados deben contar con un nivel de cifrado robusto (mínimo RSA 2048 o ECC equivalente).

• Se recomienda configurar alertas o automatismos que permitan anticiparse a la expiración de certificados.

• En caso de utilizarse un proxy inverso (como NGINX o Apache), se debe asegurar que el mismo esté correctamente configurado para servir el certificado y permitir la validación TLS adecuada.

• En el modelo OPrem/IaaS/PaaS/SaaS Híbrido, Anjana Data SL no proporciona soporte sobre herramientas específicas de gestión del ciclo de vida de los certificados, pero puede ofrecer recomendaciones.

7. Recomendaciones y consideraciones para gestión de certificados por parte del cliente

La correcta gestión de certificados digitales es un elemento clave para garantizar la seguridad, la integridad y la confiabilidad de las comunicaciones entre los distintos componentes de la plataforma Anjana Data y los sistemas del cliente. La elección del tipo de certificado, así como su ciclo de vida y la forma en la que se distribuye y mantiene, tiene un impacto directo en la experiencia de integración, en la exposición a riesgos y en el cumplimiento de normativas de seguridad.

En este apartado se presentan una serie de recomendaciones y buenas prácticas orientadas a facilitar la toma de decisiones respecto al uso de certificados autofirmados o certificados emitidos por Autoridades de Certificación (CA) públicas. Además, se detallan los escenarios en los que cada opción puede resultar adecuada, los requisitos asociados a su despliegue y mantenimiento, y las implicaciones operativas, técnicas y de seguridad que deben ser consideradas por el cliente.

El objetivo es proporcionar una guía clara que permita seleccionar el tipo de certificado más apropiado para cada entorno (desarrollo, pruebas, preproducción o producción), minimizando la carga operativa tanto para el cliente como para el proveedor e incrementando la robustez y confiabilidad de las conexiones.

7.1. Comparativa

7.2. Casos de uso

En algunas ocasiones, en casos de uso más específicos, los certificados autofirmados estarán permitidos o no se desaconsejará su uso.

✅ Cuando usar certificados autofirmados:

• Red interna corporativa: cuando todos los entornos comparten un certificado corporativo o confían en la misma CA. Estos entornos normalmente NO son accesibles externamente ni están conectados a infra externa.

• Entornos cubiertos por un balanceador de carga de aplicación que gestiona certificados (Ej: AWS ALB). El certificado interno de la máquina no establece comunicación en ningún momento, ya que el balanceador, el cual actúa en la capa de aplicación (7 del modelo OSI), es el encargado de responder usando su propio certificado, normalmente proveniente de una CA pública reconocida.

• Entornos cubiertos por un proxy donde se estén gestionando los certificados de alguna manera.

❌ Cuando NO usar certificados autofirmados:

• Entornos preproductivos o productivos accesibles públicamente.

• Integraciones con terceros.

• Entornos cubiertos mediante un balanceador de carga de red (Ej: AWS NLB). Los balanceador de carga a nivel de red actúan en la capa de transporte (4 del modelo OSI), lo cual significa que trabajan con protocolos TCP y UDP, y por lo tanto no gestionan certificados.

8. Procedimiento de Entrega y Seguridad (On-Premise, IaaS, PaaS y SaaS híbrido)

Para todas las modalidades que incluyen infraestructura es propiedad del cliente y, por tanto, son gestionadas por el cliente:

• Responsabilidad: El cliente es responsable de generar y depositar los dos archivos (anjana-fullchain.pem y anjana-privkey.pem) en la siguiente ruta designada dentro de los servidores correspondientes:

  Ruta de destino: /opt/common/anjana-certs/

• Política de Seguridad: El equipo de Operaciones de Anjana Data SL no debe recibir, manipular o transportar certificados (especialmente claves privadas) a través de canales inseguros como correo electrónico, chat o gestores de tickets.