Tu guía definitiva para la gestión de claves SSH en múltiples nubes.

AWS te proporciona un archivo .pem descargable. Azure coloca una clave pública en el archivo authorized_keys de una máquina virtual. GCP, si activas el inicio de sesión del sistema operativo, vincula el acceso SSH a una identidad de IAM en lugar de a un archivo de clave. Tres nubes, tres modelos diferentes para la misma credencial, y la mayoría de los equipos de seguridad lo descubren por las malas: durante una auditoría, una baja de personal o un incidente, cuando nadie puede generar una lista unificada de quién puede acceder por SSH a qué en todo el entorno.

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

¿Por qué la gestión de claves SSH en entornos multi-nube es más difícil que en entornos de una sola nube?

La gestión de claves SSH en entornos multinube es más compleja que en entornos de nube única, ya que no existe un plano de control de claves SSH compartido entre AWS, Azure y GCP. Cada proveedor inyecta, almacena y gestiona las claves mediante su propio mecanismo, y ninguno de estos mecanismos se comunica con los demás. Una clave generada para una instancia EC2 de AWS no guarda relación con una clave implementada en una máquina virtual de Azure o en una instancia de GCP Compute Engine, incluso si el mismo ingeniero gestiona las tres y reutiliza el mismo par de claves por comodidad.

Esa brecha se manifiesta de tres maneras concretas una vez que una organización ejecuta cargas de trabajo en más de una nube:

• Inventarios fragmentados. AWS realiza el seguimiento de pares de claves por región y cuenta, Azure realiza el seguimiento de claves públicas por archivo authorized_keys de la máquina virtual (o por recurso de Azure Key Vault, si un equipo se toma la molestia de configurarlo), y GCP realiza el seguimiento de claves en los metadatos del proyecto o la instancia, o en IAM si el inicio de sesión del sistema operativo está habilitado. Ninguna consola muestra toda la información.
• Líneas de base inconsistentes. Una política de rotación y tipo de clave aplicada en AWS mediante un proceso interno debe aplicarse por separado y manualmente en Azure y GCP, porque ninguna de las tres nubes aplicará automáticamente la política de la otra nube.
• Claves reutilizadas, sin identidad compartida. Los ingenieros suelen copiar la misma clave pública en las tres nubes por comodidad. Ahora, esa clave tiene tres radios de impacto distintos, tres puntos de revocación diferentes y ningún registro que la vincule a un único propietario.

Para obtener información completa sobre la gestión del ciclo de vida de las claves SSH en cualquier entorno, incluyendo la propiedad, los desencadenantes de rotación, la política de acceso y la evidencia de auditoría, consulte la guía «Gestión integral del ciclo de vida de las claves SSH para la seguridad empresarial» de Encryption Consulting . Esta guía se basa en dicha guía y se centra específicamente en los cambios que se producen cuando se debe aplicar la misma metodología en AWS, Azure y GCP simultáneamente.

Los datos detrás de la expansión urbana

La proliferación de claves SSH no es un riesgo teórico. Informes recientes de analistas, estudios de proveedores y encuestas del sector aportan datos que respaldan con precisión hasta qué punto las credenciales no gestionadas, incluidas las claves SSH, han superado la capacidad de gobernanza:

• La proliferación de secretos se está acelerando más rápido de lo que los equipos pueden controlarla. GitGuardian Expansión del estado de secretos 2026 Un informe publicado el 17 de marzo de 2026 reveló que solo en 2025 se expusieron 29 millones de secretos codificados en GitHub público, lo que representa un aumento interanual del 34 % y el mayor incremento anual registrado por la empresa. El mismo informe señala que incidentes recientes en la cadena de suministro, incluido el ataque a LiteLLM, extrajeron específicamente claves SSH junto con credenciales en la nube.
• Las identidades de las máquinas, incluidas las claves SSH, ahora superan con creces a las cuentas humanas. CyberArk Informe sobre el estado de la seguridad de la identidad de las máquinas de 2025Según una encuesta realizada a 1,200 líderes de seguridad, las organizaciones prevén que las identidades de las máquinas sigan aumentando y que los procesos manuales ya no puedan rastrearlas a gran escala, lo que sitúa la proporción de identidades de máquinas con respecto a las identidades humanas en aproximadamente 82 a 1.
• Las filtraciones de datos basadas en credenciales son las más lentas y de las más costosas de detectar. De IBM Costo de un informe de violación de datos de 2025 Se constató que las filtraciones de datos que comenzaron con credenciales robadas o comprometidas promediaron 4.67 millones de dólares y tardaron 246 días en identificarse y contenerse, uno de los ciclos de vida de las filtraciones más largos que registra el informe.

Los entornos multi-nube agravan cada una de estas cifras, ya que la misma clave puede existir, sin ser contabilizada, en tres inventarios distintos en lugar de uno solo.

¿Cómo gestionan AWS, Azure y GCP las claves SSH de forma nativa?

AWS, Azure y GCP tratan el acceso mediante clave SSH como un detalle a nivel de instancia o proyecto, en lugar de una credencial administrada centralmente. GCP es una excepción parcial: su función de inicio de sesión del sistema operativo permite vincular el acceso SSH a la identidad de IAM en lugar de a una clave almacenada, algo que AWS y Azure solo ofrecen como servicios independientes y opcionales, superpuestos a su modelo de clave predeterminado.

AWS: Pares de claves EC2

El modelo predeterminado de AWS es el par de claves EC2. Cuando lanzas una instancia a través de la consola, la CLI o CloudFormation, AWS almacena la clave pública con la instancia y te da exactamente una oportunidad para descargar la clave privada, por Guía del usuario de EC2 de AWSLos pares de claves tienen un alcance por región, con un límite documentado de 5,000 pares de claves por región por cuenta, y no existe un mecanismo integrado para compartir un par de claves entre regiones o cuentas. AWS admite los tipos de clave RSA y ED25519 y permite importar una clave pública generada externamente en lugar de utilizar material generado por AWS, pero la documentación no describe ninguna capacidad de rotación automatizada. Rotar un par de claves EC2 significa generar una nueva clave, actualizar authorized_keys en cada instancia afectada, y retirando el par de claves antiguo, manualmente o mediante su propio sistema de automatización.

AWS también ofrece AWS Systems Manager Session Manager como una alternativa basada en IAM que elimina la necesidad de una clave privada almacenada o un puerto SSH de entrada abierto. No es la opción predeterminada: requiere que el agente SSM se ejecute en la instancia y un rol de IAM que otorgue a la instancia permiso para comunicarse con Systems Manager. Session Manager proporciona acceso controlado por IAM y registro de sesiones, pero coexiste con pares de claves de EC2 en lugar de reemplazarlos en un entorno que ya cuenta con acceso basado en claves integrado en scripts, imágenes y canalizaciones de CI/CD.

Azure: claves SSH por máquina virtual

El modelo predeterminado de Azure se parece al de AWS, pero su alcance es aún más limitado, a la máquina virtual individual. Por Documentación de las máquinas virtuales de Azure de Microsoft, generas un par de claves (comúnmente RSA o ED25519, usando ssh-keygen o el az vm create --generate-ssh-keys bandera), y la clave pública se escribe en esa máquina virtual. ~/.ssh/authorized_keys Archivo creado. La clave privada permanece en la máquina local que la generó, y el mismo par de claves se puede reutilizar en varias máquinas virtuales, lo que simplifica la configuración, pero implica que una clave privada filtrada puede llegar a todas las máquinas virtuales a las que se haya copiado. La propia documentación de Microsoft no describe un inventario de claves a nivel de suscripción, una integración de Azure Key Vault integrada en el flujo estándar de creación de máquinas virtuales ni ninguna aplicación automatizada de la rotación; un equipo puede integrar Key Vault en un script de implementación para generar y almacenar un par de claves, pero ese es un patrón que se debe crear, no una función predeterminada de Azure.

La alternativa de Azure basada en IAM es Inicio de sesión con Microsoft Entra ID para máquinas virtuales Linux, que autentica las sesiones SSH contra las credenciales de ID de Entra y las asignaciones de roles RBAC de Azure en lugar de una clave estática. Al igual que AWS Session Manager, es opcional: requiere la instalación de AADSSHLoginForLinux La extensión de la máquina virtual permite asignar una identidad administrada por el sistema y roles como el de administrador de la máquina virtual. La autenticación estándar con clave pública SSH sigue siendo la predeterminada en Azure, y la mayoría de los entornos utilizan una combinación de máquinas virtuales con Entra habilitado y máquinas virtuales solo con clave, en lugar de un modelo uniforme.

GCP: claves de metadatos o inicio de sesión del sistema operativo vinculado a IAM

GCP comienza desde el mismo lugar que AWS y Azure: por defecto, Compute Engine lee las claves públicas SSH de los metadatos del proyecto o instancia y las escribe en authorized_keys en la máquina virtual de destino, por Las propias directrices de Google sobre cómo añadir claves SSH a las máquinas virtuales.Lo que distingue a GCP es... Inicio de sesión del sistema operativo, una función que reemplaza las claves basadas en metadatos con acceso gobernado por IAM. Con el inicio de sesión del sistema operativo habilitado, un administrador otorga a un usuario el roles/compute.osLogin or roles/compute.osAdminLogin En lugar de distribuir un archivo de clave, se utiliza el rol de IAM, y la documentación de Google describe una evaluación continua por sesión: cuando un administrador elimina el permiso de IAM de un usuario, el acceso SSH de ese usuario se revoca inmediatamente, sin que nadie toque una máquina virtual o un archivo de clave. authorized_keys archivo. OS Login también admite la autenticación de dos factores a través de Google Authenticator, SMS o claves de seguridad, y registra los intentos de conexión con fines de auditoría, según Buenas prácticas de acceso de inicio de sesión SSH de Google.

El inicio de sesión del sistema operativo tampoco es el predeterminado de GCP; debe activarse con un enable-oslogin=TRUE Indicador de metadatos a nivel de proyecto o instancia, según Google. Documentación de configuración de inicio de sesión del sistema operativo. El verdadero factor diferenciador es lo que sucede una vez que está activado: el inicio de sesión del sistema operativo controla el acceso SSH a través del mismo ssh El sistema utiliza el comando y el cliente OpenSSH estándar, empleando IAM como fuente de información principal, sin necesidad de un agente o extensión independiente, a diferencia de AWS Session Manager y el inicio de sesión con Azure Entra ID. Esto facilita la adopción del acceso SSH basado en IAM en toda la infraestructura de GCP, en comparación con las otras dos nubes, aunque sigue requiriendo el mismo despliegue planificado que AWS y Azure.

Tabla de decisiones: Proveedor de nube frente a gestión nativa de claves SSH frente a brecha de centralización

Proveedor de la nube	Manejo nativo de claves SSH	Brecha de centralización
AWS	Pares de claves EC2 por región; clave pública almacenada con la instancia, clave privada descargable una sola vez; RSA o ED25519; hasta 5,000 pares por región; Administrador de sesiones de Systems Manager basado en IAM opcional como complemento.	No incluye rotación integrada; no permite el inventario de claves entre regiones ni entre cuentas; Session Manager requiere la configuración independiente del agente SSM y del rol IAM, y no elimina los pares de claves existentes.
Azure	Entradas authorized_keys por máquina virtual, generadas mediante CLI, portal o plantilla ARM; reutilizables en diferentes máquinas virtuales; inicio de sesión opcional con Microsoft Entra ID para Linux como complemento.	No se documenta ningún inventario de claves a nivel de suscripción; no hay rotación automatizada; el inicio de sesión con Entra ID requiere la extensión AADSSHLoginForLinux y la asignación de roles RBAC además del modelo de clave predeterminado.
GCP	Claves de metadatos de proyecto o instancia por defecto; inicio de sesión del sistema operativo disponible para vincular el acceso a la identidad de IAM, con evaluación continua de permisos y autenticación de dos factores (2FA) opcional.	El inicio de sesión del sistema operativo debe habilitarse explícitamente; un entorno de GCP que nunca lo active es tan descentralizado como AWS o Azure; el propio inicio de sesión del sistema operativo no se extiende a los recursos de AWS o Azure.

Cada fila de esa tabla describe una nube individual de forma aislada. Ninguno de los tres mecanismos (pares de claves EC2, archivos authorized_keys de Azure o inicio de sesión en GCP OS) genera un registro que abarque los otros dos. Esa es la brecha de centralización que un programa multi-nube debe cerrar deliberadamente, porque ningún proveedor la cierra automáticamente.

¿Quién es el responsable del ciclo de vida de las claves SSH en los distintos entornos de la nube?

En una única nube, la propiedad se puede rastrear, al menos en teoría, hasta quien creó el par de claves, la máquina virtual o la vinculación de IAM en esa cuenta. En tres nubes, ese rastro se pierde a menos que la propiedad se asigne de forma centralizada e independiente de la plataforma en la que resida una clave determinada.

Etapa del ciclo de vida	Realidad de nube única	Lo que rompe a través de tres nubes
Generation	El ingeniero crea o importa un par de claves en una consola.	El mismo par de claves se reutiliza con frecuencia en AWS, Azure y GCP por conveniencia, por lo que un evento de generación ahora tiene tres radios de explosión separados sin registro compartido.
	El líder del equipo o el personal de seguridad revisan la solicitud en el flujo de trabajo de esa nube.	Los flujos de trabajo de aprobación difieren según la nube (adjunto de política de IAM en AWS, asignación de rol RBAC en Azure, rol de IAM de inicio de sesión del sistema operativo en GCP), por lo que se debe aplicar un único estándar de aprobación sobre los tres.
Aprovisionamiento	Clave pública escrita en los metadatos de esa nube, en el archivo authorized_keys o en la vinculación de IAM.	No existe una API de aprovisionamiento compartida; una herramienta centralizada o un manual de procedimientos documentado debe aplicar la misma política a través de tres mecanismos de aprovisionamiento diferentes.
Uso	El registro nativo de esa nube (AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs) registra la sesión.	Tres formatos de registro y políticas de retención diferentes implican que la evidencia de uso debe normalizarse antes de que sea útil para una revisión de acceso entre nubes.
Rotación y desmantelamiento	Clave eliminada de esa instancia o metadatos de la nube.	Dar de baja a un ingeniero que tenía acceso a las tres nubes implica tres acciones de eliminación separadas, cada una de las cuales puede pasarse por alto de forma independiente, a menos que un sistema active las tres.

La solución práctica consiste en asignar un único responsable, un rol (no solo una persona), a cada clave en el momento de su creación, y registrar a qué nube o nubes accede dicha clave como parte del mismo registro. Este simple cambio permite que una lista de verificación de desvinculación o una auditoría trate el acceso SSH de esta persona como un solo elemento en lugar de tres.

¿Qué debería desencadenar la rotación y por qué la rotación nativa en la nube suele ser manual o incompleta?

La rotación de claves SSH debería activarse en todas las nubes bajo las mismas tres condiciones: vencimiento del período criptográfico, cambio de personal o de rol, y sospecha de vulneración, según el marco general del NIST IR 7966. Lo que cambia en un entorno multi-nube es que ninguno de los tres proveedores automatiza los tres desencadenantes, y ninguno de ellos rotará una clave en su nombre a menos que usted mismo configure esa automatización.

• AWS No hay rotación programada para los pares de claves EC2. Rotar significa generar un nuevo par de claves y enviar la nueva clave pública a cada instancia afectada. authorized_keys archivo (manualmente, o a través de Systems Manager o su propio sistema de gestión de configuración), y eliminar el par de claves antiguo de la cuenta. Nada en la plataforma le recuerda que esto está vencido.
• Azure La historia es la misma a nivel de VM: nada fuerza una actualización de la clave que se encuentra en authorized_keysY dado que el mismo par de claves se reutiliza habitualmente en muchas máquinas virtuales, un evento de rotación en Azure suele implicar la actualización de docenas de máquinas virtuales una por una, a menos que la administración de la configuración se encargue de ello.
• GCP Las claves de metadatos se comportan como las otras dos: no tienen caducidad ni actualización automáticas. El inicio de sesión del sistema operativo modifica la naturaleza del problema en lugar de resolver la rotación directamente, ya que el acceso está vinculado a una vinculación de IAM en lugar de una clave estática; la revocación del rol de IAM es prácticamente instantánea, lo que funciona como la rotación para el acceso interactivo humano, pero las claves de cuenta de servicio y cualquier clave basada en metadatos que aún esté en uso siguen el mismo patrón manual que AWS y Azure.

La implicación práctica es la siguiente: una política de rotación diseñada para "claves SSH" en general fallará silenciosamente en un entorno multi-nube a menos que especifique, para cada nube, exactamente qué acción cumple con esa política, porque "rotar la clave" significa una secuencia de pasos diferente en cada plataforma.

¿Cómo mantener la coherencia de la política de acceso en tres modelos IAM diferentes?

AWS IAM, Azure RBAC y Google Cloud IAM expresan el control de acceso de forma lo suficientemente diferente como para que una declaración de política escrita para uno no se traduzca directamente a los demás. Mantener la coherencia en la política de acceso implica definirla una sola vez, en términos independientes de la nube, y luego asignarla por separado al modelo de cada proveedor, en lugar de intentar escribir una política nativa y esperar que se generalice.

• El principio del mínimo privilegio, expresado por plataforma. La instrucción "Los administradores de bases de datos de producción obtienen acceso SSH a los hosts de bases de datos de producción" debe convertirse en una política de IAM con ámbito definido en AWS, una asignación de rol RBAC con ámbito definido en Azure y un rol de IAM de inicio de sesión del sistema operativo con ámbito definido en GCP; tres configuraciones separadas que imponen la misma intención.
• Restricciones de origen y de comandos. Ninguna de las tres nubes impone restricciones de IP de origen o de comandos en las sesiones SSH de forma nativa a nivel de plataforma de la misma manera; esos controles, cuando se utilizan, normalmente se configuran en la clave. authorized_keys entrada en sí (AWS, Azure) o a través de las opciones compatibles con OS Login (GCP), por lo que deben aplicarse de manera consistente por cualquier proceso que proporcione la clave, no se asume desde la nube.
• Separación de funciones. La persona que aprueba una solicitud de acceso no debe ser la misma que la otorga, una regla que es fácil de aplicar dentro del flujo de trabajo de una nube, pero fácil de olvidar cuando existen tres flujos de trabajo separados que coexisten.
• Cuenta de servicio y claves de automatización. Las herramientas de gestión de configuración y los pipelines de CI/CD suelen contener claves SSH de larga duración con un amplio alcance a través de los límites de la nube; esas claves necesitan la misma disciplina en materia de políticas que las claves humanas, o incluso más, ya que se utilizan de forma continua y son más difíciles de detectar si se ven comprometidas.

Una capa de gestión de claves SSH independiente de la nube, que se sitúa por encima de AWS IAM, Azure RBAC y GCP IAM en lugar de intentar ser un cuarto modelo incompatible, es lo que hace que el concepto de "una política, tres mecanismos de aplicación" sea alcanzable en lugar de una mera aspiración.

¿Cómo se generan las pruebas de auditoría en varias consolas en la nube?

Generar evidencia de auditoría en AWS, Azure y GCP implica recopilar pruebas de solicitud, aprobación, aprovisionamiento, uso y terminación de tres sistemas de registro distintos, normalizarlas y presentarlas como un único registro por credencial, en lugar de tres fragmentos inconexos. Marcos como SOC 2, ISO/IEC 27001 y PCI DSS exigen que una organización demuestre que el acceso se revisa y revoca de manera oportuna, y a un auditor que pregunta "¿quién pudo acceder a este sistema mediante SSH y demostrarlo?" no le importa que la respuesta abarque tres consolas en la nube diferentes.

• AWS La evidencia proviene de CloudTrail (acciones de pares de claves a nivel de API) y, cuando se utiliza, de los registros de sesión de Session Manager; ninguno de los dos registra de forma nativa qué persona poseía la clave privada para un par de claves EC2 determinado, solo que el par de claves existía y qué llamadas a la API lo afectaron.
• Azure La evidencia proviene del registro de actividad de Azure y de los registros de autenticación a nivel de máquina virtual; dado que un par de claves se puede reutilizar en varias máquinas virtuales, vincular un evento de inicio de sesión específico con una persona específica requiere hacer una referencia cruzada sobre qué clave privada posee realmente esa persona, información que Azure no rastrea.
• GCP La evidencia es más sólida cuando el inicio de sesión del sistema operativo está habilitado, porque los registros de auditoría de la nube vinculan cada sesión directamente a una identidad de IAM en lugar de a una clave anónima; sin el inicio de sesión del sistema operativo, el registro de metadatos y claves de GCP presenta la misma brecha de propiedad que AWS y Azure.

La solución es la misma que resuelve el problema de la propiedad del ciclo de vida: asignar un propietario en el momento de la emisión, registrar a qué nube o nubes accede una clave e introducir los registros de uso de las tres consolas en un único sistema, una plataforma SIEM como Splunk o una herramienta dedicada a la gestión de claves SSH, de modo que la evidencia de auditoría se recopile continuamente en lugar de reconstruirse bajo la presión de los plazos cada vez que un auditor lo solicite.

Un flujo de trabajo práctico para centralizar la gestión de claves SSH en entornos multi-nube.

Centralizar la administración de claves SSH en AWS, Azure y GCP no requiere eliminar el acceso existente ni interrumpir las cargas de trabajo en ejecución. Significa superponer funciones de descubrimiento, políticas y automatización sobre las funcionalidades que cada nube ya ofrece, en una secuencia definida:

1. Inventaría todas las claves, en cada cuenta, proyecto y suscripción. Analice las regiones y cuentas de AWS en busca de pares de claves EC2, las suscripciones de Azure en busca de entradas authorized_keys de máquinas virtuales y los proyectos de GCP en busca de claves de metadatos y enlaces de inicio de sesión del sistema operativo. El descubrimiento manual a esta escala es, en palabras del propio informe IR 7966 del NIST sobre los inventarios de claves SSH en general, "prácticamente imposible", por lo que este paso debe automatizarse desde el principio.
2. Asigna un propietario y una nube a cada llave. Registra quién es responsable de cada clave y a qué nube o nubes otorga acceso. Una clave copiada en las tres plataformas debe marcarse como una única credencial de alto riesgo, y no como tres entradas independientes.
3. Decida, para cada nube, entre las claves nativas y la alternativa basada en IAM. Evalúe AWS Systems Manager Session Manager, el inicio de sesión con Microsoft Entra ID para máquinas virtuales Linux y el inicio de sesión con GCP OS en función de las restricciones operativas de su entorno. Ninguno es obligatorio, pero cada uno elimina una clave privada estática del acceso humano diario donde se implementa.
4. Normalizar la política en las tres nubes. Establezca un estándar de tipo y longitud de clave, una cadencia de rotación por nivel de riesgo y un flujo de trabajo de aprobación de acceso, y luego aplique esa única política mediante el aprovisionamiento en cada nube en lugar de escribir tres políticas separadas y cambiantes.
5. Automatice la rotación y el desaprovisionamiento de forma centralizada. Un evento de baja de usuario debería activar la eliminación de claves en AWS, Azure y GCP como una sola acción, no como tres tickets separados que dependen de que tres personas diferentes recuerden cerrarlos.
6. Integra los registros de uso de las tres nubes en una sola vista. Dirija los eventos relevantes de SSH de CloudTrail, Azure Activity Log y GCP Cloud Audit Log a una plataforma SIEM compartida o a una plataforma dedicada de administración de claves SSH, de modo que una revisión de acceso o una auditoría extraiga datos de una sola fuente en lugar de tres.
7. Pruebe la respuesta a incidentes entre nubes antes de necesitarla. Realice un ejercicio de simulación sobre el escenario "esta clave está comprometida y se reutilizó en dos de nuestras tres nubes" antes de que dicho escenario se produzca en la realidad.

¿Cómo debe reaccionar cuando una clave SSH se ve comprometida en múltiples nubes?

Una clave SSH comprometida que aparece en una nube debe tratarse como un incidente multinube hasta que se demuestre lo contrario, porque la reutilización de claves en AWS, Azure y GCP es lo suficientemente común como para que la misma clave privada sea válida con frecuencia en más de un lugar.

1. Contener en la nube donde se encontró por primera vez. Elimine el par de claves de AWS EC2 y elimine la entrada de las máquinas virtuales de Azure afectadas. authorized_keys Elimine el archivo o revoque el rol de IAM de GCP que respalda el acceso de inicio de sesión del sistema operativo, de inmediato, sin esperar a una investigación completa.
2. Compruebe si se puede reutilizar en las otras dos nubes. Busque en su inventario (creado en el flujo de trabajo anterior) la misma huella digital de clave pública en cualquier lugar de AWS, Azure o GCP. Generar una clave una sola vez y copiarla en tres entornos es uno de los patrones de propagación multinube más comunes y la forma más rápida de que un incidente en una nube se convierta en un incidente en las tres.
3. Extraiga los registros de autenticación de las tres consolas. Reconstruya la cronología de acceso utilizando AWS CloudTrail, el registro de actividad de Azure, los registros de autenticación de máquinas virtuales y los registros de auditoría de GCP Cloud, buscando específicamente sesiones de fuentes inesperadas o en momentos inesperados.
4. Gire las credenciales descendentes a las que podría llegar la clave. Una clave que abrió un servidor bastión en una nube puede ser un paso previo para obtener credenciales, secretos o claves adicionales en otra; trate cualquier elemento accesible desde la sesión comprometida como potencialmente expuesto.
5. Revoca inmediatamente los permisos de IAM en todos los lugares donde se utilizaba el acceso basado en IAM. Cuando el acceso se rige por el inicio de sesión del sistema operativo o el inicio de sesión de Entra ID, cortar la vinculación de IAM o RBAC elimina el acceso instantáneamente sin tener que modificar cada máquina virtual individualmente, lo que resulta más rápido que rotar una clave estática distribuida.
6. Documente un solo registro del incidente, no tres. Consolidar los hallazgos de las tres nubes en un único registro que abarque lo que se rotó, lo que se revisó y qué evidencia respalda la respuesta, alimentando directamente el proceso de evidencia de auditoría descrito anteriormente.

Este es un resumen de la respuesta inmediata en entornos multinube, no un manual completo de respuesta a incidentes. Para obtener información detallada sobre cómo gestionar una clave SSH expuesta, consulte la guía de Encryption Consulting sobre respuesta a incidentes con claves SSH expuestas.

Limitaciones

• Los comportamientos nativos de la nube que se describen aquí reflejan la documentación de AWS, Azure y GCP revisada en 2026; los tres proveedores actualizan periódicamente las funciones de IAM y acceso a máquinas virtuales, por lo que conviene verificar el comportamiento actual comparándolo con la documentación vigente de cada proveedor antes de finalizar un control que dependa de ella.
• El inicio de sesión en GCP OS debe habilitarse explícitamente para cada proyecto o instancia; no es la configuración predeterminada de GCP. Un entorno de GCP que nunca lo active estará tan descentralizado como un entorno de AWS o Azure.
• AWS Systems Manager Session Manager y el inicio de sesión con Microsoft Entra ID para máquinas virtuales Linux eliminan la clave privada local del acceso diario, pero ambos siguen dependiendo de una política de IAM o RBAC con el alcance correcto; un rol de IAM mal configurado simplemente traslada el riesgo de una clave SSH huérfana a una identidad con privilegios excesivos.
• Esta guía abarca AWS, Azure y GCP, los tres proveedores de hiperescaladores que utilizan la mayoría de las infraestructuras multinube empresariales. Los proveedores de nube más pequeños o regionales, así como las infraestructuras locales o híbridas, necesitan la misma metodología de descubrimiento y centralización que se describe aquí, aunque sus herramientas nativas difieran de las de los tres proveedores mencionados.
• Las directrices aquí presentadas son de carácter general. Los entornos regulados (FIPS 140-3, PCI DSS, HIPAA, DORA) 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?

Consideraríamos el acceso SSH multi-nube como un conjunto de credenciales gestionado, no como tres problemas específicos de cada nube atendidos por tres equipos distintos. En nuestros proyectos, el patrón se repite: una organización cuenta con controles razonablemente maduros en una nube, a menudo donde comenzó la atención del equipo de seguridad, y prácticamente ninguna visibilidad en las otras dos, porque ni AWS, ni Azure, ni GCP exigen por sí solos la existencia de visibilidad entre nubes.

Mediante SSH Secure , Encryption Consulting ofrece a las organizaciones un inventario y ciclo de vida centralizados en AWS, Azure, GCP e infraestructura local, en lugar de tres vistas separadas por nube que un equipo de seguridad debe conciliar manualmente. Así es como funciona en la práctica:

1. Mapeo centralizado de visibilidad y propiedad

Mediante la detección con y sin agentes, SSH Secure localiza todas las claves SSH en las instancias de AWS, Azure y GCP, así como en los servidores locales, y las almacena en un único inventario con detalles de propiedad y uso, eliminando las hojas de cálculo fragmentadas por nube con las que suelen empezar la mayoría de los equipos.

2. Control de acceso seguro y aplicación de claves vinculadas a la sesión.

El control de acceso granular basado en roles garantiza que los usuarios reciban el acceso mínimo necesario, aplicado de forma idéntica independientemente de si el sistema de destino se encuentra en AWS, Azure o GCP. Para operaciones confidenciales o temporales, SSH Secure emite claves efímeras vinculadas a la sesión que caducan automáticamente, lo que limita el alcance de las vulnerabilidades sin importar en qué nube se encuentre la sesión.

3. Orquestación automatizada del ciclo de vida de las claves en la nube.

SSH Secure automatiza la generación, la rotación basada en políticas, la expiración programada y la revocación como un único flujo de trabajo que llega a AWS, Azure y GCP simultáneamente, de modo que un evento de baja elimina el acceso de las tres nubes en una sola acción en lugar de tres pasos manuales separados.

4. Protección integrada de HSM

Las claves privadas se almacenan de forma segura en los módulos de seguridad de hardware (HSM) , lo que garantiza su inexportabilidad y resistencia a la manipulación, independientemente de la nube a la que autorice el acceso. Las claves se generan mediante algoritmos robustos como RSA -4096, ECDSA y Ed25519, y permanecen aisladas de la memoria del sistema operativo incluso si un host en cualquiera de las tres nubes se ve comprometido.

5. Control basado en políticas para operaciones clave

Todas las operaciones clave, como la generación, los flujos de trabajo de aprobación, la rotación y la revocación, se rigen por controles basados ​​en políticas que se aplican de forma idéntica independientemente de la nube a la que acceda una solicitud, sustituyendo las tres políticas separadas y cambiantes que se generan de forma orgánica cuando cada equipo de la nube redacta sus propias reglas.

6. Seguimiento continuo, auditoría y preparación para el cumplimiento normativo.

SSH Secure proporciona monitorización en tiempo real con registro detallado de eventos, integrado con los paneles de Splunk o Loki-Grafana, de modo que la actividad de AWS, Azure y GCP fluye hacia un único registro de auditoría en lugar de tres registros de consola desconectados. Las alertas centralizadas basadas en políticas permiten una detección de anomalías y una respuesta a incidentes más rápidas en todo el entorno multinube.

Conclusión

AWS, Azure y GCP resuelven el acceso a claves SSH para sus propias instancias, pero ninguna lo hace para toda la organización. Esta brecha, y no la debilidad de una nube en particular, es lo que convierte el acceso SSH multi-nube en inventarios fragmentados, rotación inconsistente y evidencia de auditoría que debe recopilarse desde tres consolas bajo la presión de los plazos. Al tratar las claves SSH como un conjunto de credenciales gobernadas, con la propiedad asignada al momento de la emisión, activadores de rotación que consideran la mecánica real de cada nube, políticas aplicadas de manera consistente a través de los tres modelos IAM y evidencia de auditoría recopilada continuamente en lugar de reconstruida, el acceso SSH multi-nube pasa de ser un riesgo oculto y fragmentado a una parte controlada y auditable del programa de seguridad, independientemente de la nube a la que acceda una clave determinada.

Lecturas relacionadas de Consultoría en Cifrado

Recursos adicionales sobre la disciplina del ciclo de vida de las claves SSH, la criptografía en la nube y el trabajo de migración mencionado anteriormente:

• Gestión integral del ciclo de vida de las claves SSH para la seguridad empresarialLa guía principal de Encryption Consulting sobre propiedad, rotación, política de acceso y evidencia de auditoría de claves SSH en cualquier entorno.
• Vulnerabilidades de SSH y cómo protegerse contra ellas Cubre las vulnerabilidades CVE a nivel de protocolo y de implementación que afectan a SSH independientemente de la nube en la que se ejecute.
• Respuesta a incidentes por claves SSH expuestas Este es el manual completo que respalda los pasos resumidos en la sección de respuesta a incidentes de esta guía.
• Propiedad de la clave SSH Profundiza en la asignación y aplicación de modelos de propiedad para credenciales privilegiadas.
• PQC para entornos en la nube: Responsabilidad compartida entre AWS, Azure y Google Cloud. Cubre el mismo modelo de comparación de tres nubes que se aplica a la responsabilidad de la migración post-cuántica.
• CBOM seguro Amplía la detección criptográfica más allá de las claves SSH, abarcando certificados y algoritmos en todos los entornos, tanto en la nube como en las instalaciones locales.

Preguntas frecuentes

¿AWS, Azure o GCP rotan automáticamente las claves SSH? No. Ninguna de las tres principales plataformas en la nube rota las claves SSH automáticamente por defecto. Los pares de claves de AWS EC2 y las entradas authorized_keys de las máquinas virtuales de Azure permanecen válidos indefinidamente hasta que alguien las reemplace o elimine manualmente. Las claves de metadatos de GCP se comportan de la misma manera; el inicio de sesión del sistema operativo de GCP solo modifica esto para el acceso gobernado por IAM, donde la revocación del rol de IAM de un usuario funciona como una rotación instantánea, pero no se extiende a las claves basadas en cuentas de servicio o metadatos.

¿Cuál es la diferencia real entre el inicio de sesión del sistema operativo de GCP y cómo AWS y Azure gestionan las claves SSH? El inicio de sesión del sistema operativo vincula el acceso SSH directamente a una identidad de Google IAM, por lo que el acceso se actualiza automáticamente cuando cambian los permisos de IAM y no depende de una clave privada almacenada para las decisiones de autorización. AWS y Azure ofrecen alternativas comparables basadas en IAM, AWS Systems Manager Session Manager y el inicio de sesión con Microsoft Entra ID para máquinas virtuales Linux, pero ambas requieren la instalación de un agente o extensión independiente y son complementos opcionales que se superponen a una configuración predeterminada basada en claves, en lugar de una ruta de autenticación SSH nativa como lo hace el inicio de sesión del sistema operativo de GCP.

¿Puedo reemplazar las claves SSH con acceso basado en IAM en las tres nubes? Puedes migrar al acceso basado en IAM en cada nube individualmente (AWS Session Manager, Azure Entra ID login y GCP OS Login lo admiten), pero ninguno de los tres se integra con los demás. Elegir el acceso basado en IAM en las tres nubes implica tener tres sistemas IAM separados que gestionar de forma coherente, que es precisamente el problema que una capa centralizada de gestión de claves SSH está diseñada para resolver.

¿Cómo puedo obtener un inventario unificado de claves SSH en AWS, Azure y GCP? Necesitas un proceso de descubrimiento o una plataforma dedicada a la gestión de claves SSH que analice los pares de claves EC2 en todas las regiones y cuentas de AWS, las entradas de authorized_keys de las máquinas virtuales en todas las suscripciones de Azure, y los metadatos de proyectos o instancias de GCP, así como las vinculaciones de inicio de sesión del sistema operativo. Luego, normaliza toda esta información en un único registro por clave con un propietario asignado. Ninguna de las tres consolas en la nube generará esta vista de forma nativa, ya que ninguna reconoce la existencia de las otras dos.

¿Habilitar GCP OS Login significa que ya no necesitamos una política de rotación de claves SSH? No. OS Login elimina las claves privadas almacenadas para los inicios de sesión interactivos en GCP Compute Engine, pero las cuentas de servicio, la automatización y cualquier instancia o proyecto que aún utilice claves basadas en metadatos mantienen los mismos requisitos de rotación que AWS y Azure. Además, OS Login solo se aplica a GCP, por lo que sigue siendo necesaria una política de rotación para cualquier modelo de acceso que utilicen AWS y Azure.

Referencias

• Cree un par de claves para su instancia Amazon EC2Amazon Web Services
• Administrador de sesiones de AWS Systems ManagerAmazon Web Services
• Pasos detallados para crear un par de claves SSHMicrosoft Learn, Máquinas virtuales de Azure
• Inicie sesión en una máquina virtual Linux en Azure utilizando Microsoft Entra ID y OpenSSH.Microsoft Learn
• Acerca del inicio de sesión del sistema operativoDocumentación de Google Cloud Compute Engine
• Configurar el inicio de sesión del sistema operativoDocumentación de Google Cloud Compute Engine
• Mejores prácticas para controlar el acceso de inicio de sesión SSHDocumentación de Google Cloud Compute Engine
• NIST IR 7966: Seguridad de la gestión de acceso interactiva y automatizada mediante Secure Shell (SSH), Instituto Nacional de Normas y Tecnología
• Expansión del estado de secretos 2026, GitGuardian
• Informe sobre el estado de la seguridad de la identidad de las máquinas de 2025, CyberArk
• Costo de un informe de violación de datos 2025, IBM