Der Produktions-VPS ruft das Repository über einen Bereitstellungsschlüssel ab – gut. Allerdings wurde es auf dem Laptop des technischen Direktors generiert, nach „/root/.ssh“ kopiert und für das Staging und die Produktion wiederverwendet. Wenn das Staging während eines anfälligen WordPress-Plugins kompromittiert wird, klont der Angreifer auch das private API-Repository – gleicher Schlüssel, Lesezugriff auf das gesamte angehängte Monorepo.
Bereitstellungsschlüssel sind der Pass zwischen Ihrem Host und Git. Schlecht geschnitten verwandeln sie einen Anwendungsvorfall in ein Leck an geistigem Eigentum.
Schlüssel-SSH bereitstellen: Mindestumfang
Auf GitHub oder GitLab: Schlüssel pro Repository bereitstellen, schreibgeschützt für einen Server, der nur den Code abruft.
| Ansatz | Vorteil | Risiko |
|---|---|---|
| Schlüssel schreibgeschützt bereitstellen | Eingeschränkter Zugriff auf ein Repository | Doppelter Schlüssel für mehrere Umgebungen |
| PAT-Maschinenbenutzer | Rich-API | Zielfernrohr zu weit, keine Rotation |
| OAuth-App | Zentralisiert | Komplexität, Prüfung |
Erstellen Sie einen Linux-Benutzer „deploy“ ohne Shell-Anmeldung (/usr/sbin/nologin), mit „ForceCommand“, wenn Sie sich auf Git-Shell beschränken müssen.
Ein Schlüssel auf dem Produktionsserver ist genauso viel wert wie dieser Server – behandeln Sie ihn als Geheimnis der obersten Ebene.
CI vs. Laufzeit: zwei unterschiedliche Identitäten
Die CI-Pipeline (GitHub Actions, GitLab CI) verwendet ein Token mit „read_repository“-Bereichen oder einen Bereitstellungsschlüssel write nur, wenn Sie Tags und Releases automatisieren – niemals mit Administratorrechten für die Organisation.
Der Produktionsserver ruft einfach den Code ab. Das CI erstellt und pusht das Artefakt (Bild, Archiv); Der Server klont nicht unbedingt bei jeder Bereitstellung, wenn Sie unveränderliche Images bereitstellen.
Durch die Trennung von Build-IDs und Bereitstellungs-IDs wird die Angriffskette eingeschränkt.
Rotation, Prüfung und Inventarisierung
Führen Sie eine Aufzeichnung: Schlüssel → Repository → Umgebung → Erstellungsdatum → nächste Rotation. Automatisieren Sie eine 90-Tage-Benachrichtigung.
Typisches Verfahren: Generieren Sie ein neues ed25519-Paar, fügen Sie den öffentlichen Schlüssel in kurzer Koexistenz zum Git-Host hinzu, validieren Sie die Bereitstellung beim Staging und dann bei der Produktion, widerrufen Sie den alten. Nach Vorfall: Sofort aufheben, nicht „nächsten Montag“.
Alternative Hosts und Git-Zugriff
Bei Shared ohne SSH-Git: Bereitstellung über FTP oder Rsync vom CI – kein Langzeitschlüssel bei Shared Hosting. Auf VPS und Bare Metal: Schlüsselstandard bereitstellen.
Einige PaaS-Plattformen (Clever Cloud usw.) verwenden Webhooks – kein Schlüssel auf dem Computer; Prüfen Sie, wer einen Einsatz auslösen kann.
Häufige Fehler
Privater Schlüssel, der an das Repository übergeben wird – Git-Verlauf scannen. „StrictHostKeyChecking no“ erleichtert MITM-Angriffe: Pin „known_hosts“. Privates Submodul ohne dedizierten Bereitstellungsschlüssel: Der übergeordnete Klon ist erfolgreich, das Submodul schlägt fehl oder erzwingt einen zu großen Schlüssel. Persönlicher Token des Leads in CI und auf dem Server wiederverwendet: Ein einziges Leck gefährdet Build und Produktion.
Oben: schreibgeschützt, was zu viel liest
Automatisierung ohne Blockierung bedeutet kurze Maschinenidentitäten, minimalen Umfang, dokumentierte Rotation – kein unsterblicher Schlüssel im Root.
Entscheide dich und gehe ohne blinden Fleck voran
Erstellen Sie einen Bereitstellungsschlüssel pro Repository und pro Umgebung, einen dedizierten „Bereitstellungs“-Benutzer, separate CI-Kennungen, eine vierteljährliche Rotation und eine Prüfung von „bekannten_Hosts“. Vergleichen Sie VPS und PaaS mit sicherer Bereitstellung über das Verzeichnis und den Vergleicher. Die Anleitungen beschreiben die Pipelines im Detail.
Führen Sie eine sofortige Prüfung durch: Listen Sie aktive Git-Schlüssel und zugängliche Repositorys auf – entfernen Sie verwaiste.
Häufig gestellte Fragen
Schlüssel oder CI-Token bereitstellen?
Stellen Sie den Schlüssel pro Repository schreibgeschützt für den Server bereit, der den Code abruft. CI-Token mit minimalen Bereichen für API-Aufrufe.
Warum das Schreiben auf einen Bereitstellungsschlüssel verbieten?
Ein kompromittierter Server mit Schreibrechten legt die Lieferkette offen; Reserve-Pull-only in der Produktion.
Wie kann man rotieren, ohne die Produktion zu unterbrechen?
Kurze Koexistenz zweier Schlüssel, Validierung beim Staging, dann Widerruf des alten Schlüssels.
Nur ein Git-Benutzer auf dem Server freigegeben?
Anti-Pattern – bevorzugen Sie einen dedizierten Bereitstellungsbenutzer und einen Schlüssel pro Umgebung.
Ein sauberer Bereitstellungsschlüssel kann nur ein Repository klonen – nicht Ihr Morgen nach der Kompromittierung.