Dein Blog zum Thema digitales Business

In den meisten GitHub-Organisationen kennt niemand mehr die vollständige Antwort auf eine einfache Frage: Wer hat gerade Zugriff worauf, und warum. Rechte werden vergeben, wenn jemand sie braucht. Zurückgenommen werden sie fast nie. Das Ergebnis ist ein stiller Rechte-Berg, der mit jedem Onboarding, jedem Projekt und jedem externen Dienstleister weiter wächst.

Rechte wachsen, aber niemand nimmt sie zurück

Der Mechanismus ist immer gleich. Ein Entwickler braucht kurz Admin-Rechte auf ein Repository, um eine Einstellung zu ändern. Ein externer Freelancer bekommt Zugriff auf drei Repos, arbeitet zwei Monate mit und bleibt danach als Mitglied bestehen. Ein Team wird umstrukturiert, aber die alten Team-Zuordnungen laufen weiter. Keiner dieser Schritte ist für sich genommen falsch. In Summe entsteht daraus eine Organisation, in der deutlich mehr Menschen deutlich mehr dürfen, als es der aktuelle Stand der Arbeit rechtfertigt.

Das Problem ist nicht theoretisch. Jeder Account mit Schreibrechten ist ein möglicher Einstiegspunkt. Wird ein Zugang übernommen, entscheidet nicht die Absicht des ursprünglichen Inhabers über den Schaden, sondern der Umfang der Rechte, die an diesem Zugang hängen. Ein kompromittierter Account mit Owner-Rechten auf die gesamte Organisation ist eine andere Größenordnung als einer mit Leserechten auf ein einzelnes Repo.

Was ein Berechtigungs-Review konkret prüft

Ein Review ist kein einmaliges Aufräumen, sondern ein wiederkehrender Abgleich zwischen vergebenen Rechten und tatsächlichem Bedarf. Vier Ebenen sind dabei relevant.

• Organisations-Owner: Wer hat Owner-Status auf die gesamte Organisation. Diese Rolle sollte auf wenige Personen begrenzt sein, nicht auf jeden, der einmal etwas einrichten musste.
• Team-Zuordnungen: Welche Teams existieren, wer ist Mitglied, und welche Repo-Rechte hängen am Team. Verwaiste Teams und Mehrfachmitgliedschaften sammeln sich hier.
• Direkte Repo-Rechte: Zugriffe, die an einzelnen Personen statt an Teams hängen. Sie sind schwer zu überblicken, weil sie in keiner zentralen Struktur auftauchen.
• Externe Mitarbeiter und Bots: Outside Collaborators, Service-Accounts und Machine-User. Gerade diese laufen oft lange nach Projektende weiter.

Die typischen Fundstellen

Wer zum ersten Mal systematisch prüft, findet fast immer dieselben Muster. Ehemalige Mitarbeiter, deren Zugang nie entzogen wurde. Externe, die vor Monaten fertig waren und trotzdem noch Schreibrechte halten. Personen mit Admin-Rechten, die nie ein Repository verwalten, sondern nur Code beitragen. Und Service-Accounts, deren Zweck niemand mehr benennen kann, deren Token aber noch aktiv sind.

Ein zweiter Klassiker sind Rechte, die über Teams vererbt werden, ohne dass es jemand bewusst so entschieden hat. Ein Nutzer ist Mitglied in einem Team, das Team hat Admin auf zwanzig Repos, und plötzlich hat auch dieser Nutzer Admin auf zwanzig Repos. Sichtbar wird das erst, wenn man die effektiven Rechte pro Person durchrechnet, nicht die nominalen.

Wie oft und wie man es macht

Ein Review pro Quartal ist für die meisten Organisationen ein sinnvoller Takt. Wichtiger als die Frequenz ist, dass er nachvollziehbar dokumentiert wird: Wer hat geprüft, was wurde entzogen, was wurde bewusst belassen und aus welchem Grund. Genau diese Dokumentation ist es, die aus einem Aufräumen eine Kontrolle macht, die vor einem Prüfer trägt.

Die GitHub-API liefert die Rohdaten dafür: Mitglieder, Teams, Repo-Berechtigungen und Outside Collaborators lassen sich vollständig auslesen. Der Aufwand liegt nicht im Abfragen, sondern im Interpretieren. Ein Skript, das die effektiven Rechte pro Person aufbereitet und mit einer Soll-Liste vergleicht, ersetzt Stunden manueller Klickarbeit im Admin-Interface.

Rechte prüfen, bevor es jemand anders tut

Ein sauberer Berechtigungsstand ist keine Fleißaufgabe, sondern eine Sicherheitskontrolle. Der GitSecOps QuickCheck nimmt Ihre GitHub-Organisation und Ihre Pipelines auf reale Schwachstellen unter die Lupe, Berechtigungen inklusive: 1.990 Euro netto, Ergebnis in 3 Werktagen. Kontakt: mm@crank.zone.