Por qué las claves SSH que nunca caducan son un riesgo para la seguridad.

Las claves SSH no caducan por defecto. Una vez que una clave pública se agrega al archivo authorized_keys de un servidor, permanece de confianza indefinidamente a menos que se elimine manualmente. Esto crea un acceso persistente y no rastreado que sobrevive a la salida de empleados, cambios de rol, desactivación de sistemas y obsolescencia de algoritmos. Un estudio del sector reveló que el 57 % de las organizaciones considera que la gestión de claves SSH es engorrosa y difícil, y que el 40 % carece de la automatización necesaria para garantizar su eliminación al finalizar la relación laboral. La acción recomendada: implementar un programa formal de gestión del ciclo de vida de las claves SSH que combine un inventario centralizado, calendarios de rotación basados ​​en riesgos, revocación automática ante eventos desencadenantes, protección de claves mediante HSM, claves efímeras para la automatización y revisiones de acceso al menos trimestrales.

Respuesta rápida: ¿Por qué las claves SSH que nunca caducan suponen un riesgo para la seguridad?

Las claves SSH que nunca caducan representan un riesgo de seguridad, ya que crean un acceso persistente e incontrolable que nadie puede revocar sin saber dónde buscar. Una clave colocada en un servidor por un empleado que ya no trabaja allí sigue siendo tan válida hoy como el día en que se creó. Una clave integrada en un script de CI/CD de un proyecto que finalizó hace dos años aún permite el acceso a todos los servidores donde se implementó esa clave pública. Las claves SSH no caducan por defecto (NIST NISTIR 7966 confirma que SSH no tiene un mecanismo de caducidad integrado), lo que significa que la gobernanza debe proporcionar lo que el protocolo no proporciona. Para conocer las implicaciones de cumplimiento de las claves que no caducan, consulte Cumplimiento de la administración de claves SSH . Para conocer los métodos de protección, consulte Los mejores métodos para proteger sus claves SSH.

Comprensión de las claves SSH

Las claves SSH son credenciales criptográficas que utiliza el protocolo SSH para autenticar clientes y establecer sesiones seguras. Imagínelas como un candado y su llave: la clave pública es el candado colocado en las máquinas remotas en el archivo authorized_keys; la clave privada es la llave física que lo abre, la cual conserva el usuario y nunca se transmite por la red.

Cuando un usuario intenta conectarse, el servidor SSH comprueba si la clave pública entrante se encuentra en authorized_keys. Si encuentra una coincidencia, el servidor envía un desafío criptográfico; el cliente firma el desafío con su clave privada sin transmitir la clave en sí; el servidor verifica la firma con la clave pública almacenada. Si la verificación es exitosa, el cliente se autentica sin necesidad de enviar ninguna contraseña a través de la red.

A diferencia de las contraseñas o los certificados digitales , las claves SSH no tienen fecha de caducidad. Una vez creadas, un par de claves permanece válido indefinidamente, a menudo mucho después de que el rol del usuario haya cambiado, haya abandonado la organización o el sistema se haya dado de baja. Esta característica crea uno de los puntos ciegos más persistentes y subestimados en la seguridad empresarial.

Cómo funcionan las claves SSH

La autenticación basada en claves SSH utiliza criptografía asimétrica. La clave privada se almacena en el cliente; la clave pública se ubica en ~/.ssh/authorized_keys en el servidor. El protocolo SSH utiliza el par de claves únicamente durante la autenticación para verificar la identidad, no para cifrar el tráfico de la sesión; una vez completada la autenticación, SSH cambia a una clave de sesión simétrica más rápida para todos los datos posteriores.

Dado que la clave privada nunca sale del dispositivo del cliente y los pares de claves asimétricas son resistentes a los ataques de fuerza bruta, la autenticación mediante clave SSH es intrínsecamente sólida. La debilidad no reside en la criptografía, sino en lo que sucede con esas claves a lo largo del tiempo cuando no existen controles del ciclo de vida. Para obtener una explicación completa sobre cómo funciona la autenticación, consulte Cómo funcionan las claves SSH.

Por qué las claves SSH no caducan y por qué eso es un problema.

SSH se diseñó para proporcionar una autenticación criptográfica robusta, pero no incluye mecanismos integrados para la caducidad, renovación o comprobación automática de la validez de las claves (NISTIR 7966). Como resultado, las organizaciones experimentan una proliferación descontrolada de claves SSH : la acumulación incontrolada de claves en servidores, cuentas y entornos. Las claves antiguas, sin usar y huérfanas se acumulan con el tiempo, creando puntos de acceso ocultos difíciles de rastrear y prácticamente imposibles de auditar sin herramientas específicas.

Las consecuencias de tener claves SSH no administradas y que nunca caducan incluyen:

• Acceso persistente

  Las claves siguen siendo válidas incluso después de que los empleados abandonen la organización o cambien de puesto. Los antiguos usuarios conservan el acceso a sistemas críticos, lo que genera importantes vulnerabilidades internas y una violación del principio de mínimo privilegio. Cuanto más tiempo permanezca la clave tras la salida del usuario autorizado, más difícil será detectarla y solucionarla.

• Llaves obsoletas

  Las cuentas deshabilitadas o inactivas aún pueden tener claves públicas activas en los servidores, dejando puntos de acceso ocultos que podrían ser explotados por atacantes que descubran las claves privadas correspondientes a través de la vulneración de los puntos finales, el acceso a las copias de seguridad o las filtraciones del repositorio.

• Duplicación de claves

  Al clonar, migrar o realizar copias de seguridad de servidores, las claves SSH integradas suelen copiarse junto con ellos. Esto crea múltiples copias de la misma clave en distintos sistemas, lo que extiende involuntariamente el acceso y aumenta la vulnerabilidad más allá de lo previsto en la implementación original.

• Pérdida de responsabilidad

  Con el tiempo, resulta difícil determinar quién creó una clave, quién es su propietario o si aún es necesaria. Sin un inventario criptográfico adecuado , correlacionar las claves con sus respectivos propietarios, sistemas o aplicaciones se vuelve prácticamente imposible, lo que dificulta enormemente la respuesta a incidentes, las auditorías y las revisiones de acceso.

• Sin limpieza automática

  Las claves creadas hace cinco o diez años siguen autenticándose sin interrupción. Sin un calendario definido para su rotación o revocación, las claves inactivas aumentan significativamente el riesgo de vulneración, abuso de privilegios y acceso no autorizado, que puede pasar desapercibido hasta que se produzca un incidente.

• Superficie de ataque oculta

  El efecto combinado de claves persistentes, obsoletas, duplicadas y sin supervisión crea una amplia superficie de ataque oculta en toda la organización. Los atacantes explotan estas claves huérfanas u olvidadas para moverse lateralmente entre sistemas y escalar privilegios sin provocar fallos de autenticación ni alertas.

Riesgos de seguridad, operativos y de cumplimiento

1. Acceso ilimitado

   Una clave que no caduca es, en la práctica, una puerta trasera permanente. Si la clave privada se ve comprometida mediante una brecha de seguridad en un punto final, una fuga en un repositorio Git, el acceso a copias de seguridad o dispositivos antiguos de empleados, los atacantes obtienen acceso ilimitado e indefinido a todos los servidores críticos donde se implementó esa clave pública.

2. Aumento de privilegios

   Las claves asociadas a cuentas privilegiadas (root, administrador, cuentas de servicio) se acumulan con el tiempo a medida que los empleados cambian de rol y los proyectos finalizan, pero las claves antiguas permanecen activas. Esto infringe el principio de mínimo privilegio y crea rutas de acceso que nunca se revisan ni se eliminan.

3. Gastos generales de gestión

   El seguimiento, la distribución, la rotación y la revocación manual de claves en cientos o miles de sistemas consume mucho tiempo y es propenso a errores. La incorporación de nuevos usuarios se retrasa debido a la necesidad de aprovisionar el acceso con cuidado; la desvinculación de usuarios es arriesgada porque las claves olvidadas dejan puntos de acceso abiertos sin supervisión.

4. Cero visibilidad durante los incidentes

   Sin marcas de tiempo de uso de claves, fechas de vencimiento ni registros centralizados, los responsables de la respuesta a incidentes no pueden determinar qué claves están activas, quién las utiliza ni a qué sistemas se ha accedido. Esto dificulta el análisis forense y prolonga considerablemente las labores de recuperación.

5. Fallos de cumplimiento

   Las normas NIST 800-53, los controles CIS, la ISO 27001, la PCI DSS y la SOX exigen la rotación de credenciales, revisiones de acceso y una correcta vinculación de identidades. Las claves SSH que no caducan entran en conflicto directo con estos requisitos. Para consultar el mapa de cumplimiento completo, vea la sección " Cumplimiento de la administración de claves SSH".

6. Riesgos de la automatización no gestionada

   Las canalizaciones de CI/CD, las tareas programadas (cron jobs) y los scripts de integración dependen de claves SSH que rara vez se auditan, rotan o eliminan. Dado que muchas organizaciones carecen de una gestión centralizada de claves y dependen de procesos manuales, las claves de automatización son objetivos ideales para el robo de claves: suelen tener privilegios, una larga vida útil y una supervisión mínima.

Propiedad del ciclo de vida de la clave SSH

Etapa del ciclo de vida	Actividad	Propietario	Evidencia presentada
Generation	Cree un par de claves con el algoritmo aprobado (Ed25519 preferido, RSA-3072 mínimo); regístrelo en el inventario centralizado.	Plataforma de gestión de claves SSH, ya sea para usuarios o automatizada.	Registro de generación con algoritmo, huella digital y propósito
Despliegue	Implemente la clave pública solo en servidores autorizados; documente los sistemas de destino y el alcance del acceso.	Plataforma de gestión de claves SSH	Registro de despliegue con lista de servidores de destino y ámbito de acceso autorizado
Monitoring	Registra todas las sesiones SSH con la huella digital de la clave, la dirección IP de origen, la marca de tiempo y el destino; revisa si hay anomalías.	Operaciones de seguridad; alertas SIEM automatizadas	Registros de sesión para cumplimiento y respuesta a incidentes
Revisión periódica	Revise todas las autorizaciones de claves SSH al menos trimestralmente; revoque las claves huérfanas o no autorizadas; confirme la propiedad.	Custodio de claves; revisor de acceso	Registro de revisión fechado con las medidas tomadas
Rotación	Generar clave de reemplazo; implementar nueva clave pública; verificar acceso; eliminar la clave pública antigua de todos los servidores.	Plataforma automatizada de gestión de claves SSH	Registro de rotación con fecha, tipo de activación y operador.
Revocación	Eliminar la clave pública de todos los archivos authorized_keys inmediatamente al activarse el evento.	Administrador de disparadores o claves automatizado	Registro de revocación con fecha de activación y confirmación de finalización

Factores que desencadenan la rotación: cuándo actuar de inmediato

• Salida de un empleado o cambio de puesto: Revocar inmediatamente todas las claves SSH que posea la persona que se marcha o cambia de rol en todos los servidores a los que tenía acceso. Documentar el tiempo transcurrido desde la notificación de salida hasta la finalización de la revocación como prueba de cumplimiento.
• Compromiso de seguridad clave sospechado o confirmado: Revocar inmediatamente la clave afectada en todos los servidores donde esté autorizada; generar e implementar una clave de reemplazo; investigar el alcance de la exposición.
• Repositorio o exposición de imágenes: Si se encuentra una clave privada en un repositorio de código, una imagen de contenedor o un artefacto compartido, considérelo inmediatamente como comprometido y siga el flujo de trabajo de respuesta a incidentes.
• Algoritmo obsoleto: Cualquier clave que utilice un algoritmo obsoleto (DSA es criptográficamente vulnerable; RSA-1024 ya no se recomienda; ssh-rsa con SHA-1 quedó obsoleto en OpenSSH 8.8) debe reemplazarse por un algoritmo aprobado. Consulte Comparación de claves SSH para orientación sobre algoritmos.
• Desmantelamiento del sistema: Revocar todas las claves SSH asociadas a los sistemas dados de baja; auditar los sistemas restantes para confirmar que no persista ninguna clave pública del host dado de baja en sus archivos authorized_keys.

Política de acceso y requisitos de evidencia de auditoría

• Requisitos de la política: La política de gestión de claves SSH debe definir criptoperíodos por nivel de riesgo (claves de usuario cada 90 días; claves de servicio/automatización cada 180 días; claves de alto riesgo cada 30 a 90 días); requisitos de algoritmo (Ed25519 preferido; RSA-3072 mínimo; DSA prohibido); prohibición de claves compartidas; prohibición de claves codificadas en el código y las imágenes; calendario de revisión de acceso (como mínimo trimestral).
• Evidencia del inventario: Un inventario actualizado que incluya cada clave, su huella digital, propietario, servidores de implementación, ámbito de acceso, fecha de creación y fecha de última rotación. Sin esto, no se puede demostrar ningún otro control de cumplimiento.
• Registros de rotación y revocación: Registros fechados que muestran que las claves se rotaron según lo programado o al activarse un evento, y registros de revocación que muestran el tiempo transcurrido desde el evento desencadenante hasta la finalización de cada clave revocada.
• Registros de sesión: Registros de sesiones SSH privilegiadas con huella digital de clave, IP de origen, marca de tiempo y sistema de destino, conservados durante el período requerido por los marcos de cumplimiento aplicables.
• Registros de revisión de acceso: Registros trimestrales fechados que muestran qué llaves fueron revisadas, el estado de propiedad y las medidas tomadas.

Mitigación de riesgos de claves SSH que nunca caducan

1. Gestión de claves centralizada

   Una plataforma centralizada de gestión de claves SSH ofrece: visibilidad completa de todas las claves, incluyendo propietario, propósito e historial de uso; aplicación de políticas para intervalos de rotación, tipos de claves aprobados y longitudes mínimas de clave; aprovisionamiento y desaprovisionamiento automatizados; y auditoría e informes para la verificación del cumplimiento. La centralización transforma las claves SSH, que antes eran elementos no gestionados, en credenciales responsables y auditables. Consulte SSH Secure para obtener más información sobre el enfoque de la plataforma.

2. Rotación clave en el cronograma y en el evento

   La rotación periódica garantiza que las claves SSH tengan una vida útil corta en relación con su nivel de riesgo. Calendario recomendado: claves de usuario cada 90 días; claves de cuentas de servicio y automatización cada 180 días. Los eventos desencadenantes siempre anulan el calendario (desvinculación, vulneración de seguridad, obsolescencia). Automatice la rotación mediante herramientas centralizadas en lugar de depender de procesos manuales que no escalan bien y generan inconsistencias que dan lugar a problemas de auditoría.

3. Revocación de clave

   Las claves asociadas a empleados que se marchan, sistemas retirados o casos sospechosos de vulneración de seguridad deben revocarse de inmediato. La revocación implica eliminar las claves públicas de todos los archivos authorized_keys, actualizar el inventario centralizado y registrar la finalización del proceso para su auditoría. La revocación manual en cientos de servidores es el punto débil más frecuente de las organizaciones tras la marcha de un empleado. La revocación automatizada, activada por los sistemas de recursos humanos o los eventos del proveedor de identidad, es la alternativa más fiable.

4. Adopte claves SSH efímeras

   En lugar de claves estáticas, genere credenciales SSH bajo demanda, válidas solo por un breve periodo (minutos u horas). Las claves efímeras eliminan la exposición prolongada a claves estáticas, caducan automáticamente y se integran con proveedores de identidad y flujos de trabajo de acceso justo a tiempo. Incluso si se expone, el acceso del atacante es limitado. Consulte « Transformación de claves SSH estáticas en identidades de carga de trabajo de corta duración» para conocer el enfoque de implementación completo.

5. Avanzar hacia certificados SSH de corta duración

   Las organizaciones con programas de seguridad avanzados reemplazan las claves estáticas con certificados SSH de corta duración emitidos por una CA de confianza. Ventajas: caducidad integrada a nivel de protocolo; fuerte vinculación de identidad para cada usuario o servicio; modelo de confianza centralizado que elimina la gestión de authorized_keys por servidor; y evidencia de cumplimiento generada automáticamente por el registro de emisión de la CA. Consulte la comparación entre claves SSH y certificados SSH.

6. Fortalecimiento operativo del acceso SSH

   El endurecimiento del servidor limita las acciones de un atacante incluso con una clave válida: desactiva el inicio de sesión como root; desactiva la autenticación por contraseña; limita el número máximo de intentos de autenticación (MaxAuthTries); restringe el acceso por usuario, grupo o dirección IP de origen; implementa algoritmos criptográficos robustos en sshd_config; desactiva el reenvío de agentes a menos que sea estrictamente necesario. Consulta « Los mejores métodos para proteger tus claves SSH» para ver la lista completa de medidas de endurecimiento.

7. Política y seguimiento

   Una política formal de gestión de claves SSH debe: mantener un inventario actualizado de todas las claves; definir la revocación inmediata en caso de vulneración; supervisar la filtración o exposición de claves privadas; y exigir revisiones trimestrales de acceso para detectar y eliminar claves huérfanas, obsoletas, duplicadas o no autorizadas. La monitorización de sesiones debe configurarse para alertar sobre patrones de acceso anómalos.

Respuesta ante incidentes de vulneración de clave SSH

1. Revocación inmediata: Revocar la clave comprometida en todos los servidores donde esté autorizada; confirmar que la revocación se haya completado en cada servidor; registrar la marca de tiempo de finalización.
2. Generación e implementación de claves de reemplazo: Generar un nuevo par de claves utilizando un algoritmo aprobado (se prefiere Ed25519; RSA-4096 para compatibilidad con versiones anteriores) dentro de un HSM cuando sea posible; implementar la nueva clave pública en todos los servidores autorizados; verificar que se haya restablecido el acceso para el usuario legítimo.
3. Investigación del alcance de la exposición: Identificar todos los sistemas a los que podría acceder la clave comprometida; revisar los registros de la sesión SSH para detectar actividad durante el período en que se sospecha que se produjo la vulneración; determinar si se produjo algún acceso no autorizado y qué datos o sistemas estuvieron involucrados.
4. Notificación a las partes interesadas: Notificar a los responsables de seguridad, a los propietarios de los sistemas afectados y, si se pudo acceder a datos regulados a través de la clave comprometida, a los organismos reguladores o a las personas afectadas, de acuerdo con los requisitos de notificación de la violación de seguridad.
5. Análisis de la causa raíz y actualización de medidas de control: Documentar cómo se expuso la clave (almacenamiento de archivos en un host comprometido, codificada directamente en el código, clave huérfana no revocada al momento de la salida); actualizar los controles para subsanar la deficiencia (migrar al almacenamiento HSM, implementar la desvinculación automatizada, agregar el escaneo de secretos a las canalizaciones de CI/CD).

Cómo puede ayudar la consultoría de cifrado

En Encryption Consulting, comprendemos los desafíos que enfrentan las empresas al administrar claves SSH a gran escala. SSH Secure ofrece seguridad integral del ciclo de vida de las claves y una visibilidad completa:

1. Mapeo centralizado de visibilidad y propiedad

   El descubrimiento, tanto con agente como sin él, localiza todas las claves SSH en servidores y equipos de usuario. Todas las claves se almacenan en un inventario unificado con detalles de propiedad y uso, lo que elimina las claves huérfanas y garantiza la total transparencia en todo el entorno.

2. Rotación de claves a pedido y programada

   SSH Secure permite la rotación de claves tanto bajo demanda como programada. Con una sola acción, las claves se pueden rotar automáticamente, lo que garantiza una corta vida útil y reduce el riesgo de vulneración, con visibilidad completa de las credenciales activas en todo momento.

3. Revocación de claves bajo demanda

   SSH Secure elimina el riesgo de claves SSH no caducadas mediante una sólida revocación. Las claves asociadas a empleados que se marchan, sistemas retirados o posibles vulnerabilidades se pueden desactivar de inmediato, confirmándose la propagación en todos los servidores. La revocación centralizada garantiza que no queden claves olvidadas o huérfanas en producción.

4. Orquestación automatizada del ciclo de vida de las claves

   Más allá de la rotación y la revocación, SSH Secure automatiza todo el ciclo de vida: generación segura, rotación basada en políticas, expiración programada y revocación. Reduce el esfuerzo manual, garantiza el cumplimiento continuo de los estándares de seguridad y elimina las brechas operativas derivadas de errores humanos.

5. Claves efímeras y vinculadas a la sesión

   Para operaciones sensibles, SSH Secure emite claves efímeras vinculadas a la sesión que caducan automáticamente. Este enfoque garantiza el acceso con privilegios mínimos, reduce el impacto de las credenciales comprometidas y elimina la exposición a largo plazo que suponen las claves estáticas.

6. Protección integrada de HSM

   Todas las claves privadas están protegidas dentro de los HSM : no se pueden exportar y son a prueba de manipulaciones. Las claves se generan mediante RSA, ECDSA y Ed25519. Ni siquiera una vulneración del sistema operativo o el rastreo de memoria pueden extraer las claves del perímetro del hardware del HSM.

7. Control basado en políticas para operaciones clave

   Todas las operaciones clave (generación, aprobación, rotación, revocación) se rigen por controles basados ​​en políticas que garantizan la coherencia en todo el entorno, reducen los errores manuales y mantienen estándares de seguridad adaptables a los requisitos reglamentarios.

8. Monitoreo continuo, auditoría y preparación para el cumplimiento

   Monitorización en tiempo real con registro detallado de eventos y detección de anomalías. Integración de Splunk y Loki-Grafana para visualización y alertas. Registros descargables e informes de cumplimiento detallados listos para la revisión del auditor. La auditoría centralizada con alertas basadas en políticas permite una gestión proactiva y una respuesta más rápida ante incidentes.

Conclusión

Las claves SSH que nunca caducan representan un riesgo oculto pero grave para la seguridad empresarial. Las claves olvidadas, huérfanas y sin gestionar proporcionan acceso persistente, permiten la escalada de privilegios y crean puntos de entrada no supervisados ​​en la infraestructura, invisibles tanto para los equipos de seguridad como para los auditores de cumplimiento. La solución requiere abordar las limitaciones de SSH por diseño: caducidad, programación de rotación, propiedad centralizada y revocación automática en eventos del ciclo de vida.

Un programa formal de gestión del ciclo de vida de las claves SSH, que combina un inventario centralizado, rotación basada en riesgos, revocación automatizada, protección de claves mediante HSM, claves efímeras para automatización y registro continuo de sesiones, transforma el acceso SSH, que antes era un riesgo no gestionado, en un mecanismo de autenticación auditable, controlado y conforme a la normativa. Para obtener más información, consulte « Los mejores métodos para proteger sus claves SSH» , «Cumplimiento de la gestión de claves SSH» y «Transformación de claves SSH estáticas en identidades de carga de trabajo de corta duración».

Preguntas frecuentes

¿Por qué las claves SSH no caducan por defecto?

SSH se diseñó para proporcionar una autenticación criptográfica robusta sin contraseña a través de la red. La caducidad se consideró una decisión de política operativa, no un control del protocolo. El documento NISTIR 7966 del NIST confirma que SSH no cuenta con mecanismos integrados para la caducidad, renovación o comprobación automática de la validez de las claves. La gobernanza debe proporcionar los controles de caducidad que el protocolo no ofrece.

¿Cuáles son los riesgos de seguridad de las claves SSH que nunca caducan?

Seis categorías: acceso ilimitado (la exposición de la clave privada otorga acceso válido indefinidamente a todos los servidores autorizados); aumento progresivo de privilegios (las claves asignadas a root o admin se acumulan con los cambios de rol); sobrecarga de gestión (el seguimiento manual no es escalable); visibilidad nula de incidentes (sin marcas de tiempo ni registros centralizados); fallos de cumplimiento (NIST 800-53, ISO 27001, PCI DSS y CIS requieren rotación y revisiones de acceso); y riesgos de automatización (las claves de la canalización CI/CD rara vez se auditan o rotan).

¿Con qué frecuencia se deben rotar las claves SSH?

Las claves SSH de los usuarios se renuevan cada 90 días; las claves de las cuentas de servicio y automatización, cada 180 días; y las claves con acceso de administrador o de producción, cada 30 a 90 días. Los eventos desencadenantes anulan el cronograma: la salida de un empleado, la sospecha de una intrusión, la obsolescencia de un algoritmo y la desactivación del sistema requieren una acción inmediata.

¿Cuál es la diferencia entre la rotación de claves SSH y la revocación de claves SSH?

La rotación reemplaza una clave existente por una nueva, manteniendo el acceso (se genera una nueva clave, se implementa una nueva clave pública y se elimina la clave antigua). Es una actividad programada del ciclo de vida. La revocación consiste en la eliminación inmediata de una clave en respuesta a un evento desencadenante (abandono, vulneración de la seguridad, violación de políticas), lo que finaliza el acceso sin generar una clave de reemplazo para el mismo usuario.

¿En qué se diferencian las claves SSH efímeras de las claves SSH de larga duración?

Las claves de larga duración persisten indefinidamente hasta que se eliminan manualmente de cada servidor. Las claves efímeras se generan bajo demanda para una sesión o período de tiempo específico y caducan automáticamente. Incluso si el atacante queda expuesto, su acceso finaliza al cerrarse dicho período. Son especialmente eficaces en pipelines de CI/CD, donde las claves estáticas integradas se acumulan y rara vez se renuevan.

¿Qué pruebas necesitan los auditores de cumplimiento para la gestión del ciclo de vida de las claves SSH?

Inventario de claves actual (cada clave con su propietario, ubicación, fecha de creación y fecha de última rotación); registros de revisión de acceso (trimestrales, con las acciones tomadas); evidencia de rotación (fecha, tipo de activación, operador); evidencia de revocación (fecha de activación, fecha de finalización por empleado que se marchó); registros de sesión (huella digital de la clave, IP de origen, marca de tiempo, destino); y política escrita de gestión de claves SSH con criptoperiodos y procedimiento de respuesta a incidentes.