Ir al contenido

PKI interna

La PKI interna de Enterprise puede crear autoridades raíz e intermedias, emitir certificados de servidor, cliente, firma de código y correo electrónico, aplicar plantillas, publicar CRL y exportar en los formatos compatibles con ámbitos explícitos.

En la consola, la PKI interna está en la página Certificates, en las pestañas Authorities, PKI Certificates y Templates.

Usa la PKI interna cuando Opfield deba gestionar un dominio de confianza privado para personas, servicios, firma de código o protección del correo. Emitir un certificado es el primer paso: antes de que se convierta en una dependencia de producción, demuestra su cadena, su uso previsto, su renovación, su revocación, su copia de seguridad y su recuperación.

PKI significa infraestructura de clave pública: las autoridades, los certificados, las claves privadas, los registros de revocación y la política que permiten a los sistemas decidir en qué identidades confiar. Una autoridad de certificación raíz es el anclaje de confianza de nivel superior. Una autoridad intermedia emite los certificados del día a día para que la raíz se use con menos frecuencia y se pueda proteger mejor.

Las claves privadas se cifran con PKI_MASTER_KEY. Conserva esta clave de forma independiente de la copia de seguridad de la base de datos. Limita los permisos de exportación y audita cada operación con autoridades, certificados, revocaciones y claves privadas.

La PKI interna de cara al usuario está separada de la PKI del sistema oculta que Opfield usa para el transporte gestionado. Cuando termina el periodo de gracia de una licencia, se conservan las autoridades, los certificados, las plantillas y el historial de auditoría existentes; todavía puedes verlos, descargar las listas de revocación, revocar y exportar certificados y eliminar plantillas, mientras que crear autoridades, emitir certificados y cambiar plantillas vuelve a requerir el plan. El transporte del sistema sigue funcionando.

Crea una autoridad raíz solo cuando Opfield deba ser responsable de ese anclaje de confianza. Es preferible mantener la raíz fuera de línea o usarla muy poco y emitir los certificados operativos desde una autoridad intermedia. Las plantillas restringen el sujeto, el tiempo de vida, el uso de la clave, el uso extendido de la clave y el comportamiento de exportación para que los operadores no tengan que reproducir la política a mano en cada petición.

Las autoridades de cara al usuario de Opfield nunca deben reutilizarse para sustituir la PKI del sistema oculta, la CA de bases de datos, las identidades de los daemons ni las identidades de servicio de Relay. Esos dominios de confianza internos tienen contratos de rotación y de recuperación separados.

Antes de crear una raíz, aprueba su alcance, su responsable, su tiempo de vida, los usos de certificados permitidos, el contacto para incidentes y el plan de retirada. Decide si la raíz se genera en Opfield o se importa, si se permite exportar la clave privada y qué sistemas que confían en ella consumirán las listas de revocación de certificados (CRL). Si esas decisiones no están documentadas, crear la autoridad es prematuro.

Usa autoridades intermedias separadas para entornos o niveles de garantía materialmente distintos. Un emisor de desarrollo comprometido no debería amenazar automáticamente a producción, y un emisor de firma de código no debería ser intercambiable con un emisor general de certificados de servidor. Las plantillas deben codificar estos límites en lugar de depender de la memoria de los operadores.

  1. Confirma el derecho del plan Enterprise y los ámbitos de PKI necesarios.
  2. Genera o importa la autoridad raíz.
  3. Haz una copia de seguridad de PKI_MASTER_KEY y de la base de datos de Opfield mediante procedimientos protegidos separados.
  4. Crea una autoridad intermedia para el entorno o el límite organizativo previsto.
  5. Crea plantillas para certificados de servidor, cliente, firma de código o correo electrónico.
  6. Emite un certificado de prueba y verifica su cadena, el uso de la clave, el tiempo de vida y el formato de exportación.
  7. Publica y prueba la ubicación de la CRL antes de emitir en producción.

Registra el responsable, la finalidad, la plantilla, el sujeto, la validez, la expectativa de renovación y el contacto de revocación de cada certificado. Concede la exportación de claves privadas solo a las identidades que necesiten el material de la clave. Un usuario que puede inspeccionar los metadatos de los certificados no necesita automáticamente permisos sobre la autoridad o de exportación de claves.

Cuando una Route usa un certificado de una CA interna, el nodo Ingress lo sirve junto con sus CA intermedias, de modo que los clientes que solo confían en la raíz pueden validarlo.

Antes de renovar, verifica que el sujeto y el uso previsto siguen siendo válidos. Revoca los certificados comprometidos o retirados, publica la CRL actualizada y confirma que los sistemas que confían en ellos la consumen. Eliminar un registro de la interfaz no sustituye a la revocación cuando un certificado todavía puede considerarse de confianza fuera.

Validez, alertas de caducidad y reemisión automática

Sección titulada «Validez, alertas de caducidad y reemisión automática»

Un certificado no puede durar más que la CA que lo emite. Por defecto, una petición cuya validez terminaría después que la CA se rechaza con VALIDITY_EXCEEDS_CA. Fija clampToCaValidity en la REST API, en MCP o en el asistente para que el certificado termine junto con su CA; el diálogo de emisión muestra un aviso y lo aplica automáticamente. Los certificados firmados a partir de una CSR siguen la misma regla. Los certificados finales de las CA del sistema de Opfield siempre terminan junto con su CA.

Opfield genera alertas de caducidad para las CA de usuario 180, 60, 30 y 7 días antes de que caduquen (las dos últimas siguen los ajustes de advertencia y críticos de caducidad de la PKI) y para las CA del sistema con 730, 365, 180, 60, 30 y 7 días de antelación. Las CA del sistema todavía no tienen renovación automática, y todos los certificados de nodos, Relays, almacenamiento gestionado y bases de datos gestionadas que emitieron dejan de funcionar cuando caducan, así que planifica su sustitución cuando aparezca la primera alerta. Las alertas indican el recurso propietario, como un clúster de almacenamiento gestionado, una base de datos gestionada, un Relay, un listener de Opfield o un nodo. Cada umbral avisa una vez: descartar una alerta dura hasta el siguiente umbral, y un certificado renovado vuelve a avisar en su nuevo periodo de vida.

Un certificado de la PKI interna vinculado como certificado SSL o al que una Route hace referencia directamente se vuelve a emitir automáticamente cuando Opfield tiene su clave privada; los certificados firmados a partir de una CSR nunca se vuelven a emitir. La reemisión requiere pki:cert:issue en la CA, como una emisión manual.

Concede pki:ca:edit para cambiar las URL de la CRL y del emisor de una CA, su validez máxima y su respondedor OCSP, y pki:ca:export para exportar una CA con su clave privada; ambos se pueden limitar a una sola CA. pki:ca:view cubre las CA raíz e intermedias y también se puede limitar a una sola CA.

Las autoridades de certificación, los certificados y las plantillas de certificados se pueden organizar en carpetas, como las Routes y los certificados SSL: crea, renombra y reordena carpetas, arrastra elementos entre ellas y elige una carpeta al crear un elemento. Una carpeta de CA contiene jerarquías completas: solo se mueven las CA raíz, y sus intermedias las siguen. Los permisos concedidos sobre una carpeta de CA cubren cada CA raíz que contiene y sus intermedias, y los permisos sobre una carpeta de certificados cubren los certificados que contiene; las carpetas de plantillas de certificados solo organizan la lista. Consulta Compatibilidad con carpetas por tipo de recurso.

Mide el éxito operativo por la cobertura de caducidades, la publicación de revocaciones, la integridad de la auditoría y las pruebas de restauración. Revisa los certificados sin responsable, las plantillas demasiado amplias, las exportaciones inesperadas de claves privadas, las intermedias sin usar y las CRL a las que no pueden llegar los sistemas que confían en ellas. Revelar o exportar una clave privada debe ser algo poco frecuente, autorizado por separado y seguido de una custodia segura fuera de Opfield.

Una copia de seguridad de la base de datos sin PKI_MASTER_KEY no puede recuperar las claves privadas cifradas. Una copia de la clave sin la base de datos no puede reconstruir las autoridades, las plantillas, los certificados, las revocaciones ni las relaciones de auditoría. Guarda y prueba ambas partes manteniéndolas operativamente separadas.

Tras una restauración, verifica las cadenas de las autoridades, el descifrado, los permisos de exportación de certificados, la publicación de la CRL y la continuidad de la auditoría antes de emitir material nuevo.

Detalles para operadores: incidentes y retirada

Sección titulada «Detalles para operadores: incidentes y retirada»

Si se sospecha que una clave emisora está comprometida, detén las nuevas emisiones, identifica todos los certificados descendientes, prepara una jerarquía sustituta, publica la información de revocación y coordina los cambios en los almacenes de confianza con los sistemas que confían en ella. Restaurar la misma clave comprometida no es una recuperación. Conserva las pruebas de auditoría y la cadena pública antigua para la investigación sin seguir confiando en ellas.

Retirar una autoridad requiere algo más que quitarla de la navegación. Detén la emisión, sustituye o deja caducar los descendientes, conserva las pruebas de revocación durante el periodo exigido, retira la confianza de los clientes y, solo entonces, elimina la autoridad cuando Opfield confirme que se han resuelto los objetos dependientes.

Comportamiento de los derechos del plan y de la eliminación

Sección titulada «Comportamiento de los derechos del plan y de la eliminación»

Cuando termina el periodo de gracia de una licencia, Opfield conserva las autoridades y los certificados y mantiene disponibles la visualización, las listas de revocación, la revocación y exportación de certificados y la eliminación, mientras que crear autoridades, emitir certificados y cambiar plantillas vuelve a requerir el plan. El transporte del sistema nunca se desactiva. Antes de eliminar una autoridad, resuelve todas las intermedias y los certificados hijos y conserva las pruebas de revocación necesarias.