Feingranulare Autorisierung: Wie fein ist fein genug?

Was feingranulare Autorisierung tatsächlich bedeutet

Bei der feingranularen Autorisierung geht es um die Größe der Sache, über die Sie entscheiden, nicht um den Mechanismus, mit dem Sie entscheiden. Grobe Autorisierung fragt: „Kann diese Identität das AI Gateway nutzen?“ Feingranulare Autorisierung fragt: „Kann diese Identität genau jetzt das Werkzeug delete_issue auf dem Linear-MCP-Server für diese Person aufrufen?“

Die Verschiebung verläuft entlang von vier unabhängigen Dimensionen, die es wert sind, getrennt zu werden, da sie unterschiedlich viel kosten:

Die meiste Literatur zu feingranularer Zugriffskontrolle fasst diese Dimensionen zu einem einzigen Schieberegler namens „sicherer“ zusammen und dreht ihn hoch. Das ist der Fehler. Subjekt- und Aktionsgranularität sind nahezu kostenlos – ein Benutzer statt einer Gruppe, eine Berechtigung statt eines Bündels kostet bei der Überprüfung nichts. Die Kosten entstehen bei der Ressourcen- und Anlassgranularität.

Granularität ist auch orthogonal zur Wahl zwischen RBAC und ABAC. Einfache Rollen können sehr feine Berechtigungen ausdrücken, wenn Sie Bindungen eng definieren, und Attribut-Richtlinien können hoffnungslos grob sein. Das Modell bestimmt, wie Sie entscheiden; Granularität bestimmt, worüber Sie entscheiden.

Die Kosten, die niemand einkalkuliert

Die Arithmetik: Vierzig Ingenieure und eine mandantenweite Berechtigung geben einer Zugriffsüberprüfung 40 Zustände zur Bestätigung. Definieren Sie dies pro Ressource über 12 MCP-Server hinweg, haben Sie 480. Gehen Sie pro Tool bei 25 Tools pro Server vor, haben Sie 12.000 Zellen. Fügt man eine Genehmigung pro Aufruf hinzu, ist das Überprüfungsobjekt kein Raster mehr – es wird zu einem Ereignisprotokoll.

Niemand auditiert 12.000 Zellen. Was stattdessen passiert, ist das reale Risiko einer Über-Granularität:

• Das Modell wird approximiert. Prüfer hören auf, Zellen zu überprüfen, und fangen an, Rollennamen zu prüfen, sodass die darunter liegenden Berechtigungen unbemerkt abweichen.
• Jemand baut einen Notausstieg. Ein gemeinsames Dienstkonto mit weitreichendem Zugriff entsteht, weil der korrekte Pfad drei Genehmigungen und ein Ticket erfordert. Jede Kontrolle auf dem sorgfältigen Pfad ist nun reine Dekoration.
• Berechtigungen reichern sich an. Feingranulare Berechtigungen sind einzeln klein, sodass niemand das Gewicht spürt, eine aufrechtzuerhalten. Grobe Berechtigungen werden widerrufen, weil sie sichtbar sind.
• Die Genehmigungswarteschlange wird zum blinden Abstempeln. Wenn Sie alles reglementieren, klicken Genehmiger ungelesen durch – schlimmer als gar nichts zu reglementieren, weil ein signierter Datensatz nun besagt, dass ein Mensch zugestimmt hat.

Die Einschränkung ist also die Beantwortbarkeit. Auf jeder Stufe sollten Sie drei Fragen beantworten können, ohne einen Job auszuführen: Wer kann diese Ressource erreichen, was kann er damit tun und wann hat er es zuletzt getan. Wenn Sie das durchbrechen, haben Sie Präzision mit Sichtbarkeit erkauft.

Das ist auch der Grund, warum Least-Privilege-Berechtigungen und maximale Granularität nicht dasselbe Ziel sind. Least Privilege gewährt nicht mehr Befugnisse, als die Aufgabe erfordert; es besagt nicht, dass Sie sie so dünn schneiden sollen, wie das System es erlaubt. Eine Rolle, die genau die sieben Berechtigungen hält, die ein Job benötigt, entspricht dem Prinzip der geringsten Rechte. Siebenhundert separate Zuweisungen, die sich zur selben Befugnis aufsummieren, sind einfach nur teuer.

Die Granularitätsleiter

Vier Stufen, von grob bis fein, jede mit einer spezifischen Aufgabe. Die Regel lautet: Sitzen Sie auf der untersten Stufe, die das Risiko beinhaltet.

Zwei Eigenschaften machen dies zu einer Leiter, nicht zu einem Menü.

Die Stufen setzen sich nach unten fort, nicht nach oben oder seitlich. Stufe 3 ist nur für Identitäten relevant, die Stufe 2 passiert haben, und ein deaktiviertes Tool ist unerreichbar, egal welche Rolle jemand innehat. Sie können auf einer groben Stufe großzügig und auf einer feinen Stufe streng sein, und die Strenge bleibt bestehen.

Jede Stufe ist ein Datensatz unterschiedlicher Form. Stufe 1 und 2 sind Tabellen, die Sie lesen. Stufe 3 ist eine Liste, die Sie mit dem letzten Quartal vergleichen. Stufe 4 ist ein Protokoll, aus dem Sie Stichproben ziehen. Die Behandlung von Stufe 4 wie eine Tabelle führt dazu, dass Teams am Ende zweihundert Richtlinien haben, die niemand zusammenfassen kann.

Wo Teams Fehler machen

Verwendung von Stufe 1 für die Aufgabe von Stufe 2. Der mit Abstand häufigste Fehler. Jemand benötigt einen MCP-Server und erhält daher eine mandantenweite Rolle, die mcp-server:ReadMcpServer enthält – was jeden MCP-Server im Mandanten erreicht. Die Zuweisung sieht eng aus, weil die Berechtigungsliste kurz ist. Das ist sie aber nicht.

Aufstieg auf Stufe 4, um einer Diskussion über Stufe 2 auszuweichen. Genehmigungsrichtlinien sind attraktiv, weil sie die Entscheidung aufschieben. Aber eine Schranke an einem Tool, das die falschen Leute überhaupt erreichen können, ist eine Schranke vor einer offenen Tür. Korrigieren Sie zuerst die Bindung.

Behandlung von Schaltern auf Tool-Ebene als Grenze gegen nicht vertrauenswürdige Aufrufer. Das Deaktivieren eines Tools entfernt es aus der Erkennung und blockiert den Aufruf – genau richtig gegen einen Agenten, der sonst etwas Gefährliches aus einer langen Liste auswählen würde. Es ersetzt jedoch nicht die eigenen Berechtigungen des vorgelagerten Systems für das Anmeldeauthentifizierungselement.

Niemaliges Überprüfen der feinen Stufen. Grobe Zuweisungen werden überprüft, weil sie auffällig sind. Ein Tool, das vor acht Monaten für eine einmalige Migration aktiviert wurde, ist unsichtbar. Auditieren Sie die Listen aktivierter Tools im selben Rhythmus, in dem Sie Rollen auditieren.

Möchten Sie die Leiter in einer Konsole sehen?

Beschränken Sie eine Rolle auf eine einzelne Ressource und deaktivieren Sie dann ein Tool darauf – in etwa fünf Minuten von Anfang bis Ende.

Kostenlos starten

Wie die Leiter in TrueFoundry funktioniert

TrueFoundry implementiert alle vier Stufen. Ein Subjekt (Benutzer, Team, Virtual Account oder Agent) plus eine Ressource plus eine Rolle ergibt eine Rollenbindung (Role Binding), die unabhängig von der Ressourcenkonfiguration verwaltet wird – Sie ändern also, wer etwas erreichen kann, ohne es neu bereitzustellen.

Stufe 1 — Mandantenweite Fähigkeit

Drei Mandantenrollen sind integriert: Admin (Vollzugriff, nicht bearbeitbar), Member (die bearbeitbare Standard-Basislinie) und Read-Only Member (schreibgeschützt, ebenfalls fest).

Wenn diese zu breit oder zu eng sind, erstellen Sie eine benutzerdefinierte Rolle unter Access > Custom Roles. Der Katalog ist hier die Substanz feingranularer Berechtigungen: Jeder Eintrag ist ein Schlüssel im Format ressource:Aktion, gruppiert nach Ressourcentyp, und die Benennung verrät Ihnen, welche Granularität existiert, bevor Sie irgendetwas entwerfen.

Das Erstellen eines MCP-Servers und das Verwalten eines MCP-Servers sind getrennte Schlüssel. Diese Aufteilungen verleihen dem Design eines Autorisierungsmodells seine nutzbare Auflösung.

Eine Regel gilt für diese Stufe: Berechtigungen aus benutzerdefinierten Rollen gelten für alle Ressourcen des ausgewählten Typs. Für eine einzelne Ressource verwenden Sie die Access Control-Seite dieser Ressource. Dies zu verwechseln entspricht dem oben beschriebenen Fehler, Stufe 1 für die Aufgabe von Stufe 2 zu nutzen.

Stufe 2 — Rollen pro Ressource

Öffnen Sie das Drei-Punkte-Menü der Ressource und wählen Sie Access Control.

Wählen Sie Subjekte und eine Rolle. Der Drawer listet die Aktionen auf, die jede Rolle enthält, sodass Sie die Zuweisung zuerst sehen.

Die Rollen hängen von der Ressource ab: Manager und User bei einem Provider Account; MCP Server Manager, MCP Server User und MCP Server Approver bei einem MCP-Server; Agent Manager und Agent Access bei einem Agenten; Admin-, Member- und Viewer-Stufen auf Clustern und Workspaces. Die Gewährung an ein Team ist besser als die Gewährung an eine Person – zukünftige Mitglieder erben sie, und die Zuweisungstabelle bleibt kurz genug zum Lesen. Das Modell zur MCP Access Control baut auf dieser Stufe auf.

Stufe 3 — Pro Tool innerhalb einer Ressource

Dies ist die Stufe, nach der Teams zuletzt greifen und die Agenten am meisten benötigen. Auf einem Remote- oder TrueFoundry-verwalteten MCP-Server steuert der Tab Tools, welche Tools aufrufbar sind.

Deaktivierte Tools werden aus responses von tools/list ausgelassen und können nicht aufgerufen werden. Beide Hälften zählen: Das Modell kann nicht wählen, was es nie sieht, und das Gateway verweigert den Aufruf, wenn etwas trotzdem nachfragt.

Der Schalter Enable new tools by default legt die Basislinie fest, und das ist eine echte Designentscheidung. Ist er aktiviert, ist die Liste eine Denylist und neue Vendor-Tools erscheinen automatisch. Ist er deaktiviert, ist es eine Allowlist und neue vorgelagerte Tools bleiben verborgen, bis sie jemand aktiviert. Eine Allowlist ist richtig für alles, was die Produktion berührt.

Edit Tool bewirkt etwas Subtileres. Neben dem Überschreiben einer Beschreibung legen Sie MCP Tool Annotations auf None, Read-only oder Destructive fest, was readOnlyHint oder destructiveHint setzt.

Diese Annotation ist die Kennzeichnung, die Stufe 4 liest, sodass eine einmalige Klassifizierung zur fortlaufenden Richtlinie wird, ohne Tools zweimal benennen zu müssen.

Stufe 4 — Genehmigung pro Aufruf

Tool-Genehmigungsrichtlinien halten einen reglementierten Aufruf von tools/call am Gateway an, erstellen eine ausstehende Anfrage und benachrichtigen Genehmiger. Das Tool wird nicht ausgeführt. Einmal genehmigt, sind Aufrufe für ein Gültigkeitsfenster erfolgreich, danach ist eine neue Genehmigung erforderlich.

Zwei Regler stellen die Granularität ein, und beide haben dokumentierte Vorrangregeln:

Zuweisungen sind auf den Anforderer sowie den spezifischen Server und das Tool beschränkt und werden nicht zwischen Benutzern geteilt. Genehmiger arbeiten in den Pending Requests, wo Tool, Richtlinie, Anforderer, Gültigkeitsfenster und Tool-Argumente angezeigt werden.

Wer hier was tun kann, ist selbst über Stufen hinweg aufgeteilt. Nur Mandanten-Administratoren können Richtlinien erstellen, aktualisieren oder löschen. Das Genehmigen oder Ablehnen erfordert den Mandanten-Admin oder die Rolle MCP Server Approver auf diesem Server, hinzugefügt aus dessen Collaborators-Liste.

Wenn ein durch eine Richtlinie benannter Server keine Approver-Collaborators hat, können nur Mandanten-Administratoren entscheiden – ein leiser Weg, jede Genehmigung zu drei überlasteten Personen zu leiten.

Eine ehrliche Einschränkung: Eine Ablehnung ist keine Blockade. Sie wird protokolliert, und der nächste Aufruf löst eine neue Anfrage aus. Um den Zugriff dauerhaft zu stoppen, gehen Sie die Leiter wieder hinunter – entfernen Sie den Zugriff des Subjekts auf den Server oder deaktivieren Sie das Tool. Stufe 4 regelt Anlässe, nicht die grundsätzliche Befugnis.

Ein durchgerechnetes Beispiel: Lesen versus Nutzen bei einer Secret Group

Secret Groups zeigen am deutlichsten, warum Aktionsgranularität ihre Berechtigung hat, denn hier gilt es, das Sehen eines Werts vom Abhängen von einem Wert zu trennen.

Eine Secret Group organisiert zusammengehörige Secrets, sodass Sie den Zugriff einmal verwalten und nicht pro Secret. Wenn Sie ein Secret speichern, geht der Wert an Ihren eigenen Secret Manager – AWS SSM, GCP Secret Manager, HashiCorp Vault, Azure Vault – und TrueFoundry speichert einen vollqualifizierten Namen (FQN), auf den Sie sich aus Bereitstellungen, Volume Mounts, Integrationen und Gateway-Modell-API-Schlüsseln beziehen.

Diese Indirektion ist der Mechanismus: Eine Bereitstellung, die ein Secret per FQN konsumiert, erfordert nicht, dass ein Mensch den Wert gelesen hat. Das macht diese Trennung real und nicht kosmetisch:

Die Zeile „Secret Group Viewer“ ist der Gewinn. Jemand kann sehen, dass stripe-live-key hier existiert – genug, um zu überprüfen, wovon ein Projekt abhängt –, ohne dass der Wert auf seinem Bildschirm erscheint. Der Berechtigungskatalog macht dieselbe Aufteilung explizit: secret-group:ReadSecretGroup zeigt die Gruppe an, secret-group:ReadData liest Werte. Verschiedene Schlüssel, sodass eine benutzerdefinierte Rolle den einen ohne den anderen halten kann.

Zwei Vorbehalte, da die Dokumentation hier enger ist als das Konzept: Ein Mandanten-Admin hat standardmäßig Zugriff auf alle Secret Groups; für Mitglieder und Teams weisen Sie jeder Gruppe individuell eine Rolle zu. Und die Ressourcen-Rollen-Liste nennt eine vierte Rolle, Secret Group Access, neben Admin, Editor und Viewer – die Secret-Management-Seite dokumentiert jedoch nur die drei obigen, daher werden wir Ihnen nicht sagen, was die vierte gewährt. Überprüfen Sie Ihre eigene Konsole, bevor Sie einen Prozess darauf aufbauen.

Das Muster lässt sich verallgemeinern. Wo immer eine Ressource sowohl eine Beschreibung als auch eine Nutzlast (Payload) hat, suchen Sie nach separaten Schlüsseln für beides – Repositories haben dieselbe Aufteilung in ReadRepository und ReadData – und gewähren Sie die Beschreibung ohne die Nutzlast, wo immer dies ausreicht.

Bereit, Lesen von Nutzen zu trennen?

Erstellen Sie eine Secret Group, gewähren Sie einem Teammitglied die Rolle Viewer und beobachten Sie, wie die Werte verborgen bleiben.

Kostenlos auf TrueFoundry starten

Fallstricke, die man kennen sollte

Zuweisungen kombinieren sich, und das Entfernen der einen entfernt nicht die andere. Ein Subjekt kann Zugriff direkt halten und ihn über ein Team erben. TrueFoundry kombiniert beides, sodass das Widerrufen der direkten Zuweisung die geerbte intakt lässt. Überprüfen Sie beides in dieser Reihenfolge. Feine Granularität verschlimmert dies: mehr kleine Zuweisungen, mehr Orte zum Nachschauen.

Das Bearbeiten einer Team-Standardrolle ändert sie für jedes Team. Team Member und Team Manager werden unter Access > Default Roles bearbeitet, und die Änderung gilt global. Das Hinzufügen von virtual-account:ManageVirtualAccount, damit ein Team Tokens abrufen kann, gewährt diese Fähigkeit in jedem Team. Die Leute bleiben auf ihre eigenen Teams beschränkt, aber die Fähigkeit breitet sich aus. Eine Änderung der Stufe 1 im Gewand der Stufe 2.

Eine ausstehende Genehmigung ist eine erfolgreiche Antwort, kein Fehler. Während eine Anfrage aussteht, gibt das Gateway ein JSON-RPC-Ergebnis mit isError: false und _meta.approval_status: "pending" zurück, dessen Text den Aufrufer zum Warten auffordert. Ein Agent, der nur auf Fehler prüft, behandelt dies als echtes Tool-Ergebnis und fährt fort. Lesen Sie _meta.approval_status und versuchen Sie es erneut.

Weiterführende Literatur

• MCP Access Control: Securing AI Agents with an MCP Gateway — Stufen 2 und 3 für Agenten-Tooling
• What Is MCP Authorization? — wie Entscheidungen einen Tool-Aufruf erreichen
• Enterprise MCP Access Control — die Leiter über viele Server hinweg lesbar halten
• API Auth and RBAC in the AI Gateway — wo Zuweisungen bei live verarbeitetem Datenverkehr durchgesetzt werden
• Virtual MCP Servers — Zusammenstellung einer kuratierten Tool-Oberfläche aus mehreren Servern

Fazit

Feingranulare Autorisierung wird als Schieberegler verkauft, den man hochdreht. Sie ist jedoch eine Leiter, die man bewusst erklimmt – und man hört auf, wenn das Risiko aufhört zu steigen, und nicht erst, wenn der Plattform die Optionen ausgehen.

Jede Stufe beantwortet eine andere Frage. Die Mandantenfähigkeit fragt, was jemand überhaupt tun kann. Rollen pro Ressource fragen wo. Berechtigungen auf Tool-Ebene fragen, welche Operationen zur Auswahl stehen. Die Genehmigung pro Aufruf fragt, ob dieser Aufruf jetzt stattfinden sollte. In dieser Reihenfolge schränkt jede Stufe die vorherige ein, und alle bleiben lesbar.

Ausserhalb der Reihenfolge – eine Schranke pro Aufruf, die eine zu breite Bindung schützt, oder eine mandantenweite Rolle, die als Ressourcenzuweisung einspringt – erhalten Sie ein Modell, das in einem Diagramm streng aussieht, aber in einem Audit nicht erklärt werden kann. Das feinste Autorisierungsmodell ist nicht das beste. Das feinste Modell, das Sie laut vorlesen können, ist es.

Definieren Sie Ihren ersten Agenten auf TrueFoundry

Kostenlos starten