AiHummer
Deutsch
AnmeldenKonto
v1.0.x
{ }Swagger

RBAC & begrenzte API-Schlüssel

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

AiHummer schützt seine Admin-Oberfläche mit rollenbasierte Zugriffskontrolle und umfangsbezogene API-Schlüssel. Rollen entscheiden, wer eine Person sein darf; Scoped Keys ermöglichen es, einem Automatisierungsstück nur die Berechtigungen zu geben, die es tatsächlich benötigt, anstatt eines Schlüssels, der alles tun kann.

Rollen

Der Zugriff auf die Admin-API und die Admin-Benutzeroberfläche wird durch Rollen geregelt. Eine Rolle bestimmt, welche Ressourcengruppen ein Prinzipal einsehen und welche er ändern darf.

Rollen werden über die Admin-Oberflächen verwaltet Rollen Seite. Aus der Verpackung heraus gibt es eingebaute Rollenowner (alles), admin, operator und member — die schreibgeschützt sind (mit einem „Eingebaut“-Abzeichen gekennzeichnet; sie können nicht bearbeitet oder gelöscht werden). Darüber hinaus können Sie erstellen benutzerdefinierte Rollen: Das Rollenformular nimmt einen Namen, eine Beschreibung und ein Berechtigungsgitter an — Lese-/Schreib-Kontrollkästchen für jede der ~19 Ressourcen-Domänen (Agenten, Unterhaltungen, Werkzeuge, Geheimnisse, Plugins, Einstellungen, Genehmigungen, API-Schlüssel und so weiter; „schreiben“ impliziert automatisch „lesen“). Jede Rolle zeigt, wie viele Benutzer sie verwenden; eine Rolle, die jemandem zugewiesen ist, kann nicht gelöscht werden, bis die Zuweisungen entfernt werden.

Kombinieren Sie Rollen mit den anderen Steuerelementen auf dieser Website — IP-Positivliste, Unternehmens-SSO und der Prüfprotokoll — sodass jede Administratoraktion sowohl autorisiert als auch aufgezeichnet wird.

Gescopte API-Schlüssel

API-Schlüssel tragen Umfänge die einschränken, was der Schlüssel tun kann. Die definierten Bereiche sind:

Umfang Zuschüsse
chat Das OpenAI-kompatible Endbenutzer-Endpunkt (der alte Standard für bestehende Schlüssel).
admin:read Schreibgeschützter Zugriff auf Admin-Ressourcen (GET /v1/admin/*: Einstellungen, Unterhaltungen, Analysen usw.).
admin:write Mutierende Admin-API-Aufrufe (POST/PUT/DELETE /v1/admin/*).
mcp Der veröffentlichte MCP-Endpunkt (POST /v1/mcp).
a2a Der veröffentlichte Agent-zu-Agent-Endpunkt (POST /a2a/message).
* Vollzugriff auf alles (der wahre Vollzugriffsbereich).

Außerdem ein generisches <area>:* Wildcard funktioniert: admin:*, zum Beispiel Zuschüsse jede Admin-Aktion aber tut nicht gewähren chat, mcp oder a2a — es ist kein separat definierter Umfang, nur ein Fall des Platzhalters. Nur * gewährt vollen Zugriff auf alle Oberflächen.

Schlüssel, die vor der Existenz von Bereichen geprägt wurden, funktionieren weiterhin uneingeschränkt; neue Schlüssel können mit einem engen Bereich geprägt werden, sodass zum Beispiel ein Dashboard, das nur Metriken liest, niemals einen Schlüssel besitzt, der Einstellungen ändern könnte.

[!TIP] Wenden Sie das Prinzip der minimalen Rechte an: Eine Überwachungs- oder Berichtsintegration sollte erhalten admin:read Schlüssel, nicht admin:write — geschweige denn *. Reservieren * für Schlüssel die wirklich Zugang zu jeder Oberfläche benötigen.

Die richtige Reichweite wählen

  • Chat-Clients (Aufrufen des OpenAI-kompatiblen Endpunkts) → chat.
  • Nur-Lese-Integrationen (Dashboards, Exporteure, Statusprüfungen) → admin:read.
  • Automatisierung, die Ressourcen erstellt oder bearbeitet (Bereitstellungsagenten, Importieren Wissen, Zeitpläne verwalten) → admin:write.
  • MCP- und A2A-Kundenmcp und a2a jeweils.
  • Notfallzugang / Vollzugriff*, gehalten von so wenigen Tasten wie möglich und regelmäßig gedreht.

[!WARNING] Ein eingeschränkter Schlüssel ist immer noch ein Zugangsdaten für die Admin-API. Bewahren Sie ihn in der Geheimnis-Safe oder Ihrem eigenen Geheimnismanager, niemals in Quellenkontrolle und drehen Sie es, wenn es möglicherweise exponiert gewesen sein könnte.

Wie Schlüssel verwaltet werden

Admin-API-Schlüssel werden über die Admin-API verwaltet (/v1/admin/apikeys) und die Admin-Benutzeroberfläche, in der Sie einen Schlüssel erstellen, seinen Bereich zuweisen und ihn widerrufen, wenn er nicht mehr benötigt wird. Da die Admin-API selbst durch OIDC und die IP-Positivliste, das Erstellen eines Schlüssels ist eine authentifizierte, geprüfte Operation.

Wohin als Nächstes