ENS desde dentro (XXVIII): Protección de claves criptográficas (op.exp.10) — un certificado válido no demuestra que las claves estén protegidas

Qué exige realmente op.exp.10 del ENS: qué fases del ciclo de vida de una clave hay que proteger, qué algoritmos están autorizados, por qué hace falta un inventario de certificados y qué evidencia enseñar al auditor.

Una captura con un certificado válido y una A+ en TLS es la evidencia más fácil de conseguir de op.exp.10. También es la que menos dice sobre quién custodia las claves.

Este artículo forma parte de la serie ENS desde dentro.

👉 Puedes ver la guía completa aquí:

https://www.handersonboratto.com/ens-desde-dentro/

👉 Si es tu primera vez en la serie, empieza por aquí:

https://www.handersonboratto.com/blog/que-es-ens/

👉 O continúa con el artículo anterior:

https://www.handersonboratto.com/blog/ens-registro-gestion-incidentes-op-exp-9/

Hasta ahora, la serie de explotación hablaba de procesos: mantener, cambiar, detectar, registrar. op.exp.10 es distinto, porque habla de un objeto concreto: las claves y los certificados que sostienen el cifrado de todo lo demás. Si se pierden, caducan o se filtran, no falla un proceso: falla la confianza.

Qué exige realmente el control

El control pide proteger las claves criptográficas durante todo su ciclo de vida, no solo mientras están en uso. Son cinco fases: generación, transporte hasta el punto de explotación, custodia durante la explotación, archivo cuando se retiran de la explotación activa y destrucción final.

Dos matices importantes. La generación se hace en un medio aislado de los de explotación, y el archivo posterior también se guarda en medios aislados. Es decir, la clave no nace ni se archiva en el mismo servidor donde trabaja.

Además, solo se pueden usar algoritmos y parámetros autorizados por el CCN. Y no basta con elegirlos una vez: hay que comprobar periódicamente que siguen incluidos en la última versión de la guía CCN-STIC-807 de criptología de empleo en el ENS, o en el catálogo del acuerdo europeo SOG-IS. Lo que era aceptable hace cinco años puede dejar de serlo.

Por último, el Responsable del Sistema mantiene un inventario de los certificados en uso, con las medidas aplicadas en cada fase que corresponda.

La evidencia en la práctica

La evidencia que pide el control es una captura de pantalla de la información del certificado SSL de un sitio web. Se obtiene con un analizador público de TLS, o desde el propio navegador, y se puede ejecutar contra cualquier servicio con HTTPS.

Lo que conviene que se vea en la captura: la autoridad que emite el certificado, que debe ser reconocida; el tipo y la longitud de la clave y el algoritmo de firma; las fechas de validez; la versión de TLS más alta soportada; si hay HSTS y la calificación global.

Es útil reunir más de un ejemplo, de familias distintas. Un servicio corporativo en la nube, un portal propio expuesto a internet y la comunicación de una herramienta de seguridad, como el agente del EDR con su plataforma, cubren tres situaciones diferentes: quién custodia la clave en cada caso no es lo mismo.

Dónde se queda corta esa evidencia

Aquí viene lo que creo que más se pasa por alto. Un certificado válido demuestra que el canal está cifrado hoy. No demuestra nada de lo que el control pide en realidad.

Cuando el certificado pertenece a un proveedor, como el servicio de correo en la nube o la plataforma del EDR, las claves las genera y custodia el proveedor. La captura prueba que el proveedor lo hace bien, no que tu organización protege sus claves. Solo el certificado de un servicio que tú gestionas, como un portal propio, enseña claves que te corresponden a ti.

Tampoco prueba el ciclo de vida. Una captura no dice dónde se generó la clave, cómo llegó al servidor, quién tiene acceso a ella, dónde se archiva la anterior ni cómo se destruye. Para eso hace falta el inventario de certificados con las medidas de cada fase, y una prueba de que se comprueban los algoritmos contra la guía vigente.

Y hay un tercer detalle, casi trivial pero que cuesta en una auditoría: la fecha de validez. Si la captura muestra un certificado cuyo periodo ya terminó, aunque se renovase después, el auditor ve un certificado caducado. Conviene capturar siempre una vigente y con la fecha visible.

La lección práctica

Si algo me llevo de este control es que la captura del certificado es el principio de la evidencia, no la evidencia entera: lo que demuestra op.exp.10 es el inventario y el ciclo de vida que hay detrás.

Mi recomendación: empieza por el inventario. Una hoja con un certificado por fila, quién es el responsable, cuándo caduca, dónde está la clave y qué se hace en cada fase del ciclo de vida. Revísala cuando se acerquen las caducidades y, al menos una vez al año, contrasta los algoritmos con la guía vigente. La captura del analizador, con fecha, va como anexo a una fila de esa hoja.

Este post forma parte de la serie "ENS desde dentro", donde comparto cómo se implementan y auditan en la práctica las medidas del Esquema Nacional de Seguridad. Si te está siendo útil, puedes suscribirte a la newsletter para recibir cada entrega, o descargar el checklist "Documentación para una auditoría ENS" con los 8 bloques de evidencia que un auditor va a pedirte.