In der GitHub-Oberfläche steht neben jedem Team eine Rolle: Read, Write, Admin. Das ist die nominale Zuweisung, also das, was jemand laut Konfiguration bekommen soll. Was eine einzelne Person am Ende tatsächlich darf, steht dort nicht. Effektive Rechte entstehen aus mehreren Quellen gleichzeitig, und bei Konflikten gewinnt immer die höchste. Wer nur auf die Team-Liste schaut, sieht die Absicht, nicht den Zustand.
Vier Wege zum selben Repository
Zugriff auf ein Repository kann über mehrere unabhängige Kanäle entstehen, und die meisten Organisationen nutzen mehr als einen davon gleichzeitig.
- Basisberechtigung der Organisation. Eine Einstellung, die für jedes Mitglied auf jedes Repository der Organisation wirkt.
- Team-Mitgliedschaft. Entweder direkt vergeben oder von einem Elternteam geerbt.
- Direkte Einladung als Collaborator. Auf Repo-Ebene, oft schnell für einen Einzelfall vergeben und nie zurückgenommen.
- Organisation-Owner. Übersteuert alles darunter, auf jedem Repository.
Dazu kommen technische Identitäten: GitHub Apps mit eigenen Berechtigungen, Deploy-Keys, Personal Access Tokens. Jeder Kanal ist für sich harmlos und nachvollziehbar. Die Summe ist es selten. Entscheidend ist die Rechenregel: Wenn mehrere Wege auf dasselbe Repository führen, gilt die höchste Stufe. Nicht die zuletzt gesetzte, und schon gar nicht die niedrigste.
Wie Team-Vererbung wirklich läuft
GitHub erlaubt verschachtelte Teams. Ein Kindteam erbt die Zugriffsrechte seines Elternteams. Das GitHub-eigene Beispiel dafür ist eine Hierarchie wie Employees über Engineering über Application Engineering über Identity. Gibt man Engineering Schreibzugriff auf ein Repository, haben Application Engineering und Identity diesen Schreibzugriff ebenfalls, ohne dass ihn jemand dort eingetragen hat.
Die Vererbung läuft nach unten, und genau da entsteht die Überraschung. Man nimmt jemanden in ein kleines Spezialteam ganz unten in der Hierarchie auf und hält das für eine eng begrenzte Vergabe. Tatsächlich bekommt diese Person alles, was jedes Team über ihr besitzt. Je tiefer das Team in der Struktur hängt, desto größer die Erbmasse.
Ein zweiter Stolperstein steckt in der Oberfläche selbst: Mitglieder eines Kindteams erscheinen auf der Members-Seite des Elternteams, sind aber keine direkten Mitglieder davon. Wer diese Liste als Beleg für eine Team-Zuordnung exportiert, zieht falsche Schlüsse. Und ein geerbtes Recht lässt sich im Kindteam nicht korrigieren. Man muss ans Elternteam, was in der Praxis bedeutet: Die Korrektur trifft alle anderen Kindteams mit.
Die Basisberechtigung ist der stille Verstärker
Die Basisberechtigung einer Organisation wird einmal beim Aufsetzen gewählt und danach oft nie wieder angefasst. Steht sie auf Write, hat jedes Mitglied Schreibrechte auf jedes Repository, ganz ohne Team, ganz ohne Einladung. Die sorgfältig gebaute Team-Struktur darüber ist dann Kosmetik.
Wichtig ist die Richtung: Eine höhere Zuweisung über Team oder Collaborator-Status übersteuert die Basis. Umgekehrt funktioniert es nicht. Ein Team mit Read-Recht auf ein Repository senkt eine Basisberechtigung Write nicht ab. Rechte lassen sich in GitHub addieren, aber nicht durch eine engere Zuweisung wieder einschränken.
Wie man effektive Rechte prüft
Für Einzelfälle reicht die Oberfläche. Unter Settings, Collaborators und Teams zeigt GitHub eine Warnung mit dem Hinweis Mixed roles neben Personen mit widersprüchlichem Zugriff. Ein Klick darauf zeigt, woher die Rechte jeweils stammen.
Für eine ganze Organisation ist das nutzlos. Vierzig Repositories mal dreißig Personen sind zwölfhundert Einzelprüfungen, die niemand macht. Der belastbare Weg führt über die API: Der Endpunkt für die Berechtigung eines Collaborators auf einem Repository liefert die effektive Stufe zurück, also das Ergebnis nach allen Vererbungs- und Übersteuerungsregeln. Repositories durchlaufen, effektive Rechte pro Person abfragen, gegen die Soll-Liste halten. Das ist ein Skript von überschaubarer Größe und der einzige Weg zu einer Aussage, die vor einem Prüfer trägt.
Das ergänzt den Blick auf den Prozess, den wir in Berechtigungs-Reviews in GitHub-Organisationen beschrieben haben. Ein Review ohne effektive Rechte prüft die Absicht, nicht die Realität.
Was das praktisch heißt
Drei Punkte bleiben hängen. Erstens: Nominale Rechte sind eine Absichtserklärung, effektive Rechte sind der Zustand. Nur der Zustand ist auditierbar. Zweitens: Teams verschachtelt man erst, nachdem die bestehenden Rechte geprüft sind. GitHub empfiehlt das in der eigenen Dokumentation und aus gutem Grund. Ein Elternteam sollte nur Rechte haben, die für jedes Mitglied jedes Kindteams darunter vertretbar sind. Drittens: Bei einem Audit exportiert man nicht die Team-Liste, sondern die effektive Berechtigung pro Repository und Person.
Der Aufwand dafür ist gering. Der Aufwand, nach einem Vorfall zu rekonstruieren, wer zum fraglichen Zeitpunkt Schreibrechte auf das betroffene Repository hatte, ist es nicht.
Wenn ihr nicht sicher sagen könnt, wer heute auf welches Repository schreiben darf, könnt ihr auch nicht belegen, dass ein Artefakt aus einer kontrollierten Quelle stammt. Der GitSecOps QuickCheck schaut sich genau das an: effektive Berechtigungen, Pipeline-Konfiguration, Secrets und Freigabewege in eurer GitHub-Organisation. Ergebnis nach drei Werktagen, Festpreis 1.990 Euro netto, konkrete Befunde statt Scanner-Dump. Kontakt: mm@crank.zone.
Dein Blog zum Thema digitales Business 