Identidades No Humanas (NHI): el riesgo invisible que ya tiene acceso a tu empresa
Las brechas ya no empiezan con “un usuario cayó en phishing”. Cada vez más incidentes arrancan con algo más silencioso: una identidad no humana (Non-Human Identity, NHI).
Hablamos de API keys, tokens, service accounts, certificados, secretos de apps, identidades de workloads en cloud, cuentas de integración, robots de RPA, pipelines CI/CD, y cualquier “actor” que autentica y recibe permisos sin ser una persona.
El problema es simple: las identidades no humanas crecen más rápido que tu control, y por eso terminan con permisos excesivos, credenciales eternas y poca visibilidad. Resultado: un atacante no necesita comprometer a “Juan de Contabilidad”; le basta con robar un token o key con acceso privilegiado.
En Ti Rescue, ofrecemos servicios especializados para proteger a las organizaciones contra amenazas. Contáctanos para fortalecer la seguridad de tus datos y prevenir ataques dirigidos.
🚀 ¡Contáctanos ahora!
¿Qué son las identidades no humanas (NHI)?
Una identidad no humana es cualquier identidad digital usada por software/servicios para autenticarse y operar en sistemas, nubes, aplicaciones o APIs. Ejemplos comunes:
- API keys (integraciones con terceros, apps internas, móviles)
- Tokens OAuth / JWT (sesiones de apps, integraciones, microservicios)
- Service accounts (Google Workspace, Azure AD/Entra ID, AWS IAM roles, Kubernetes service accounts)
- Certificados TLS / mTLS (comunicación servicio-a-servicio)
- Secrets (passwords de BD embebidos en apps, variables de entorno, vaults mal gobernados)
- Cuentas técnicas para backups, monitoreo, automatización, ETL, RPA
- Identidades de workloads (pods, contenedores, funciones serverless)
La clave: no es “una cuenta”. Es un mecanismo de acceso con permisos y alcance real sobre datos y sistemas críticos.
En Ti Rescue, ofrecemos servicios especializados para proteger a las organizaciones contra amenazas. Contáctanos para fortalecer la seguridad de tus datos y prevenir ataques dirigidos.
🚀 ¡Contáctanos ahora!
¿Por qué las identidades no humanas son el “usuario más peligroso”?
Porque combinan 4 factores que a un atacante le encantan:
- Permanencia
Muchas credenciales NHI no expiran: keys “para siempre”, certificados sin rotación, secretos olvidados.
- Exceso de privilegios
Para que “funcione rápido”, se les da acceso tipo admin o permisos amplios (ej. *:* en cloud, roles globales, acceso total a buckets/DB).
- Baja visibilidad
No tienen dueño claro. No hay “quién responde” por esa identidad cuando algo cambia o se filtra.
- Difícil detección
Un token robado se ve “normal”: tráfico válido, autenticado, desde integraciones reales.
La superficie real de acceso es: personas + máquinas. Y muchas empresas solo gobiernan a las personas.
¿Qué riesgos traen las NHI y cómo se atacan?
7 riesgos típicos (con ejemplos reales de operación)
- Secretos expuestos en repositorios
- config.yml con password de BD
- .env subido por error
- claves en scripts de despliegue
- tokens en logs de CI/CD
- Tokens sin expiración o con TTL demasiado largo
- Un token filtrado hoy sirve semanas/meses
- Permisos excesivos por “comodidad”
- Una integración de facturación con permisos de lectura/escritura sobre todo el ERP
- Un servicio con acceso completo a storage + base de datos + IAM
- Rotación inexistente
- La key sigue viva aunque el proveedor ya no existe o el proyecto murió
- Falta de segmentación entre entornos
- Mismo secreto para dev, qa y prod
- Acceso de pipelines de dev hacia prod
- Falta de trazabilidad
- No hay logs centralizados o no se correlaciona quién/qué usó el secreto
- Sin alertas por comportamiento anómalo
- Dependencia de terceros
- Integraciones externas con acceso persistente (CRM, marketing, contabilidad, proveedores)
- Riesgo de cadena de suministro: si el tercero cae, tu acceso cae
¿Cómo saber cuántas identidades no humanas tengo?
Aquí es donde la mayoría se sorprende: nadie sabe el número real.
Para descubrirlo, necesitas un inventario técnico. Checklist de “descubrimiento”:
Inventario mínimo (en 1–2 semanas, bien ejecutado)
- Cloud IAM: roles, service accounts, access keys, IAM roles, policies
- CI/CD: GitHub Actions/GitLab/Jenkins (secrets, tokens, runners)
- Kubernetes: service accounts, roles/rolebindings, tokens, secrets
- Aplicaciones: vault/secret managers, variables de entorno, archivos de config
- Terceros: integraciones OAuth, API keys, cuentas técnicas con permisos
- Certificados: expiración, CA, quién emite, dónde se usa, rotación
Señal de alerta: si no puedes responder “qué servicio usa esta key y quién la aprobó”, esa identidad ya es un riesgo.
Buenas prácticas para gestionar NHI (lo que sí funciona)
1) Asigna propietario y propósito (sí o sí)
Cada NHI debe tener:
- Owner (área/persona responsable)
- Sistema origen y sistema destino
- Propósito (qué habilita)
- Caducidad / revisión (fecha)
- Impacto (qué pasa si se cae)
Si una NHI no tiene owner ni propósito, es candidata a revocación.
2) Reduce privilegios (least privilege) con permisos “por tarea”
Regla práctica: una identidad = una función.
Evita identidades “multiuso”.
- Una NHI que solo lee datos no debería escribir
- Una NHI que opera en un bucket no debería administrar IAM
- Una NHI de monitoreo no debería tocar bases de datos
Esto corta el “blast radius” cuando se filtra una credencial.
3) Adopta credenciales de vida corta (short-lived) y rotación automatizada
Objetivo moderno:
- tokens temporales
- rotación automática (cada X días/horas)
- revocación inmediata cuando cambia el contexto (fin del proyecto, baja de proveedor)
Esto convierte un robo de secreto en un incidente de minutos, no de meses.
4) Centraliza secretos en un Secret Manager (y elimina “secrets en texto plano”)
- Nada en repositorios
- Nada en archivos locales sin control
- Nada en correos / chats
- Nada embebido en código
Ideal: vault + políticas + auditoría + rotación.
5) Observabilidad y detección: logs + alertas por anomalías
Lo mínimo que debes monitorear:
- Uso de tokens fuera de horario
- Uso desde regiones/ASNs inusuales
- Incremento súbito de llamadas API
- Acceso a recursos “raros” para esa identidad
- Cambios de permisos o nuevas credenciales creadas
Aquí se conecta con SOC/monitoreo: si no lo ves, no lo controlas.
6) Segmenta entornos y aplica Zero Trust “service-to-service”
- Separar dev/qa/prod
- mTLS o identidad de workload
- políticas por contexto (origen, red, postura, dispositivo/host)
- acceso condicionado y verificable
Zero Trust no es solo para usuarios humanos.
¿Cómo auditar identidades no humanas? (método práctico)
Una auditoría NHI efectiva no es “un reporte bonito”. Es un proceso que termina con reducción real de riesgo. En TI Rescue, normalmente lo estructuramos así:
Fase 1 — Descubrimiento y mapeo
- Inventario de NHIs en cloud, CI/CD, apps, Kubernetes y terceros
- Mapa de flujos: quién habla con quién y con qué permisos
Fase 2 — Evaluación de riesgo
- Identidades sin owner / sin caducidad
- Permisos excesivos
- Secretos no rotados
- Credenciales expuestas (repos/logs/configs)
- Integraciones de terceros con acceso persistente
Fase 3 — Remediación priorizada
- Revocar lo inútil
- Reducir permisos
- Migrar a short-lived
- Centralizar secretos
- Activar monitoreo y alertas
Fase 4 — Control continuo
- Políticas + revisiones mensuales
- Automatización: rotación, expiración, detección de secretos filtrados
- Indicadores (KPIs) y cumplimiento interno
Señales de que tu empresa ya tiene riesgo alto en NHI
Si te suena alguno, hay trabajo urgente:
- “No sabemos cuántas API keys tenemos”
- “Tenemos service accounts con permisos de admin”
- “Usamos el mismo token hace 2 años y funciona”
- “Las integraciones las monta cada equipo a su manera”
- “Los secretos están en .env y en pipelines”“Nadie revisa per
- misos de CI/CD”
- “No hay alertas cuando una identidad accede raro”
Beneficio comercial: ¿qué gana el negocio controlando NHI?
Además de seguridad (obvio), hay beneficios directos:
- Menos incidentes y menos downtime (continuidad operativa)
- Menor riesgo de ransomware / extorsión por acceso persistente
- Cumplimiento y auditorías más simples (trazabilidad, owners, controles)
- Menos dependencia de “héroes” (ya no depende de 1 persona que “sabe dónde está la key”)
- Integraciones más estables (rotación gestionada, menos caídas por expiraciones sorpresa)
¿Qué es una identidad no humana?
Es una identidad digital usada por software o servicios (no personas) para autenticarse y acceder a sistemas: tokens, keys, service accounts, certificados, secretos, etc.
¿Por qué las identidades no humanas son un riesgo?
Porque suelen tener permisos altos, poca visibilidad, rotación débil y larga vida. Cuando se filtran, el acceso parece legítimo y es difícil de detectar.
¿Dónde se encuentran más?
Cloud (IAM), CI/CD, Kubernetes, integraciones con terceros, microservicios, aplicaciones internas, automatizaciones y RPA.
¿Cómo empiezo a controlar las identidades no humanas?
Primero inventario + owner + propósito. Luego reducción de privilegios, rotación, secretos centralizados y monitoreo.
¿Un WAF soluciona esto?
No. Un WAF ayuda a proteger apps web, pero no gobierna identidades, permisos, rotación ni uso anómalo de secretos.
Suscríbete a Nuestro Blog: Mantente actualizado con las últimas noticias y consejos en ciberseguridad. Suscríbete ahora.
