Cumplimiento de la gestión de claves SSH: qué esperan los auditores y cómo lograrlo.

Las claves SSH son credenciales potentes y duraderas que los auditores ahora exigen que sean gestionadas, supervisadas, rotadas y revocadas a tiempo. Las claves SSH no caducan automáticamente, lo que significa que la organización debe aplicarles la misma disciplina de gestión del ciclo de vida que a cualquier otra credencial privilegiada. Sin una gobernanza activa, las claves SSH se acumulan como puertas traseras sin protección: sin fecha de caducidad, sin registro de propiedad y sin rastro de auditoría. La acción recomendada es tratar cada clave SSH como una credencial privilegiada, crear un inventario, asignar la propiedad, garantizar la rotación y la revocación, y mantener los registros de sesión y la evidencia de revisión de acceso que exigen PCI DSS, ISO 27001, SOC 2, NIST y CIS.

Respuesta rápida: ¿Qué significa el cumplimiento de la gestión de claves SSH?

El cumplimiento de la gestión de claves SSH implica demostrar a los auditores que cada clave SSH en su entorno es propiedad de, está controlada, supervisada y eliminada a tiempo. Los principales marcos, incluidos PCI DSS v4.0.1, ISO 27001, SOC 2 y NIST SP 800-53, exigen que las claves SSH se gestionen con la misma disciplina que otras credenciales privilegiadas. La diferencia entre aprobar y reprobar una auditoría de claves SSH casi siempre radica en un problema de proceso y evidencia, no en uno criptográfico. Para obtener información sobre el marco fundamental de rotación de claves SSH, consulte Diseño de una política eficaz de rotación de claves SSH . Para acceder a la página del pilar de gobernanza de claves SSH, consulte Cómo la gestión de claves SSH refuerza la seguridad.

¿Por qué las claves SSH se convirtieron en un problema de cumplimiento normativo?

El diseño de la clave SSH genera el problema de cumplimiento. Una clave SSH consta de dos partes: la clave privada permanece con el usuario o el servicio; la clave pública se encuentra en el servidor de destino, en un archivo llamado authorized_keys. Cuando ambas coinciden, se concede el acceso sin solicitar contraseña ni fecha de caducidad predefinida. Puede consultar la arquitectura del protocolo en el RFC 4251.

Ese diseño es práctico, pero ahí radica el problema. Las claves se acumulan sin control, ya que la limpieza casi siempre es manual. Con el paso de los años, la mayoría de los equipos pierden la noción de cuántas claves existen y a qué puede acceder cada una. En el sector, esto se conoce como proliferación de claves : demasiadas claves sin un registro claro de quién las posee ni qué desbloquean. Un auditor lo denomina acceso no controlado.

La proliferación de sistemas es solo una parte del problema. La mayoría de las sesiones SSH nunca se registran, por lo que no existe un registro de auditoría que indique quién se conectó, cuándo y a qué. Sin ese registro, una sola clave mal utilizada puede convertirse en una brecha de seguridad imposible de explicar, reconstruir o atribuir. Actualmente, las identidades de las máquinas superan con creces a las identidades humanas, y esta brecha sigue creciendo a medida que se expanden la nube, la automatización y la IA. Muchas de estas identidades de máquinas se autentican con claves SSH. Si la organización no puede determinar quién es el propietario de una clave ni qué desbloquea, no puede demostrar el control durante una auditoría de cumplimiento.

¿Qué significa "gestionado" en términos de cumplimiento normativo?

Los auditores no solicitan inspeccionar las claves privadas, sino observar el proceso. La referencia más clara proviene del NIST. El Informe Interno del NIST (NISTIR) 7966 es la guía oficial para proteger el acceso SSH. Describe el ciclo de vida de la clave: solicitar y aprobar el acceso, aprovisionarla, supervisar su uso, rotarla periódicamente y eliminarla cuando ya no sea necesaria.

Un programa de claves SSH preparado para auditorías abarca seis aspectos:

• Inventario: Cada llave está documentada, se conoce su ubicación y se registra a qué puede acceder.
• Propiedad: Cada clave está vinculada a una persona o un servicio específico.
• Privilegios mínimos: Una llave solo alcanza lo que su función requiere, nada más.
• Rotación: Las llaves se cambian según lo programado y de inmediato cuando alguien se va o se sospecha que se ha producido una vulneración de la seguridad.
• Monitoreo: Todas las sesiones privilegiadas quedan registradas y esa actividad se revisa en busca de patrones anómalos.
• Revocación: El acceso se revoca rápidamente y la organización puede demostrar, con registros fechados, que esto ocurrió.

Si se omite cualquiera de estos elementos, aparecerá una deficiencia que el evaluador detectará. Estos mismos seis controles son los que exigen los principales marcos de cumplimiento normativo.

¿Cómo gestionan las principales plataformas las claves SSH?

Casi ningún marco de trabajo menciona las palabras clave SSH. Describen resultados. Una vez que esos resultados se interpretan como reglas sobre credenciales, la correspondencia se vuelve clara:

Marco conceptual	Lo que espera de tus claves SSH	Controles clave relevantes para SSH
PCI DSS v4.0.1	Identidad única para cada usuario, sin credenciales compartidas, control estricto sobre las claves de cuenta del sistema.	Requisito 8 (identidad de usuario, prohibición de clave compartida); Requisito 8.6 (cuentas de aplicación/sistema, prohibición de secretos codificados); Requisito 7.2.4 (revisiones de acceso cada seis meses)
ISO / IEC 27001: 2022	Identidades gestionadas, derechos de acceso controlados, acceso privilegiado protegido, uso adecuado de la criptografía.	Anexo A 5.15 a 5.18 (gestión de identidad y acceso); 8.2 (acceso privilegiado); 8.24 (uso de criptografía)
SOC 2	Controles de acceso lógicos que otorgan, revisan y revocan el acceso con pruebas demostrables.	CC6.1 (controles de acceso lógico); CC6.2 (autenticación); CC6.3 (eliminación de acceso)
SP 800-53 del NIST	Gestión de cuentas, control de acceso y gestión de autenticadores.	AC-2 (gestión de cuentas); AC-3 (control de acceso); IA-5 (gestión de autenticadores)
Controles CIS v8	Gestión de cuentas y control de acceso, eliminación de credenciales obsoletas o no utilizadas.	Control 5 (gestión de cuentas); Control 6 (gestión de control de acceso)

PCI DSS es el marco más estricto en este tema. Los requisitos futuros de PCI DSS v4.0.1 se volvieron obligatorios el 31 de marzo de 2025. El requisito 8 exige identidades únicas para todos los usuarios. Las claves SSH compartidas incumplen esta regla, ya que los registros de autenticación no pueden distinguir a un usuario de otro cuando se comparte una sola clave. El requisito 8.6.2 exige que las contraseñas y frases de contraseña para las cuentas de aplicaciones y sistemas no estén codificadas directamente en scripts, archivos de configuración o código fuente. El mismo objetivo se aplica directamente a las claves privadas SSH: una clave privada integrada en un script de implementación es precisamente la credencial codificada directamente a la que apunta este requisito.

La norma ISO/IEC 27001:2022 adopta un enfoque basado en el riesgo. Sus controles del Anexo A exigen la gestión de identidades, el control de derechos de acceso, la protección del acceso privilegiado y el uso adecuado de la criptografía. Las claves SSH abarcan estas cuatro áreas. La norma SOC 2 se centra en si los controles de acceso lógico funcionan correctamente y si la organización puede demostrar su eficacia. Los controles CIS son los más específicos desde el punto de vista operativo, con pasos sencillos para la gestión de cuentas y la eliminación de accesos que ya no se utilizan.

También se aplican las normativas de privacidad. El artículo 32 del RGPD exige una seguridad adecuada de los datos personales. Una clave SSH no gestionada que expone los sistemas que contienen datos personales constituye un fallo de seguridad según la ley. La HIPAA impone requisitos de control de acceso similares para los sistemas sanitarios. El patrón en todos los marcos normativos es el mismo: conozca sus credenciales, limítelas, protéjalas y elimínelas a tiempo.

Propiedad del ciclo de vida de las claves SSH para el cumplimiento normativo

Etapa del ciclo de vida	Actividad	Propietario	Se presentaron pruebas de cumplimiento
Solicitud y aprobación	El usuario o el servicio solicitan acceso SSH; el acceso se aprueba en función de la necesidad del negocio y la revisión de privilegios mínimos.	Revisor de acceso; gerente	Registro de aprobación con justificación comercial
Aprovisionamiento	Par de claves generado mediante un algoritmo aprobado (Ed25519 preferido, RSA-3072 mínimo); clave pública implementada en servidores autorizados.	Plataforma de gestión de claves SSH o administrador de claves	Registro de generación con algoritmo, huella digital de clave y sistemas objetivo.
Uso y seguimiento	Todas las sesiones SSH se registran con huella digital de clave, marca de tiempo, IP de origen y sistema de destino.	Registro automatizado; operaciones de seguridad	Registros de sesión para revisión de cumplimiento y respuesta a incidentes
Revisión periódica del acceso	Se revisaron todas las autorizaciones de claves SSH; se eliminaron las claves huérfanas o no autorizadas; se confirmó la propiedad.	Custodio de claves; revisor de acceso	Registro de revisión fechado con las acciones tomadas (llaves retiradas, rotadas, confirmadas)
Rotación	La clave se rota según un cronograma definido por la política (basado en el tiempo) o mediante un evento desencadenante (salida, compromiso, obsolescencia).	Plataforma automatizada de gestión de claves SSH	Registro de rotación con fecha, tipo de activación y operador.
Revocación	Clave pública eliminada de todos los archivos authorized_keys; acceso confirmado eliminado	Disparador automático en caso de salida o evento de compromiso	Registro de revocación con fecha de activación, fecha de finalización y confirmación.

Activadores de rotación: Cuando la rotación programada no es suficiente

Los cronogramas de rotación basados ​​en el tiempo constituyen la base de cumplimiento. Los disparadores basados ​​en eventos son la red de seguridad que previene los hallazgos de auditoría más graves:

• Salida de un empleado o cambio de puesto: Rote y revoque inmediatamente todas las claves SSH que posea la persona que se marcha o cambia de rol. Documente el tiempo transcurrido desde la notificación de salida hasta la finalización de la revocación; los auditores revisan este lapso.
• Compromiso de seguridad clave sospechado o confirmado: Revocar inmediatamente la clave afectada; generar e implementar una clave de reemplazo; documentar la cronología del incidente.
• Algoritmo obsoleto: Cualquier clave SSH que utilice un algoritmo obsoleto (DSA, RSA-1024) debe reemplazarse inmediatamente por un algoritmo aprobado. Para comparar algoritmos, consulte Comparación de claves SSH: RSA, DSA, ECDSA o EdDSA.
• Desmantelamiento del sistema: Revoque todas las claves SSH asociadas a los sistemas dados de baja; no reutilice las claves en diferentes sistemas.
• Finalización del contrato con terceros o contratistas: Revocar todo el acceso SSH otorgado a terceros al finalizar la relación.

¿Qué errores relacionados con las claves SSH provocan fallos en las auditorías?

La mayoría de los hallazgos de las auditorías no son excepcionales. Se repiten en todas las organizaciones:

• Claves huérfanas: Un miembro del equipo se marcha, pero su clave permanece activa en los servidores. El requisito 8 de PCI DSS y NIST AC-2 exigen la eliminación oportuna del acceso que ya no sea necesario.
• Claves compartidas: Varias personas utilizan una misma clave, por lo que ningún registro puede rastrear las acciones hasta un individuo. El requisito 8 de PCI DSS exige identidades únicas; las claves compartidas infringen directamente este requisito.
• Claves codificadas: claves privadas incrustadas en scripts, imágenes de contenedores o archivos de configuración. El requisito 8.6.2 de PCI DSS prohíbe explícitamente el uso de secretos codificados directamente en el código para las cuentas del sistema.
• Sin rotación: Las claves proporcionadas hace años siguen funcionando hoy en día sin necesidad de una rotación documentada. Todo framework requiere algún tipo de gestión del ciclo de vida de las credenciales.
• Sin registro de auditoría: No hay registro de quién se conectó, cuándo y a qué sistema. Las normas SOC 2 CC6 y NIST AC-3 exigen pruebas de que los controles de acceso funcionan correctamente.
• Sin inventario: La organización no puede proporcionar una lista actualizada de claves SSH bajo demanda. El inventario es un requisito previo para cualquier otro control; sin él, no se puede demostrar ningún requisito del marco de trabajo.

¿Cómo se crea un programa de claves SSH preparado para auditorías?

Un proceso constante y repetible es lo que permite superar las auditorías. El siguiente flujo de trabajo de implementación de 7 pasos crea el registro de evidencia que los auditores requieren:

1. Construye el inventario: Analice cada servidor y lea cada archivo authorized_keys. Cree un inventario centralizado de claves, propietarios y los sistemas a los que pueden acceder. No se puede controlar lo que no se ve; sin un inventario, no se puede demostrar ningún otro control de cumplimiento.
2. Asigne la propiedad a cada clave: Una llave sin propietario no tiene responsabilidad. Elimine cualquier llave que ningún propietario reclame. Documente la propiedad en el inventario, indicando el rol, la unidad de negocio y la justificación del acceso.
3. Redacte una política breve y clara: Definir períodos de rotación por nivel de riesgo (alto riesgo cada 30 a 90 días, medio cada 90 a 180 días, bajo cada 180 a 365 días); requerir claves únicas por persona y propósito; prohibir claves compartidas; prohibir claves privadas codificadas directamente en el código. Ver Diseño de una política eficaz de rotación de claves SSH para el marco completo.
4. Automatizar la rotación y la revocación: La desvinculación y rotación manual son los procesos donde surgen las deficiencias en el cumplimiento normativo. La rotación automatizada elimina el lapso entre el día en que una persona se marcha y el día en que se le retira el acceso. Registre cada rotación con la fecha y el operador para tener constancia de auditoría.
5. Habilitar y centralizar el registro de sesiones: Registre cada sesión SSH privilegiada con la huella digital de la clave, la dirección IP de origen, la marca de tiempo y el sistema de destino. Envíe los registros a un SIEM. La evidencia debe estar lista antes de que el auditor la solicite.
6. Realizar revisiones periódicas de acceso: PCI DSS requiere revisiones semestrales; CIS Controls requiere revisiones trimestrales. Las revisiones trimestrales cumplen con ambos requisitos y permiten detectar vulnerabilidades latentes antes de que se conviertan en problemas. Documente cada revisión con las fechas y las acciones tomadas.
7. Considere la posibilidad de utilizar certificados SSH de corta duración: El estado final más sólido para el cumplimiento. En lugar de claves permanentes, una Autoridad de Certificación de confianza emite certificados que caducan en horas. El acceso desaparece automáticamente; no hay claves antiguas que eliminar posteriormente. Este modelo satisface el espíritu de todos los marcos anteriores. Ver Claves SSH frente a certificados SSH y Transforme las claves SSH estáticas en identidades de carga de trabajo de corta duración. para orientación sobre la implementación.

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

Los auditores solicitan tipos de evidencia específicos. Configure la administración de claves SSH para generarlos antes de que comience la evaluación:

• Inventario actual de claves SSH: Se enumeran todas las claves, su huella digital, propietario, servidores de implementación, ámbito de acceso, fecha de creación, fecha de última rotación y fecha de último uso observado.
• Registros de revisión de acceso: Registros fechados de revisiones periódicas que incluyen qué claves fueron revisadas, las acciones tomadas (revocadas, rotación activada, propiedad confirmada) y la identidad del revisor.
• Evidencia de rotación: Registros que muestran que las llaves se rotaron según un cronograma o al activarse un evento, con fechas, tipo de activación e identidad del operador.
• Pruebas de revocación: Registros de la eliminación del acceso SSH de los empleados que se han marchado, incluyendo la fecha de salida, la fecha de finalización de la revocación y la confirmación de que las claves públicas se eliminaron de todos los servidores autorizados.
• Registros de sesión: Registros de sesiones SSH privilegiadas que muestran la huella digital de la clave, la dirección IP de origen, la marca de tiempo y el sistema de destino, conservados durante el período requerido por el marco aplicable.
• Documentación de políticas: La política escrita de gestión de claves SSH define los criptoperíodos, los requisitos del algoritmo, la prohibición de claves compartidas, la prohibición de claves codificadas y el procedimiento de respuesta ante incidentes en caso de sospecha de compromiso de clave.

Plan de respuesta ante incidentes relacionados con el cumplimiento de las claves SSH

1. Revocación inmediata: Revocar la clave presuntamente comprometida en todos los servidores donde esté autorizada; confirmar que la revocación se ha completado y 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; desplegar 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 sesión para detectar accesos durante el período en el que se sospecha que se produjo la vulneración; determinar si se produjo alguna actividad no autorizada.
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 violaciones de seguridad aplicables.
5. Documentación de cumplimiento: Documente la cronología del incidente, la causa raíz (cómo se expuso la clave), el cronograma de revocación, el reemplazo y el alcance del acceso. Esta documentación cumple con los requisitos de evidencia de respuesta a incidentes de PCI DSS, HIPAA e ISO 27001.
6. Actualización de la política posterior al incidente: Identifique qué control falló (falta de inventario, retraso en la baja de empleados, clave codificada) y actualice la política de gestión de claves SSH para solucionar el problema.

Cómo puede ayudar la consultoría de cifrado

Un sólido cumplimiento de la gestión de claves SSH requiere más que políticas: requiere automatización que genere el registro de evidencia que esperan los auditores. SSH Secure de Encryption Consulting aborda los seis controles de cumplimiento:

• Inventario centralizado en tiempo real: El descubrimiento, tanto con agentes como sin ellos, localiza cada clave SSH con datos de propiedad y uso, satisfaciendo así los requisitos de inventario y propiedad de cada plataforma.
• RBAC basado en políticas: Cada clave está restringida únicamente a los sistemas que requiere su función, cumpliendo así con los controles de privilegios mínimos. Los flujos de trabajo de aprobación generan los registros de justificación de acceso que solicitan los auditores.
• Rotación y revocación automatizadas: La rotación programada y la revocación instantánea ante eventos desencadenantes (salida, vulneración de la seguridad) cierran el período de acceso. Cada evento de rotación y revocación se registra con la fecha, el tipo de desencadenante y la identidad del operador como evidencia de cumplimiento.
• Registro de sesiones e integración con SIEM: Toda la actividad de las sesiones SSH privilegiadas se registra y se integra con los paneles de control de Splunk o Loki-Grafana, cumpliendo así con los requisitos de supervisión y auditoría de PCI DSS, SOC 2 y NIST.
• Claves efímeras y vinculadas a la sesión: Las claves privadas están protegidas en módulos de seguridad de hardware (HSM) validados según FIPS 140-3; las claves efímeras emitidas para operaciones confidenciales caducan automáticamente, eliminando por completo el problema de la limpieza.
• Informes de cumplimiento descargables: Exportaciones listas para auditoría de inventario clave, historial de rotación, registros de revocación y registros de sesiones en formatos preparados para la revisión del evaluador.

El acceso SSH Just-in-Time (JIT) va un paso más allá, ya que concede las credenciales solo cuando son necesarias y las revoca automáticamente, de modo que no queda ningún acceso permanente que pueda ser explotado una vez finalizada la sesión.

Conclusión

Las claves SSH son potentes, discretas y fáciles de olvidar. Esta combinación las convierte en un riesgo para el cumplimiento normativo. La solución es sencilla: conocer cada clave, asignar un propietario, limitar su alcance, rotarlas y revocarlas a tiempo, registrar las sesiones y revisar el acceso con frecuencia. Si se siguen estas seis acciones de forma sistemática, la mayoría de las normativas PCI DSS, ISO 27001, SOC 2, NIST y CIS se cumplen automáticamente. Al tratar las claves SSH como las credenciales privilegiadas que son, la próxima auditoría se convierte en una revisión de controles bien documentados en lugar de un intento desesperado por reconstruir el historial de acceso. Para obtener más información, consulte « Diseño de una política eficaz de rotación de claves SSH» , «Protección de claves SSH con HSM » y «Superación de auditorías de claves SSH».

Preguntas frecuentes

¿Qué requisitos exige el cumplimiento de la normativa de gestión de claves SSH?

Seis controles para cada clave: inventario (cada clave documentada con su ubicación y alcance de acceso), propiedad (cada clave vinculada a una persona o servicio específico), privilegio mínimo (cada clave solo accede a los sistemas necesarios), rotación (según un cronograma y de inmediato al finalizar el acceso o en caso de vulneración), supervisión (cada sesión privilegiada registrada y revisada) y revocación (el acceso se elimina rápidamente con evidencia fechada).

¿Qué marcos de cumplimiento abordan específicamente las claves SSH?

Ningún marco menciona explícitamente la clave SSH. Describen resultados de credenciales: PCI DSS v4.0.1 Requisito 8 (identidades únicas, sin claves compartidas, prohibición de secretos codificados en el Requisito 8.6.2); ISO 27001:2022 Anexo A 5.15-5.18, 8.2, 8.24 (gestión de identidades, acceso privilegiado, criptografía); SOC 2 CC6.1-CC6.3 (controles de acceso lógico con evidencia); NIST SP 800-53 AC-2, AC-3, IA-5; CIS Controls v8 Controles 5 y 6.

¿Cuáles son los problemas más comunes con las claves SSH que provocan fallos en las auditorías?

Claves huérfanas (claves de exempleados aún activas); claves compartidas (sin auditoría por usuario); claves codificadas en scripts o imágenes (incumple la norma PCI DSS 8.6.2); sin documentación de rotación; sin registro de auditoría de sesión; sin inventario (no se puede generar una lista de claves bajo demanda). Cada una se corresponde con un control de marco específico.

¿Con qué frecuencia se deben revisar las claves SSH para comprobar su conformidad?

El requisito 7.2.4 de PCI DSS exige revisiones de acceso al menos cada seis meses; el Control 5 de CIS exige revisiones trimestrales. Las revisiones trimestrales cumplen con ambos requisitos. También se requieren revisiones basadas en eventos: la salida de un empleado y la sospecha de una vulneración de seguridad exigen la revocación inmediata, no el siguiente ciclo de revisión programado.

¿Qué pruebas debe presentar una organización para una auditoría de cumplimiento de claves SSH?

Inventario de claves actual; registros de revisión de acceso fechados con las acciones tomadas; evidencia de rotación con fechas y tipo de activación; evidencia de revocación con fecha de salida y fecha de finalización de la revocación; registros de sesión con huella digital de la clave, IP de origen, marca de tiempo y destino; y política escrita de administración de claves SSH con criptoperíodos y procedimiento de respuesta a incidentes.

¿Cómo ayuda SSH Secure a cumplir con los requisitos de cumplimiento de las claves SSH?

SSH Secure ofrece: inventario en tiempo real con datos de propiedad; control de acceso basado en roles (RBAC) para garantizar el mínimo privilegio; rotación automatizada basada en políticas y revocación activada por eventos con registros de auditoría; registro de sesiones con integración SIEM; emisión de claves efímeras; e informes de cumplimiento descargables listos para la revisión del evaluador. Las claves privadas están protegidas en módulos de seguridad de hardware (HSM) validados según FIPS 140-3.