Seguridad de las identidades de máquina: guía práctica para CISO (2026)
En la mayoría de los entornos, las identidades de máquina superan ya con mucho a las humanas, y a menudo no tienen responsable, tienen demasiados privilegios, son de larga duración y no se rotan. Esa combinación es la razón por la que las identidades no humanas (NHI) se han convertido en una vía principal de entrada en las brechas. Esta guía es un programa de controles práctico que un CISO puede impulsar de verdad, no un argumento de venta.
Qué abarca la «identidad de máquina»
Una identidad de máquina es cualquier credencial que usa el software para autenticarse en lugar de una persona: cuentas de servicio, claves de API, credenciales de cliente y tokens OAuth, certificados TLS/SSL y de cliente, claves SSH e identidades de carga de trabajo en la nube. Cada una es un principal autenticable que puede llegar a sistemas y datos, así que cada una es una superficie de ataque. «Identidad no humana» (NHI) es la misma idea con un nombre más reciente.
Por qué cuesta más gobernarlas que las identidades humanas
- Sin responsable. Las cuentas de servicio y las claves se crean para una tarea y luego se olvidan; nadie se da cuenta de un uso indebido.
- Sin ciclo de vida natural. No hay alta ni baja de empleado, así que las credenciales persisten indefinidamente.
- Los controles humanos no se aplican. El software no puede hacer MFA ni iniciar sesión de forma interactiva, así que esas protecciones no existen.
- Los secretos se filtran al código. Las claves acaban escritas en el código de los repositorios, en los logs de la CI y en las imágenes de contenedor.
- Se mueven deprisa. Las cargas de trabajo efímeras aparecen y desaparecen constantemente, así que las revisiones de IAM con cadencia fija no encajan.
Un programa de controles práctico
- Inventario y responsables. Descubre todas las identidades de máquina en la nube, el SaaS, la CI/CD, el código y la infraestructura, y asigna un responsable a cada una. Es la base: cuenta con encontrar cuentas huérfanas y claves olvidadas.
- Mínimo privilegio. Limita cada identidad exactamente a lo que necesita. Las cuentas de servicio y las relaciones de confianza con demasiados permisos convierten una sola filtración en un acceso amplio: revísalas con un analizador de políticas IAM → y una auditoría de políticas de confianza.
- Credenciales de corta duración. Sustituye las claves estáticas y de larga duración por otras de corta duración emitidas de forma dinámica (federación de identidades de carga de trabajo, un servicio emisor, secretos dinámicos). Es el control con más palanca: un token robado caduca antes de que sea útil.
- Gestión de secretos. Centraliza el almacenamiento, el acceso, la auditoría y la rotación para que las aplicaciones obtengan los secretos en tiempo de ejecución en lugar de llevarlos encima. Encuentra los que ya se han filtrado con un escáner de secretos y programa la rotación con el planificador de rotación de claves →.
- Ciclo de vida de los certificados. Trata los certificados TLS y de cliente como identidades: descubre, emite, renueva y revoca, y automatízalo, porque los periodos de validez no dejan de acortarse y la renovación manual es una causa conocida de caídas.
- Monitorización y revocación. Establece una línea base del comportamiento normal de las máquinas, alerta ante usos anómalos (origen nuevo, alcance nuevo, fuera de horario) y mantén una vía de revocación rápida para poder anular una credencial filtrada en minutos.
Cómo se conecta con el resto de tu programa
La identidad de máquina es gobierno de identidades, no un asunto secundario. El mismo razonamiento de acceso condicional que aplicas a las personas tiene un equivalente para las máquinas (explóralo en el laboratorio de acceso condicional y MFA), y los controles anteriores encajan en un conjunto de controles más amplio que puedes consultar por marco en la biblioteca de controles. Si estás montando la detección del uso anómalo de credenciales de máquina, la evaluación de madurez del SOC muestra dónde encaja esa monitorización en tu hoja de ruta.
Preguntas frecuentes
¿La identidad de máquina en una línea? Las credenciales que usa el software para autenticarse (cuentas de servicio, claves, tokens, certificados, identidades de carga de trabajo), que ya superan en número a las cuentas humanas y son una vía principal de brechas.
¿Primer paso? Inventariar todas las identidades de máquina y dar un responsable a cada una.
¿El control con más palanca? Credenciales de corta duración emitidas de forma dinámica en lugar de claves estáticas de larga duración.
¿Sigo necesitando un gestor de secretos? Sí, pero una bóveda llena de secretos de larga duración, con demasiados permisos y sin responsable sigue teniendo el problema de fondo; combínalo con el mínimo privilegio y la rotación.
Preguntas frecuentes
¿Qué es una identidad de máquina?
Una identidad de máquina es cualquier credencial que usa el software, y no una persona, para autenticarse y obtener autorización: cuentas de servicio, claves de API, credenciales de cliente y tokens OAuth, certificados TLS/SSL y de cliente, claves SSH e identidades de carga de trabajo en la nube (como un rol de instancia o una federación de cargas de trabajo). También se llaman identidades no humanas (NHI). Cada una es un principal autenticable que puede acceder a sistemas y datos, así que cada una es una superficie de ataque.
¿En qué se diferencia la identidad de máquina de la identidad humana?
Las identidades humanas tienen una persona detrás, un responsable, un ciclo de vida de alta y baja y controles como la MFA y el inicio de sesión interactivo que suponen la presencia de una persona. Las identidades de máquina a menudo no tienen nada de eso: ningún responsable claro, ninguna caducidad natural, ninguna MFA (el software no puede responder a una notificación push), credenciales incrustadas en el código o la configuración y privilegios que se concedieron una vez y nunca se revisaron. Además cambian mucho más rápido (las cargas de trabajo efímeras se crean y se destruyen constantemente), así que los procesos de IAM estáticos y pensados para personas no encajan con ellas.
¿Por qué son un riesgo de seguridad las identidades no humanas (NHI)?
Se suman tres razones. Primera, la escala: las NHI suelen superar muchas veces en número a las cuentas humanas, así que la superficie de ataque es grande y está mal cartografiada. Segunda, el privilegio permanente: las credenciales de máquina suelen tener demasiados permisos y una larga duración, así que una sola clave filtrada puede dar un acceso amplio y persistente. Tercera, la mala higiene: los secretos se escriben en el código de los repositorios, en los logs de la CI y en las imágenes, rara vez se rotan y no tienen un responsable que detecte el uso indebido. Una credencial filtrada, de alcance amplio y nunca rotada está cerca del peor caso, y es algo habitual.
¿Cuál es el primer paso para proteger las identidades de máquina?
El inventario y los responsables. No puedes gobernar lo que no ves, así que el primer paso es descubrir todas las identidades de máquina en la nube, el SaaS, la CI/CD, el código y la infraestructura, y asignar a cada una una persona o un equipo responsable. El descubrimiento casi siempre revela cuentas de servicio huérfanas, claves olvidadas y roles demasiado amplios. Tener responsables es lo que hace que todos los controles posteriores (revisión, rotación, revocación) ocurran de verdad.
¿Cómo ayudan las credenciales de corta duración?
Una credencial que caduca en minutos u horas limita mucho el valor de una filtración: un token robado deja de servir poco después de emitirse, y no hay nada de larga duración que exfiltrar. Pasar de claves estáticas de larga duración a credenciales de corta duración emitidas de forma dinámica (mediante la federación de identidades de carga de trabajo, un servicio emisor o un gestor de secretos con secretos dinámicos) es el control con más palanca para la identidad de máquina, porque ataca directamente el problema de la «credencial permanente de larga duración».
¿Dónde encajan los gestores de secretos?
Un gestor de secretos centraliza el almacenamiento, el control de acceso, la auditoría y la rotación de las credenciales para que no estén repartidas por el código, la configuración y las canalizaciones. El objetivo es que las aplicaciones obtengan los secretos en tiempo de ejecución desde un almacén gobernado (idealmente, secretos de corta duración emitidos bajo demanda) en lugar de llevar secretos estáticos. También te da un registro de auditoría y un único lugar desde el que revocar. Es necesario pero no suficiente: un gestor de secretos lleno de secretos de larga duración, con demasiados permisos y sin responsable sigue teniendo el problema de fondo.
¿Qué relación tiene el ciclo de vida de los certificados con la identidad de máquina?
Los certificados TLS y de cliente son identidades de máquina, y un certificado caducado o mal emitido provoca las mismas caídas y fallos de confianza que cualquier problema de identidad, además del riesgo de siempre de que un certificado desconocido y sin gestionar caduque en producción. La gestión del ciclo de vida de los certificados (descubrimiento, emisión, renovación y revocación, y la automatización de las cuatro) es una parte central de un programa de identidad de máquina, sobre todo porque los periodos de validez de los certificados siguen acortándose y la renovación manual deja de ser viable.