Règles DLP
Vérifié avec Cortex le 2 octobre 2026
Le DLP (prévention des fuites de données) est ce qui permet à Cortex de laisser vos employés utiliser des modèles externes. Chaque message sortant est analysé avant d’atteindre un fournisseur : les éléments sensibles sont remplacés par des jetons comme [EMAIL_1], la réponse du modèle est contrôlée à son tour, et le journal d’audit ne consigne que le type de ce qui a été détecté, jamais sa valeur. Tout se règle dans la console, sous « Politiques DLP ».
Ce que Cortex détecte
La détection se fait en trois niveaux, qui s’additionnent.
Les motifs de la passerelle sont toujours actifs. La console les nomme « Motifs système » (21) :
| Catégorie | Motifs |
|---|---|
| Identifiant gouvernemental | « Numéro d'assurance sociale (CA) », « Social Security Number (US) » |
| Financier | « Carte de crédit » |
| Coordonnées | « Adresse courriel », « Téléphone (Amérique du Nord) », « Téléphone (international) » |
| Réseau | « Adresse IPv4 », « Adresse IPv6 » |
| Secret | « Clé d'accès AWS », « Clé secrète AWS », « Jeton JWT », « Bloc de clé privée », « Jeton Slack », « Jeton GitHub », « Jeton Bearer », « Clé API OpenAI », « Clé API Anthropic », « Clé API Stripe », « Clé API SendGrid », « Jeton Hugging Face », « Identifiant générique » |
Les numéros d’assurance sociale et de carte sont validés par leur clé de contrôle, ce qui limite les faux positifs. La passerelle signale aussi, dans l’audit seulement, les textes qui ressemblent à du base64, à de l’hexadécimal ou à une chaîne à forte entropie, sans les bloquer ni les caviarder.
Les noms, avec le moteur IA (optionnel). Le nœud reconnaît les noms de personnes (« Personne ») en français et en anglais, ainsi que les secrets opaques qui suivent un mot comme « clé » ou « mot de passe ». Il ne rapporte pas les organisations, les villes, les régions ni les pays.
Le modèle local, avec le moteur IA et un moteur d’inférence configuré. Un modèle servi par un moteur d’inférence que vous exploitez (Ollama ou vLLM, par exemple) lit le texte pour y trouver ce que les motifs ne voient pas : « Personne », « Lieu précis » (adresses, quartiers, bâtiments), « Secret », « Santé », « Finances (personnelles) » et « Identifiant interne ». Ce modèle lit le texte original : il est censé tourner à l’intérieur de votre réseau.
Ces détections couvrent les formats connus et ne garantissent pas l’exhaustivité.
Profils par destination
L’onglet « Profils par destination » règle le « Profil de filtrage » de chaque destination : « DLP complet » (décrit dans la console comme la protection maximale pour les destinations externes) ou « Profil allégé » (réservé au réseau privé). Il liste les « Composantes actives » : « Caviardage amont », « Pseudonymisation », « Filtre aval » et « Audit », ces deux derniers étant « non désactivable ». Les quatre interrupteurs sont activés pour toutes les destinations. Pour l’instant, le profil est une étiquette de politique que l’employé voit sous sa zone de saisie : la console précise que « Tous les motifs actifs s'appliquent à chaque destination ».
Le « Profil allégé » sur une destination dont la « Résolution d'adresse » n’est pas « Privée » demande une approbation. Dans « Modifier », le « Garde-fou réseau » affiche cette résolution (« Publique », « Privée » ou « Inconnue ») et l’« Approbation du profil allégé ».
- Créez la destination avec le « DLP complet ».
- Ouvrez-la avec « Modifier » et choisissez « Profil allégé » : le garde-fou demande l’approbation et propose « Approuver… ».
- Cochez la reconnaissance, tapez « APPROUVER » et confirmez, puis cliquez sur « Fermer ». L’approbation est enregistrée.
- Cliquez sur « Enregistrer » pour appliquer le « Profil allégé ».
Une fois l’approbation enregistrée, vous pouvez aussi fermer « Modifier la destination » sans enregistrer et choisir « Profil allégé » dans l’onglet « Profils par destination » de « Politiques DLP ». Changer l’« Endpoint » retire l’approbation ; enregistrer sans le modifier la conserve.
Vos propres motifs
Les motifs système ne se désactivent ni ne se suppriment : seule leur gravité change, entre « Avertissement » (caviardé puis pseudonymisé) et « Blocage » (l’envoi est refusé). Vos motifs s’y ajoutent.
- Ouvrez l’onglet « Motifs de détection », puis « Nouveau motif ».
- Facultatif : choisissez un « Motif de base ». Le formulaire propose le nom
{nom}_deriveet reprend la catégorie, le motif et la gravité ; le motif système reste actif. Restreignez l’expression : un motif identique à un existant est refusé. - Renseignez le « Nom » (minuscules, chiffres et
_), la « Catégorie » (existante, ou créée à la volée), le « Motif (regex) » et la « Gravité ». - Cliquez sur « Créer ».
Cortex refuse un motif de plus de 512 caractères, de syntaxe invalide ou à risque de ReDoS (références arrière, quantificateurs imbriqués). Un motif prend effet à la requête suivante. Sous « Règles personnalisées », vous pouvez le désactiver, le modifier, changer sa gravité ou le supprimer ; « Exporter les motifs » télécharge les définitions en JSON.
Tester le filtrage
L’onglet « Test du filtrage » analyse un « Texte d'essai » sans rien envoyer ni conserver. Cliquez sur « Tester le filtrage » : le texte s’affiche avec ses jetons, suivi du nombre d’entités détectées, de la mention « Envoi bloqué » le cas échéant, et, pour chaque détection, du motif (système ou personnalisé) et de sa gravité. Le test applique les motifs de la passerelle, les vôtres compris, mais pas les noms ni le modèle local.