Comptes de service selon les familles d'OS : le moindre privilège pour les services d'arrière-plan propres à un agent

Ce que c'est

Chaque famille d'OS fournit aux processus non interactifs une identité qui n'est pas la connexion d'une personne :

• Utilisateurs système Linux : créés avec useradd --system et dotés du shell /usr/sbin/nologin (ou /bin/false). La page de manuel nologin(8) le décrit comme un programme qui refuse poliment la connexion et affiche le contenu de /etc/nologin.txt si ce fichier existe ; le compte reste propriétaire de fichiers et exécute des processus normalement, mais il ne peut pas ouvrir de session interactive.
• systemd DynamicUser= : au lieu de créer un utilisateur système persistant, une unité peut définir DynamicUser=yes dans sa section [Service]. D'après systemd.exec(5), systemd alloue alors dynamiquement un UID/GID uniquement pour la durée d'exécution de l'unité, sans compte persistant, sans répertoire personnel ni shell à sécuriser ; StateDirectory= lui fournit toujours un stockage persistant, avec les bons propriétaires.
• Comptes virtuels Windows : identités de la forme NT SERVICE\<servicename>, gérées automatiquement par l'OS, sans mot de passe à stocker ni à renouveler. Microsoft les documente comme une option à côté des comptes intégrés traditionnels Local System, Network Service et Local Service.
• Comptes de service gérés de groupe (gMSA) : compte géré par Active Directory, dont le mot de passe est généré et renouvelé automatiquement par AD et ne peut être récupéré que par les machines expressément autorisées, comme le décrit la présentation des gMSA de Microsoft. C'est l'équivalent du compte virtuel dans un environnement joint à un domaine, destiné aux services qui s'exécutent sur plusieurs machines ou ont besoin d'un accès au domaine.
• Utilisateurs de démons macOS : les démons gérés par launchd s'exécutent couramment sous des UID système dédiés, dans la plage basse réservée, plutôt que sous un véritable utilisateur interactif ; la configuration passe par la liste de propriétés launchd du démon, et non par une connexion shell.

Pourquoi c'est important

Un agent qui installe son propre service d'arrière-plan (planificateur, écouteur de webhook, démon de synchronisation) hérite du compte sous lequel il est lancé. Un service exécuté avec un compte administrateur ordinaire ou celui de « l'utilisateur qui déploie » dispose de tous les accès aux fichiers de ce compte et, sous Windows, de ses identifiants réseau, soit bien plus que ce dont le service a besoin. Chacun des mécanismes ci-dessus existe précisément pour éviter cela : pas de connexion interactive, pas de mot de passe durable géré à la main et, souvent, aucune identité persistante à nettoyer.

Comment l'appliquer

• Sous Linux, privilégier DynamicUser=yes (avec StateDirectory= pour les données à conserver) ; se rabattre sur un utilisateur --system avec nologin lorsque des fichiers situés hors des répertoires gérés par systemd exigent un UID stable.
• Sous Windows, un service créé avec sc.exe create ou New-Service s'exécute sous LocalSystem si rien d'autre n'est indiqué ; il faut donc définir explicitement NT SERVICE\<name>. Un compte virtuel accède au réseau sous l'identité du compte d'ordinateur ; utiliser un gMSA lorsque le service a besoin de sa propre identité de domaine ou s'exécute sur plusieurs hôtes, plutôt qu'un compte de domaine partagé avec un mot de passe statique.
• Sous macOS, exécuter les agents d'arrière-plan sous un utilisateur de démon dédié via launchd, et non sous l'utilisateur connecté de manière interactive.
• Dans tous les cas, n'accorder que les permissions précises sur les fichiers, le réseau et les API dont le service a besoin, et non celles de la personne qui l'a installé.

Pièges

• Croire que nologin empêche totalement le compte d'exécuter des processus : il ne bloque que la connexion shell interactive ; cron, systemd et su -s peuvent toujours exécuter des commandes sous cet utilisateur.
• Laisser la liste des ordinateurs autorisés d'un gMSA plus large que l'ensemble des machines qui exécutent réellement le service.