Contrôle d'accès, gestion des identités et des secrets

Gains :

• Possibilité de séparer l'authentification et l'autorisation et d'appliquer une autorisation minimale avec RBAC/ABAC
• Possibilité d'éviter les risques de proxy mixte en exécutant le modèle dans le contexte utilisateur
• Possibilité de stocker et de faire pivoter les clés API avec le système de gestion des secrets

Une part importante des attaques contre un système d’IA ne commencent pas par « tromper » le modèle, mais par le vol d’une clé API ou un compte surautorisé. Cette couche de sécurité vient de la sécurité classique de l'information, mais ajoute de nouveaux risques dans le contexte de l'IA : un modèle appelle un trajet pour le compte de quelqu'un d'autre, un compte de service accède à toutes les données, une clé fuit vers GitHub. Dans cette unité, nous apprendrons comment restreindre l'accès au système d'IA avec l'authentification, l'autorisation (RBAC/ABAC), l'autorisation minimale et la gestion des secrets.

Différence entre l'authentification et l'autorisation

Les deux termes sont souvent confondus :

• Authentification : « Qui êtes-vous ? » — prouver que l'utilisateur/service est bien celui qu'il prétend être (mot de passe, jeton, certificat, MFA).
• Autorisation : « Que pouvez-vous faire ? — déterminer à quelle ressource/action la partie authentifiée peut accéder.

La subtilité essentielle des systèmes d'IA est la suivante : lorsque le modèle effectue un travail pour le compte d'un utilisateur, fonctionne-t-il avec l'autorité de cet utilisateur ou avec un compte de service étendu ? Ce dernier est dangereux, car le modèle trompé par l'injection obtient un accès complet au compte de service.

Attention : Problème de « député confus » : un utilisateur de faible autorité accède indirectement à des données auxquelles il ne peut pas accéder en externalisant un modèle de haute autorité. Le modèle doit toujours fonctionner dans le contexte de l'autorité de l'utilisateur, et non de sa propre autorité au sens large.

RBAC et ABAC

• RBAC (Role-Based Access Control) : L'accès dépend du rôle de l'utilisateur. Le rôle « spécialiste du support » peut lire les notes des clients, mais ne peut pas les supprimer. Simple et commun.
• ABAC (Attribute-Based Access Control) : L'accès dépend d'attributs : le service de l'utilisateur, le label de confidentialité des données, l'heure de la journée, le réseau d'où provient la demande. Plus fin mais plus complexe.

La plupart des organisations commencent par RBAC et approfondissent vers ABAC pour les données sensibles. Règle générale pour l'IA : le modèle doit filtrer chaque agent qu'il appelle et toutes les données auxquelles il accède en fonction du rôle/des attributs de l'utilisateur qui fait la demande.

Étape par étape : exercer une autorité minimale

1. Faites l'inventaire. Quels outils le modèle appelle-t-il, à quelles données accède-t-il ? Énumérez-les tous.
2. Justifiez chaque accès. « Cet assistant a-t-il vraiment besoin d'une autorisation de suppression ? » Sinon, supprimez-le.
3. Valeur par défaut en lecture seule. Le modèle doit pouvoir lire par défaut ; Nécessite l’écriture/suppression d’un jeton distinct à portée étroite.
4. Déplacer le contexte utilisateur. Appelez le véhicule avec l'autorité de l'utilisateur, pas avec le compte de service.
5. Titre de courte durée. Utilisez des jetons de courte durée à renouvellement automatique au lieu de clés de longue durée.

Gestion secrète

Un secret correspond à des informations d'identification qui doivent rester secrètes, telles qu'une clé API, un mot de passe, un jeton ou un certificat. L'accident le plus courant dans les projets d'IA survient lorsque la clé API du fournisseur de modèles est intégrée dans le code et fuit dans le contrôle de version (Git).

Application correcte :

• N'intégrez jamais de clés dans le code ; Utilisez une variable d'environnement ou un système de gestion des secrets (un service qui stocke les clés cryptées et contrôle l'accès).
• Rotation : Renouveler les clés à intervalles réguliers (par exemple tous les 90 jours) ; Si une fuite est suspectée, annulez immédiatement.
• Réduction de la portée : chaque commutateur ne dispose que du service requis et de l'autorisation requise.
• Audit : enregistrez qui a utilisé la clé, quand et où.

Quatre modèles copiables

Invite de contrôle de révision d’accès :

Pour chaque outil de la liste d'outils ci-dessous, évaluez : - Cet outil est-il REQUIS pour effectuer le travail de cet assistant ? (oui/non) - Est-ce en lecture seule ou en écriture/effacement ? - Cet outil est-il appelé avec l'autorité ou le compte de service de l'utilisateur ? Marquez ceux qui sont inutiles ou excessivement autorisés comme "REMOVE/REDACT".<tools>{{ tool_list }}</tools>

Invite d'analyse des fuites secrètes :

Recherchez tout ce qui pourrait être un secret codé en dur dans l'extrait de code suivant : clé API, mot de passe, jeton, chaîne de connexion, clé privée. Donnez une ligne et tapez pour chacun. COPIER la valeur dans la réponse ; masque (4 premiers caractères + ***).<code>{{ source }}</code>

Règle de décision de moindre autorité :

Lorsqu'une nouvelle demande d'outil/d'accès arrive, demandez :1. La tâche peut-elle être exécutée sans cet accès ? -> Si oui : REJETER2. La lecture seule est-elle suffisante ? -> Si oui : GRANT l'autorisation d'écriture3. La portée peut-elle être réduite à une seule source ? -> Si oui : daratLa réponse par défaut est « non » ; L'accès se fait par la raison.

Rappel du calendrier de rotation :

Pour chaque secret, enregistrez : propriétaire, date de création, expiration, portée. Signalez toute clé qui a dépassé 90 jours ou qui n'a pas été utilisée pendant 30 jours comme « CANDIDAT À LA ROTATION/ANNULATION ».

Invite faible/Invite forte

mauvaise approche

Approche forte

Le modèle accède à toutes les données avec un seul compte de service

Le modèle accède avec l'autorité de l'utilisateur faisant la demande

La clé API est intégrée dans le code, elle ne change jamais

Rotation au sein du gestionnaire des secrets clés, 90 jours

Large pouvoir de « faire n'importe quoi » pour l'assistant

Lecture seule par défaut, écriture étroite

Les accès ne sont jamais révisés

Examen et révocation réguliers de l'accès

Trois mini-étuis

Cas 1 — Fuite de données proxy mixtes. Un assistant interne travaillait avec un compte de service ayant accès à tous les dossiers des employés. Un utilisateur stagiaire a accédé à des données qu'il ne verrait normalement pas en disant « résumer le tableau des salaires des cadres » ; parce que le modèle l'a remis en question dans le contexte de sa propre autorité large, et non dans celui de l'utilisateur. Une fois le contexte utilisateur ajusté pour être déplacé, le stagiaire a pu extraire des enregistrements que lui seul pouvait voir.

Cas 2 — Clé qui fuit, facture de 190 000 TL en 2 semaines. Un développeur a intégré la clé API du modèle dans un script d'assistance et l'a transférée vers un référentiel public. Un robot a trouvé la clé en 40 minutes et l’a utilisée pendant deux semaines ; La facture a atteint 190 000 TL. Lorsque la clé a été déplacée vers le gestionnaire de secrets, connectée à la rotation et que l'analyse du référentiel a été ajoutée, l'incident ne s'est pas reproduit.

Cas 3 — Interruption empêchée par défaut en lecture seule. Un assistant DevOps a reçu une commande « réinitialiser la base de données de production » via une injection rapide. Cependant, l'assistant n'a reçu qu'un jeton en lecture seule ; l'écriture/l'effacement s'effectuait dans un flux approuvé distinct. La commande a été rejetée avec une erreur d'autorisation et l'événement a été enregistré comme alarme ; Il n'y a eu aucune perte de données.

Astuce : Faites « non » votre réponse par défaut à une nouvelle demande d'accès. L'accès est quelque chose qui s'obtient par la justification ; Donner large à tout le monde puis réduire les dépenses n'est presque jamais fait et le risque s'accumule.

Erreurs courantes

• Exécuter le modèle avec un grand compte de service et perdre le contexte utilisateur (proxy mixte).
• Intégrer la clé API dans le code et la divulguer dans le contrôle de version.
• Ne pas faire tourner les touches du tout ("fonctionne, ne touchez pas").
• Donner à l'assistant des autorisations d'écriture/suppression par défaut.
• Accorder l’accès une fois et ne jamais le reconsidérer.
• Confondre authentification et autorisation et supposer "qu'il est connecté, il peut accéder à tout".

En résumé

• L'authentification est une question de « qui êtes-vous », l'autorisation est une question de « que pouvez-vous faire » ; En IA, les deux doivent fonctionner dans le contexte de l’utilisateur.
• Le modèle doit fonctionner avec l’autorité de l’utilisateur qui fait la demande, et non avec sa propre autorité large (en évitant le risque d’agence mixte).
• Commencez par RBAC, approfondissez avec ABAC sur les données sensibles ; Faites de l'autorité minimale la valeur par défaut.
• N'enfouissez pas les secrets dans le code ; stockez-le dans le gestionnaire secret, affinez-le et mettez-le en rotation régulière.
• La valeur par défaut en lecture seule et l'écriture étroite limitent considérablement l'impact de l'injection.

Tâche de candidature

Répertoriez tous les outils et données auxquels votre assistant IA accède. Répondez à trois questions pour chacun : (1) Est-ce vraiment nécessaire ? (2) La lecture seule est-elle suffisante ? (3) Fonctionne-t-il dans le contexte utilisateur ? Recherchez ensuite tous les secrets codés en dur (via l'invite d'analyse ci-dessus) et rédigez un plan de rotation pour chaque clé que vous trouvez. Supprimez au moins une autorisation inutile.

liste de contrôle

• [ ] Le modèle s'exécute dans le contexte d'autorité de l'utilisateur qui fait la demande.
• [ ] L'accès aux outils et aux données a été réduit au principe du moindre privilège.
• [ ] L'écriture/effacement est distincte de la lecture seule, authentifiée et étroite.
• [ ] Aucun secret n'est enfoui dans le code ; Il est conservé dans le gestionnaire secret.
• [ ] Il existe un calendrier de rotation et une procédure d'annulation des clés.
• [ ] Les accès sont révisés régulièrement.