Personnaliser un type d’informations sensibles intégrés

Important :  Cet article a été traduit automatiquement, voir l’avertissement. Vous pouvez consulter la version en anglais de cet article ici.

Lorsque vous recherchez des informations sensibles dans le contenu, vous devez décrivent ces informations dans ce qu’on appelle une règle. Prévention des pertes (DLP) inclut des règles pour les types d’informations sensibles plus courantes que vous pouvez utiliser immédiatement. Pour utiliser les règles suivantes, vous devez les inclure dans une stratégie. Il peut arriver que vous souhaitez ajuster ces règles intégrées pour répondre aux besoins spécifiques de votre organisation, et vous pouvez le faire en créant un type d’informations sensibles personnalisé. Cette rubrique vous montre comment personnaliser le fichier XML qui contient la collection de règles existant pour détecter un large éventail d’informations de carte de crédit potentiels.

Vous pouvez prendre cet exemple et appliquez-le à d’autres types d’informations sensibles intégrés. Pour une liste des types d’informations sensibles par défaut et les définitions XML, voir Rechercher quels types d’informations sensibles.

Cette rubrique vous guide à travers les sections suivantes pour les personnalisations de règle XML :

Pour savoir en quoi consistent les différentes parties des règles et ce qu’elles font, voir Term glossary à la fin de cette rubrique.

Exporter le fichier XML des règles actuelles

Pour exporter le fichier XML, vous devez se connecter à la sécurité et le centre de conformité via PowerShell distante..

  1. Dans la session PowerShell, tapez la commande suivante pour afficher les règles de votre organisation à l’écran. Si vous n’avez pas créé votre propre, vous verrez uniquement les par défaut, les règles intégrées, intitulées « Package Microsoft Rule ».

    Get-DlpSensitiveInformationTypeRulePackage

  2. Stocker les règles de votre organisation dans une dans une variable en tapant ce qui suit. Stockage dans une variable rend facilement disponible plus loin dans un format qui convient à des commandes PowerShell à distance.

    $ruleCollections = Get-DlpSensitiveInformationTypeRulePackage

  3. Créez un fichier XML mis en forme avec les données en tapant ce qui suit. (Set-content est la partie de l’applet de commande qui enregistre le fichier XML dans le fichier).

    Set-Content -path "C:\custompath\exportedRules.xml" -Encoding Byte -Value $ruleCollections.SerializedClassificationRuleCollection

    Important : Assurez-vous que vous utilisez l’emplacement du fichier où votre pack règle se trouve en réalité. C:\custompath\ est un espace réservé.

Rechercher la règle à modifier dans le fichier XML

Les applets de commande ci-dessus exportés toute la collection de règles, qui inclut les règles par défaut que nous fournissons. Vous devez ensuite rechercher spécifiquement pour la règle de numéro de carte bancaire que vous souhaitez modifier.

  1. Utilisez un éditeur de texte pour ouvrir le fichier XML que vous avez exporté dans la section précédente.

  2. Faites défiler jusqu'à la balise <Rules> , qui correspond au début de la section qui contient les règles DLP. (Car ce fichier XML contient les informations relatives à la collection de règles entier, il contient d’autres informations dans la partie supérieure dont vous avez besoin de faire défiler pour accéder aux règles).

  3. Recherchez Func_credit_card rechercher la définition des règles de numéro de carte de crédit. (Dans le code XML, les noms de règle ne peut pas contenir d’espaces, afin que les espaces sont généralement remplacées par des traits de soulignement et les noms de règle sont parfois l’abréviation. La règle de numéros de sécurité sociale américain, est un exemple de ce qui est sous forme abrégée « Numéro de sécurité sociale. » La règle de numéro de carte de crédit XML doit ressembler à l’exemple de code suivant.

    <Entity id="50842eb7-edc8-4019-85dd-5a5c1f2bb085"
           patternsProximity="300" recommendedConfidence="85">
          <Pattern confidenceLevel="85">
           <IdMatch idRef="Func_credit_card" />
            <Any minMatches="1">
              <Match idRef="Keyword_cc_verification" />
              <Match idRef="Keyword_cc_name" />
              <Match idRef="Func_expiration_date" />
            </Any>
          </Pattern>
        </Entity>

Maintenant que vous avez localisé la définition de règle de numéro de carte de crédit dans le XML, vous pouvez personnaliser le XML de la règle pour répondre à vos besoins. (Pour un rappel sur les définitions XML, voir Term glossary à la fin de cette rubrique.)

Modifier le XML et créer un type d’informations sensibles

Vous devez tout d’abord, créez un nouveau type d’informations sensibles, car vous ne pouvez pas modifier directement les règles par défaut. Vous pouvez effectuer un large éventail de points avec des types d’informations sensibles personnalisée, qui sont décrites dans créer un type d’informations sensibles personnalisé. Dans cet exemple, nous allons Restez simple et uniquement supprimer la preuve destinée et ajouter des mots clés à la règle de numéro de carte de crédit.

Toutes les définitions de règle XML sont construites sur le modèle général suivant. Vous devez copier et coller le XML de définition de numéro de carte de crédit dans le modèle, modifier certaines valeurs (remarquez les espaces réservés « . . .” dans l’exemple suivant), puis télécharger le XML modifié en tant que nouvelle règle pouvant être utilisée dans des stratégies.

<?xml version="1.0" encoding="utf-16"?>
<RulePackage xmlns="http://schemas.microsoft.com/office/2011/mce">
  <RulePack id=". . .">
    <Version major="1" minor="0" build="0" revision="0" />
    <Publisher id=". . ." /> 
    <Details defaultLangCode=". . .">
      <LocalizedDetails langcode=" . . . ">
         <PublisherName>. . .</PublisherName>
         <Name>. . .</Name>
         <Description>. . .</Description>
      </LocalizedDetails>
    </Details>
  </RulePack>
  
 <Rules>
   <!-- Paste the Credit Card Number rule definition here.--> 

      <LocalizedStrings>
         <Resource idRef=". . .">
           <Name default="true" langcode=" . . . ">. . .</Name>
           <Description default="true" langcode=". . ."> . . .</Description>
         </Resource>
      </LocalizedStrings>

   </Rules>
</RulePackage>

Vous obtenez maintenant quelque chose qui ressemble au XML suivant. Étant donné que les packages de règles et les règles sont identifiés par leur GUID unique, vous devez générer deux GUID : un pour le package de règles et un pour remplacer le GUID de la règle de numéro de carte de crédit. (Le GUID pour l’ID d’entité dans l’exemple de code suivant est celui de la définition de notre règle intégrée, que vous devez remplacer.) Il existe plusieurs façons de générer des GUID, mais vous pouvez le faire facilement dans PowerShell en saisissant [guid]::NewGuid().

<?xml version="1.0" encoding="utf-16"?>
<RulePackage xmlns="http://schemas.microsoft.com/office/2011/mce">
  <RulePack id="8aac8390-e99f-4487-8d16-7f0cdee8defc">
    <Version major="1" minor="0" build="0" revision="0" />
    <Publisher id="8d34806e-cd65-4178-ba0e-5d7d712e5b66" />
    <Details defaultLangCode="en">
      <LocalizedDetails langcode="en">
        <PublisherName>Contoso Ltd.</PublisherName>
        <Name>Financial Information</Name>
        <Description>Modified versions of the Microsoft rule package</Description>
      </LocalizedDetails>
    </Details>
  </RulePack>
  
 <Rules>
    <Entity id="db80b3da-0056-436e-b0ca-1f4cf7080d1f"
       patternsProximity="300" recommendedConfidence="85">
      <Pattern confidenceLevel="85">
        <IdMatch idRef="Func_credit_card" />
        <Any minMatches="1">
          <Match idRef="Keyword_cc_verification" />
          <Match idRef="Keyword_cc_name" />
          <Match idRef="Func_expiration_date" />
        </Any>
      </Pattern>
    </Entity>

      <LocalizedStrings>
         <Resource idRef="db80b3da-0056-436e-b0ca-1f4cf7080d1f"> 
<!-- This is the GUID for the preceding Credit Card Number entity because the following text is for that Entity. -->
           <Name default="true" langcode="en-us">Modified Credit Card Number</Name>
           <Description default="true" langcode="en-us">Credit Card Number that looks for additional keywords, and another version of Credit Card Number that doesn’t require keywords (but has a lower confidence level)</Description>
         </Resource>
      </LocalizedStrings>

   </Rules>
</RulePackage>

Supprimer l’exigence de preuve crédible d’un type d’informations sensibles

Maintenant que vous avez un nouveau type d’informations sensibles dont vous êtes en mesure de télécharger à la sécurité et le centre de conformité, l’étape suivante consiste pour rendre la règle plus spécifique. Modifier la règle afin qu’elle recherche uniquement pour un nombre de 16 chiffres qui passe la somme de contrôle, mais ne nécessite pas de preuve (destinée) supplémentaire (par exemple des mots-clés). Pour ce faire, vous devez supprimer la partie du code XML qui ressemble de preuves destiné. Preuve destinée est très utile pour réduire les fausses, car en règle générale, il existe certains mots clés ou une date d’expiration près du numéro de carte de crédit. Si vous supprimez cette preuve, vous devez également ajuster comment vous êtes-vous sûr que vous avez trouvé un numéro de carte de crédit en réduisant la confidenceLevel, c'est-à-dire 85 dans l’exemple.

<Entity id="db80b3da-0056-436e-b0ca-1f4cf7080d1f" patternsProximity="300"
      <Pattern confidenceLevel="85">
        <IdMatch idRef="Func_credit_card" />
      </Pattern>
    </Entity>

Rechercher des mots clés propres à votre organisation

Vous souhaiterez peut-être exiger des preuves destiné mais voulez différentes ou supplémentaires de mots clés, et vous souhaiterez peut-être modifier où trouver cette preuve. Vous pouvez ajuster la patternsProximity pour développer ou réduire la fenêtre de preuves destiné entoure le numéro de 16 chiffres. Pour ajouter vos propres mots clés, vous devez définir une liste de mots clés et faire référence au sein de votre règle. Le code XML suivant ajoute les mots-clés « carte d’entreprise » et « Carte Contoso » afin que les messages contenant ces phrases au sein de 150 caractères d’un numéro de carte bancaire sont traités comme un numéro de carte de crédit.

<Rules>
<! -- Modify the patternsProximity to be "150" rather than "300." -->
    <Entity id="db80b3da-0056-436e-b0ca-1f4cf7080d1f" patternsProximity="150" recommendedConfidence="85">
      <Pattern confidenceLevel="85">
        <IdMatch idRef="Func_credit_card" />
        <Any minMatches="1">
          <Match idRef="Keyword_cc_verification" />
          <Match idRef="Keyword_cc_name" />
<!-- Add the following XML, which references the keywords at the end of the XML sample. -->
          <Match idRef="My_Additional_Keywords" />
          <Match idRef="Func_expiration_date" />
        </Any>
      </Pattern>
    </Entity>
<!-- Add the following XML, and update the information inside the <Term> tags with the keywords that you want to detect. -->
    <Keyword id="My_Additional_Keywords">
      <Group matchStyle="word">
        <Term caseSensitive="false">company card</Term>
        <Term caseSensitive="false">Contoso card</Term>
      </Group>
    </Keyword>

Télécharger votre règle

Pour télécharger votre règle, vous devez procéder comme suit.

  1. Enregistrez-la en tant que fichier .xml avec le codage Unicode. Ceci est important car la règle ne fonctionne pas si le fichier est enregistré dans un codage différent.

  2. Se connecter à la sécurité et le centre de conformité via PowerShell distante.

  3. Dans la session PowerShell, tapez les informations suivantes.

    New-DlpSensitiveInformationTypeRulePackage -FileData (Get-Content -Path "C:\custompath\MyNewRulePack.xml" -Encoding Byte.

    Important : Assurez-vous que vous utilisez l’emplacement du fichier où votre pack règle se trouve en réalité. C:\custompath\ est un espace réservé.

  4. Pour confirmer, tapez O, puis appuyez sur entrée.

  5. Vérifiez que votre nouvelle règle a été téléchargé en tapant Get-DlpSensitiveInformationType, qui affiche désormais le nom de votre règle.

Pour commencer à utiliser la nouvelle règle pour détecter les informations sensibles, vous devez ajouter la règle à une stratégie DLP. Pour savoir comment ajouter la règle à une stratégie, voir créer une stratégie DLP à partir d’un modèle.

Glossaire terminologique

Voici les définitions des termes que vous avez rencontrés au cours de cette procédure.

Terme

Définition

Entité

Les entités sont ce que nous appelons des types d’informations sensibles, comme les numéros de carte de crédit. Chaque entité possède un GUID unique qui constitue son ID. Si vous copiez un GUID et que vous le recherchez dans le XML, vous trouvez la définition de règle XML, ainsi que toutes les traductions localisées de cette règle XML. Vous pouvez également trouver cette définition en localisant le GUID de la traduction, puis en recherchant ce GUID.

Fonctions

Le fichier XML référence Func_credit_card, qui est une fonction dans le code compilé. Fonctions sont utilisées pour exécuter regexes complexes et vérifiez que les totaux de contrôle de nos règles intégrés correspondre.) Étant donné que cela se produit dans le code, certaines des variables n’apparaissent pas dans le fichier XML.

IdMatch

Il s’agit de l’identificateur qui est le modèle de données à jour correspondre à la — par exemple, un numéro de carte de crédit. Vous pouvez en savoir plus à ce sujet et sur les balises Match dans les règles entité.

Listes de mots clés

Le fichier XML fait référence également keyword_cc_verification et keyword_cc_name, qui sont des listes de mots clés à partir de laquelle nous cherchons des correspondances au sein de la patternsProximity pour l’entité. Ceux-ci ne sont pas actuellement affichés dans le fichier XML.

Modèle

Le modèle contient la liste de ce que le type sensible recherche. Cela inclut des mots clés, des expressions régulières et des fonctions internes (qui effectuent des tâches telles que la vérification des sommes de contrôle). Ces types d’informations sensibles peuvent avoir plusieurs modèles avec des niveaux de confiance uniques. Ceci est utile lors de la création d’un type d’informations sensibles qui renvoie un niveau de confiance élevé si des preuves crédibles sont trouvées et un niveau de confiance faible dans le cas contraire.

confidenceLevel

Il s’agit du niveau de confiance appliqué lorsque le moteur DLP trouve une correspondance. Ce niveau de confiance est associé à une correspondance pour le modèle si les exigences du modèle sont remplies. C’est la mesure de confiance à prendre en considération lorsque vous utilisez des règles de transport Exchange.

patternsProximity

Quand nous trouvé ce à quoi ressemble un modèle de numéro de carte de crédit, patternsProximity est la proximité autour de ce numéro où nous allons examiner les preuves destiné.

recommendedConfidence

C’est le niveau de confiance que nous vous recommandons de cette règle. La confiance recommandée s’applique aux entités et affinités. Pour les entités, ce nombre n’est jamais évalué contre la confidenceLevel pour le modèle. Il est simplement une suggestion pour vous aider à choisir un niveau de confiance si vous voulez appliquer. Pour affinités, confidenceLevel du modèle doit être supérieure au nombre de recommendedConfidence pour une action ETR à appeler. La recommendedConfidence est le niveau de confiance par défaut utilisé dans ETRs qui appelle une action. Si vous le souhaitez, vous pouvez modifier manuellement la ETR à appeler en fonction de niveau de confiance du motif, à la place.

Pour plus d’informations

Remarque : Avertissement traduction automatique : cet article a été traduit par un ordinateur, sans intervention humaine. Microsoft propose cette traduction automatique pour offrir aux personnes ne maîtrisant pas l’anglais l’accès au contenu relatif aux produits, services et technologies Microsoft. Comme cet article a été traduit automatiquement, il risque de contenir des erreurs de grammaire, de syntaxe ou de terminologie.

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoignez le programme Office Insider

Ces informations vous ont-elles été utiles ?

Nous vous remercions pour vos commentaires.

Merci pour vos commentaires. Il serait vraisemblablement utile pour vous de contacter l’un de nos agents du support Office.

×