À propos du service managé DLP

• Créer une règle DLP
• Modifier une règle DLP
• Supprimer une règle DLP
• Créer une policy DLP
• Modifier une policy DLP
• Supprimer une policy DLP
• Créer un détecteur personnalisé DLP
• Modifier un détecteur personnalisé DLP
• Supprimer un détecteur personnalisé DLP
• Publier un ruleset DLP
• Consulter les journaux de décision DLP
• Gérer les utilisateurs DLP
• Supprimer un utilisateur DLP
• Réinitialiser le mot de passe d'un utilisateur DLP
• Consulter la piste d'audit DLP
• Consulter le tableau de bord DLP

Introduction

Le service managé DLP (Data Loss Prevention) permet d'inspecter, d'évaluer et de protéger les données sensibles en temps réel. Le service DLP s'intercale entre les plateformes internes et leurs backends, inspecte les requêtes entrantes et renvoie une décision : passer, bloquer, modifier ou surveiller.

Ce service est conçu pour prévenir les fuites de données sensibles — clés API, identifiants cloud, tokens d'accès — dans les flux transitant par les plateformes de Numspot.

Avantages du service managé DLP

• Protection en temps réel : inspection des requêtes à la volée, sans latence perceptible ;
• Règles personnalisables : création de règles et de détecteurs adaptés aux besoins de chaque organisation ;
• Détecteurs prédéfinis : bibliothèque de détecteurs couvrant les secrets cloud, les tokens d'API et les services IA ;
• Modification automatique : caviardage ou suppression des données sensibles détectées dans les flux ;
• Audit complet : traçabilité des décisions et journalisation des actions d'administration ;
• Haute disponibilité : architecture avec composants redondants et mise à l'échelle automatique des workers.

Accès à la console DLP

La console DLP est une interface web standalone, accessible via sa propre URL. Elle n'est pas accessible depuis la console Numspot.

Architecture

Le service DLP repose sur cinq composants :

Composant	Rôle
Control	API d'administration, gestion des règles, des utilisateurs et des détecteurs
Control Frontend	Interface web de gestion DLP
Control Gateway	Proxy inverse qui route les requêtes vers le frontend ou l'API Control
worker	Moteur d'évaluation sans état, exposé aux plateformes consommatrices
Log Collector	Collecte, stockage et interrogation des journaux de décision

Fonctionnement de l'évaluation

1. La plateforme consommatrice envoie une requête au worker DLP ;
2. Le worker authentifie la requête via une clé API ;
3. Le worker valide la requête par rapport au schéma de la plateforme ;
4. Le worker évalue toutes les règles actives dans l'ordre des policies ;
5. Le worker renvoie la décision : pass, block ou modify.

Les workers se synchronisent avec le composant Control toutes les 30 secondes pour récupérer la dernière version publiée des règles et de la configuration. Si aucune modification n'est détectée, la synchronisation renvoie un statut 304 (non modifié).

Concepts clés

Règles

Une règle DLP définit une condition et une action à appliquer lorsque la condition est remplie.

• Condition : expression DSL (Domain Specific Language) sous forme de chaîne de caractères qui spécifie le champ à inspecter et le détecteur à utiliser ;
• Action : décision à appliquer lorsque la condition est remplie.

Les actions disponibles sont les suivantes :

Action	Description
pass	Autorise la requête sans modification
block	Bloque la requête et renvoie un message d'erreur
modify	Modifie les champs sensibles détectés (caviardage ou suppression)
monitor	Autorise la requête mais journalise l'événement et stocke la charge utile

Les règles sont créées en tant que brouillons. Elles doivent être publiées dans un ruleset (ensemble de règles) pour être actives.

Opérateurs DSL

Le langage DSL dispose de deux opérateurs :

Opérateur	Description
matches_detector	Vérifie si le champ spécifié correspond au détecteur indiqué
not_matches_detector	Vérifie si le champ spécifié ne correspond pas au détecteur indiqué

Exemple de condition DSL :

matches_detector(tool_arguments, @preset:aws_access_key)

Policies

Une policy DLP (politique DLP) regroupe un ensemble de règles et définit une action par défaut.

• Règles : liste ordonnée de règles à évaluer ;
• Action par défaut : décision appliquée lorsqu'aucune règle ne déclenche une action terminale — pass ou block.

L'évaluation suit l'ordre des règles dans la policy. Une action pass ou block termine l'évaluation. L'action modify accumule les modifications et poursuit l'évaluation. L'action monitor journalise l'événement et poursuit l'évaluation.

Détecteurs

Un détecteur identifie un type de données sensible à l'aide d'expressions régulières.

Il existe deux catégories de détecteurs :

• Détecteurs prédéfinis : fournis par Numspot, répartis en trois catégories :
  • secrets (~80 détecteurs) : clés d'accès cloud, tokens d'API, secrets d'infrastructure ;
  • mistral-service (2 détecteurs) : détecteurs spécifiques aux services Mistral ;
  • generic (1 détecteur) : détecteur générique.
• Détecteurs personnalisés : créés par l'utilisateur avec des expressions régulières propres à son organisation.

Les détecteurs sont référencés dans les conditions des règles via la syntaxe @preset:<id> pour les prédéfinis et @custom:<id> pour les personnalisés.

Rulesets

Un ruleset est une version immuable de l'ensemble des règles, policies et détecteurs personnalisés actifs. La publication d'un ruleset fige toutes les règles et policies en brouillon dans une nouvelle version numérotée.

Le rollback restaure une version précédente en créant une nouvelle version (N+1) identique à la version sélectionnée.

Schémas de plateforme

Chaque plateforme consommatrice possède un schéma qui définit les champs attendus dans les requêtes d'évaluation. Le schéma spécifie pour chaque champ :

• le nom en notation pointée ;
• le type : string, number, boolean, enum, array ou datetime ;
• le caractère obligatoire ou facultatif ;
• la description.

Schéma de la plateforme Mistral

Champ	Type	Obligatoire	Description
tool_arguments	string	Oui	Arguments de l'outil appelé
tool_called	string	Non	Nom de l'outil appelé
request_time	datetime	Oui	Horodatage de la requête

Lorsqu'un champ référencé par une règle est absent de la requête, la politique de champ absent détermine le comportement :

• fail_open : la règle ne se déclenche pas ;
• fail_closed : la règle se déclenche.

Rôles et permissions

Le service DLP utilise un modèle de contrôle d'accès basé sur les rôles. Les rôles disponibles sont les suivants :

Rôle	Permissions
viewer	Lecture des règles, policies, détecteurs, journaux et audit
detector_editor	Lecture + écriture des détecteurs personnalisés
rule_editor	Lecture + écriture des règles et des policies
rule_publisher	Lecture + publication des rulesets
admin	Toutes les permissions, y compris la gestion des utilisateurs

Les modifications de rôles prennent effet immédiatement sur les sessions existantes.

Authentification

L'accès à l'API Control se fait via des sessions basées sur des cookies sécurisés (HttpOnly, SameSite=Strict), d'une durée de 8 heures configurable.

L'accès au worker DLP se fait via des clés API par instance de plateforme, avec une authentification Bearer.

Après 5 tentatives de connexion échouées, un verrouillage de 5 minutes est appliqué par nom d'utilisateur.

Journaux et audit

Journaux de décision

Chaque évaluation par le worker produit un journal de décision contenant :

• l'identifiant de la requête ;
• la plateforme consommatrice ;
• la décision rendue ;
• les règles déclenchées ;
• les champs modifiés ;
• la latence de traitement.

Les journaux de décision sont consultables depuis la section Decision Logs de la console DLP.

Événements monitorés

Les règles en mode monitor génèrent des événements qui stockent la charge utile originale dans un stockage objet compatible S3. Les charges utiles peuvent être consultées en version complète ou caviardée.

Audit Logs

Toutes les actions d'administration — création, modification, suppression de règles, policies, détecteurs, publication de ruleset, gestion des utilisateurs — sont enregistrées dans les journaux d'audit.

Les journaux d'audit sont consultables depuis la section Audit Logs de la console DLP.

Cas d'utilisation

Protection des clés d'accès cloud

Détectez et bloquez la transmission accidentelle de clés d'accès AWS, GCP ou d'autres fournisseurs cloud dans les requêtes transitant par les plateformes de Numspot.

Caviardage des données sensibles

Remplacez automatiquement les secrets détectés — clés API, tokens d'accès, identifiants — par des masques dans les flux de données.

Surveillance conformitaire

Journalisez les requêtes contenant des données sensibles sans les bloquer, afin de constituer une trace d'audit pour les exigences de conformité.

Bonnes pratiques

• Règles spécifiques : créez des règles ciblant des champs précis plutôt que le champ générique * pour limiter les faux positifs ;
• Test avant publication : utilisez la fonctionnalité de test des règles et des détecteurs avant de publier un ruleset ;
• Action monitor en premier : commencez par surveiller les flux en mode monitor pour mesurer l'impact avant de passer en block ;
• Rollback rapide : en cas de faux positifs massifs, utilisez le rollback pour restaurer la version précédente du ruleset ;
• Moindre privilège : attribuez le rôle minimal nécessaire à chaque utilisateur — viewer par défaut, rule_editor uniquement pour les utilisateurs créant des règles.