AiHummer
Dansk▾
Log indKonto
v1.0.x▾
v1.2.xstablev1.1.xstablev1.0.xstable
{ }Swagger
Sikkerhed/RBAC og scoped API-nøgler

RBAC og scoped API-nøgler

v1.0.x · opdateret 2026-07-07

AiHummer beskytter sin administrationsflade med rollebaseret adgangskontrol og begrænsede API-nøgler. Roller bestemmer, hvem en person har lov til at være; scoped keys lader dig give et stykke automatisering kun de privilegier, det faktisk har brug for, i stedet for en nøgle, der kan gøre alt.

Roller

Adgang til admin-API’et og admin-brugerfladen styres af roller. En rolle bestemmer, hvilke ressourcegrupper en principal må se, og hvilke de må ændre.

Roller administreres på admin-brugergrænsefladerne Roller side. Ud af boksen er der indbyggede roller — owner (alt), admin, operator og member — som kun kan læses (markeret med et “Indbygget” mærke; de kan ikke redigeres eller slettes). Udover dem kan du oprette tilpassede roller: rolleformularen tager et navn, en beskrivelse og et tilladelsesgitter — læse/skrive afkrydsningsfelter for hver af de ~19 ressourceområder (agenter, samtaler, værktøjer, adgangskoder, plugins, indstillinger, godkendelser, API-nøgler og så videre; “skrive” indebærer automatisk “læse”). Hver rolle viser, hvor mange emner der bruger den; en rolle, der er tildelt nogen, kan ikke slettes, før tildelingerne er fjernet.

Kombiner roller med de andre kontroller på dette sted — IP tilladelsesliste, virksomheds SSO og den revisionslog — så enhver administratorhandling både er godkendt og registreret.

Begrænsede API-nøgler

API-nøgler bærer områder der begrænser, hvad nøglen kan gøre. De definerede scopes er:

Omfang Tilskud
chat Slutbruger OpenAI-kompatibelt endepunkt (standardindstillingen for eksisterende nøgler).
admin:read Skrivebeskyttet adgang til admin-ressourcer (GET /v1/admin/*: indstillinger, samtaler, analyser osv.).
admin:write Mutation af admin-API-kald (POST/PUT/DELETE /v1/admin/*).
mcp Den offentliggjorte MCP-endpoint (POST /v1/mcp).
a2a Den offentliggjorte Agent-til-Agent-endpoint (POST /a2a/message).
* Fuld adgang til alt (det egentlige fulde adgangsområde).

Derudover en generisk <area>:* jokertegn virker: admin:*, for eksempel tilskud hver admin-handling men gør ikke tilskud chat, mcp eller a2a — det er ikke et separat defineret omfang, blot et tilfælde af jokertegnet. Kun * giver fuld adgang til alle overflader.

Nøgler, der blev præget, før scopes eksisterede, fortsætter med at fungere uden begrænsninger; nye nøgler kan præges med et snævert scope, så for eksempel et dashboard, der kun læser metrics, aldrig har en nøgle, der kan ændre indstillinger.

[!TIP] Anvend mindst privilegium: en overvågnings- eller rapporteringsintegration bør få en admin:read nøgle, ikke admin:write — for ikke at nævne *. Reserve * til nøgler der virkelig har brug for adgang til alle overflader.

At vælge det rigtige sigte

  • Chatklienter (ringe til den OpenAI-kompatible endpoint) → chat.
  • Læs-only integrationer (dashboards, eksportører, statuskontroller) → admin:read.
  • Automatisering, der opretter eller redigerer ressourcer (udbydere af tjenester, import) viden, styring af tidsplaner) → admin:write.
  • MCP- og A2A-klienter → mcp og a2a henholdsvis.
  • Knus-glass / fuld adgang → *, holdt med så få taster som muligt og drejet regelmæssigt.

[!WARNING] En scoped nøgle er stadig en legitimationsoplysning til admin-API’en. Opbevar den i hemmelighedskammer eller din egen hemmelige manager, aldrig i kontroller kilden, og udskift den, hvis den kan have været udsat.

Hvordan nøgler administreres

Admin API-nøgler administreres gennem admin API’et (/v1/admin/apikeys) og admin-brugergrænsefladen, hvor du opretter en nøgle, tildeler dens omfang og tilbagekalder den, når den ikke længere er nødvendig. Da admin-API’en selv er beskyttet af OIDC og IP-hvidliste, at udstede en nøgle er en autentificeret, revideret handling.

Hvor til næste