Serverzugänge im Team verwalten: SSH-Keys, Rollen und ein sauberes Offboarding

In vielen Unternehmen wächst der Serverzugang mit dem Team mit, ohne dass er jemals bewusst gestaltet wurde. Am Anfang kennt eine Person das Root-Passwort, später drei, dann ein Dienstleister. Nach zwei Jahren weiß niemand mehr genau, wer sich auf welchem System anmelden kann. Spätestens wenn eine Mitarbeiterin das Unternehmen verlässt oder ein Audit ansteht, wird das zum Problem.

Zugriffsverwaltung ist dabei keine Frage teurer Werkzeuge, sondern von Konventionen, die konsequent eingehalten werden. Dieser Beitrag beschreibt, welche Entscheidungen dafür nötig sind.

Warum geteilte Sammelkonten das Kernproblem sind

Ein gemeinsam genutzter Root-Zugang hat drei Nachteile, die sich nicht durch Sorgfalt ausgleichen lassen.

Erstens ist keine Zuordnung möglich. Steht im Log ein Befehl, der eine Datenbank gelöscht hat, steht dort nur der Benutzername root. Wer es war, lässt sich nur noch durch Nachfragen klären.

Zweitens skaliert der Entzug nicht. Verlässt eine Person das Unternehmen, müssen Sie das Passwort auf allen Systemen ändern und allen anderen neu mitteilen. In der Praxis wird das aufgeschoben.

Drittens fehlt die Rechteabstufung. Wer Root hat, kann alles, auch versehentlich. Ein Entwickler, der nur einen Dienst neu starten muss, braucht keinen Vollzugriff auf das Dateisystem.

Jeder Mensch, der auf einen Server zugreift, sollte einen eigenen, namentlich zuordenbaren Account haben und nur die Rechte, die seine Aufgabe erfordert.

Persönliche Accounts als Grundlage

Der erste Schritt ist unspektakulär: Für jede Person wird ein eigener Systembenutzer angelegt, die direkte Anmeldung als root wird deaktiviert. In der sshd_config heißt das:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Damit ist die Anmeldung nur noch mit SSH-Schlüsseln möglich. Das entfernt in einem Schritt die gesamte Klasse von Angriffen, die auf geratene oder wiederverwendete Passwörter setzt. Automatisierte Anmeldeversuche laufen ins Leere, weil sie nichts mehr haben, das sie durchprobieren könnten.

Für Dienstkonten gilt derselbe Grundsatz. Ein Deployment-Prozess bekommt einen eigenen Benutzer mit eigenem Schlüssel, keine Kopie des Zugangs eines Menschen. Sonst lässt sich später nicht unterscheiden, ob eine Änderung von der Pipeline oder von einer Person kam.

SSH-Keys praktisch handhaben

Welcher Schlüsseltyp

Für neue Schlüssel ist ed25519 die pragmatische Wahl: kurz, schnell und ohne Parameterentscheidungen. RSA mit 4096 Bit funktioniert weiterhin, ist aber nur nötig, wenn ein altes System ed25519 nicht unterstützt.

ssh-keygen -t ed25519 -C "vorname.nachname@firma"

Der Kommentar am Ende ist wichtiger, als er aussieht. Er ist oft das einzige Merkmal, an dem Sie in einer authorized_keys erkennen, zu wem ein Schlüssel gehört.

Private Schlüssel gehören nicht auf den Server

Ein privater Schlüssel bleibt auf dem Arbeitsgerät, geschützt durch eine Passphrase. Wer von einem Server auf einen weiteren springen muss, nutzt Agent Forwarding oder besser einen ProxyJump-Eintrag in der lokalen SSH-Konfiguration, statt den Schlüssel zu kopieren.

Host app01
  HostName 10.0.0.11
  User jdoe
  ProxyJump bastion

Liegt ein privater Schlüssel ohne Passphrase auf einem Server, ist jeder kompromittierte Dienst dort automatisch ein Zugang zu allen weiteren Systemen.

Wer pflegt die authorized_keys

Sobald mehr als eine Handvoll Server im Spiel ist, wird das manuelle Verteilen von Schlüsseln unzuverlässig. Sinnvoll ist eine zentrale Quelle: ein Konfigurationsmanagement, das aus einer Liste von Personen und Rollen die Dateien erzeugt, oder eine Anbindung an ein Verzeichnis. Entscheidend ist weniger das Werkzeug als die Regel, dass niemand Schlüssel direkt auf einem System einträgt. Sonst entsteht wieder ein Zustand, den nur der kennt, der ihn geschaffen hat.

Rechte staffeln statt Root verteilen

Die meisten Aufgaben brauchen keinen Vollzugriff. Über sudo lassen sich einzelne Befehle freigeben, zum Beispiel der Neustart eines Dienstes:

%webteam ALL=(root) /usr/bin/systemctl restart nginx

Das ist kein perfekter Schutz, denn viele Befehle lassen sich mit genug Kreativität ausweiten. Als organisatorische Grenze funktioniert es dennoch: Es macht den Unterschied zwischen einer geplanten und einer versehentlichen Änderung sichtbar, und es dokumentiert, wer wofür zuständig ist.

Praktisch bewährt sich eine kleine Zahl von Rollen, etwa Vollzugriff für den Serverbetrieb, Anwendungszugriff für Entwicklung und ein reiner Leserechte-Zugang für Monitoring und Fehlersuche. Mehr als vier oder fünf Rollen pflegt in der Regel niemand konsequent.

Zugangswege bündeln

Wenn jeder Server direkt aus dem Internet erreichbar ist, müssen Sie die Zugriffsregeln auf jedem Server einzeln pflegen. Eine Bastion, also ein einzelner Einstiegspunkt, oder ein VPN-Zugang reduziert das auf eine Stelle. Die Anwendungsserver akzeptieren SSH dann nur noch aus dem internen Netz.

Der Nebeneffekt ist wichtiger als die Sicherheit an sich: Sie haben einen Ort, an dem Anmeldungen protokolliert werden, und einen Ort, an dem Sie einen Zugang sperren können, wenn es schnell gehen muss.

Nachvollziehbarkeit

Serverzugriffe sollten so protokolliert werden, dass sich nachträglich rekonstruieren lässt, wer wann eingeloggt war. Das leisten die Standardlogs bereits, solange sie nicht nur lokal liegen. Wird ein System kompromittiert, kann der Angreifer lokale Logs verändern. Ein Versand an einen zentralen Logdienst verhindert das im Nachhinein nicht, macht Lücken aber erkennbar.

Für die Frage, welche Befehle ausgeführt wurden, gibt es Session-Aufzeichnung. Das ist aufwendig, wirft Fragen der Mitbestimmung auf und ist für die meisten Unternehmen nicht nötig. Die Kombination aus persönlichen Accounts, sudo-Protokollierung und zentralem Log deckt die typischen Anforderungen ab.

Offboarding als Prozess, nicht als Erinnerung

Der häufigste Befund bei Prüfungen sind Zugänge von Personen, die längst nicht mehr im Unternehmen sind. Das liegt selten an Nachlässigkeit, sondern daran, dass niemand eine vollständige Liste hat.

Hilfreich ist eine Übersicht, die für jede Person festhält, auf welche Systeme sie Zugriff hat und über welchen Weg. Diese Liste ist Teil des Offboardings, gemeinsam mit E-Mail, VPN und Anwendungskonten. Wichtig ist, dass der Zugang deaktiviert und nicht nur der Schlüssel entfernt wird, denn ein Benutzerkonto kann weitere Zugangswege haben.

Das Gleiche gilt für externe Dienstleister. Ein Zugang, der für ein Projekt eingerichtet wurde, sollte ein Enddatum haben, das beim Anlegen festgelegt wird.

Notfallzugang

Wer Passwortanmeldung und Root-Login abschaltet, braucht einen Weg zurück, falls die SSH-Konfiguration fehlerhaft ist oder das Netzwerk ausfällt. Dafür gibt es Konsolenzugänge über den Hosting-Anbieter oder ein hinterlegtes Notfallkonto, dessen Zugangsdaten verschlossen aufbewahrt werden.

Dieser Zugang sollte dokumentiert und mindestens einmal getestet worden sein. Ein Notfallweg, den noch niemand benutzt hat, ist eine Annahme und kein Plan.

Ein realistischer Einstieg

Wenn Sie heute mit geteilten Zugängen arbeiten, lohnt sich diese Reihenfolge:

1. Bestandsaufnahme: Wer hat auf welchen Systemen Zugriff, und über welchen Weg?
2. Persönliche Accounts für alle aktiven Personen anlegen und Schlüssel hinterlegen.
3. Passwortanmeldung und direkten Root-Login deaktivieren, nachdem der Notfallzugang geprüft ist.
4. Rechte über sudo auf das Notwendige begrenzen und Rollen definieren.
5. Offboarding um den Punkt Serverzugänge ergänzen und die Übersicht aktuell halten.

Die Schritte eins und fünf sind dabei die unbequemen, weil sie organisatorische Arbeit bedeuten. Sie entscheiden aber darüber, ob die technische Umstellung nach zwei Jahren noch stimmt oder wieder in einem Zustand endet, den nur einzelne Personen überblicken.