Diseño de una política eficaz de rotación de claves SSH

Las claves SSH (Secure Shell) impulsan la infraestructura moderna, permitiendo que administradores, sistemas de automatización y pipelines de CI/CD se comuniquen de forma segura a través de redes sin contraseñas. Sin embargo, las claves SSH no caducan automáticamente: una vez generadas y reconocidas, pueden permanecer válidas indefinidamente. Sin una política de rotación explícita, las organizaciones acumulan credenciales de larga duración sin rotar que proporcionan acceso persistente a sistemas críticos mucho después de que finalice la necesidad empresarial original. Los atacantes lo saben. Si obtienen una clave SSH privada creada hace años, a menudo consiguen acceso inmediato sin contraseña a los sistemas que autoriza. La acción recomendada: definir una política formal de rotación de claves SSH con calendarios de rotación basados ​​en riesgos, activadores basados ​​en eventos, estándares criptográficos y aplicación automatizada a través de una plataforma centralizada de gestión de claves SSH.

Respuesta rápida: ¿Qué requisitos debe cumplir una política eficaz de rotación de claves SSH?

Una política eficaz de rotación de claves SSH requiere: un inventario completo de todas las claves SSH del entorno; una estructura de gobernanza que defina la propiedad, los roles y las responsabilidades; calendarios de rotación basados ​​en el riesgo (de 30 a 90 días para claves de alto riesgo, anualmente para claves de bajo riesgo); desencadenantes de rotación basados ​​en eventos (desconexión, vulneración, obsolescencia del algoritmo); estándares criptográficos obligatorios (Ed25519 preferido, RSA-3072 mínimo); un proceso de rotación documentado de extremo a extremo; automatización mediante una plataforma de gestión de claves SSH; y registro de auditoría que proporcione evidencia de cumplimiento. Para obtener información relacionada, consulte nuestras publicaciones sobre comparación de algoritmos de claves SSH y autenticación SSH sin contraseña.

¿Por qué se suele pasar por alto la rotación de claves SSH?

A diferencia de las contraseñas o los certificados TLS, las claves SSH no tienen un mecanismo de caducidad integrado. No aparece ningún aviso cuando una clave alcanza cierta antigüedad; ningún fallo de autenticación indica que debe reemplazarse. Esta falta de urgencia técnica crea una brecha de gestión que persiste hasta que un incidente obliga a solucionar el problema. Problemas operativos comunes que resultan de ello:

• No existe un inventario que indique dónde se encuentran las claves: qué servidores tienen autorizadas qué claves públicas, dónde se almacenan las claves privadas o cuántas claves SSH hay en total en el entorno.
• La rotación manual es propensa a errores y genera interrupciones operativas a gran escala: actualizar authorized_keys en cientos de servidores requiere automatización para ser fiable.
• Los usuarios generan claves libremente mediante ssh-keygen, lo que crea inconsistencias en la fuerza del algoritmo, la longitud de las claves y las convenciones de nomenclatura en todo el entorno.
• Los tipos de clave heredados (DSA, RSA-1024) siguen en producción sin visibilidad sobre la frecuencia de uso, las marcas de tiempo del último acceso o si el propietario de la clave todavía trabaja en la organización.
• Claves codificadas en aplicaciones o scripts de automatización que no se pueden rotar sin modificar el código.
• Sin gobernanza centralizada: ningún equipo es responsable de la gestión del ciclo de vida de las claves SSH en todo el entorno.

Los riesgos de no rotar las claves SSH

Supervisión	Mareas Ideales para Lecciones
Acceso no autorizado persistente	Las claves no caducan, lo que permite a los atacantes un acceso a largo plazo una vez que obtienen una clave privada.
Claves huérfanas	Las claves creadas por usuarios que han abandonado la organización permanecen autorizadas en los servidores, a veces con acceso administrativo.
Movimiento lateral	La reutilización de claves en múltiples sistemas permite a los atacantes cambiar silenciosamente de servidor.
TI en la sombra	Los desarrolladores y administradores crean claves no gestionadas sin aprobación, al margen de cualquier sistema de gobernanza o inventario.
Cuestiones de auditoría y cumplimiento	Las normas PCI DSS, ISO 27001, SOX, NIST SP 800-53 y FedRAMP exigen la gestión de claves criptográficas y pruebas de control de acceso; las claves no rotadas generan incumplimientos normativos.

Componentes del par de claves SSH

Un par de claves SSH consta de dos componentes vinculados criptográficamente:

• Llave privada: Almacenada de forma segura en el cliente; debe permanecer confidencial; nunca se transmite por la red. Esta es la credencial que autoriza el acceso.
• Llave pública: Se almacena en el archivo authorized_keys del servidor remoto. El servidor lo comprueba para determinar si el cliente está autorizado.

La rotación de claves reemplaza ambos componentes: se genera un nuevo par de claves; la nueva clave pública se implementa en los servidores autorizados; la clave pública antigua se elimina de los archivos authorized_keys de todos los servidores; la clave privada del cliente se reemplaza por la nueva. La rotación no se completa hasta que la clave pública antigua se haya eliminado de todos los servidores que la tenían autorizada.

Una política de rotación bien diseñada rige todo el ciclo de vida de la clave SSH:

1. Solicitud / Creación
2. Aprobación y asignación de metadatos
3. Implementación en servidores de destino
4. Uso y monitorización
5. Rotación / Revocación
6. Desmantelamiento

Una política de rotación sólida debe basarse en el riesgo, estar automatizada, contar con protección criptográfica y estar alineada con las operaciones comerciales.

Diseño de la política de rotación de claves SSH

Una política eficaz de rotación de claves SSH establece controles claros y aplicables sobre todo el ciclo de vida de las claves SSH. Los siguientes ocho componentes definen un marco de política completo:

1. Establecer la gobernanza de SSH

Antes de implementar la rotación, defina una estructura de gobernanza que abarque:

• Funciones y responsabilidades (quién gestiona las claves SSH, quién aplica las políticas, quién aprueba las solicitudes de claves)
• Propiedad de cada clave SSH: cada clave debe tener un propietario individual o de sistema documentado.
• Flujos de trabajo de aprobación para la generación de nuevas claves y concesiones de acceso.
• Plan de revisión periódica del acceso (trimestral o semestral para llaves de alto riesgo)
• Mecanismo de aplicación (aplicación automatizada de políticas a través de una plataforma de gestión de claves SSH)
• Un documento formal y escrito sobre la política de rotación de claves SSH.

2. Realizar el descubrimiento de claves SSH

No puedes rotar lo que no puedes ver. Discovery debe cubrir:

• Todos los servidores del entorno (Linux, Unix, instancias en la nube, aplicaciones)
• Todos los archivos authorized_keys en todos los servidores y cuentas de usuario.
• Todos los almacenes locales de claves privadas en estaciones de trabajo y servidores.
• Claves integradas en scripts, herramientas de automatización, pipelines de CI/CD y archivos de configuración.

El resultado del descubrimiento es un inventario completo de claves SSH que relaciona cada clave pública con su propietario, ubicaciones de implementación, fecha de creación, algoritmo y marca de tiempo del último acceso. Sin este inventario, la rotación es incompleta, ya que no se puede eliminar una clave de todos los servidores si se desconoce en cuáles se encuentra. Consulte nuestra publicación sobre inventario criptográfico para obtener un contexto más amplio.

3. Clasificar las claves por riesgo

Un programa de rotación basado en el riesgo evita tanto la rotación insuficiente (claves de alto riesgo con periodos prolongados) como la rotación excesiva (claves de bajo riesgo que requieren interrupciones frecuentes). La siguiente clasificación es un ejemplo; la política específica de su organización debe reflejar la evaluación de riesgos interna y los requisitos normativos.

Nivel de riesgo	Criterios de alto nivel	Frecuencia de rotacion
Alto	Acceso de administrador, claves compartidas, propietarios desconocidos, claves con más de 2 años de antigüedad, claves con acceso a datos confidenciales o entornos de producción.	30 a día 90
Media	Claves de DevOps y automatización, claves de usuario con sudo, claves de cuenta de servicio	90 a día 180
Bajo	Cuentas no privilegiadas, sistemas de prueba y desarrollo, acceso de solo lectura	180 a día 365

4. Definir estándares criptográficos

La política de rotación debe garantizar estándares criptográficos mínimos para todas las claves nuevas y rotadas. Estándares recomendados alineados con NIST SP 800-57 y la guía actual de OpenSSH:

• Ed25519: Preferible para todas las claves nuevas y rotadas. Firmas deterministas, operaciones de tiempo constante, seguridad equivalente a ~128 bits, tamaños de clave mínimos.
• RSA-3072 o RSA-4096 con firmas SHA-2: Para compatibilidad con versiones anteriores donde Ed25519 no es compatible, RSA-2048 es el mínimo aceptable; RSA-1024 está obsoleto y no debe utilizarse.
• ECDSA P-256 o superior: aceptable si Ed25519 no está disponible y se requiere una curva elíptica.
• DSA: prohibido. Obsoleto según NIST en FIPS 186-5 (2023); deshabilitado en OpenSSH 7.0+. Todas las claves DSA existentes deben reemplazarse de inmediato.

Para una comparación completa de algoritmos, consulte nuestra publicación sobre la comparación de algoritmos de claves SSH.

5. Definir el proceso de rotación

Un flujo de trabajo completo de principio a fin para la rotación de llaves:

• Iniciar rotación según cronograma o evento activado.
• Genere un nuevo par de claves en un sistema cliente autorizado o a través de una plataforma de gestión de claves SSH, utilizando el algoritmo aprobado (se prefiere Ed25519).
• Aplique las siguientes convenciones de nomenclatura: usuario, sistema, fecha, entorno.
• Implemente la nueva clave pública en todos los servidores de destino a través de la plataforma automatizada de administración de claves SSH.
• Antes de eliminar la clave antigua, compruebe que la nueva clave se autentica correctamente en todos los servidores autorizados.
• Revocar y eliminar las claves públicas antiguas de los archivos authorized_keys de todos los servidores.
• Actualizar el inventario centralizado y el registro de auditoría con el evento de rotación, la fecha y el operador.

6. Definir activadores de rotación

Además de los cronogramas de rotación basados ​​en el tiempo, se deben definir y aplicar inmediatamente, cuando se activen, los desencadenantes de rotación basados ​​en eventos:

• Salida del usuario o cambio de rol: Rotar y 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.
• Compromiso sospechado o confirmado: Gire inmediatamente la clave afectada en todos los servidores donde esté autorizada; investigue el alcance del acceso durante el período en que se produjo la vulneración.
• Acceda a los resultados de la revisión: Las claves que se identifiquen como innecesarias, huérfanas o que no cumplan con las políticas durante las revisiones de acceso deben rotarse o revocarse de inmediato.
• Migración de infraestructura: Las claves deben revisarse y rotarse cuando se reinstala el sistema operativo de los servidores, se migran a un nuevo entorno o se transfieren a un equipo diferente.
• Algoritmo obsoleto: Cualquier clave que utilice un algoritmo obsoleto (DSA, RSA-1024) debe sustituirse inmediatamente por un algoritmo aprobado en cuanto se identifique.

7. Integrar la automatización y la gestión de claves SSH.

La automatización no es opcional para la rotación de claves SSH a escala empresarial. La rotación manual en cientos o miles de servidores es propensa a errores y no es escalable. Una plataforma de gestión de claves SSH como SSH Secure debería proporcionar:

• Inventario centralizado de todas las claves SSH con información sobre la propiedad, el algoritmo, la ubicación de implementación y los datos del último acceso.
• Descubrimiento automatizado (con y sin agentes) en todo el conjunto de servidores.
• Creación de claves basada en políticas que aplica estándares criptográficos
• Implementación automatizada de claves públicas en todos los servidores autorizados.
• Limpieza automatizada de claves antiguas de todos los servidores después de verificar la nueva clave.
• Control de acceso basado en roles y flujos de trabajo de aprobación
• Registros de auditoría e informes de cumplimiento para todos los eventos del ciclo de vida.

8. Consideraciones de cumplimiento

Una política sólida de rotación de claves SSH genera la evidencia de auditoría requerida por los marcos de cumplimiento:

• PCI DSS v4.0: Requisito 2.2.7 (criptografía robusta para el acceso administrativo sin consola); Requisito 12.6 (concienciación sobre seguridad y revisiones de acceso periódicas).
• NIST SP 800-53: SC-12 (Establecimiento y gestión de claves criptográficas) y SC-17 (Certificados de infraestructura de clave pública); IA-3 (Identificación y autenticación de dispositivos).
• NIST SP 800-57: Recomendaciones de cryptoperiod por tipo de clave y algoritmo.
• ISO 27001:2022 Control 8.24: Uso de criptografía, requisitos de gestión de claves.
• SOX / FedRAMP: Rotación periódica, control de acceso, establecimiento de claves, separación de funciones, trazabilidad y eliminación de credenciales compartidas.

Requisitos de la política de acceso para claves SSH

• Una llave por usuario: Cada usuario debe tener un par de claves único. Las claves compartidas eliminan la posibilidad de auditoría por usuario y complican la revocación.
• Privilegios mínimos: Cada clave solo debe autorizarse en los servidores y cuentas de usuario específicos necesarios para la función empresarial. Una autorización amplia aumenta el impacto de cualquier vulneración de una sola clave.
• Sin claves codificadas: Las claves SSH integradas en el código fuente o en los archivos de configuración no se pueden rotar sin una implementación. Utilice plataformas de gestión de secretos para inyectar credenciales SSH de forma dinámica.
• No se requieren claves privadas sin contraseña para el acceso privilegiado: Las claves privadas para accesos de alto riesgo deben estar protegidas con contraseña o almacenadas en hardware HSM para evitar su extracción en caso de que el sistema del cliente se vea comprometido.
• Revisión periódica de acceso: Todas las autorizaciones de claves SSH deben revisarse al menos trimestralmente para el acceso de alto riesgo y anualmente para el acceso estándar, para confirmar que siguen siendo necesarias.

Evidencia de auditoría: ¿Qué requieren las auditorías de rotación clave?

• Inventario clave: Un registro actualizado de todas las claves SSH, sus propietarios, algoritmos, fechas de creación, servidores de implementación y fechas de última rotación.
• Registros de rotación: Registros con marca de tiempo de cada evento de rotación, incluyendo si fue programado por tiempo o activado por un evento, el operador, la huella digital de la clave antes y después, y la confirmación de la eliminación de la clave antigua.
• Documentación sobre activadores de eventos: Cuando una salida o una vulneración de la seguridad desencadene una rotación, documente el evento, el cronograma desde que se desencadena hasta que finaliza la rotación y la confirmación de que la clave anterior se eliminó de todos los servidores.
• Registros de revisión de acceso: Registros fechados de la finalización de la revisión de acceso, incluidas las claves revocadas o los propietarios actualizados como resultado.
• Evidencia de cumplimiento del algoritmo: Confirmación de que todas las claves del entorno utilizan algoritmos aprobados; registros de la corrección de claves obsoletas.

Cómo SSH Secure permite la rotación escalable

SSH Secure está diseñado para ofrecer seguridad y gobernanza del ciclo de vida de las claves SSH de extremo a extremo a escala empresarial. Capacidades clave:

• Mapeo centralizado de visibilidad y propiedad: El descubrimiento basado en agentes y sin agentes localiza todas las claves SSH en servidores y máquinas de usuario; todas las claves se almacenan en un inventario unificado con detalles de propiedad, uso y alcance de implementación; elimina las claves huérfanas y reduce expansión de claves.
• Orquestación automatizada del ciclo de vida de las claves: Automatiza la generación segura (Ed25519, ECDSA, RSA-4096), la rotación basada en políticas, la expiración programada y la revocación; elimina las claves débiles y obsoletas; reduce la intervención humana.
• Rotación de teclas sin contacto: Rote las claves SSH bajo demanda o según un cronograma en una única operación automatizada: genere una clave nueva, impleméntela en todos los servidores, verifique y elimine la clave antigua; sin intervención manual en servidores individuales; visibilidad completa de todos los accesos SSH activos.
• Operaciones clave impulsadas por políticas: La generación, aprobación, rotación y revocación de todos los permisos se gestionan mediante políticas configurables; la aplicación de las normas es coherente en todo el entorno; y se adapta a los requisitos reglamentarios.
• Protección de clave privada integrada en HSM: Claves privadas protegidas dentro de módulos de seguridad de hardware (HSM); no exportables y a prueba de manipulaciones; protegidas incluso contra ataques de vulneración del sistema operativo y de extracción de datos de memoria.
• Supervisión continua, auditoría y preparación para el cumplimiento normativo: Monitorización en tiempo real con detección de anomalías; integración con SIEM (Splunk, Loki-Grafana); registros de auditoría e informes de cumplimiento descargables; permite una respuesta rápida ante incidentes.

Conclusión

Diseñar una política eficaz de rotación de claves SSH no es una buena práctica que se deba añadir a la lista de tareas pendientes: es un componente crítico de la seguridad del acceso privilegiado empresarial. Las claves SSH que nunca se rotan proporcionan acceso persistente tanto a atacantes como a exempleados. Una política completa requiere visibilidad total del inventario, calendarios de rotación basados ​​en riesgos, activadores basados ​​en eventos para la rotación inmediata, estándares criptográficos obligatorios (se prefiere Ed25519, se prohíben los algoritmos obsoletos), un proceso de rotación documentado y automatizado, y la evidencia de auditoría que exigen los marcos de cumplimiento. La automatización mediante una plataforma de gestión de claves SSH es la única forma práctica de lograr una aplicación coherente de la política a gran escala. Para obtener información relacionada, consulte nuestras publicaciones sobre la comparación de algoritmos de claves SSH , la autenticación SSH sin contraseña y SSH Secure.

Preguntas frecuentes

¿Por qué las organizaciones necesitan una política de rotación de claves SSH si las claves no caducan?

Dado que las claves que nunca caducan se acumulan indefinidamente, las claves de los exempleados permanecen autorizadas en los servidores. Las claves comprometidas siguen siendo utilizables hasta que se revocan manualmente. Una política de rotación establece los controles necesarios para forzar la rotación según un calendario y ante eventos específicos (baja, vulneración de seguridad, obsolescencia de algoritmos), evitando así la acumulación silenciosa de credenciales de larga duración que los atacantes pueden aprovechar.

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

Basado en el riesgo: alto riesgo (acceso de administrador, compartido, propietario desconocido) cada 30-90 días; riesgo medio (DevOps, automatización, sudo) cada 90-180 días; bajo riesgo (sin privilegios, sistemas de prueba) cada 180-365 días. Los desencadenantes basados ​​en eventos (salida, vulneración, obsolescencia) anulan el cronograma y requieren una rotación inmediata.

¿Qué debe incluir un proceso de rotación de claves SSH?

Iniciar la rotación; generar un nuevo par de claves (se prefiere Ed25519) en el sistema aprobado o mediante el administrador de claves SSH; aplicar las convenciones de nomenclatura; implementar la nueva clave pública en todos los servidores de destino; comprobar que la nueva clave se autentica correctamente; eliminar las claves públicas antiguas de los archivos authorized_keys de todos los servidores; actualizar el inventario y el registro de auditoría.

¿Qué algoritmos de clave SSH debería aplicar una política de rotación?

Se prefiere Ed25519 (seguridad determinista, de tiempo constante y equivalente a 128 bits). RSA-3072 o RSA-4096 como mínimo si se requiere RSA. ECDSA P-256+ es aceptable. DSA está prohibido (obsoleto según NIST FIPS 186-5, 2023; deshabilitado en OpenSSH 7.0+). RSA-1024 está prohibido. Todas las claves rotadas deben cumplir con los requisitos del algoritmo; las claves existentes que no cumplan con los requisitos deben reemplazarse.

¿Qué marcos de cumplimiento normativo requieren la rotación de claves SSH?

Requisitos 2.2.7 y 12.6 de PCI DSS v4.0; NIST SP 800-53 SC-12, SC-17, IA-3; NIST SP 800-57 (criptoperíodos); ISO 27001:2022 Control 8.24; SOX (controles de acceso y revisiones de credenciales); FedRAMP (referencias NIST 800-53).

¿Cómo automatiza SSH Secure la rotación de claves SSH?

Descubrimiento de todas las claves SSH; inventario centralizado con información sobre la propiedad y el uso; programación de rotación basada en políticas que se aplica automáticamente; rotación sin intervención (generar, implementar, verificar y eliminar claves antiguas) en una única operación automatizada; rotación activada por eventos en caso de salida o vulneración de la seguridad; protección de claves privadas respaldada por HSM; registro de auditoría integrado con SIEM para obtener evidencia de cumplimiento.