Dein Blog zum Thema digitales Business

Du hast wahrscheinlich noch mindestens einen klassischen Personal Access Token im Einsatz — in einem lokalen Git-Credential-Store, einer .netrc oder einem Skript, das eigentlich mit deinem Namen läuft. Angelegt mit dem Scope repo, weil das am schnellsten ging. Seitdem kann er auf jedes private Repository zugreifen, auf das du Zugriff hast — inklusive aller Repositories, die morgen zu deiner Organisation dazukommen. Das ist keine Fahrlässigkeit, das ist schlicht, wie klassische PATs funktionieren. Fine-grained Personal Access Tokens ändern genau das.

Dieser Artikel behandelt ausschließlich deinen eigenen Nutzertoken — den Zugriff, den du als Mensch mit deinem GitHub-Account ausübst. Nicht Bots, nicht Deploy-Prozesse, nicht installierte Drittanbieter-Apps. Dazu weiter unten mehr.

Was ein klassischer PAT tatsächlich freigibt

Ein Personal Access Token (classic) arbeitet mit Scopes — grob geschnittenen Berechtigungsblöcken wie repo, workflow oder admin:org. Klassische PATs nutzen laut GitHub dasselbe Scope-Modell wie OAuth-Apps, und der wichtigste, am häufigsten vergebene Scope repo ist dort so definiert:

„Grants full access to public and private repositories including read and write access to code, commit statuses, repository invitations, collaborators, deployment statuses, and repository webhooks. In addition to repository related resources, the repo scope also grants access to manage organization-owned resources including projects, invitations, team memberships and webhooks.“ (Scopes for OAuth apps)

Ein einziges Scope-Häkchen gibt also Lese- und Schreibzugriff auf jedes Repository, das dein Konto sehen kann — heute und in Zukunft. GitHub selbst beschreibt es so: Personal access tokens (classic) „will grant access to all repositories within the organizations that you have access to“ (Managing your personal access tokens).

Ein Ablaufdatum ist bei klassischen PATs nicht Pflicht. GitHub löscht sie zwar automatisch, wenn sie ein Jahr lang nicht benutzt wurden, aber ein aktiv genutzter Token ohne gesetztes Ablaufdatum lebt unbegrenzt weiter — mit vollem repo-Zugriff, bis jemand ihn manuell widerruft.

Was Fine-grained PATs stattdessen tun

Fine-grained Personal Access Tokens drehen dieses Modell um. Statt eines groben Scopes wählst du beim Anlegen erst den Ressourcen-Eigentümer (dein eigenes Konto oder eine Organisation) und dann den Repository-Zugriff — entweder auf ausgewählte Repositories beschränkt oder auf alle Repositories dieses Eigentümers: „Each token can be further limited to only access specific repositories“ (Managing your personal access tokens).

Innerhalb dieses Repository-Satzes vergibst du dann keine Scopes mehr, sondern einzelne Permissions pro Ressourcentyp — Contents, Issues, Pull Requests, Actions, Secrets und weitere: „Each token is granted specific, fine-grained permissions, which offer more control than the scopes“ (ebd.). Du kannst also Lesezugriff auf Issues geben, ohne dass der Token eine Zeile Code schreiben oder Repository-Einstellungen ändern kann. Für jeden REST-API-Endpunkt listet GitHub auf, welche Permission-Stufe — read, write oder bei administrativen Ressourcen admin — benötigt wird (Permissions required for fine-grained personal access tokens). Genau hier verhält sich ein Nutzertoken zum ersten Mal wie eine IAM-Policy statt wie ein Generalschlüssel: Du bestimmst pro Ressourcentyp, ob überhaupt und in welche Richtung Zugriff besteht — nicht mehr „alles oder nichts pro Repository-Satz“. Ausgenommen bleiben öffentliche Repositories: Ein Fine-grained-Token hat unabhängig von der Einschränkung immer Lesezugriff auf alle öffentlichen Repositories (Creating a personal access token).

Ablaufdatum: differenzierter als der erste Blick zeigt

Seit Oktober 2024 gilt: Fine-grained-Tokens, die nur auf deine eigenen, persönlichen Repositories zugreifen, dürfen unbegrenzte Laufzeiten haben. Für Fine-grained-Tokens mit Zugriff auf eine Organisation gilt das nicht automatisch — dort setzen Organisationen und Enterprises Rotationsrichtlinien mit einer maximalen Lebensdauer zwischen einem und 366 Tagen, mit 366 Tagen als Standardwert: Developers „still can’t create infinite lifetime fine-grained PATs for use against an organization“ they’re a member of, unless the administrator relaxes the policy (New PAT rotation policies preview and optional expiration for fine-grained PATs, GitHub Changelog). Sobald ein Fine-grained-Token also Organisationsressourcen berührt, erzwingt die Organisation faktisch einen Rotationsrhythmus — ein Kompromittierungsfenster, das bei einem unbefristeten klassischen repo-Token schlicht nicht existiert.

Owner-Approval: die Organisation bekommt ein Vetorecht

Der vielleicht wichtigste IAM-Baustein ist die Freigabepflicht: „Organization owners can require approval for any fine-grained personal access tokens that can access resources in the organization“ (Managing your personal access tokens). Bis zur Freigabe bleibt der Token im Status pending und kann in dieser Zeit nur öffentliche Ressourcen lesen (Creating a personal access token). Das ist der Unterschied zwischen „ein Entwickler entscheidet selbst, was sein Token darf“ und „die Organisation sieht jede beantragte Berechtigung, bevor sie wirksam wird“ — die Kontrollinstanz, die man von einem IAM-System erwartet und die bei klassischen PATs schlicht fehlt.

Least Privilege ist damit näher, nicht automatisch erreicht

Fine-grained PATs machen „least privilege“ für menschliche Nutzerkonten aus drei Gründen praktikabler: Ein kompromittierter Token betrifft nur die Repositories, die er explizit bekommen hat, statt automatisch jedes Repository, das dein Account sehen kann. Du kannst „read Issues“ von „write Contents“ trennen, wo ein klassischer repo-Scope beides in einem Paket liefert. Und die Owner-Approval verhindert, dass ein einzelner Nutzer sich unbemerkt breite Organisationszugriffe selbst ausstellt.

Was das Werkzeug nicht automatisch löst: Ein Token mit Zugriff auf „Alle Repositories“ eines Eigentümers und Schreibrecht auf zehn Ressourcentypen ist granular möglich, aber genauso breit wie ein klassischer Token, wenn du es so konfigurierst. Fine-grained PATs erzwingen keine sparsame Nutzung — sie machen sie zum ersten Mal realistisch umsetzbar.

Praxisbeispiel

Ein Entwickler braucht für ein lokales Skript nur Lesezugriff auf die Issues eines einzelnen Repositories, um sie in ein internes Reporting zu ziehen. Mit einem klassischen PAT bleibt dafür nur der Scope repo — voller Lese-/Schreibzugriff auf Code, Deployment-Status und Collaborator-Verwaltung in jedem Repository der Organisation, nur damit das Skript Issues lesen kann. Mit einem Fine-grained PAT wählt er das eine Repository aus, setzt bei „Issues“ die Permission auf „Read-only“ und lässt alle anderen Ressourcentypen auf „No access“. Ein Leak dieses Tokens gibt einem Angreifer dann Leserechte auf Issues eines Repositories — nicht Schreibzugriff auf den gesamten Repository-Bestand der Organisation.

Abgrenzung: worum es hier nicht geht

Dieser Artikel behandelt bewusst nur den Token, den ein Mensch für sein eigenes GitHub-Nutzerkonto anlegt. Vier verwandte Themen bleiben hier ausdrücklich außen vor:

Bei Maschinenidentitäten — einem Dienst oder einer Pipeline, die dauerhaft und unabhängig von einem einzelnen Menschen agieren soll — ist ein persönlicher Token grundsätzlich das falsche Werkzeug, egal wie granular er geschnitten ist: Ein PAT bleibt an ein Nutzerkonto gebunden, während ein Dienstkonto oder eine GitHub App als eigenständige Identität auftritt und unabhängig von einem Menschen handeln kann (Differences between GitHub Apps and OAuth apps). Das ist das Thema von Service-Accounts und Bot-Tokens.

Genauso wenig ersetzt ein Fine-grained PAT einen Deploy Key: Ein Deploy Key ist „an SSH key that grants access to a single repository“ (Managing deploy keys) und hängt am Repository selbst statt an einem Nutzerkonto — richtig für einen einzelnen Server oder CI-Job, nicht für einen Menschen mit Zugriff auf mehrere Repositories. GitHub Apps lösen dasselbe Problem für komplexere Automatisierungen. Beides ist Maschinenzugang und Thema des Artikels Deploy Keys oder GitHub Apps: welcher Maschinenzugang wofür, nicht dieses.

Die granulare Permission eines Fine-grained-Tokens ist außerdem nicht dasselbe wie die effektiven Rechte, die ein Nutzer über seine Team-Mitgliedschaft in einer Organisation erbt: Dort geht es um die Repository-Rolle durch Teamzugehörigkeit — eine Frage der Organisationsstruktur, nicht der Token-Konfiguration. Ein Token hat ohnehin „the same capabilities to access resources and perform actions on those resources that the owner of the token has, and is further limited by any scopes or permissions granted to the token“ (Managing your personal access tokens) — ein Fine-grained PAT engt bestehende Rechte ein, er erweitert sie nicht.

Und schließlich: Wenn du einer Drittanbieter-Anwendung per OAuth erlaubst, sich mit deinem GitHub-Konto zu verbinden — etwa einem CI-Dienst oder einem Projektmanagement-Tool —, bewegst du dich im Bereich der OAuth-Scopes installierter Apps. Das ist ein separater Autorisierungsmechanismus mit eigenem Freigabe-Dialog, nicht die Verwaltung deiner eigenen Tokens in den Developer Settings deines Accounts.

Was du konkret prüfen solltest

Schau dir deine aktiven Tokens unter GitHub-Kontoeinstellungen an. Prüfe für jeden klassischen PAT, ob der tatsächliche Verwendungszweck wirklich organisationsweiten repo-Zugriff braucht — oder ob ein Fine-grained-Token mit einem einzigen Repository und zwei, drei granularen Permissions denselben Zweck erfüllt. Bei jedem Token mit Organisationszugriff lohnt zusätzlich die Frage, ob eure Organisation Owner-Approval für Fine-grained PATs bereits aktiviert hat.

Wenn du prüfen willst, wo in eurer Umgebung noch klassische Tokens mit unnötig breitem Zugriff im Einsatz sind, oder wie sich Owner-Approval und Rotationsrichtlinien für eure Organisation sinnvoll konfigurieren lassen, schreib an mm@mhm-dl.de.