Écrire des conditions de règles DLP
Introduction
Les conditions des règles DLP sont exprimées dans un DSL (Domain Specific Language) dédié. Ce guide décrit la syntaxe, les opérateurs disponibles et les bonnes pratiques pour écrire des conditions efficaces.
Syntaxe
Structure de base
Une condition se compose d'un champ, d'un opérateur et d'une valeur :
<champ> <opérateur> <valeur>
Champ
Le champ correspond à un élément du schéma de la plateforme. Utilisez la notation pointée pour les champs imbriqués. Le champ générique * désigne tous les champs de la requête.
Pour la plateforme Mistral, les champs disponibles sont tool_arguments, tool_called et request_time.
Opérateurs
| Opérateur | Description |
|---|---|
matches_detector | Vrai si le détecteur trouve une correspondance dans le champ |
not_matches_detector | Vrai si le détecteur ne trouve aucune correspondance dans le champ |
Références de détecteurs
| Syntaxe | Description |
|---|---|
@preset:<id> | Référence un détecteur prédéfini |
@custom:<id> | Référence un détecteur personnalisé |
Exemples :
@preset:aws_access_key_id: détecteur prédéfini pour les clés d'accès AWS ;@preset:github_token: détecteur prédéfini pour les tokens GitHub ;@preset:openai_api_key: détecteur prédéfini pour les clés API OpenAI ;@custom:project_codename: détecteur personnalisé pour les noms de code projet.
Combinaison de conditions
Utilisez les opérateurs logiques pour combiner des conditions :
AND: les deux conditions doivent être vraies ;OR: au moins une des conditions doit être vraie ;- Parenthèses : pour grouper des conditions et définir la priorité d'évaluation.
Il n'y a pas de limite de profondeur d'imbrication.
Exemples
Détecter une clé AWS dans les arguments d'outil
tool_arguments matches_detector @preset:aws_access_key_id
Détecter une clé AWS ou un token GitHub
(tool_arguments matches_detector @preset:aws_access_key_id OR tool_arguments matches_detector @preset:github_token)
Détecter des données sensibles dans tous les champs
* matches_detector @preset:aws_access_key_id
Combiner détection et exclusion
tool_arguments matches_detector @preset:aws_access_key_id AND tool_arguments not_matches_detector @custom:whitelist_domain
Exclure un détecteur
tool_arguments not_matches_detector @custom:whitelist_domain
Normalisation du texte
Avant l'évaluation, les chaînes de caractères sont normalisées :
- normalisation NFC ;
- suppression des caractères invisibles (U+00AD, U+180E, U+2064, U+FFF9-FFFB, etc.).
Cette normalisation empêche les tentatives de contournement par insertion de caractères invisibles dans les données sensibles.
Politique de champ absent
Lorsqu'une règle référence un champ absent de la requête, le comportement dépend de la configuration de la plateforme consommatrice :
fail_open: la règle ne se déclenche pas — comportement par défaut ;fail_closed: la règle se déclenche comme si la condition était remplie.
Configurez la politique de champ absent au niveau de l'instance de plateforme selon le niveau de sécurité requis.
Bonnes pratiques
- Privilégiez les champs spécifiques plutôt que le champ générique
*pour limiter les faux positifs et améliorer les performances ; - Testez chaque règle avec des données représentatives avant de publier un ruleset (ensemble de règles) ;
- Utilisez
not_matches_detectorcombiné avecANDpour créer des exceptions — par exemple, autoriser un domaine tout en bloquant les autres ; - Groupez les conditions avec des parenthèses pour rendre les règles lisibles et éviter les ambiguïtés d'évaluation.