Guía conceptual de EJBCA RA

Esta guía de conceptos de RA describe los conceptos básicos de la Autoridad de Registro (RA) de EJBCA.

Para obtener información sobre cómo administrar la RA, consulte la Guía de operaciones de RA .

Para obtener información sobre la implementación de RA externa asincrónica obsoleta, consulte RA externa mediante sondeo de base de datos .

¿Qué es la EJBCA RA?

¿Qué implica un nombre y qué significa tener una RA instalada? Una Autoridad de Registro (RA) gestiona las operaciones de inscripción, que pueden realizarse directamente a través de la interfaz de RA de EJBCA, como se describe en las siguientes secciones, o mediante otros métodos de inscripción como ACME, EST, REST, etc.

Cómo se diseña y se gestiona esto se analiza en la sección Conceptos de arquitectura del sistema .

La RA puede residir en la misma instancia EJBCA que la CA, pero lo más común es que se redirija a su propia instancia EJBCA y se conecte a EJBCA mediante el protocolo de pares . El objetivo de esto es no exponer la CA al dominio general, sino mantenerla en una zona de alta seguridad tras un firewall que solo permite conexiones salientes mediante TLS, mientras que la RA se encuentra en una zona de baja seguridad (es decir, una DMZ) que permite conexiones entrantes desde la red o incluso desde más allá, según el caso de uso. Esto también permite que varias RA se conecten a la CA tras un balanceador de carga.

Conceptos generales

Inscripción

Un aspecto fundamental de cualquier RA es que los usuarios puedan interactuar directamente con ella para inscribirse en certificados o almacenes de claves. EJBCA ofrece dos flujos de trabajo básicos: o bien, los usuarios se inscriben proporcionando su propia información de identificación (nombre de usuario y contraseña) o bien, se inscriben en una entidad final predefinida y simplemente envían el nombre de usuario y la contraseña que se les ha proporcionado. Los certificados se crean en un proceso de dos pasos:

  1. En primer lugar, se crea una entidad final, que define todos los valores inherentes a esa entidad final, como el tipo de certificado (es decir , Descripción general de perfiles de entidad final ), el subtipo de certificado (es decir, perfil de certificado ), los valores DN del sujeto, los nombres alternativos del sujeto, etc.

  2. En el segundo paso, se produce la inscripción propiamente dicha y se genera el certificado/almacén de claves. Entre ambos pasos, pueden producirse diversas aprobaciones y validaciones si la CA está configurada para ello.

Si el usuario de RA está inscribiendo su propia entidad final, se le dará la opción de ingresar la información completa (algoritmo de firma, tamaño de clave, etc.) del almacén de claves que está solicitando, o ser dirigido a un campo donde puede pegar/subir un CSR. Si la CA está configurada para permitir todas las inscripciones, entonces se le permitirá descargar el almacén de claves/certificado en cualquiera de los formatos aprobados, de lo contrario, se le dará un código de inscripción que puede usar para recuperar el certificado/almacén de claves cuando se le haya notificado que se ha emitido. En el caso de un almacén de claves, el archivo del almacén de claves en sí se bloqueará con la contraseña proporcionada. EJBCA no guarda los almacenes de claves generados por defecto, a menos que la CA se haya configurado para permitir la recuperación posterior , que hará que la CA guarde el almacén de claves en la base de datos, cifrado por la clave de cifrado de la CA. (Esto solo funciona para claves de cifrado RSA, ya que EC no permite el cifrado).

El RA también se puede configurar para permitir conexiones no autenticadas (ya sea a través de http simple, https o ambos).

Gestión del ciclo de vida de certificados y entidades finales

El segundo aspecto básico de la RA con el que interactuarán la mayoría de los usuarios son las pantallas de búsqueda, que permiten buscar entidades finales y certificados mediante datos de búsqueda parciales, restringidos a lo que el usuario puede ver (ver más información a continuación). A través de esta vista, los usuarios y administradores pueden solicitar la revocación de sus certificados.

Gestión de aprobaciones

Una parte esencial del flujo de trabajo de un administrador de RA es gestionar las solicitudes de inscripción en las CA configuradas para usar aprobaciones . En la RA EJBCA, los usuarios autorizados pueden iniciar sesión y gestionar las solicitudes de inscripción que requieren su atención. En una instancia EJBCA configurada como proxy de una CA, las solicitudes se enviarán sin problemas de la CA a la RA, y podrán gestionarse desde allí.

Gestión de roles

Si bien la mayoría de las asignaciones de roles y reglas de acceso se gestionan desde la interfaz de usuario de la CA, la RA ofrece funciones limitadas de administración de roles para que los usuarios autorizados puedan crear administradores de RA adicionales. El objetivo es permitir que las configuraciones de PKI administrada (donde la RA es propiedad exclusiva de una entidad distinta a la CA y está administrada por ella) administren a sus propios usuarios. Los administradores de RA creados a través de esta interfaz solo podrán administrar entidades finales y aprobar solicitudes; no podrán obtener privilegios de administración en la CA ni acceso de gestión a la propia RA.

Conceptos de arquitectura de sistemas

Seguridad de transferencia

Al usar la interfaz EJBCA RA conectada a otra instancia configurada como CA, ambas se conectan mediante el protocolo EJBCA Peers. La base de Peers es la comunicación peer-to-peer entre instancias de EJBCA sobre TLS, donde el lado iniciador (es decir, saliente ) se identifica mediante un certificado emitido por una CA de confianza común para el lado receptor (es decir, entrante ), que en el extremo saliente se definirá mediante un Authentication Key Binding . El nivel de seguridad asumido es que el firewall entre las dos zonas solo permitirá la comunicación saliente segura de la CA a la RA, por lo que la CA iniciará las comunicaciones dejando una serie de subprocesos de comunicación de larga duración a la RA, que puede usar para reenviar solicitudes del usuario final. El grupo de subprocesos es limitado, lo que mitiga el riesgo de que una RA comprometida pueda realizar ataques DOS contra la CA.

Seguridad del dominio

Como se mencionó anteriormente, una vulneración completa de la RA (incluidos los pares de claves de administrador) solo puede tener efectos limitados en la CA. Si bien, en el peor de los casos, podría inscribir certificados y aprobar solicitudes, la RA se comunica con la capa de la CA (incluso cuando ambas se encuentran en la misma instancia) a través de una interfaz proxy que limita las operaciones disponibles. Si la RA se encuentra en una instancia proxy (que tiene un riesgo mucho mayor de verse comprometida al estar en una zona de menor seguridad que la CA), el daño se mitiga aún más gracias a que la conexión entre pares tiene su propio rol y reglas de acceso asociadas. Esto significa que, incluso si un atacante obtiene un par de claves de superadministrador y lo usa en la RA, el alcance del ataque se limita a lo anterior; no podrá realizar operaciones de administración de la CA ni acceder a otras CA alojadas en la instancia de CA a las que la conexión entre pares no esté autorizada. Además, los mensajes de error se filtran al enviarse a la RA, lo que proporciona a un posible atacante poco acceso a información no autorizada. Para obtener más información, consulte Administración de la RA .

Personalización

El RA de EJBCA se puede personalizar ampliamente para adaptarse a las necesidades individuales, incluso permitiendo administrar varias hojas de estilo desde la CA y configurarlas de manera diferente según el rol del usuario.

Para obtener más información, consulte Personalizar la apariencia de RA .

Agrupamiento

Puede usar varios servidores RA para proporcionar mayor disponibilidad o aumentar el rendimiento. El RA en sí no tiene estado, por lo que cualquier usuario puede acceder a cualquier servidor RA para realizar sus tareas, siempre que sea un RA con los mismos privilegios.

Para obtener más información, consulte Alta disponibilidad y agrupación en clústeres .

Una sesión de usuario en la interfaz de usuario de RA utiliza sesiones HTTPS y, por lo general, un balanceador de carga las vincula a un nodo específico. Un nodo de RA siempre debe atender un clúster de CA, pero no importa qué nodo del clúster de CA atienda una solicitud, siempre que todos tengan una vista común de la base de datos de CA.