Une revue d'accès à l'API d'IA est le contrôle qui prouve que chaque clé de passerelle a toujours le bon propriétaire, la bonne portée, le bon environnement, le bon plan de rotation et le bon chemin de gestion des départs. Ce n'est pas seulement une analyse des secrets. C'est la revue récurrente qui demande si chaque clé doit encore exister, qui en est responsable, ce qu'elle peut atteindre, quelles dépenses elle peut générer, quels journaux prouvent son utilisation et ce qui se passe lorsqu'une personne, un fournisseur, un projet ou une charge de travail quitte l'entreprise.
Ceci est plus important pour les passerelles d'IA que pour les clés d'API ordinaires à service unique. Une seule information d'identification de passerelle peut atteindre de nombreux modèles, fournisseurs, familles de points de terminaison, budgets et produits. Une clé obsolète pourrait maintenir en vie une automatisation retirée. Une clé à portée étendue pourrait permettre à une tâche de bac à sable d'appeler des modèles de production. La clé d'un sous-traitant parti pourrait encore envoyer des requêtes via une intégration partagée. Une route de secours pourrait continuer à utiliser un fournisseur que le service des achats n'approuve plus.
Utilisez cette revue d'accès à l'API d'IA pour transformer l'accès à la passerelle en un fichier de preuves appartenant à l'acheteur. La revue devrait permettre aux équipes de sécurité, de plateforme, des achats, des finances et des produits de répondre plus tard aux mêmes questions : qui possède cette clé, pourquoi existe-t-elle, quelles sont les portées autorisées, quand a-t-elle été renouvelée, quelles routes peut-elle appeler et quel événement de départ la révoque ?
Pour les acheteurs de Flatkey, la revue concerne le compte de la passerelle et la surface des clés/routes. Le site public actuel de Flatkey positionne le produit comme une passerelle d'API d'IA unique pour l'accès aux modèles, le routage, la facturation, l'analyse de l'utilisation et les contrôles opérationnels, avec une seule clé d'API, une seule URL de base et un seul tableau de bord. Cela fait de la passerelle un endroit utile pour centraliser les preuves d'accès. Cela ne supprime pas la nécessité de vérifier les rôles spécifiques au compte, les journaux, la gestion des charges utiles brutes, les conditions des fournisseurs et les procédures de gestion des départs avant l'utilisation en production.
Ce qu'une revue d'accès à l'API d'IA doit décider
Une revue d'accès à l'API d'IA doit approuver l'information d'identification et la route qu'elle peut atteindre. Si la revue s'arrête à « la clé fonctionne toujours », elle passe à côté du risque de gouvernance.
| Domaine de la revue | Décision à prendre | Preuve à conserver | Condition d'échec |
|---|---|---|---|
| Objectif commercial | Quel produit, flux de travail ou équipe a besoin de cette clé ? | Dossier de cas d'utilisation, approbation du propriétaire, étiquette d'environnement | Aucun propriétaire commercial actuel |
| Propriétaire humain | Qui accepte le risque et le budget pour cette clé ? | Propriétaire désigné, propriétaire de secours, mappage de manager ou d'équipe | Le propriétaire est parti, inconnu ou est seulement une boîte aux lettres partagée |
| Propriétaire technique | Qui peut renouveler, désactiver et dépanner la clé ? | Runbook, groupe d'astreinte, chemin du coffre de clés | Personne ne peut la renouveler en toute sécurité |
| Environnement | S'agit-il d'un accès de développement, de pré-production, de production, d'intégration continue, de fournisseur ou d'urgence ? | Étiquette d'environnement, périmètre du projet, configuration de la route | Une clé de non-production peut appeler des routes de production |
| Portée | Quels modèles, points de terminaison, outils, fichiers, prompts, exportations d'utilisation, API d'administration ou routes peut-elle utiliser ? | Liste des portées, mappage des rôles, paramètres du fournisseur | La portée est plus large que ce que la charge de travail nécessite |
| Budget et quota | Quelles limites de dépenses, de jetons, de débit et de modèles s'appliquent ? | Politique de quota, propriétaire de l'alerte, réviseur financier | La clé peut dépenser sans propriétaire désigné |
| Journalisation et audit | Quels événements prouvent l'utilisation et les changements ? | Métadonnées des requêtes, journaux de changement de route, journaux de changement de clé, lignes d'utilisation | L'utilisation ne peut pas être liée à la clé, au propriétaire, à la route et à l'heure |
| Rotation | Comment l'ancienne clé sera-t-elle remplacée sans interruption de service ? | Date de rotation, basculement vers la deuxième clé, vérification de la dernière utilisation, preuve de suppression | La clé n'a pas de déclencheur de rotation ou d'expiration |
| Gestion des départs | Quel événement révoque l'accès ? | Déclencheur de départ RH/fournisseur/projet, suppression du groupe, enregistrement de désactivation de la clé | La clé survit au départ de l'utilisateur, du fournisseur ou du projet |
Le résultat est un registre d'accès plus une liste d'actions : conserver, restreindre, renouveler, réaffecter, désactiver, supprimer ou escalader.
Construire d'abord le registre des clés
Ne commencez pas une revue d'accès à l'API d'IA en renouvelant les clés à l'aveugle. Construisez un registre qui décrit le rôle réel de la clé en production.
Chaque clé de passerelle devrait avoir ces champs :
| Champ | Pourquoi c'est important |
|---|---|
| Alias ou ID de la clé | Permet aux réviseurs de discuter de la clé sans exposer la valeur secrète |
| Projet ou espace de travail de la passerelle | Sépare les périmètres de produit, d'environnement, de client ou d'équipe |
| Propriétaire et propriétaire de secours | Empêche les accès orphelins et les rotations bloquées |
| Charge de travail ou intégration | Montre pourquoi la clé existe et où elle est déployée |
| Environnement | Empêche le développement, les tests, l'intégration continue et la production de partager des informations d'identification |
| Routes et modèles autorisés | Rend la revue d'accès à l'IA spécifique au comportement du modèle et du point de terminaison |
| Points de terminaison et outils autorisés | Indique si la clé peut appeler des API de chat, d'images, de vidéo, de fichiers, d'exécution d'outils ou d'administration |
| Portée ou rôle | Prouve le principe du moindre privilège plutôt qu'un accès administrateur hérité |
| Emplacement de stockage du secret | Indique si la clé se trouve dans un coffre-fort, un magasin de secrets d'intégration continue, un fichier local ou un emplacement non pris en charge |
| Dernière utilisation et modèle d'utilisation | Sépare les clés actives des informations d'identification obsolètes ou divulguées |
| Propriétaire des coûts et quota | Lie les dépenses du modèle à un propriétaire de budget |
| Date et méthode de rotation | Indique quand et comment la clé peut être remplacée |
| Déclencheur de gestion des départs | Définit quel changement révoque ou restreint l'accès |
Le registre ne doit pas inclure les valeurs secrètes. Il doit inclure suffisamment de métadonnées pour renouveler et révoquer la clé rapidement.
Assigner les propriétaires avant les portées
Une revue d'accès à l'API d'IA échoue lorsque chaque clé appartient à « l'ingénierie » ou à « l'équipe plateforme ». La propriété partagée fait que l'accès persiste après le départ des employés, des sous-traitants, des fournisseurs et la fin des projets.
Utilisez quatre rôles de propriétaire :
| Rôle du propriétaire | Responsable de | Devrait approuver |
|---|---|---|
| Propriétaire métier | Déterminer si le workflow a toujours besoin d'un accès à l'IA | Conserver, retirer ou transférer la clé |
| Propriétaire technique | Rotation, stockage, déploiement, restauration et réponse aux incidents | Plan de rotation et preuve de basculement |
| Propriétaire de la sécurité | Portée, moindre privilège, journalisation, exposition des données et gestion des départs | Modifications de la portée et gestion des exceptions |
| Propriétaire financier ou opérationnel | Dépenses, quotas, anomalies d'utilisation et rapprochement des factures | Budget et politique de quotas |
Le propriétaire métier et le propriétaire technique ne doivent pas être la même personne, sauf si l'équipe est très petite. Une clé de production nécessite une personne qui accepte le risque métier et une autre qui peut modifier les informations d'identification en toute sécurité.
Pour les clés appartenant à des humains, exigez une personne nommée ainsi qu'une équipe. Pour les clés de service, exigez un compte de service, une identité de charge de travail, un référentiel, un pipeline de déploiement et un groupe de propriétaires. Pour les clés de fournisseur, exigez un propriétaire de contrat, un propriétaire de données, une date d'expiration et un plan de suppression.
Examiner les portées par rapport à la charge de travail réelle
Le principe du moindre privilège est au cœur d'une revue d'accès à l'API d'IA. La question n'est pas « cet utilisateur a-t-il besoin de l'IA ? » La question est « de quelles actions d'API exactes cette charge de travail a-t-elle besoin ? »
Les directives RBAC d'OpenAI constituent un modèle utile, car elles séparent les rôles d'organisation, les rôles de projet, les groupes, les autorisations, les clés d'API de projet, l'administration de projet et les comptes de service. Elles notent également que les limites de projet peuvent isoler les expérimentations, la préproduction et la production. Appliquez le même raisonnement pour n'importe quelle passerelle d'IA : limitez la portée de la clé au plus petit projet, à la plus petite route, au plus petit point de terminaison, à la plus petite classe de modèle et au plus petit ensemble d'actions qui prend en charge la charge de travail.
La documentation sur la fédération d'identité de charge de travail d'OpenAI ajoute un autre modèle important : les identités externes peuvent être mappées à un compte de service, un projet et des autorisations d'API facultatives spécifiques, et ces autorisations de mappage ne peuvent pas accorder un accès au-delà du compte de service mappé. C'est le bon modèle mental pour l'accès à la passerelle : une tâche de CI, une charge de travail de serveur ou une automatisation ne doit pas hériter de l'accès étendu à la console d'un propriétaire humain.
Pour chaque clé, enregistrez si elle peut :
- Effectuer des requêtes de modèle.
- Utiliser uniquement des modèles approuvés ou des routes de secours.
- Appeler des points de terminaison de fichier, de vecteur, de prompt, d'évaluation, de lot, d'image, d'audio, de vidéo ou d'administration.
- Lire les exportations d'utilisation ou les données de facturation.
- Modifier les routes, les quotas, les clés, les rôles, les journaux ou les paramètres du fournisseur.
- Accéder aux prompts bruts, aux sorties, aux arguments d'outils, aux fichiers, aux traces ou uniquement aux métadonnées.
Comparez ensuite la portée réelle avec la portée nécessaire :
| Si la clé a seulement besoin de... | Elle ne devrait pas également pouvoir... |
|---|---|
| Appeler une route de chat de production | Gérer les clés, les utilisateurs, les routes, la facturation ou les comptes de fournisseur |
| Exécuter des évaluations de préproduction | Appeler des routes de production ou des sources de données client |
| Générer des images dans une tâche par lots | Lire des fichiers, des prompts ou des exportations d'utilisation non liés |
| Exporter l'utilisation pour la finance | Modifier les modèles, les prompts, les quotas ou les routes de la passerelle |
| Exécuter des tests de fumée CI | Utiliser des informations d'identification humaines à longue durée de vie |
| Prendre en charge une intégration de fournisseur | Accéder à des routes internes ou à d'autres environnements client |
Si un fournisseur ou une passerelle n'expose pas de portées granulaires, compensez par la séparation des projets, la séparation des routes, les limites de quota, les restrictions d'IP ou de charge de travail, une cadence de rotation plus courte et une surveillance renforcée.
Effectuer la rotation des clés avec un plan de basculement
La rotation est une tâche de fiabilité, pas seulement une tâche de sécurité. Les directives de mise à jour des clés d'accès d'AWS décrivent le modèle pratique : créer une deuxième clé pendant que la première est encore active, mettre à jour les applications pour utiliser la nouvelle clé, vérifier l'utilisation de l'ancienne clé, la désactiver avant de la supprimer, attendre suffisamment longtemps pour intercepter les appelants manqués, puis la supprimer. Cette séquence est utile pour les clés de passerelle d'IA, car une suppression soudaine peut interrompre les appels de modèle, les tâches en arrière-plan et les agents en contact avec les clients.
Les directives sur les clés de compte de service de Google Cloud traitent également les clés de compte de service comme des informations d'identification sensibles et recommandent des alternatives d'authentification plus sécurisées lorsque cela est possible. Sa documentation sur la rotation des clés renforce le fait que la rotation doit être planifiée, et non improvisée après une exposition.
Utilisez ce processus de rotation :
| Étape | Action | Preuve |
|---|---|---|
| 1. Préparer | Confirmer le propriétaire, la charge de travail, l'emplacement de la clé, les routes, les quotas et le chemin de restauration | Ligne de registre et runbook |
| 2. Créer un remplacement | Générer une nouvelle clé ou un nouveau mappage de charge de travail sans supprimer l'ancien | Nouvel ID de clé, heure de création, propriétaire |
| 3. Déployer | Mettre à jour le coffre-fort, le secret CI, le secret d'exécution ou l'intégration de la passerelle | Enregistrement de déploiement ou ticket de modification |
| 4. Test de fumée (Smoke test) | Envoyer des requêtes contrôlées via chaque route approuvée | ID de requête, route, modèle, statut, échantillon de coût |
| 5. Surveiller l'ancienne clé | Vérifier les données de dernière utilisation, les journaux et les alertes d'erreur pour le trafic de l'ancienne clé | Capture d'écran de la dernière utilisation ou lecture de l'API |
| 6. Désactiver | Désactiver l'ancienne clé avant de la supprimer lorsque la plateforme prend en charge cet état | Horodatage de désactivation et propriétaire |
| 7. Supprimer | Supprimer l'ancienne clé après la fenêtre d'observation | Preuve de suppression |
| 8. Clôturer | Mettre à jour le registre et la prochaine date de revue | Enregistrement de la revue d'accès |
La rotation d'urgence ignore la longue fenêtre d'observation mais n'ignore pas les preuves. Si une clé est divulguée, révoquez-la, effectuez une rotation des charges de travail dépendantes, recherchez le secret exposé dans le code et les journaux, et enregistrez les systèmes qui ont été testés par la suite. Le guide de gestion des secrets (Secrets Management Cheat Sheet) de l'OWASP est utile ici car il traite l'audit, la rotation, la révocation, la suppression et la détection du cycle de vie comme faisant partie de la gestion des secrets.
La gestion des départs doit révoquer plus que la connexion de l'utilisateur
La gestion des départs (offboarding) est le point où de nombreux programmes de revue d'accès à l'API d'IA échouent. Supprimer une personne du SSO ne supprime pas toujours les clés de service, les secrets CI, les identifiants de fournisseurs partagés, les fichiers .env locaux, les clés de console du fournisseur de modèles ou les clés de passerelle créées sous le compte de cette personne.
Créez des déclencheurs de gestion des départs pour :
- Départ d'un employé.
- Départ d'un sous-traitant ou d'un fournisseur.
- Transfert d'équipe.
- Arrêt d'un projet.
- Archivage d'un référentiel.
- Migration de l'environnement client.
- Remplacement du compte fournisseur.
- Mise hors service de la route de la passerelle.
- Incident de sécurité ou suspicion d'exposition de clé.
Pour chaque déclencheur, décidez de ce qui doit se passer :
| Déclencheur de gestion des départs | Action requise | Preuve à conserver |
|---|---|---|
| Départ du propriétaire humain | Réattribuer le propriétaire métier et technique ; effectuer une rotation des clés créées par l'utilisateur | Suppression RH/IdP, mise à jour du propriétaire, journal de rotation |
| Départ du sous-traitant | Supprimer les rôles du projet, révoquer les clés du fournisseur, effectuer une rotation des clés d'intégration partagées | Ticket de gestion du départ du fournisseur |
| Compte de service retiré | Désactiver la route, révoquer la clé, supprimer le secret CI, supprimer l'entrée de coffre-fort inutilisée | Lecture de la route et preuve de suppression du secret |
| Arrêt du projet | Désactiver toutes les clés du projet et archiver les preuves d'utilisation/facturation | Checklist de clôture du projet |
| Changements de fournisseur | Effectuer une rotation de la clé côté fournisseur et du secret côté passerelle | Preuve de la console du fournisseur et test de la passerelle |
| Route mise hors service | Supprimer la route du modèle, la solution de repli, le quota, les alertes et la clé exposée | Preuve de suppression de la route |
| Suspicion de fuite de clé | Révocation immédiate, rotation, recherche, revue d'incident | Chronologie de l'incident et test post-rotation |
N'attendez pas la revue trimestrielle pour gérer les départs. La revue trimestrielle d'accès à l'API d'IA doit vérifier que les déclencheurs de gestion des départs ont fonctionné.
Utiliser un fichier de preuves spécifique à la passerelle
Pour les passerelles d'IA, une revue IAM normale n'est pas suffisante. Le fichier de preuves doit relier l'accès par clé au comportement des routes d'IA, aux dépenses des modèles et aux limites des fournisseurs.
| Élément de preuve | Ce que les examinateurs doivent voir |
|---|---|
| ID de clé ou alias | Identifiant stable et non secret |
| Mappage des propriétaires | Propriétaire métier, propriétaire technique, examinateur de la sécurité, examinateur financier |
| Liste des routes | Routes de passerelle, modèles, fournisseurs, familles de points de terminaison et solutions de repli approuvés |
| Liste des portées | Actions que la clé peut effectuer et actions explicitement refusées |
| Limite de l'environnement | Environnement de développement, de pré-production, de production, CI, fournisseur ou client |
| Emplacement du secret | Coffre-fort, magasin de secrets CI, gestionnaire de secrets cloud ou autre emplacement approuvé |
| Dernière utilisation | Utilisation récente par route, modèle et charge de travail |
| Événements de modification | Qui a créé, effectué une rotation, désactivé, supprimé ou modifié la clé |
| Preuve de coût | Lignes d'utilisation, quota, solde, propriétaire de la facture, seuil d'alerte |
| Preuve de données | Si les prompts, les sorties, les fichiers, les traces et les métadonnées sont stockés ou exportés |
| Enregistrement de rotation | Création de nouvelle clé, désactivation de l'ancienne clé, suppression de l'ancienne clé, tests de fumée (smoke tests) |
| Déclencheur de gestion des départs | Condition utilisateur, équipe, fournisseur, charge de travail ou projet qui révoque l'accès |
| Exceptions | Accès large temporaire, date d'expiration, approbateur et contrôles compensatoires |
Connectez ce fichier à la checklist de la passerelle API d'IA d'entreprise, aux journaux d'audit pour l'utilisation de l'API d'IA, et à l'évaluation des risques des fournisseurs d'API d'IA. La revue d'accès décide qui peut appeler la passerelle. Le journal d'audit prouve ce qui a changé. La revue des risques des fournisseurs prouve quelles limites des fournisseurs en amont s'appliquent toujours.
Checklist de la revue d'accès aux clés API
Exécutez cette liste de contrôle pour chaque projet de passerelle de production, projet de préproduction à haut risque, intégration de fournisseur et automatisation CI pouvant appeler des modèles d'IA.
- Exportez l'inventaire des clés.
Extrayez chaque clé de passerelle, clé de fournisseur, compte de service, mappage d'identité de charge de travail, secret CI et identifiant de fournisseur pouvant initier des requêtes d'IA.
- Confirmez les propriétaires actifs.
Associez chaque clé à un propriétaire métier, un propriétaire technique, un réviseur de sécurité et un propriétaire des coûts. Réattribuez ou désactivez les clés orphelines.
- Confirmez l'objectif de la charge de travail.
Liez la clé à une fonctionnalité de produit, une automatisation, un référentiel, un fournisseur, un environnement client ou un flux de travail opérationnel.
- Vérifiez la séparation des environnements.
Confirmez que les accès de développement, de préproduction, de production, CI, fournisseur et d'urgence ne partagent pas la même clé.
- Examinez les portées et les routes.
Comparez les portées autorisées, les modèles, les familles de points de terminaison, les routes de secours, les comptes de fournisseur, les autorisations d'outils, les fichiers, les invites et les capacités d'administration avec les besoins réels de la charge de travail.
- Examinez l'utilisation et les preuves de la dernière utilisation.
Recherchez les clés inutilisées, le trafic inhabituel, les modèles inattendus, les pics d'activité en dehors des heures de bureau, les nouvelles zones géographiques ou les schémas de dépenses qui ne correspondent pas au propriétaire.
- Examinez la journalisation et la gestion des données.
Confirmez quelles métadonnées, invites, sorties, fichiers, traces et lignes de facturation sont stockés. Utilisez la liste de contrôle pour la rétention des données de l'API d'IA si la rétention de la charge utile et des métadonnées n'est pas claire.
- Effectuez une rotation ou restreignez l'accès.
Pour chaque clé, choisissez de conserver, restreindre, effectuer une rotation, réattribuer, désactiver, supprimer ou remonter. Suivez l'action jusqu'à sa résolution.
- Testez la gestion des départs.
Sélectionnez des départs récents d'employés, de fournisseurs, de projets et de routes. Vérifiez que l'accès a été supprimé et que les clés obsolètes n'ont pas survécu au départ.
- Définissez le prochain déclencheur.
Définissez la cadence des revues et les déclencheurs basés sur des événements : changement de propriétaire, changement de route, changement de modèle, changement de portée, changement de fournisseur, fuite de clé, incident, départ d'un fournisseur ou anomalie de coût.
Exemple de politique de route
La revue d'accès à l'API d'IA doit produire une politique que les ingénieurs peuvent mettre en œuvre. Le schéma exact dépend de votre passerelle, mais la forme du contrôle doit être explicite.
key_id: support-agent-prod-gateway
owners:
business: support_ops
technical: ai_platform
security: appsec
finance: finops
environment: production
workload:
service: support-agent-api
repository: support-platform
deployment: production
routes:
allowed:
- support-summary-prod
- support-classification-prod
denied:
- experimental-tools
- unrestricted-admin
models:
allowed_groups:
- approved-support-models
fallback_requires_same_data_policy: true
scopes:
allow:
- model_request
- usage_metadata_read
deny:
- key_management
- route_management
- raw_payload_export
- admin_api
quotas:
monthly_budget_usd: 500
alert_owner: finops
burst_limit: controlled
logging:
request_metadata: enabled
raw_payload_storage: verify_in_account
audit_events_required:
- key_created
- key_rotated
- key_disabled
- route_changed
rotation:
cadence: 90d_or_owner_change
method: create_second_key_cutover_deactivate_delete
last_completed: 2026-07-04
offboarding:
triggers:
- owner_departure
- vendor_exit
- service_retirement
- route_decommission
- suspected_exposure
exceptions:
allowed: false
Cette politique force la revue d'accès à devenir opérationnelle. Si la passerelle ne peut pas exprimer une décision directement, conservez la décision dans le fichier de preuves et ajoutez des contrôles compensatoires tels que des projets distincts, une configuration de route restreinte, un quota plus bas, une rotation plus courte et des alertes plus fortes.
Comment cela s'intègre-t-il avec Flatkey
Flatkey peut être la surface opérationnelle pour une revue d'accès à l'API d'IA car la surface publique du produit est centrée sur l'accès unifié aux modèles, une seule clé, une URL de base compatible avec OpenAI, le routage, la facturation, l'analyse de l'utilisation, les limites de quota et un tableau de bord pour les clés et le routage. La page d'accueil actuelle montre le modèle de routeur utilisant https://router.flatkey.ai/v1/chat/completions, tandis que les pages de tarification et de modèles décrivent l'accès aux modèles, la couverture des fournisseurs, le solde prépayé, l'analyse de l'utilisation et la facturation de l'API de production.
Utilisez Flatkey pour centraliser la revue, puis vérifiez ces détails spécifiques au compte avant de vous fier au contrôle :
- Quels rôles peuvent créer, afficher, faire pivoter, désactiver ou supprimer les clés de passerelle.
- Si les clés peuvent être séparées par projet, environnement, charge de travail, fournisseur et client.
- Quels modèles, fournisseurs, familles de points de terminaison et routes de secours chaque clé peut appeler.
- Quels quotas, soldes et alertes d'utilisation s'appliquent par clé ou par route.
- Quels événements d'audit existent pour les changements de clé, les changements de route, les changements de quota, les changements de journalisation et les changements de fournisseur.
- Si les invites brutes, les sorties, les fichiers, les arguments d'outils, les traces ou seulement les métadonnées sont conservés.
- Si la gestion des départs peut être liée aux utilisateurs, aux équipes, aux fournisseurs, aux projets et aux comptes de service.
L'avantage de la passerelle est la centralisation des preuves. L'acheteur reste propriétaire de la revue d'accès à l'API d'IA.
Cadence de la revue d'accès
Définissez des revues à la fois planifiées et basées sur des événements.
| Type de revue | Déclencheur | Action minimale |
|---|---|---|
| Revue opérationnelle mensuelle | Clés de passerelle de production | Examiner le propriétaire, la dernière utilisation, les dépenses, les appels échoués, les nouvelles routes |
| Revue de sécurité trimestrielle | Toutes les clés de production et de fournisseur | Reconfirmer le propriétaire, la portée, la rotation, la gestion des départs, les exceptions |
| Revue de version | Nouvelle route, nouveau modèle, nouveau point de terminaison, nouveau fournisseur ou solution de secours | Approuver la portée de la clé avant le lancement |
| Revue de gestion des départs | Départ d'un employé, d'un fournisseur, fin d'un projet ou d'un service | Réattribuer, faire pivoter, désactiver ou supprimer les clés concernées |
| Revue d'incident | Fuite, anomalie, dépense inattendue, abus, contournement de politique | Révoquer, faire pivoter, enquêter et mettre à jour les contrôles |
| Revue de renouvellement | Contrat, DPA, conditions du fournisseur, disponibilité du modèle, changement de tarification | Revalider les preuves du fournisseur et de la passerelle |
La règle la plus importante : chaque exception doit avoir une date d'expiration. Les clés à large portée, les clés partagées, les clés d'urgence et les clés de fournisseur nécessitent des propriétaires explicites, des dates d'expiration et des déclencheurs de revue.
FAQ
Qu'est-ce qu'une revue d'accès à l'API d'IA ?
Une revue d'accès à l'API d'IA est un contrôle de gouvernance récurrent qui confirme que chaque clé de passerelle ou de fournisseur d'IA a toujours un propriétaire, un objectif, une portée, une limite de route, un modèle d'utilisation, un plan de rotation, une piste d'audit et un déclencheur de gestion des départs valides.
En quoi une revue d'accès à l'API d'IA est-elle différente de la rotation des clés d'API ?
La rotation remplace un identifiant. Une revue d'accès à l'API d'IA décide si l'identifiant doit exister, qui en est le propriétaire, à quoi il peut accéder, comment il dépense de l'argent, quels journaux prouvent son utilisation et quel événement devrait le révoquer.
Qui devrait être propriétaire des clés de passerelle d'IA ?
Chaque clé de production devrait avoir un propriétaire métier, un propriétaire technique, un réviseur de sécurité et un propriétaire financier ou opérationnel. Les clés détenues par des humains ne devraient pas être l'identifiant à long terme pour les services de production ; les clés détenues par des services nécessitent une identité de charge de travail, un référentiel, un déploiement et des preuves de groupe de propriétaires.
À quelle fréquence les clés d'API d'IA doivent-elles être renouvelées ?
La cadence de rotation dépend du risque, des capacités de la plateforme et des exigences de conformité, mais les clés de production devraient avoir une cadence planifiée ainsi que des déclencheurs basés sur des événements. Effectuez une rotation immédiate après une exposition suspectée, le départ d'un propriétaire, le départ d'un fournisseur, un changement de portée, un changement de compte de fournisseur ou l'arrêt d'un projet.
Que devrait inclure la gestion des départs pour les clés d'API d'IA ?
La gestion des départs devrait inclure la suppression des rôles utilisateur, la réattribution ou la rotation des clés créées par les utilisateurs, la révocation des identifiants des fournisseurs, la suppression des secrets d'intégration continue (CI), la désactivation des comptes de service retirés et la vérification des journaux de la passerelle/du fournisseur pour détecter toute utilisation obsolète après la suppression.
Comment une passerelle d'IA aide-t-elle aux revues d'accès ?
Une passerelle d'IA peut centraliser les clés, la politique de routage, l'utilisation, les quotas, la facturation et les preuves de changement entre les fournisseurs. Elle ne remplace pas la revue du moindre privilège ou la vérification spécifique au compte. Utilisez la passerelle comme surface de preuve, puis vérifiez le comportement du fournisseur et du compte acheteur.
Conclusion
Une revue d'accès à l'API d'IA devrait rendre chaque identifiant de passerelle explicable. Tenez un registre, attribuez de vrais propriétaires, réduisez les portées, effectuez la rotation avec un plan de basculement, testez la gestion des départs et clôturez chaque exception avec des preuves. Lorsque vous êtes prêt à centraliser l'accès aux modèles d'IA, le routage, l'utilisation et la facturation derrière une seule passerelle, consultez les tarifs et le catalogue de modèles actuels de Flatkey, puis obtenez une clé.
