Fijnmazige autorisatie: Hoe fijn is fijn genoeg?

Wat fijnmazige autorisatie daadwerkelijk betekent

Fijnmazige autorisatie gaat over de grootte van het object waarover u beslist, niet over het mechanisme waarmee u beslist. Grove autorisatie vraagt “mag deze identiteit de AI-gateway gebruiken?” Fijnmazige autorisatie vraagt “mag deze identiteit op dit moment de delete_issue-tool op de Linear MCP-server aanroepen voor deze persoon?”

De verschuiving vindt plaats langs vier onafhankelijke dimensies, die het waard zijn om te scheiden omdat ze verschillende kosten met zich meebrengen:

De meeste artikelen over fijnmazige toegangscontrole schuiven deze dimensies op één hoop als een schuifknop met het label “veiliger” en draaien die helemaal open. Dat is een fout. Subject- en actie-granulariteit zijn vrijwel gratis — een gebruiker in plaats van een groep, één permissie in plaats van een bundel, kost niets tijdens een review. Resource- en gelegenheids-granulariteit zijn de punten waar de rekening gepresenteerd wordt.

Granulariteit staat ook los van de keuze tussen RBAC en ABAC. Eenvoudige rollen kunnen zeer fijne permissies uitdrukken als u bindings strikt afbakent, en attribuutbeleid kan hopeloos grof zijn. Het model is *hoe* u beslist; granulariteit is *waartoe* u beslist.

De kosten die niemand meerekent

De rekensom. Veertig engineers en één tenant-brede gateway-permissie geeft een toegangsreview 40 toestanden om te controleren. Bepaal het bereik per resource over 12 MCP-servers en u heeft er 480. Ga per tool bij 25 tools per server en u heeft 12.000 cellen. Voeg goedkeuring per aanroep toe en het object van review is geen matrix meer — het wordt een logboek.

Niemand auditeert 12.000 cellen. Wat er in plaats daarvan gebeurt, is het werkelijke risico van te grote granulariteit:

• Het model wordt benaderd. Reviewers stoppen met het controleren van cellen en kijken alleen nog naar rolnamen, waardoor de onderliggende permissies ongemerkt afwijken.
• Iemand bouwt een geitenpaadje. Er verschijnt een gedeeld service-account met brede toegang, omdat het correcte pad drie goedkeuringen en een ticket vereist. Elke controle op het zorgvuldige pad is nu puur decoratief.
• Toewijzingen hopen zich op. Fijnmazige toewijzingen zijn individueel klein, dus niemand voelt de noodzaak om een overbodige toewijzing in te trekken. Grove toewijzingen worden wel ingetrokken omdat ze opvallen.
• De goedkeuringswachtrij wordt een stempelmachine. Bepaal alles met goedkeuringen en goedkeurders klikken ongelezen door — erger dan niets beveiligen, omdat een ondertekend rapport nu zegt dat een mens akkoord is gegaan.

De beperking is dus controleerbaarheid. Op elke sport moet u drie vragen kunnen beantwoorden zonder een script uit te voeren: wie kan deze resource bereiken, wat kunnen ze ermee doen, wanneer hebben ze dat voor het laatst gedaan. Als u dat doorbreekt, heeft u precisie gekocht ten koste van het overzicht.

Dit is ook waarom least privilege permissions en maximale granulariteit niet hetzelfde doel zijn. Least privilege verleent niet meer bevoegdheid dan de taak vereist; het zegt niet dat u het zo dun moet snijden als het systeem toelaat. Een rol met precies de zeven permissies die een taak nodig heeft, is least privilege. Zevenhonderd losse toewijzingen die optellen tot dezelfde bevoegdheid is gewoon duur.

De granulariteitsladder

Vier sporten, van grof naar fijn, elk met een specifieke taak. De regel is om op de laagste sport te blijven zitten die het risico afdekt.

Twee eigenschappen maken het een ladder, geen keuzemenu.

De sporten bouwen naar beneden op, niet zijwaarts. Sport 3 is alleen van belang voor identiteiten die sport 2 hebben gepasseerd, en een uitgeschakelde tool is onbereikbaar, ongeacht welke rol iemand heeft. U kunt ruimdenkend zijn op een grove sport en strikt op een fijne sport, en de striktheid blijft van kracht.

Elke sport heeft een ander type record. Sport 1 en 2 zijn tabellen die u leest. Sport 3 is een lijst die u vergelijkt met het vorige kwartaal. Sport 4 is een logboek waaruit u steekproeven neemt. Sport 4 behandelen als een tabel is hoe teams eindigen met tweehonderd regels beleid die niemand kan samenvatten.

Waar teams de fout in gaan

Sport 1 gebruiken om het werk van sport 2 te doen. Veruit de meest voorkomende fout. Iemand heeft één MCP-server nodig, dus krijgt hij een tenant-brede rol met mcp-server:ReadMcpServer — die toegang geeft tot elke MCP-server in de tenant. De toewijzing lijkt beperkt omdat de permissielijst kort is. Dat is het niet.

Klimmen naar sport 4 om een gesprek over sport 2 te vermijden. Goedkeuringsbeleid is aantrekkelijk omdat het de beslissing uitstelt. Maar een poort voor een tool die de verkeerde mensen überhaupt kunnen bereiken, is een poort voor een open deur. Herstel eerst de binding.

Schakelaars op tool-niveau zien als een grens tegen niet-vertrouwde aanroepers. Het uitschakelen van een tool verwijdert deze uit de discovery en blokkeert de aanroep — uitstekend tegen een agent die anders iets gevaarlijks uit een lange lijst zou kiezen. Het vervangt niet de permissies van het bovenliggende systeem op de authenticatiegegevens zelf.

De fijne sporten nooit meer herzien. Grove toewijzingen worden geauditeerd omdat ze opvallen. Een tool die acht maanden geleden is ingeschakeld voor een eenmalige migratie is onzichtbaar. Auditeer lijsten met ingeschakelde tools met dezelfde frequentie als waarmee u rollen auditeert.

Wilt u de ladder in één console zien?

Bepaal het bereik van een rol tot een enkele resource en schakel er vervolgens een tool op uit — dit duurt ongeveer vijf minuten van begin tot eind.

Aan de slag — gratis

Hoe de ladder werkt in TrueFoundry

TrueFoundry implementeert alle vier de sporten. Een subject (gebruiker, team, virtueel account of agent) plus een resource plus een rol vormt een role binding, die onafhankelijk van de resource-configuratie wordt beheerd — zo wijzigt u wie iets kan bereiken zonder het opnieuw te hoeven deployen.

Sport 1 — tenant-brede functionaliteit

Er zijn drie ingebouwde tenant-rollen: Admin (volledige controle, niet bewerkbaar), Member (de bewerkbare standaardbasis) en Read-Only Member (alleen-lezen, eveneens vast).

Wanneer deze te breed of te beperkt zijn, bouwt u een aangepaste rol via Access > Custom Roles. De catalogus vormt de essentie van fijnmazige permissies hier: elke vermelding is een resource:Action sleutel, gegroepeerd op resourcetype. De naamgeving laat zien welke granulariteit er bestaat voordat u iets ontwerpt.

Het aanmaken van een MCP-server en het beheren ervan zijn gescheiden sleutels. Die splitsingen geven een autorisatiemodel de gewenste bruikbare resolutie.

Één regel is van toepassing op deze sport: permissies van aangepaste rollen gelden voor alle resources van het geselecteerde type. Gebruik voor een enkele resource de Access Control pagina van die specifieke resource. Dit verkeerd om doen leidt tot de hierboven genoemde fout waarbij sport 1 het werk van sport 2 doet.

Sport 2 — rollen per resource

Open het menu met de drie puntjes van de resource en selecteer Access Control.

Kies subjecten en een rol. Het uitklapvenster toont de acties die elke rol bevat, zodat u de toewijzing direct kunt inzien.

Rollen zijn afhankelijk van de resource: Manager en User op een provider-account; MCP Server Manager, MCP Server User en MCP Server Approver op een MCP-server; Agent Manager en Agent Access op een agent; admin-, member- en viewer-niveaus op clusters en workspaces. Toewijzen aan een team is beter dan toewijzen aan een persoon — toekomstige teamleden erven het automatisch, en de toewijzingstabel blijft kort genoeg om leesbaar te blijven. Het MCP toegangscontrole model is gebouwd op deze sport.

Sport 3 — per tool binnen een resource

Dit is de sport die teams als laatste toepassen, maar die agents het hardst nodig hebben. Op een Remote of door TrueFoundry beheerde MCP-server bepaalt het tabblad Tools welke tools aanroepbaar zijn.

Uitgeschakelde tools worden weggelaten uit tools/list antwoorden en kunnen niet worden aangeroepen. Beide kanten zijn belangrijk: het model kan niet kiezen wat het niet ziet, en de gateway weigert de aanroep als er toch een verzoek wordt gedaan.

De optie Enable new tools by default bepaalt de uitgangssituatie, en dat is een fundamentele ontwerpkeuze. Ingeschakeld werkt de lijst als een denylist en verschijnen nieuwe vendor-tools automatisch. Uitgeschakeld werkt het als een allowlist en blijven nieuwe bovenliggende tools verborgen totdat iemand ze expliciet inschakelt. Een allowlist is de juiste keuze voor alles wat met productie te maken heeft.

Edit Tool doet iets subtielers. Naast het overschrijven van een beschrijving kunt u MCP Tool Annotations instellen op None, Read-only of Destructive, wat de parameters readOnlyHint of destructiveHint instelt.

Die annotatie is het label dat sport 4 leest, waardoor een eenmalige classificatie doorlopend beleid wordt zonder dat u tools dubbel hoeft te benoemen.

Sport 4 — goedkeuring per aanroep

Goedkeuringsbeleid voor tools houdt een aangeroepen tools/call tegen bij de gateway, maakt een in behandeling zijnd verzoek aan en informeert goedkeurders. De tool wordt niet uitgevoerd. Zodra het verzoek is goedgekeurd, slagen aanroepen gedurende een geldigheidsvenster, waarna een nieuwe goedkeuring vereist is.

Twee instellingen bepalen de granulariteit, en beide hebben gedocumenteerde voorrangsregels:

Toewijzingen zijn gebonden aan de aanvrager plus de specifieke server en tool, en worden niet gedeeld tussen gebruikers. Goedkeurders werken vanuit Pending Requests, waarin de tool, het beleid, de aanvrager, het geldigheidsvenster en de tool-argumenten worden getoond.

Wie hier wat mag doen, is zelf ook verdeeld over de sporten. Alleen tenant-beheerders kunnen beleid aanmaken, bijwerken of verwijderen. Goedkeuren of afwijzen vereist tenant-admin rechten of de rol MCP Server Approver op die specifieke server, toegevoegd via de lijst met Collaborators.

Als een server in een beleid geen Approver-collaborators heeft ingesteld, kunnen alleen tenant-beheerders beslissen — een onopvallende manier om elke goedkeuring door te sturen naar drie toch al overbelaste mensen.

Een belangrijke nuance: een afwijzing is geen definitieve blokkade. Het wordt vastgelegd, en de volgende call maakt een nieuw verzoek aan. Om toegang duurzaam te stoppen, moet u weer afdalen op de ladder — verwijder de toegang van het subject tot de server, of schakel de tool uit. Sport 4 beheert gelegenheden, geen permanente bevoegdheden.

Een uitgewerkt voorbeeld: lezen versus gebruiken bij een geheimengroep

Geheimengroepen laten het duidelijkst zien waarom actie-granulariteit de moeite waard is, omdat het verschil tussen een waarde inzien en afhankelijk zijn van een waarde essentieel is.

Een geheimengroep (secret group) structureert gerelateerde geheimen zodat u de toegang eenmalig beheert, in plaats van per geheim. Wanneer u een geheim opslaat, gaat de waarde naar uw eigen secrets manager — AWS SSM, GCP Secret Manager, HashiCorp Vault, Azure Vault — en slaat TrueFoundry een fully-qualified name (FQN) op waarnaar u verwijst vanuit deployments, volume mounts, integraties en gateway model API-sleutels.

Die indirectie is het mechanisme: een deployment die een geheim via FQN gebruikt, vereist niet dat een mens de waarde ooit heeft gelezen. Dat maakt deze scheiding reëel en niet cosmetisch:

De rij met Viewer is de winst. Iemand kan zien dat stripe-live-key hier bestaat — voldoende om te beoordelen waarvan een project afhankelijk is — zonder dat de waarde op hun scherm verschijnt. De permissiecatalogus maakt dezelfde scheiding expliciet: secret-group:ReadSecretGroup bekijkt de groep, secret-group:ReadData leest de waarden. Dit zijn verschillende sleutels, dus een aangepaste rol kan de een bevatten zonder de ander.

Twee kanttekeningen, omdat de documentatie hier specifieker is dan het algemene concept. Een tenant-admin heeft standaard toegang tot alle geheimengroepen; voor leden en teams wijst u per groep individueel een rol toe. En de lijst met resource-rollen noemt een vierde rol, Secret Group Access, naast Admin, Editor en Viewer — maar de documentatie voor geheimenbeheer beschrijft alleen de drie hierboven genoemde rollen. Controleer dus uw eigen console voordat u hier een proces op bouwt. [VERIFY]

Dit patroon is breed toepasbaar. Waar een resource zowel een beschrijving als een inhoud bevat, moet u zoeken naar gescheiden sleutels voor beide — repositories kennen een vergelijkbare scheiding tussen ReadRepository en ReadData — en verleent u toegang tot de beschrijving zonder de inhoud waar dat volstaat.

Klaar om lezen van gebruiken te scheiden?

Maak een geheimengroep aan, verleen de rol Viewer aan een teamgenoot en zie hoe de waarden afgeschermd blijven.

Start gratis op TrueFoundry

Aandachtspunten die u moet weten

Toewijzingen worden gecombineerd, en het verwijderen van de een verwijdert de ander niet. Een subject kan rechtstreeks toegang hebben én toegang erven via een team. TrueFoundry combineert beide, dus het intrekken van de rechtstreekse toewijzing laat de geërfde toewijzing intact. Controleer beide, in die volgorde. Fijnmazige granulariteit maakt dit complexer: meer kleine toewijzingen betekent meer locaties om te controleren.

Het bewerken van een standaard rol van een team wijzigt deze voor elk team. Team Member en Team Manager worden bewerkt onder Access > Default Roles, en deze wijziging is globaal. Het toevoegen van virtual-account:ManageVirtualAccount zodat één team tokens kan ophalen, verleent die mogelijkheid direct in elk team. Mensen blijven beperkt tot hun eigen teams, maar de functionaliteit verspreidt zich. Een wijziging op sport 1 in de gedaante van sport 2.

Een in behandeling zijnde goedkeuring is een succesvol antwoord, geen foutmelding. Zolang een verzoek in behandeling is, retourneert de gateway een JSON-RPC resultaat met isError: false en _meta.approval_status: "pending", waarvan de tekst de aanroeper vraagt te wachten. Een agent die alleen op fouten controleert, ziet dit als een echt resultaat van de tool en gaat door. Lees _meta.approval_status uit en probeer het opnieuw.

Gerelateerde artikelen

• MCP Access Control: Securing AI Agents with an MCP Gateway — sport 2 en 3 voor agent-tooling
• What Is MCP Authorization? — hoe beslissingen een tool-aanroep bereiken
• Enterprise MCP Access Control — de ladder overzichtelijk houden over meerdere servers
• API Auth and RBAC in the AI Gateway — waar toewijzingen worden afgedwongen op live verkeer
• Virtual MCP Servers — het samenstellen van een gecureerde tool-omgeving uit meerdere servers

Conclusie

Fijnmazige autorisatie wordt vaak gepresenteerd als een knop die u zover mogelijk opendraait. Het is echter een ladder die u bewust beklimt, waarbij u stopt wanneer het risico niet langer stijgt, in plaats van wanneer het platform geen opties meer biedt.

Elke sport beantwoordt een andere vraag. Tenant-functionaliteit vraagt wat iemand überhaupt kan doen. Rollen per resource vragen waar. Permissies op tool-niveau vragen welke operaties beschikbaar zijn om te kiezen. Goedkeuring per aanroep vraagt of deze specifieke call nu moet plaatsvinden. In die volgorde verfijnt elke sport de vorige, terwijl alles overzichtelijk blijft.

Wanneer dit verkeerd wordt toegepast — een controle per aanroep die een te brede binding beschermt, een tenant-brede rol die de plaats inneemt van een resource-toewijzing — ontstaat er een model dat er op een diagram rigoureus uitziet, maar tijdens een audit niet kan worden uitgelegd. Het fijnste autorisatiemodel is niet per definitie het beste model. Het fijnste model dat u helder kunt uitleggen is dat wel.

Stel het bereik van uw eerste agent in op TrueFoundry

Gratis om te beginnen