Contrôles d'équipe basés sur SCIM pour une passerelle AI API : provisionner des utilisateurs, révoquer des clés et maintenir les comptes de service en cours d'exécution
Utilisez SCIM et SSO comme entrées du cycle de vie, puis laissez la passerelle appliquer des rôles explicites, des profils de modèle, des autorisations de dépenses, la propriété des clés et des règles de transfert de compte de service. L’objectif est un déploiement rapide sans interrompre les applications de production.
Le départ d'une personne ne doit pas devenir un exercice de panne. Dans de nombreuses équipes, le fournisseur d'identité peut désactiver rapidement l'employé, mais la passerelle API AI dispose toujours de clés de développeur de longue durée, de scripts partagés, de comptes de service de production, de locataires revendeurs et de privilèges de facturation qui ne correspondent pas clairement à un seul compte humain. Le modèle pratique consiste à utiliser SCIM comme entrée du cycle de vie, puis à conserver l'autorisation, la propriété des clés, les limites de dépenses, l'accès au modèle et les enregistrements d'audit en tant qu'objets de passerelle explicites.
Le problème : les modifications d'identité ne sont pas la même chose que l'autorisation API
SSO indique si un utilisateur peut se connecter. SCIM permet d'automatiser le provisionnement des utilisateurs et des groupes. Ni l'un ni l'autre, à lui seul, ne répond à toutes les questions opérationnelles qu'une passerelle AI doit appliquer : quel locataire cet utilisateur peut-il administrer, quels profils de modèle peut-il utiliser, quelles clés sont personnelles, quelles clés exécutent la production, qui peut approuver les augmentations de budget et quels objets client de l'API partenaire peuvent-ils toucher ?
Une architecture propre traite l'identité comme la source des événements du cycle de vie, et non comme un modèle d'autorisation complet. La passerelle doit recevoir les modifications des utilisateurs et des groupes du fournisseur d'identité, les normaliser et les traduire en enregistrements natifs de la passerelle. Ces enregistrements doivent ensuite être évalués au moment de l'exécution pour les actions d'administration, la création de clés API, l'accès au modèle, les limites de dépenses, la propriété du compte de service et les exportations d'audit.
Fait : SCIM 2.0 est un protocole standard de l'IETF pour la gestion des identités entre domaines. Son comportement de protocole est spécifié dans la RFC 7644 et ses schémas de ressources sont spécifiés dans la RFC 7643. SCIM offre aux équipes un moyen standard de créer, mettre à jour, désactiver et regrouper des utilisateurs sur plusieurs systèmes.
Recommandation : Ne placez pas l'autorisation de passerelle directement dans les noms de groupes d'IdP ou les chemins de requête. Utilisez les groupes SCIM comme entrées dans une table de mappage contrôlée, puis évaluez les rôles et les politiques de passerelle à partir des enregistrements appartenant à la passerelle.
Objets de base que la passerelle devrait posséder
La passerelle a besoin de son propre modèle d'autorisation, car l'accès LLM allie sécurité, coût et continuité opérationnelle. Au minimum, définissez ces enregistrements comme des objets de première classe :
- Identité : l'utilisateur humain provisionné, lié au sujet, à l'adresse e-mail, au statut et aux appartenances au groupe de l'IdP.
- Locataire ou espace de travail : limite administrative pour les utilisateurs, les clés, les budgets, les profils de modèle, les intégrations et l'utilisation.
- Rôle : autorisations de passerelle telles que développeur, administrateur de locataire, administrateur de facturation, administrateur de modèle, auditeur ou administrateur de l'API partenaire.
- Profil de modèle : un ensemble autorisé de modèles, de règles de routage, de contraintes de gestion des données et de portes de fonctionnalités.
- Autorité budgétaire : qui peut dépenser, augmenter les limites, créer des clés coûteuses ou approuver des exceptions temporaires.
- Clé API humaine : clé créée pour une personne, généralement révoquée ou suspendue lorsque cette personne quitte l'établissement.
- Compte de service : une identité d'application avec les propriétaires, l'objectif, l'environnement, les métadonnées de rotation, l'horodatage de la dernière utilisation et la stratégie associée.
- Événement d'audit : enregistrement simplifié des décisions d'identité, de rôle, de clé, de budget et d'autorisation.
Cette séparation rend le départ déterministe. Un utilisateur peut devenir inactif sans supprimer les comptes de service correctement enregistrés en tant qu'identités d'application. Un administrateur de locataire peut perdre son autorité de facturation sans perdre l’accès de base à l’audit en lecture seule. Un revendeur peut gérer les locataires clients attribués sans pouvoir énumérer les locataires non liés.
Flux de provisionnement : de l'événement SCIM à l'accès à la passerelle
Un flux de provisionnement utile est ennuyeux de par sa conception. Il doit tolérer les tentatives, les mises à jour partielles et la synchronisation de groupe retardée. Les implémentations SCIM diffèrent en termes de timing, de comportement de suppression ou de désactivation, de mappages d'attributs et de prise en charge des groupes. La passerelle doit donc éviter les hypothèses fragiles.
1. Ingérer et normaliser l'utilisateur
Lorsque la passerelle reçoit un événement de création ou de mise à jour d'utilisateur SCIM, elle doit insérer l'enregistrement d'identité à l'aide d'un identifiant externe stable. Stockez le statut de l'utilisateur, le nom d'affichage, l'adresse e-mail, le service ou le centre de coûts si disponible, ainsi que les références brutes du groupe IdP sous une forme normalisée. Évitez d'utiliser l'e-mail comme seul identifiant immuable ; les e-mails changent.
Exemples de champs d'identité normalisés :
{
"external_subject": "utilisateur-idp-12345",
"email": "[email protected]",
"actif": vrai,
"groups": ["llm-developers", "support-ai-prod"],
"cost_center": "support",
"last_scim_event_at": "2026-08-30T10:14:00Z"
2. Traduire les groupes en rôles de passerelle
Utilisez une table de traduction gérée par la passerelle. Chaque ligne doit lier une référence de groupe IdP à un locataire, un rôle et des profils facultatifs tels que des modèles autorisés ou des classes budgétaires. Les groupes non mappés ne devraient rien accorder. Les mappages privilégiés doivent nécessiter un examen, en particulier par l'administrateur de facturation, l'administrateur du modèle, le propriétaire du locataire et l'administrateur de l'API partenaire.
{
"idp_group": "support-ai-prod",
"locataire": "support",
"role": "développeur",
"model_profile": "support-approved-models",
"budget_profile": "budget-d'équipe-standard",
"requires_review": faux
Recommandation : utilisez le refus par défaut pour les groupes non mappés. Il est préférable qu'un groupe nouvellement créé ne produise aucun accès IA plutôt que d'hériter accidentellement du modèle de production ou de l'autorité de facturation parce qu'une chaîne correspond à un préfixe de chemin.
3. Matérialiser un accès efficace
Après la traduction du groupe, matérialisez l'accès effectif à la passerelle de l'utilisateur : adhésions de locataires, rôles, profils de modèle, autorisations de création de clés, autorité budgétaire et autorisations d'intégration. Les contrôles d'exécution doivent lire cette vue matérialisée ou un service d'autorisation fortement cohérent, et non analyser les chaînes de groupe d'IdP à chaque requête.
Cela donne également aux administrateurs un aperçu des accès utilisable : "montrez-moi tous ceux qui peuvent créer des clés dans le locataire de support", "montrez-moi qui peut augmenter les limites de dépenses mensuelles" et "montrez-moi tous les utilisateurs qui peuvent accéder à des modèles de raisonnement coûteux".
Séparer les clés humaines des comptes de service
La distinction opérationnelle la plus importante est simple : une clé humaine représente une personne ; un compte de service représente une application. Traiter les deux comme des clés API génériques crée un risque de délocalisation.
Les clés humaines doivent hériter du cycle de vie de l'utilisateur humain. Lorsque l'utilisateur devient inactif, la passerelle doit bloquer la création de nouvelles clés et suspendre ou révoquer les clés personnelles. Ces clés doivent également comporter des métadonnées sur le propriétaire, le locataire, le profil de modèle, le profil budgétaire, l'horodatage de la dernière utilisation et l'objectif afin que les équipes puissent détecter les utilisations abusives avant le jour du départ.
Les clés de compte de service ne doivent pas appartenir à un seul employé qui part, ce qui pourrait interrompre la production. Un compte de service doit avoir au moins deux propriétaires humains ou un groupe propriétaire, une étiquette d'environnement, une stratégie de rotation, la visibilité de la dernière utilisation et un profil de stratégie. Il doit rester actif lorsqu'un propriétaire quitte, à condition qu'un autre propriétaire valide ou un processus de bris de vitre existe.
Fait : Les principales directives concernant le cloud découragent généralement les clés de compte de service de longue durée non gérées et recommandent de limiter les exceptions. Le même principe s'applique aux clés AI Gateway : gardez les identités des applications explicites, limitées, examinées et alternées.
Recommandation : Si une clé personnelle est utilisée pour une tâche sans surveillance, ne la conservez pas silencieusement pendant la déconnexion. Mettez-le en quarantaine, signalez-le comme utilisation de production mal classée, exigez un transfert de propriété et remplacez-le par une clé de compte de service conformément à la politique.
Concevoir le déprovisionnement en tant que machine à états
Le déprovisionnement doit être un workflow, et non une simple commande de suppression. Une machine à états donne à la passerelle suffisamment de structure pour réduire rapidement les risques tout en préservant l'auditabilité et la continuité de la production.
État 1 : déprovisionnement reçu
La passerelle reçoit un événement de désactivation, de suppression, de suppression de groupe ou un événement de cycle de vie équivalent. Enregistrez l'événement, sa source et l'accès effectif précédent. Étant donné que les événements IdP peuvent être réessayés ou arriver dans le désordre, rendez cette étape idempotente.
État 2 : utilisateur marqué comme inactif
Définissez l'identité de la passerelle sur inactive. Bloquez la connexion interactive, les actions d'administration, la création de nouvelles clés, la création de nouveaux comptes de service et les modifications budgétaires. Cela devrait se produire avant l'exécution de tâches de nettoyage plus lentes.
État 3 : clés personnelles suspendues
Suspendez les clés humaines immédiatement ou après une courte période de grâce définie par la politique. La solution par défaut la plus sûre est la suspension immédiate. Pour l'expérience des développeurs, la passerelle peut renvoyer une erreur d'authentification claire qui pointe les administrateurs vers le propriétaire inactif, l'ID de clé, le locataire et la dernière utilisation réussie.
État 4 : transfert de propriété requis
Recherchez les ressources appartenant à l'utilisateur inactif : comptes de service, locataires, profils de modèle, intégrations, contacts de facturation, informations d'identification de l'API partenaire et canaux d'alerte. Transférez automatiquement la propriété lorsqu’un groupe propriétaire valide existe. Sinon, placez la ressource dans une file d'attente « propriétaire des besoins ».
État 5 : notifications et examen
Avertissez les propriétaires de locataires, les administrateurs de sécurité ou les administrateurs de facturation. La notification doit inclure les clés concernées, les horodatages de la dernière utilisation, l'utilisation au cours des 30 et 90 derniers jours, les comptes de service nécessitant un nouveau propriétaire et toutes les clés personnelles ayant récemment servi le trafic de production.
État 6 : Finalisation
Une fois que les règles de conservation le permettent, finalisez la suppression ou l'anonymisation des attributs utilisateur tout en préservant les enregistrements d'audit requis. L’audit du cycle de vie des identités ne nécessite généralement pas d’invites brutes. Stockez les événements réduits en invite qui décrivent la décision politique, les ID d'objet, l'acteur, le locataire, l'horodatage et le résultat.
L'accès aux modèles et les limites de dépenses appartiennent à la même revue
L'autorisation de la passerelle AI ne concerne pas seulement qui peut appeler un point de terminaison. Un utilisateur peut être autorisé à appeler des modèles de développement à faible coût, mais pas des modèles de raisonnement à coût élevé, des outils hébergés, des tâches par lots ou des alias de production. Un utilisateur peut être autorisé à dépenser à partir du budget d'une équipe, mais ne pas approuver une augmentation de budget.
Pour chaque rôle effectif, définissez le coût associé et les autorisations de modèle :
- Profils de modèle et alias internes autorisés.
- Coût estimé maximum par demande.
- Profil budgétaire mensuel ou quotidien
- Autorisation de créer des clés personnelles.
- Autorisation de créer ou de posséder des comptes de service.
- Autorisation d'utiliser des outils hébergés, le traitement de fichiers, des sessions en temps réel ou des charges de travail par lots.
- Autorisation d'afficher les analyses d'utilisation, les factures ou les exportations de centres de coûts.
Recommandation : créez une exportation d'examen des accès qui joint l'identité, les rôles de passerelle, les clés actives, les comptes de service, l'utilisation au cours des 30 et 90 derniers jours, les autorisations de modèle et l'autorité budgétaire. Ceci est plus utile qu'une simple liste d'utilisateurs, car il montre ensemble le risque opérationnel et le pouvoir d'achat.
API partenaire et autorisation multi-locataires
L'automatisation de l'API partenaire ajoute une autre limite d'autorisation. Une agence, un revendeur ou une plateforme peut fournir des locataires clients, des utilisateurs, des clés, des budgets et des exportations d'utilisation via une API. Les utilisateurs internes pilotés par SCIM ne devraient pas automatiquement bénéficier d'un accès étendu aux objets client simplement parce qu'ils administrent le propre locataire du partenaire.
Faites en sorte que chaque opération de l'API partenaire soit limitée à la fois par l'appelant et par le locataire client. Le provisionnement doit être idempotent : la création deux fois du même locataire client, du même mappage de groupe ou du même utilisateur doit converger vers un état attendu. Les points de terminaison de liste ne doivent renvoyer que les objets que l'appelant est explicitement autorisé à administrer.
Cela est important car les échecs d'autorisation au niveau de l'objet et de la propriété de l'objet constituent des risques courants liés aux API. Dans une passerelle AI, les objets exposés sont sensibles : enregistrements de locataires, clés API, registres d'utilisation, budgets, autorisations de modèle, listes de membres et comptes de service. La passerelle doit tester ces chemins avec plusieurs identités et plusieurs ID de locataire, pas seulement avec un administrateur happy-path.
Les tests utiles incluent :
- L'administrateur du locataire A tente de lire, d'effectuer une rotation ou de révoquer les clés du locataire B.
- L'utilisateur suspendu essaie une ancienne clé API personnelle.
- L'administrateur revendeur tente d'énumérer les locataires clients n'appartenant pas.
- Le membre du projet tente de modifier les paramètres de facturation.
- Le propriétaire du compte de service essaie de s'attribuer l'administrateur de facturation.
- Les informations d'identification de l'API partenaire tentent de modifier les profils de modèle en dehors de leur portée client autorisée.
Audit sans thésaurisation rapide
Les enquêtes sur le cycle de vie des identités doivent généralement savoir qui a modifié l'accès, quelle stratégie a été évaluée, quel objet a été affecté et si l'action a réussi. Ils ne nécessitent généralement pas d'invites brutes. Conservez un flux d'audit distinct pour les décisions relatives à l'identité et aux politiques.
Enregistrer les événements tels que :
- Utilisateur provisionné, mis à jour, désactivé ou supprimé.
- Groupe mappé, non mappé ou rejeté.
- Rôle de passerelle accordé, modifié ou supprimé.
- Clé personnelle créée, suspendue, révoquée ou utilisée après la désactivation.
- Le propriétaire du compte de service a changé.
- Autorisation budgétaire accordée ou supprimée.
- Profil de modèle attaché ou détaché.
- Demande d'API partenaire refusée en raison de la portée du locataire.
Chaque événement doit inclure l'acteur, le sujet, le locataire, le type d'objet, l'ID d'objet, le système source, la décision, le code motif et l'horodatage. Utilisez des identifiants stables au lieu du contenu d'invite brut. Lorsque des détails sur la charge utile sont nécessaires, stockez les métadonnées de stratégie structurées plutôt que les entrées du modèle.
Liste de contrôle de mise en œuvre
Utilisez cette liste de contrôle lors de la mise en œuvre de contrôles d'équipe basés sur SCIM dans une passerelle AI :
- Définissez des objets natifs de passerelle pour le locataire, le rôle, l'utilisateur, la clé, le compte de service, le profil de modèle, le profil de budget et l'accès à l'intégration.
- Stockez le sujet de l'IdP externe séparément de l'e-mail.
- Rendre les upserts d'utilisateurs et de groupes SCIM idempotents.
- Utilisez une table de conversion groupe-rôle révisée avec un comportement de refus par défaut.
- Exiger une approbation explicite pour les mappages de rôles privilégiés.
- Distinguez les clés humaines des clés de compte de service dans le schéma et l'interface utilisateur.
- Empêcher les utilisateurs inactifs de se connecter, d'effectuer des actions d'administration, de créer des clés et de modifier leur budget.
- Suspendre les clés personnelles pendant la déprovisionnement.
- Transférer ou mettre en quarantaine les ressources appartenant à des utilisateurs inactifs.
- Exiger que les comptes de service disposent de métadonnées de propriétaire, d'objectif, d'environnement, d'horodatage de dernière utilisation et de métadonnées de rotation.
- Participez aux examens d'accès avec les analyses d'utilisation et l'autorité budgétaire.
- Testez l'autorisation au niveau de l'objet pour les locataires, les clients, les utilisateurs, les clés et les objets de facturation.
- Conserver les enregistrements d'audit d'identité avec une invite réduite par défaut.
Compromis
SCIM réduit la dérive des accès manuels, mais ne supprime pas le besoin d'une autorisation spécifique à la passerelle. Différents fournisseurs d'identité gèrent différemment la synchronisation des groupes, les suppressions, les désactivations, les tentatives et le mappage des attributs. La passerelle doit tolérer des informations partielles et converger en toute sécurité.
La révocation immédiate d'une clé personnelle réduit le risque de délocalisation, mais elle peut révéler une mauvaise hygiène opérationnelle lorsqu'une clé de développeur a été utilisée pour une tâche sans surveillance. Ce n’est pas une raison pour conserver indéfiniment les clés personnelles. C'est une raison pour détecter tôt l'utilisation de la clé personnelle en production et la migrer vers des comptes de service avant le départ d'un employé.
Les mappages de groupes précis peuvent exprimer une gouvernance précise, mais trop de groupes deviennent difficiles à auditer. Un ensemble plus restreint de rôles de passerelle, combinés à des profils de modèle et des profils budgétaires, est généralement plus facile à utiliser.
Les comptes de service assurent l'exécution des applications, mais ils peuvent perdre leur propriétaire ou devenir trop privilégiés. Exigez les propriétaires, les dates de révision, les métadonnées de rotation, les profils de modèles ciblés, les budgets ciblés et les dernières analyses utilisées.
Prédiction : les examens d'accès à la passerelle AI combineront de plus en plus l'identité, l'utilisation, l'autorité de dépense et les autorisations de modèle dans un seul rapport. Vérifier « qui a accès » sans indiquer « ce qu'ils peuvent dépenser et quelles clés sont encore actives » sera trop superficiel pour les équipes exécutant des charges de travail d'IA en production.
Conclusion exploitable
Le modèle durable consiste à laisser SCIM et SSO piloter le cycle de vie, puis à laisser la passerelle posséder l'autorisation. Approvisionnez les utilisateurs à partir du fournisseur d'identité, traduisez les groupes via des mappages révisés, matérialisez les rôles des locataires, liez explicitement les profils de modèle et de budget et traitez les clés humaines différemment des comptes de service.
Pour la désintégration, utilisez une machine d'état : recevez l'événement d'identité, marquez l'utilisateur comme inactif, bloquez les nouveaux accès, suspendez les clés personnelles, transférez ou mettez en quarantaine les ressources détenues, informez les propriétaires et finalisez la suppression une fois que les règles de conservation le permettent. Cela donne aux équipes de sécurité une révocation rapide, donne aux équipes de plate-forme une continuité de production et donne aux finances et aux auditeurs un enregistrement clair de qui avait l'autorité sur les modèles, les dépenses, les clés et les locataires.