Arquitectura de referencia de Keyfactor EJBCA

Descripción general

En esta arquitectura de referencia, se define el diseño conceptual para integrar Keyfactor EJBCA Enterprise como una autoridad certificadora (CA) externa en Google Distributed Cloud (GDC) air-gapped.

Keyfactor EJBCA Enterprise es una plataforma de autoridad certificadora altamente escalable, sólida y compatible con FIPS que permite a las organizaciones administrar la infraestructura de clave pública (PKI) en entornos heterogéneos.

GDC air-gapped incluye un servicio de autoridad certificadora nativo para la administración automatizada de claves y certificados dentro del límite de la nube alojada. El servicio de CA nativo es la solución recomendada para la mayoría de los clientes, ya que proporciona capacidades de PKI sin problemas y completamente administradas dentro de la plataforma. Sin embargo, las organizaciones que estandarizaron su infraestructura de PKI en Keyfactor EJBCA para cargas de trabajo existentes fuera de GDC pueden preferir aprovechar la misma arquitectura de CA y políticas de administración coherentes para las cargas de trabajo que se ejecutan en sus entornos de GDC.

Características y funciones

La solución proporciona varios componentes funcionales principales para la administración del ciclo de vida de los certificados:

• Administración automatizada del ciclo de vida de los certificados: Aprovecha la entidad emisora de EJBCA personalizada dentro de los clústeres estándar de GDC para automatizar el aprovisionamiento, la renovación y la revocación de certificados de servidor a través de cert-manager.
• Automatización estandarizada de ACME: Compatibilidad con el protocolo de entorno automático de administración de certificados (ACME) mediante desafíos DNS-01, lo que permite que los servicios de la plataforma soliciten y renueven certificados sin problemas.
• Integración segura de HSM: Protección criptográfica directa de todas las claves privadas de la CA dentro de un módulo de seguridad de hardware (HSM) certificado por CC EAL4+, lo que garantiza que el material de claves nunca salga del límite de seguridad física. Keyfactor EJBCA Enterprise puede usar su propio HSM administrado o conectarse a un HSM externo.
• Compatibilidad con air-gapped: Flujos de trabajo especializados para duplicar la imagen de la entidad emisora de cert-manager de EJBCA de registros públicos al registro privado de Harbor de GDC, lo que garantiza la disponibilidad sin conexión.
• Aislamiento del tráfico de salida: Configuración de red saliente con recursos de subred de GDC y CloudNATGateway para restringir el tráfico de la API de GDC directamente a la dirección IP del servidor EJBCA externo.

Principios de arquitectura

• Modelo de responsabilidad compartida: El cliente opera el servidor EJBCA externo y el HSM, es propietario de la infraestructura física de PKI y las claves raíz de la CA, mientras que GDC proporciona las capas de procesamiento, DNS interno y cliente automatizadas dentro del clúster estándar.
• Diseño centrado en la seguridad: Cumple con los requisitos de seguridad de air-gapped mediante el uso de duplicados de imágenes de contenedor locales y la aplicación de una puerta de enlace de salida estricta para minimizar la superficie de ataque de la red.
• Estandarización de protocolos: Prioriza los protocolos estándar (ACME y mTLS REST) para la interacción de la CA, evita las dependencias de la API propietaria y permite integraciones de clientes flexibles.

Arquitectura

La arquitectura sigue el modelo de autoridad certificadora externa, en el que el servidor EJBCA y su módulo de seguridad de hardware (HSM) de respaldo se alojan de forma externa fuera de los límites físicos de GDC, pero son accesibles a la red. El servidor EJBCA se puede implementar de forma externa como un dispositivo de hardware o software. La integración principal que se describe en esta guía solo requiere que se pueda acceder al servidor EJBCA externo a través de una dirección IP estable.

Entre los componentes clave de esta arquitectura, se incluyen los siguientes:

• Servidor EJBCA Enterprise: Se implementa de forma externa como un dispositivo de hardware o software de Keyfactor, que aloja las CAs (raíz y subordinada) y genera todo el material de claves de la CA dentro de un HSM certificado por CC EAL4+.
• VPC predeterminada: VPC en la que se implementan las cargas de trabajo del usuario, ya sea en clústeres estándar de Kubernetes o en máquinas virtuales.
• DNS interno de GDC: Administra zonas de DNS privadas locales (con el nombre de dominio privado configurado en las variables de entorno) que se usan para resolver desafíos DNS-01 de ACME.
• Puerta de enlace NAT de salida de GDC: Dirige el tráfico saliente de los pods del clúster a la dirección IP del servidor EJBCA externo.
• Registro privado de Harbor: Aloja imágenes de contenedor duplicadas (como la entidad emisora de cert-manager de EJBCA) para la implementación de air-gapped.

Conceptos y tecnologías

En esta sección, se detallan los componentes funcionales, sus responsabilidades y cómo se comunican dentro del sistema.

Infraestructura y plataforma

• Clúster estándar de GDC: Es el entorno de procesamiento principal en el que residen los pods de la entidad emisora de EJBCA y cert-manager, y ejecuta la automatización de certificados para las cargas de trabajo.
• Registro de Harbor: Es la fuente confiable, segura y local de todas las imágenes de contenedor en GDC. Proporciona análisis automatizados para garantizar que las imágenes no tengan vulnerabilidades conocidas antes de la implementación.
• Puerta de enlace de salida de GDC: Recursos de redes nativos de la plataforma (subred y CloudNATGateway) que rigen y protegen el tráfico de la API saliente de los pods del clúster al servidor de CA externo.

Servicios y lógica

• Servidor EJBCA Enterprise: Es el motor de CA externo (dispositivo de software o hardware físico) responsable de administrar las jerarquías de CA (raíz y subordinada), validar las solicitudes de certificados, firmar certificados y registrar registros de auditoría.
• Módulo de seguridad de hardware (HSM): Es el módulo criptográfico compatible con CC EAL4+ que controla la generación de claves y la firma de certificados, lo que garantiza que las claves privadas de la CA nunca se expongan.
• DNS interno de GDC: Administra zonas de DNS privadas (ManagedDNSZone y ResourceRecordSet) que usa el servicio de validación de desafíos de ACME para verificar la propiedad del dominio a través de registros TXT temporales.
• cert-manager con la entidad emisora de EJBCA: Es el controlador de certificados nativo de Kubernetes que intercepta las solicitudes de certificados y aprovecha la entidad emisora de EJBCA para traducirlas en llamadas seguras a la API de EJBCA.

Flujo de datos e interfaces

• Protocolo ACME: Es la interfaz de API estándar para la emisión automatizada de certificados de servidor validados por dominio con el desafío DNS-01.
• API de REST de EJBCA: Es la interfaz RESTful que se usa para el bootstrapping administrativo y las operaciones programáticas (como la firma y la revocación de CSR).
• Autenticación de cliente mTLS: Es el mecanismo de autenticación principal para la integración de cert-manager, que verifica la identidad del cliente a través de TLS mutua con certificados de cliente dedicados.

Consideraciones

• Escalabilidad y rendimiento:
  • El servidor EJBCA externo debe escalarse (CPU, memoria, capacidad de HSM) para controlar las solicitudes simultáneas de validación y firma, en especial durante los perfiles de emisión de ráfagas.
  • Los recursos de la puerta de enlace de salida de GDC deben tener el tamaño adecuado para garantizar una latencia mínima al servidor de CA externo, lo que evita los tiempos de espera durante los ciclos de validación de cert-manager.
• Seguridad y cumplimiento:
  • El aislamiento de las claves raíz de la CA dentro de un HSM externo cumple con los altos estándares de seguridad y cumplimiento (como BSI VS-NfD).
  • El acceso administrativo a EJBCA debe estar estrictamente limitado con controles de acceso basados en roles (RBAC) y asignado a números de serie de certificados de cliente únicos.
• Disponibilidad y confiabilidad:
  • Se recomienda la implementación de alta disponibilidad del servidor EJBCA externo en varias zonas de disponibilidad (con una configuración activa-pasiva o en clúster) para garantizar el funcionamiento continuo y evitar un único punto de falla.
  • La implementación de varias réplicas del controlador de cert-manager dentro de GDC garantiza que la emisión automatizada de certificados del lado del clúster siga siendo resistente.
• Administración operativa:
  • El cliente conserva la propiedad del servidor EJBCA, incluidos los parches del sistema, la rotación de claves de HSM y la publicación de CRL.
  • Los administradores de la plataforma GDC del cliente son responsables de mantener el cert-manager en el clúster y el controlador de la entidad emisora de EJBCA, y de administrar los registros DNS privados del lado de GDC.

Decisión de diseño

Las principales opciones de arquitectura para esta solución se centran en equilibrar la automatización con las restricciones del entorno de air-gapped.

Opción de integración de EJBCA

El servicio de autoridad certificadora nativo de GDC es la solución de PKI recomendada para la mayoría de los clientes, ya que proporciona capacidades de PKI sin problemas y completamente administradas dentro de los entornos de GDC air-gapped. Sin embargo, para las organizaciones que ya estandarizaron su infraestructura de PKI en Keyfactor EJBCA para cargas de trabajo fuera de GDC, se ofrece la integración de su servidor de CA externo existente como una opción de participación. Esto les permite reutilizar plantillas de PKI, políticas de seguridad y modelos operativos establecidos sin rediseñar su jerarquía de confianza ni migrar flujos de trabajo principales.

Opciones de validación de desafíos de ACME

Se admiten por completo los protocolos de validación de desafíos de ACME HTTP-01 y DNS-01. Si bien esta guía de arquitectura destaca el desafío DNS-01 con el DNS interno de GDC (que es ideal para entornos privados y aislados que no pueden admitir tráfico HTTP público entrante), los clientes pueden seleccionar cualquiera de los métodos de validación según su topología de red específica, las políticas de seguridad y los requisitos de carga de trabajo.

Recomendación de canal administrativo mTLS

Se recomienda usar TLS mutua (mTLS) como un método de autenticación sólido para cert-manager y clientes de integración. mTLS proporciona una verificación criptográfica altamente segura de la identidad del cliente mediante el uso de certificados de cliente, aunque el cliente puede elegir configurar otros mecanismos de autenticación compatibles con su instancia de EJBCA según sus políticas de seguridad corporativas.

Suposiciones y limitaciones

Suposiciones

• El servidor EJBCA externo se implementa, configura y se puede acceder a él a través de una dirección IP estable.
• El servidor EJBCA está preconfigurado con las CAs raíz y subordinadas necesarias, junto con los perfiles de entidad final adecuados.
• Hay un mecanismo seguro (como un nodo bastión o un flujo de trabajo de transferencia sin conexión) disponible para publicar la imagen de contenedor de la entidad emisora de EJBCA en el registro de Harbor de GDC.
• Los clústeres estándar de Kubernetes dentro de GDC tienen cert-manager preinstalado o configurado para la operación.

Limitaciones

• Mantenimiento externo de HSM y EJBCA: El plano de control de GDC no administra el servidor EJBCA externo ni su HSM de respaldo. El equipo de operaciones de PKI del cliente controla las operaciones del ciclo de vida (copias de seguridad, actualizaciones, rotaciones de claves).
• Restricción de validación de DNSSEC: Debido a que se usa DNS interno privado, la validación de DNSSEC debe inhabilitarse del lado del servidor en la configuración de ACME para evitar fallas de resolución para dominios privados locales.
• Dependencia de conectividad de salida: Los servicios automatizados de emisión de certificados dependen de la disponibilidad y la latencia del vínculo de red entre el rack de GDC y el servidor EJBCA externo.