Transforme las claves SSH estáticas en identidades de carga de trabajo de corta duración.

El par de claves SSH ha sido la unidad predeterminada de acceso a máquinas y administradores durante más de dos décadas, y esa longevidad es precisamente el problema. Una clave privada SSH estática es una credencial de portador sin fecha de caducidad, sin requisito de autenticación multifactor nativa y, con frecuencia, sin registro de auditoría. Funciona igual el día en que se genera y el día en que el ingeniero que la creó deja la empresa. En un mundo donde las cargas de trabajo son efímeras, escalan continuamente y son cada vez más autónomas, una credencial diseñada para durar para siempre no se ajusta bien a una infraestructura que se reconstruye constantemente.

Este artículo defiende la idea de tratar el acceso SSH como una identidad de carga de trabajo efímera en lugar de una clave secreta permanente. Este cambio no es teórico. El mismo patrón que sustituyó los archivos de contraseñas por el inicio de sesión único ahora está sustituyendo los archivos de claves estáticas por identidades certificadas y rotadas automáticamente, emitidas en el momento del acceso. Analizaremos por qué este cambio es importante ahora, los fundamentos técnicos de los certificados SSH y el marco de identidad de carga de trabajo SPIFFE/SPIRE, los riesgos operativos de no hacer nada y una ruta de migración práctica que no interrumpa la automatización de la que depende su negocio.

Por qué esto importa ahora

Tres fuerzas han convergido para convertir las claves SSH estáticas en una preocupación a nivel de la junta directiva, en lugar de una tarea administrativa.

Las identidades de las máquinas ahora dominan el panorama.

Las identidades no humanas han superado silenciosamente a las cuentas humanas por un amplio margen. Un estudio de CyberArk de 2025 reveló que las identidades de máquina superan a las humanas en una proporción de más de 80 a 1, y casi la mitad posee acceso privilegiado o sensible. Otras mediciones sitúan esta proporción aún más alta en entornos nativos de la nube. Cada una de estas identidades necesita autenticarse, y una gran parte aún lo hace con una clave SSH estática o un secreto equivalente de larga duración. Esta magnitud por sí sola hace que la gestión manual de claves sea insostenible.

El riesgo siempre ha existido, y los atacantes lo saben.

El inventor de SSH, Tatu Ylonen, fue el autor de la guía del Instituto Nacional de Estándares y Tecnología de EE. UU . sobre el tema, y ​​ha sido tajante al afirmar que el problema se ha ido agravando durante los últimos 20 años porque el acceso entre sistemas pasó desapercibido para la mayoría de los programas de seguridad. Las relaciones de confianza SSH no gestionadas permiten que un atacante que compromete un sistema pueda acceder a muchos, y las claves huérfanas pertenecientes a exempleados actúan como puertas traseras permanentes e indetectables.

Las herramientas modernas finalmente hacen que la alternativa sea práctica.

Hasta hace poco, el principal obstáculo para el acceso SSH efímero era la fricción operativa. Eso ha cambiado. La compatibilidad con certificados OpenSSH, la integración con proveedores de identidad y los marcos de identidad de código abierto consolidados permiten ahora que las empresas emitan credenciales SSH con una validez de horas en lugar de años, con renovación automática imperceptible para las cargas de trabajo. La autenticación basada en certificados garantiza la seguridad ante posibles fallos en la gestión de claves: si nadie renueva una credencial, el acceso simplemente caduca en lugar de permanecer activo indefinidamente.

Cómo funcionan las credenciales SSH de corta duración

La sustitución de una clave estática por una identidad temporal se basa en dos pilares fundamentales: los certificados SSH, que encapsulan una clave pública en metadatos firmados y con fecha de caducidad, y el marco de identidad de carga de trabajo SPIFFE/SPIRE, que define la naturaleza de una carga de trabajo antes de emitir cualquier credencial. Comprender por qué una clave estática presenta vulnerabilidades estructurales, cómo los certificados solucionan este problema y dónde encaja la identidad de carga de trabajo es la base para una migración que no interrumpa la automatización.

Por qué una clave SSH estática es estructuralmente débil

Una clave SSH estándar prácticamente no contiene información sobre quién o qué la utiliza. Funciona como una llave física: su posesión otorga acceso, y campos como el comentario son opcionales y el servidor no los interpreta. No hay vinculación de identidad, ni caducidad, ni autoridad central. El acceso se concede añadiendo una clave pública a un archivo authorized_keys en cada servidor, lo que significa que la confianza está descentralizada y resulta prácticamente imposible de controlar a gran escala.

El propio SSH nunca fue diseñado para solucionar este problema. El informe interno del NIST sobre el tema afirma claramente que SSH no tiene mecanismos integrados para la caducidad, renovación o comprobación automática de la validez de las claves, razón por la cual la acumulación incontrolada, conocida como proliferación de claves, es tan común.

Certificados SSH de corta duración

Un certificado SSH conserva el par de claves habitual, pero encapsula la clave pública en metadatos firmados: un nombre principal que identifica al usuario o servicio, un período de validez y restricciones opcionales como comandos obligatorios o restricciones de IP de origen. Una autoridad de certificación de confianza firma cada certificado, por lo que los servidores confían en la CA en lugar de mantener entradas de claves autorizadas por usuario, y la expiración garantiza que las credenciales comprometidas caduquen automáticamente. Este es el mismo modelo que utilizan organizaciones como Google, Netflix y Uber para gestionar el acceso a servidores a gran escala.

El proceso de emisión típico es sencillo. El usuario se autentica mediante inicio de sesión único, la utilidad de inicio de sesión genera un nuevo par de claves y solicita un certificado firmado a la CA. La CA devuelve un certificado válido solo durante la sesión de trabajo, generalmente de ocho a veinte horas, tras lo cual el ingeniero simplemente se vuelve a autenticar. Algunas implementaciones emiten certificados que se renuevan diariamente o caducan después de un solo día laborable, mientras que las plataformas de acceso privilegiado emiten un nuevo certificado para cada conexión, que puede durar solo unos minutos. La característica fundamental es la misma: la credencial es efímera y el host confía en una autoridad y una decisión política, en lugar de en una lista de claves permanente.

Cómo se configuran los servidores para confiar en la CA

En el lado del servidor, el cambio es mínimo. La clave pública de la CA se coloca en cada host y se le indica a sshd que confíe en ella mediante la directiva TrustedUserCAKeys, con un archivo AuthorizedPrincipalsFile que asigna las entidades principales del certificado a las cuentas locales permitidas. También se pueden emitir certificados de host para que los clientes ya no tengan que aceptar la solicitud de confianza en el primer uso, que la mayoría de los usuarios aceptan sin cuestionar. Dado que la autenticación de clave pública puede ejecutarse en paralelo durante la transición, la migración puede ser incremental en lugar de una migración completa.

Identificación de carga de trabajo con SPIFFE y SPIRE

Los certificados resuelven el problema del formato de credenciales, pero por sí solos no responden a la cuestión fundamental de cómo una carga de trabajo demuestra su naturaleza antes de que se emita cualquier credencial. Aquí es donde entran en juego SPIFFE, el marco de identidad segura para la producción, y su implementación de referencia, SPIRE. Ambos son proyectos finalizados de la Cloud Native Computing Foundation.

SPIFFE asigna a cada carga de trabajo una identidad estructurada, el ID de SPIFFE, expresado como una URI como spiffe://prod.acme.com/billing/api. Un sistema compatible con SPIFFE emite una credencial de corta duración, el Documento de Identidad Verificable de SPIFFE (SVID), que puede ser un certificado X.509 o un JWT. La idea arquitectónica clave es que la carga de trabajo no implementa conjuntamente ningún secreto de autenticación. En su lugar, el agente local inspecciona las propiedades verificables de la carga de trabajo, como su espacio de nombres de Kubernetes, cuenta de servicio o imagen de contenedor, y solo entonces emite una identidad. La documentación de SPIFFE describe cómo, para minimizar la exposición a una clave filtrada o comprometida, todas las claves privadas y los certificados son de corta duración, se rotan con frecuencia y se rotan automáticamente.

SPIRE gestiona el ciclo de vida. Un servidor central SPIRE firma y emite los SVID, mientras que agentes SPIRE ligeros en cada nodo verifican las cargas de trabajo y obtienen las credenciales. Fundamentalmente, la renovación es invisible para la aplicación. El agente SPIRE renueva los SVID a la mitad de su período de validez, por lo que un certificado de una hora se renueva cada treinta minutos sin intervención humana, y las credenciales almacenadas en caché permanecen válidas durante una breve interrupción del servicio. La clave reside en la seguridad: una credencial comprometida durante una hora tiene un período de exposición máximo de sesenta minutos, mientras que una credencial anual expone 8,760 horas.

Donde SSH se encuentra con SPIFFE

Ambos enfoques son complementarios. En lugar de depender de claves SSH estáticas, una implementación compatible con SPIFFE puede emitir certificados temporales para el acceso a la infraestructura, normalmente a través de un servidor o cliente SSH que valida certificados firmados por una CA gestionada por SPIRE, o intercambiando una identidad SPIFFE por credenciales SSH temporales. Esto reduce el riesgo de que las claves se vean comprometidas y simplifica la gestión de claves al eliminar por completo la clave estática. Para tareas automatizadas, incluso se puede intercambiar un JWT-SVID emitido por SPIRE con un servicio de identidad en la nube como AWS STS para obtener credenciales temporales por tarea, sin otorgar privilegios persistentes a los agentes CI compartidos.

¿Cuánto te cuestan realmente las claves SSH estáticas?

Comprender los modos de fallo del statu quo aclara por qué merece la pena el esfuerzo de la migración.

Supervisión	Por que sucede	Consecuencia
Claves huérfanas y obsoletas	Las claves SSH nunca caducan. y rara vez se revocan cuando el personal se marcha o cambia de puesto.	Los exempleados y contratistas conservan un acceso no controlado, a menudo privilegiado, mucho después de su partida.
Acceso a las sombras	Los ingenieros generan claves de forma ad hoc, sin un flujo de trabajo de aprobación.	El acceso privilegiado elude la gobernanza central de identidades y evita las auditorías.
Movimiento lateral	Las relaciones de confianza entre sistemas forman redes de confianza no supervisadas.	Una sola clave comprometida permite a un atacante operar en múltiples sistemas.
sin responsabilidad	Las claves no tienen ninguna identidad y las conexiones no están vinculadas a ninguna persona.	La investigación forense y la respuesta ante incidentes son lentas y poco concluyentes.
Exposición al cumplimiento	Las claves no gestionadas infringen los principios de mínimo privilegio y control de acceso.	Hallazgos en GDPR, PCI DSS, HIPAAy regímenes similares.

La expansión urbana descontrolada es la norma, no la excepción.

La magnitud de la brecha en el inventario es sorprendente. Un estudio realizado por Keyfactor y el Instituto Ponemon reveló que aproximadamente el 57 % de las organizaciones carecen de un inventario preciso de sus claves SSH. Una encuesta del Instituto Ponemon de 2014, ampliamente citada y encargada por Venafi, halló que las organizaciones poseen un promedio de aproximadamente 23 000 claves SSH, la gran mayoría sin gestionar y sin fecha de caducidad, autenticación multifactor (MFA) ni, a menudo, un registro de auditoría. El mismo estudio de Keyfactor/Ponemon informó que alrededor del 53 % de las organizaciones no cuentan con un sistema centralizado y dependen de procesos manuales, como hojas de cálculo, para gestionar las claves SSH, un enfoque que no es escalable y es propenso a errores.

El organismo de normalización ya se ha pronunciado al respecto.

Esta preocupación no es inventada por el proveedor. En 2015, el NIST publicó el informe NISTIR 7966, Seguridad de la administración de acceso interactivo y automatizado mediante Secure Shell (SSH) , que advierte que las concesiones de SSH suelen elevar los privilegios, a menudo al nivel de administrador, y que surgen diversas vulnerabilidades si no se implementan procesos adecuados de aprovisionamiento, terminación y supervisión. El informe señala que muchas organizaciones ni siquiera saben cuántas claves SSH tienen configuradas ni quién posee copias de ellas.

Desafíos migratorios que deben planificarse

La migración a identidades de corta duración introduce su propia disciplina operativa, y es mejor reconocerlo desde el principio. La autoridad central se convierte en infraestructura crítica: la disponibilidad del servidor SPIRE es crucial, y aunque los agentes almacenan las credenciales localmente para superar interrupciones breves, la ruta de emisión debe tener alta disponibilidad. También se requiere un trabajo de integración real. La identidad emitida en el momento del despliegue se origina cada vez más en sistemas CI/CD, y un marco que no certifique de forma nativa las plataformas de compilación puede obligar a los equipos a volver a usar tokens de unión de larga duración, reproduciendo el mismo problema que la migración pretendía solucionar. Por último, el registro de auditoría de cada emisión de credenciales debe enviarse a un SIEM para que se puedan detectar emisiones anómalas.

Migración sin interrumpir la automatización

Una planificación migratoria pragmática organiza el trabajo de manera que el valor llegue pronto y el riesgo se mantenga controlado.

1. Primero, crea el inventario: No se puede retirar lo que no se ve. Utilice el descubrimiento basado en agentes y sin agentes para localizar todas las claves SSH en servidores y máquinas de usuario, registrar la propiedad y los datos del último uso, e identificar las claves huérfanas. Mantenga el descubrimiento y la corrección estrictamente separados, ya que la automatización de la producción a menudo depende de claves mal documentadas y eliminar la incorrecta puede interrumpir las copias de seguridad, las implementaciones o el acceso de emergencia. SSH seguro Realiza precisamente esta detección, tanto con agentes como sin ellos, registrando la propiedad y los datos de último uso para que las claves huérfanas salgan a la luz para su revisión en lugar de ser eliminadas sin más.
2. Establezca una autoridad de certificación y habilite la confianza paralela: Configure los hosts para que confíen en la CA mediante TrustedUserCAKeys, manteniendo la autenticación de clave pública existente. Esto hace que la transición sea gradual y reversible.
3. Integre la emisión con su proveedor de identidad: Vincule la emisión de certificados al inicio de sesión único y a la autenticación multifactor, de modo que una solicitud humana genere un certificado válido solo para la sesión y la pertenencia a grupos se asigne a los roles del servidor. Agregar o eliminar un usuario en el proveedor de identidades se propaga automáticamente al acceso SSH.
4. Primero, migre las cargas de trabajo con privilegios más amplios que utilizan claves estáticas: Para las cuentas de servicio y automatización, implemente SPIFFE/SPIRE para que las cargas de trabajo reciban SVID certificados y de rotación automática. Comience con las cargas de trabajo que tengan los permisos más amplios, documente el registro de auditoría como evidencia de cumplimiento y, a continuación, amplíe a máquinas virtuales y hosts físicos mediante certificados de nodo.
5. Restringir el alcance y la vigencia del certificado: Limite estrictamente las entidades principales, establezca la validez al período más corto que no interrumpa el trabajo y aplique restricciones de origen o comandos de fuerza cuando sea apropiado. Evite el error más común: tratar un certificado como un reemplazo permanente de clave sin restringir las entidades principales, la confianza del emisor ni los períodos de validez.
6. Instrumento y monitor: Envíe los registros de SVID y emisión de certificados a su SIEM, reciba alertas si la emisión no coincide con los selectores esperados y revise las rotaciones de paquetes de confianza y CA según un cronograma definido. SSH Secure centraliza esta monitorización, enviando los registros de emisión a los paneles de Splunk o Loki-Grafana con detección de anomalías integrada.
7. Desmantelar deliberadamente: Una vez que la carga de trabajo se haya migrado por completo, proceda a eliminar gradualmente sus claves heredadas mediante la gestión de la configuración durante una ventana de mantenimiento y observe el comportamiento de la aplicación inmediatamente después.

Lo que gana cada equipo de seguridad

El cambio de claves estáticas a identidades de carga de trabajo de corta duración afecta a varias funciones, cada una con implicaciones distintas.

• CISO obtener una reducción cuantificable en el privilegio de legitimidad y una respuesta defendible a la pregunta de auditoría sobre quién puede acceder a la producción y durante cuánto tiempo.
• Arquitectos de seguridad Se puede integrar el acceso SSH en un modelo coherente de confianza cero en el que cada solicitud se verifica, se define su alcance y se limita su tiempo, en lugar de otorgarse mediante un archivo estático.
• Equipos de PKI y criptografía Extender la disciplina existente sobre el ciclo de vida de los certificados a SSH, tratando los certificados SSH con la misma gobernanza que se aplica a TLS y a las firmas de código.
• Equipos de DevSecOps Eliminar las claves privadas integradas en los ejecutores y las canalizaciones, sustituyéndolas por credenciales por trabajo que caducan cuando finaliza el trabajo.
• Equipos de nube e IAM Unificar la identidad de las cargas de trabajo en todos los clústeres y cuentas, intercambiando identidades verificadas por tokens en la nube de corta duración en lugar de distribuir credenciales estáticas.
• Ingenieros de infraestructura Deje de mantener archivos authorized_keys en toda la flota y permita que los hosts confíen en una autoridad y una decisión política.

Cómo SSH Secure implementa la gestión de claves SSH

En Encryption Consulting, comprendemos los desafíos que enfrentan las empresas al administrar claves SSH a gran escala. SSH Secure está diseñado para brindar seguridad integral del ciclo de vida de las claves y una visibilidad completa, para que las organizaciones puedan administrarlas con confianza y sin complejidad adicional. Así es como ayuda:

1. Mapeo centralizado de visibilidad y propiedad: Mediante una combinación de descubrimiento basado en agentes y sin agentes, SSH seguro Localiza todas las claves SSH en servidores y equipos de usuario. Todas las claves se almacenan en un único inventario con detalles de propiedad y uso, lo que elimina las claves huérfanas, reduce la dispersión y garantiza la total responsabilidad en todo el entorno.
2. Control de acceso seguro y claves vinculadas a la sesión: El control de acceso basado en roles (RBAC) granular garantiza que los usuarios reciban únicamente el nivel mínimo de acceso necesario. Para operaciones sensibles o temporales, SSH Secure emite claves efímeras vinculadas a la sesión que caducan automáticamente. En conjunto, estos controles refuerzan el principio del mínimo privilegio y minimizan el impacto de cualquier credencial comprometida.
3. Orquestación automatizada del ciclo de vida de las claves: SSH Secure automatiza el ciclo de vida completo de las claves, incluyendo la generación segura, la rotación basada en políticas, la expiración programada y la revocación. La gestión del ciclo de vida elimina las claves débiles o obsoletas, reduce la intervención humana y garantiza el cumplimiento continuo de las mejores prácticas del sector.
4. Protección integrada HSM: Todas las claves privadas están protegidas dentro de HSM, lo que garantiza la no exportación y la resistencia a la manipulación. Las claves se generan utilizando algoritmos criptográficos robustos como RSA-4096, ECDSA y Ed25519, proporcionando una sólida protección y resistencia contra ataques de fuerza bruta.
5. Control basado en políticas para operaciones clave: Todas las operaciones clave, incluyendo la generación, los flujos de trabajo de aprobación, la rotación y la revocación, se rigen por controles basados ​​en políticas. Esto garantiza la coherencia en todo el entorno, reduce los errores manuales y mantiene los estándares de seguridad de la organización. Las políticas pueden adaptarse a los requisitos normativos o personalizarse para dar soporte a los modelos de gobernanza internos.
6. Supervisión continua, auditoría y preparación para el cumplimiento normativo: SSH Secure ofrece monitorización en tiempo real de las actividades clave con registro detallado de eventos y detección de anomalías integrada. Los registros se pueden integrar con los paneles de Splunk o Loki-Grafana para una visualización, correlación y alertas avanzadas. Las funciones de auditoría flexibles incluyen registros descargables e informes detallados, lo que proporciona a los equipos de seguridad una visión clara del uso de las claves y la postura general. La auditoría centralizada con alertas basadas en políticas permite una gestión de seguridad proactiva, una detección rápida de anomalías y una respuesta más ágil ante incidentes.

Conclusión

Las claves SSH estáticas persisten porque son familiares y porque, individualmente, cada una parece inofensiva. En conjunto, forman uno de los mayores conjuntos de acceso privilegiado no gestionado en la empresa moderna, sin que se vea afectado por la caducidad, la autenticación multifactor ni las auditorías. La alternativa ya no es experimental. Los certificados SSH de corta duración emitidos mediante inicio de sesión único y las identidades de carga de trabajo autenticadas mediante SPIFFE y SPIRE permiten a una organización reemplazar las claves permanentes con credenciales que demuestran qué es una carga de trabajo, otorgan acceso solo durante el tiempo necesario y se rotan automáticamente.

La transformación de claves SSH estáticas a identidades de carga de trabajo de corta duración supone, fundamentalmente, un cambio de la confianza basada en la posesión a una identidad certificada y con caducidad limitada. Comience con el descubrimiento, habilite la confianza paralela para que la migración sea segura y reversible, y traslade primero las cargas de trabajo con mayores privilegios. Considere el acceso SSH como una identidad que debe gestionarse, en lugar de un secreto que debe almacenarse, y la credencial que antes era permanente se convertirá en una que caduca antes de que pueda ser utilizada indebidamente.