Cuentas de servicio en distintas familias de SO: mínimo privilegio para los propios servicios en segundo plano de un agente

Qué es

Cada familia de SO ofrece a un proceso desatendido una identidad que no es el inicio de sesión de una persona:

• Usuarios de sistema en Linux: se crean con useradd --system y con /usr/sbin/nologin (o /bin/false) como shell. La página de manual nologin(8) lo documenta como un programa que rechaza el inicio de sesión con cortesía e imprime el contenido de /etc/nologin.txt si ese archivo existe; la cuenta sigue siendo propietaria de archivos y ejecuta procesos con normalidad, pero no puede iniciar una sesión interactiva.
• DynamicUser= de systemd: en lugar de crear un usuario de sistema persistente, una unidad puede establecer DynamicUser=yes en su sección [Service]. systemd.exec(5) documenta que systemd asigna entonces un UID/GID de forma dinámica solo durante la ejecución de la unidad, sin cuenta persistente, directorio personal ni shell que proteger; StateDirectory= sigue proporcionándole almacenamiento persistente con el propietario correcto.
• Cuentas virtuales de Windows: identidades con el formato NT SERVICE\<servicename>, gestionadas automáticamente por el SO, sin contraseña que almacenar ni rotar. Microsoft las documenta como una opción junto a las cuentas integradas tradicionales Local System, Network Service y Local Service.
• Cuentas de servicio administradas de grupo (gMSA): una cuenta gestionada por Active Directory cuya contraseña genera y rota automáticamente AD, y que solo pueden recuperar los equipos concretos autorizados para ella, según la descripción general de gMSA de Microsoft. Es el equivalente, en equipos unidos a un dominio, de una cuenta virtual para servicios que se ejecutan en varias máquinas o necesitan acceso al dominio.
• Usuarios de daemon en macOS: los daemons gestionados por launchd suelen ejecutarse con UID de sistema dedicados, dentro del rango bajo reservado, en lugar de un usuario real con inicio de sesión, y se configuran mediante la lista de propiedades de launchd del daemon, no mediante un inicio de sesión con shell.

Por qué importa

Un agente que instala su propio servicio en segundo plano (un planificador, un listener de webhooks, un daemon de sincronización) hereda la cuenta con la que se lanza. Un servicio ejecutado como administrador normal o como la cuenta del «usuario que hizo el despliegue» conserva todo el acceso a archivos de esa cuenta y, en Windows, sus credenciales de red, mucho más de lo que el servicio necesita. Cada uno de los mecanismos anteriores existe precisamente para evitarlo: sin inicio de sesión interactivo, sin contraseña duradera gestionada a mano y, a menudo, sin una identidad persistente que haya que limpiar.

Cómo aplicarlo

• En Linux, es preferible DynamicUser=yes (con StateDirectory= para los datos que deba conservar); cuando haya archivos fuera de los directorios gestionados por systemd que necesiten un UID estable, recurra a un usuario --system con nologin.
• En Windows, un servicio creado con sc.exe create o New-Service se ejecuta como LocalSystem si no se indica otra cosa, así que establezca NT SERVICE\<name> de forma explícita. Una cuenta virtual accede a la red como la cuenta del equipo; use una gMSA cuando el servicio necesite su propia identidad de dominio o se ejecute en varios hosts, en lugar de una cuenta de dominio compartida con contraseña estática.
• En macOS, ejecute los agentes en segundo plano como un usuario de daemon dedicado mediante launchd, no como el usuario que ha iniciado sesión de forma interactiva.
• En todos los casos, conceda solo los permisos concretos de archivos, red y API que el servicio necesita, no los de quien lo instaló.

Trampas

• Suponer que nologin impide por completo que la cuenta ejecute procesos: solo bloquea el inicio de sesión interactivo con shell; cron, systemd y su -s aún pueden ejecutar comandos como ese usuario.
• Dejar la lista de equipos autorizados de una gMSA más amplia que las máquinas que realmente ejecutan el servicio.