Propiedad de las claves SSH: Cómo mapear todas las credenciales privilegiadas antes de su próxima revisión de acceso.

Toda revisión de acceso se basa en la premisa implícita de que, para cada credencial que otorga acceso a un sistema sensible, alguien puede responder tres preguntas: ¿Quién es el propietario? ¿Por qué existe? ¿Debería seguir existiendo? En el caso de las cuentas humanas vinculadas a un directorio y a un registro de Recursos Humanos, estas preguntas suelen tener respuesta. Sin embargo, para las claves privilegiadas que utilizan las máquinas, los servicios y la automatización para comunicarse entre sí, sobre todo las claves SSH, con frecuencia no la tienen.

Una clave SSH es una credencial que permite que una máquina o usuario inicie sesión en otra mediante el protocolo Secure Shell (SSH) , generalmente con acceso administrativo o de superusuario. A diferencia de una contraseña, una clave SSH no caduca automáticamente, no guarda ningún registro de quién la creó y rara vez está vinculada a un directorio o sistema de recursos humanos. Esta combinación (altos privilegios, larga duración y ausencia de un propietario inherente) convierte a las claves SSH en la credencial más difícil de gestionar y en el tema central de este artículo.

Esta es la incómoda realidad que se esconde tras muchas campañas de certificación aparentemente impecables. Los revisores certifican las cuentas humanas que pueden ver, mientras que una cantidad mucho mayor de claves SSH, tokens de API y credenciales de cuentas de servicio quedan completamente fuera de la revisión, a menudo con acceso privilegiado o incluso de administrador. Este artículo trata de cerrar esa brecha. Explica por qué es tan difícil establecer la propiedad de las claves SSH y otras credenciales privilegiadas, qué consecuencias tiene que una revisión se lleve a cabo sin ello y cómo crear el mapeo de descubrimiento y propiedad (la base de una gestión eficaz de claves SSH ) que garantice que la próxima revisión de acceso sea honesta en lugar de una mera aspiración.

¿Por qué es importante la propiedad de las claves privilegiadas?

Tres factores han transformado la propiedad de las claves privilegiadas, pasando de ser un detalle administrativo a una prioridad de gobernanza: las identidades de máquinas superan con creces a las humanas, una gran parte de ellas carecen de propietario y los reguladores y las aseguradoras han comenzado a preguntarse quién es responsable de ellas. En conjunto, estos factores explican por qué la próxima revisión de acceso no puede dejar fuera del alcance las credenciales no humanas.

Actualmente, las identidades de las máquinas superan en número a las de los humanos.

La gobernanza del acceso se diseñó para un mundo donde los humanos representaban la mayoría de las identidades. Ese mundo ya no existe. Las identidades no humanas superan drásticamente a las humanas. Los informes de la industria indican que el desequilibrio entre las identidades de las máquinas y las humanas sigue aumentando. Si una revisión de acceso solo abarca las cuentas humanas, se está revisando una pequeña y menguante fracción de quienes realmente pueden acceder a la producción.

El verdadero problema es el volumen no propietario

El problema no radica simplemente en el volumen; se trata de un volumen sin propietario. Una parte significativa de las identidades empresariales no tiene propietario en los sistemas de RR. HH. porque el creador se marchó, pero la cuenta y su acceso permanecieron, y muchas identidades no humanas tienen más de un año sin que se haya realizado ninguna rotación de credenciales. Una revisión de acceso sin datos de propiedad no puede tomar una decisión sobre si revocar o conservar; solo puede aprobarla sin más.

Los reguladores y las aseguradoras ahora lo esperan.

Las expectativas se han endurecido. Marcos como el Marco de Ciberseguridad 2.0 del NIST y la Directiva NIS2 de la UE hacen cada vez más referencia a la gobernanza de la identidad de las máquinas, y los analistas señalan que las organizaciones se enfrentan a una mayor presión en materia de cumplimiento normativo relacionado con los privilegios, ya que las aseguradoras exigen controles de privilegios más estrictos. Los revisores ya no pueden considerar las claves privilegiadas no asignadas como un problema ajeno.

¿Por qué es tan difícil obtener acceso a claves privilegiadas?

Si ya se ha resuelto la cuestión de incluir las claves privilegiadas en el ámbito de aplicación, la pregunta más difícil es por qué resulta complicado hacerlo. La dificultad radica en su estructura, no en el esfuerzo que requiere. Una clave privilegiada es simplemente una credencial que otorga acceso elevado, pero las claves SSH, en particular, carecen de identidad propia, nunca caducan automáticamente y establecen relaciones de confianza implícitas entre sistemas. Comprender por qué se resisten a ser registradas y qué información debe contener un registro de propiedad útil es fundamental para todo lo que sigue.

¿Qué se considera una clave privilegiada?

En este contexto, una clave privilegiada es cualquier credencial no humana que otorga acceso elevado a un sistema: una clave privada SSH que se autentica en un servidor, un token de API, un secreto de cliente OAuth, una contraseña de cuenta de servicio o una credencial de carga de trabajo en la nube. Las claves SSH representan el caso más complejo, ya que son simultáneamente de alto privilegio y de estructura opaca. Las concesiones SSH suelen otorgar privilegios elevados, a menudo de nivel de administrador, pero la clave en sí misma prácticamente no contiene información de identidad.

¿Por qué las claves SSH se resisten a ser controladas?

Una clave pública SSH en un servidor es una decisión de acceso permanente y no supervisada. El sistema operativo simplemente afirma que quien posea la clave privada correspondiente puede autenticarse como esa cuenta. Para el demonio SSH, una clave administrativa legítima y una clave huérfana parecen idénticas. No hay usuario asociado, ni fecha de caducidad, ni vínculo a un directorio. Un entorno Linux típico acumula una mezcla de claves de usuario, claves de root, claves de servicio, claves de despliegue, claves de emergencia, claves de proveedor y restos de scripts descontinuados, y el protocolo no ofrece ninguna forma de distinguirlas.

La causa principal es la falta de coincidencia en el ciclo de vida. Las contraseñas caducan y las cuentas de inicio de sesión único se desactivan, pero las claves SSH, a menos que se gestionen de forma específica, permanecen válidas indefinidamente. Se generan fácilmente y sin aprobación, razón por la cual la guía del NIST destaca la necesidad de un aprovisionamiento, terminación y supervisión estrictos del acceso SSH.

Cómo las relaciones de confianza distribuyen el riesgo

La propiedad se complica aún más por las relaciones de confianza entre sistemas. Las claves SSH se utilizan para establecer conexiones automatizadas entre sistemas e incluso entre organizaciones, y las claves no gestionadas pueden convertir esas relaciones de confianza en infracciones de políticas; por ejemplo, una clave que conecta silenciosamente un sistema de desarrollo con uno de producción. Estas redes de confianza son precisamente las que permiten a un atacante que compromete un host acceder a muchos otros. Son invisibles para una revisión que solo analiza cuentas individuales.

Lo que debe incluir un registro de propiedad útil

Determinar la propiedad implica más que simplemente asignar un nombre. Un registro de propiedad útil para una clave privilegiada debe incluir al propietario o equipo responsable, la ubicación de la clave privada, sus permisos de acceso, la fecha de su último uso, su antigüedad y estado de rotación, así como la justificación empresarial de su existencia. En el caso específico de SSH, esto incluye mapear la relación entre una clave privada en la máquina de un usuario o en una canalización y cada entrada de authorized_keys que pueda satisfacer. Las herramientas de detección que registran las rutas de archivo y el contexto de detección son valiosas precisamente porque permiten a un auditor rastrear un hallazgo hasta su origen para su corrección.

¿Qué sucede cuando falta la propiedad?

Cuando se lleva a cabo una revisión de acceso sin datos de propiedad de las claves privilegiadas, las consecuencias son concretas.

Modo de fallo	¿Qué va mal?	Impacto en el negocio
El acceso para huérfanos sobrevive	Las llaves de los empleados que se han marchado nunca se marcan como sospechosas porque ningún propietario activa su eliminación.	Puertas traseras permanentes sin seguimiento en sistemas privilegiados.
Los críticos se rinden ante el miedo.	Los equipos evitan eliminar las claves que no comprenden.	El acceso obsoleto y excesivamente amplio persiste indefinidamente.
Respuesta lenta a incidentes	Las claves comprometidas no se pueden localizar ni revocar rápidamente.	Mayor radio de explosión y mayor tiempo de permanencia del atacante.
Deficiencias en auditorías y cumplimiento normativo	No existe documentación que acredite el propietario ni justificación para el acceso privilegiado.	Hallazgos y sanciones según PCI DSS, HIPAA, GDPRy regímenes similares.
Falsa seguridad	La certificación cubre únicamente a los seres humanos y se firma como completa.	Los líderes creen que el acceso está regulado, cuando no es así.

Los críticos dejan intacto lo que no pueden explicar.

Una de las dinámicas más perjudiciales es la cautela racional. Dado que los sistemas de producción suelen depender de una automatización mal documentada, los equipos de seguridad simplemente evitan la rotación y eliminación de claves por temor a interrumpir las operaciones. El resultado es que las claves que más necesitan revisión, aquellas cuya causa nadie puede explicar, son precisamente las que un revisor precavido deja intactas. Los datos de propiedad rompen esa parálisis al sustituir el miedo por evidencia.

Los datos con los que empiezas ya están dañados.

El punto de partida es desfavorable. Los estudios indican que entre el 60 y el 90 por ciento de las organizaciones carecen de un inventario completo de sus claves SSH activas, y una gran parte depende de procesos manuales, como hojas de cálculo, para su seguimiento. No es posible determinar la propiedad de decenas de miles de claves con una hoja de cálculo, y una revisión basada en datos incompletos hereda todas las lagunas existentes.

¿Cómo establecer la titularidad antes de la próxima revisión?

Si la falta de responsabilidad es lo que impide una revisión, la solución consiste en reconstruirla deliberadamente. Cerrar esta brecha de responsabilidad es un proceso secuencial, y la mayor parte puede completarse antes del siguiente ciclo de revisión si se inicia de forma planificada.

1. Descubra de forma exhaustiva todas las claves y hosts: Utilice tanto el descubrimiento basado en agentes como el descubrimiento sin agentes para encontrar todas las claves SSH en servidores y equipos de usuario, y aplique la misma metodología a los tokens de API y las credenciales de cuentas de servicio. Priorice la exhaustividad; un descubrimiento parcial ofrece una garantía parcial.
2. Correlacionar las claves con los propietarios utilizando múltiples señales: Asigne las claves privadas a las cuentas y los flujos de trabajo que las utilizan, correlacione con los datos del directorio y de recursos humanos, y utilice la telemetría de último uso para distinguir las claves activas de las inactivas. Si no se encuentra al propietario, esto constituye un hallazgo que debe escalarse, no un registro que se pueda omitir.
3. Clasificar por privilegios y exposición, no solo por edad: Priorice las claves con acceso de administrador o de raíz, las claves que conectan entornos de confianza (como entornos de no producción a entornos de producción) y las claves que no se han rotado según la política establecida. Una clave con un año de antigüedad que no protege nada es menos importante que una clave con una semana de antigüedad con derechos de administrador.
4. Separar el descubrimiento de la remediación: Nunca inicie la limpieza eliminando claves que no reconozca. Realice las eliminaciones por etapas mediante la administración de la configuración durante una ventana de mantenimiento y supervise el comportamiento de la aplicación inmediatamente después, ya que eliminar la clave incorrecta puede interrumpir las copias de seguridad, las implementaciones o el acceso de emergencia.
5. Sustituya las métricas de actividad por métricas de exposición en los informes: En lugar de informar cuántos elementos se revisaron, realice un seguimiento de las identidades sin propietario, las credenciales obsoletas y las claves privilegiadas que acceden a sistemas sensibles fuera de los patrones habituales. Priorice las métricas de exposición sobre el número de revisiones para los informes ejecutivos.
6. Reduzca la población existente para que las futuras revisiones se reduzcan: Siempre que sea posible, sustituya las claves de larga duración por credenciales de corta duración y rotación automática, de modo que haya menos acceso permanente a los atributos. Las directrices sobre identidad no humana priorizan la eliminación total de las credenciales de larga duración en lugar de su rotación periódica.
7. Que la propiedad sea continua, no anual: Integrar el descubrimiento y la propiedad en un inventario continuo para que las nuevas claves adquieran un propietario en el momento de su creación y las claves huérfanas se marquen a medida que aparecen, en lugar de esperar a la siguiente campaña.

¿Qué significa esto para cada parte interesada en la seguridad?

Definir la propiedad no es tarea de un solo equipo. La propiedad de las claves privilegiadas es una responsabilidad compartida, y cada función depende de ella de manera diferente.

• CISO Se necesita una certificación defendible. Aprobar una revisión de acceso que excluya la mayoría de las credenciales privilegiadas representa un riesgo de gobernanza y responsabilidad que los datos de propiedad mitigan directamente.
• Equipos de IAM Es necesario extender la gobernanza más allá de las cuentas humanas. Los mismos controles de ciclo de vida que se aplican a los nuevos empleados, los que se trasladan o los que se marchan deben llegar a las cuentas de servicio, los tokens y las claves, que se comportan de manera diferente y suelen tener una vida útil más larga.
• Arquitectos de seguridad Se pueden utilizar los datos de propiedad y exposición para razonar sobre el radio de acción, limitando hasta dónde puede moverse una sola credencial y cuánto tiempo permanece sin revisión.
• Equipos de PKI y criptografía son propietarios naturales del inventario de claves y pueden integrar las claves SSH en la misma gobernanza aplicada a certificados.
• Equipos de DevSecOps y de plataforma Almacenan el contexto para las credenciales de canalización y servicio, y son esenciales para asignar las claves a la automatización que las utiliza.
• Equipos de auditoría y cumplimiento Obtenga la documentación que acredite al propietario y la justificación que convierta una revisión de una mera formalidad en evidencia de control.

¿Cómo puede ayudar la consultoría de cifrado?

Ejecutar este programa manualmente resulta difícil a escala empresarial, por lo que las herramientas especializadas son de gran ayuda. En Encryption Consulting, comprendemos los retos a los que se enfrentan las empresas al gestionar claves SSH a gran escala. Nuestra solución, SSH Secure , está diseñada para ofrecer seguridad integral del ciclo de vida de las claves, visibilidad centralizada y protección respaldada por HSM, lo que garantiza que las organizaciones puedan gestionar sus claves con confianza y sin complejidad adicional.

Algunas de las características clave de SSH Secure incluyen:

• Mapeo centralizado de visibilidad y propiedad: Mediante una combinación de descubrimiento basado en agentes y sin agentes, SSH Secure localiza cada Clave SSH En todos los servidores y equipos de usuario. Todas las claves se almacenan en un inventario unificado con detalles de propiedad y uso, lo que elimina las claves huérfanas y garantiza la total responsabilidad en todo el entorno.
• 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 y la revocación. Las claves se pueden rotar o revocar bajo demanda o de acuerdo con las políticas de la organización. Para operaciones sensibles, SSH Secure puede emitir claves efímeras vinculadas a la sesión que caducan automáticamente. Esta gestión centralizada del ciclo de vida garantiza el acceso con privilegios mínimos, reduce el riesgo de vulneración y asegura que las claves no permanezcan válidas más allá de su uso previsto.
• Protección integrada HSM: Todas las claves privadas se generan y almacenan dentro de los HSM. Las claves se generan utilizando algoritmos criptográficos robustos como RSA-4096, ECDSAy Ed25519, que proporcionan una sólida protección criptográfica, resistencia contra ataques criptoanalíticos y un rendimiento eficiente.
• Control basado en políticas para operaciones clave: Todas las operaciones clave, como la generación, los flujos 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 respaldar los modelos de gobernanza interna.
• 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 Grafana Loki 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 información clara sobre el 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.

Implementar la gestión de claves SSH con HSM a escala empresarial implica mucho más que elegir el hardware adecuado. Requiere detección, orquestación del ciclo de vida, aplicación de políticas y visibilidad continua en un entorno complejo. En Encryption Consulting, desarrollamos SSH Secure para gestionar precisamente esto, ofreciendo seguridad integral del ciclo de vida de las claves y protección con HSM sin añadir complejidad operativa.

Conclusión

Una revisión de acceso que no puede identificar al propietario de cada clave privilegiada no es realmente una revisión; es un inventario parcial con una firma adjunta. Las credenciales con mayor probabilidad de causar daño, las claves huérfanas, con privilegios excesivos e inexplicables, son precisamente las que pasan desapercibidas en una verificación humana y las que un revisor prudente probablemente no intervendrá. La solución no reside en una firma más rigurosa, sino en una mejor información subyacente a dicha firma.

Para descubrir quién posee cada clave privilegiada antes de la próxima revisión de acceso, realice una investigación exhaustiva, correlacione las claves con sus propietarios mediante el directorio, la canalización y las señales de uso, priorice por privilegio y exposición en lugar de por antigüedad, e integre toda la información en un inventario continuo para que la propiedad se establezca en el momento de la creación, en lugar de reconstruirse antes de la fecha límite. De esta forma, la próxima revisión de acceso dejará de ser un ejercicio de incertidumbre y se convertirá en una declaración certera sobre quién puede acceder a qué y por qué.