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 (AC) de terceros en Google Distributed Cloud (GDC) aislado.

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

GDC aislado 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 AC nativo es la solución recomendada para la mayoría de los clientes, ya que proporciona capacidades de PKI completamente administradas y sin interrupciones dentro de la plataforma. Sin embargo, las organizaciones que estandarizaron su infraestructura de PKI en Keyfactor EJBCA para las cargas de trabajo existentes fuera de GDC pueden preferir aprovechar la misma arquitectura de AC y las mismas 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 de ACME estandarizada: Compatibilidad con el protocolo de entorno automático de administración de certificados (ACME) con desafíos de 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 AC dentro de un módulo de seguridad de hardware (HSM) con certificación 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 entornos aislados: Flujos de trabajo especializados para duplicar la imagen de la entidad emisora de cert-manager de EJBCA desde registros públicos hasta el registro privado de Harbor de GDC, lo que garantiza la disponibilidad sin conexión.
  • Aislamiento del tráfico de salida: Configuración de red de salida con recursos de subred de GDC y CloudNATGateway para restringir el tráfico de la API de GDC directamente a la dirección IP externa del servidor de EJBCA.

Principios de arquitectura

  • Modelo de responsabilidad compartida: El cliente opera el servidor EJBCA externo y el HSM, y es propietario de la infraestructura de PKI física y las claves raíz de la AC, mientras que GDC proporciona las capas de procesamiento, DNS interno y cliente automatizado dentro del clúster estándar.
  • Diseño centrado en la seguridad: Se adhiere a los requisitos de seguridad aislados mediante el uso de duplicados de imágenes de contenedores locales y la aplicación de un control estricto de salida 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 con la AC, lo que evita las dependencias de APIs de propiedad exclusiva y permite integraciones de clientes flexibles.

Arquitectura

La arquitectura sigue el modelo de autoridad certificadora externa, en el que el servidor de 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 se puede acceder a ellos por red. El servidor de 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 de EJBCA externo a través de una dirección IP estable.

Diagrama de arquitectura de Keyfactor EJBCA.

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

  • EJBCA Enterprise Server: Se implementa de forma externa como un dispositivo de hardware o software de Keyfactor, que aloja las AC (raíz y subordinada) y genera todo el material de claves de AC dentro de un HSM con certificación CC EAL4+.
  • VPC predeterminada: Es la VPC en la que se implementan las cargas de trabajo de los usuarios, ya sea en clústeres de Kubernetes estándar o en máquinas virtuales.
  • DNS interno de GDC: Administra las zonas del DNS privadas locales (con el nombre de dominio privado configurado en las variables de entorno) que se usan para resolver los desafíos de 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 externa del servidor de EJBCA.
  • Registro privado de Harbor: Aloja imágenes de contenedor duplicadas (como la entidad emisora de cert-manager de EJBCA) para la implementación aislada.

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, que ejecutan la automatización de certificados para las cargas de trabajo.
  • Registro de Harbor: Es la fuente de información local y segura para 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: Son 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 la AC externa.

Servicios y lógica

  • EJBCA Enterprise Server: Es el motor de CA externo (dispositivo de software o hardware) 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 AC nunca se expongan.
  • DNS interno de GDC: Administra las zonas del 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 la 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 de RESTful que se usa para el inicio 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 de EJBCA externo debe escalarse (CPU, memoria, capacidad de HSM) para controlar las solicitudes de validación y firma simultáneas, 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 para el servidor de la AC externa, lo que evita tiempos de espera durante los ciclos de validación de cert-manager.
  • Seguridad y cumplimiento:
    • Aislar las claves raíz de la AC dentro de un HSM externo cumple con altos estándares de seguridad y cumplimiento (como BSI VS-NfD).
    • El acceso de administrador a EJBCA debe estar estrictamente limitado con el control de acceso basado 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 de 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 punto único de fallo.
    • Implementar 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 resiliente.
  • Administración operativa:
    • El cliente conserva la propiedad del servidor de EJBCA, lo que incluye la aplicación de parches del sistema, la rotación de claves de HSM y la publicación de CRL.
    • Los administradores de la plataforma de 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 aislado.

Opción de integración de EJBCA

El servicio de Certificate Authority nativo de GDC es la solución de PKI recomendada para la mayoría de los clientes, ya que proporciona capacidades de PKI completamente administradas y sin interrupciones en entornos de GDC aislados. 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 AC externo existente como una opción de habilitació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 aislados y privados 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 la carga de trabajo.

Recomendación de canal administrativo de mTLS

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

Suposiciones y limitaciones

Suposiciones

  • El servidor de EJBCA externo se implementa, se configura y se puede acceder a él a través de una dirección IP estable.
  • El servidor de EJBCA está preconfigurado con las AC raíz y subordinadas necesarias, junto con los perfiles de entidad final adecuados.
  • Hay un mecanismo seguro (como un nodo de 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 de Kubernetes estándar dentro de GDC tienen cert-manager preinstalado o configurado para su funcionamiento.

Limitaciones

  • Mantenimiento externo de HSM y EJBCA: El plano de control de GDC no administra el servidor de EJBCA externo ni su HSM de respaldo; las operaciones del ciclo de vida (copias de seguridad, actualizaciones, rotaciones de claves) las controla el equipo de operaciones de PKI del cliente.
  • Restricción de validación de DNSSEC: Debido a que se usa un 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 en los dominios privados locales.
  • Dependencia de la conectividad de salida: Los servicios de emisión de certificados automatizados dependen de la disponibilidad y la latencia del vínculo de red entre el bastidor de GDC y el servidor de EJBCA externo.