סוגי מידע ומזהי סוגי מידע

‫Sensitive Data Protection משתמש בסוגי מידע – או infoTypes – כדי להגדיר את מה שהוא סורק. סוג מידע (infoType) הוא סוג של מידע אישי רגיש, כמו שם, כתובת אימייל, מספר טלפון, מספר זיהוי, מספר כרטיס אשראי וכו'. גלאי מסוג infoType הוא מנגנון הזיהוי המתאים שמתאים לקריטריונים של infoType.

שיטות מומלצות לבחירת סוגי מידע

אחד השלבים הראשונים והחשובים בהגנה על הנתונים הוא להבין אותם. השיטה המומלצת היא לאסוף, לאחסן ולעבד רק את המידע שאתם צריכים לצורך עסקי. זיהוי הנתונים שאתם מטפלים בהם מאפשר לכם לקבל החלטות מושכלות לגבי העסק, המשתמשים, אבטחת הנתונים והפרטיות.

יכול להיות שחלק מהתרחישים העסקיים שלכם ידרשו מידע רגיש מסוים, ואחרים לא. אין פתרון יחיד שתומך בכל תרחישי השימוש. לכן, Sensitive Data Protection מאפשר שליטה גמישה בסוגי הנתונים שנסרקים. אם אתם משתמשים ב-infoTypes לביטול הזיהוי או להסתרת נתונים, אתם גם יכולים לשלוט מתי ואיך הנתונים עוברים טרנספורמציה.

הנחיות כלליות

כשבוחרים את סוגי המידע, חשוב להקפיד על ההנחיות הכלליות הבאות:

שימוש בסוגי מידע כלליים במקום בסוגי מידע ספציפיים

אם אתם לא צריכים שתוצאות הסריקה יציגו את סוגי המידע הספציפיים שזוהו, כדאי להשתמש בסוגי מידע כלליים במקום בסוגי מידע ספציפיים בהגדרות הבדיקה. בקטע גלאי סוגי מידע כלליים וספציפיים בדף הזה מוסבר על היתרונות של שימוש בגלאי סוגי מידע כלליים בבקשות.

רשימה מלאה של סוגי מידע כלליים וסוגי המידע הספציפיים שהם כוללים זמינה במאמר סוגי מידע כלליים.

מידע רגיש שאין צורך לאסוף

כל שירות בעסק שלכם צריך לאסוף רק את הנתונים שהוא צריך. לדוגמה, שירותים מסוימים בעסק לא צריכים לאסוף מידע פיננסי. בשירותים האלה, כדאי להפעיל גלאי infoType כמו CREDIT_CARD_NUMBER,‏ FINANCIAL_ACCOUNT_NUMBER ו-infoTypes אחרים בקטגוריית ענף FINANCE.

מידע שאתם צריכים לאסוף אבל לא רוצים לשתף עם כל הצוות

יכול להיות שיש מקרים מוצדקים לאיסוף מידע אישי, אבל לא כדאי לשתף אותו עם כל הצוות. לדוגמה, לקוח ששולח כרטיס תמיכה עשוי לספק לכם פרטים ליצירת קשר, כדי שתוכלו ליצור איתו קשר ולפתור בעיות. אתם לא רוצים שכל מי שצופה בכרטיס בצוות יראה את הפרטים האישיים המזהים (PII). מומלץ להפעיל גלאים של infoType כמו PHONE_NUMBER,‏ EMAIL_ADDRESS ו-infoTypes אחרים בקטגוריית הסוג PII.

קטגוריות של מידע אישי רגיש שחלות עליהן תקנות בתחום, תקנות בנושא פרטיות נתונים או תקנות שיפוטיות

סוגי מידע מסוימים נחשבים רגישים בגלל האופן שבו הם מונפקים או בגלל השימוש שאפשר לעשות בהם. במקרים אחרים, מידע הקשרי ודמוגרפי נחשב לקטגוריה מוגנת. יכול להיות שיהיו הגבלות נוספות על אופן האיסוף, השימוש והניהול של סוגי המידע האלה. מומלץ להפעיל גלאי סוגי מידע בקטגוריות הבאות:

• הקלדת קטגוריה SPII, GOVERNMENT_ID וDEMOGRAPHIC
• קטגוריית התחום HEALTH

בחירה בין סוגי מידע דומים

כשבוחרים בין גלאים דומים של infoType, כדאי להביא בחשבון את הנקודות הבאות.

דרכונים

אם אין צורך לסרוק מזהי דרכון ממדינה ספציפית, בוחרים בגלאי הכללי: PASSPORT.

יש גלאי דרכונים שמתמקדים במדינות מסוימות, כמו UK_PASSPORT. עם זאת, חלק מהגלאים של דרכונים ספציפיים למדינה יכולים לזהות רק דרכונים בפורמטים מסוימים או דרכונים שכוללים רמזים הקשריים.

שמות של אנשים

כשסורקים שמות של אנשים, ברוב תרחישי השימוש כדאי להשתמש ב-PERSON_NAME במקום ב-FIRST_NAME או ב-LAST_NAME.

‫PERSON_NAME הוא מזהה של שמות אנשים. הוא כולל שמות שמורכבים ממילה אחת ושמות מלאים. המזהה הזה מנסה לזהות, לדוגמה, שמות כמו Jane,‏ Jane Smith ו-Jane Marie Smith באמצעות טכנולוגיות שונות, כולל הבנת שפה טבעית. ‫FIRST_NAME ו-LAST_NAME הם קבוצות משנה של המזהה הזה שמנסות לזהות חלקים משם. הממצאים של המזהים האלה הם תמיד קבוצות משנה של הממצאים של PERSON_NAME.

תאריכים ושעות

אם אין צורך לסרוק את כל התאריכים, אפשר להשתמש בכלי לזיהוי תאריכים ממוקד כמו DATE_OF_BIRTH. המזהה הזה מנסה לזהות הקשר שמצביע על כך שהתאריך קשור למועד הלידה של אדם.

המזהה DATE מנסה למצוא את כל התאריכים בלי קשר להקשר. הוא גם מסמן תאריכים יחסיים, כמו היום או אתמול. באופן דומה, TIME מנסה למצוא את כל חותמות הזמן.

מיקומים

אם לא צריך לסרוק את כל המיקומים, כדאי להשתמש ב-STREET_ADDRESS במקום בכלי לזיהוי LOCATION. הכלי STREET_ADDRESSdetector מנסה למצוא כתובות מוגדרות במלואן, שבדרך כלל מדויקות יותר ממיקומים כלליים, ויכולות להיחשב כרגישות יותר.

הכלי LOCATION infoType detector מנסה למצוא מיקום כלשהו בלי קשר להקשר – לדוגמה, Paris או Canada.

מזהים של סוגי מידע שדורשים הקשר

הרבה גלאים של סוגי מידע דורשים רמזים הקשריים כדי לזהות התאמה. אם גלאי מובנה של סוגי מידע לא מסמן פריטים שאתם מצפים שיסומנו, כי אין רמזים הקשריים בקרבה לפריטים האלה, כדאי להשתמש במקום זאת ב-GENERIC_ID או בגלאי מותאם אישית של סוגי מידע.

סוגי מידע שאין להם הגדרה משותפת בתחום

לסוגי מידע מסוימים אין הגדרה משותפת בתחום. דוגמאות: מספרים של רשומות רפואיות, מספרי חשבונות, קודי אימות וקודי אבטחה. במקרים כאלה, כדאי להשתמש ב-infoTypes כמו GENERIC_ID,‏ FINANCIAL_ACCOUNT_NUMBER ו-MEDICAL_RECORD_NUMBER. המזהים האלה משתמשים בשילוב של זיהוי ישויות והקשר כדי למצוא רכיבים שעלולים להיות רגישים.

מזהים של סוגי מידע עם זמן אחזור ארוך יותר

• אל תפעילו גלאי סוגי מידע שאתם לא צריכים. למרות שסוגי המידע הבאים שימושיים בתרחישים מסוימים, הם עלולים לגרום להרצת בקשות לאט יותר בהשוואה לבקשות שלא כוללות אותם:

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

• תמיד צריך לציין גלאי infoType באופן מפורש. אל תשתמשו ברשימה ריקה של infoTypes.

איך משתמשים ב-infoTypes

כדי לקבוע מה לבדוק ואיך לשנות את הממצאים, מערכת Sensitive Data Protection משתמשת בגלאי Infotype בהגדרות של הסריקות שלה. שמות של סוגי מידע משמשים גם להצגה או לדיווח של תוצאות הסריקה.

לדוגמה, אם רוצים לחפש כתובות אימייל בבלוק טקסט, צריך לציין את EMAIL_ADDRESSהגלאי infoType בהגדרות הבדיקה. אם רוצים לצנזר כתובות אימייל מבלוק הטקסט, צריך לציין EMAIL_ADDRESS גם בהגדרות הבדיקה וגם בהגדרות הסרת הפרטים המזהים, כדי לציין איך לצנזר או לשנות את הסוג הזה.

בנוסף, אפשר להשתמש בשילוב של גלאי infoType מובנים ובהתאמה אישית כדי להחריג קבוצת משנה של כתובות אימייל מתוצאות הסריקה. קודם צריך ליצור סוג מידע מותאם אישית בשם INTERNAL_EMAIL_ADDRESS ולהגדיר אותו כך שכתובות אימייל של בדיקה פנימית לא ייכללו בו. אחר כך אפשר להגדיר את הסריקה כך שתכלול ממצאים לגבי EMAIL_ADDRESS, אבל להוסיף כלל החרגה שיחריג ממצאים שתואמים ל-INTERNAL_EMAIL_ADDRESS. מידע נוסף על כללי החרגה ותכונות אחרות של גלאי סוגי מידע בהתאמה אישית זמין במאמר בנושא יצירת גלאי סוגי מידע בהתאמה אישית.

‫Sensitive Data Protection מספק קבוצה של גלאי infoType מובנים שאתם מציינים לפי שם. כל אחד מהם מפורט בחומר העזר בנושא גלאי infoType. המזהים האלה משתמשים במגוון טכניקות כדי לגלות ולסווג כל סוג. לדוגמה, חלק מהסוגים ידרשו התאמה לתבנית, חלקם עשויים לכלול סכומי ביקורת מתמטיים, חלקם כוללים הגבלות מיוחדות על ספרות, ואחרים עשויים לכלול קידומות ספציפיות או הקשר סביב הממצאים.

דוגמאות

כשמגדירים את Sensitive Data Protection כדי לסרוק את התוכן, צריך לכלול את גלאי ה-infoType שבהם רוצים להשתמש בהגדרת הסריקה.

לדוגמה, בדוגמאות הקוד וה-JSON הבאות מוצגת בקשת סריקה פשוטה ל-DLP API. שימו לב שגלאי PHONE_NUMBER מצוין ב-inspectConfig, שמורה ל-Sensitive Data Protection לסרוק את המחרוזת הנתונה כדי למצוא מספר טלפון.

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

בהגדרת הבדיקה צריך לציין infoTypes מסוימים שמופיעים בהפניה. אם לא מציינים infoTypes, ‏ Sensitive Data Protection משתמש ברשימת infoTypes שמוגדרת כברירת מחדל ומיועדת למטרות בדיקה בלבד. יכול להיות שהרשימה שמוגדרת כברירת מחדל לא מתאימה לתרחישי השימוש שלכם.

למידע נוסף על שימוש בגלאי infoType לסריקת התוכן, אפשר לעיין באחד מהמאמרים עם הוראות בנושא בדיקה, עריכה או הסרת פרטים מזהים.

מהימנות ובדיקות

התוצאות מדווחות עם ציון ודאות שנקרא סבירות. הציון של הסבירות מציין עד כמה סביר שממצא מסוים תואם לסוג המתאים. לדוגמה, סוג מסוים עשוי להחזיר סבירות נמוכה יותר אם הוא תואם רק לתבנית, וסבירות גבוהה יותר אם הוא תואם לתבנית ויש סביבו הקשר חיובי. לכן יכול להיות שתשימו לב שממצא יחיד יכול להתאים לכמה סוגים ברמת סבירות נמוכה יותר. בנוסף, יכול להיות שממצא לא יופיע או שרמת הוודאות שלו תהיה נמוכה יותר אם הוא לא תואם בצורה נכונה, או אם יש סביבו הקשר שלילי. לדוגמה, יכול להיות שממצא לא ידווח אם הוא תואם למבנה של סוג המידע שצוין, אבל לא עובר את בדיקת הסכום המשולב של סוג המידע. לחלופין, יכול להיות שממצא מסוים יתאים ליותר מסוג מידע אחד, אבל ההקשר שלו יחזק את אחד מהם, ולכן הוא ידווח רק עבור הסוג הזה.

אם אתם בודקים גלאים שונים, יכול להיות שתשימו לב שנתונים מזויפים או נתונים לדוגמה לא מדווחים, כי הם לא עוברים מספיק בדיקות כדי שיהיה אפשר לדווח עליהם.

סוגים של מזהי סוגי מידע

‫Sensitive Data Protection כולל כמה סוגים של גלאי infoType, וכולם מסוכמים כאן:

• גלאי infoType מובנים הם חלק מ-Sensitive Data Protection. הם כוללים גלאים לסוגי מידע אישי רגיש שספציפיים למדינה או לאזור, וגם לסוגי נתונים שרלוונטיים באופן גלובלי. אפשר גם להשתמש בסוגי מידע כלליים כדי לפשט את ההגדרות.
• מזהים מותאמים אישית של סוגי מידע הם מזהים שאתם יוצרים בעצמכם. יש שלושה סוגים של גלאי סוגי מידע בהתאמה אישית:
  • מזהים של מילונים קטנים בהתאמה אישית הם רשימות מילים פשוטות ש-Sensitive Data Protection מתאים להן. כדאי להשתמש בגלאים של מילון מותאם אישית קטן אם יש לכם רשימה של עד כמה עשרות אלפי מילים או ביטויים. מומלץ להשתמש במזהים של מילונים קטנים בהתאמה אישית אם לא צפויים שינויים משמעותיים ברשימת המילים.
  • גלאים גדולים של מילונים בהתאמה אישית נוצרים על ידי Sensitive Data Protection באמצעות רשימות גדולות של מילים או ביטויים שמאוחסנים ב-Cloud Storage או ב-BigQuery. כדאי להשתמש בגלאים של מילון מותאם אישית גדול אם יש לכם רשימה גדולה של מילים או ביטויים – עד עשרות מיליונים.
  • מזהים של ביטויים רגולריים (regex) מאפשרים ל-Sensitive Data Protection לזהות התאמות על סמך דפוס של ביטוי רגולרי.

כדי לשפר את תוצאות הסריקה, אפשר ליצור כללי בדיקה.

מזהים מובנים של infoType

מזהים מובנים של infoType מוטמעים ב-Sensitive Data Protection, וכוללים גלאים של סוגי מידע אישי רגיש שספציפיים למדינה או לאזור מסוימים, כמו Numéro d'Inscription au Répertoire‏ (NIR) (FRANCE_NIR) בצרפת, מספר רישיון נהיגה בבריטניה (UK_DRIVERS_LICENSE_NUMBER) ומספר תעודת זהות בארה"ב (US_SOCIAL_SECURITY_NUMBER). הם כוללים גם סוגי נתונים שרלוונטיים באופן גלובלי, כמו שם של אדם (PERSON_NAME), מספרי טלפון (PHONE_NUMBER), כתובות אימייל (EMAIL_ADDRESS) ומספרי כרטיסי אשראי (CREDIT_CARD_NUMBER).

רשימת הגלאים המובנים של סוגי המידע מתעדכנת כל הזמן. רשימה מלאה של מזהי InfoType מובנים שנתמכים כרגע זמינה בחומר העזר בנושא גילוי InfoType.

אפשר גם להציג רשימה מלאה של כל הגלאים המובנים של Infotype על ידי קריאה לשיטה infoTypes.list של Sensitive Data Protection.

טכניקות זיהוי

כדי לזהות תוכן שתואם לסוגי מידע מובנים, Sensitive Data Protection משתמש בטכניקות שונות, כולל התאמת תבניות, אימות של סכומי ביקורת, למידת מכונה וניתוח הקשר. לדוגמה, כדי לזהות את סוג המידע CREDIT_CARD_NUMBER, הכלי 'הגנה על מידע רגיש' מחפש קידומות ידועות של מנפיקים, מאמת את סכומי הביקורת, מנתח את אורכי התווים ומתייחס להקשר שבו מופיע מספר כרטיס האשראי הפוטנציאלי.

הדגמה של Sensitive Data Protection היא אפליקציה מבוססת-אינטרנט שבה אפשר לבדוק גלאי infoType מובנים.

שפות

סוגי מידע ספציפיים למדינה תומכים בשפה האנגלית ובשפות של המדינה הרלוונטית. רוב סוגי המידע הגלובליים פועלים עם כמה שפות. כדאי לבדוק את Sensitive Data Protection עם הנתונים שלכם כדי לוודא שהיא עונה על הדרישות.

מזהים כלליים וספציפיים של סוגי מידע

גלאי infoType כללי הוא גלאי שמוגדר בצורה רחבה יותר מגלאי infoType רגילים, ויכול להתאים למגוון רחב של סוגי מידע רגיש פוטנציאלי. מידע כללימזהים של סוגי מידע הם קבוצות-על של מזהים ספציפיים של סוגי מידע שחולקים מאפיין או מטרה משותפים. לדוגמה, גלאי מסוג infoType‏ DRIVERS_LICENSE_NUMBER יכול לזהות תוכן שתואם לסוגי המידע GERMANY_DRIVERS_LICENSE_NUMBER ו-CANADA_DRIVERS_LICENSE_NUMBER.

במקרים רבים, גלאי Infotype כלליים יכולים גם למצוא התאמות שגלאי Infotype ספציפיים לא יכולים למצוא. לדוגמה, גלאי PASSPORT טוב יותר באיתור מספרי דרכון מאשר גלאי דרכון ספציפיים למדינה, שלפעמים דורשים נוכחות של רמזים הקשריים או תוכן בפורמט ספציפי.

בהגדרת הבדיקה, אפשר להשתמש בגלאי כללי של סוג מידע במקום בגלאי ספציפי של סוג מידע. התוצאות של Sensitive Data Protection מוצגות על סמך הגלאי שציינתם בבקשה. לדוגמה, אם מחרוזת שבדקתם תואמת ל-GERMANY_DRIVERS_LICENSE_NUMBER infoType וסרקתם את DRIVERS_LICENSE_NUMBER ואת GERMANY_DRIVERS_LICENSE_NUMBER בבקשה, תקבלו שתי תוצאות לגבי אותה מחרוזת – אחת לגבי DRIVERS_LICENSE_NUMBER ואחת לגבי GERMANY_DRIVERS_LICENSE_NUMBER. עם זאת, אם בבקשה שלכם סרקתם רק את DRIVERS_LICENSE_NUMBER, בתוצאת הבדיקה יוצג רק הממצא שקשור ל-DRIVERS_LICENSE_NUMBER.

היתרונות של שימוש בכלי כללי לזיהוי סוגי מידע:

• במקרים רבים, לגלאי infoType כלליים יש recall גבוה יותר מאשר לגלאי infoType ספציפיים. ההחזרה היא מספר המקרים החיוביים האמיתיים מתוך המספר הכולל של המקרים הרלוונטיים.

• אתם יכולים לפשט את הבקשות שלכם ל-Sensitive Data Protection כי אתם לא צריכים לציין כל סוג מידע ספציפי שאתם צריכים לסרוק. לדוגמה, רק GOVERNMENT_ID מזהה סוגי המידע כולל יותר מ-100 מזהים שונים של סוגי מידע.

• הסבירות שתגיעו למגבלה של 150 גלאי סוגי מידע לכל בקשה נמוכה יותר.

• אם Sensitive Data Protection מפרסם infoType חדש ומוסיף אותו ל-infoType כללי שכבר צוין בהגדרות הקיימות, אז Sensitive Data Protection כולל באופן אוטומטי את ה-infoType החדש בסריקות שלו. אתם לא צריכים להוסיף ידנית סוגי מידע חדשים שפורסמו להגדרות הקיימות שלכם.

לסוגי מידע כלליים ולסוגי מידע ספציפיים יש קשר של רבים לרבים. כלומר, סוג מידע כללי יכול לכלול הרבה סוגי מידע ספציפיים, וסוג מידע ספציפי יכול להשתייך להרבה סוגי מידע כלליים. רשימה מלאה של סוגי מידע כלליים וסוגי המידע הספציפיים שהם כוללים זמינה במאמר סוגי מידע כלליים.

מזהים מותאמים אישית של סוגי מידע

יש שלושה סוגים של גלאי סוגי מידע בהתאמה אישית:

• מזהים מותאמים אישית של מילונים קטנים
• מזהים של מילונים מותאמים אישית גדולים
• ביטויים רגולריים (regex)

כדי לשפר את תוצאות הסריקה, אפשר ליצור כללי בדיקה.

מזהים מותאמים אישית של מילונים קטנים

כדאי להשתמש במזהים של מילונים מותאמים אישית קטנים (שנקראים גם 'מזהים של מילונים מותאמים אישית רגילים') כדי להתאים לרשימה קצרה (עד כמה עשרות אלפים) של מילים או ביטויים. מילון מותאם אישית קטן יכול לשמש כמזהה ייחודי משלו.

מזהים של מילונים בהתאמה אישית שימושיים כשרוצים לסרוק רשימה של מילים או ביטויים שלא קל להתאים להם ביטוי רגולרי או מזהה מובנה. לדוגמה, נניח שאתם רוצים לסרוק חדרי ישיבות שמתייחסים אליהם בדרך כלל לפי השמות שהוקצו להם ולא לפי מספרי החדרים, כמו שמות של מדינות או אזורים, ציוני דרך, דמויות בדיוניות וכן הלאה. אפשר ליצור מזהה מותאם אישית קטן של מילון שמכיל רשימה של שמות החדרים האלה. Sensitive Data Protection יכול לסרוק את התוכן שלכם כדי למצוא את כל אחד משמות החדרים, ולהחזיר התאמה כשהוא נתקל באחד מהם בהקשר. בקטע פרטים ספציפיים על התאמה למילון במאמר יצירת גלאי מותאם אישית רגיל למילון מוסבר איך Sensitive Data Protection מתאימה מילים וביטויים במילון.

למידע נוסף על אופן הפעולה של גלאים של סוגי מידע בהתאמה אישית עם מילון קטן, וגם דוגמאות לשימוש, אפשר לעיין במאמר בנושא יצירת גלאי מילון רגיל בהתאמה אישית.

מזהים גדולים של מילונים מותאמים אישית

כדאי להשתמש במזהים של מילונים גדולים בהתאמה אישית (שנקראים גם 'מזהים של מילונים מאוחסנים בהתאמה אישית') אם יש לכם יותר מכמה מילים או ביטויים לסריקה, או אם רשימת המילים או הביטויים משתנה לעיתים קרובות. מזהים של מילונים מותאמים אישית גדולים יכולים להתאים לעשרות מיליוני מילים או ביטויים.

מזהים של מילונים גדולים בהתאמה אישית נוצרים באופן שונה ממזהים של ביטויים רגילים בהתאמה אישית וממזהים של מילונים קטנים בהתאמה אישית. כל מילון גדול מותאם אישית מכיל שני רכיבים:

• רשימה של ביטויים שאתם יוצרים ומגדירים. הרשימה מאוחסנת כקובץ טקסט ב-Cloud Storage או כעמוד בטבלה ב-BigQuery.
• קובצי המילון שנוצרו, שנבנו על ידי Sensitive Data Protection על סמך רשימת הביטויים שלכם. קובצי המילון מאוחסנים ב-Cloud Storage וכוללים עותק של נתוני הביטויים מהמקור, בנוסף למסנני בלום, שמסייעים בחיפוש ובהתאמה. אי אפשר לערוך את הקבצים האלה ישירות.

אחרי שיוצרים רשימת מילים ואז משתמשים ב-Sensitive Data Protection כדי ליצור מילון מותאם אישית, מתחילים סריקה או מתזמנים סריקה באמצעות גלאי מילון מותאם אישית גדול, באופן דומה לגלאי Infotype אחרים.

לפרטים נוספים על אופן הפעולה של גלאים של מילונים גדולים בהתאמה אישית, וגם דוגמאות לשימוש, אפשר לעיין במאמר יצירת גלאי של מילון בהתאמה אישית שמאוחסן.

ביטויים רגולריים

מזהה מידע אישי רגיש בהתאמה אישית באמצעות ביטוי רגולרי (regex) מאפשר לכם ליצור מזהים משלכם של מידע אישי רגיש, כדי ש-Sensitive Data Protection יוכל לזהות התאמות על סמך דפוס של ביטוי רגולרי. לדוגמה, נניח שיש לכם מספרי תיקים רפואיים בפורמט ###-#-#####. אפשר להגדיר תבנית regex כמו זו שבהמשך:

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

לאחר מכן, Sensitive Data Protection מתאים פריטים כמו אלה:

123-4-56789

אפשר גם לציין סבירות להקצאה לכל התאמה של סוג מידע מותאם אישית. כלומר, אם Sensitive Data Protection יזהה התאמה לרצף שציינתם, הוא יקצה את הסבירות שציינתם. השימוש בשיטה הזו מועיל כי אם הביטוי הרגולרי המותאם אישית מגדיר רצף שכיח מספיק, הוא עלול להתאים בקלות לרצף אקראי אחר. במקרה כזה, לא תרצו ש-Sensitive Data Protection יסווג כל התאמה כ-VERY_LIKELY. פעולה כזו תפגע באמינות של תוצאות הסריקה, ועלולה לגרום להתאמה או להסרה של מידע שגוי.

מידע נוסף על גלאים של סוגי מידע בהתאמה אישית באמצעות ביטויים רגולריים ודוגמאות לשימוש זמין במאמר יצירת גלאי מותאם אישית של ביטויים רגולריים.

כללי בדיקה

משתמשים בכללי בדיקה כדי לשפר את התוצאות שמוחזרות על ידי גלאי סוגי מידע קיימים – מובנים או מותאמים אישית. כללי בדיקה יכולים להיות שימושיים במקרים שבהם צריך להוסיף לתוצאות שמתקבלות מ-Sensitive Data Protection או להחריג מהן, או להוסיף לזיהוי הקיים של סוג המידע או להחריג ממנו.

מידע נוסף על כללי בדיקה זמין במאמר בנושא שינוי של גלאי סוגי מידע כדי לשפר את תוצאות הסריקה.

כללי החרגה

כללי החרגה מאפשרים לכם להקטין את הכמות או את רמת הדיוק של הממצאים שמוחזרים על ידי הוספת כללים לגלאי מובנה או מותאם אישית של סוגי מידע. כללי החרגה יכולים לעזור לכם לצמצם את הרעש או ממצאים לא רצויים אחרים שמוחזרים על ידי כלי לזיהוי סוגי מידע.

לדוגמה, אם סורקים מסד נתונים כדי למצוא כתובות אימייל, אפשר להוסיף כלל החרגה בצורה של ביטוי רגולרי מותאם אישית שמורה ל-Sensitive Data Protection להחרגת ממצאים שמסתיימים ב-‎@example.com.

מידע נוסף על כללי החרגה מופיע במאמר בנושא שינוי של גלאי סוגי מידע כדי לשפר את תוצאות הסריקה.

כללים להרחבה (Hotword)

כללי מילות הפעלה מאפשרים לכם להגדיל את הכמות או את הדיוק של הממצאים שמוחזרים על ידי הוספת כללים לגלאי מובנה או מותאם אישית של סוגי מידע. כללים של מילות הפעלה יכולים לעזור לכם להרחיב את הכללים של גלאי קיים של סוג מידע.

לדוגמה, נניח שרוצים לסרוק מסד נתונים רפואי כדי לאתר שמות של מטופלים. אפשר להשתמש בכלי המובנה PERSON_NAME infoType detector של Sensitive Data Protection, אבל הוא יזהה את כל השמות של האנשים, ולא רק את השמות של המטופלים. כדי לפתור את הבעיה, אפשר לכלול כלל הרחבה (Hotword) בצורה של ביטוי רגולרי (regex) custom infoType שמחפש את המילה patient (מטופל) בקרבה מסוימת לתו הראשון של התאמות פוטנציאליות. לאחר מכן תוכלו להקצות לממצאים שתואמים לדפוס הזה סבירות של 'סביר מאוד', כי הם תואמים לקריטריונים המיוחדים שלכם.

מידע נוסף על כללים של מילות הפעלה זמין במאמר שינוי של גלאי סוגי מידע כדי לשפר את תוצאות הסריקה.

דוגמאות

כדי להבין טוב יותר איך סוגי המידע מתאימים לממצאים, אפשר לעיין בדוגמאות הבאות להתאמה לסדרת ספרות כדי לקבוע אם מדובר במספר ביטוח לאומי בארה"ב או במספר Individual Taxpayer Identification Number‏ (ITIN) בארה"ב. חשוב לזכור שהדוגמאות האלה מתייחסות לגלאי סוגי מידע מובנים. כשיוצרים מזהה מותאם אישית של סוג מידע, מציינים את הקריטריונים שקובעים את הסבירות להתאמה לסריקה.

דוגמה 1

"SSN 222-22-2222"

הדוח מציג ציון גבוה של סבירות להמרה VERY_LIKELY עבור US_SOCIAL_SECURITY_NUMBER כי:

• הוא בפורמט הרגיל של מספר תעודת זהות, מה שמגביר את רמת הוודאות.
• יש הקשר בסביבה ("מספר ביטוח לאומי") שמחזק את US_SOCIAL_SECURITY_NUMBER.

דוגמה 2

"999-99-9999"

הדוח מציג ציון נמוך של סבירות להפרה, VERY_UNLIKELY, עבור US_SOCIAL_SECURITY_NUMBER כי:

• הוא בפורמט הרגיל, ולכן רמת הוודאות גבוהה יותר.
• הוא מתחיל בספרה 9, שאסור להשתמש בה במספרי תעודת זהות, וזה מפחית את רמת הוודאות.
• חסר בו הקשר, ולכן רמת הוודאות נמוכה יותר.

דוגמה 3

"999-98-9999"

הדוח מציג ניקוד סבירות של POSSIBLE עבור US_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER ושל VERY_UNLIKELY עבור US_SOCIAL_SECURITY_NUMBER כי:

• הפורמט הוא הפורמט הרגיל של US_SOCIAL_SECURITY_NUMBER ושל US_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER.
• המספר מתחיל ב-9 ויש בו בדיקת ספרה נוספת, מה שמגדיל את רמת הוודאות לגבי US_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER.
• אין הקשר, ולכן רמת הוודאות של שניהם נמוכה.

כללי התאמה

כללי התאמה יכולים לעזור לכם לשפר את דיוק הזיהוי על ידי הגדלה (שנקראת גם הגברה) או הקטנה של ערכי הסבירות של הממצאים על סמך ההקשר שבו הם מופיעים.

לדוגמה, אפשר להשתמש בכלל התאמה כדי להגדיל את ערכי הסבירות של GENERIC_ID ממצאים כשהם מופיעים במסמכים שתואמים ל-DOCUMENT_TYPE/CONTEXT/FINANCE.

מידע נוסף זמין במאמר בנושא כללי התאמה.

המאמרים הבאים

צוות Sensitive Data Protection מפרסם מעת לעת גלאים וקבוצות חדשים של infoType. במאמר רשימה של מזהי Infotype מובנים מוסבר איך מקבלים את הרשימה העדכנית של מזהי Infotype מובנים.