Dein Blog zum Thema digitales Business

Wenn ein Mensch das Unternehmen verlässt, wird sein Zugang entzogen. Das ist Routine. Es gibt aber Zugänge, die niemandem gehören und trotzdem alles dürfen: Service-Accounts und Bot-Tokens. Sie deployen, öffnen Pull Requests, schreiben in Repositories und laufen oft seit Jahren durch. Kein Offboarding erfasst sie, kein Passwortwechsel betrifft sie. Genau deshalb sind sie ein blinder Fleck.

Was ein Service-Account wirklich ist

Ein Service-Account ist ein technischer Nutzer, der keine Person hinter sich hat. In GitHub taucht er in mehreren Formen auf: als eigener Maschinen-Account mit Personal Access Token, als Deploy Key an einem Repository, als CI-Token in der Pipeline oder als GitHub-App-Installation. Allen gemeinsam ist, dass sie Rechte tragen, ohne dass ein Name daran hängt, der beim Ausscheiden geprüft wird. Der Zugang lebt weiter, solange das Token gültig ist. Und gültig heißt bei vielen Personal Access Tokens: bis jemand es aktiv widerruft.

Warum sie beim Offboarding durchrutschen

Offboarding-Listen prüfen Menschen. Wer geht, verliert Zugriff. Ein Service-Account steht auf keiner dieser Listen, weil er kein Mitarbeiter ist. Häufig hat aber genau eine Person das Token erzeugt und in einem CI-System hinterlegt. Diese Person geht, das Token bleibt. Niemand weiß mehr, wofür es gebraucht wird, also fasst es niemand an. So sammeln sich über die Jahre Zugänge an, die aktiv sind, breit berechtigt und ohne bekannten Zweck. Ein Angreifer, der einen solchen Token findet, hat einen Generalschlüssel ohne Ablaufdatum.

Drei Schwachstellen, die fast immer auftauchen

Der erste Punkt sind zu weite Rechte. Ein Token, das nur ein Repository bauen soll, hat oft Schreibrechte auf die ganze Organisation, weil das beim Einrichten am schnellsten ging. Der zweite Punkt ist das fehlende Ablaufdatum. Klassische Personal Access Tokens konnten unbegrenzt gültig sein, und viele im Umlauf sind es bis heute. Der dritte Punkt ist die fehlende Zuständigkeit. Steht kein Eigentümer fest, entscheidet niemand über Rotation, Prüfung oder Abschaltung. Ein Zugang ohne Eigentümer wird nie widerrufen, weil sich niemand verantwortlich fühlt.

Inventar zuerst, dann Regeln

Bevor man Regeln aufstellt, braucht man die Liste. Welche Maschinen-Accounts existieren, welche Personal Access Tokens sind aktiv, welche Deploy Keys hängen an welchen Repositories, welche GitHub Apps sind installiert. GitHub liefert diese Informationen über die Organisations-Einstellungen und die API, etwa die Liste der Personal Access Tokens mit Zugriff auf die Organisation und die installierten Apps mit ihren Berechtigungen. Aus dieser Liste ergibt sich sofort die erste Arbeit: Zugänge ohne erkennbaren Zweck abschalten, zu weite Rechte einschränken, jedem verbleibenden Zugang einen Eigentümer geben.

GitHub Apps statt Personal Access Token

Wo es geht, ersetzt eine GitHub App den Maschinen-Account mit Token. Eine App bekommt fein abgestufte Berechtigungen, ihre Zugriffs-Tokens sind kurzlebig und werden automatisch erneuert, und sie hängt nicht an einer einzelnen Person. Für Deployments aus GitHub Actions heraus ist OIDC die noch sauberere Variante, weil dann gar kein statisches Secret gespeichert wird. Das Ziel ist in allen Fällen dasselbe: kein dauerhaft gültiges Geheimnis, das jahrelang unbemerkt in einem CI-System liegt.

Wer nicht weiß, welche technischen Zugänge in der eigenen Organisation aktiv sind, hat die Kontrolle schon abgegeben. Ein Inventar ist der erste Schritt, und es ist kein großes Projekt, sondern eine Stunde Arbeit an der richtigen Stelle.

GitSecOps QuickCheck: Wir prüfen Ihre GitHub-Organisation und Pipeline auf stille Dauer-Zugänge, zu weite Rechte und fehlende Rotation. Ergebnis in 3 Werktagen, 1.990 Euro netto. Kontakt: mm@crank.zone.