infoTypes und infoType-Detektoren

Der Schutz sensibler Daten verwendet Informationstypen bzw. infoTypes, um zu definieren, wonach gescannt wird. Ein infoType ist ein Typ sensibler Daten wie Name, E-Mail-Adresse, Telefonnummer, Sozialversicherungsnummer, Kreditkartennummer usw. Ein infoType-Detektor ist der entsprechende Erkennungsmechanismus, der mit den Abgleichskriterien eines infoType übereinstimmt.

Best Practices für die Auswahl von infoTypes

Ihre Daten zu verstehen ist einer der ersten wichtigen Schritte, um sie zu schützen. Als Best Practice sollten Sie nur die Informationen erheben, speichern und verarbeiten, die Sie für Ihr Unternehmen benötigen. Wenn Sie die Daten identifizieren, die Sie verarbeiten, können Sie fundierte Entscheidungen für Ihr Unternehmen, Ihre Nutzer und Ihre Daten treffen und Ihre Sicherheits- und Datenschutzstrategie verbessern.

Für einige Ihrer geschäftlichen Anwendungsfälle sind möglicherweise bestimmte vertrauliche Informationen erforderlich, für andere nicht. Es gibt keine einzelne Lösung, die alle Anwendungsfälle unterstützt. Aus diesem Grund bietet Sensitive Data Protection eine flexible Steuerung der Datentypen, nach denen gesucht werden soll. Wenn Sie infoTypes für die De-Identifikation oder Maskierung verwenden, können Sie auch steuern, wann und wie Daten transformiert werden.

Allgemeine Richtlinien

Beachten Sie bei der Auswahl von infoTypes die folgenden allgemeinen Richtlinien.

Allgemeine infoTypes anstelle von spezifischen infoTypes verwenden

Wenn in Ihren Scanergebnissen nicht die spezifischen erkannten infoTypes angezeigt werden müssen, sollten Sie in Ihren Prüfkonfigurationen allgemeine statt spezifischer infoTypes verwenden. Informationen zu den Vorteilen der Verwendung allgemeiner InfoType-Detektoren in Ihren Anfragen finden Sie auf dieser Seite unter Allgemeine und spezifische InfoType-Detektoren.

Eine vollständige Liste der allgemeinen infoTypes und der spezifischen infoTypes, die sie enthalten, finden Sie unter Allgemeine infoTypes.

Vertrauliche Informationen, die Sie nicht erheben müssen

Für jeden Dienst in Ihrem Unternehmen sollten nur die Daten erhoben werden, die für den Dienst erforderlich sind. Beispielsweise müssen für bestimmte Dienste in Ihrem Unternehmen keine Finanzinformationen erhoben werden. Für diese Dienste sollten Sie infoType-Detektoren wie CREDIT_CARD_NUMBER, FINANCIAL_ACCOUNT_NUMBER und andere infoTypes in der Branchenkategorie FINANCE aktivieren.

Informationen, die Sie erfassen müssen, aber nicht mit Ihrem gesamten Team teilen möchten

Es kann zwar zulässige Anwendungsfälle für die Erhebung personenbezogener Daten geben, Sie sollten diese jedoch nicht allgemein mit Ihrem Team teilen. Ein Kunde, der ein Support-Ticket einreicht, gibt Ihnen beispielsweise Kontaktdaten, damit Sie ihn kontaktieren können, um Probleme zu beheben. Sie möchten nicht, dass alle Teammitglieder, die das Ticket aufrufen, die personenidentifizierbaren Informationen sehen. Aktivieren Sie infoType-Detektoren wie PHONE_NUMBER, EMAIL_ADDRESS und andere infoTypes in der Typkategorie PII.

Kategorien sensibler Daten, die Branchen-, Datenschutz- oder Gerichtsbarkeitsbestimmungen unterliegen

Bestimmte Arten von Informationen gelten als sensibel, weil sie auf bestimmte Weise ausgestellt werden oder für bestimmte Zwecke verwendet werden können. In anderen Fällen gelten kontextbezogene und demografische Informationen als geschützte Kategorie. Für diese Arten von Informationen gelten möglicherweise zusätzliche Einschränkungen hinsichtlich der Erhebung, Verwendung und Verwaltung. Aktivieren Sie infoType-Detektoren in den folgenden Kategorien:

• Typkategorie SPII, GOVERNMENT_ID und DEMOGRAPHIC
• Branchenkategorie HEALTH

Zwischen ähnlichen infoTypes auswählen

Berücksichtigen Sie Folgendes, wenn Sie zwischen ähnlichen infoType-Detektoren wählen.

Reisepässe

Wenn Sie keine Ausweis-IDs aus einem bestimmten Land scannen müssen, wählen Sie den allgemeinen Detektor aus: PASSPORT.

Bestimmte länderspezifische Reisepass-Erkennungstools wie UK_PASSPORT sind verfügbar. Einige länderspezifische Pass-Erkennungstools können jedoch nur Pässe mit bestimmten Formaten oder mit Kontextinformationen erkennen.

Namen von Personen

Verwenden Sie beim Scannen nach Namen von Personen in den meisten Fällen PERSON_NAME anstelle von FIRST_NAME oder LAST_NAME.

PERSON_NAME ist ein Detektor für Namen von Personen. Sie umfasst Namen, die aus einem Wort bestehen, und vollständige Namen. Dieser Detektor versucht, beispielsweise Namen wie Erika, Erika Müller und Erika Marie Müller mithilfe verschiedener Technologien zu erkennen, darunter Natural Language Understanding. FIRST_NAME und LAST_NAME sind Teilmengen dieses Detektors, mit denen versucht wird, Teile eines Namens zu identifizieren. Die Ergebnisse dieser Detektoren sind immer Teilmengen der Ergebnisse von PERSON_NAME.

Datums- und Uhrzeitwerte

Wenn Sie nicht alle Datumsangaben scannen müssen, sollten Sie einen gezielten Datumsdetektor wie DATE_OF_BIRTH verwenden. Dieser Detektor versucht, Kontext zu identifizieren, der darauf hinweist, dass sich das Datum auf die Geburt einer Person bezieht.

Der DATE-Detektor versucht, alle Datumsangaben unabhängig vom Kontext zu finden. Außerdem werden relative Datumsangaben wie heute oder gestern gekennzeichnet. Ebenso versucht TIME, alle Zeitstempel zu finden.

Standorte

Wenn Sie nicht alle Standorte scannen müssen, sollten Sie STREET_ADDRESS anstelle des LOCATION-Detektors verwenden. Der STREET_ADDRESS-Detektor versucht, vollqualifizierte Adressen zu finden, die in der Regel genauer als allgemeine Standorte sind und als sensibler gelten können.

Der LOCATION-infoType-Detektor versucht, jeden Ort unabhängig vom Kontext zu finden, z. B. Paris oder Kanada.

infoType-Detektoren, die Kontext erfordern

Viele infoType-Detektoren benötigen Kontextinformationen, bevor sie eine Übereinstimmung erkennen. Wenn ein integrierter infoType-Detektor Elemente, die Ihrer Meinung nach gekennzeichnet werden sollten, nicht kennzeichnet, weil in unmittelbarer Nähe dieser Elemente keine Kontextinformationen vorhanden sind, sollten Sie stattdessen GENERIC_ID oder einen benutzerdefinierten infoType-Detektor verwenden.

Informationstypen ohne gemeinsame Branchendefinition

Für einige Informationstypen gibt es keine gemeinsame Branchendefinition. Beispiele sind Krankenaktennummern, Kontonummern, PINs und Sicherheitscodes. Für diese Typen sollten Sie InfoTypes wie GENERIC_ID, FINANCIAL_ACCOUNT_NUMBER und MEDICAL_RECORD_NUMBER verwenden. Diese Detektoren verwenden eine Kombination aus Erkennung von Entitäten und Kontext, um potenziell vertrauliche Elemente zu finden.

infoType-Detektoren mit höherer Latenz

• Aktivieren Sie keine infoType-Detektoren, die Sie nicht benötigen. Die folgenden infoTypes können in bestimmten Szenarien nützlich sein, führen aber dazu, dass Anfragen viel langsamer ausgeführt werden als Anfragen ohne diese infoTypes:

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

• Geben Sie infoType-Detektoren immer explizit an. Verwenden Sie keine leere infoTypes-Liste.

So verwenden Sie infoTypes

Sensitive Data Protection verwendet in der Konfiguration für seine Scans infoType-Detektoren, um zu bestimmen, wonach gesucht werden soll und wie die Ergebnisse transformiert werden. Die infoType-Namen werden auch für die Anzeige von Scanergebnissen oder in entsprechenden Berichten verwendet.

Wenn Sie beispielsweise nach E-Mail-Adressen in einem Textblock suchen möchten, geben Sie den infoType-Detektor EMAIL_ADDRESS in der Inspektionskonfiguration an. Wenn Sie E-Mail-Adressen aus dem Textblock entfernen möchten, geben Sie sowohl in der Inspektionskonfiguration als auch in der De-Identifikationskonfiguration EMAIL_ADDRESS an, um anzugeben, wie dieser Typ entfernt oder angepasst werden soll.

Darüber hinaus können Sie eine Kombination aus integrierten und benutzerdefinierten infoType-Detektoren verwenden, um einen Teil der E-Mail-Adressen aus den Scanergebnissen auszuschließen. Erstellen Sie zuerst einen benutzerdefinierten infoType namens INTERNAL_EMAIL_ADDRESS und konfigurieren Sie ihn so, dass interne Test-E-Mail-Adressen ausgeschlossen werden. Anschließend können Sie Ihren Scan so einrichten, dass Ergebnisse für EMAIL_ADDRESS eingeschlossen werden. Sie können aber eine Ausschlussregel hinzufügen, die alle Ergebnisse ausschließt, die mit INTERNAL_EMAIL_ADDRESS übereinstimmen. Weitere Informationen zu Ausschlussregeln und andere Features von benutzerdefinierten infoType-Detektoren finden Sie unter Benutzerdefinierte infoType-Detektoren erstellen.

Sensitive Data Protection bietet eine Reihe von integrierten infoType-Detektoren, die Sie namentlich angeben und die alle in der InfoType-Detektorreferenz aufgeführt sind. Diese Detektoren nutzen eine Vielzahl von Techniken, um jeden Typ zu erkennen und zu klassifizieren. Einige Typen erfordern beispielsweise einen Musterabgleich, einige haben mathematische Prüfsummen, einige haben spezielle Ziffernbeschränkungen und andere können bestimmte Präfixe oder Kontexte um die Ergebnisse enthalten.

Beispiele

Wenn Sie Sensitive Data Protection zum Scannen Ihrer Inhalte einrichten, geben Sie die zu verwendenden infoType-Detektoren in der Scankonfiguration an.

Die folgenden JSON- und Codebeispiele veranschaulichen beispielsweise eine einfache Scananfrage an die DLP API. Beachten Sie, dass der Detektor PHONE_NUMBER in inspectConfig angegeben ist. Damit wird Sensitive Data Protection angewiesen, in dem angegebenen String nach einer Telefonnummer zu suchen.

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"
      }
    ]
  }
}

Sie müssen in Ihrer Prüfkonfiguration bestimmte infoTypes angeben, die in der Referenz aufgeführt sind. Wenn Sie keine infoTypes angeben, verwendet Sensitive Data Protection eine Standardliste von infoTypes, die nur für Testzwecke vorgesehen ist. Die Standardliste ist möglicherweise nicht für Ihre Anwendungsfälle geeignet.

Weitere Informationen zur Verwendung von infoType-Detektoren zum Scannen von Inhalten finden Sie in den Anleitungen zu den Themen Prüfung, Entfernung und De-Identifikation.

Sicherheit und Tests

Die Ergebnisse werden mit dem Sicherheitsfaktor Wahrscheinlichkeit gemeldet. Der Wahrscheinlichkeitswert gibt an, mit welcher Wahrscheinlichkeit ein Ergebnis mit dem entsprechenden Typ übereinstimmt. Ein Typ kann beispielsweise eine geringere Wahrscheinlichkeit zurückgeben, wenn er nur mit dem Muster übereinstimmt, und eine höhere Wahrscheinlichkeit, wenn er mit dem Muster übereinstimmt und von einem positiven Kontext umgeben ist. Deshalb stellen Sie möglicherweise fest, dass ein einzelnes Ergebnis mit geringerer Wahrscheinlichkeit zu mehreren Typen passt. Außerdem wird ein Ergebnis möglicherweise nicht angezeigt oder hat eine geringere Wahrscheinlichkeit, wenn es nicht richtig übereinstimmt oder von einem negativen Kontext umgeben ist. Beispielsweise wird ein Ergebnis möglicherweise nicht gemeldet, wenn es mit der Struktur für den angegebenen infoType übereinstimmt, aber bei der Prüfsumme des infoType fehlschlägt. Oder ein Ergebnis könnte mit mehr als einem infoType übereinstimmen, aber einen Kontext haben, der einen davon verbessert, und somit nur für diesen Typ gemeldet wird.

Wenn Sie verschiedene Detektoren testen, stellen Sie möglicherweise fest, dass falsche Daten oder Beispieldaten nicht gemeldet werden, da sie nicht genügend Prüfungen bestehen.

Arten von infoType-Detektoren

Der Schutz sensibler Daten umfasst mehrere Arten von infoType-Detektoren, die hier zusammengefasst sind:

• Integrierte infoType-Detektoren sind in Sensitive Data Protection eingebunden. Dazu gehören Detektoren für länder- oder regionsspezifische sensible Datentypen sowie global anwendbare Datentypen. Allgemeine infoTypes sind ebenfalls verfügbar, um die Konfigurationen zu vereinfachen.
• Benutzerdefinierte infoType-Detektoren sind Detektoren, die Sie selbst erstellen. Es gibt drei Arten von benutzerdefinierten infoType-Detektoren:
  • Kleine benutzerdefinierte Wörterbuchdetektoren sind einfache Wortlisten, in denen Sensitive Data Protection nach Übereinstimmungen sucht. Verwenden Sie kleine benutzerdefinierte Wörterbuchdetektoren, wenn Sie eine Liste mit mehreren Zehntausend Wörtern oder Wortgruppen haben. Kleine benutzerdefinierte Wörterbuchdetektoren werden bevorzugt, wenn Sie nicht erwarten, dass sich Ihre Wortliste erheblich ändert.
  • Große benutzerdefinierte Wörterbuchdetektoren werden von Sensitive Data Protection unter Verwendung umfangreicher Listen von Wörtern oder Wortgruppen erstellt, die entweder in Cloud Storage oder BigQuery gespeichert sind. Verwenden Sie große benutzerdefinierte Wörterbuchdetektoren, wenn Sie eine große Liste mit (bis zu zehn Millionen) Wörtern oder Wortgruppen haben.
  • Detektoren regulärer Ausdrücke (Regex-Detektoren) ermöglichen es Sensitive Data Protection, Übereinstimmungen anhand eines regulären Ausdrucksmusters zu erkennen.

Außerdem gilt in Sensitive Data Protection das Konzept der Prüfregeln, mit denen Sie die Scanergebnisse auf folgende Weise verfeinern können:

• Ausschlussregeln können Sie einem integrierten oder benutzerdefinierten infoType-Detektor hinzufügen, um die Anzahl der Ergebnisse einzugrenzen.
• Hotword-Regeln können Sie einem integrierten oder benutzerdefinierten infoType-Detektor hinzufügen, um die Anzahl der Ergebnisse zu erhöhen oder den Wahrscheinlichkeitswert der Ausgabe zu ändern.

Integrierte infoType-Detektoren

Integrierte infoType-Detektoren sind in Sensitive Data Protection bereits enthalten und umfassen Detektoren für länder- oder regionsspezifische sensible Daten wie die französische Numéro d'Inscription au Répertoire (NIR) (FRANCE_NIR), die englische Führerscheinnummer (UK_DRIVERS_LICENSE_NUMBER) und die US-amerikanische Sozialversicherungsnummer (US_SOCIAL_SECURITY_NUMBER). Ebenfalls enthalten sind Detektoren für global anwendbare Datentypen wie Namen von Personen (PERSON_NAME), Telefonnummern (PHONE_NUMBER), E-Mail-Adressen (EMAIL_ADDRESS) und Kreditkartennummern (CREDIT_CARD_NUMBER). Um Inhalte zu erkennen, die infoTypes entsprechen, nutzt Sensitive Data Protection verschiedene Techniken wie Mustervergleich, Prüfsummen, maschinelles Lernen und Kontextanalyse.

Die Liste der integrierten infoType-Detektoren wird kontinuierlich aktualisiert. Eine vollständige Liste der derzeit unterstützten integrierten infoType-Detektoren finden Sie in der InfoType-Detektorreferenz.

Sie können auch die vollständige Liste aller integrierten infoType-Detektoren ansehen. Dazu müssen Sie die Methode infoTypes.list von Sensitive Data Protection aufrufen.

Sprachunterstützung

Länderspezifische infoTypes unterstützen die englische Sprache und die Sprachen des jeweiligen Landes. Die meisten globalen infoTypes funktionieren mit mehreren Sprachen. Testen Sie den Schutz sensibler Daten mit Ihren Daten, um zu prüfen, ob er Ihren Anforderungen entspricht.

Allgemeine und spezifische InfoType-Detektoren

Ein allgemeiner infoType-Detektor ist ein Detektor, der allgemeiner definiert ist als typische infoType-Detektoren und eine Vielzahl potenziell sensibler Informationstypen abgleichen kann. Allgemeine infoType-Detektoren sind Obermengen spezifischer infoType-Detektoren, die ein gemeinsames Attribut oder einen gemeinsamen Zweck haben. Der infoType-Detektor DRIVERS_LICENSE_NUMBER kann beispielsweise Inhalte erkennen, die mit den infoTypes GERMANY_DRIVERS_LICENSE_NUMBER und CANADA_DRIVERS_LICENSE_NUMBER übereinstimmen.

In vielen Fällen können allgemeine infoType-Detektoren auch Übereinstimmungen finden, die spezifische infoType-Detektoren nicht finden können. Der PASSPORT-Detektor ist beispielsweise besser darin, Reisepassnummern zu finden, als länderspezifische Reisepassdetektoren, die manchmal das Vorhandensein von Kontextinformationen oder speziell formatierten Inhalten erfordern.

In Ihrer Prüfkonfiguration können Sie anstelle eines bestimmten infoType-Detektors einen allgemeinen infoType-Detektor verwenden. Die Ergebnisse des Schutzes sensibler Daten basieren auf dem Detektor, den Sie in Ihrem Antrag angegeben haben. Wenn beispielsweise ein String, den Sie prüfen, mit dem infoType GERMANY_DRIVERS_LICENSE_NUMBER übereinstimmt und Sie in Ihrer Anfrage sowohl nach DRIVERS_LICENSE_NUMBER als auch nach GERMANY_DRIVERS_LICENSE_NUMBER gesucht haben, erhalten Sie zwei Ergebnisse für denselben String – eines für DRIVERS_LICENSE_NUMBER und eines für GERMANY_DRIVERS_LICENSE_NUMBER. Wenn Sie in Ihrer Anfrage jedoch nur nach DRIVERS_LICENSE_NUMBER gesucht haben, wird im Prüfergebnis nur das Ergebnis für DRIVERS_LICENSE_NUMBER angezeigt.

Die Verwendung eines allgemeinen infoType-Detektors bietet folgende Vorteile:

• In vielen Fällen haben allgemeine infoType-Detektoren einen höheren Recall als spezifische infoType-Detektoren. Die Trefferquote ist die Anzahl der richtig positiven Instanzen im Verhältnis zur Gesamtzahl der relevanten Instanzen.

• Sie können Ihre Anfragen zum Schutz sensibler Daten vereinfachen, da Sie nicht jeden einzelnen infoType angeben müssen, nach dem gesucht werden soll. Der infoType-Detektor GOVERNMENT_ID allein umfasst beispielsweise mehr als 100 verschiedene infoType-Detektoren.

• Es ist weniger wahrscheinlich, dass Sie das Limit von 150 infoType-Detektoren pro Anfrage erreichen.

• Wenn Sensitive Data Protection einen neuen infoType veröffentlicht und ihn einem allgemeinen infoType hinzufügt, der bereits in Ihren vorhandenen Konfigurationen angegeben ist, wird der neue infoType automatisch in die Scans aufgenommen. Sie müssen neu veröffentlichte infoTypes nicht manuell zu Ihren vorhandenen Konfigurationen hinzufügen.

Zwischen allgemeinen und spezifischen infoTypes besteht eine m:n-Beziehung. Ein allgemeiner infoType kann viele spezifische infoTypes enthalten und ein spezifischer infoType kann zu vielen allgemeinen infoTypes gehören. Eine vollständige Liste der allgemeinen infoTypes und der spezifischen infoTypes, die sie enthalten, finden Sie unter Allgemeine infoTypes.

Benutzerdefinierte infoType-Detektoren

Es gibt drei Arten von benutzerdefinierten infoType-Detektoren:

• Kleine benutzerdefinierte Wörterbuchdetektoren
• Große benutzerdefinierte Wörterbuchdetektoren
• Reguläre Ausdrücke (Regex)

Darüber hinaus enthält Sensitive Data Protection Prüfregeln, mit denen Sie die Scanergebnisse mit den folgenden vorhandenen Detektoren verfeinern können:

• Ausschlussregeln
• Hotword-Regeln

Kleine benutzerdefinierte Wörterbuchdetektoren

Verwenden Sie kleine benutzerdefinierte Wörterbuchdetektoren (auch als "reguläre benutzerdefinierte Wörterbuchdetektoren" bezeichnet), um eine kurze Liste mit (bis zu zehntausenden) Wörtern oder Wortgruppen abzugleichen. Ein kleines benutzerdefiniertes Wörterbuch kann als eigener eindeutiger Detektor verwendet werden.

Benutzerdefinierte Wörterbuchdetektoren sind nützlich, wenn Sie Inhalte auf Übereinstimmungen mit einer Liste von Wörtern oder Ausdrücken prüfen möchten, die mit einem regulären Ausdruck oder einem integrierten Detektor nicht leicht gefunden werden können. Nehmen Sie zum Beispiel an, Sie möchten nach Konferenzräumen suchen, die nicht mit Raumnummern gekennzeichnet, sondern nach Namen von Ländern oder Regionen, Sehenswürdigkeiten oder fiktiven Figuren benannt sind. Hier können Sie einen kleinen benutzerdefinierten Wörterbuchdetektor erstellen, der eine Liste dieser Raumnamen enthält. Sensitive Data Protection kann Ihren Inhalt nach allen enthaltenen Raumnamen prüfen und eine Übereinstimmung zurückgeben, wenn er im Kontext einen davon findet. Weitere Informationen dazu, wie Sensitive Data Protection nach Wörtern und Wortgruppen aus Wörterbüchern sucht, finden Sie unter Regulären benutzerdefinierten Wörterbuchdetektor erstellen im Abschnitt Details zum Wörterbuchabgleich.

Weitere Informationen zur Funktionsweise von kleinen benutzerdefinierte infoType-Wörterbuchdetektoren sowie Beispiele in der Praxis finden Sie unter Regulären benutzerdefinierten Wörterbuchdetektor erstellen.

Große benutzerdefinierte Wörterbuchdetektoren

Verwenden Sie große benutzerdefinierte Wörterbuchdetektoren (auch als "gespeicherte benutzerdefinierte Wörterbuchdetektoren" bezeichnet), wenn Sie nach mehreren Wörtern oder Wortgruppen scannen möchten oder wenn sich Ihre Liste mit Wörtern oder Wortgruppen häufig ändert. Große benutzerdefinierte Wörterbuchdetektoren können Dutzende Millionen von Wörtern oder Wortgruppen abgleichen.

Große benutzerdefinierte Wörterbuchdetektoren werden anders erstellt als benutzerdefinierte Detektoren für reguläre Ausdrücke und kleine benutzerdefinierte Wörterbuchdetektoren. Jedes große benutzerdefinierte Wörterbuch umfasst zwei Komponenten:

• Eine Liste von Wortgruppen, die Sie erstellen und definieren. Die Liste wird entweder als Textdatei in Cloud Storage oder als Spalte in einer BigQuery-Tabelle gespeichert.
• Die generierten Wörterbuchdateien, die von Sensitive Data Protection basierend auf Ihrer Wortgruppenliste generiert werden. Die Wörterbuchdateien werden in Cloud Storage gespeichert und bestehen aus einer Kopie der Quellwortgruppen sowie Bloomfiltern, die beim Suchen und Abgleichen helfen. Sie können diese Dateien nicht direkt bearbeiten.

Nachdem Sie eine Wortliste erstellt und dann mit dem Schutz sensibler Daten ein benutzerdefiniertes Wörterbuch generiert haben, starten oder planen Sie einen Scan mithilfe eines großen benutzerdefinierten Wörterbuchdetektors, ähnlich wie mit anderen infoType-Detektoren.

Weitere Informationen zur Funktionsweise von großen benutzerdefinierten Wörterbuchdetektoren sowie Beispiele in der Praxis finden Sie unter Gespeicherten benutzerdefinierten Wörterbuchdetektor erstellen.

Reguläre Ausdrücke

Ein benutzerdefinierter, auf einem regulären Ausdruck (Regex) basierender infoType-Detektor ermöglicht es Ihnen, eigene infoType-Detektoren zu erstellen, mit denen der Schutz sensibler Daten Übereinstimmungen anhand eines Regex-Musters erkennen kann. Nehmen Sie beispielsweise an, Sie haben Krankenaktennummern im Format ###-#-#####. Sie könnten ein Regex-Muster wie das Folgende definieren:

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

Sensitive Data Protection prüft dann auf Übereinstimmungen mit Elementen wie diesem:

123-4-56789

Außerdem können Sie jeder benutzerdefinierten infoType-Übereinstimmung eine Wahrscheinlichkeit zuweisen. Das heißt, wenn Sensitive Data Protection eine Übereinstimmung mit der angegebenen Sequenz findet, weist sie die von Ihnen angegebene Wahrscheinlichkeit zu. Dies ist nützlich, wenn Ihr benutzerdefinierter Regex einer Sequenz entspricht, die allgemein verwendet wird und auch ohne weiteres anderen, nicht relevanten Sequenzen entsprechen könnte. In diesem Fall sollte Sensitive Data Protection nicht jede Übereinstimmung als VERY_LIKELY einstufen. Dies würde nämlich die Zuverlässigkeit der Scanergebnisse beeinträchtigen und möglicherweise dazu führen, dass die falsche Information de-identifiziert wird.

Weitere Informationen zu regulären infoType-Detektoren für reguläre Ausdrücke sowie Praxisbeispiele finden Sie unter Benutzerdefinierten Regex-Detektor erstellen.

Inspektionsregeln

Prüfregeln werden verwendet, um die von vorhandenen, regulären oder benutzerdefinierten, infoType-Detektoren zurückgegebenen Ergebnisse zu verfeinern. Prüfregeln können nützlich sein, wenn die Ergebnisse, die Sensitive Data Protection zurückgibt, auf beliebige Weise erweitert werden müssen. Dazu werden Elemente entweder dem vorhandenen infoType-Detektor hinzugefügt oder von diesem ausgeschlossen.

Die zwei Arten von Prüfregeln sind:

• Ausschlussregeln
• Hotword-Regeln

Weitere Informationen zu Inspektionsregeln finden Sie unter infoType-Detektoren zum Verfeinern von Scanergebnissen anpassen.

Ausschlussregeln

Durch Ausschlussregeln können Sie die Anzahl oder die Genauigkeit von zurückgegebenen Ergebnissen eingrenzen. Fügen Sie dafür einem integrierten oder benutzerdefinierten infoType-Detektor Regeln hinzu. Ausschlussregeln tragen dazu bei, die Ausgabe falscher positiver Ergebnisse oder anderer unerwünschter Ergebnisse durch einen infoType-Detektor zu reduzieren.

Wenn Sie beispielsweise E-Mail-Adressen in einer Datenbank suchen, können Sie eine Ausschlussregel in Form eines benutzerdefinierten regulären Ausdrucks einfügen, mit dem Sensitive Data Protection angewiesen wird, alle Ergebnisse auszuschließen, die auf „@beispiel.com“ enden.

Ausschlussregeln können nicht auf object infoTypes angewendet werden.

Weitere Informationen zu Ausschlussregeln finden Sie unter infoType-Detektoren zum Verfeinern von Scanergebnissen anpassen.

Hotword-Regeln

Durch Hotword-Regeln können Sie die Anzahl oder die Genauigkeit von zurückgegebenen Ergebnissen erhöhen. Fügen Sie dafür einem integrierten oder benutzerdefinierten infoType-Detektor Regeln hinzu. Mit Hotword-Regeln werden die Regeln vorhandener infoType-Detektoren gelockert.

Angenommen, Sie möchten eine medizinische Datenbank nach Patientennamen durchsuchen. Sie können zwar den in Sensitive Data Protection integrierten infoType-Detektor PERSON_NAME verwenden, dies führt aber dazu, dass Sensitive Data Protection Übereinstimmungen bei allen Personennamen zurückgibt, nicht nur bei Namen von Patienten. Zur Behebung dieses Problems können Sie eine Hotword-Regel in Form eines regulären Ausdrucks als benutzerdefinierten infoType einfügen, die in einem bestimmten Zeichenabstand vom ersten Zeichen möglicher Übereinstimmungen nach dem Wort "Patient" sucht. Ergebnissen, die diesem Muster entsprechen, können Sie dann eine Wahrscheinlichkeit von "sehr wahrscheinlich" zuweisen, da sie Ihren speziellen Kriterien entsprechen.

Weitere Informationen zu Hotword-Regeln finden Sie unter infoType-Detektoren zum Verfeinern von Scanergebnissen anpassen.

Beispiele

Für ein besseres Verständnis dafür, wie infoTypes mit Ergebnissen übereinstimmen, sehen Sie sich die folgenden Beispiele für Übereinstimmungen mit einer Reihe von Ziffern an. Hier wird bestimmt, ob sie eine US-Sozialversicherungsnummer oder eine US-amerikanische Steueridentifikationsnummer bilden. Beachten Sie, dass sich diese Beispiele auf integrierte infoType-Detektoren beziehen. Wenn Sie einen benutzerdefinierten infoType-Detektor erstellen, geben Sie die Kriterien an, die die Wahrscheinlichkeit einer Scanübereinstimmung bestimmen.

Beispiel 1

"SSN 222-22-2222"

Meldet einen hohen Wahrscheinlichkeitswert von VERY_LIKELY für US_SOCIAL_SECURITY_NUMBER aus folgenden Gründen:

• Es hat das Standardformat für Sozialversicherungsnummern, was die Sicherheit erhöht.
• Es hat Kontext in der Nähe ("SSN"), der ihn in Richtung US_SOCIAL_SECURITY_NUMBER verbessert.

Beispiel 2

"999-99-9999"

Meldet einen niedrigen Wahrscheinlichkeitswert von VERY_UNLIKELY für US_SOCIAL_SECURITY_NUMBER aus folgenden Gründen:

• Es hat das Standardformat, was die Sicherheit erhöht.
• Es beginnt mit einer 9, die in Sozialversicherungsnummern nicht zulässig ist, wodurch die Sicherheit verringert wird.
• Es fehlt der Kontext, was die Sicherheit verringert.

Beispiel 3

"999-98-9999"

Meldet einen Wahrscheinlichkeitswert von POSSIBLE für US_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER und VERY_UNLIKELY für US_SOCIAL_SECURITY_NUMBER aus folgenden Gründen:

• Es hat das Standardformat für US_SOCIAL_SECURITY_NUMBER und US_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER.
• Es beginnt mit einer 9 und hat eine weitere Ziffernprüfung, was die Sicherheit für US_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER erhöht.
• Es hat keinen Kontext, was die Sicherheit für beide verringert.

Nächste Schritte

Das Team für den Schutz sensibler Daten veröffentlicht regelmäßig neue infoType-Detektoren und -Gruppen. Details zur aktuellen Liste der integrierten infoTypes finden Sie unter Integrierte InfoType-Detektoren auflisten.