Netskope LogoNetskope Logo
  • Services de sécurité
  • Services d’IA
  • Services de miseenréseau
  • Services d'analyse
  • Intégrations
  • getting-started.svgPour commencer
    • Support
    • Communauté
    • Netskope.com
    © 2026 Tous droits réservés. Netskope Inc.
    Accueil
    Console d'administration
    Incidents
    A propos de DLP (Prévention des pertes de données)

    A propos de DLP (Prévention des pertes de données)

    Netskope données Loss Prevention (DLP (Prévention des pertes de données)) protège les données sensibles dans le cloud avec exactitude et précision en inspectant tous les services cloud sanctionnés et non autorisés. Lorsque les utilisateurs enfreignent une politique DLP (Prévention des pertes de données), Netskope enregistre l'incident. Si vous disposez d'Endpoint DLP (Prévention des pertes de données), les utilisateurs qui enfreignent vos politiques de contrôle de contenu déclenchent également un incident DLP (Prévention des pertes de données).

    Note

    Des incidents sont générés pour chaque fichier/sous-fichier qui correspond au(x) profil(s) DLP (Prévention des pertes de données) et aux règles DLP (Prévention des pertes de données), règles d'empreintes digitales, classificateurs basés sur le ML ou profils de fichiers correspondants. Un sous-fichier est un fichier situé à l'intérieur d'un fichier conteneur (par ex. dans un fichier zip/tar ou une image dans un document pptx ou une feuille de calcul dans un fichier docx). Un incident sera généré pour chaque fichier conteneur et un pour chaque sous-fichier correspondant aux profils DLP (Prévention des pertes de données).

    Si un document PowerPoint correspond à une règle DLP (Prévention des pertes de données) utilisée dans un profil DLP (Prévention des pertes de données), un incident sera créé pour ce fichier. Si une image intégrée d'une carte de crédit dans le même document PowerPoint correspond à un classificateur basé sur le ML pour les cartes de crédit, un autre incident sera créé pour cette image.

    Si la prévention des pertes de données (DLP) détecte une violation dans un document incorporé, seul le nom du fichier incorporé est enregistré. Par exemple, si un fichier zip, Data.zip, contient une feuille de calcul Excel, Microsoft_Excel_Worksheet.xlsx, la violation n'enregistrera que le fichier Microsoft_Excel_Worksheet.xlsx et NOT le fichier Data.zip.
    Le service DLP (Prévention des pertes de données) a pour limite interne de ne générer que 50 incidents pour une demande donnée.
    Par exemple, si un fichier .zip a 300 fichiers, le service DLP (Prévention des pertes de données) générera au maximum 50 incidents.
    Tous les fichiers incorporés correspondants génèrent un incident en cas d'introspection et de CASB.
    Pour les demandes en ligne (nsProxy), DLP (Prévention des pertes de données) génère des événements/incidents uniquement pour le profil associé à la politique de priorité la plus élevée. La limite d'incidents combinée à la génération d'événements/incidents uniquement pour la politique/le profil le plus élevé peut entraîner la génération d'alertes qui n'ont pas d'incident correspondant. Par exemple, si les 50 premiers fichiers incorporés correspondent à une politique/un profil de moindre priorité et que les fichiers incorporés suivants correspondent à une politique/un profil de priorité plus élevée, les incidents relatifs au profil de priorité plus élevée ne sont pas enregistrés car la limite a été atteinte.

    Visualisation des incidents DLP (Prévention des pertes de données)

    Incident grouping depends on whether the Object ID or hash changes; incidents are grouped if the Object ID remains the same, and a change in hash triggers a new incident, with filename changes not necessarily causing new incidents if content remains unchanged.

    Pour afficher les incidents DLP (Prévention des pertes de données) dans votre organisation, accédez à Incidents > DLP.

    1. Actualisez les résultats des incidents DLP (Prévention des pertes de données).
    2. Filtrez les incidents DLP (Prévention des pertes de données) en fonction d'une période spécifique. Vous pouvez utiliser une période prédéfinie ou choisir Date Range pour utiliser les menus calendrier et temps afin de personnaliser votre propre période.
    3. Recherchez et filtrez les incidents DLP (Prévention des pertes de données) par requête. Cliquez sur + Add Filter pour ajouter d’autres filtres afin de cibler vos résultats de recherche. Par exemple, vous pouvez choisir Block pour le Last Action et sélectionner une application pour ne voir que les incidents DLP (Prévention des pertes de données) correspondant à ces critères. Vous pouvez également cliquer L'icône du mode requête de Netskope. pour passer au mode de recherche avancée par requête. Cliquez L’icône du filtre d’enregistrement. pour enregistrer la combinaison de filtres pour les recherches futures.

      Note

      Si vous disposez d'Endpoint DLP (Prévention des pertes de données), vous pouvez filtrer les incidents par Endpoint Content Control Policy.

    4. Consultez les 5 principales applications, les expositions et les 5 principales politiques avec des violations.
    5. Consultez la liste des incidents DLP (Prévention des pertes de données). Pour chaque incident, vous pouvez consulter les informations par défaut suivantes :
      • Object: Nom du fichier ou de l'objet qui a déclenché la violation. Cliquez pour ouvrir une page contenant plus de détails où vous pouvez changer le statut, attribuer des incidents, modifier la gravité et prendre des mesures.Application: Application ayant déclenché la violation.Site: Le site Web ayant déclenché la violation.Exposure: Le niveau d'exposition du fichier.
        • Public – IndexéPublic – Non répertoriéPublicPrivéPartagé en externePartagé en internePartagé à l'échelle de l'entrepriseInter-géo
        # Violations: Le nombre total de violations avec le fichier. Le décompte fait référence au nombre agrégé d'enregistrements détectés dans l'ensemble des politiques de l'incidentLast Action: L'action qui a été effectuée, telle que l'autorisation, le blocage, l'alerte, etc.Status: indique l'état de l'événement. Il existe trois états :
        • NewIn ProgressResolved
        Assignee: la personne désignée pour surveiller l'incident.Severity: Le niveau de gravité de l'objet ou du fichier. Il existe quatre niveaux :
        • LowMediumHighCritical

        En outre, si vous avez sélectionné Count only unique record sous Severity Threshold pour une règle DLP (Prévention des pertes de données), la gravité affiche le compte comme Count: <Number of Violations> unique. Si vous désélectionnez Count only unique record, le compte de gravité s'affiche sous la forme Count: <Number of Violations>.

        Object ID: The ID of the object or file.Timestamp: The date and time that the violation occurred.Instance: The application instance that triggered the violation.Instance Id: The ID of the application instance.Last Modified By: L'utilisateur ayant effectué les dernières modifications sur le fichier lorsque Netskope l'a traité.

        Note

        Dans la protection des données de l'API pour ServiceNow, pour certains types d'activités, l'utilisateur Last Modified By peut être l'utilisateur administrateur système ServiceNow au lieu de l'utilisateur réel. Ceci est dû au fait que, pour certaines activités telles qu'un téléchargement de fichier, ServiceNow effectue certaines vérifications et analyses. De ce fait, l'utilisateur Last Modified By peut être « system » ou « admin ».

        Object Owner: Le propriétaire d'origine de l'objet ou du fichier.File Path: Le chemin d’accès complet au fichier sur le périphériqueDLP Policy: La politique de DLP (Prévention des pertes de données) qui a déclenché la violationDLP Profile: Le profil de DLP (Prévention des pertes de données) associé à la politique et à la violation de DLP (Prévention des pertes de données)DLP Rule: Les règles de DLP (Prévention des pertes de données) associées à la politique et à la violation de DLP (Prévention des pertes de données).
    6. Select un ou plusieurs objets pour mettre à jour les sites Mark Status As et Severity ainsi que le site Assign afin de surveiller l'incident.
    7. Triez le tableau selon les critères suivants :
      • Object
      • Application
      • Site
      • Exposition
      • Statut
      • Assignee
      • Sévérité
      • Instance
      • Last Modified By
      • Propriétaire de l'objet
      • Timestamp
    8. Select un ou plusieurs objets pour mettre à jour le statut. Vous pouvez également :
      • Create Custom Status: Créez un nom pour un statut personnalisé.
      • Manage Custom Statuses: Affichez, modifiez ou supprimez les états personnalisés.
    9. Select un ou plusieurs objets pour modifier le niveau de gravité.
    10. Select un ou plusieurs objets permettant de choisir l'adresse électronique d'un administrateur chargé de surveiller l'incident.
    11. Exportez tous les incidents DLP (Prévention des pertes de données) (jusqu'à 500 000 lignes) vers un fichier CSV sous forme de résumé ou avec tous les détails.
    12. Cliquez L'icône Paramètres. pour personnaliser les colonnes du tableau ou rétablir celles par défaut.
    13. Visualisez jusqu'à 100 incidents DLP (Prévention des pertes de données) par page.
    14. Afficher plusieurs pages du tableau.
    La page DLP (Prévention des pertes de données) dans Incidents.

    Visualisation des détails de l'objet

    Sur la page DLP (Prévention des pertes de données), vous pouvez cliquer sur le site Object pour obtenir des informations plus détaillées.

    L’objet sur la page DLP (Prévention des pertes de données).

    En haut de la page Détails de l'objet, vous pouvez modifier les :

    • Status: Choisissez un statut pour l’objet. Cliquez L'icône Plus. pour :
      • Create Custom Status: Créez un nom pour un statut personnalisé.
      • Manage Custom Statuses: Affichez, modifiez ou supprimez les états personnalisés.
    • Assigned to: Choisissez l'adresse électronique d'un administrateur pour surveiller l'objet.
    • Severity: Sélectionnez un niveau de gravité pour l'objet.
    • Actions: Effectuer l’une des actions suivantes.
      • Encrypt: Chiffrer l'objet.
      • Restore: Restore the object.
      • BlockBloquez l'objet.

        Note

        L'interface utilisateur du locataire Netskope a désactivé les actions de chiffrement, de restauration et de blocage pour les fichiers dont l'option "require check out" est activée dans les sites SharePoint de Microsoft Office 365. Dans les cas où l'option de retrait obligatoire est activée, une copie du fichier est placée en quarantaine, mais le fichier original n'est pas supprimé.

        Disable-Actions-Require-CheckOut-SharePoint.png
      • Delete: Supprimer l'objet.
      • Release Email: libérer l'e-mail mis en quarantaine pour l'envoyer au destinataire (incidents de proxy SMTP uniquement).
      • Change File Permissions: Modifier les permissions des objets en restreignant l’accès à certains administrateurs, utilisateurs, propriétaires de fichiers, etc.
      • Contact Users: Contactez les utilisateurs impliqués dans l’objet.
      • Check Object History: Consultez l'historique de l'objet, y compris tous les incidents survenus avec l'objet, les journaux de correction ou d'actions entreprises sur l'objet, ainsi que d'autres informations sur l'activité et la version de l'objet à partir des données de l'API Protection.
      • Download Object: Téléchargez l’objet incident dans le dossier défini dans votre profil médico-légal. Pour en savoir plus : Télécharger les fichiers d’incidents DLP (Prévention des pertes de données).
      • View More: Consultez les détails résumés actuels de l’objet, y compris les informations de base, les liens partagés, les collaborateurs et l’historique des versions.

      Lorsqu'une pierre tombale échoue, Netskope affiche un message d'erreur :

      Le « fichier de la pierre tombale de quarantaine non généré avec succès. » message.
    La page Détails de l'objet.

    Visualisation des détails de l'incident

    Sous Incident Detail dans la page Détails de l'objet, vous pouvez voir les détails complets de l'objet :

    • Timestamp: La date et l'heure auxquelles la violation s'est produite.
    • Type: Le type d'incident.
    • Entity Created: Indique l'heure à laquelle l'entité a été créée dans l'application SaaS. Ceci s'applique uniquement à la protection des données de l'API de nouvelle génération.
    • Last Modified: Affiche l'heure à laquelle l'entité a été mise à jour ou modifiée pour la dernière fois. Ceci s'applique uniquement à la protection des données de l'API de nouvelle génération.
    • Last Modified By: L'utilisateur qui a apporté les dernières modifications au fichier lorsque Netskope l'a traité.

      Note

      Dans API données Protection pour ServiceNow, pour certains types d'activités, l'utilisateur Last Modified By peut être l'utilisateur administrateur système ServiceNow au lieu de l'utilisateur réel. Cela est dû au fait que, pour certaines activités telles qu'un téléchargement de fichier, ServiceNow effectue certaines vérifications et analyses. En raison de cela, l'utilisateur Last Modified By peut être « system » ou « admin ».

    • Activity: L'activité associée à l'incident.
    • Action Taken: Les mesures prises à la suite de l'incident en fonction de vos politiques.
    • Violations: Nombre total d'infractions enregistrées. Ce nombre fait référence au nombre total d'enregistrements détectés pour l'ensemble des politiques concernées par l'incident. Cliquez L’icône Netskope Go To. pour accéder aux alertes informatiques de Skope.
    • Application: L'application en nuage (par exemple, Dropbox) qui a déclenché la violation.
    • SiteLe site qui a déclenché l'infraction. Si Traffic Type est Cloud App, le site affiche le nom de l'application cloud. Si Traffic Type est Web, le site affiche le nom de domaine de deuxième niveau et le nom de domaine de premier niveau. Par exemple, pour « www.cnn.com », C'est « cnn.com ».
    • Instance: L'instance d'application qui a déclenché la violation.
    • URL: L'URL du fichier ou de l'application qui a déclenché la violation.
    • Object Name: Le nom du fichier ou de l'objet qui a déclenché l'infraction. Cliquez L’icône Netskope Go To. pour accéder aux détails du fichier dans la protection activée par API.
    • Object Type: Le type de l'objet sur lequel on agit. Il peut s'agir d'un fichier, d'un dossier, d'un rapport, d'un document, d'un message, etc.
    • File Path: Le chemin d'accès complet au fichier sur le périphérique de l'utilisateur.
    • File Type: Le type de fichier.
    • File Size: La taille du fichier en octets.
    • File Owner: Le créateur du fichier dans l'application.

      Note

      Dans Google Drive, lorsque vous modifiez le propriétaire d'un dossier, cela modifie uniquement le propriétaire du dossier sélectionné et n'affecte pas les fichiers qu'il contient. Par exemple, si vous changez le propriétaire d'un dossier de l'utilisateur A à l'utilisateur B:

      • la propriété du dossier passe à l'utilisateur B.
      • la propriété du contenu du dossier, c'est-à-dire des fichiers et des dossiers, ne passe pas à l'utilisateur B. Elle reste à l'utilisateur A.
    • File Language: La langue écrite du fichier.
    • True File Type: Le type de vrai fichier.
    • True File Category: La catégorie du vrai fichier.
    • From User: L'adresse électronique utilisée pour se connecter à l'application SaaS.
    • Channel: Le canal de l'utilisateur pour les applications Slack et Slack Enterprise.
    • Data Classification: Les détails de la classification des données.
    • Incident ID: L'identifiant de l'incident associé au sous-fichier. Si l'incident est déclenché pour le fichier principal, l'ID de l'incident sera le même que l'ID de l'incident parent.
    • Parent Incident ID: L'identifiant de l'incident associé au fichier principal du conteneur (ou du non-conteneur) qui a été analysé.
    • Object ID: L'ID de l'objet ou du fichier.
    • MD5: Le hachage MD5 du fichier. Vous pouvez utiliser cette valeur de hachage pour filtrer les événements de Skope IT et visualiser d'autres activités associées au fichier.
    • Connection ID: L'ID de l'incident de connexion. Chaque connexion a un identifiant unique.
    • App Session ID: L'identifiant unique de session de l'application/du site lorsque Traffic Type est Cloud App ou Web. Une session d'application commence lorsque les utilisateurs commencent à utiliser une application/un site cloud et se termine après une période d'inactivité (par exemple, 15 minutes). Vous pouvez utiliser cet identifiant pour consulter toutes les activités de l'utilisateur au cours d'une même session d'application. L'identifiant de session de l'application est unique pour un utilisateur, un périphérique, un navigateur et un domaine.
    • Referer: L'URL de référence de l'application (avec HTTP) que l'utilisateur a visitée.
    • Source: La ville de l'utilisateur telle que déterminée par la base de données géographique Maxmind ou IP2Location.
    • Destination: La ville de l'application telle que déterminée par la base de données géographique Maxmind ou IP2Location.

    Visualisation des infractions

    Sous Violations dans la page Détails de l'objet, vous pouvez voir une liste de toutes les violations DLP (Prévention des pertes de données) pour l'objet :

    • Cliquez L'icône Aperçu. pour afficher un aperçu des correspondances d'identifiants de données. Vous pouvez survoler les correspondances en surbrillance pour voir le profil DLP (Prévention des pertes de données) déclenché, l'identifiant de données, la règle DLP (Prévention des pertes de données) déclenchée et le niveau de gravité. En raison de la limite de stockage, tous les matchs ne sont pas mis en évidence.
    • Sous Overview, vous trouverez les informations suivantes :
      • Policy: La politique DLP (Prévention des pertes de données) déclenchée. Cliquez sur Edit Policy pour accéder à la page Protection en temps réel et modifier la stratégie DLP (Prévention des pertes de données).
      • Violations: Le nombre total de violations pour la politique DLP (Prévention des pertes de données).
      • Rule Hit: Une liste des règles DLP déclenchées (Prévention des pertes de données).
      • Policies: Une liste des politiques DLP (Prévention des pertes de données) associées à la règle DLP déclenchée (Prévention des pertes de données).
      • Severity: Le niveau de gravité et le nombre d'accès pour chaque règle DLP (Prévention des pertes de données). Si vous avez sélectionné Count only unique record sous Severity Threshold pour une règle DLP (Prévention des pertes de données), alors la gravité affiche le nombre comme Count: <Number of Violations> unique. Si vous désélectionnez Count only unique record, le nombre de gravité est affiché comme Count: <Number of Violations>.
    • Sous DLP Rule Violations, vous trouverez les informations suivantes :
      • #: Le numéro d’infraction.
      • Preview: Une liste des identifiants de données correspond. Passez la souris pour voir l’identifiant de données déclenché.
      • Rule: Cliquez pour afficher les détails de la règle DLP (Prévention des pertes de données) associée. Cliquez sur View Rule pour accéder à la page des règles DLP (Prévention des pertes de données).
      • DLP Profile: Cliquez pour afficher le détail du profil DLP (Prévention des pertes de données) associé. Cliquez sur View Profile pour accéder à la page Profil DLP (Prévention des pertes de données).
      • DLP Policy: Cliquez pour afficher les détails sur les raisons pour lesquelles la violation a déclenché la politique DLP (Prévention des pertes de données). Cliquez sur Edit Policy pour accéder à la page Protection en temps réel et modifier la stratégie DLP (Prévention des pertes de données).
    La section « Violations » de la page « Détails de l'objet ».

    Paramètres du workflow

    Cette fonction n'est pas disponible pour les locataires hébergés dans RUH1.

    Les incidents peuvent être transmis au responsable de l'utilisateur qui a déclenché l'incident. Cela permet au responsable de l'utilisateur à l'origine de l'action de donner son verdict, que l'action déclenchée soit requise à des fins professionnelles ou qu'elle enfreigne la politique de l'entreprise. Sur la base de ces commentaires, l'analyste peut décider de la manière de procéder à la résolution de l'incident.

    Le gestionnaire doit cliquer sur le verdict approprié pour compléter le workflow. Une fois le verdict donné, celui-ci ne peut plus être modifié et cliquer sur l’autre verdict n’aura aucun effet.

    Des courriels de rappel seront envoyés au gestionnaire 20 jours après le déclenchement de workflow.

    Le flux de travail expire après 30 jours de déclenchement et passera à un état No Response , moment où l’analyste pourra redéclencher le workflow.

    Conditions préalables

    Avant de configurer les workflows de correction, assurez-vous que les exigences suivantes sont satisfaites :

    • Les attributs SCIM personnalisés sont activés au sein de votre organisation pour récupérer les adresses e-mail des responsables.
    • L'utilisateur actif est importé dans le locataire Netskope et possède une adresse e-mail de responsable valide configurée dans son profil SCIM.
    • Votre politique de protection en temps réel inclut l'action Add SMTP Header pour mettre en quarantaine les messages signalés. Pour en savoir plus : Politiques de protection en temps réel.

    Autorisation de l'intégration Microsoft Exchange

    Pour les workflows de correction de la mise en quarantaine des e-mails dans Microsoft Exchange, effectuez les étapes d'autorisation suivantes :

    Étape 1 : Accorder l'authentification unifiée dans Netskope
    1. Depuis la console d'administration Netskope, allez à Incidents > DLP.
    2. Sur le côté droit, cliquez sur Workflow Settings.
    3. Dans le volet Workflow Settings, sélectionnez l'onglet Integrations.
    4. Cliquez sur Microsoft Exchange, connectez-vous avec votre compte d'administrateur Microsoft 365 et acceptez l'invite de consentement.
      • Lorsque le consentement réussit, Microsoft ajoute l'application d'entreprise Netskope for SMTP Workflow à votre client Microsoft Entra.
    Étape 2 : Attribuer le rôle d'administrateur de la sécurité dans le portail Azure
    1. Connectez-vous au portail Azure avec le même locataire Microsoft.
    2. Dans la barre de recherche supérieure, entrez Microsoft Entra roles and administrators et sélectionnez Microsoft Entra roles and administrators sous Services.
    3. Dans la page All roles, recherchez et sélectionnez Security Administrator.
    4. Cliquez sur Add assignments.
    5. Recherchez Netskope for SMTP Workflow, sélectionnez-le et cliquez sur Add.
    Les New autorisations peuvent prendre entre 30 minutes et 2 heures pour prendre effet dans Exchange Online.

    Configuration du mappage des approbateurs

    La configuration du mappage des approbateurs est globale pour votre tenant. Pour associer l’attribut personnalisé pour les escalades de responsable et les demandes de libération d’e-mails :

    1. Depuis la console d'administration Netskope, allez à Incidents > DLP.

    2. Sur le côté droit, cliquez sur Workflow Settings.

    3. Dans le volet Workflow Settings, sélectionnez l'onglet Approver Mapping.

    4. Sous Custom Attribute for Manager Email, cliquez sur la liste déroulante Manager Email – Custom Attribute.

    5. Select l'attribut personnalisé qui stocke l'adresse e-mail du responsable pour vos utilisateurs.

    6. Cliquez sur Save.

    Après avoir configuré le workflow, actualisez la page pour activer les options de workflow dans la vue des détails de l'incident.

    Lancement de workflow

    Vous pouvez lancer des workflows de remédiation directement à partir de la page des détails des incidents DLP (Prévention des pertes de données) :

    1. Depuis la console d'administration, allez dans Incidents > DLP.

    2. Cliquez sur l'incident que vous souhaitez corriger.

    3. Choisissez l'action de remédiation appropriée :

      Escalade des incidents vers les responsables

      1. Sur le côté droit, cliquez sur Initiate Workflow > Escalate to Manager.

        Cette action envoie une notification par e-mail au responsable de l’utilisateur pour lui demander son avis afin de déterminer si le Action is required for business ou le Action violates company policy.

      Libération des e-mails mis en quarantaine (Microsoft Exchange)

      Pour les incidents DLP (Prévention des pertes de données) liés aux e-mails lorsqu'un e-mail a été mis en quarantaine dans Microsoft Exchange :

      • Direct Release: cliquez sur RELEASE EMAIL dans la barre d’actions supérieure pour libérer immédiatement l’e-mail mis en quarantaine et l’envoyer aux destinataires sans demander l’approbation du responsable.

      • Request Manager Approval: Cliquez sur INITIATE WORKFLOW > Request Approval to Release Email. Le workflow s'initie immédiatement et envoie une notification par e-mail au responsable de l'expéditeur.

          Lorsque vous déclenchez le workflow :

          • L'expéditeur reçoit un e-mail de notification confirmant que le workflow d'approbation a été déclenché.
          • Une notification par e-mail est envoyée au responsable de l'expéditeur avec les détails de l'incident, notamment l'expéditeur, les destinataires, l'objet, l'horodatage, le nom des pièces jointes ainsi que les règles de DLP (Prévention des pertes de données) et les niveaux de gravité spécifiques enfreints. Le responsable peut cliquer sur Release ou Reject directement depuis la notification par e-mail.
          • L'expéditeur et l'analyste reçoivent tous deux des notifications par e-mail concernant le verdict d'approbation ou de rejet du responsable.

      Statuts et infobulles des workflows

      Le tableau suivant décrit les états de l'interface et les infobulles affichés pour les workflows de workflow :

      État du workflowDescriptionTooltip Text
      Missing Attribute MappingLe mappage d'attributs personnalisé n'a pas été configuré dans la configuration du workflow.Spécifiez le mappage d'attributs personnalisés dans la page de configuration du workflow afin d'activer et d'utiliser ce workflow.
      Workflow In ProgressUn workflow d'approbation a déjà été initié pour cet incident.Le workflow de demande d’approbation pour la libération de l’e-mail a déjà été initié. Vous pouvez réinitier ce workflow 30 jours après la date de déclenchement initiale si le responsable ne rend pas de verdict d’ici là.
      Missing Acting User EmailL'adresse e-mail de l'utilisateur actif est manquante ou ne peut pas être résolue.Aucune adresse e-mail d'utilisateur agissant valide à utiliser lors de la référence au gestionnaire à contacter lors de la tentative de libération de l'e-mail mis en quarantaine.
      Email ReleasedThe email was already released from quarantine (including duplicate incidents for the same email).Le bouton RELEASE EMAIL et l'option de menu Request Approval to Release Email sont désactivés, et une notification indique que l'e-mail a déjà été libéré.
      Not a Quarantined EmailL'incident n'est pas un incident d'e-mail mis en quarantaine.Le workflow de libération de la mise en quarantaine des e-mails n’est disponible que pour les incidents liés aux e-mails mis en quarantaine
      Not an SMTP Proxy IncidentL'incident n'a pas été détecté par le proxy SMTP.Le workflow de publication de la mise en quarantaine des e-mails n'est disponible que pour les incidents détectés par le proxy SMTP.
      Not Microsoft ExchangeL'incident de messagerie ne provenait pas de Microsoft Exchange.Le workflow de libération de la mise en quarantaine des e-mails est uniquement disponible pour les incidents de messagerie Microsoft Exchange
      Missing Exchange GrantAucun accès à une instance Microsoft Exchange n'a été accordé.Accordez l’accès à une instance Microsoft Exchange sur la page des intégrations de la configuration du workflow afin d’activer ce workflow.
      Quarantine ExpiredLa période de rétention de la mise en quarantaine de 30 jours est écoulée.Email can no longer be released from quarantine, as a quarantined email is only retained for 30 days from the incident date

      Toutes les actions de workflow, les réponses des gestionnaires et les opérations de libération sont enregistrées dans les détails de l'incident sous Incident Workflow Details et Object History.

      Ajout de notes aux incidents DLP (Prévention des pertes de données)

      Des notes peuvent désormais être ajoutées aux incidents DLP (Prévention des pertes de données). Les notes ont une limite de 512 caractères et vous pouvez ajouter jusqu'à 25 notes.
      Les privilèges des notes se trouvent dans Settings > Administration > Roles > (Role) > Privileges > Incidents > DLP. Vous pourrez définir des rôles en mode lecture seule ((View)) ou avec autorisation d'ajout ((Manage).

      Pour ajouter une note :

      1. Allez à Incidents > DLP.

      2. Cliquez sur n’importe quel Incident.

      3. Cliquez sur le bouton Incident Notes mis en évidence ci-dessus. La fenêtre Incident Notes s'ouvre alors.

      4. Saisissez votre texte et appuyez sur Add Note. Les notes ajoutées seront associées à l'utilisateur qui s'est connecté lors de leur ajout. Les utilisateurs (disposant au moins d'un droit d'écriture) peuvent être marqués avec @. Ces notes informeront la personne assignée aux incidents, y compris les personnes étiquetées sur la note spécifique.

      S'il y a plusieurs Incidents dans un Incident Event, chaque Incident aura son propre fil de notes.

      Visualisation des incidents DLP (Prévention des pertes de données) liés à des fichiers supprimés

      Pour savoir si un fichier a été supprimé :

      1. Allez à Incidents > DLP.
      2. Cliquez sur le site Object. La page Détails de l'objet s'affiche.
        L’objet sur la page DLP (Prévention des pertes de données).
      3. Sous Actions, Netskope affiche un message d'attention :
        « Attention : cet objet n’existe plus. » message.
      • Téléchargement des fichiers d'incidents DLP

      Dans ce thème
      • A propos de DLP (Prévention des pertes de données)