AiHummer
Français▾
ConnexionCompte
v1.1.x▾
v1.2.xstablev1.1.xstablev1.0.xstable
{ }Swagger
Sécurité/RBAC et clés API à portée

RBAC et clés API à portée

v1.1.x · mis à jour 2026-07-07

AiHummer protège sa surface d’administration avec contrôle d’accès basé sur les rôles et clés API limitées. Les rôles déterminent ce qu’une personne est autorisée à être ; les clés à portée permettent de donner à une partie de l’automatisation uniquement les privilèges dont elle a réellement besoin, au lieu d’une clé qui peut tout faire.

Rôles

L’accès à l’API d’administration et à l’interface utilisateur d’administration est régi par les rôles. Un rôle détermine quels groupes de ressources un principal peut consulter et quels groupes il peut modifier.

Les rôles sont gérés sur l’interface d’administration Rôles page. Prêt à l’emploi, il y a rôles intégrés — owner (tout), admin, operator et member — qui sont en lecture seule (marqués d’un badge « Intégré » ; ils ne peuvent pas être modifiés ou supprimés). Au-delà de ceux-ci, vous pouvez créer rôles personnalisés: le formulaire de rôle prend un nom, une description et une grille de permissions — cases à cocher lecture/écriture pour chacun des ~19 domaines de ressources (agents, conversations, outils, secrets, plugins, paramètres, approbations, clés API, etc. ; « écrire » implique automatiquement « lire »). Chaque rôle indique combien de sujets l’utilisent ; un rôle qui est attribué à quelqu’un ne peut pas être supprimé tant que les attributions ne sont pas supprimées.

Combinez les rôles avec les autres contrôles sur ce site — Liste d’autorisation IP, SSO d’entreprise et le journal d’audit — de sorte que chaque action d’administration soit à la fois autorisée et enregistrée.

Clés API limitées

Les clés API portent portées qui limitent ce que la clé peut faire. Les portées définies sont :

Portée Subventions
chat Le point de terminaison compatible OpenAI pour l’utilisateur final (l’option par défaut héritée pour les clés existantes).
admin:read Accès en lecture seule aux ressources administratives (GET /v1/admin/*: paramètres, conversations, analyses, etc.).
admin:write Modifier les appels API administrateur (POST/PUT/DELETE /v1/admin/*).
mcp Le point de terminaison MCP publié (POST /v1/mcp).
a2a Le point de terminaison Agent-à-Agent publié (POST /a2a/message).
* Accès complet à tout (la véritable portée de l’accès complet).

De plus, un générique <area>:* fonctionne avec des caractères génériques : admin:*, par exemple, des subventions chaque action d’administration mais fait pas accorder chat, mcp ou a2a — ce n’est pas un champ défini séparément, juste un cas du caractère générique. Seulement * accorde un accès complet à toutes les surfaces.

Les clés frappées avant l’existence des portées continuent de fonctionner sans restriction ; de nouvelles clés peuvent être frappées avec une portée limitée de sorte que, par exemple, un tableau de bord qui ne fait que lire des métriques ne détienne jamais une clé pouvant modifier les paramètres.

[!TIP] Appliquer le principe du moindre privilège : une intégration de surveillance ou de reporting devrait obtenir un admin:read clé, pas admin:write — sans parler de *. Réserver * pour les clés qui ont vraiment besoin d’accéder à chaque surface.

Choisir la bonne portée

  • Clients de chat (appel du point de terminaison compatible OpenAI) → chat.
  • Intégrations en lecture seule (tableaux de bord, exportateurs, contrôles de statut) → admin:read.
  • Automatisation qui crée ou modifie des ressources (agents de provisionnement, importation connaissance, gestion des horaires) → admin:write.
  • Clients MCP et A2A → mcp et a2a respectivement.
  • Briser le verre / accès complet → *, tenu par le moins de touches possible et tourné régulièrement.

[!WARNING] Une clé avec portée reste un identifiant pour l’API admin. Stockez-la dans le coffre-fort à secrets ou votre propre gestionnaire de secrets, jamais dans contrôle de la source, et faites-la pivoter si elle a pu être exposée.

Comment les clés sont gérées

Les clés API administrateur sont gérées via l’API administrateur (/v1/admin/apikeys) et l’interface d’administration, où vous créez une clé, attribuez sa portée et la révoquez lorsqu’elle n’est plus nécessaire. Parce que l’API d’administration elle-même est protégée par OIDC et la liste blanche IP, frapper une clé est une opération authentifiée et auditée.

Où aller ensuite