Getrennte SSH-Zugangsdaten für sichereren Produktionszugriff

Eine einzelne SSH-Zugangsdaten, die Entwicklung, Staging und Produktion erreicht, macht aus einer kleinen Bequemlichkeit eine weitreichende Fernberechtigung. Sie macht auch Genehmigungen unehrlich: Jemand kann eine harmlos wirkende Staging-Aufgabe genehmigen, während dieselbe Zugangsdaten wenige Minuten später eine Produktionssitzung öffnet.

Trennen Sie SSH-Zugangsdaten nach Systemklasse und Risiko. Machen Sie die Trennung anschließend in der Client-Konfiguration sichtbar, setzen Sie sie auf den Servern durch und testen Sie verweigerte Pfade ebenso gründlich wie erlaubte. Ich habe Teams erlebt, die das Zugriffskontrolle nannten, obwohl sie einem Schlüssel in ~/.ssh/config lediglich drei Namen gaben. Das ist keine Grenze.

Eine Zugangsdaten erzeugt eine gemeinsame Fehlerdomäne

Eine Zugangsdaten, die über mehrere Umgebungen hinweg verwendet wird, gibt jedem Besitzer die zusammengefassten Berechtigungen dieser Umgebungen. Wenn der Arbeitsplatz eines Entwicklers, eine automatisierte Aufgabe oder ein Genehmigungspfad sie verwenden kann, erreicht die Kompromittierung dieses einen Pfads die höchste Umgebung, die den öffentlichen Schlüssel akzeptiert.

Die übliche Verteidigung lautet, dass dieselben Personen jede Umgebung verwalten. Das verfehlt den Punkt. Die Personen können sich überschneiden, die Situationen aber nicht. Entwicklungsarbeit umfasst oft ungeprüfte Skripte, Testdaten, temporäre Rechner und breit angelegte Experimente. Produktionsarbeit sollte weniger zulässige Abläufe, sorgfältigere Prüfungen und eine klare Aufzeichnung darüber haben, wer sich wann und warum verbunden hat.

Darum bewirkt auch eine einzelne Zugangsdaten mit getrennten Host-Aliasen nichts. Diese Einträge wirken ordentlich:

Host dev-db
  HostName dev-db.internal

Host prod-db
  HostName prod-db.internal

Wenn jedoch beide Hosts denselben öffentlichen SSH-Schlüssel akzeptieren, kann sich jeder Alias mit demselben privaten Schlüssel authentifizieren. Ein Tippfehler in einer Automatisierungsvariable oder ein kopierter Befehl kann die Grenze ohne eine neue Autorisierungsentscheidung überschreiten.

Getrennte Zugangsdaten ändern das Ergebnis. Eine gestohlene Entwicklungszugangsdaten sollte bei Staging und Produktion scheitern. Ein Prozess, der für die Verwendung einer Staging-Zugangsdaten genehmigt wurde, sollte weder privates Material noch Signiermöglichkeiten besitzen, mit denen er sich in der Produktion authentifizieren kann. Das sind unterschiedliche Kontrollen. Die erste begrenzt einen Einbruch. Die zweite verhindert, dass ein legitimer, aber zu weit berechtigter Prozess etwas Falsches tut.

Verwechseln Sie das nicht mit Passwortrotation. Bei der Rotation wird eine Zugangsdaten im Laufe der Zeit ersetzt. Die Trennung entscheidet, wo eine Zugangsdaten überhaupt funktionieren darf. Sie brauchen beides, aber Rotation kann keine Zugangsdaten reparieren, die absichtlich überall akzeptiert wird.

Umgebungsnamen reichen als Grenzen nicht aus

Entwicklung, Staging und Produktion sind nur dann hilfreiche Bezeichnungen, wenn sie unterschiedlichen Vertrauensentscheidungen entsprechen. Ein Host namens staging kann produktionsähnliche Daten enthalten, echte E-Mails versenden, ein Signiergeheimnis speichern oder mit einem aktiven Zahlungsendpunkt verbunden sein. Umgekehrt kann ein Produktionshost für Monitoring weniger Berechtigungen benötigen als ein Administrator einer Staging-Datenbank.

Ordnen Sie SSH-Zugriff nach den Folgen einer Sitzung ein, nicht nach einem Hostnamenpräfix. Ich beginne normalerweise mit vier Fragen:

• Kann dieses Konto Kunden- oder regulierte Daten lesen?
• Kann es einen laufenden Dienst, eine Bereitstellung, eine Firewall oder einen DNS-Eintrag ändern?
• Kann es eine weitere Zugangsdaten abrufen oder einen anderen Dienst imitieren?
• Kann es zu Systemen mit höheren Berechtigungen wechseln?

Wenn sich die Antwort zwischen Hosts ändert, sollte sich auch der Bereich der Zugangsdaten ändern. Das führt oft zu nützlicheren Gruppen als dem bekannten Drei-Umgebungen-Modell: Anwendungsentwicklung, Testsysteme mit sensiblen Daten, Release-Hosts, schreibgeschützte Produktionsdiagnose und Produktionsadministration.

Ein eigenes Unix-Konto gehört oft ebenfalls in den Entwurf. Ein Konto namens deploy kann das Release-Verzeichnis besitzen und einen eingeschränkten Befehl akzeptieren. Ein Konto namens ops-read kann Protokolle prüfen, ohne Service-Units zu bearbeiten. Ein Konto namens admin kann Wartungsarbeiten unter einem höheren Genehmigungsstandard durchführen. Getrennte Konten geben dem Server einen Ort, an dem Berechtigungen angebunden werden können, und den Protokollen ein aussagekräftiges Subjekt.

Lassen Sie sich von getrennten Kontonamen nicht dazu verleiten, eine gemeinsame Zugangsdaten zu akzeptieren. Wenn derselbe öffentliche Schlüssel auf verschiedenen Rechnern unter dev, deploy und admin auftaucht, bleibt der private Schlüssel eine umgebungsübergreifende Zugangsdaten. Getrennte Konten und getrennte Zugangsdaten lösen unterschiedliche Teile des Problems.

Geben Sie jeder Person und jedem Prozess eine eigene Identität

Jeder menschliche Bediener und jeder Automatisierungsprozess benötigt innerhalb seiner erlaubten Umgebungsklasse eine eigene SSH-Identität. Ein privater Teamschlüssel erschwert die Reaktion auf Vorfälle, weil der Zugriff einer Person nur durch Ersetzen des Schlüssels für alle widerrufen werden kann. Außerdem sind Protokolle nahezu wertlos, wenn mehrere Personen sich mit demselben Konto und demselben öffentlichen Schlüssel authentifizieren.

Erstellen Sie für menschliche Bediener getrennte private Schlüssel für die erlaubten Bereiche. Verwenden Sie Namen, die den Bereich nennen, nicht vage Namen wie id_ed25519_new oder server-key-final.

mkdir -p ~/.ssh/identities
chmod 700 ~/.ssh/identities

ssh-keygen -t ed25519 \\
  -f ~/.ssh/identities/id_ed25519_dev_alex \\
  -C dev-alex

ssh-keygen -t ed25519 \\
  -f ~/.ssh/identities/id_ed25519_stage_alex \\
  -C stage-alex

ssh-keygen -t ed25519 \\
  -f ~/.ssh/identities/id_ed25519_prod_alex \\
  -C prod-alex

Der Kommentar hilft Menschen beim Prüfen einer Liste öffentlicher Schlüssel, erzwingt aber nichts. Der Server entscheidet anhand des öffentlichen Schlüssels, des Kontos und weiterer Autorisierungsregeln über den Zugriff. Behandeln Sie Kommentare als Bezeichnungen für Bediener, nicht als Sicherheitsmetadaten.

Für Automatisierung gilt dieselbe Disziplin. Ein Release-Job sollte Zugangsdaten verwenden, die für diesen Job und diese Umgebung ausgestellt wurden, nicht die in einem Secret-Speicher abgelegten Produktionszugangsdaten eines Entwicklers. Wenn mehrere Jobs Zugriff benötigen, geben Sie ihnen getrennte Identitäten, sofern sie nicht denselben Besitzer, dieselbe Zielmenge und dieselbe Befehlsberechtigung haben. Eine Zugangsdaten sollte bei einer Untersuchung nach einem Vorfall eine einfache Frage beantworten: Welcher Prozess hat sie verwendet?

Hardware-gestützte Zugangsdaten können den Diebstahl einer privaten Schlüsseldatei erschweren, reparieren aber keinen zu breit gefassten Autorisierungsentwurf. Eine hardwaregestützte Zugangsdaten, die von allen Umgebungen akzeptiert wird, gewährt weiterhin Zugriff auf alle Umgebungen. Begrenzen Sie zuerst den Bereich und entscheiden Sie anschließend, wie jeder private Schlüssel geschützt wird.

Die Client-Konfiguration muss verhindern, dass Identitäten auslaufen

OpenSSH versucht Identitäten aus der Konfiguration und, sofern nicht eingeschränkt, Identitäten, die ein SSH-Agent anbietet. Dieses Verhalten ist praktisch, bis ein Agent eine Produktionsidentität enthält und eine für Staging gedachte Verbindung damit erfolgreich ist.

Das OpenSSH-Handbuch zu ssh_config beschreibt IdentitiesOnly als Einstellung, die die für die Public-Key-Authentifizierung verwendeten Identitäten auf die konfigurierten Identitätsdateien und Zertifikate beschränkt, selbst wenn ein Agent andere Identitäten enthält. Setzen Sie sie für jeden Bereichs-Alias. Geben Sie jedem Alias genau eine ausdrückliche Identitätsdatei und verlassen Sie sich nicht auf die Reihenfolge, in der ein Agent zufällig Schlüssel anbietet.

Host dev-*
  User devops
  IdentityFile ~/.ssh/identities/id_ed25519_dev_alex
  IdentitiesOnly yes
  ForwardAgent no

Host stage-*
  User release
  IdentityFile ~/.ssh/identities/id_ed25519_stage_alex
  IdentitiesOnly yes
  ForwardAgent no

Host prod-*
  User admin
  IdentityFile ~/.ssh/identities/id_ed25519_prod_alex
  IdentitiesOnly yes
  ForwardAgent no

Verwenden Sie Aliase, bei denen die Umgebung im Terminalverlauf kaum zu übersehen ist. prod-api-01 ist beispielsweise besser als api-01, wenn Entwicklung und Produktion jeweils einen API-Host mit ähnlichem Namen enthalten. Verbergen Sie das Ziel nicht hinter einem allgemeinen Alias wie server.

Prüfen Sie die endgültige Konfiguration, die OpenSSH verwenden wird. So erkennen Sie Konflikte durch Wildcards, eingebundene Dateien und eine vergessene globale Einstellung.

ssh -G prod-api-01 | grep -E '^(hostname|user|identityfile|identitiesonly|forwardagent) '

Die Ausgabe sollte so aussehen:

hostname prod-api-01.internal
user admin
identitiesonly yes
forwardagent no
identityfile ~/.ssh/identities/id_ed25519_prod_alex

Der Pfad kann auf Ihrem Rechner anders aufgelöst werden. Entscheidend ist, dass der Produktionsalias nur auf die Produktionsidentität verweist und identitiesonly den Wert yes hat.

Ein häufiger Fehler tritt auf, nachdem jemand aus Bequemlichkeit ssh-add ausgeführt hat. Der Agent enthält nun mehrere Identitäten. Ohne IdentitiesOnly yes probiert der Client sie an einem Host aus, bis eine funktioniert. Server begrenzen häufig die Zahl der Authentifizierungsversuche, was zu schwer verständlichen Fehlern führen kann. Schlimmer noch: Eine umfassende Zugangsdaten kann die Verbindung unbemerkt erfolgreich machen, und der Bediener merkt möglicherweise nie, dass er den falschen Bereich verwendet hat.

Die Serverautorisierung muss die Trennung abbilden

Getrennte private Schlüssel funktionieren nur, wenn jeder Server den passenden öffentlichen Schlüssel akzeptiert und die anderen ablehnt. Hinterlegen Sie den öffentlichen Entwicklungsschlüssel auf Entwicklungs-Hosts, den Staging-Schlüssel auf Staging-Hosts und den Produktionsschlüssel nur dort, wo Produktionszugriff vorgesehen ist.

Diese Regel klingt selbstverständlich, doch das schlechte Muster ist bei dringenden Einrichtungsvorgängen verbreitet: Jemand kopiert eine vollständige authorized_keys-Datei auf einen neuen Host. Sie enthält oft jahrelang veraltete Identitäten, frühere Auftragnehmer, Bereitstellungsschlüssel und einen allgemeinen Administratorschlüssel. Der neue Produktionshost übernimmt dadurch Zugriffsentscheidungen, die niemand geprüft hat.

Erstellen Sie die Autorisierungsliste jedes Kontos aus seiner Aufgabe heraus. Verwenden Sie für ein Bereitstellungskonto OpenSSH-Einschränkungen, die zu einem nicht interaktiven Transfer oder Bereitstellungsvorgang passen. Das OpenSSH-Handbuch zu authorized_keys dokumentiert die Option restrict. Sie deaktiviert Port-Weiterleitung, Agent-Weiterleitung, X11-Weiterleitung und PTY-Zuweisung, sofern keine andere Option sie erlaubt. Ein eingeschränkter Bereitstellungseintrag kann so aussehen:

restrict,from="198.51.100.0/24" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... prod-release-job

Ersetzen Sie das Beispielnetz durch einen Adressbereich, den Sie tatsächlich kontrollieren. Fügen Sie from= nicht nur hinzu, weil es streng aussieht. Wenn der Job von wechselnden Adressen oder einem Pool gehosteter Runner kommt, verursacht eine ungenaue Quellenbeschränkung einen Ausfall. Unter Zeitdruck wird dann womöglich jede Einschränkung entfernt.

Verwenden Sie erzwungene Befehle nur für eng definierte Automatisierung. Ein erzwungener Befehl kann verhindern, dass eine Bereitstellungszugangsdaten eine Shell erhält, wird aber zugleich zu einem Wartungsvertrag. Der Befehl muss Eingaben prüfen, Pfade sicher auswählen und die Anfrage protokollieren. Wenden Sie einen erzwungenen Befehl nicht auf ein Administratorkonto an und nehmen Sie dann an, das Konto sei sicher. Irgendwann wird jemand eine Shell benötigen und die Einschränkung umgehen.

Für menschliche Produktionsadministration ist ein eigenes Konto mit eigenem öffentlichen Schlüssel meist verständlicher als eine komplizierte Sammlung von authorized_keys-Optionen. Beschränken Sie das Konto mit den normalen Hostberechtigungen, protokollieren Sie seine sudo-Aktivitäten, soweit zutreffend, und entfernen Sie den öffentlichen Schlüssel, sobald die Person keinen Zugriff mehr benötigt.

SSH-Zertifikate helfen nur bei eng gefassten Angaben

OpenSSH-Zertifikate können die Ausgabe kurzlebiger Zugangsdaten und ihren operativen Widerruf erleichtern. Eine Zertifizierungsstelle signiert den öffentlichen Schlüssel eines Benutzers. Die Server vertrauen dann der Zertifizierungsstelle, statt jeden einzelnen öffentlichen Schlüssel zu speichern. Das kann den Aufwand für große Rechnerflotten verringern.

Sie machen die Trennung von Autoritäten jedoch nicht überflüssig. Ein Zertifikat mit einem Produktions-Principal sollte nicht zusätzlich Entwicklung und Staging Zugriff geben, nur weil ein Bediener in allen drei Bereichen arbeitet. Stellen Sie unterschiedliche Zertifikate aus, verwenden Sie verschiedene Principals oder setzen Sie getrennte Zertifizierungsstellen ein, wenn die Verwaltungs- und Risikogrenzen das rechtfertigen.

Das OpenSSH-Zertifikatsprotokoll unterscheidet Benutzerzertifikate, Principals, Gültigkeitszeiträume und kritische Optionen. Diese Struktur ist nur dann nützlich, wenn der Server die Principals prüft und die Ausstellungsregeln eng bleiben. Ein Zertifikat, das für jedes Konto auf jedem Host gültig ist, macht aus einem privaten Schlüssel lediglich eine umfassend vertrauenswürdige Identität mit Ablaufdatum.

Kurze Zertifikatslaufzeiten helfen bei verlorenen Geräten und ausgeschiedenen Mitarbeitern, ersetzen aber nicht den Widerruf während eines aktiven Vorfalls. Sie brauchen weiterhin eine Möglichkeit, die Akzeptanz einer kompromittierten Identität sofort zu beenden oder ihre Autorisierung zügig zu entfernen. Planen Sie diesen Mechanismus vor der Ausstellung von Zertifikaten und testen Sie ihn auf einem echten Host.

Zertifikate lösen auch keinen Missbrauch des Agents. Wenn ein automatisierter Prozess jederzeit ein Produktionszertifikat anfordern kann, bildet dieser Ausstellungsdienst die Produktionsgrenze. Schützen Sie ihn mit derselben Sorgfalt wie einen privaten Produktionsschlüssel.

Agent-Weiterleitung überschreitet eine unsichtbare Grenze

SSH-Agent-Weiterleitung erlaubt es einem entfernten Host, Ihren lokalen Agenten zum Signieren von Authentifizierungsanfragen für weitere Hosts aufzufordern. Der entfernte Rechner erhält den privaten Schlüssel nicht. Ein Prozess, der unter dem entfernten Konto läuft, kann den weitergeleiteten Agenten jedoch verwenden, solange Ihre Sitzung geöffnet ist.

Das macht die Weiterleitung besonders gefährlich, wenn eine Produktionssitzung zunächst auf einem Sprunghost landet. Wird der Sprunghost kompromittiert oder läuft dort ein nicht vertrauenswürdiger Prozess unter diesem Konto, kann er Signaturen von jeder Identität anfordern, die Ihr weitergeleiteter Agent anbietet. Das Ergebnis kann seitlicher Zugriff sein, den Ihr ursprünglicher Verbindungsplan nie erwähnt hat.

Behalten Sie diese Standardeinstellung in der Client-Konfiguration:

Host *
  ForwardAgent no

Erstellen Sie anschließend nur dort eine einzelne, ausdrückliche Ausnahme, wo ein gepflegter Ablauf sie erfordert. Fragen Sie vor dieser Ausnahme, ob ProxyJump, eine eigene Bastion-Zugangsdaten oder ein lokal ausgeführter Vorgang die Weiterleitung überflüssig machen würden. ProxyJump transportiert die SSH-Verbindung über einen Zwischenhost. Es legt Ihren lokalen Agenten diesem Host nicht auf dieselbe Weise offen.

Akzeptieren Sie nicht das Argument, Weiterleitung sei sicher, weil der private Schlüssel auf dem Laptop bleibt. Eine Signiermöglichkeit kann ausreichen, um sich anderswo zu authentifizieren. Der Unterschied ist bei einem Einbruch entscheidend: Eine Datei zu schützen ist nicht dasselbe wie die Nutzung der Zugangsdaten zu begrenzen.

Der Genehmigungsbereich muss zum Bereich der Zugangsdaten passen

Eine Genehmigung, die einem neuen Prozess die Nutzung einer SSH-Zugangsdaten erlaubt, sollte deren Umgebung und den Prozess nennen, der sie angefordert hat. Eine Eingabeaufforderung mit nur ssh command requested verlangt von einem Menschen, aus zu wenigen Angaben zu viel abzuleiten.

Hier vermischen Teams oft zwei Kontrollen. Der Bereich der Zugangsdaten beantwortet, wo sich eine Identität authentifizieren kann. Der Genehmigungsbereich beantwortet, welcher laufende Prozess diese Identität verwenden darf. Sie brauchen beides. Getrennte Produktionszugangsdaten verhindern, dass ein Entwicklungsprozess versehentlich die Produktion erreicht. Eine Prozessgenehmigung verhindert, dass ein unbekannter lokaler Prozess eine verfügbare Produktionszugangsdaten verwendet.

Genehmigung für jeden einzelnen Befehl klingt sicherer. Nach einem unangenehmen Vorfall wird sie häufig gefordert. Im normalen Betrieb scheitert sie meist, weil wiederholte Aufforderungen Bediener dazu bringen, ohne Lesen zu bestätigen. Reservieren Sie die Bestätigung pro Nutzung für Zugangsdaten, deren Verwendung selbst eine menschliche Entscheidung erfordert, etwa eine besonders wirkungsvolle Produktionsidentität. Geben Sie der normalen Arbeit eine Sitzungsautorisierung, die mit dem Prozess endet, und halten Sie den serverseitigen Bereich der Zugangsdaten eng.

Sallyport bewahrt SSH-Zugangsdaten in seinem verschlüsselten Tresor auf und kann eine Genehmigung für einen neuen Agent-Prozess oder eine Bestätigung bei jeder Nutzung einer ausgewählten Zugangsdaten verlangen. Das ersetzt keine getrennte Serverautorisierung, macht die Prozessgrenze aber sichtbar, ohne die Zugangsdaten dem Agenten zu übergeben.

Ein KI-Coding-Agent braucht eine strengere Trennung als ein interaktives Terminal, weil er schnell viele Befehle ausführen und einer falschen Anweisung folgen kann. Geben Sie ihm standardmäßig Entwicklungszugriff. Wenn er Staging benötigt, verwenden Sie eine reine Staging-Identität und einen gesondert genehmigten Lauf. Behandeln Sie Produktionszugriff als eigenen Vorgang mit benanntem Ziel und engem Zweck.

Der Fehler beginnt meist mit einer harmlosen Ausnahme

Nehmen wir ein Team mit einem einzigen ops-SSH-Schlüssel, der von Entwicklungs-, Staging- und Produktionshosts akzeptiert wird. Ein Entwickler lädt diesen Schlüssel für ein Wartungsfenster in der Produktion in einen SSH-Agenten. Später öffnet ein lokaler Build-Helfer eine SSH-Verbindung zu einem Staging-Host, um Protokolle abzurufen.

Der Helfer hat keine ausdrückliche Einstellung für IdentityFile, und IdentitiesOnly fehlt. OpenSSH probiert Identitäten aus dem Agenten. Der gemeinsame ops-Schlüssel funktioniert, weil Staging ihn akzeptiert. Der Helfer besitzt nun eine Staging-Sitzung, die mit einer Identität authentifiziert wurde, die auch in der Produktion funktioniert.

Ein zweiter Fehler folgt. Auf dem Staging-Host ist Agent-Weiterleitung aktiviert, weil jemand im vergangenen Monat eine einmalige Verbindung benötigte. Ein Prozess auf diesem Host kann über den weitergeleiteten Agenten Signaturen anfordern. Er erreicht einen Produktionshost mit derselben ops-Identität. Der ursprüngliche Entwickler genehmigte eine Produktionswartung, doch ein unabhängiger Helfer und ein Staging-Host haben deren Berechtigung geerbt.

Für diese Abfolge ist kein gestohlener privater Schlüssel erforderlich. Der Entwurf erlaubte eine weitreichende Identität, der Client wählte sie opportunistisch und die Weiterleitung vergrößerte ihre Reichweite. Protokolle können durchgehend eine gültige Authentifizierung zeigen. Deshalb bezeichnen Teams das Problem fälschlich als Bedienfehler, statt das Zugriffsmodell zu reparieren.

Ein getrennter Entwurf unterbricht die Kette an mehreren Stellen. Der Helfer verwendet nur eine Staging-Zugangsdaten. Die Produktion weist diese Zugangsdaten zurück. Agent-Weiterleitung bleibt deaktiviert. Die Produktionsidentität ist nur für einen ausdrücklich genehmigten Produktionsprozess verfügbar. Jede einzelne Kontrolle hilft. Zusammen sorgen sie dafür, dass die falsche Verbindung früh scheitert.

Rotation und Notfallwiderruf brauchen eine eingeübte Reihenfolge

Rotation funktioniert, wenn Sie zuerst einen Ersatz hinzufügen, bevor Sie die alte Identität entfernen, anschließend den genauen Pfad prüfen und erst dann die alte Identität widerrufen. Produktionsrotationen scheitern, wenn jemand nur vom eigenen Laptop aus testet, während der echte Bereitsteller ein anderes Konto, Netzwerk oder einen anderen Automatisierungs-Runner verwendet.

Für eine normale Rotation gilt diese Reihenfolge:

1. Erstellen Sie eine Ersatz-Zugangsdaten im selben engen Bereich wie die alte.
2. Fügen Sie ihren öffentlichen Schlüssel oder die Zertifikatsautorisierung dem vorgesehenen Konto und den vorgesehenen Hosts hinzu.
3. Testen Sie den echten Befehl über den echten Prozesspfad, einschließlich eines möglichen Sprunghosts.
4. Entfernen Sie die alte Autorisierung und bestätigen Sie, dass die alte Zugangsdaten nun scheitert.
5. Halten Sie Fingerabdruck, Besitzer, Bereich und Entfernungstermin des Ersatzes im Zugriffsregister fest.

Halten Sie einen Notfallzugang bereit, machen Sie ihn aber nicht zu einem zweiten dauerhaften Administratorschlüssel, der auf jeden Arbeitsplatz kopiert wird. Bewahren Sie ihn getrennt auf, begrenzen Sie, wer ihn aktivieren darf, und testen Sie ihn unter kontrollierten Bedingungen. Ein Notfallprozess, den niemand ausprobiert hat, wird während eines Ausfalls zu hektischem Raten.

Ein Notfallwiderruf ist etwas anderes. Wenn eine Produktionszugangsdaten möglicherweise offengelegt wurde, entfernen Sie sofort ihren öffentlichen Schlüssel oder beenden Sie die Akzeptanz ihres Zertifikats und ersetzen Sie sie anschließend. Warten Sie nicht auf das geplante Rotationsfenster, denn ein Angreifer richtet sich nicht nach Ihrem Kalender. Der Nachteil ist eine mögliche Betriebsunterbrechung. Genau deshalb lohnen sich eng gefasste Zugangsdaten: Der Widerruf einer Produktions-Bereitstellungsidentität sollte die Entwicklungsarbeit nicht stoppen.

Testen Sie verweigerten Zugriff und lesen Sie die Belege

Die Zugriffstrennung ist erst abgeschlossen, wenn die falsche Zugangsdaten auf eine Weise scheitert, die Sie erklären können. Testen Sie nach jeder wichtigen Änderung einen absichtlichen Negativfall: Verwenden Sie die Entwicklungsidentität gegen einen Produktionshost und prüfen Sie, dass die Public-Key-Authentifizierung fehlschlägt. Testen Sie anschließend die erwartete Zugangsdaten und kontrollieren Sie Konto und Ziel in der Verbindungsaufzeichnung.

Verwenden Sie beim Testen eine ausführliche Client-Ausgabe, nicht dauerhaft:

ssh -vvv -o IdentitiesOnly=yes \\
  -i ~/.ssh/identities/id_ed25519_dev_alex \\
  [email protected]

Sie sollten sehen, dass der Client den öffentlichen Entwicklungsschlüssel anbietet und der Server ihn zurückweist. Kopieren Sie diese Ausgabe nicht ungeprüft in Tickets. Ausführliche SSH-Protokolle können Hostnamen, Benutzernamen und Authentifizierungsdetails offenlegen.

Serverprotokolle sollten Ihnen sagen können, wer sich authentifiziert hat, welches Konto verwendet wurde, welchen Fingerabdruck des öffentlichen Schlüssels der Server akzeptiert hat und woher die Verbindung kam. Wenn mehrere Personen oder Prozesse dieselbe Identität verwenden, kann das Protokoll die fehlende Zuordnung später nicht wiederherstellen.

Prüfen Sie auf schleichende Grenzverschiebungen: ein Entwicklungsschlüssel, der einem Produktionskonto hinzugefügt wurde, alte Bereitstellungszugangsdaten, die weiterhin akzeptiert werden, ein Produktionsschlüssel in einem allgemeinen Agenten oder eine Wildcard-Clientregel, die IdentitiesOnly überschreibt. Solche Änderungen werden häufig als vorübergehende Reparaturen eingeführt. Vorübergehender SSH-Zugriff bleibt gern lange nach dem Notfall bestehen, der ihn erforderlich gemacht hat.

Beginnen Sie damit, jeden auf Produktionshosts akzeptierten öffentlichen Schlüssel zu inventarisieren und nach Besitzer, Prozess, Zweck und Bereich zu beschriften. Jeder Eintrag, der diese vierteilige Beschreibung nicht erfüllt, sollte nicht autorisiert bleiben.