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

Der erste wichtige Schritt zum Schutz Ihrer Daten besteht darin, sie zu verstehen. Als Best Practice sollten Sie nur die Informationen erheben, speichern und verarbeiten, die für Ihr Unternehmen erforderlich sind. Wenn Sie die von Ihnen verarbeiteten Daten identifizieren, können Sie fundierte Entscheidungen für Ihr Unternehmen, Ihre Nutzer sowie für die Datensicherheit und den Datenschutz treffen.

Für einige Ihrer Geschäftsanwendungsfälle sind möglicherweise bestimmte vertrauliche Daten erforderlich, für andere wiederum nicht. Es gibt keine einzige Lösung, die alle Anwendungsfälle unterstützt. Aus diesem Grund bietet Sensitive Data Protection eine flexible Kontrolle über die Datentypen, nach denen gesucht werden soll. Wenn Sie Infotypen für die De-Identifikation oder Maskierung verwenden, können Sie auch festlegen, wann und wie Daten transformiert werden.

Allgemeine Richtlinien

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

Vertrauliche Daten, 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. Für bestimmte Dienste in Ihrem Unternehmen müssen beispielsweise keine Finanzinformationen erhoben werden. Aktivieren Sie für diese Dienste InfoType-Detektoren wie CREDIT_CARD_NUMBER, FINANCIAL_ACCOUNT_NUMBER und andere InfoTypes aus der Branche FINANCE.

Informationen, die Sie erheben müssen, aber nicht allgemein mit Ihrem Team teilen möchten

Es kann durchaus legitime Anwendungsfälle für die Erhebung personenbezogener Daten geben, aber Sie sollten sie nicht allgemein mit Ihrem Team teilen. Ein Kunde, der ein Support-Ticket erstellt, kann dir beispielsweise Kontaktdaten geben, damit du ihn kontaktieren kannst, um Probleme zu beheben. Sie möchten nicht, dass alle Teammitglieder, die sich das Ticket ansehen, die personenidentifizierbaren Informationen sehen. Sie können InfoType-Detektoren wie PHONE_NUMBER, EMAIL_ADDRESS und andere InfoTypes in der Typenkategorie PII aktivieren.

Kategorien sensibler Daten, die Branchen-, Datenschutz- oder rechtlichen Bestimmungen unterliegen

Bestimmte Arten von Informationen gelten aufgrund ihrer Art der Herausgabe oder ihrer Verwendung als sensibel. In anderen Fällen gelten Kontext- und demografische Informationen als geschützte Kategorie. Für diese Arten von Informationen gelten möglicherweise zusätzliche Einschränkungen bei der Erhebung, Verwendung und Verwaltung. Wir empfehlen, infoType-Detektoren in den folgenden Kategorien zu aktivieren:

• Typkategorie SPII, GOVERNMENT_ID und DEMOGRAPHIC
• Branchenkategorie HEALTH

Zwischen ähnlichen infoTypes wählen

Berücksichtigen Sie bei der Auswahl zwischen ähnlichen infoType-Detektoren Folgendes:

Reisepässe

Wenn Sie nicht nach Reisepass-IDs aus einem bestimmten Land suchen müssen, wählen Sie den allgemeinen Detector aus: PASSPORT.

Bestimmte länderspezifische Reisepass-Detektoren wie UK_PASSPORT sind verfügbar. Einige länderspezifische Ausweiserkennungssysteme können jedoch nur Pässe in bestimmten Formaten oder mit Kontexthinweisen erkennen.

Personennamen

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

PERSON_NAME ist ein Detektor für Personennamen. Dazu gehören einsilbige Namen und vollständige Namen. Mit diesem Detektor werden beispielsweise Namen wie Jane, Jane Smith und Jane Marie Smith mithilfe verschiedener Technologien erkannt, 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 nach allen Datumsangaben suchen müssen, können Sie einen gezielten Datumsdetektor wie DATE_OF_BIRTH verwenden. Dieser Detektor versucht, Kontext zu identifizieren, der darauf hinweist, dass das Datum sich auf das Geburtsdatum einer Person bezieht.

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

Standorte

Wenn Sie nicht nach allen Standorten suchen müssen, sollten Sie STREET_ADDRESS anstelle des LOCATION-Detektors verwenden. Der STREET_ADDRESS-Detektor versucht, vollständig qualifizierte Adressen zu finden, die in der Regel genauer sind als allgemeine Standorte und als sensibler eingestuft werden können.

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

InfoType-Detektoren, die Kontext erfordern

Viele Infotyp-Erkennungsmechanismen erfordern Kontexthinweise, bevor eine Übereinstimmung erkannt wird. Wenn ein integrierter infoType-Detektor keine Elemente kennzeichnet, die Ihrer Meinung nach gekennzeichnet werden sollten, weil in unmittelbarer Nähe dieser Elemente keine kontextbezogenen Hinweise vorhanden sind, sollten Sie stattdessen GENERIC_ID oder einen benutzerdefinierten infoType-Detektor verwenden.

Informationstypen ohne gemeinsame Branchendefinition

Für einige Arten von Informationen gibt es keine gemeinsame Branchendefinition. Beispiele hierfür sind Krankenaktennummern, Kontonummern, PINs und Sicherheitscodes. Verwenden Sie für diese Typen InfoTypes wie GENERIC_ID, FINANCIAL_ACCOUNT_NUMBER und MEDICAL_RECORD_NUMBER. Diese Detektoren verwenden eine Kombination aus Entitätserkennung und Kontext, um potenziell sensible Elemente zu finden.

infoType-Detektoren mit höherer Latenz

• Aktivieren Sie nicht benötigte infoType-Detektoren. Die folgenden infoTypes sind in bestimmten Szenarien zwar nützlich, können aber dazu führen, 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

Der Schutz sensibler Daten 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.

Der Schutz sensibler Daten 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 den Schutz sensibler Daten 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 der Schutz sensibler Daten 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 in der Referenz aufgeführte infoTypes angeben. Wenn Sie keine infoTypes angeben, verwendet der Schutz sensibler Daten eine Standard-infoTypes-Liste, die nur zu Testzwecken gedacht 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 den Schutz sensibler Daten eingebunden. Dazu gehören Detektoren für länder- oder regionsspezifische sensible Datentypen sowie global anwendbare Datentypen.
• 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 der Schutz sensibler Daten 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 vom Schutz sensibler Daten unter Verwendung umfangreicher Listen von Wörtern oder Wortgruppen generiert, 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 dem Schutz sensibler Daten, Übereinstimmungen anhand eines regulären Ausdrucksmusters zu erkennen.

Außerdem gilt in Sensitive Data Protection das Konzept der Inspektionsregeln, 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 der Funktion zum Schutz sensibler Daten 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). Zum Erkennen von Inhalten, die InfoTypes entsprechen, werden beim Schutz sensibler Daten verschiedene Verfahren wie Musterabgleich, Prüfsummen, maschinelles Lernen und Kontextanalyse eingesetzt.

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 „Schutz sensibler Daten“ 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.

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 der Schutz sensibler Daten 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. Der Schutz sensibler Daten 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 der Schutz sensibler Daten 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 vom Schutz vor sensiblen Daten anhand Ihrer Wortgruppenliste erstellt 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

Mit einem benutzerdefinierten, auf einem regulären Ausdruck (Regex) basierenden infoType-Detektor können Sie eigene infoType-Detektoren 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 der Schutz sensibler Daten 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. Inspektionsregeln 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 Regex einfügen, mit dem der Schutz sensibler Daten angewiesen wird, alle Ergebnisse auszuschließen, die auf „@beispiel.de“ enden.

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 in einer medizinischen Datenbank nach Patientennamen suchen. 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.