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!

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!

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.

7 riesgos típicos (con ejemplos reales de operación)

• config.yml con password de BD • .env subido por error • claves en scripts de despliegue • tokens en logs de CI/CD

• Un token filtrado hoy sirve semanas/meses

• 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

• La key sigue viva aunque el proveedor ya no existe o el proyecto murió

• Mismo secreto para dev, qa y prod • Acceso de pipelines de dev hacia prod

• No hay logs centralizados o no se correlaciona quién/qué usó el secreto • Sin alertas por comportamiento anómalo

• Integraciones externas con acceso persistente (CRM, marketing, contabilidad, proveedores) • Riesgo de cadena de suministro: si el tercero cae, tu acceso cae

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.

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.

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.

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.

• 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.

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.

• 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.

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

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”

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)

Temas que podrían interesarte:

Suscríbete a Nuestro Blog: Mantente actualizado con las últimas noticias y consejos en ciberseguridad. Suscríbete ahora.