Alertes de publication de contenu Web
Web Content Publishing définit des règles pour les contenus soumis par les terminaux à des sites ou interfaces Web, avec blocage, audit ou alerte selon l'adresse et les critères de sensibilité. Les enregistrements montrent des soumissions contrôlées, collectées et transmises ; ils ne représentent pas tous les accès Web et ne prouvent pas à eux seuls une fuite.
Les procédures utilisent les libellés anglais de la console d'administration.
Pour la configuration complète, consultez la stratégie de publication de contenu Web.
Pour consulter des alertes existantes, utilisez un compte doté du droit correspondant et passez directement à la recherche des alertes ci-dessous. Ne modifiez pas une stratégie et ne produisez pas d’événements de test pour la seule consultation. Pour vérifier une nouvelle alerte, contrôlez d’abord la règle applicable et son option d’alerte ; seule une personne autorisée à gérer les stratégies les modifie si nécessaire avant le test pilote.
Préparer la configuration
- La consultation des alertes existantes nécessite les droits correspondants ; vérifiez séparément les droits de consultation des enregistrements associés. Modifier une politique DLP nécessite ses droits de gestion. Pour vérifier de nouvelles alertes, contrôlez la connexion, la licence et la visibilité des terminaux.
- Définissez sites, interfaces et terminaux pilotes. Pour une correspondance sur contenu sensible, préparez des règles adaptées au métier et aux échantillons de test.
- Définissez selon l'organisation l'objectif d'utilisation des données, les personnes autorisées et leur conservation. Le blocage peut perturber l'activité ; préparez un retour arrière et utilisez des contenus de test non sensibles et autorisés.
Configurer les règles
- Pour vérifier un nouvel événement, contrôlez la licence, le périmètre et la durée de la stratégie du terminal pilote ainsi que la règle Web Content Publishing applicable. Réutilisez une règle adaptée ; toute modification exige le droit de gestion des stratégies.
- Vérifiez l’URL, les conditions de contenu sensible et l’ordre des règles pour la requête test. Activez Audit pour les enregistrements et Alert pour les alertes : ces options sont distinctes. Évaluez les conséquences métier et ne bloquez pas à la légère pour un test.
- En cas de modification, confirmez la fenêtre, enregistrez toute la stratégie et attendez sa réception. L’enregistrement ne prouve ni l’exécution ni la remontée. Les règles et formats d’URL complets figurent dans le chapitre de stratégie ci-dessus.
- Avec un contenu de test autorisé et non sensible, vérifiez séparément les requêtes correspondantes et non correspondantes, leur résultat et les enregistrements ou alertes attendus. Évaluez l’impact avant toute extension selon la procédure de changement.
Pour vérifier les alertes, ouvrez DLP > Alerts, recherchez par date, terminal et type, puis ouvrez les détails disponibles. Comparez heure et contenu à l’opération pilote. La période initiale comprend aujourd’hui et les 29 jours précédents. Si le contenu ou les détails sont indisponibles, examinez les audits et autres preuves sans conclure à l’absence d’événement. Le bouton d’export visible ne permet pas d’exporter la liste des alertes ; demandez à un administrateur ou au support les moyens disponibles pour obtenir les éléments nécessaires.
Consulter et traiter les alertes : les mots-clés et filtres avancés s’appliquent aux alertes déjà chargées. Si l’alerte recherchée est absente, effacez les filtres, ajustez les dates et vérifiez d’autres enregistrements. À l’ouverture d’une alerte non lue, la page tente de la marquer comme lue ; les détails peuvent toutefois s’ouvrir même si cette opération échoue. Vérifiez alors l’état dans la liste. Les actions disponibles permettent aussi de marquer les alertes individuellement ou par lot. L’état lu ne signifie pas que l’envoi a été retiré, que le risque a disparu ou que l’incident est traité. Si les détails d’une alerte de contenu Web sont indisponibles, ne considérez pas le message affiché comme le contenu transmis. Consultez les enregistrements Web correspondants et les autres preuves dans les limites de vos autorisations et protégez les informations sensibles.
Périmètre du traitement groupé : le marquage groupé ne traite que les alertes sélectionnées encore présentes dans les résultats filtrés actuels. Les alertes sélectionnées auparavant mais masquées après modification du mot-clé ou des filtres avancés ne sont pas incluses ; une nouvelle requête réussie efface la sélection précédente. Vérifiez les filtres et la sélection avant l’action, puis l’état de lecture des alertes attendues.
Couverture et dépannage
Cette fonction peut examiner les soumissions de contenu POST et PUT prises en charge. Vérifiez séparément sites, applications, protocoles, trafic chiffré, formats et plateformes. Il ne faut pas supposer que toutes les actions Web et tous les contenus de fichiers sont détectables.
Taille du contenu, durée de traitement ou autres conditions peuvent entraîner une détection inachevée suivie d'une autorisation. En cas d'échec de détection, de non-correspondance ou d'échec de transmission d'audit, un enregistrement interrogeable n'est pas garanti. Son absence ne prouve ni l'absence de soumission ni l'innocuité du contenu.
- Enregistrement introuvable : vérifiez licences, diffusion de politique, URL et critères sensibles, action d'audit, transmission, visibilité et période ; retirez les filtres et retestez avec un échantillon contrôlé.
- Alerte attendue absente : vérifiez son activation, la correspondance de la règle et les droits de consultation. Alerte et audit sont des résultats distincts.
- Activité bloquée involontairement : rétablissez-la selon la procédure, vérifiez ordre, URL, critères et actions, puis ajustez et retestez sur le pilote.
- Détection inachevée ou résultat anormal : conservez heure, terminal et contexte pour le support ; une autorisation ou des détails vides ne prouvent pas une vérification réussie.
Mis à jour le