Identity Visibility 2026: la base que falta en seguridad Linux y multicloud

septiembre 22, 2026 Alfonso Moreno | Sysadmin Senior 35 Visitas 10 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 2-3 horas para el switch a enforcing.
Requisitos: Root, kernel moderno, 2-4 semanas en permissive antes de enforcing.
Resultado: Sistema con MAC activo, logs en /var/log/audit/audit.log.
Troubleshooting: audit2allow, audit2why, setenforce 0 para emergencias.

Por qué importa la visibilidad de identidades en 2026

El Verizon DBIR 2026 dejó una cifra que cambia la conversación sobre seguridad: el 39% de los breaches analizados involucraron abuso de credenciales en algún punto de la cadena de ataque, no solo como vector inicial. Y el 50% de las víctimas de ransomware tuvieron un evento de credencial robada o infostealer en los 95 días previos al despliegue del ransomware. El otro dato relevante: el 31% de los breaches ahora empiezan por vulnerabilidades de software, pero las credenciales siguen siendo el tejido conectivo de toda la cadena.

Para un sysadmin Linux, esto se traduce en una pregunta incómoda: ¿cuántas identidades existen hoy en tu infraestructura que tu IAM no está rastreando? Porque la respuesta típica, según el reporte del Permiso State of Identity Security 2026, es preocupante: la cobertura comprehensiva de identidad cayó 47 puntos en el último año. Y Gartner acaba de crear en su Hype Cycle for Digital Identity 2026 una categoría completamente nueva, IVIP (Identity Visibility and Intelligence Platform), solo para cubrir este hueco.

La visibilidad de identidades dejó de ser un nice-to-have: es el prerrequisito de cualquier control de identidad serio.

Qué es exactamente “identity visibility”

Identity visibility es la capacidad de ver cada identidad en un entorno, qué puede acceder, y cómo se usa realmente ese acceso en tiempo de ejecución. Combina tres elementos:

Inventario: lista exhaustiva de identidades humanas, de servicio, de máquina, API keys, workloads efímeros y agentes AI
Mapeo de entitlements: qué permisos tiene cada identidad, contra qué recursos
Telemetría comportamental: cómo se usa el acceso en la práctica, no solo qué dice la política

La diferencia con un IAM clásico es que el IAM tradicional opera con snapshots periódicos. La visibilidad de identidades pide una imagen continua, no un reporte trimestral. Porque entre snapshot y snapshot pasan los 95 días en los que se cuece el ransomware.

El caso Linux: por qué esto pega distinto

En un homelab o servidor Linux tradicional, la respuesta fácil sería “tengo un usuario root, un usuario deploy, y los usuarios del sistema”. Pero ese inventario rara vez sobrevive al contacto con la realidad operativa. Veamos qué aparece cuando uno mira:

# Identidades humanas en el server
cat /etc/passwd | awk -F: '$3 >= 1000 && $7 != "/usr/sbin/nologin" {print $1}'
# Identidades de servicio activas (systemd)
systemctl list-unit-files --type=service --state=enabled | awk '{print $1}'
# Claves SSH autorizadas (human + service accounts)
find / -name "authorized_keys" -type f 2>/dev/null
# Tokens persistentes en /etc y configs de app
find /etc /opt /usr/local/etc -name "*.env" -o -name "*.conf" 2>/dev/null | 
  xargs grep -lE "TOKEN|KEY|SECRET|PASSWORD" 2>/dev/null

La salida real suele revelar sorpresas: cuentas de técnicos que rotaron hace un año pero nunca se borraron, deploy keys para repos que ya no existen, tokens de servicios cloud (AWS IAM roles, GitHub Actions runners, secretos en Vault) que viven en configs olvidadas. Cada uno de esos es una identidad que tu IAM no rastrea, y por tanto no puede revocar cuando deja de ser legítima.

Lo que muestra el DBIR 2026 es que los atacantes están automatizando el descubrimiento de estas identidades “huérfanas” con la misma velocidad con la que el shadow IT las crea. Si tu inventario tiene un delay de semanas, el atacante ya movió lateralmente antes de que te enteres.

Las tres capas que necesitas ver

Para construir visibilidad práctica en un entorno Linux + multicloud, hay tres capas que tienen que estar iluminadas:

Capa 1: Identidades humanas (incluyendo shadow accounts)

El 67% de usuarios corporativos accede a servicios AI desde cuentas no corporativas en dispositivos corporativos, según el análisis de AuthMind sobre el DBIR 2026. Esas cuentas son invisibles para tu IAM: no pasan por SSO, no se loguean en tu directorio, no aparecen en tu access review.

El patrón técnico es claro: descubrimiento continuo por telemetría de browser, DNS, logs de autenticación, comparación con el directorio federado aprobado. Lo que existe en la práctica pero no en tu governance es exactamente donde vive el riesgo.

Capa 2: Non-human identities (NHI)

Aquí es donde el inventario tradicional de Linux más falla. Identidades no humanas son: service accounts, API keys, certificados, tokens de CI/CD, secrets en Vault o .env, IAM roles de cloud, service accounts de Kubernetes, máquinas SSH con clave. El Permiso 2026 mostró que las organizaciones pierden control de estas identidades a un ritmo acelerado porque proliferan sin un ciclo de vida explícito.

# API keys y tokens en variables de entorno (incluyendo procesos en runtime)
sudo cat /proc/*/environ 2>/dev/null | tr '' 'n' | 
  grep -E "^(AWS|API|TOKEN|GITHUB|KUBE|VAULT|SECRET)_" | sort -u
# Service accounts de Kubernetes sin dueño claro
kubectl get serviceaccounts --all-namespaces -o json | 
  jq -r '.items[] | select(.metadata.annotations."kubernetes.io/created-by" == null) | .metadata.name'
# IAM roles no usados en los últimos 90 días (AWS)
aws iam generate-credential-report --output text --query 'Content' | base64 -d | 
  awk -F, '$5 != "N/A" && $5 < "2026-06-22" {print $1}'

Lo que está en juego no es solo "saber qué existe", pero el tiempo entre exposición y acción. Una credencial expuesta que permanece activa 60 días no es un problema de discovery: es un fallo de control.

Capa 3: Identidades AI / agentic

La categoría más nueva y más explosiva. Agentes AI, MCP servers, automatizaciones que se autentican a recursos para "actuar en nombre del usuario". Cada uno crea una identidad nueva que, en arquitecturas típicas, vive fuera de los procesos de offboarding.

El bug común es tratar el shadow AI como problema de DLP: bloquear contenido. Pero si la cuenta que accede al recurso no está en tu IAM, ningún control de contenido va a cerrar la exposición. Primero la identidad, después el contenido.

Implementación práctica en 2026

Un programa mínimo viable de visibilidad de identidades en Linux + multicloud, ordenado por prioridad operativa:

Paso 1: Inventario automatizado cross-system

Cron semanal que consolide identidades humanas + service accounts + secrets + IAM roles en un único reporte. La clave es que sea ejecutable, no aspiracional:

#!/bin/bash
# identity_inventory.sh — corre como root cada lunes 03:00
REPORT=/var/log/identity-inventory/$(date +%Y%m%d).json
{
  echo "{"scan_date": "$(date -Iseconds)","
  echo ""human_users": $(getent passwd | awk -F: '$3 >= 1000' | jq -R . | jq -s .),"
  echo ""ssh_keys": $(find /home /root -name authorized_keys 2>/dev/null | jq -R . | jq -s .),"
  echo ""systemd_services": $(systemctl list-unit-files --type=service --state=enabled --no-legend | awk '{print $1}' | jq -R . | jq -s .),"
  echo ""env_secrets": $(sudo cat /proc/*/environ 2>/dev/null | tr '' 'n' | grep -E '_KEY|_TOKEN|_SECRET' | sort -u | jq -R . | jq -s .),"
  echo ""kube_sa": $(kubectl get sa --all-namespaces -o json 2>/dev/null | jq '[.items[] | {ns: .metadata.namespace, name: .metadata.name}]')"
  echo "}"
} > "$REPORT"
# Diff contra el inventario anterior
if [ -f /var/log/identity-inventory/last.json ]; then
  diff <(jq -S . /var/log/identity-inventory/last.json) 
       <(jq -S . "$REPORT") > /var/log/identity-inventory/delta_$(date +%Y%m%d).diff
fi
cp "$REPORT" /var/log/identity-inventory/last.json

El reporte en sí mismo no protege nada, pero el delta semanal es donde aparecen las identidades nuevas que nadie provisionó formalmente. Esas son las candidatas a revisión.

Paso 2: Correlación con access logs

Inventario sin uso real es inventario a medias. Hay que cruzar con access logs: SSH auth log, journald, cloud trail, kube audit. La pregunta no es solo "qué identidades existen", sino "cuáles se usan, desde dónde, y con qué frecuencia".

# Top 20 usuarios SSH por actividad últimos 30 días
journalctl -u ssh --since "30 days ago" --no-pager | 
  grep "Accepted publickey" | awk '{print $9}' | sort | uniq -c | sort -rn | head -20
# Service accounts que no se loguean en 60 días (candidatos a revisión)
lastlog -t 60 | awk 'NR>1 && $2 != "**Never" {print $1}'

Una cuenta de servicio que no se loguea en 60 días tiene tres posibilidades: está muerta y hay que borrarla, está mal configurada y no loguea donde debería, o está siendo usada sin que quede traza. Las tres son accionables: en el primer caso borrar, en el segundo arreglar logging, en el tercero investigar.

Paso 3: Lifecycle atado a ownership

Aquí está el cambio cultural importante. La pregunta "¿quién es el dueño de esta identidad?" tiene que tener respuesta escrita, versionada, y revisable. Si una API key de un vendor lleva 8 meses activa sin review, no es solo un gap técnico: es un accountability gap. El patrón correcto:

Cada identidad tiene un owner documentado en tu sistema de tickets o IAM
Cada identidad tiene una fecha de expiración explícita, no "indefinida"
Revisión trimestral obligatoria, owner debe confirmar legitimidad
Auto-revocación cuando expira, sin intervención manual

Lo que NO hacer

Tres patrones que aparecen una y otra vez y que no resuelven el problema:

1. Comprar un IAM "moderno" y pensar que el inventario está resuelto. Un IAM moderno te da una capa de governance, pero si los procesos de provisioning no alimentan ese IAM (típico en shadow AI, service accounts que se crean por scripts, deploy keys que se generan localmente), el inventario del IAM sigue incompleto. El IAM es un destino de datos, no la fuente.

2. Tratar shadow AI como problema de DLP. Si bloqueas contenido pero la identidad que accede sigue activa y sin review, el problema vuelve la próxima semana con otro prompt. La cuenta AI personal en dispositivo corporativo es un problema de identidad primero.

3. Asumir que "Linux server" significa pocas identidades. Cada systemd unit con un EnvironmentFile, cada proceso de CI/CD que se autentica a GitHub, cada kube service account, cada IAM role attachado a una instancia EC2 — son identidades. El inventario de un server moderno en producción tiene cientos, no decenas. Si tu inventario tiene menos, falta algo.

Conclusión

La visibilidad de identidades en 2026 dejó de ser un proyecto nice-to-have para convertirse en la base de cualquier control serio. Las cifras del DBIR 2026 son contundentes: 39% de breaches con credenciales, 50% de ransomware con infostealer previo en 95 días, 31% empezando por vulnerabilidades de software. Los attackers automatizan el descubrimiento de identidades huérfanas; los defenders necesitamos hacer lo mismo pero con la lista buena.

El programa mínimo viable empieza con tres cosas concretas: inventario automatizado semanal con delta visible, correlación con access logs, y lifecycle atado a fecha de expiración y ownership documentado. No requiere un producto nuevo, requiere los procesos correctos alrededor de las herramientas que ya tienes.

Preguntas frecuentes

¿Por qué Identity Visibility 2026: la base que falta en seguridad Linux y multicloud es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Identity Visibility 2026: la base?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Identity Visibility 2026: la base?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Identity Visibility 2026: la base y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Identity Visibility 2026: la base?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.