ACLs et principe du moindre privilège — Sécurité & conformité xAI

Le principe du moindre privilège appliqué aux API

Le principe du moindre privilège stipule que chaque composant d’un système ne doit avoir accès qu’aux ressources strictement nécessaires à son fonctionnement. Appliqué aux clés API xAI, cela signifie que chaque clé doit être limitée aux seuls endpoints et modèles requis par l’application qui l’utilise.

xAI implémente ce principe via un système d’ACLs (Access Control Lists) granulaire.

Le système d’ACLs de xAI

Structure des ACLs

Les ACLs suivent le format api-key:{type}:{valeur} :

Endpoint : api-key:endpoint:{endpoint} — restreint les endpoints accessibles
Modèle : api-key:model:{model_id} — restreint les modèles utilisables
Wildcard : api-key:endpoint:* — accès à tous les endpoints (à éviter en production)

Endpoints disponibles

Voici les endpoints que vous pouvez autoriser individuellement :

chat : complétion de chat (le plus courant)
embed : génération d’embeddings
image : génération et édition d’images
models : consultation de la liste des modèles
tokenize : tokenisation de texte
documents : gestion de documents
sample : échantillonnage

Exemple de clé restrictive

Pour un chatbot de support qui n’utilise que le modèle grok-3 en mode chat :

{
  "name": "support-chatbot-prod",
  "acls": [
    "api-key:endpoint:chat",
    "api-key:model:grok-3"
  ],
  "qps": 5,
  "qpm": 100,
  "tpm": 500000,
  "expireTime": "2026-12-31T23:59:59Z"
}

Cette clé :

Ne peut accéder qu’à l’endpoint chat (pas d’images, pas d’embeddings)
Ne peut utiliser que le modèle grok-3 (pas de modèles plus coûteux)
Est limitée à 5 requêtes/seconde et 100 requêtes/minute
A une date d’expiration définie

Limites de débit : une couche de sécurité supplémentaire

Au-delà des ACLs, les limites de débit protègent contre l’abus et les erreurs de programmation :

QPS (Queries Per Second)

Le nombre maximum de requêtes par seconde. Utile pour éviter les pics accidentels (boucle infinie, attaque DDoS).

QPM (Queries Per Minute)

Le nombre maximum de requêtes par minute. Lissage du trafic sur une période plus longue.

TPM (Tokens Per Minute)

Le nombre maximum de tokens par minute. Protège contre les requêtes individuelles très longues qui consommeraient le budget rapidement.

Stratégie de clés par environnement

Développement

{
  "name": "dev-team-alpha",
  "acls": ["api-key:endpoint:*", "api-key:model:*"],
  "qps": 2,
  "qpm": 30,
  "tpm": 100000,
  "expireTime": "2026-06-30T23:59:59Z"
}

Accès large mais débit limité pour éviter les surprises de facturation.

Staging

{
  "name": "staging-chatbot",
  "acls": ["api-key:endpoint:chat", "api-key:model:grok-3"],
  "qps": 5,
  "qpm": 100,
  "tpm": 500000,
  "expireTime": "2026-12-31T23:59:59Z"
}

Même ACLs que la production pour détecter les problèmes de permissions en amont.

Production

{
  "name": "prod-chatbot-v2",
  "acls": ["api-key:endpoint:chat", "api-key:model:grok-3"],
  "qps": 20,
  "qpm": 600,
  "tpm": 2000000,
  "expireTime": "2027-03-31T23:59:59Z"
}

Permissions strictes, débit adapté au trafic réel, expiration planifiée.

Vérification des permissions d’une clé

Pour auditer les permissions d’une clé en cours d’utilisation :

curl https://api.x.ai/v1/api-key \
  -H "Authorization: Bearer $XAI_API_KEY"

Réponse :

{
  "acls": ["api-key:endpoint:chat", "api-key:model:grok-3"],
  "api_key_blocked": false,
  "api_key_disabled": false,
  "redacted_api_key": "xai-...abc",
  "team_id": "team_xyz"
}

Vérifiez régulièrement que les ACLs correspondent bien aux besoins réels de l’application.

Les modèles accessibles par équipe

L’endpoint GET /auth/teams/{teamId}/models retourne la liste des modèles disponibles pour votre équipe, avec leurs tarifs. Utilisez cette information pour définir des ACLs modèle appropriées et éviter l’utilisation accidentelle de modèles coûteux.

Mise en pratique : audit de sécurité des clés

Réalisez cet audit sur toutes vos clés API :

Listez toutes les clés actives de chaque équipe
Pour chaque clé, vérifiez :
- Les ACLs sont-elles minimales ? (pas de wildcard * en production)
- Les limites de débit sont-elles raisonnables ?
- La date d’expiration est-elle définie ?
- Le nom est-il descriptif ? (identifier l’application et l’environnement)
Supprimez les clés inutilisées ou orphelines
Documentez le résultat de l’audit

Points clés à retenir

Chaque clé doit avoir des ACLs restrictives : uniquement les endpoints et modèles nécessaires
N’utilisez jamais de wildcard * en production
Combinez les ACLs avec des limites de débit (QPS, QPM, TPM) adaptées
Créez des clés distinctes par environnement (dev, staging, prod) et par application
Auditez régulièrement les permissions de vos clés actives