InfoTypes et détecteurs d'infoTypes

La protection des données sensibles se sert de types d'informations ou infoTypes pour définir ce qui doit être analysé. Un infoType est un type de données sensibles, par exemple un nom, une adresse e-mail, un numéro de téléphone, un numéro d'identification, un numéro de carte de crédit, etc. Un détecteur d'infoType est un mécanisme de détection qui établit des correspondances en fonction des critères d'un infoType.

Bonnes pratiques pour sélectionner des infoTypes

Comprendre vos données est l'une des premières étapes essentielles pour les protéger. Il est recommandé de ne collecter, stocker et traiter que les informations dont vous avez besoin pour votre activité. En identifiant les données que vous gérez, vous pouvez prendre des décisions éclairées pour votre entreprise, vos utilisateurs, et votre posture en matière de sécurité et de confidentialité des données.

Certains de vos cas d'utilisation commerciaux peuvent nécessiter certaines informations sensibles, et d'autres non. Il n'existe pas de solution unique adaptée à tous les cas d'utilisation. C'est pourquoi Sensitive Data Protection offre un contrôle flexible sur les types de données à rechercher. Si vous utilisez des infoTypes pour l'anonymisation ou le masquage, vous pouvez également contrôler quand et comment les données sont transformées.

Consignes générales

Tenez compte des consignes générales suivantes lorsque vous sélectionnez des infoTypes.

Informations sensibles que vous n'avez pas besoin de collecter

Chaque service de votre entreprise ne doit collecter que les données dont il a besoin. Par exemple, certains services de votre entreprise n'ont pas besoin de collecter des informations financières. Pour ces services, envisagez d'activer des détecteurs d'infoTypes tels que CREDIT_CARD_NUMBER, FINANCIAL_ACCOUNT_NUMBER et d'autres infoTypes de la catégorie sectorielle FINANCE.

Informations que vous devez collecter, mais que vous ne souhaitez pas partager largement avec votre équipe

Il peut exister des cas d'utilisation valides pour la collecte d'informations personnelles, mais vous ne devez pas les partager largement avec votre équipe. Par exemple, un client qui envoie une demande d'assistance peut vous fournir ses coordonnées afin que vous puissiez le contacter pour résoudre les problèmes. Vous ne voulez pas que tous les membres de l'équipe qui consultent la demande voient les informations permettant d'identifier personnellement l'utilisateur. Envisagez d'activer les détecteurs d'infoTypes tels que PHONE_NUMBER, EMAIL_ADDRESS et d'autres infoTypes dans la catégorie de type PII.

Catégories de données sensibles soumises à des réglementations sectorielles, sur la confidentialité des données ou juridictionnelles

Certains types d'informations sont considérés comme sensibles en raison de la façon dont ils sont émis ou de l'utilisation à laquelle ils peuvent être destinés. Dans d'autres cas, les informations contextuelles et démographiques sont considérées comme une catégorie protégée. Ces types d'informations peuvent être soumis à des restrictions supplémentaires concernant la façon dont ils sont collectés, utilisés et gérés. Envisagez d'activer les détecteurs d'infoTypes dans les catégories suivantes:

• Catégorie de type SPII, GOVERNMENT_ID et DEMOGRAPHIC
• Catégorie sectorielle HEALTH

Choisir entre des infoTypes similaires

Tenez compte des éléments suivants lorsque vous choisissez entre des détecteurs d'infoType similaires.

Passeports

Si vous n'avez pas besoin de rechercher des identifiants de passeport d'un pays spécifique, choisissez le détecteur généralisé: PASSPORT.

Certains détecteurs de passeports spécifiques à un pays, comme UK_PASSPORT, sont disponibles. Toutefois, certains détecteurs de passeports spécifiques à un pays ne peuvent identifier que les passeports de formats spécifiques ou en présence d'indices contextuels.

Noms de personnes

Lorsque vous recherchez des noms de personnes, utilisez PERSON_NAME pour la plupart des cas d'utilisation au lieu de FIRST_NAME ou LAST_NAME.

PERSON_NAME est un détecteur de noms de personnes. Il inclut les noms composés d'un seul mot et les noms complets. Ce détecteur tente de détecter, par exemple, des noms comme Jane, Jane Smith et Jane Marie Smith à l'aide de diverses technologies, y compris la compréhension du langage naturel. FIRST_NAME et LAST_NAME sont des sous-ensembles de ce détecteur qui tentent d'identifier des parties d'un nom. Les résultats de ces détecteurs sont toujours des sous-ensembles des résultats de PERSON_NAME.

Dates et heures

Si vous n'avez pas besoin d'analyser toutes les dates, envisagez d'utiliser un détecteur de date ciblé comme DATE_OF_BIRTH. Ce détecteur tente d'identifier le contexte indiquant que la date est liée à la date de naissance d'une personne.

Le détecteur DATE tente de trouver toutes les dates, quel que soit le contexte. Il signale également les dates relatives, comme aujourd'hui ou hier. De même, TIME tente de trouver tous les codes temporels.

Emplacements

Si vous n'avez pas besoin d'analyser tous les emplacements, envisagez d'utiliser STREET_ADDRESS au lieu du détecteur LOCATION. Le détecteur STREET_ADDRESS tente de trouver des adresses entièrement qualifiées, qui sont généralement plus précises que les zones géographiques génériques et peuvent être considérées comme plus sensibles.

Le détecteur d'infoType LOCATION tente de trouver n'importe quel emplacement, quel que soit le contexte (par exemple, Paris ou Canada).

Détecteurs d'infoTypes nécessitant un contexte

De nombreux détecteurs d'infoType nécessitent la présence d'indices contextuels avant d'identifier une correspondance. Si un détecteur d'infoType intégré ne signale pas les éléments que vous attendez, car aucun indice contextuel ne se produit à proximité de ces éléments, envisagez d'utiliser GENERIC_ID ou un détecteur d'infoType personnalisé à la place.

Types d'informations qui ne font pas l'objet d'une définition commune dans le secteur

Certains types d'informations ne disposent pas d'une définition commune dans le secteur. Il peut s'agir, par exemple, de numéros de dossiers médicaux, de numéros de compte, de codes secrets et de codes de sécurité. Pour ces types, envisagez d'utiliser des infoTypes tels que GENERIC_ID, FINANCIAL_ACCOUNT_NUMBER et MEDICAL_RECORD_NUMBER. Ces détecteurs combinent la détection d'entités et le contexte pour trouver des éléments potentiellement sensibles.

Détecteurs d'infoTypes à latence plus élevée

• Évitez d'activer les détecteurs d'infoTypes dont vous n'avez pas besoin. Bien que les éléments suivants soient utiles dans certains scénarios, ces infoTypes peuvent ralentir considérablement les requêtes par rapport à celles qui ne les incluent pas:

  • PERSON_NAME
  • FEMALE_NAME
  • MALE_NAME
  • FIRST_NAME
  • LAST_NAME
  • DATE_OF_BIRTH
  • LOCATION
  • STREET_ADDRESS
  • ORGANIZATION_NAME

• Spécifiez toujours les détecteurs d'infoTypes explicitement. N'utilisez pas de liste d'infoTypes vide.

Utiliser des infoTypes

La protection des données sensibles se sert des détecteurs d'infoTypes dans la configuration de ses analyses pour déterminer les éléments à inspecter et la façon dont elle doit transformer les résultats. Les noms des infoTypes sont également utilisés lorsque vous affichez des résultats d'analyse ou créez des rapports.

Par exemple, si vous souhaitez rechercher des adresses e-mail dans un bloc de texte, vous devez spécifier le détecteur d'infoType EMAIL_ADDRESS dans la configuration d'inspection. Si vous souhaitez effacer les adresses e-mail qui figurent dans un bloc de texte, spécifiez EMAIL_ADDRESS dans la configuration d'inspection et d'anonymisation de façon à indiquer la méthode d'effacement ou de transformation à utiliser pour ce type de données.

En outre, vous pouvez utiliser une combinaison de détecteurs d'infoTypes intégrés et personnalisés de façon à exclure un sous-ensemble d'adresses e-mail des résultats d'analyse. Tout d'abord, créez un infoType personnalisé nommé INTERNAL_EMAIL_ADDRESS et configurez-le de façon à exclure les adresses e-mail de test internes. Ensuite, configurez l'analyse de façon à inclure les résultats correspondant à l'infoType EMAIL_ADDRESS, mais spécifiez une règle d'exclusion afin d'exclure tous les résultats correspondant à l'infoType INTERNAL_EMAIL_ADDRESS. Pour en savoir plus sur les règles d'exclusion et les autres fonctionnalités des détecteurs d'infoTypes personnalisés, consultez la page Créer des détecteurs d'infotype personnalisés.

La protection des données sensibles fournit un ensemble de détecteurs d'infoTypes intégrés que vous spécifiez par leur nom, chacun étant répertorié dans la documentation de référence sur les détecteurs d'InfoTypes. Ces détecteurs s'appuient sur diverses techniques pour détecter et classifier chaque type de données. Par exemple, certains détecteurs utilisent une correspondance de modèle, d'autres des sommes de contrôle mathématiques, des limitations numériques particulières, des préfixes spécifiques ou encore le contexte particulier des données identifiées.

Examples

Lorsque vous configurez la protection des données sensibles pour analyser votre contenu, vous incluez dans la configuration de l'analyse les détecteurs d'infoTypes à utiliser.

Par exemple, les extraits de code JSON et le code suivants illustrent une requête d'analyse simple envoyée à l'API DLP. Vous remarquerez que le détecteur d'infoType PHONE_NUMBER est spécifié dans inspectConfig, qui indique à la protection des données sensibles d'analyser la chaîne fournie pour rechercher un numéro de téléphone.

using System;
using Google.Api.Gax.ResourceNames;
using Google.Cloud.Dlp.V2;

public class InspectPhoneNumber
{
    public static InspectContentResponse Inspect(
        string projectId,
        string text,
        Likelihood minLikelihood = Likelihood.Possible)
    {
        // Instantiate a client.
        var dlp = DlpServiceClient.Create();

        // Set content item.
        var contentItem = new ContentItem { Value = text };

        // Construct inspect config.
        var inspectConfig = new InspectConfig
        {
            InfoTypes = { new InfoType { Name = "PHONE_NUMBER" } },
            IncludeQuote = true,
            MinLikelihood = minLikelihood
        };

        // Construct a request.
        var request = new InspectContentRequest
        {
            ParentAsLocationName = new LocationName(projectId, "global"),
            InspectConfig = inspectConfig,
            Item = contentItem,
        };

        // Call the API.
        var response = dlp.InspectContent(request);

        // Inspect the results.
        var resultFindings = response.Result.Findings;

        Console.WriteLine($"Findings: {resultFindings.Count}");

        foreach (var f in resultFindings)
        {
            Console.WriteLine("\tQuote: " + f.Quote);
            Console.WriteLine("\tInfo type: " + f.InfoType.Name);
            Console.WriteLine("\tLikelihood: " + f.Likelihood);
        }

        return response;
    }
}

import (
	"context"
	"fmt"
	"io"

	dlp "cloud.google.com/go/dlp/apiv2"
	"cloud.google.com/go/dlp/apiv2/dlppb"
)

// inspectPhoneNumber demonstrates a simple scan request to the Cloud DLP API.
// Notice that the PHONE_NUMBER detector is specified in inspectConfig,
// which instructs Cloud DLP to scan the given string for a phone number.
func inspectPhoneNumber(w io.Writer, projectID, textToInspect string) error {
	// projectID := "my-project-id"
	// textToInspect := "My phone number is (123) 555-6789"

	ctx := context.Background()

	// Initialize a client once and reuse it to send multiple requests. Clients
	// are safe to use across goroutines. When the client is no longer needed,
	// call the Close method to cleanup its resources.
	client, err := dlp.NewClient(ctx)
	if err != nil {
		return err
	}
	// Closing the client safely cleans up background resources.
	defer client.Close()

	// Create and send the request.
	req := &dlppb.InspectContentRequest{
		Parent: fmt.Sprintf("projects/%s/locations/global", projectID),
		Item: &dlppb.ContentItem{
			DataItem: &dlppb.ContentItem_Value{
				Value: textToInspect,
			},
		},
		InspectConfig: &dlppb.InspectConfig{
			// Specify the type of info the inspection will look for.
			// See https://cloud.google.com/dlp/docs/infotypes-reference
			// for complete list of info types
			InfoTypes: []*dlppb.InfoType{
				{Name: "PHONE_NUMBER"},
			},
			IncludeQuote: true,
		},
	}

	// Send the request.
	resp, err := client.InspectContent(ctx, req)
	if err != nil {
		fmt.Fprintf(w, "receive: %v", err)
		return err
	}

	// Process the results.
	result := resp.Result
	fmt.Fprintf(w, "Findings: %d\n", len(result.Findings))
	for _, f := range result.Findings {
		fmt.Fprintf(w, "\tQuote: %s\n", f.Quote)
		fmt.Fprintf(w, "\tInfo type: %s\n", f.InfoType.Name)
		fmt.Fprintf(w, "\tLikelihood: %s\n", f.Likelihood)
	}
	return nil
}

import com.google.cloud.dlp.v2.DlpServiceClient;
import com.google.privacy.dlp.v2.ContentItem;
import com.google.privacy.dlp.v2.Finding;
import com.google.privacy.dlp.v2.InfoType;
import com.google.privacy.dlp.v2.InspectConfig;
import com.google.privacy.dlp.v2.InspectContentRequest;
import com.google.privacy.dlp.v2.InspectContentResponse;
import com.google.privacy.dlp.v2.Likelihood;
import com.google.privacy.dlp.v2.LocationName;
import java.io.IOException;

public class InspectPhoneNumber {

  public static void main(String[] args) throws Exception {
    // TODO(developer): Replace these variables before running the sample.
    String projectId = "your-project-id";
    String textToInspect = "My name is Gary and my email is gary@example.com";
    inspectString(projectId, textToInspect);
  }

  // Inspects the provided text.
  public static void inspectString(String projectId, String textToInspect) throws IOException {
    // Initialize client that will be used to send requests. This client only needs to be created
    // once, and can be reused for multiple requests. After completing all of your requests, call
    // the "close" method on the client to safely clean up any remaining background resources.
    try (DlpServiceClient dlp = DlpServiceClient.create()) {
      // Specify the type and content to be inspected.
      ContentItem item = ContentItem.newBuilder().setValue(textToInspect).build();

      // Specify the type of info the inspection will look for.
      // See https://cloud.google.com/dlp/docs/infotypes-reference for complete list of info types
      InfoType infoType = InfoType.newBuilder().setName("PHONE_NUMBER").build();

      // Construct the configuration for the Inspect request.
      InspectConfig config =
          InspectConfig.newBuilder()
              .setIncludeQuote(true)
              .setMinLikelihood(Likelihood.POSSIBLE)
              .addInfoTypes(infoType)
              .build();

      // Construct the Inspect request to be sent by the client.
      InspectContentRequest request =
          InspectContentRequest.newBuilder()
              .setParent(LocationName.of(projectId, "global").toString())
              .setItem(item)
              .setInspectConfig(config)
              .build();

      // Use the client to send the API request.
      InspectContentResponse response = dlp.inspectContent(request);

      // Parse the response and process results
      System.out.println("Findings: " + response.getResult().getFindingsCount());
      for (Finding f : response.getResult().getFindingsList()) {
        System.out.println("\tQuote: " + f.getQuote());
        System.out.println("\tInfo type: " + f.getInfoType().getName());
        System.out.println("\tLikelihood: " + f.getLikelihood());
      }
    }
  }
}

// Imports the Google Cloud Data Loss Prevention library
const DLP = require('@google-cloud/dlp');

// Instantiates a client
const dlp = new DLP.DlpServiceClient();

// The project ID to run the API call under
// const projectId = 'my-project';

// The string to inspect
// const string = 'My email is gary@example.com and my phone number is (223) 456-7890.';

// The minimum likelihood required before returning a match
// const minLikelihood = 'LIKELIHOOD_UNSPECIFIED';

// The maximum number of findings to report per request (0 = server maximum)
// const maxFindings = 0;

// The infoTypes of information to match
// See https://cloud.google.com/dlp/docs/concepts-infotypes for more information
// about supported infoTypes.
// const infoTypes = [{ name: 'PHONE_NUMBER' }];

// The customInfoTypes of information to match
// const customInfoTypes = [{ infoType: { name: 'DICT_TYPE' }, dictionary: { wordList: { words: ['foo', 'bar', 'baz']}}},
//   { infoType: { name: 'REGEX_TYPE' }, regex: {pattern: '\\(\\d{3}\\) \\d{3}-\\d{4}'}}];

// Whether to include the matching string
// const includeQuote = true;

async function inspectPhoneNumber() {
  // Construct item to inspect
  const item = {value: string};

  // Construct request
  const request = {
    parent: `projects/${projectId}/locations/global`,
    inspectConfig: {
      infoTypes: infoTypes,
      customInfoTypes: customInfoTypes,
      minLikelihood: minLikelihood,
      includeQuote: includeQuote,
      limits: {
        maxFindingsPerRequest: maxFindings,
      },
    },
    item: item,
  };

  // Run request
  const [response] = await dlp.inspectContent(request);
  const findings = response.result.findings;
  if (findings.length > 0) {
    console.log('Findings:');
    findings.forEach(finding => {
      if (includeQuote) {
        console.log(`\tQuote: ${finding.quote}`);
      }
      console.log(`\tInfo type: ${finding.infoType.name}`);
      console.log(`\tLikelihood: ${finding.likelihood}`);
    });
  } else {
    console.log('No findings.');
  }
}
inspectPhoneNumber();

use Google\Cloud\Dlp\V2\Client\DlpServiceClient;
use Google\Cloud\Dlp\V2\ContentItem;
use Google\Cloud\Dlp\V2\InfoType;
use Google\Cloud\Dlp\V2\InspectConfig;
use Google\Cloud\Dlp\V2\InspectContentRequest;
use Google\Cloud\Dlp\V2\Likelihood;

/**
 * Inspect data for phone numbers
 * Demonstrates a simple scan request to the Cloud DLP API. Notice that the PHONE_NUMBER detector is specified in inspectConfig, which instructs Cloud DLP to scan the given string for a phone number.
 *
 * @param string $projectId         The Google Cloud project id to use as a parent resource.
 * @param string $textToInspect     The string to inspect.
 */
function inspect_phone_number(
    // TODO(developer): Replace sample parameters before running the code.
    string $projectId,
    string $textToInspect = 'My name is Gary and my phone number is (415) 555-0890'
): void {
    // Instantiate a client.
    $dlp = new DlpServiceClient();

    $parent = "projects/$projectId/locations/global";

    // Specify what content you want the service to Inspect.
    $item = (new ContentItem())
        ->setValue($textToInspect);

    $inspectConfig = (new InspectConfig())
        // The infoTypes of information to match
        ->setInfoTypes([
            (new InfoType())->setName('PHONE_NUMBER'),
        ])
        // Whether to include the matching string
        ->setIncludeQuote(true)
        ->setMinLikelihood(Likelihood::POSSIBLE);

    // Run request
    $inspectContentRequest = (new InspectContentRequest())
        ->setParent($parent)
        ->setInspectConfig($inspectConfig)
        ->setItem($item);
    $response = $dlp->inspectContent($inspectContentRequest);

    // Print the results
    $findings = $response->getResult()->getFindings();
    if (count($findings) == 0) {
        printf('No findings.' . PHP_EOL);
    } else {
        printf('Findings:' . PHP_EOL);
        foreach ($findings as $finding) {
            printf('  Quote: %s' . PHP_EOL, $finding->getQuote());
            printf('  Info type: %s' . PHP_EOL, $finding->getInfoType()->getName());
            printf('  Likelihood: %s' . PHP_EOL, Likelihood::name($finding->getLikelihood()));
        }
    }
}

import google.cloud.dlp


def inspect_phone_number(
    project: str,
    content_string: str,
) -> None:
    """Uses the Data Loss Prevention API to analyze strings for protected data.
    Args:
        project: The Google Cloud project id to use as a parent resource.
        content_string: The string to inspect phone number from.
    """

    # Instantiate a client.
    dlp = google.cloud.dlp_v2.DlpServiceClient()

    # Prepare info_types by converting the list of strings into a list of
    # dictionaries (protos are also accepted).
    info_types = [{"name": "PHONE_NUMBER"}]

    # Construct the configuration dictionary.
    inspect_config = {
        "info_types": info_types,
        "include_quote": True,
    }

    # Construct the `item`.
    item = {"value": content_string}

    # Convert the project id into a full resource id.
    parent = f"projects/{project}"

    # Call the API.
    response = dlp.inspect_content(
        request={"parent": parent, "inspect_config": inspect_config, "item": item}
    )

    # Print out the results.
    if response.result.findings:
        for finding in response.result.findings:
            print(f"Quote: {finding.quote}")
            print(f"Info type: {finding.info_type.name}")
            print(f"Likelihood: {finding.likelihood}")
    else:
        print("No findings.")

POST https://dlp.googleapis.com/v2/projects/[PROJECT-ID]/content:inspect?key={YOUR_API_KEY}

{
  "item":{
    "value":"My phone number is (415) 555-0890"
  },
  "inspectConfig":{
    "includeQuote":true,
    "minLikelihood":"POSSIBLE",
    "infoTypes":{
      "name":"PHONE_NUMBER"
    }
  }
}

{
  "result":{
    "findings":[
      {
        "quote":"(415) 555-0890",
        "infoType":{
          "name":"PHONE_NUMBER"
        },
        "likelihood":"VERY_LIKELY",
        "location":{
          "byteRange":{
            "start":"19",
            "end":"33"
          },
          "codepointRange":{
            "start":"19",
            "end":"33"
          }
        },
        "createTime":"2018-10-29T23:46:34.535Z"
      }
    ]
  }
}

Vous devez spécifier des infoTypes listés dans la documentation de référence dans votre configuration d'inspection. Si vous ne spécifiez aucun infoType, la protection des données sensibles utilise une liste d'infoTypes par défaut destinée uniquement aux tests. La liste par défaut peut ne pas être adaptée à vos cas d'utilisation.

Si vous souhaitez en savoir plus sur l'utilisation des détecteurs d'infoTypes pour analyser votre contenu, consultez l'un des guides pratiques relatifs à l'inspection, à l'effacement ou à l'anonymisation.

Certitude et tests

Les résultats sont renvoyés avec un score de certitude appelé probabilité. Le score de certitude indique la probabilité qu'un résultat corresponde à l'infoType identifié. Par exemple, un infoType peut présenter un score de certitude moins élevé si la seule technique utilisée est une correspondance de modèle. En revanche, il peut présenter une probabilité plus élevée s'il y a correspondance de modèle et contexte positif. Pour cette raison, vous remarquerez peut-être qu'un seul résultat peut correspondre à plusieurs infoTypes, mais avec une probabilité moins élevée. En outre, il se peut qu'un résultat n'apparaisse pas ou qu'il présente un degré de certitude moins élevé s'il ne s'agit pas d'une correspondance parfaite ou s'il présente un contexte négatif. Par exemple, il se peut qu'un résultat ne soit pas affiché s'il correspond à la structure de l'infoType spécifié mais pas à la somme de contrôle de l'infoType. Ou bien, il se peut qu'un résultat corresponde à plusieurs infoTypes, mais qu'il présente un contexte plus favorable à l'un d'entre eux. Dans ce cas, il ne sera affiché que pour cet infoType.

Si vous testez plusieurs détecteurs, vous remarquerez peut-être que les données fictives ou les données d'échantillonnage ne sont pas présentées, car elles ne sont pas suffisamment vérifiées.

Types de détecteurs d'infoTypes

La protection des données sensibles comprend plusieurs types de détecteurs d'infoTypes résumés ci-dessous:

• Les détecteurs d'infoTypes intégrés sont intégrés à la protection des données sensibles. Ils comprennent des détecteurs pour les types de données sensibles spécifiques à un pays ou une région, ainsi que pour les types de données applicables au niveau mondial.
• Les détecteurs d'infoTypes personnalisés sont des détecteurs que vous créez vous-même. Il existe trois types de détecteurs d'infoTypes personnalisés :
  • Les détecteurs de dictionnaires personnalisés de petite taille sont de simples listes de mots dont la protection des données sensibles se sert pour rechercher des correspondances. Utilisez ces détecteurs de dictionnaires personnalisés lorsque vous avez une liste qui contient au maximum plusieurs dizaines de milliers de mots ou d'expressions. Les détecteurs de dictionnaires personnalisés de petite taille sont recommandés si vous pensez que votre liste de mots ne changera pas de manière significative.
  • Les détecteurs de dictionnaires personnalisés de grande taille sont générés par la protection des données sensibles à l'aide de listes volumineuses de mots ou d'expressions stockées dans Cloud Storage ou BigQuery. Utilisez ces détecteurs de dictionnaire personnalisés de grande taille lorsque vous disposez d'une longue liste de mots ou d'expressions (jusqu'à plusieurs dizaines de millions).
  • Les détecteurs d'expressions régulières (regex) permettent à la protection des données sensibles de détecter les correspondances basées sur un motif d'expression régulière.

En outre, Sensitive Data Protection intègre le concept de règles d'inspection grâce auxquelles vous pouvez affiner les résultats de l'analyse à l'aide des éléments suivants:

• Les règles d'exclusion vous permettent de réduire le nombre de résultats renvoyés en ajoutant des règles à un détecteur d'infoType intégré ou personnalisé.
• Les règles relatives aux mots clés vous permettent d'augmenter la quantité ou de modifier la valeur de probabilité des résultats renvoyés en ajoutant des règles à un détecteur d'infoType intégré ou personnalisé.

Détecteurs d'infoTypes intégrés

Les détecteurs infoType intégrés font partie intégrante de la protection des données sensibles. Ils comprennent des détecteurs pour les types de données sensibles spécifiques à un pays ou une région, par exemple le Numéro d'Inscription au Répertoire ou NIR pour la France (FRANCE_NIR), le numéro de permis de conduire pour le Royaume-Uni (UK_DRIVERS_LICENSE_NUMBER) et le numéro de sécurité sociale pour les États-Unis (US_SOCIAL_SECURITY_NUMBER). Ils incluent également les types de données applicables au niveau mondial tels que les noms de personnes (PERSON_NAME), les numéros de téléphone (PHONE_NUMBER), les adresses e-mail (EMAIL_ADDRESS) et les numéros de carte de crédit (CREDIT_CARD_NUMBER). Pour détecter le contenu qui correspond aux infoTypes, la protection des données sensibles exploite diverses techniques, y compris la mise en correspondance de modèles, les sommes de contrôle, l'apprentissage automatique, l'analyse du contexte, etc.

La liste des détecteurs d'infoTypes intégrés est constamment mise à jour. Pour obtenir la liste complète des détecteurs d'infoTypes intégrés actuellement acceptés, consultez la documentation de référence sur les détecteurs d'infoTypes.

Vous pouvez également afficher cette liste en appelant la méthode infoTypes.list de la protection des données sensibles.

Langues acceptées

Les infoTypes spécifiques à un pays sont compatibles avec l'anglais ainsi qu'avec les langues respectives du pays. La plupart des infoTypes globaux fonctionnent avec plusieurs langues. Testez la protection des données sensibles avec vos données pour vérifier qu'elles répondent bien à vos exigences.

Détecteurs d'infoTypes personnalisés

Il existe trois types de détecteurs d'infoTypes personnalisés :

• Détecteurs de dictionnaires personnalisés
• Détecteurs de dictionnaires personnalisés de grande taille
• Expressions régulières (regex)

En outre, Sensitive Data Protection inclut des règles d'inspection qui vous permettent d'affiner les résultats de l'analyse en ajoutant à des détecteurs les éléments suivants:

• Règles d'exclusion
• Règles relatives aux mots clés

Détecteurs de dictionnaires personnalisés

Utilisez des détecteurs de dictionnaire personnalisés de petite taille (également appelés "détecteurs de dictionnaire personnalisés standards") pour faire correspondre une courte liste (plusieurs dizaines de milliers) de mots ou d'expressions. Un dictionnaire personnalisé standard peut agir comme son propre détecteur unique.

Les détecteurs de dictionnaire personnalisés sont utiles lorsque vous souhaitez baser l'analyse sur une liste de mots ou d'expressions pour lesquels une expression régulière ou un détecteur intégré ne trouvera pas facilement de correspondance. Par exemple, supposons que vous souhaitiez rechercher des salles de conférence à partir du nom qui leur est attribué (basé, par exemple, sur des noms d'États ou de régions, de monuments, de personnages de fiction, etc.) plutôt qu'à partir de leur numéro de salle. Vous pouvez créer un détecteur de dictionnaire personnalisé de petite taille contenant une liste de ces noms de salle. Sensitive Data Protection peut analyser votre contenu pour rechercher chacun des noms de salle et renvoyer une correspondance lorsqu'elle rencontre l'un d'entre eux dans le bon contexte. Pour en savoir plus sur la manière dont la protection des données sensibles identifie des correspondances avec les mots et expressions du dictionnaire, consultez la section Caractéristiques des correspondances avec le dictionnaire de la page Créer un détecteur de dictionnaire personnalisé standard.

Pour en savoir plus sur le fonctionnement des détecteurs de dictionnaires personnalisés de petite taille et pour obtenir des exemples concrets, consultez la page Créer un détecteur de dictionnaire personnalisé standard.

Détecteurs de dictionnaires personnalisés de grande taille

Utilisez des détecteurs de dictionnaire personnalisés de grande taille (également appelés "détecteurs de dictionnaire personnalisés stockés") lorsque vous avez plusieurs mots ou expressions à analyser, ou si votre liste de mots ou d'expressions change fréquemment. Les détecteurs de dictionnaire personnalisés stockés permettent d'identifier des correspondances avec des listes allant jusqu'à plusieurs dizaines de millions de mots ou d'expressions.

Les détecteurs de dictionnaires personnalisés stockés sont créés différemment des détecteurs personnalisés à base d'expressions régulières et des détecteurs de dictionnaires personnalisés standards. Chaque dictionnaire personnalisé stocké possède deux composants :

• Une liste d'expressions que vous créez et définissez. Cette liste est stockée sous forme de fichier texte dans Cloud Storage ou de colonne dans une table BigQuery.
• Les fichiers de dictionnaire générés, qui sont compilés par la protection des données sensibles à partir de votre liste d'expressions. Ces fichiers sont stockés dans Cloud Storage et comprennent une copie des données sources (les expressions) ainsi que des filtres de Bloom qui facilitent la recherche et la correspondance. Vous ne pouvez pas modifier ces fichiers directement.

Une fois que vous avez créé une liste de mots, puis utilisé la protection des données sensibles pour générer un dictionnaire personnalisé, vous lancez ou planifiez une analyse avec un détecteur de dictionnaire personnalisé stocké de la même manière qu'avec les autres détecteurs d'infoTypes.

Pour en savoir plus sur le fonctionnement des détecteurs de dictionnaires personnalisés stockés et pour obtenir des exemples concrets, consultez la page Créer un détecteur de dictionnaire personnalisé stocké.

Expressions régulières

Un détecteur d'infoType personnalisé à base d'expression régulière (regex) vous permet de créer vos propres détecteurs d'infoTypes grâce auxquels la protection des données sensibles détecte les correspondances basées sur un modèle d'expression régulière. Supposons par exemple que vous ayez des numéros de dossiers médicaux au format ###-#-#####. Vous pouvez définir un modèle d'expression régulière comme le suivant :

[1-9]{3}-[1-9]{1}-[1-9]{5}

La protection des données sensibles trouve alors les éléments comme ceux-ci:

123-4-56789

Vous pouvez également spécifier une probabilité attribuée à chaque correspondance d'infoType personnalisé. Autrement dit, lorsque la protection des données sensibles trouve la séquence spécifiée, elle attribue la probabilité que vous avez indiquée. Cette technique est utile si votre expression régulière personnalisée définit une séquence relativement courante, car celle-ci peut facilement être mise en correspondance avec une autre séquence aléatoire. Or, il ne faut pas que la protection des données sensibles attribue l'étiquette VERY_LIKELY à chaque correspondance. Cela pourrait en effet affecter la fiabilité des résultats d'analyse et entraîner des mises en correspondance erronées ou l'anonymisation par erreur de certaines informations.

Pour en savoir plus sur les détecteurs d'infoTypes personnalisés à base d'expressions régulières et pour obtenir des exemples concrets, consultez la page Créer un détecteur d'expression régulière personnalisé.

Règles d'inspection

Vous pouvez utiliser des règles d'inspection dans le but d'affiner les résultats renvoyés par les détecteurs d'infoTypes existants, qu'ils soient intégrés ou personnalisés. Les règles d'inspection peuvent être utiles lorsque les résultats renvoyés par la protection des données sensibles doivent être augmentés d'une manière ou d'une autre, soit en les ajoutant au détecteur d'infoType existant, soit en les supprimant.

Les deux types de règles d'inspection sont les suivants :

• Règles d'exclusion
• Règles relatives aux mots clés

Pour en savoir plus sur les règles d'inspection, consultez la page Modifier les détecteurs d'InfoTypes pour affiner les résultats d'analyse.

Règles d'exclusion

Les règles d'exclusion vous permettent de réduire la quantité ou la précision des résultats renvoyés en ajoutant des règles à un détecteur d'infoType intégré ou personnalisé. Les règles d'exclusion peuvent vous aider à éviter que le bruit et d'autres résultats indésirables ne soient renvoyés par un détecteur d'infoType.

Par exemple, si vous analysez des adresses e-mail dans une base de données, vous pouvez ajouter une règle d'exclusion sous la forme d'une expression régulière personnalisée indiquant à la protection des données sensibles d'exclure tout résultat se terminant par "@example.com".

Pour en savoir plus sur les règles d'exclusion, consultez la page Modifier les détecteurs d'infoTypes pour affiner les résultats d'analyse.

Règles relatives aux mots clés

Les règles relatives aux mots clés vous permettent d'augmenter la quantité ou d'améliorer la justesse des résultats renvoyés en ajoutant des règles à un détecteur d'infoType intégré ou personnalisé. Les règles relatives aux mots-clés peuvent ainsi vous aider à assouplir les règles d'un détecteur d'infoType existant.

Par exemple, supposons que vous souhaitez analyser une base de données médicale afin d'identifier les noms des patients. Pour cela, vous pouvez utiliser le détecteur d'infoType PERSON_NAME intégré à la protection des données sensibles, mais vous obtiendrez des correspondances avec tous les noms de personnes, et non uniquement les noms de patients. Pour résoudre ce problème, vous pouvez inclure une règle relative aux mots clés sous la forme d'un infoType personnalisé d'expression régulière, qui recherche le mot "patient" dans un voisinage du premier caractère des correspondances potentielles. Vous pouvez ensuite attribuer aux résultats correspondant à ce modèle une valeur de probabilité "very_likely" (très probable), car ils répondent à vos critères spéciaux.

Pour en savoir plus sur les règles relatives aux mots clés, consultez la page Modifier les détecteurs d'infoTypes pour affiner les résultats d'analyse.

Exemples

Pour mieux comprendre les correspondances entre les infoTypes et les résultats, consultez les exemples ci-dessous réalisés sur une série de chiffres afin de déterminer s'ils constituent un numéro de sécurité sociale américain ou un numéro d'identification fiscale américain. N'oubliez pas que ces exemples utilisent les détecteurs d'infoTypes intégrés. Lorsque vous créez un détecteur d'infoType personnalisé, vous spécifiez les critères qui déterminent la probabilité d'une correspondance d'analyse.

Exemple 1

"SSN 222-22-2222"

Présente un score de probabilité élevé VERY_LIKELY (très probable) pour l'infoType US_SOCIAL_SECURITY_NUMBER, car :

• il s'agit du format de numéro de sécurité sociale standard, ce qui augmente la certitude ;
• il présente un contexte de proximité ("SSN", ou numéro de sécurité sociale) qui augmente la probabilité d'un infoType US_SOCIAL_SECURITY_NUMBER.

Exemple 2

"999-99-9999"

Présente un score de probabilité faible VERY_UNLIKELY (très peu probable) pour l'infoType US_SOCIAL_SECURITY_NUMBER, car :

• il est au format standard, ce qui augmente la certitude ;
• il commence par le chiffre 9 qui n'est pas autorisé dans les numéros de sécurité sociale, ce qui diminue la certitude ;
• il est dépourvu de contexte, ce qui diminue la certitude.

Exemple 3

"999-98-9999"

Présente un score de probabilité POSSIBLE (probable) pour l'infoType US_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER et VERY_UNLIKELY (très peu probable) pour l'infoType US_SOCIAL_SECURITY_NUMBER, car :

• il est au format standard pour les deux infoTypes US_SOCIAL_SECURITY_NUMBER et US_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER ;
• il commence par un 9 et comporte un autre chiffre, ce qui augmente la certitude pour l'infoType US_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER ;
• il est dépourvu de contexte, ce qui diminue la certitude pour les deux infoTypes.

Étape suivante

L'équipe de la protection des données sensibles lance régulièrement de nouveaux détecteurs et groupes d'infoTypes. Pour savoir comment obtenir la liste mise à jour des infoTypes intégrés, consultez la section Répertorier les détecteurs d'infoTypes intégrés.