Autorisierung — wer was darf und wie du es nachweist

Control Center beantwortet zwei Autorisierungsfragen, und die beiden meinen nicht dasselbe. „Darf diese Person diese Operation aufrufen?“ betrifft Menschen, Rollen und Repositories. „Darf dieser Agent diese Wirkung auslösen?“ betrifft Aktionen, Argumente und den Wirkungsradius — das steht unter Schutzregeln.

Diese Seite ist die erste Frage, und dazu die Aufzeichnung, die beide hinterlassen.

Ein Entscheidungspunkt

Jede Autorisierungsentscheidung auf Menschenseite läuft durch eine einzige Funktion:

can(principal, permission, resource) → allow | deny + why

Eine Berechtigung hat die Form <domain>:<tier> — tickets:write, members:administer, repos:read. Der Katalog ist abgeleitet, nicht von Hand geschrieben: Er wird aus der Operationsoberfläche selbst berechnet (das Namenspräfix der Operation liefert die Domäne, die Mindestrolle, die sie schon erzwingt, die Stufe). So tragen alle ~550 Operationen eine Berechtigung, ohne dass jemand eine eintippt.

Genau diese Ableitung ist es wert, geschützt zu werden. Eine NEUE Operation ist damit von vornherein an eine Berechtigung gebunden — beim von Hand annotierten Modell vergisst jemand etwas, und das Vergessene ist das Gate. Ein Ratchet-Test hält die resultierende Domänenmenge fest. Eine Operation unter einem neuen Präfix hinzuzufügen ist damit eine Namensentscheidung, die ein Mensch trifft, und kein Versehen.

Die vier Stufen bilden die eingebauten Rollen genau ab:

Stufe	Mindestrolle	Beispiel
read	Gast	tickets:read
write	Mitglied	tickets:write
administer	Admin	members:administer
own	Eigentümer	workspace:own

Rollen

Fünf eingebaute Rollen — Eigentümer, Admin, Mitglied, Betrachter, Gast — sind Voreinstellungen auf diesem Katalog. Die Eigentümerschaft ist ein einzelner Platz pro Arbeitsbereich und wird ausdrücklich mit Besitz übertragen weitergegeben (ein Eigentümer, der geht, lässt sich sonst nicht entfernen: die SCIM-Deprovisionierung lehnt jeden Arbeitsbereichs-Eigentümer ab — zuerst übertragen).

Benutzerdefinierte Rollen nehmen nur weg. Eine benutzerdefinierte Rolle nennt eine Basisvorlage (admin, member, viewer oder guest — nie owner) und eine Menge von Berechtigungen, die davon ENTFERNT werden — „Admin, kann aber keine Mitglieder verwalten“. Sie kann nie mehr gewähren als ihre Basis. Genau deshalb lassen sie sich in einer bestehenden Installation einführen: jede bestehende Prüfung bleibt eine verlässliche Obergrenze. Mitglieder führen sie als custom:<id>, und ein Client, der zu alt ist, um diesen Wert zu verstehen, fällt auf Gast zurück, statt zu raten.

Unter den Rollen liegen Freigaben pro Repo (none / read / review / write): die Mitgliedschaft im Arbeitsbereich gibt nie stillschweigend mehr Rechte als der Code-Host. Jede Oberfläche, die Code zeigt, prüft sie — auch die, die seitlich an den Code kommen, etwa ein Terminal oder eine Editor-Sitzung auf dem Worktree eines Bereichs.

Serverautorität

Manche Operationen betreffen gar keinen Arbeitsbereich: installationsweite Einstellungen, die SSO-Konfiguration, Anbieter-Zugangsdaten, die Modellverwaltung, Sicherungen der ganzen Installation. Sie deklarieren Serverautorität und werden für alle abgelehnt außer dem Betreiber der Installation (dem hinterlegten Server-Eigentümer). Absichtlich gibt es genau eine Betreiberidentität und genau eine Definition davon.

Das Audit-Protokoll

Jede Autorisierungsentscheidung — Zulassen und Ablehnen — wird an ein Audit-Protokoll angehängt, das pro Arbeitsbereich geführt und über Hashes verkettet ist.

Ein Protokoll nur mit Ablehnungen beantwortet „Was haben wir blockiert?“, aber nicht „Was hat dieser Agent tatsächlich getan, und wer hat es autorisiert?“. Mit dieser Frage beginnt eine Vorfallprüfung. Jeder Eintrag hält deshalb die ganze Zuschreibungskette fest: den handelnden Prinzipal, den Menschen, in dessen Auftrag er gehandelt hat, die Delegation, über die er gekommen ist, die Aktion und ihre Argumente (als Digest), die Entscheidung und die Regel, die entschieden hat.

Die Einträge sind verkettet: der Hash eines Eintrags umfasst den des vorherigen. Wer eine Zeile ändert, löscht oder umordnet, bricht damit jeden Hash danach. Kette prüfen leitet das Ganze neu ab und nennt das erste Glied, das nicht hält. Ein Audit-Protokoll, das du nicht prüfen kannst, ist ein Protokoll. Eines, das du neu ableiten kannst, ist ein Beweis.

Zwei Folgen, die du kennen solltest:

• Die Audit-Tabelle ist von der altersbasierten Bereinigung ausgenommen. Eine Hash-Kette lässt sich nicht aus der Mitte kürzen. Aufbewahrt wird durch Export und anschließendes Kürzen, und das Kürzen hinterlässt einen Checkpoint mit dem End-Hash des entfernten Abschnitts. Was bleibt, lässt sich so weiterhin bis zum Anfang prüfen.
• Es steht neben der Aktivitätschronologie, nicht darüber. Die Chronologie ist, was Menschen getan haben; hier steht, was autorisiert und abgelehnt wurde. Eine gemeinsame Korrelations-ID liest einen Aufruf über beide.

Es wird als zeilengetrenntes JSON exportiert und kann an ein SIEM gestreamt werden (Splunk, Elastic, Sentinel — ein HTTP-Endpunkt mit einem Bearer-Token). Das Streaming ist bewusst Best Effort: Fällt ein SIEM aus, darf das einen Tool-Aufruf eines Agenten nie blockieren. Die dauerhafte, prüfbare Kopie liegt so oder so auf der Platte.

Sitzungen

Eine Installation kann ein maximales Sitzungsalter und ein Inaktivitätszeitlimit setzen. Beides wird bei der Prüfung der Geräteanmeldedaten durchgesetzt, durch die jeder authentifizierte Weg läuft — eine Sitzungsgrenze, die ein Client ignorieren könnte, beantwortet einen Fragebogen, keinen Angreifer. Eine Installation kann außerdem SSO verlangen. Das schaltet die manuelle Kopplung für neue Geräte ab (mit einem Aussperrschutz: abgelehnt wird, solange keine funktionierende SSO-Verbindung besteht).

Was das nicht ist

• Keine ACLs pro Objekt. Es gibt absichtlich keine Berechtigung pro Ticket oder pro Nachricht. Trennung auf Repository-Ebene ist das, wonach Teams tatsächlich fragen, und die gibt es. Freigabe pro Objekt ist eine kombinatorische Oberfläche ohne nachgewiesenen Bedarf hier.
• Keine Policy-Engine, die du in einer DSL konfigurierst. Das Vokabular ist absichtlich geschlossen, damit sich die ganze Richtlinie darstellen, erklären und aufzählen lässt.
• Durchgesetzt wird nur auf dem Server. Prüfungen auf dem Client gibt es nur, damit kein Steuerelement angeboten wird, das abgelehnt würde. Die maßgebliche Entscheidung trifft immer der Server.