Personnaliser un type d’informations sensibles intégré

Article
03/11/2024

Lorsque vous recherchez des informations de contenu sensible vous devez décrire ces informations dans ce que l'on appelle une règle. Protection contre la perte de données Microsoft Purview (DLP) inclut des règles pour les types d’informations sensibles les plus courants. Vous pouvez utiliser ces règles immédiatement. Pour les utiliser, vous devez les inclure dans une stratégie. Vous pouvez ajuster ces règles intégrées pour répondre aux besoins spécifiques de votre organization. Pour ce faire, vous pouvez créer un type d’informations sensibles personnalisé. Cette rubrique vous montre comment personnaliser le fichier XML qui contient la collection de règles existante afin de pouvoir détecter un plus large éventail d’informations de crédit potentielles carte.

Vous pouvez prendre cet exemple et l'appliquer à d'autres types d'informations sensibles intégrés. Pour obtenir la liste des types d’informations sensibles par défaut et des définitions XML, consultez Définitions d’entité de type d’informations sensibles.

Conseil

Si vous n’êtes pas un client E5, utilisez la version d’évaluation de 90 jours des solutions Microsoft Purview pour découvrir comment des fonctionnalités Supplémentaires purview peuvent aider vos organization à gérer les besoins en matière de sécurité et de conformité des données. Commencez dès maintenant au hub d’essais portail de conformité Microsoft Purview. En savoir plus sur les conditions d’inscription et d’essai.

Exporter le fichier XML des règles actuelles

Pour exporter le code XML, vous devez vous connecter au PowerShell de sécurité et conformité.

Dans PowerShell, tapez ce qui suit pour afficher les règles de votre organization à l’écran. Si vous n'avez pas créé votre propre règle, vous ne verrez que les règles intégrées par défaut, sous le libellé « Package de règles Microsoft ».
```
Get-DlpSensitiveInformationTypeRulePackage
```
Stockez les règles de votre organisation dans une variable en tapant ce qui suit. Le stockage d’un élément dans une variable le rend facilement disponible ultérieurement dans un format qui fonctionne pour les commandes PowerShell.
```
$ruleCollections = Get-DlpSensitiveInformationTypeRulePackage
```
Créez un fichier XML formaté avec toutes ces données en tapant ce qui suit.
```
[System.IO.File]::WriteAllBytes('C:\custompath\exportedRules.xml', $ruleCollections.SerializedClassificationRuleCollection)
```
Importante

Assurez-vous que vous utilisez l’emplacement de fichier dans lequel votre pack de règles est effectivement stocké. C:\custompath\ est un espace réservé.

Rechercher la règle à modifier dans le fichier XML

Les applets de commande ci-dessus ont exporté l’intégralité de la collection de règles, qui inclut les règles par défaut que Microsoft fournit. Ensuite, vous devez rechercher spécifiquement la règle de numéro de carte de crédit que vous souhaitez modifier.

Utilisez un éditeur de texte pour ouvrir le fichier XML que vous avez exporté dans la section précédente.
Faites défiler jusqu’à la <Rules> balise, qui est le début de la section qui contient les règles DLP. Étant donné que ce fichier XML contient les informations relatives à l’ensemble de la collection de règles, il contient d’autres informations en haut que vous devez faire défiler au-dessus pour accéder aux règles.
Recherchez Func_credit_card pour trouver la définition de règle de numéro de carte de crédit. Dans le code XML, les noms de règle ne pouvant pas contenir d’espaces, les espaces sont généralement remplacés par des traits de soulignement et les noms de règle sont parfois abrégés. La règle de numéro de sécurité sociale des États-Unis, abrégée SSN, en est un exemple. Le code XML de la règle de numéro de carte de crédit 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 une actualisation des définitions XML, consultez le glossaire de terme à la fin de cette rubrique.

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

Tout d'abord, vous devez créer un type d'informations sensibles, car vous ne pouvez pas modifier directement les règles par défaut. Vous pouvez effectuer un large éventail de tâches avec des types d’informations sensibles personnalisés, qui sont décrits dans Créer un type d’informations sensibles personnalisé dans le PowerShell de sécurité et conformité. Pour cet exemple, nous allons rester simples et nous contenter de supprimer les preuves crédibles et d'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 code XML de définition du numéro de carte de crédit dans le modèle, modifier certaines valeurs (notez le . . espaces réservés dans l’exemple suivant), puis chargez le code XML modifié en tant que nouvelle règle qui peut être utilisée dans les stratégies.

<?xml version="1.0" encoding="utf-16"?>
<RulePackage xmlns="https://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 de l’ID d’entité dans l’exemple de code suivant est celui de notre définition de règle intégrée, que vous devez remplacer par une nouvelle. Vous disposez de plusieurs méthodes pour générer des GUID, mais cette opération peut être effectuée facilement dans PowerShell en saisissant [guid]::NewGuid().

<?xml version="1.0" encoding="utf-16"?>
<RulePackage xmlns="https://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

Vous disposez maintenant d’un nouveau type d’informations sensibles que vous pouvez charger dans le portail de conformité Microsoft Purview. L’étape suivante consiste à rendre la règle plus spécifique. Modifiez la règle afin qu’elle recherche uniquement un nombre à 16 chiffres qui passe la somme de contrôle, mais qui ne nécessite pas de preuves supplémentaires (corroboratives), telles que des mots clés. Pour ce faire, vous devez retirer la partie du XML qui recherche la preuve corroborante. Les preuves corroborantes sont très utiles pour réduire les faux positifs. Dans ce cas, il existe généralement certains mots clés ou une date d’expiration proche du numéro de carte de crédit. Si vous supprimez cette preuve, vous devez également ajuster votre niveau de confiance par rapport au fait que vous avez trouvé un numéro de carte de crédit en abaissant la valeur du paramètre confidenceLevel qui est définie sur 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 voulez peut-être exiger des preuves crédibles, mais aussi des mots clés différents ou supplémentaires, et vous voulez aussi peut-être modifier l’endroit où rechercher ces preuves. Vous pouvez ajuster pour patternsProximity développer ou réduire la fenêtre pour obtenir des preuves corroboratives autour du nombre à 16 chiffres. Pour ajouter vos propres mots clés, vous devez définir une liste mot clé et la référencer dans votre règle. Le code XML suivant ajoute les mots clés « company carte » et « Contoso carte », afin que tout message qui contient ces expressions dans les 150 caractères d’un numéro de carte de crédit soit identifié 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.

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.
Se connecter à Security & Compliance PowerShell.
Dans PowerShell, saisissez la commande suivante.
```
New-DlpSensitiveInformationTypeRulePackage -FileData ([System.IO.File]::ReadAllBytes('C:\custompath\MyNewRulePack.xml'))
```
Importante

Assurez-vous que vous utilisez l’emplacement de fichier dans lequel votre pack de règles est effectivement stocké. C:\custompath\ est un espace réservé.
Pour confirmer, saisissez Y, puis appuyez sur Entrée.
Vérifiez le nom complet de votre nouvelle règle et qu’elle a été chargée, en entrant :
```
Get-DlpSensitiveInformationType
```

Pour commencer à utiliser la nouvelle règle afin de détecter des informations sensibles, vous devez l'ajouter à une stratégie DLP. Pour savoir comment ajouter la règle à une stratégie, consultez Créer et déployer des stratégies de protection contre la perte de données.

Glossaire terminologique

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

Terme	Définition
Entity	Les entités sont ce que nous appelons des types d’informations sensibles, tels que 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 fait référence `Func_credit_card`à , qui est une fonction dans le code compilé. Les fonctions sont utilisées pour exécuter des expressions régulières complexes et vérifier que les sommes de contrôle correspondent à nos règles intégrées. Étant donné que cela se produit dans le code, certaines variables n’apparaissent pas dans le fichier XML.
IdMatch	Il s’agit de l’identificateur auquel le modèle tente de correspondre, par exemple un numéro de carte de crédit.
Listes de mots clés	Le fichier XML fait également référence `keyword_cc_verification` à et `keyword_cc_name`, qui sont des listes de mots clés que nous cherchons à faire correspondre dans pour `patternsProximity` l’entité . Ces éléments ne sont actuellement pas affichés dans le fichier XML.
Modèle	Le modèle contient la liste des éléments recherchés par le type sensible. Celle-ci 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. Les 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. Il s’agit de la mesure de confiance que vous devez prendre en compte lors de l’utilisation de règles de flux de messagerie Exchange (également appelées règles de transport).
patternsProximity	Lorsque nous trouvons ce qui ressemble à un modèle de nombre carte de crédit, `patternsProximity` est la distance autour de ce nombre où nous allons rechercher des preuves corroboratives.
recommendedConfidence	Il s'agit du niveau de confiance que nous recommandons pour cette règle. Le niveau de confiance recommandé s’applique aux entités et aux affinités. Pour les entités, ce nombre n’est jamais évalué par rapport au `confidenceLevel` pour le modèle. Il s'agit d'une simple suggestion pour vous aider à choisir un niveau de confiance, si vous voulez en appliquer un. Pour les affinités, le `confidenceLevel` du modèle doit être supérieur au `recommendedConfidence` nombre d’actions de règle de flux de messagerie à appeler. est `recommendedConfidence` le niveau de confiance par défaut utilisé dans les règles de flux de courrier qui appellent une action. Si vous le souhaitez, vous pouvez modifier manuellement la règle de flux de courrier pour qu’elle soit appelée en fonction du niveau de confiance du modèle.