DORA artículo 7: gestión de claves y registro de certificados

El artículo 7 del Reglamento Delegado (UE) 2024/1774 de la Comisión, las normas técnicas de regulación (RTS) de DORA sobre gestión del riesgo de TIC, exige dos cosas: la gestión de las claves criptográficas durante todo su ciclo de vida y un registro de los certificados de los activos TIC que soportan funciones esenciales o importantes. El registro es un artefacto de cumplimiento, pero también es la lista operativa que necesitará el día en que migre el intercambio de claves y las firmas a algoritmos poscuánticos. Esta guía expone los campos que conviene registrar, los comandos de solo lectura que permiten descubrir certificados y la forma en que el registro se conecta con el inventario criptográfico más amplio que exige el artículo 6 de DORA. Se trata de información, no de asesoramiento jurídico.

Qué pide literalmente el artículo 7

El texto de las RTS es breve y concreto. Las entidades financieras deben disponer de políticas y procedimientos de gestión de claves criptográficas que cubran la generación, renovación, almacenamiento, copia de seguridad, archivo, recuperación, transmisión, retirada, revocación y destrucción de las claves. Por otra parte, deben mantener un registro de los certificados y de los dispositivos de almacenamiento de certificados de los activos TIC que soportan funciones esenciales o importantes, y gestionar la renovación de los certificados para que su caducidad no interrumpa esas funciones. El texto auténtico está disponible en EUR-Lex: Reglamento Delegado (UE) 2024/1774 de la Comisión.

De esa redacción se derivan directamente tres consecuencias, antes de cualquier interpretación.

• El alcance lo determinan las funciones, no la infraestructura. El desencadenante es el soporte a una función esencial o importante, de modo que el registro sigue su propia clasificación de funciones, no un perímetro de red.
• Los dispositivos entran en el alcance, no solo los ficheros. Los dispositivos de almacenamiento de certificados incluyen los módulos de seguridad de hardware (HSM), las tarjetas inteligentes, los módulos de plataforma segura (TPM) y los almacenes de claves de los appliances, así que inventaríe tanto el soporte como la credencial.
• La renovación es un control de disponibilidad. Un certificado caducado en una pasarela de pagos es un incidente relacionado con las TIC, y por eso el artículo 7 asocia el registro a la gestión de las renovaciones.

Lo que el artículo 7 no dice es igual de importante. No menciona los algoritmos poscuánticos, no fija una fecha de migración y no exige un formato de fichero concreto. Es el artículo 6 el que exige disposiciones para actualizar o cambiar la tecnología criptográfica en función de la evolución del criptoanálisis, que es el anclaje de la cripto-agilidad. Nuestra lectura, presentada como interpretación: un registro que recoge el algoritmo y el tamaño de clave de cada certificado convierte el artículo 6 de una intención escrita en algo ejecutable, porque permite enumerar en minutos todos los activos que todavía dependen de firmas RSA o ECDSA.

Campos que registrar para cada certificado

Mantenga el registro en un formato legible por máquina (una fila por certificado, exportada desde sus fuentes en lugar de introducida a mano). Las columnas siguientes cubren las obligaciones del artículo 7 y contienen los datos que necesita una migración poscuántica.

Hay dos campos que compensan el esfuerzo de añadirlos aunque ningún texto los exija: la superficie de despliegue (qué balanceador de carga, ingress, broker o par de TLS mutuo presenta el certificado) y un indicador de preparación poscuántica por activo, establecido a partir de mediciones y no de intenciones.

Ciclo de vida de las claves: qué documentar sobre las claves, no sobre los certificados

Un certificado es un objeto público con fecha de caducidad. La obligación relativa al ciclo de vida de las claves abarca material que nunca debe exportarse, por lo que el registro recoge datos sobre la clave y no la clave en sí. Para cada clave, o para cada clase de claves cuando tenga miles, registre: el método de generación y la fuente de entropía, el algoritmo y los parámetros aprobados, el perímetro de almacenamiento (software, HSM, almacén de claves en la nube con su nivel de protección), quién tiene derechos de administración y de recuperación, las disposiciones de copia de seguridad y custodia, el periodo de archivo de las claves que aún deben verificar firmas antiguas, los criterios de retirada, el procedimiento de destrucción y su evidencia, y el plan de respuesta ante compromiso con su responsable de decisión.

Distinga tres categorías, porque sus vías de migración son diferentes. Las claves de acuerdo de claves protegen la confidencialidad en tránsito, y el tráfico grabado puede descifrarse más adelante si el acuerdo de claves se rompe, motivo por el cual el escenario recolectar ahora, descifrar después hace del intercambio de claves lo primero que se debe migrar. Las claves de firma autentican, y una firma falsificada en 2035 no puede comprometer retroactivamente una sesión de hoy, de modo que los certificados pueden migrar después del intercambio de claves. Las claves de firma de larga duración son la excepción: las claves de firma de firmware y de software que deben seguir siendo fiables durante una década merecen atención ya, y NIST normalizó las firmas basadas en hash con estado precisamente para ese caso en SP 800-208 (LMS y XMSS, véase SP 800-208).

Descubrimiento: cómo poblar el registro

Ninguna fuente contiene por sí sola todos los certificados. Combine al menos cuatro y considere cada una de ellas parcial.

1. Consulte a las autoridades de certificación

Las bases de datos de las CA internas y sus cuentas en CA públicas enumeran todo lo que han emitido. Las emisiones públicas también son visibles en los registros de Certificate Transparency, que son la forma más rápida de encontrar certificados emitidos para sus dominios por equipos cuya existencia desconocía.

2. Escanee lo que realmente está a la escucha

Las comprobaciones de solo lectura contra un host muestran el certificado en producción, que a veces no es el que usted cree haber desplegado. Pruebe primero en un entorno que no sea de producción y confirme su autorización de escaneo.

# Inspect the presented chain and the key algorithm
openssl s_client -connect host.example.com:443 -servername host.example.com -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -serial -fingerprint -sha256 -text \
  | grep -E "Subject:|Issuer:|Not (Before|After)|Public Key Algorithm|Public-Key|Signature Algorithm|DNS:"

# Which key agreement group was negotiated (OpenSSL 3.5 or later for the ML-KEM groups)
openssl s_client -connect host.example.com:443 -servername host.example.com \
  -groups X25519MLKEM768:X25519 </dev/null 2>/dev/null | grep -E "Negotiated|Protocol"

3. Recorra los sistemas de ficheros y los almacenes de claves

# Certificates and keys on disk, with expiry, for one host
find /etc /opt /srv -type f \( -name "*.pem" -o -name "*.crt" -o -name "*.cer" \) 2>/dev/null \
  | while read -r f; do
      printf '%s\t' "$f"
      openssl x509 -in "$f" -noout -subject -enddate 2>/dev/null || echo "not a certificate"
    done

# Java keystore contents (read-only listing)
keytool -list -v -keystore /path/to/keystore.jks | grep -E "Alias name|Valid from|Signature algorithm"

4. Consulte las plataformas que gestionan los certificados por usted

Secretos de Kubernetes y recursos de cert-manager, gestores de certificados en la nube, almacenes de claves en la nube y particiones de HSM, service meshes que emiten certificados de TLS mutuo de corta duración, pasarelas de API, brokers de mensajería, configuración TLS de las bases de datos, concentradores VPN y servicios de firma de código. Los certificados de corta duración de una service mesh suelen registrarse mejor como una fila de política (emisor, algoritmo, duración, mecanismo de rotación) que como millones de filas individuales; indíquelo expresamente en el registro para que un revisor vea que la elección fue deliberada.

# cert-manager inventory across a cluster (read-only)
kubectl get certificates -A \
  -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,ISSUER:.spec.issuerRef.name,SECRET:.spec.secretName,RENEWAL:.status.renewalTime,EXPIRY:.status.notAfter

El primer día, la automatización importa más que la exhaustividad. Las instrucciones federales estadounidenses de OMB M-26-15 piden un inventario criptográfico automatizado y actualizado de forma continua, y ese principio es perfectamente trasladable: un registro actualizado por una tarea programada perdura, una hoja de cálculo actualizada por buena voluntad no.

Vincular el registro con el inventario criptográfico

El registro de certificados es una capa de un inventario más amplio. Manténgalos vinculados en lugar de fusionarlos: el registro de certificados responde a qué credenciales existen y cuándo caducan, mientras que el inventario criptográfico responde a qué algoritmos utilizan realmente su software y sus protocolos, incluidos el acuerdo de claves, el cifrado simétrico en reposo, las funciones hash y las bibliotecas. Una lista de materiales criptográficos (CBOM) es una forma práctica de expresar la capa de software, como se describe en qué es un CBOM; se trata de nuestra interpretación de las buenas prácticas, no de un requisito de DORA.

Los mismos artefactos sirven a varios marcos normativos, lo que justifica construirlos una sola vez.

En cuanto a las fechas, mantenga las distinciones con precisión. El requisito 12.3.3 de PCI DSS v4.0.1 es obligatorio desde el 31 de marzo de 2025. La hoja de ruta de implementación coordinada de la UE v1.1, publicada el 23 de junio de 2025, es una orientación coordinada para los Estados miembros y no un reglamento vinculante para las empresas: sitúa los inventarios criptográficos y las hojas de ruta nacionales a finales de 2026, la migración de los casos de uso de alto riesgo a finales de 2030 y la de riesgo medio a finales de 2035. NIST IR 8547 sigue siendo un borrador público inicial; propone declarar obsoletos los algoritmos vulnerables a la computación cuántica con seguridad de 112 bits después de 2030 y prohibir los algoritmos de clave pública vulnerables a la computación cuántica después de 2035, y debe citarse como borrador. El conjunto completo de hitos fechados figura en nuestro centro de normativa.

Errores frecuentes

• Registrar solo los certificados web públicos. El TLS mutuo entre servicios internos, los clientes de bases de datos, los brokers de mensajería, la firma de código y la identidad de dispositivos suelen superar en número a los públicos.
• Omitir la ubicación de la clave privada. Sin ella no puede responder a la única pregunta que importa durante un compromiso: dónde está la clave y quién puede acceder a ella.
• Tratar la caducidad como el único evento del ciclo de vida. Una revocación que nunca se ha ejercitado es un control no probado.
• Dejar que el alcance derive sin control. Cuando una función se reclasifica como esencial o importante, sus certificados entran en el alcance. Vuelva a aplicar la regla de alcance de forma periódica y conserve el resultado fechado.
• Confundir la migración de certificados con la migración del intercambio de claves. El acuerdo de claves híbrido protege el tráfico grabado hoy y ya puede desplegarse; los certificados poscuánticos dependen del soporte de las CA y de los clientes. Empiece por el intercambio de claves, como se explica en cripto-agilidad.
• Arrastrar algoritmos obsoletos anteriores a la norma. Los grupos TLS del borrador Kyber han sido sustituidos por los grupos normalizados ML-KEM; el grupo híbrido que debe buscar es X25519MLKEM768.

Siguiente paso: medir antes de documentar

Un registro construido a partir de intenciones envejece mal, así que rellene las columnas de algoritmo y de preparación a partir de mediciones. Para cada activo accesible desde el exterior que soporte una función esencial o importante, escanee su dominio con PQC Status para conocer las versiones de TLS negociadas, los grupos de acuerdo de claves ofrecidos, las suites de cifrado y la cadena de certificados, y después copie esos valores directamente en el registro. El escaneo describe únicamente la configuración TLS visible desde el exterior: no es una certificación ni una atestación de cumplimiento, y nuestra página de metodología expone con exactitud lo que demuestra y lo que no. Una vez registrada la superficie externa, repita los comandos de descubrimiento anteriores en los servicios internos a la escucha, asigne un responsable a cada fila y programe la exportación para que el registro se actualice por sí solo.