Configurer un contrôle de sécurité de prévention des fuites

Un contrôle peut utiliser l’applicabilité d’une politique de prévention des fuites de données (DLP) comme condition d’une politique d’accès Zero Trust. Sa création seule ne limite pas l’accès et ne remplace ni la politique DLP ni la protection réelle du terminal.

Préparer la politique

1. Vérifiez les capacités DLP et Zero Trust requises ainsi que les droits de gestion des politiques et contrôles. Choisissez des terminaux pilotes contrôlés et des terminaux témoins qui ne devraient pas satisfaire la condition.
2. Créez ou modifiez la politique DLP nécessaire, par exemple une restriction de transfert selon les règles de sécurité des fichiers. Vérifiez activation, période et périmètre ; enregistrez les réglages et toute la politique.
3. Attendez la réception sur les terminaux pilotes et vérifiez la protection réelle avec des fichiers de test non sensibles. Enregistrement, applicabilité et exécution sont des états distincts.

Créer et utiliser le contrôle

1. Dans Data Loss Prevention, ouvrez « Security Checks » et choisissez « Create Check » ou « Create Security Check ». Dans « Check type », sélectionnez « Data Loss Prevention Policy Applied ».
2. Dans « Check settings », choisissez une politique DLP activée et valide. Dans « Review », saisissez un nom, vérifiez la sélection et enregistrez. Si un contrôle du même type existe pour cette politique, vérifiez-le et réutilisez-le.
3. Vérifiez nom, type et activation dans la liste. La création ne l’ajoute pas automatiquement à une politique d’accès. Pour contrôler l’accès Zero Trust, modifiez la politique cible, sélectionnez le contrôle dans « Security Checks » et enregistrez.
4. Définissez source, cible, direction, protocole et ports selon les besoins. Après mise à jour des données et réglages, testez les terminaux qui doivent satisfaire ou non la condition ; vérifiez aussi autres politiques, routes et pare-feu cible.

Le contrôle évalue l’applicabilité : il ne prouve pas à lui seul la réception ou l’exécution sur le terminal. Un résultat en échec, inconnu ou expiré ne doit pas être supposé conforme. Le contrôle est une condition de correspondance de la source : ajouté à une politique de refus, il ne garantit pas le refus d’une source en échec ; d’autres politiques ou routes peuvent intervenir. Testez séparément réussite, échec et données absentes.

Vérification après modification : Un changement de périmètre de la politique peut ne pas actualiser immédiatement le résultat du contrôle. Attendez sa réévaluation et la mise à jour des réglages concernés, puis testez séparément les terminaux satisfaisant ou non la condition. Ne jugez pas l’accès d’après un enregistrement réussi ou un ancien résultat seulement.

Lors de la création, choisissez « Next » après chaque étape de l’assistant, puis « Create Check » dans « Review ». Pour modifier un contrôle existant, le dernier bouton est « Save ». Après soumission, revenez à la liste et vérifiez le résultat.

Modifier et dépanner

• Avant de modifier ou désactiver le contrôle ou sa politique, examinez les références et l’impact métier. Un contrôle référencé ne peut pas être supprimé directement ; traitez les références selon la procédure de changement puis vérifiez l’accès.
• Si la politique est introuvable ou l’enregistrement échoue, vérifiez activation, validité, droits et contrôle existant du même type. Rechargez et vérifiez en cas d’erreur ou de résultat incertain, sans créer plusieurs fois.
• Si le résultat diffère de l’attendu, vérifiez périmètre du terminal, état du contrôle, actualisation, politiques Zero Trust et routes, puis testez la protection réelle. Le nom du contrôle ou une seule requête ne prouve pas la protection.