# Service Accounts Mastery: Das Prinzip der minimalen Rechte

TL;DR / Management Summary Ein gehackter Webserver darf niemals Root-Rechte erlangen. Der Schlüssel dazu ist die Nutzung von Service-Accounts. Ein Senior Admin erstellt für jeden Dienst einen dedizierten, unprivilegierten Benutzer, der weder ein Passwort noch eine Shell besitzt. Mit dem Principle of Least Privilege (PoLP) stellen wir sicher, dass ein Prozess nur auf genau die Dateien und Sockets zugreifen kann, die er zwingend für seine Arbeit benötigt.

# 1. Einführung & Architektur

Die Anatomie eines Service-Accounts.

Im Gegensatz zu menschlichen Usern haben Service-Accounts (System-User) folgende Merkmale:

1. UID < 1000 (Standard in den meisten Distros).
2. Kein Login-Passwort (Sperre in /etc/shadow).
3. Keine interaktive Shell ( /usr/sbin/nologin).
4. Minimale Berechtigungen auf dem Dateisystem.

# Die Isolation (Mermaid)

graph TD
    subgraph "The Protected Core"
        A[Root FS / etc / root]
    end
    subgraph "Service A: Web"
        B[User: www-data] --> C[Files: /var/www]
        B --x|Block| A
    end
    subgraph "Service B: DB"
        D[User: mysql] --> E[Files: /var/lib/mysql]
        D --x|Block| A
        D --x|Block| C
    end

# 2. Praxis: Erstellung eines sicheren Accounts

Schritt-für-Schritt.

Wir erstellen einen Account für eine Custom Go-Applikation namens processor.

# Der Profi-Befehl

sudo useradd -r -s /usr/sbin/nologin -d /var/lib/processor -m -c "App: Data Processor" processor

• -r: Erstellt einen System-User (UID < 1000).
• -s /usr/sbin/nologin: Verhindert jeden Login (auch via SSH).
• -d /var/lib/processor: Definiert ein Arbeitsverzeichnis.

# 3. Berechtigungs-Management

Nur das Nötigste.

Sichern Sie die Daten der Applikation so ab, dass andere Service-Accounts (z.B. der Webserver) sie nicht lesen können.

# Gehört dem Service-Account, Gruppe hat keine Rechte
sudo chown -R processor:processor /var/lib/processor
sudo chmod 700 /var/lib/processor

# 4. Day-2 Operations: Systemd Integration

Dienste unter dem Account ausführen.

Integrieren Sie den User direkt in die Unit-Datei (Artikel 007).

[Service]
User=processor
Group=processor
WorkingDirectory=/var/lib/processor
# Verhindert, dass der Prozess neue Rechte erlangt
NoNewPrivileges=true

# 5. Troubleshooting & “War Stories”

Wenn die Sicherheit blockiert.

# Story 1: “Der hängende Cronjob”

Symptom: Ein Skript, das unter dem User backup-user laufen soll, bricht sofort ab. Ursache: Der Admin hat dem User /bin/false als Shell gegeben. Manche Skript-Interpreter oder Cron-Umgebungen versuchen jedoch eine Shell zu spawnen, um Pipes (|) zu verarbeiten. Lösung: Nutzen Sie /usr/sbin/nologin. Es gibt eine freundliche Meldung aus, falls doch ein interaktiver Login versucht wird, erlaubt aber die Ausführung von Skripten durch den Scheduler.

# Story 2: “Das Root-Loch durch Dateibesitz”

Symptom: Ein Angreifer hat den Webserver-Account übernommen und konnte das System permanent kompromittieren. Ursache: Das Binary des Webservers (/usr/local/bin/nginx) gehörte dem User www-data. Der Angreifer hat das Binary einfach durch ein bösartiges Programm ersetzt. Lösung: Binaries müssen immer Root gehören! Nur die Datenverzeichnisse dürfen dem Service-Account gehören. sudo chown root:root /usr/local/bin/myapp && sudo chmod 755 /usr/local/bin/myapp.

# 6. Fazit & Empfehlung

• Pflicht: Führen Sie niemals einen Dämon als root aus, wenn es nicht technisch zwingend erforderlich ist (wie bei sshd).
• Wartung: Nutzen Sie find / -user <service_account>, um regelmäßig zu prüfen, ob der User Dateien an Orten erstellt hat, an die er nicht hingehört.
• Wahl: Nutzen Sie für jeden Dienst einen einzigartigen User. Nutzen Sie niemals www-data für Ihre Datenbank!

# Anhang: Cheatsheet