Seguridad de cuentas de servicio: identidades no humanas

La seguridad de las cuentas de servicio es la práctica de controlar, monitorizar y rotar las credenciales que usan las identidades no humanas: software, scripts y procesos automatizados que se autentican sin que haya una persona presente. Protegerlas se reduce a cuatro movimientos: inventariar cada cuenta de servicio, limitar cada una al mínimo privilegio, rotar o guardar en un almacén sus credenciales y monitorizar su uso real para detectar desviaciones. Esto importa más cada año porque, según los análisis del sector, las identidades no humanas superan ya en número a las humanas en la mayoría de los entornos en la nube y suelen tener un privilegio permanente más amplio, con peor rotación y monitorización que las cuentas humanas: es decir, tu mayor superficie de ataque de identidad es probablemente la que menos vigilas.

¿Qué es una cuenta de servicio en ciberseguridad?

Una cuenta de servicio es una identidad no humana que usa una aplicación, un servicio o un proceso automatizado para autenticarse y acceder a recursos, nunca una persona que inicia sesión de forma interactiva. Ejemplos habituales:

• Identidades de cargas de trabajo en la nube: un rol de AWS IAM que asume una función Lambda, o una cuenta de servicio de Google Cloud (del tipo que creas para una integración con la API de Gmail/Workspace) que lee buzones o envía correo de forma programática.
• Claves y tokens de API: una clave estática que usa un pipeline de CI/CD para subir imágenes a un registro de contenedores.
• Cuentas entre aplicaciones: un usuario de base de datos que usa una aplicación para cada consulta, o un agente de monitorización que recoge métricas de toda tu flota.
• Agentes de IA: la categoría más reciente, a menudo aprovisionada con amplio acceso de lectura a almacenes de datos y pocas salvaguardas.

El riesgo que las define: las cuentas de servicio suelen tener privilegio permanente (acceso siempre activo, no justo a tiempo) y no tienen MFA, porque no hay ningún humano para aprobar una solicitud. Esa combinación es exactamente lo que quieren los atacantes.

Cómo saber si una cuenta es una cuenta de servicio

A menudo heredas entornos en los que las cuentas humanas y no humanas están mezcladas. Señales de que una cuenta es de servicio:

• Sin inicios de sesión interactivos: la autenticación se produce solo mediante API, token o clave, nunca a través de un flujo de SSO en el navegador.
• Convenciones de nombres: prefijos como svc-, sa-, app-, o sufijos como @project.iam.gserviceaccount.com en Google Cloud.
• Sin MFA registrada y sin responsable humano en tu directorio.
• Comportamiento de máquina: peticiones idénticas a intervalos fijos, acceso desde rangos de IP de servidores, actividad 24/7 sin bajada en fines de semana ni festivos.
• La contraseña o la clave nunca caduca, o no se ha rotado en años.

En Active Directory, filtra las cuentas que tienen un Service Principal Name (SPN) o el indicador DONT_EXPIRE_PASSWORD. En la nube, enumera los roles IAM y las cuentas de servicio directamente desde la API del proveedor: no te fíes solo de tu vista del SSO.

Cómo saber dónde se está usando una cuenta de servicio

Es el paso más difícil y el que más se omite, y la razón por la que sobreviven tantas cuentas obsoletas y con privilegios excesivos. No puedes rotar ni retirar con seguridad lo que no puedes rastrear. Métodos prácticos:

• Lee los registros, no la configuración. Consulta CloudTrail, los registros de inicio de sesión de Azure o los registros de auditoría de Workspace para cada evento en el que la cuenta fue la que actuó. Mira las IP de origen, las llamadas a la API y los recursos tocados en una ventana de 90 días.
• Mapea las marcas de último uso. AWS muestra el «último uso» por clave de acceso y por rol IAM; Google Cloud muestra el uso de las claves de cuentas de servicio en el recomendador de IAM. Cualquier cuenta sin usar durante más de 90 días es candidata a retirarse.
• Busca en tu infraestructura como código y en tus almacenes de secretos. Busca en Terraform, en los manifiestos de Kubernetes y en las rutas del almacén el nombre de la cuenta o el ID de la clave para averiguar qué cargas de trabajo la referencian.
• Usa herramientas de recomendación de accesos. AWS IAM Access Analyzer y el Policy Analyzer de GCP comparan los permisos concedidos con los permisos realmente usados: la diferencia es el exceso de aprovisionamiento que debes recortar.

Cómo proteger una cuenta de servicio: un método priorizado

No intentes arreglarlo todo a la vez. Prioriza por radio de impacto (nivel de privilegio multiplicado por exposición) y trabaja de arriba abajo:

• 1. Guarda la credencial en un almacén de secretos. Saca las claves estáticas y las contraseñas del código y la configuración y llévalas a un gestor de secretos (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager). Elimina primero los secretos incrustados en el código: son lo más fácil de robar para un atacante.
• 2. Limita al mínimo privilegio. Usa los datos de uso de la sección anterior para quitar los permisos que no se usan. Una integración con la API de Gmail que solo envía correo no necesita permiso de lectura completa del buzón.
• 3. Sustituye las claves estáticas por credenciales de corta duración. Prefiere la federación de identidades de cargas de trabajo, OIDC o la asunción de roles frente a las claves de larga duración. Un token que vive 15 minutos vale mucho menos robado que una clave que vive para siempre.
• 4. Rota de forma programada y automatízalo. Cualquier secreto estático que quede recibe una política de rotación (de 30 a 90 días) impuesta por herramientas, no por recordatorios en el calendario.
• 5.