Configurer les politiques de détection et les niveaux de sévérité
Concevoir, échelonner et déployer les politiques de détection Zeuslock sans perdre la confiance des opérateurs — du Monitor de référence au Block.
Le modèle de politique en un paragraphe
Chaque politique Zeuslock est une matrice types de détection (ce qui a été repéré) croisée avec actions (ce qu'on en fait). Pour chaque type de détection, vous choisissez une action parmi trois : Monitor journalise l'événement et transmet le prompt intact ; Anonymize réécrit la valeur sensible sur place via une rédaction préservant le format avant que le prompt ne quitte le poste ; Block refuse la requête et affiche une explication intégrée à l'utilisateur. Les actions sont assignées par type de détection, par groupe, et facultativement par destination. Il n'existe volontairement pas d'interrupteur global.
Catégories de détection sur lesquelles agir
Zeuslock fournit des détecteurs dans cinq familles. Vous assignez une action à chacune indépendamment.
- Identifiants —
api_key(AWS AKIA, Stripe sk_, OpenAI sk-, Azure, Google/Gemini, GitHub ghp_, Slack xoxb-, GitLab glpat-, npm npm_, jetons Bearer),password,jwt,private_key,connection_string,env_variable. - Financier —
credit_card(validation Luhn),IBAN,crypto_wallet. - Données personnelles —
email,phone,NIR(Sécurité Sociale), SSN américain,passport, adresse postale,ip_address. - Code source — détection heuristique du code propriétaire collé, avec empreinte de langage.
- Identifiants organisationnels — vos détecteurs personnalisés (noms de code projets, identifiants clients internes, cibles M&A). Voir le guide développeur sur les détecteurs personnalisés pour la procédure complète.
Niveaux de sévérité et leur attribution
La sévérité est calculée au moment de la détection à partir de trois signaux : le risque intrinsèque du type de détection, des heuristiques contextuelles autour de la correspondance (jetons environnants, structure du prompt, destination), et le score de confiance du détecteur. Vous pouvez surcharger le mappage par défaut, mais nous recommandons de conserver les valeurs par défaut le premier mois.
| Sévérité | Signification | Déclencheurs typiques | Action par défaut |
|---|---|---|---|
| Critique | Secret actif ou identifiant réglementé avec haute confiance | private_key, paire AWS AKIA + secret, credit_card valide, NIR | Block |
| Élevée | Probablement sensible, confirmation partielle | Jeton Bearer, mot de passe dans une structure clé/valeur, IBAN | Anonymize |
| Moyenne | Sensible mais récupérable, ou confiance plus faible | Couple email + téléphone, motif de passeport, forme générique de clé API | Anonymize |
| Faible | Informationnel, souvent à risque de faux positif | email isolé, ip_address, identifiant public | Monitor |
Le déploiement que nous recommandons
Ne démarrez pas en Block. Les deux premières semaines de tout déploiement DLP vous apprennent ce que votre organisation colle réellement dans ChatGPT, Claude et Gemini — et la réponse est presque toujours plus variée que ce que l'équipe sécurité avait prévu. Échelonnez le déploiement en trois phases.
- Semaines 1-2 — Monitor partout. Mettez chaque type de détection en Monitor. Consultez le tableau de bord Incidents tous les jours. Affinez les détecteurs personnalisés. Identifiez les types de détection bruyants propres à votre environnement.
- Semaines 3-5 — Anonymize finance et données personnelles. Basculez
credit_card,IBAN,email,phone,passport,SSN,NIRet adresses postales en Anonymize. La rédaction préservant le format envoie au LLM aval une valeur structurellement valide, donc les workflows utilisateurs ne cassent pas. - Semaine 6 et au-delà — Block identifiants et code source. Basculez
api_key,password,jwt,private_keyet code source en Block. À ce stade, les utilisateurs ont vu assez de bandeaux Anonymize pour comprendre pourquoi Zeuslock refuse, et votre taux de faux positifs est suffisamment bas pour que les blocages soient acceptés.
Ne démarrez jamais en Block. Les politiques de Block au jour un génèrent des tickets coléreux, poussent les utilisateurs vers leurs appareils personnels et brûlent le capital politique nécessaire à la suite du programme. Monitor d'abord. Toujours.
Surcharges par groupe
Une seule politique convient rarement à toute l'entreprise. Les développeurs collent des clés API et du code dans Copilot toute la journée ; le commercial colle des listes clients dans ChatGPT pour rédiger des relances ; la finance colle des IBAN dans Gemini pour la réconciliation. Chaque groupe a besoin d'une posture différente.
- Allez dans
Settings → Policies → Groups. - Choisissez le groupe SCIM (ou créez un groupe manuel) et cliquez sur Override default policy.
- Vous voyez la même matrice que la politique par défaut, avec des flèches d'héritage à côté de chaque cellule. Les cellules non modifiées continuent d'hériter de la politique par défaut — quand vous changerez la valeur par défaut plus tard, ces cellules suivront automatiquement.
- Enregistrez la surcharge. Elle prend effet au prochain prompt ; aucun redémarrage côté client.
Un schéma courant : les développeurs reçoivent Anonymize sur api_key (avec des fausses clés structurellement valides pour que leurs extraits de code se parsent), tandis que tout le monde reçoit Block.
Exceptions horaires
Le risque n'est pas constant dans la journée. Les prompts hors heures de bureau vers des outils IA grand public sont statistiquement plus susceptibles d'être de l'exfiltration ou des projets parallèles imprudents. Dans Settings → Policies → Schedules, attachez une variante plus stricte aux heures non ouvrées — par exemple, faites passer Anonymize en Block sur les identifiants entre 20:00 et 07:00 heure locale, et le week-end. Les plannings respectent le fuseau horaire de chaque utilisateur depuis son profil SCIM.
Surcharges par destination
Tous les outils IA ne méritent pas le même niveau de confiance. Nous recommandons trois paliers.
- LLM internes validés (un Mistral auto-hébergé, un déploiement Azure OpenAI dans votre tenant) — relâchez en Monitor sur PII et finance, gardez Block sur les identifiants.
- Outils commerciaux validés (ChatGPT Enterprise, Claude for Work avec DPA signé) — appliquez votre politique par défaut.
- Outils non validés ou à haut risque (DeepSeek, Poe, tout outil signalé par la détection Shadow AI) — augmentez tout d'un cran. Anonymize devient Block, Monitor devient Anonymize. Zeuslock signale automatiquement au RSSI la première utilisation de tout outil non validé.
Détecteurs personnalisés
Les détecteurs personnalisés permettent d'attraper les identifiants organisationnels — noms de code projets internes, noms de cibles M&A, formats d'identifiants employés, numéros de référence client. Ils participent au même modèle de sévérité que les détecteurs intégrés et peuvent recevoir n'importe laquelle des trois actions. Le workflow complet de création, y compris l'outil de backtest sur les 30 derniers jours de trafic, est documenté dans le guide développeur.
Testez chaque changement de politique avec le dry-run
Avant d'activer un changement, exécutez-le en mode dry-run. Zeuslock rejoue les 24 dernières heures de prompts à travers la politique proposée et vous montre exactement ce qui aurait été bloqué, anonymisé ou journalisé — par utilisateur, par groupe, par destination. Si le dry-run montre 400 nouveaux blocages sur l'équipe juridique à cause d'un faux positif Bearer dans leurs modèles de contrats, vous l'apprenez avant eux. Activez seulement quand le rapport dry-run correspond à votre intention.
À surveiller le premier mois
- Le tableau de bord Incidents, quotidiennement, filtré sur Critique et Élevée.
- La file Faux positifs — tout ce qui y est signalé alimente l'affinage des détecteurs.
- Le rapport Shadow AI — nouveaux outils apparaissant dans votre environnement.
- Les taux de blocage par groupe — si un groupe génère 10 fois plus de blocages qu'un autre, c'est probablement une surcharge à créer, pas un sermon à faire.