Cuentas de servicio y sus riesgos

Tres rasgos hacen a una cuenta de servicio más peligrosa que una cuenta de persona con el mismo nivel de privilegio: su contraseña suele ser antigua porque rotarla implica coordinar un cambio en la aplicación que la usa, con frecuencia tiene privilegios de administrador de dominio «por comodidad» cuando bastaría con permisos mucho más acotados, y su actividad es constante y automatizada, lo que hace que un uso indebido se mezcle con el ruido normal y sea más difícil de distinguir. Ninguno de los tres es un fallo de software: son decisiones de diseño que se acumulan con el tiempo.

Un nombre principal de servicio (SPN) asocia una cuenta con el servicio que representa —por ejemplo, un servicio de base de datos corriendo bajo una cuenta de dominio en lugar de una cuenta de equipo local—. Que una cuenta tenga un SPN registrado es información pública dentro del dominio, visible para cualquier usuario autenticado, y por eso el inventario de SPN es uno de los primeros lugares donde un evaluador —o un atacante— identifica qué cuentas de servicio existen y a qué sistema sirven, sin tocar nada todavía.

El hallazgo con más peso no es la antigüedad de la contraseña por sí sola, ni el privilegio por sí solo: es cuando las dos cosas coinciden en la misma cuenta. Una cuenta de servicio con privilegios de administrador de dominio y una contraseña que no ha cambiado en años es el tipo de hallazgo que un informe prioriza arriba, porque junta una ventana de exposición larga con un impacto máximo si esa contraseña se compromete por cualquier vía.

No toda cuenta de servicio con privilegio alto es un hallazgo: si ese privilegio es el mínimo necesario para la función del servicio, está documentado y la cuenta está dada de alta en un inventario de activos conocido, es una configuración correcta aunque suene parecida sobre el papel a una mal configurada. El criterio para separar ambas no es el nivel de privilegio en sí, sino si ese privilegio corresponde a lo que el servicio necesita hacer.