Dienstkonten über Betriebssystemfamilien hinweg: Least Privilege für die eigenen Hintergrunddienste eines Agenten

Worum es geht

Jede Betriebssystemfamilie stellt einem unbeaufsichtigten Prozess eine Identität zur Verfügung, die nicht der Login einer Person ist:

• Linux-Systembenutzer: angelegt mit useradd --system und der Shell /usr/sbin/nologin (oder /bin/false). Die Man-Page nologin(8) beschreibt sie als Programm, das den Login höflich verweigert und den Inhalt von /etc/nologin.txt ausgibt, sofern diese Datei existiert. Das Konto besitzt weiterhin Dateien und führt Prozesse ganz normal aus, kann aber keine interaktive Sitzung starten.
• systemd DynamicUser=: Statt überhaupt einen persistenten Systembenutzer anzulegen, kann eine Unit in ihrem Abschnitt [Service] die Option DynamicUser=yes setzen. Laut systemd.exec(5) vergibt systemd dann nur für die Laufzeit der Unit dynamisch eine UID/GID; es gibt kein persistentes Konto, kein Home-Verzeichnis und keine Shell, die abgesichert werden müssten. Über StateDirectory= erhält die Unit dennoch persistenten Speicher mit korrekten Besitzverhältnissen.
• Virtuelle Windows-Konten: Identitäten der Form NT SERVICE\<servicename>, die vom Betriebssystem automatisch verwaltet werden, ohne Passwort, das gespeichert oder rotiert werden müsste. Microsoft dokumentiert sie als Option neben den klassischen eingebauten Konten Local System, Network Service und Local Service.
• Gruppenverwaltete Dienstkonten (gMSA): ein von Active Directory verwaltetes Konto, dessen Passwort von AD automatisch erzeugt und rotiert wird und nur von den dafür autorisierten Rechnern abgerufen werden kann (siehe Microsofts Übersicht zu gMSA). Es ist das domänenintegrierte Gegenstück zum virtuellen Konto für Dienste, die auf mehreren Rechnern laufen oder Domänenzugriff benötigen.
• macOS-Daemon-Benutzer: Von launchd verwaltete Daemons laufen üblicherweise unter dedizierten System-UIDs im reservierten unteren Bereich statt unter einem echten Login-Benutzer. Konfiguriert wird das über die launchd-Property-List des Daemons, nicht über einen Shell-Login.

Warum es wichtig ist

Installiert ein Agent einen eigenen Hintergrunddienst (Scheduler, Webhook-Listener, Sync-Daemon), übernimmt dieser das Konto, unter dem er gestartet wird. Ein Dienst, der als normaler Administrator oder als Konto des deployenden Benutzers läuft, erhält dessen vollen Dateizugriff und unter Windows auch dessen Netzwerk-Anmeldedaten – weit mehr, als der Dienst braucht. Alle oben genannten Mechanismen sollen genau das vermeiden: kein interaktiver Login, kein langlebiges, von Hand verwaltetes Passwort und oft gar keine persistente Identität, die später aufgeräumt werden müsste.

So wird es angewendet

• Unter Linux DynamicUser=yes bevorzugen (mit StateDirectory= für Daten, die erhalten bleiben müssen). Auf einen --system-Benutzer mit nologin zurückgreifen, wenn Dateien ausserhalb von systemd-verwalteten Verzeichnissen eine stabile UID erfordern.
• Unter Windows läuft ein mit sc.exe create oder New-Service erstellter Dienst als LocalSystem, sofern nichts anderes angegeben wird; deshalb NT SERVICE\<name> ausdrücklich setzen. Ein virtuelles Konto greift im Netzwerk als Computerkonto zu. Braucht der Dienst eine eigene Domänenidentität oder läuft er auf mehreren Hosts, ein gMSA verwenden statt eines gemeinsamen Domänenkontos mit statischem Passwort.
• Unter macOS Hintergrundagenten über launchd als dedizierten Daemon-Benutzer ausführen, nicht als interaktiv angemeldeten Benutzer.
• In jedem Fall nur die konkreten Datei-, Netzwerk- und API-Berechtigungen vergeben, die der Dienst benötigt, nicht die Berechtigungen dessen, der ihn installiert hat.

Stolpersteine

• Annahme, nologin verhindere generell, dass das Konto Prozesse ausführt – es blockiert nur den interaktiven Shell-Login; cron, systemd und su -s können weiterhin Befehle als dieser Benutzer ausführen.
• Die Liste der autorisierten Rechner eines gMSA grösser lassen als die Menge der Rechner, auf denen der Dienst tatsächlich läuft.