Gestión integral del ciclo de vida de las claves SSH para la seguridad empresarial

Publicado: febrero de 2026. Actualizado: agosto de 2026. Revisado por el equipo de gestión de claves de Encryption Consulting.

SSH (Secure Shell) es un protocolo de red criptográfico que se utiliza para autenticar, comunicar e intercambiar datos entre sistemas a través de una red no segura. Una gestión integral del ciclo de vida de las claves SSH para la seguridad empresarial implica tratar cada par de claves en el que se basa el protocolo, tanto manuales como automatizadas, como una credencial controlada con un propietario, un calendario de rotación y un registro de auditoría, en lugar de un archivo que se crea una vez y se olvida.

Cuando los administradores y los sistemas de automatización se conectan a los servidores mediante SSH, la autenticación casi siempre se realiza a través de claves SSH en lugar de contraseñas. Estas claves proporcionan un acceso seguro y cifrado, y se han convertido en el mecanismo predeterminado para administrar servidores Linux, cargas de trabajo en la nube, pipelines de CI/CD (integración continua/entrega continua) e infraestructura empresarial crítica. Si necesita una introducción al protocolo antes de profundizar, nuestra guía completa de SSH cubre los fundamentos; esta guía se centra específicamente en la gestión de las claves a lo largo de todo su ciclo de vida.

En entornos de gran tamaño, las claves SSH tienden a proliferar rápidamente. Se comparten entre usuarios y sistemas, se reutilizan en distintos servidores, se copian sin control y permanecen activas mucho después de haber cumplido su función original. A diferencia de los certificados o las cuentas de usuario, las claves SSH suelen carecer de fechas de caducidad, propiedad clara y gobernanza centralizada, lo que las convierte en un riesgo de seguridad empresarial significativo, aunque a menudo ignorado.

Esta guía abarca qué significa realmente la gestión del ciclo de vida de las claves SSH, quién debe ser el propietario de las claves en cada etapa, qué debe desencadenar una rotación, cómo diseñar una política de acceso, qué pruebas de auditoría debe generar un programa maduro, un flujo de trabajo de implementación práctico desde el descubrimiento hasta la desactivación, cómo se comparan las plataformas de gestión de claves SSH manuales, integradas con PAM y dedicadas, y los aspectos básicos de cómo responder cuando una clave queda expuesta.

¿Qué es la gestión del ciclo de vida de las claves SSH?

La gestión del ciclo de vida de las claves SSH es la disciplina que controla un par de claves SSH desde su generación hasta su eliminación, incluyendo quién es el propietario, a qué permisos tiene acceso, cuándo se reemplaza y cómo se registra su uso. Su existencia se debe a que un par de claves SSH sin procesar, por sí solo, carece de propietario, fecha de caducidad o registro de aprobación. Estos controles deben añadirse posteriormente.

Las claves SSH son una forma de demostrar la identidad al usar SSH. En lugar de escribir una contraseña cada vez, SSH suele usar la autenticación basada en claves, que es más segura contra intentos de adivinación y ataques de fuerza bruta, y más fácil de automatizar.

Una clave SSH viene en un par:

• A llave privada, que permanece con el usuario o la aplicación y debe mantenerse en secreto.
• Una clave pública, que se coloca en el archivo authorized_keys del servidor para permitir el acceso.

Cuando se establece una conexión, el servidor verifica que el cliente posea la clave privada que coincide con la clave pública en la que confía. Si la coincidencia es válida, se concede el acceso. Las versiones actuales de OpenSSH generan una clave Ed25519 por defecto cuando ssh-keygen se ejecuta sin argumentos; donde se requiere RSA para compatibilidad, el manual de OpenSSH establece el tamaño predeterminado y mínimo recomendado en 3072 bits, y la guía de endurecimiento de CISA para infraestructura de comunicaciones recomienda de forma independiente una clave RSA mínima de 3072 bits para SSH, según el Página del manual de ssh-keygen y Guía de CISA para mejorar la visibilidad y el fortalecimiento de la infraestructura de comunicacionesLas versiones recientes de OpenSSH también han comenzado a agregar tipos de claves híbridas post-cuánticas junto con Ed25519 y RSA, una señal de que la elección del algoritmo, y no solo la política de rotación, forma parte de un programa actual de claves SSH.

La diferencia crítica con respecto a los sistemas basados ​​en certificados es la siguiente: management es que un par de claves SSH estándar no caduca por sí solo. Un certificado X.509 lleva una notAfter Fecha que obliga a la renovación: un par de claves SSH sin procesar se autenticará indefinidamente a menos que algo externo al protocolo, una política, un script o una plataforma de gestión lo elimine. Este hecho es la razón por la que se produce la proliferación de claves SSH y por la que la gestión del ciclo de vida debe ser un programa deliberado en lugar de una suposición.

¿Por qué las claves SSH necesitan gestión del ciclo de vida?

Las claves SSH requieren gestión del ciclo de vida porque se encuentran fuera de los sistemas de identidad que las empresas ya utilizan para controlar el acceso. La mayoría de las empresas usan sistemas IAM (Gestión de Identidades y Accesos) para gestionar las identidades de los usuarios y plataformas PAM (Gestión de Accesos Privilegiados) para el acceso administrativo de alto riesgo. Las claves SSH se sitúan entre estas dos áreas: funcionan como identidades digitales tanto para personas como para servicios, otorgando acceso directo al sistema sin necesidad de pasar por ningún punto de control.

Técnicamente, las claves SSH pueden eludir IAM y PAM porque el acceso se otorga directamente a nivel del sistema utilizando el par de claves, sin requerir credenciales de inicio de sesión administradas por ninguno de los sistemas. Una vez que una clave pública se autoriza en un servidor, ese servidor confía en ella independientemente de cualquier identidad centralizada o control de acceso privilegiado, que es precisamente la razón por la que las claves no rastreadas pueden eludir la gobernanza estándar y por la que la propia guía del NIST describe la seguridad de acceso basada en claves SSH como un área que "ha sido ignorada en gran medida hasta la fecha" en la mayoría de las organizaciones, según NIST IR 7966, Seguridad de la administración de acceso interactivo y automatizado mediante Secure Shell.

En entornos empresariales, las plataformas de automatización, las canalizaciones de CI/CD y los scripts operativos dependen de claves SSH para permitir el acceso entre sistemas a gran escala. Este modelo ofrece velocidad y fiabilidad, pero también provoca que el acceso SSH crezca rápidamente, superando la supervisión manual. A medida que los entornos se expanden, las claves se copian entre hosts, se reutilizan en múltiples servicios y permanecen en su lugar incluso después de que las aplicaciones cambien o los equipos se marchen. Este crecimiento descontrolado, a menudo sin un propietario claro, fecha de caducidad ni visibilidad centralizada, se conoce como proliferación de claves SSH.

Las claves SSH no gestionadas presentan riesgos específicos y bien documentados:

• Movimiento lateral: Si una clave se ve comprometida, los atacantes pueden moverse entre sistemas que confían en ella sin ser detectados, ampliando así su acceso a través de la red.
• Acceso privilegiado persistente: Las claves que permanecen activas mucho después de que se necesiten, o después de que la persona que las gestiona abandone el puesto, proporcionan un acceso administrativo continuo que puede ser objeto de abuso.
• Cuentas de servicio no detectadas: Los procesos, scripts o aplicaciones automatizados pueden usar claves SSH sin una propiedad clara, lo que crea cuentas ocultas que son difíciles de rastrear.
• Deficiencias en la auditoría: Sin una visibilidad centralizada, es difícil verificar quién tiene acceso a qué sistemas, lo que hace que las auditorías de cumplimiento sean lentas, incompletas o poco fiables.

Estos riesgos pueden provocar filtraciones de datos, interrupciones operativas y consecuencias regulatorias o financieras. Abordarlos no implica restringir la automatización, sino tratar las claves SSH como credenciales de acceso gestionadas en lugar de archivos no gestionados, de modo que los mismos principios de gobernanza que se aplican a las identidades y al acceso privilegiado se apliquen también al acceso SSH. Para un análisis más detallado de cómo se generan las brechas específicas en los procesos de acceso, consulte « Eliminación de brechas en el acceso SSH».

¿Quién es el propietario de las claves SSH en cada etapa de su ciclo de vida?

La propiedad debe asignarse en el momento en que se proporciona una clave, no reconstruirse posteriormente durante una auditoría o un incidente. La norma NIST IR 7966 exige que las organizaciones asignen un propietario, ya sea de la aplicación o del proceso de negocio, a cada clave que otorga acceso a un servidor, idealmente vinculada automáticamente a una base de datos de configuración en lugar de gestionarse manualmente. En la práctica, la propiedad no es una función única; cambia a lo largo del ciclo de vida, y cada etapa requiere una persona responsable designada. Para un análisis más detallado de los modelos de propiedad, consulte Propiedad de claves SSH.

Etapa del ciclo de vida	Propietario principal	Medioambiental
Generation	Ingeniero solicitante o propietario de la aplicación	Genere el par de claves utilizando un algoritmo y una longitud aprobados; proteja la clave privada.
	Equipo de seguridad o de gestión de accesos	Revisar la solicitud en función de la política establecida; aprobar el alcance, la fuente y las restricciones de comando.
Aprovisionamiento	Administrador de plataforma o sistema de automatización, supervisado por seguridad.	Instale la clave pública con las restricciones aprobadas; registre el evento de instalación.
Uso	Operaciones de seguridad (SOC)	Supervisar los eventos de autenticación vinculados a la clave; marcar el uso anómalo o que no cumpla con las políticas establecidas.
Rotación	Propietario de la clave, supervisado por el equipo de seguridad, ejecutado mediante automatización.	Reemplace la clave antes de que expire el período de cifrado o cuando se produzca un evento desencadenante.
Desmantelamiento	Propietario de la aplicación o servicio, junto con el equipo de seguridad.	Retire la clave al retirar el sistema, al cambiar de personal o de función; confirme la eliminación.

El responsable de cada etapa es quien rinde cuentas, pero lo que realmente importa en una auditoría es el registro de quién aprobó qué y cuándo. Este es el vínculo entre la propiedad, la rotación y los requisitos de evidencia que se abordan más adelante en esta guía.

¿Qué desencadena la rotación de claves SSH?

Una clave SSH debe rotar en función de tres tipos de desencadenantes, no de un único calendario fijo: el final de su criptoperiodo definido, un evento específico vinculado a la persona o al sistema que la posee, y cualquier indicio de riesgo para la propia clave.

1. Basado en el tiempo (expiración del criptoperíodo). Las organizaciones deben establecer el tiempo máximo, el criptoperiodo, durante el cual se puede utilizar una clave de identidad antes de su reemplazo, y el plazo específico debe basarse en el tipo de clave y el contexto de uso. NIST SP 800-57 Parte 1 Revisión 5 Proporciona el marco general del criptoperiodo; la norma NIST IR 7966 lo aplica específicamente a las claves de identidad SSH. En la práctica, las claves de servicio automatizadas suelen requerir un criptoperiodo más corto que las claves humanas interactivas, ya que se utilizan de forma continua y son más difíciles de detectar si se ven comprometidas.
2. Basado en eventos (cambios de personal y de sistema). La norma NIST IR 7966 establece explícitamente que las claves de identidad utilizadas para procesos automatizados «deben cambiarse antes de que expire el período criptográfico siempre que un administrador responsable de gestionar las claves de uno o más procesos automatizados haya sido reasignado o despedido». Esta misma lógica se aplica a los cambios de rol, la baja de contratistas o proveedores y la desactivación de aplicaciones, cualquiera de las cuales debería desencadenar una rotación o revocación inmediata, independientemente del período criptográfico restante.
3. Basado en el riesgo (compromiso sospechado o confirmado). Una clave expuesta en un repositorio de código, un archivo de registro, un ticket de soporte o un dispositivo extraviado debe reemplazarse de inmediato. Lo mismo se aplica cuando una clave ya no cumple con los estándares actuales de algoritmo o longitud, o cuando una vulnerabilidad (CVE) afecta la implementación de SSH o un sistema con el que interactúa la clave.

Las empresas con programas maduros utilizan los tres tipos de activadores conjuntamente. Un calendario fijo por sí solo no detecta cambios de personal ni vulneraciones de seguridad; los activadores sin un criptoperiodo base permiten que las claves inactivas y sin revisar permanezcan indefinidamente.

¿Cómo deberían las empresas diseñar su política de acceso SSH?

Una política de acceso SSH eficaz define quién puede solicitar acceso, cuándo se emiten las claves, cuánto dura el acceso y qué entornos requieren controles más estrictos, y luego aplica esas reglas automáticamente en lugar de depender de que los administradores individuales las recuerden.

Una política viable debería abarcar:

• Acceso basado en roles y separación de funciones. El acceso a producción debe gestionarse de forma diferente al acceso a desarrollo, y las cuentas de servicio deben seguir reglas distintas a las de los usuarios humanos. La persona que aprueba una solicitud de clave no debe ser la misma que la instala, siempre que el entorno lo permita.
• Restricciones de origen y de comandos. La norma NIST IR 7966 recomienda configurar restricciones de IP de origen y restricciones de comandos directamente en las claves de procesos automatizados, de modo que una clave robada tenga limitaciones en cuanto a dónde puede conectarse y qué puede ejecutar, en lugar de otorgar acceso ilimitado a la consola.
• Controles basados ​​en el entorno. Aprobación más estricta y períodos de cifrado más cortos para los sistemas de producción y los sistemas conectados a Internet; controles más flexibles, aunque con registro de actividad, para entornos de desarrollo aislados.
• Integración de la canalización CI/CD. Agregar comprobaciones de políticas a las canalizaciones de CI/CD significa que el acceso se verifica como parte del propio proceso de implementación, lo que se ajusta a la forma en que los equipos de DevOps ya trabajan y evita que la política se convierta en una puerta de entrada manual que se omita bajo la presión de los plazos de entrega.

Para demostrar los resultados a la dirección, haga un seguimiento de indicadores como la cantidad de claves huérfanas eliminadas, el tiempo ahorrado durante las auditorías y la mejora en los índices de cumplimiento. Estas cifras justifican la inversión continua en un programa estructurado de gestión de claves SSH.

¿Qué pruebas de auditoría deben presentar los programas clave de SSH?

Las auditorías requieren pruebas, no una descripción de la intención. El modelo NIST IR 7966 describe un ciclo de vida de acceso SSH controlado en cinco fases: solicitud, aprobación, aprovisionamiento, registro de uso y terminación. Un programa capaz de generar un registro en cada fase convierte el cumplimiento en un subproducto de las operaciones normales, en lugar de una tarea ardua y aislada.

• Registro de solicitud: quién solicitó el acceso, a qué sistemas y la justificación comercial aducida.
• Registro de aprobación: quién revisó la solicitud, con base en qué política y qué restricciones (origen, comando) se adjuntaron.
• Registro de aprovisionamiento: Confirmación de cuándo y dónde se instaló la clave pública, y mediante qué proceso.
• Registro de uso: La norma NIST IR 7966 recomienda que los servidores SSH registren las huellas digitales de las claves para cada sesión autenticada, de modo que el uso pueda vincularse a una clave y un propietario específicos con fines forenses y de auditoría.
• Registro de terminación: Confirmación de que la clave fue retirada, cuándo y por qué (cambio de rol, baja del empleado o desactivación del sistema).

Los marcos de trabajo como SOC 2, ISO/IEC 27001 y PCI DSS exigen que las organizaciones demuestren que el acceso se revisa y revoca de manera oportuna. Las claves SSH suelen ser el eslabón más débil de esta cadena de evidencia precisamente porque, a diferencia de los certificados, no generan un evento de caducidad automático que sirva de referencia para la revisión. Nuestra guía para superar las auditorías de claves SSH profundiza en la preparación de esta evidencia para un ciclo de auditoría específico.

¿Cómo se implementa la gestión del ciclo de vida de las claves SSH?

La implementación de la gestión del ciclo de vida de las claves SSH no requiere interrumpir las operaciones existentes. Añade gobernanza y automatización a los flujos de trabajo existentes en una secuencia definida, desde el descubrimiento hasta la desactivación.

Paso 1: Descubra e inventaria cada llave.

Antes de implementar cualquier política, una organización necesita saber qué claves SSH ya existen. El informe NIST IR 7966 es claro al respecto: el descubrimiento manual y el inventario de todas las claves de identidad y autorizadas en un entorno extenso es prácticamente imposible, y la automatización es esencial. En la práctica, esto implica escanear servidores, instancias en la nube y plataformas de automatización en busca de claves autorizadas, mapear las relaciones de confianza entre sistemas y registrar el propietario de cada una. Herramientas como SSH Secure automatizan este descubrimiento, proporcionando una visión unificada del acceso SSH en todo el entorno.

Las claves no rastreadas o huérfanas pueden permitir el acceso no autorizado y complicar la respuesta ante incidentes. Comience por evaluar el inventario actual y, a continuación, elabore un plan de migración que priorice los sistemas críticos y se expanda gradualmente para minimizar las interrupciones y, al mismo tiempo, establecer una visibilidad constante.

Paso 2: Asignar la propiedad

Cada clave descubierta y cada clave emitida en el futuro necesita un propietario identificado, vinculado a una persona, rol o aplicación. La propiedad no es opcional; es lo que permite realizar auditorías, revisiones de acceso y responder a incidentes de forma manejable, en lugar de convertirlas en un análisis forense. Una herramienta de gestión del ciclo de vida realiza un seguimiento automático de esta propiedad y contexto de acceso en cada etapa de la vida útil de la clave.

Paso 3: Definir y aplicar la política de acceso.

Una vez establecida la visibilidad y la propiedad, aplique las políticas de acceso descritas anteriormente (acceso basado en roles, restricciones de origen y comando, y controles específicos del entorno) y hágalos cumplir durante el propio proceso de aprovisionamiento, en lugar de hacerlo a posteriori.

Paso 4: Aprovisionamiento con aprobación controlada

Las nuevas claves deben pasar por un paso de solicitud y aprobación antes del aprovisionamiento, de acuerdo con el modelo de fases que describe NIST IR 7966. Siempre que sea posible, el aprovisionamiento en sí debe automatizarse: NIST IR 7966 señala que el aprovisionamiento automatizado reduce los recursos, reduce la necesidad de acceso privilegiado permanente y elimina los errores de configuración manual en comparación con un administrador que edita manualmente un archivo. authorized_keys .

Paso 5: Automatizar la rotación

La rotación manual en múltiples sistemas es compleja y propensa a errores. La rotación automatizada permite a las organizaciones implementar nuevas claves sin interrumpir los servicios, especialmente en entornos multinube, al tiempo que garantiza que las claves salientes se eliminen rápidamente en lugar de permanecer activas junto con las de reemplazo.

Paso 6: Monitorear y registrar el uso

Cada inicio de sesión SSH debe registrarse con la clave específica utilizada, su propietario y el sistema al que accedió. Estos registros de uso permiten identificar claves no utilizadas, detectar accesos que infringen las políticas y confirmar si una clave debe rotarse o revocarse. Integrar la actividad de las claves SSH en una plataforma SIEM como Splunk garantiza la coherencia de la visibilidad de SSH con el resto de las operaciones de seguridad de la organización.

Paso 7: Desactivar y revocar

Cada clave debe eliminarse eventualmente, ya sea al retirar un sistema, cambiar de rol, al finalizar un contrato o al término de un mismo, y dicha eliminación debe confirmarse, no darse por sentada. Este es el paso que la mayoría de las prácticas SSH improvisadas omiten por completo, y es precisamente así como se acumulan claves huérfanas sin un propósito claro en un entorno durante años.

Manual, integrado con PAM o dedicado: ¿Qué modelo de gestión de claves SSH se ajusta mejor a sus necesidades?

Generalmente, las empresas gestionan las claves SSH de tres maneras diferentes, y cada una produce un resultado de auditoría y de riesgo muy distinto a medida que el entorno crece.

Capacidad	Manual (scripts, hojas de cálculo)	PAM integrado	Gestión de claves SSH dedicada
Descubrimiento:	Ad hoc, frecuentemente incompleto	Limitado a las claves ya almacenadas en PAM.	Descubrimiento continuo en diferentes entornos
Seguimiento de la propiedad	Conocimiento informal y tribal	Vinculado a la identidad PAM, no siempre a la clave misma.	Asignado y controlado por clave en el momento de su emisión.
Rotación	Manual, propenso a errores a gran escala	Automatizado, pero solo para llaves almacenadas en bóveda.	Automatizado con restricciones específicas de SSH preservadas
Restricciones de origen/comando	Rara vez se aplica de forma consistente.	A menudo no es compatible de forma nativa.	Nativo del modelo de confianza SSH
Pruebas de auditoría	Ensamblado manualmente, lento de producir.	Fuerte para llaves de bóveda, ciego para el resto	Continuo y exportable en todo el inventario.
Ajuste típico	Entornos muy pequeños	Organizaciones ya estandarizadas en PAM con un volumen moderado de claves	Entornos grandes, híbridos o altamente regulados

Una plataforma PAM no sustituye la gestión del ciclo de vida específica de SSH; si bien suele gestionar bien las claves que almacena, las claves SSH generadas fuera de esa bóveda, integradas en la automatización, copiadas a un nuevo host o remanentes de un proyecto anterior, permanecen invisibles para ella. Precisamente esa brecha es la que las herramientas especializadas de descubrimiento y gestión del ciclo de vida de las claves SSH están diseñadas para solucionar.

¿Qué nivel de riesgo clave de SSH requiere qué controles?

No todas las teclas conllevan el mismo riesgo, y aplicar una misma cadencia de rotación a todas supone un desperdicio de recursos en las teclas de bajo riesgo, a la vez que se descuida el control de las de alto riesgo. Utilice la clase de la tecla para establecer los controles necesarios.

Clase clave	Ejemplo	Cadencia de rotación	Controles requeridos
Interacción humana	Inicio de sesión de ingeniero o administrador en producción	Periodo corto de criptoactivo (generalmente de 90 a 180 días), o inmediatamente después de un cambio de rol o empleo.	Clave privada protegida con contraseña, flujo de trabajo de aprobación, aprovisionamiento con autenticación multifactor (MFA) cuando esté disponible.
Servicio automatizado	Canalización de CI/CD, agente de despliegue, sistema de monitorización	El período criptográfico es más corto que el de las claves humanas debido a su uso continuo y de alta frecuencia; rotación inmediata si el administrador que gestiona la automatización cambia de rol.	Restricciones de IP de comando y origen, almacenamiento seguro, sin necesidad de contraseña interactiva.
Terceros/proveedores	Acceso del contratista o proveedor de servicios gestionados	Rotar en los hitos del contrato e inmediatamente al finalizar el contrato.	Acceso restringido por tiempo limitado a los sistemas mínimos necesarios, registrado y revisado por separado de las claves internas.
Raíz/romper vidrio	Ruta de acceso administrativo de emergencia	Gire después de cada uso.	Aprobación por múltiples partes, almacenamiento sellado o en bóveda, revisión posterior al uso obligatoria.

¿Cómo deben responder las empresas cuando se ve comprometida una clave SSH?

Una clave SSH comprometida debe tratarse como un incidente activo, no como una operación rutinaria. La primera hora es crucial, ya que una clave que otorga acceso a un sistema puede, a través de relaciones de confianza, abrir la puerta a muchos más.

1. Gire o revoque la llave inmediatamente. Elimine la clave pública comprometida de cada authorized_keys Entrada en la que aparece; no espere a una ventana de rotación programada.
2. Mapear las relaciones de confianza. Identifique todos los sistemas que confiaron en la clave comprometida, incluidos todos los sistemas posteriores a los que pudiera llegar, utilizando el inventario creado durante el proceso de detección.
3. Revise los registros de autenticación para detectar movimientos laterales. Compruebe si la clave se utilizó desde una fuente inesperada, en un momento inesperado o para acceder a sistemas fuera de su patrón normal.
4. Si procede, cambie las claves descendentes. Si la clave comprometida pudiera haberse utilizado para acceder a otras credenciales o sistemas, considérelos también como potencialmente expuestos.
5. Documente el incidente. Registre lo sucedido, lo que se rotó y qué evidencia respalda la respuesta, incorporándolo directamente a la cadena de evidencia de auditoría descrita anteriormente.

Este es un resumen de la respuesta inmediata, no un plan de acción completo. Para obtener instrucciones paso a paso sobre cómo gestionar un incidente, consulte Respuesta a incidentes por claves SSH expuestas , y para reforzar la seguridad de SSH frente a las técnicas de ataque que provocan la vulneración de claves, consulte Protección de SSH contra ataques.

Limitaciones

• Las herramientas de gestión del ciclo de vida reducen el riesgo, pero no sustituyen las decisiones políticas; la asignación de responsabilidades sigue requiriendo el compromiso de la organización y un proceso definido, no solo software.
• El descubrimiento automatizado puede pasar por alto claves incrustadas en imágenes de contenedores, codificadas en scripts fuera de las rutas escaneadas o almacenadas en bóvedas de contraseñas personales no administradas; la revisión manual periódica sigue siendo necesaria junto con la automatización.
• La gestión del ciclo de vida de las claves SSH complementa a IAM y PAM; no las reemplaza. En concreto, gestiona un tipo de credencial que IAM y PAM a menudo no pueden reconocer de forma nativa.
• Cuando una organización adopta certificados SSH, credenciales de corta duración emitidas por una autoridad de certificación SSH interna, parte de la carga de rotación se traslada a la emisión de certificados en lugar del reemplazo de claves estáticas. Esta guía abarca el ciclo de vida de los pares de claves estándar; una CA SSH es un modelo operativo independiente con sus propias ventajas e inconvenientes.
• Las directrices aquí presentadas son de carácter general. Los entornos regulados (FIPS 140-3, PCI DSS, HIPAA) deben validar los ciclos de rotación específicos y las decisiones de control en función de sus propias obligaciones de cumplimiento antes de finalizar la política.

¿Qué recomendaría Encryption Consulting?

Consideramos que la proliferación de claves SSH es una deficiencia en la gobernanza, no una carencia de herramientas que un solo script pueda solucionar. En nuestros proyectos, el patrón se repite: las organizaciones cuentan con controles estrictos sobre certificados y contraseñas, pero prácticamente no tienen visibilidad de las claves SSH, porque el protocolo no exige dicha visibilidad.

A través de SSH Secure , Encryption Consulting ofrece a las organizaciones visibilidad centralizada de todo el ciclo de vida de las claves SSH: descubrimiento, definición de políticas, aprovisionamiento controlado, asignación de propiedad, rotación, revocación, monitorización y auditoría, todo en un mismo lugar. Este enfoque basado en el ciclo de vida refuerza el control de acceso, reduce el acceso no autorizado, minimiza las interrupciones operativas y disminuye los costes administrativos. La clara identificación de la propiedad y los registros auditables simplifican las revisiones de acceso y la baja de usuarios, mientras que la visibilidad continua agiliza las evaluaciones de cumplimiento y reduce el consumo de recursos.

SSH Secure se integra con plataformas SIEM como Splunk, de modo que la actividad SSH se supervisa junto con el resto de las operaciones de seguridad de una organización, en lugar de hacerlo de forma aislada. Junto con CertSecure Manager para la gestión del ciclo de vida de los certificados, PKI-as-a-Service para una infraestructura de clave pública escalable y HSM-as-a-Service para la protección de claves basada en hardware, SSH Secure permite a las empresas gestionar el acceso criptográfico de forma coherente, en lugar de gestionar un tipo de credencial a la vez.

Conclusión

Preguntas frecuentes

¿Qué es la gestión del ciclo de vida de las claves SSH? La gestión del ciclo de vida de las claves SSH es la disciplina estructurada que consiste en descubrir cada par de claves SSH en un entorno, asignar un propietario responsable, aplicar una política de acceso durante el aprovisionamiento, rotar las claves según un criptoperiodo definido o un evento desencadenante, supervisar el uso de cada clave y revocarla o desactivarla cuando ya no se necesite el acceso. Sustituye la gestión informal de claves, servidor por servidor, por un proceso controlado y auditable.

¿Con qué frecuencia se deben rotar las claves SSH? No existe una cifra universal. Las directrices del NIST vinculan la rotación a un criptoperiodo definido según el tipo de clave y el riesgo, que suele ser más corto para las claves de servicios automatizados que para las claves de interacción humana, y exigen la rotación inmediata ante eventos desencadenantes específicos, como un cambio de rol, la rescisión del contrato de un empleado o una posible vulneración de la seguridad, independientemente del tiempo que quede del criptoperiodo.

¿Quién debe ser el propietario de las claves SSH en un entorno empresarial? Cada clave SSH debe tener un propietario asignado en el momento de su aprovisionamiento, normalmente el ingeniero solicitante o el responsable de la aplicación. Un equipo de seguridad o de gestión de accesos se encarga de aprobar la solicitud y de hacer cumplir la política. La propiedad nunca debe modificarse posteriormente durante una auditoría o un incidente.

¿Cuál es la diferencia entre la rotación y la revocación de claves SSH? La rotación es el reemplazo planificado y rutinario de una clave antes o al final de su período de validez, con el fin de limitar la duración de la validez de cada clave. La revocación, por otro lado, implica la pérdida de confianza en una clave específica, generalmente provocada por un incidente, un cambio de rol o la desactivación de un sistema, y ​​puede ocurrir en cualquier momento, independientemente del calendario de rotación.

¿Es posible automatizar la gestión del ciclo de vida de las claves SSH sin interrumpir los flujos de trabajo de CI/CD? Sí. El aprovisionamiento basado en plantillas, la rotación automatizada y las comprobaciones de políticas pueden integrarse directamente en los flujos de trabajo de CI/CD, de modo que la emisión y rotación de claves se produzcan como parte del proceso, en lugar de ser un proceso manual secundario. La norma NIST IR 7966 recomienda específicamente el aprovisionamiento automatizado para reducir los errores de configuración manual y la necesidad de acceso privilegiado permanente.

Recursos de seguridad SSH relacionados

Esta guía es la referencia principal de Encryption Consulting para la gestión del ciclo de vida de las claves SSH. Los recursos que se presentan a continuación profundizan en aspectos específicos de la seguridad SSH:

• Todo lo que necesitas saber sobre SSH, para conocer los fundamentos del protocolo antes de adentrarse en la gestión del ciclo de vida.
• Eliminación de las brechas de acceso SSH, para cerrar las brechas de proceso específicas que permiten que se acumule el acceso no controlado.
• Propiedad de la clave SSH, para un análisis más profundo de los modelos de asignación y aplicación de la propiedad.
• Explosión de claves SSHpara comprender cómo se produce el crecimiento descontrolado de las claves y cómo revertirlo.
• Claves SSH no administradas, por los riesgos específicos de las llaves sin propietario rastreable.
• Vulnerabilidades de SSH: Cómo protegerse contra ellas, por vulnerabilidades a nivel de protocolo y de implementación.
• Cómo proteger SSH contra ataques, para reforzar SSH contra las técnicas de ataque que conducen a su vulneración.
• Respuesta a incidentes por claves SSH expuestas, para consultar el manual completo de respuesta a incidentes mencionado anteriormente.
• SSH seguroPlataforma de Encryption Consulting para el descubrimiento, la política, la rotación y la auditoría a lo largo del ciclo de vida de las claves SSH.

Referencias

• NIST IR 7966: Seguridad de la gestión de acceso interactiva y automatizada mediante Secure Shell (SSH), Instituto Nacional de Normas y Tecnología
• NIST SP 800-57 Parte 1 Revisión 5: Recomendación para la gestión de claves, general, Instituto Nacional de Normas y Tecnología
• Guía para mejorar la visibilidad y el fortalecimiento de la infraestructura de comunicacionesAgencia de Ciberseguridad y Seguridad de Infraestructuras
• Página del manual de ssh-keygen(1)Proyecto OpenBSD/OpenSSH