Recuperación ante desastres de PKI: planificación, procedimientos y patrones de conmutación por error

La mayoría de las organizaciones invierten un esfuerzo considerable en la creación de una infraestructura de clave pública (PKI), el diseño de la jerarquía de la autoridad de certificación (CA), la protección de las claves raíz en un módulo de seguridad de hardware (HSM), la implementación de respondedores OCSP y la configuración de plantillas de certificados. Sin embargo, muchas menos dedican el mismo rigor a planificar qué sucede cuando falla dicha PKI.

Un fallo de una CA no es un caso aislado e hipotético. El hardware falla, los centros de datos se saturan y el ransomware no ignora la infraestructura de seguridad. Cuando una CA deja de funcionar, las consecuencias se suceden rápidamente: no se pueden emitir nuevos certificados, no se establecen túneles VPN, los servidores web sirven certificados no confiables y, lo que es crítico, las listas de revocación de certificados (CRL) dejan de actualizarse. Una vez que caduca una CRL, todas las aplicaciones que realizan comprobaciones de revocación comenzarán a rechazar certificados válidos, lo que provocará la caída de sistemas que no tienen nada que ver con la propia CA.

Esta guía abarca todo, desde el alcance de las copias de seguridad y los procedimientos de emergencia hasta las arquitecturas de conmutación por error y los manuales de pruebas de recuperación ante desastres, con orientación práctica tanto para entornos PKI autogestionados como gestionados.

¿Por qué la recuperación ante desastres de PKI es diferente?

La recuperación ante desastres de PKI tiene una característica que la mayoría de los demás escenarios de recuperación ante desastres no poseen: el tiempo ya está corriendo antes de que te des cuenta de que algo anda mal.

Cuando una CA falla, ya no puede firmar ni publicar CRL. Sin embargo, las CRL ya publicadas conservan su validez durante el período configurado, que suele ser de 7 días para una CRL base y de 24 horas para una CRL delta. Esto significa que, desde el momento en que una CA se desconecta, se dispone de un plazo fijo para restaurarla o utilizar procedimientos de emergencia antes de que las aplicaciones empiecen a fallar.

Considere dos escenarios:

Escenario A: Su CA emisora ​​publica una CRL base cada 7 días y una CRL delta cada 24 horas. La CRL delta expiró hace 2 horas cuando la CA dejó de estar disponible. Dispone de aproximadamente 22 horas antes de que las partes que confían en ella ya no puedan validar la CRL delta, y de 5 días antes de que expire la CRL base.

Escenario B: Su CA emisora ​​publica una CRL base cada 7 días y ninguna CRL delta. La CRL base se publicó hace 4 días. Tiene 3 días antes de que la validación de certificados comience a fallar en toda la empresa.

El diseño del calendario de publicación de su CRL determina directamente su presupuesto de tiempo para la recuperación ante desastres. Esto no es solo un detalle de configuración, sino una decisión de recuperación ante desastres.

La segunda característica distintiva de la recuperación ante desastres de PKI es la custodia de claves. Recuperar una CA sin la clave privada original es imposible. La copia de seguridad de esa clave, así como el procedimiento para acceder a ella, deben planificarse y probarse antes de necesitarla.

¿Qué falla cuando una CA se cae?

Antes de diseñar una estrategia de recuperación, es útil comprender exactamente qué falla y en qué orden:

Inmediatamente (minutos):

• Se detiene la emisión de nuevos certificados.
• Los respondedores de OCSP que dependen de la base de datos en tiempo real de la CA dejan de devolver respuestas autorizadas.
• Cualquier servicio de inscripción (NDES, inscripción web, SCEP) deja de estar disponible.

En cuestión de horas o días (dependiendo del período de validez de la CRL):

• Las CRL delta caducan: las aplicaciones que realizan comprobaciones de revocación mediante CRL delta empiezan a fallar.
• Las CRL base caducan: todas las aplicaciones de partes confiables que verifican la revocación comienzan a rechazar los certificados.

A largo plazo:

• El propio certificado de la CA puede estar próximo a caducar si la recuperación se retrasa durante un período prolongado.
• Las cadenas de confianza para las CA subordinadas o con certificación cruzada se ven interrumpidas.

Comprender esta cronología permite priorizar una interrupción de OCSP sin una falla de CA correspondiente, lo cual es urgente pero no catastrófico; una falla de CA con una CRL delta vencida es un incidente inmediato que requiere la intervención de todo el personal.

Alcance de la copia de seguridad: qué debe protegerse

Una copia de seguridad de la CA solo es útil si contiene todo lo necesario para restaurar la CA en un servidor diferente. Deben incluirse todos los siguientes componentes:

Claves privadas de la CA raíz y emisora

La clave privada es el elemento más crítico y peligroso de su infraestructura de clave pública (PKI). Debe protegerse en reposo mediante un módulo de seguridad de hardware (HSM) o, como mínimo, con un archivo PKCS#12 protegido con contraseña y almacenado en una ubicación físicamente segura y con acceso controlado. Si se pierde la clave privada, la autoridad de certificación (CA) no podrá recuperarse jamás. Será necesario crear una nueva jerarquía de CA desde cero.

Para las organizaciones que utilizan un HSM, siga los procedimientos de copia de seguridad y restauración de claves de su proveedor (Luna, nShield y Utimaco tienen flujos de trabajo específicos para la copia de seguridad de claves de HSM). La copia de seguridad de la clave de HSM debe almacenarse en una ubicación física diferente a la del HSM principal.

Base de datos de certificados

La base de datos de la CA contiene un registro de todos los certificados emitidos o revocados. Sin ella, se pierde el historial completo de emisiones y no se puede reconstruir la información de revocación. Para las CA basadas en ADCS, esta es la base de datos Jet/ESE ubicada en:

%SystemRoot%\System32\CertLog

Configuración del registro

La configuración de la CA, incluyendo la configuración de la CRL, las extensiones de certificado, los períodos de validez y los puntos de publicación, se almacena en el registro de Windows en:

HKLM\SYSTEM\CurrentControlSet\Servicios\CertSvc\Configuración

Exporta esto como un archivo .reg con cada copia de seguridad.

CAPolicy.inf

Este archivo define la política de certificados de la CA durante la instalación. Si bien no es necesario para restaurar una CA en funcionamiento, constituye una documentación esencial para reconstruirla en caso de que la clave privada se vea comprometida.

Plantillas de certificado

En un entorno de Active Directory, las plantillas de certificados se almacenan en la partición de configuración de AD, no en el propio servidor de la CA. Sin embargo, es importante documentar las definiciones de plantillas personalizadas para cada atributo, de modo que puedan recrearse si es necesario reconstruir Active Directory.

Archivos CRL

Realice una copia de seguridad de los archivos CRL base y delta actuales. En caso de emergencia, estos archivos se pueden volver a publicar en un nuevo punto de distribución o utilizarse como base para una operación de re-firma de CRL.

El script CA Backup de Encryption Consulting automatiza todo este proceso en una única ejecución programada de PowerShell, incluyendo el truncamiento de registros y el registro de eventos.

Procedimiento de emergencia: Re-firma de CRL

La renovación de la CRL es la técnica de emergencia más importante que todo administrador de PKI debería conocer, y la que con mayor frecuencia falta en los manuales de recuperación ante desastres.

Cuando una CA falla y una CRL está próxima a caducar, no es necesario restaurar completamente la CA para evitar una interrupción por revocación. Si dispone de una copia de seguridad de la clave privada de la CA, puede usarla para volver a firmar una CRL existente y extender su período de validez. Esto le proporciona horas o días adicionales para completar la restauración de la CA sin afectar la validación de certificados en toda la empresa.

Cuándo usarlo: Cuando una CA está fuera de línea y una CRL está dentro de su período de solapamiento o ya ha expirado.

Que es lo que necesita:

• Una copia de seguridad del par de claves pública/privada de la CA (PKCS#12 o material de clave respaldado por HSM).
• El archivo CRL más reciente de su punto de distribución o copia de seguridad

Pasos de alto nivel:

1. Importe el par de claves de CA a una estación de trabajo segura y temporal.
2. Utilice certutil -sign (ADCS) o el equivalente en su plataforma PKI para volver a firmar la CRL con un período de validez extendido.
3. Publique la CRL firmada nuevamente en todos los puntos de distribución configurados (HTTP, LDAP).
4. Supervise las aplicaciones de verificación de OCSP y CRL para confirmar que aceptan la CRL renovada.
5. Proceda con la restauración completa de CA en paralelo.

La nueva firma de la CRL no sustituye la recuperación de la CA, sino que actúa como un puente que evita una interrupción por revocación mientras se lleva a cabo la recuperación.

RTO y RPO por componente PKI

No todos los componentes de PKI tienen los mismos requisitos de recuperación. Definir el RTO (Objetivo de Tiempo de Recuperación) y el RPO (Objetivo de Punto de Recuperación) para cada componente ayuda a priorizar los esfuerzos y la inversión.

Componente	Objetivo típico de RTO	Objetivo típico de RPO	Notas
Respondedor OCSP	<15 minutos	Casi cero	Impacto inmediato de alto impacto; considere el OCSP activo-activo.
Emisión de CA	<1 horas	Última copia de seguridad (diaria o más frecuente)	La ventana CRL determina la criticidad
CA raíz	<4 horas	Última copia de seguridad	La CA raíz sin conexión agrega tiempo de ceremonia
Base de datos de CA	Última copia de seguridad	Última copia de seguridad	Replicación diaria o continua
Plantillas de certificado	Baja urgencia	Configuración documentada	Almacenado en la enfermedad de Alzheimer; recuperable si la enfermedad de Alzheimer está sana.

Para las organizaciones con un acuerdo de nivel de servicio (SLA) formal o un requisito normativo, estos objetivos deben documentarse en un plan de continuidad del negocio específico para la infraestructura de clave pública (PKI) y revisarse anualmente.

Arquitecturas de conmutación por error

CA de DR activo-pasivo

El patrón más común para la infraestructura de clave pública (PKI) empresarial es una implementación activo-pasiva: una CA emisora ​​principal gestiona toda la emisión de certificados durante las operaciones normales, mientras que una o más CA emisoras de recuperación ante desastres (DR) permanecen en estado de espera, preconfiguradas y probadas, pero sin emitir certificados.

Principios clave de diseño para esta arquitectura:

• Las CA de recuperación ante desastres (DR CA) deben estar preinstaladas y configuradas con las mismas plantillas de certificados, puntos de distribución de CRL y extensiones AIA que la CA principal. El costo de implementar una DR CA durante un incidente, bajo presión, es desproporcionadamente alto.
• La sincronización de la configuración debe ser explícita. Cuando las plantillas o las políticas cambian en el servidor principal, esos cambios deben replicarse en las CA de recuperación ante desastres (DR). Un modo de fallo común es descubrir que una CA de DR tiene una configuración que se desvió de la de producción hace seis meses.
• Pruebe la conmutación por error periódicamente. Emita un certificado de prueba de la CA de recuperación ante desastres al menos trimestralmente para confirmar su funcionamiento. Una CA de recuperación ante desastres que nunca se ha probado no es una CA de recuperación ante desastres, sino un riesgo.

Autoridades de certificación emisoras activas-activas

Para organizaciones con altos volúmenes de emisión de certificados o acuerdos de nivel de servicio (SLA) de disponibilidad estrictos, es preferible el modelo activo-activo. En este modelo, dos o más autoridades de certificación emisoras comparten la carga mediante DNS round-robin o un balanceador de carga, y cualquiera de ellas puede emitir certificados de forma independiente.

Este enfoque requiere una estrategia de base de datos cuidadosa: cada CA mantiene su propia base de datos de certificados, lo que significa que el historial de emisión se divide entre las distintas CA. La publicación de la CRL debe tener esto en cuenta, de modo que cada CA publique su propia CRL, y los respondedores OCSP deben configurarse para consultar ambas.

Consideraciones sobre la CA raíz fuera de línea

En la mayoría de los diseños de infraestructura de clave pública (PKI) empresariales, la CA raíz se mantiene sin conexión, apagada y protegida físicamente cuando no se utiliza. Esto reduce drásticamente la superficie de ataque, pero introduce consideraciones de procedimiento para las operaciones de recuperación ante desastres.

Un procedimiento de recuperación ante desastres de la CA raíz fuera de línea diseñado correctamente incluye:

• Integridad de dos personas (acceso a clave M de N): utilice el método de compartición de secretos de Shamir o controles de quórum impuestos por HSM (por ejemplo, "deben estar presentes M de los N custodios") para que ningún individuo pueda acceder a la clave privada de la CA raíz.
• Documentación de la ceremonia de entrega de la clave física: Cada vez que se encienda la CA raíz, los pasos realizados deben registrarse, presenciarse y archivarse con fines de auditoría.
• Ruta de restauración probada: Al menos una vez al año, siga el procedimiento completo de restauración de la CA raíz en hardware aislado para confirmar que los medios sin conexión, las copias de seguridad de claves y la documentación son suficientes para reconstruir la CA.

Pruebas de recuperación ante desastres: Manual de procedimientos y cronograma

Un plan de recuperación ante desastres que nunca se ha probado es una hipótesis. El siguiente cronograma proporciona una base práctica para las pruebas de recuperación ante desastres de PKI.

Mensual

• Verifique que las copias de seguridad automáticas de CA se hayan completado correctamente y que los archivos de copia de seguridad sean accesibles.
• Confirme que la publicación de CRL y delta CRL esté actualizada en todos los puntos de distribución.
• Confirme que los respondedores de OCSP estén en buen estado y devuelvan respuestas dentro del SLA.
• Revise los registros de eventos de CA para detectar errores o advertencias.

Trimestral

• Realice una restauración completa de CA en un entorno de prueba aislado utilizando la copia de seguridad más reciente.
• Emitir un certificado de prueba desde cada CA de recuperación ante desastres/reserva
• Confirme que la configuración entre las CA primaria y DR esté sincronizada.
• Verifique que el procedimiento de re-firma de la CRL se pueda ejecutar correctamente (utilizando una clave que no sea de producción).

Anualmente

• Ejecutar una simulación completa de conmutación por error: desconectar la CA emisora ​​principal y confirmar que la CA de recuperación ante desastres toma el control sin intervención manual.
• Recorra el proceso de restauración de Root CA sin conexión
• Revisar y actualizar el manual de recuperación ante desastres para cualquier cambio en la infraestructura.
• Revise los objetivos de RTO/RPO en función de los requisitos del negocio y ajústelos si es necesario.

Consideraciones de DR durante la migración de CA

La migración de CA introduce un período temporal en el que la postura de recuperación ante desastres se ve comprometida. Es posible que la antigua CA se desactive antes de que el entorno de recuperación ante desastres de la nueva CA esté completamente implementado. Medidas de mitigación específicas:

• No desactive la CA antigua antes de que la CA de recuperación ante desastres de la nueva CA esté operativa. La CA antigua debe permanecer como respaldo hasta que se haya demostrado la estabilidad de la nueva jerarquía de CA.
• Garantizar la continuidad de la CRL durante la migración. Si los puntos CDP/AIA cambian, los antiguos puntos de distribución de CRL deben permanecer accesibles durante la vigencia de los certificados emitidos por la antigua CA.
• Realice una copia de seguridad de la CA anterior antes de cualquier paso de migración. Una copia de seguridad realizada justo antes de que comience la migración es el artefacto de recuperación más importante que tendrá.
• Defina los criterios de reversión con antelación. Acuerde las condiciones específicas que desencadenarían una reversión a la CA anterior antes de que comience la migración, no durante la misma.

Cómo elegir el modelo de DR adecuado

PKI autogestionada

Si gestiona la infraestructura de clave pública (PKI) internamente, las directrices de este artículo le proporcionan los elementos básicos de un programa de recuperación ante desastres (DR). La postura mínima viable es:

• Un proceso de copia de seguridad de CA programado y probado que abarca todos los componentes enumerados anteriormente.
• Al menos una CA emisora ​​de DR preconfigurada
• Un procedimiento documentado de re-firma de CRL con el material clave para ejecutarlo.
• Un ciclo de pruebas trimestral

PKI gestionada (PKIaaS)

Para las organizaciones que desean garantías de recuperación ante desastres sin la complejidad operativa, un servicio PKI gestionado traslada la responsabilidad de la recuperación ante desastres al proveedor. El servicio PKI como servicio de Encryption Consulting incluye monitorización proactiva, respuesta activa a incidentes y un equipo especializado disponible para situaciones de recuperación ante desastres, como se demuestra en nuestro caso de éxito de PKIaaS , donde todos los incidentes de interrupción global se resolvieron en menos de una hora.

Gestión del ciclo de vida de los certificados

Independientemente de si la infraestructura de clave pública (PKI) se gestiona internamente o se externaliza, tener visibilidad en tiempo real del inventario de certificados multiplica la capacidad de recuperación ante desastres. CertSecure Manager proporciona una vista centralizada y siempre actualizada de todos los certificados de su entorno, de modo que, al iniciar la recuperación, sabrá exactamente qué certificados se emitieron, cuáles están a punto de caducar y qué servicios están en riesgo, sin necesidad de reconstruir la información a partir de una copia de seguridad antigua.

¿Cómo puede ayudar la consultoría de cifrado?

El equipo de PKI de Encryption Consulting diseña e implementa arquitecturas PKI preparadas para la recuperación ante desastres (DR) que se ajustan a los requisitos de RTO/RPO y las obligaciones de cumplimiento normativo de su organización. Tanto si está integrando la recuperación ante desastres en una PKI existente, planificando una migración o buscando simplificar por completo la complejidad operativa con PKIaaS, nuestro equipo aporta experiencia práctica en ADCS, PKI en la nube y entornos de múltiples proveedores.

• Servicios de PKIDiseño, implementación y planificación de recuperación ante desastres de extremo a extremo para infraestructura de clave pública (PKI).
• PKI como servicioPKI totalmente gestionada con recuperación ante desastres integrada y monitorización 24/7.
• Administrador de CertSecure: Gestión del ciclo de vida de los certificados con inventario en tiempo real y alertas de caducidad.
• Script de copia de seguridad de CA: Utilidad gratuita de PowerShell para automatizar copias de seguridad completas de CA
• HSM como servicioProtección de claves de alta seguridad con implementación de HSM preparada para la recuperación ante desastres

Póngase en contacto con nosotros para hablar sobre sus requisitos de recuperación ante desastres de PKI o solicite una demostración para ver CertSecure Manager en acción.

Conclusión

La recuperación ante desastres de PKI no es una tarea de configuración única, sino una disciplina operativa continua. Los principios clave son:

• Diseñe ventanas de validez de CRL teniendo en cuenta la recuperación ante desastres. El período entre su última CRL publicada y su vencimiento es su presupuesto de tiempo de recuperación.
• Proteja la clave privada por encima de todo. Cualquier otro componente puede reconstruirse; la clave no.
• Conozca el procedimiento de renovación de la CRL antes de necesitarlo. Es la técnica de emergencia más valiosa en PKI DR y la menos utilizada.
• Ponga a prueba su DR. Una CA de DR que nunca ha emitido un certificado de prueba es una suposición no comprobada.
• Planifique la recuperación ante desastres (DR) en cada migración. Una migración es un período de alto riesgo; la preparación para la recuperación ante desastres debe mantenerse durante todo el proceso.