Dein Blog zum Thema digitales Business

Die meisten CI/CD-Pipelines laufen mit weit mehr Rechten, als sie für ihre Arbeit brauchen. Ein Job, der nur Tests ausführt, hat plötzlich Schreibzugriff auf das Repository, kann Releases anlegen und liest jedes Secret im Projekt. Niemand hat das so geplant. Es ist über die Zeit gewachsen, weil ein breiter Token einfacher war als ein passgenauer. Genau hier setzt Least Privilege an: Jeder Schritt bekommt nur die Rechte, die er wirklich benötigt, und keins mehr.

Warum zu viele Rechte ein konkretes Risiko sind

Eine Pipeline ist ein attraktives Ziel, weil sie an einer Stelle Zugriff auf alles hat: Quellcode, Build-Artefakte, Deployment-Umgebungen und Zugangsdaten. Wenn ein Schritt kompromittiert wird, etwa durch eine manipulierte Abhängigkeit oder einen Pull Request von außen, erbt der Angreifer genau die Rechte dieses Schritts. Hat der Job breite Schreibrechte und Zugriff auf Produktions-Secrets, ist der Schaden groß. Läuft derselbe Job mit minimalen Leserechten, bleibt der Schaden begrenzt. Der Unterschied liegt nicht im Angriff, sondern in der Vorbereitung.

Wo überflüssige Rechte typischerweise stecken

In GitHub Actions ist der häufigste Fall der voreingestellte Token mit weitreichenden Berechtigungen. Ohne explizite Begrenzung bekommt jeder Workflow Schreibzugriff auf Inhalte, Issues und Pull Requests, obwohl die meisten Jobs nur lesen müssen. Dazu kommen Service-Accounts, die einmal für ein Deployment angelegt wurden und seitdem in jeder Pipeline mitlaufen, sowie Cloud-Rollen, die zur Sicherheit lieber etwas mehr durften. Auch Secrets sind oft global verfügbar, statt an die Umgebung gebunden zu sein, in der sie gebraucht werden.

Der Standardweg: Rechte explizit setzen

Der erste Schritt kostet wenig und wirkt sofort. In GitHub Actions setzt man die Berechtigungen des Tokens am Anfang des Workflows oder pro Job explizit. Ein guter Ausgangspunkt ist permissions: contents: read auf Workflow-Ebene. Jeder Job, der mehr braucht, etwa Schreibzugriff für ein Release oder einen Kommentar an einem Pull Request, hebt sich dieses eine Recht gezielt an. So fällt sofort auf, welcher Schritt wirklich schreibt und welcher nur mitliest.

Für die Cloud gilt dasselbe Prinzip. Statt einer breiten Rolle, die alles in einem Konto darf, bekommt jede Pipeline eine eigene Rolle mit einer eng gefassten Policy. Deploys in die Produktion und Deploys in die Testumgebung nutzen getrennte Identitäten. Wer dazu OIDC statt langlebiger Zugangsschlüssel einsetzt, entfernt die gespeicherten Secrets gleich mit.

Vom Aufräumen zur Kontrolle

Least Privilege ist kein einmaliges Projekt, sondern ein Zustand, den man halten muss. Rechte wachsen sonst wieder zurück, weil ein schneller Fix einfacher ist als die saubere Lösung. Drei Gewohnheiten helfen:

• Berechtigungen stehen sichtbar im Workflow, nicht in einer separaten Einstellung, die niemand prüft.
• Neue Rechte werden im Code Review begründet, genau wie jede andere Änderung auch.
• In regelmäßigen Abständen wird geprüft, welche Tokens und Rollen noch genutzt werden und welche stillgelegt werden können.

Das Ergebnis ist eine Pipeline, deren Rechte man auf einen Blick versteht. Das macht sie nicht nur sicherer, sondern auch einfacher zu prüfen, wenn ein Kunde oder Auditor wissen will, wer was in der Lieferkette darf.

Pipeline-Rechte einmal sauber durchleuchten

Der GitSecOps QuickCheck prüft Ihre Pipeline gezielt auf zu breite Rechte, ungenutzte Tokens und offen liegende Secrets und zeigt konkret, wo Least Privilege fehlt. Festpreis 1.990 Euro netto, Ergebnis in drei Werktagen. Anfragen an mm@crank.zone.