Dein Blog zum Thema digitales Business

Jemand verlässt das Team. Der Laptop wird eingezogen, das Postfach deaktiviert, der Chat-Zugang gesperrt. Und der GitHub-Zugang? Der bleibt in vielen Firmen noch Wochen bestehen, weil niemand genau weiß, woran er überall hängt. Genau in dieser Lücke entsteht das Risiko. Ein ehemaliger Entwickler mit weiter gültigem Token liest still den gesamten Quellcode, oder schlimmer, er kann noch pushen.

Warum GitHub-Offboarding besonders leicht durchrutscht

Zugang in GitHub kommt aus mehreren Quellen gleichzeitig. Eine Person kann direkt auf einzelnen Repos berechtigt sein, über Team-Mitgliedschaften erben, eine Organisationsrolle tragen, persönliche Access Tokens angelegt haben, eigene SSH- und GPG-Schlüssel hinterlegt haben und OAuth-Apps autorisiert haben. Wer nur das zentrale SSO deaktiviert, hat oft nur die Vordertür geschlossen. Persönliche Tokens und Deploy-Keys funktionieren je nach Konfiguration weiter, weil sie nicht am SSO-Login hängen.

Was tatsächlich entzogen werden muss

• Organisationsmitgliedschaft und alle Team-Mitgliedschaften
• Direkte Repo-Zugänge als Outside Collaborator
• Persönliche Access Tokens, klassisch und fine-grained
• Hinterlegte SSH- und GPG-Schlüssel
• Deploy-Keys, die die Person in Repos angelegt hat
• Von der Person autorisierte OAuth- und GitHub-Apps
• Zugang zu self-hosted Runnern und deren Maschinen
• Secrets, die die Person kannte und die weiter gültig sind

Der Reihenfolge-Fehler

SSO deaktivieren heißt nicht Zugang weg. Wer zuerst die Mitgliedschaft entfernt und danach in Ruhe die Tokens sucht, gibt der Person ein Zeitfenster, in dem einzelne Tokens noch greifen. Sinnvoller ist die andere Reihenfolge. Erst alle persönlichen Tokens und Schlüssel widerrufen, dann die Mitgliedschaften entfernen, dann die Secrets rotieren, die im Umfeld der Person lagen. Zum Thema Rotation lohnt der Blick auf den Beitrag zu Pipeline-Secrets rotieren.

Was bleibt, wenn man nichts tut

Der offensichtliche Fall ist der weiter gültige Token. Der stille Fall ist alles, was die Person mitgenommen hat, bevor sie ging. Lokale Klone des gesamten Repos liegen auf dem privaten Rechner. Secrets, die einmal in der Historie standen, sind ausgelesen. Ein einzelner nicht widerrufener Deploy-Key auf einem alten Repo reicht, um Monate später wieder hineinzukommen. Deshalb ist Offboarding nie nur ein Häkchen im Personalsystem, sondern eine technische Aufräumaktion.

Die Checkliste

1. Persönliche Access Tokens der Person prüfen und, wo möglich als Admin, invalidieren
2. SSH- und GPG-Schlüssel der Person aus den relevanten Konten und Repos entfernen
3. Deploy-Keys in allen Repos durchgehen und die von der Person angelegten löschen
4. OAuth- und GitHub-App-Autorisierungen der Person entziehen
5. Person aus allen Teams und aus der Organisation entfernen
6. Outside-Collaborator-Einträge auf einzelnen Repos prüfen
7. Secrets rotieren, die die Person kannte, vor allem lang laufende Deploy-Credentials
8. Im Organisations-Audit-Log kontrollieren, dass die Entfernung protokolliert ist

Nachweis, dass es passiert ist

Der Satz „wir haben den Zugang entzogen“ ist ohne Beleg nur eine Behauptung. Das Organisations-Audit-Log zeigt, wann eine Mitgliedschaft entfernt und wann ein Token widerrufen wurde. Wer regelmäßig offboardet, sollte die Checkliste mit den effektiven Rechten der Person abgleichen. Warum nominale und tatsächliche Rechte auseinanderlaufen, steht im Beitrag zu effektiven versus nominalen Rechten. Und wer Offboarding nicht bei jedem Austritt einzeln neu erfinden will, macht es Teil der regelmäßigen Berechtigungs-Reviews.

Sie wissen nicht sicher, wer in Ihren Repos noch Zugang hat und was ein ausgeschiedener Mitarbeiter theoretisch noch könnte? Der GitSecOps QuickCheck sieht sich Ihre Pipeline und Ihre Zugänge an und liefert in drei Werktagen einen konkreten Befund. 1.990 Euro netto. Kontakt: mm@crank.zone.