Job e trigger di job

Un job è un'azione eseguita da Sensitive Data Protection per analizzare i contenuti alla ricerca di dati sensibili o calcolare il rischio di reidentificazione. Sensitive Data Protection crea ed esegue una risorsa job ogni volta che gli chiedi di controllare i tuoi dati.

Attualmente esistono due tipi di job di Sensitive Data Protection:

• I job di ispezione esaminano i tuoi contenuti per individuare dati sensibili in base ai tuoi criteri e generano report di riepilogo sulla posizione e sul tipo di dati sensibili esistenti.
• I job di analisi del rischio analizzano dati anonimizzati e restituiscono metriche sulla probabilità che i dati possano essere reidentificati.

Puoi pianificare l'esecuzione dei job da parte di Sensitive Data Protection creando attivatori di job. Un trigger di job è un evento che automatizza la creazione di job di Sensitive Data Protection per la scansione dei repository di Google Cloud Storage, inclusi bucket Cloud Storage, tabelle BigQuery e tipi di datastore.

I trigger di job consentono di pianificare job di scansione impostando gli intervalli di attivazione di ogni trigger. Possono essere configurati in modo da cercare nuovi risultati dall'esecuzione dell'ultima scansione per monitorare le modifiche o le aggiunte ai contenuti o per generare report aggiornati sui risultati. I trigger pianificati vengono eseguiti in base a un intervallo impostato, da 1 giorno a 60 giorni.

Nota: annullare prematuramente un'operazione durante l'esecuzione di un job causerà comunque un addebito dei costi per la parte del job che è stata completata. Per ulteriori informazioni sulla fatturazione, consulta la pagina relativa ai prezzi di Sensitive Data Protection.

Passaggi successivi

Ulteriori informazioni su come creare, modificare ed eseguire job e trigger di job nei seguenti argomenti:

• Creazione di job di ispezione e trigger di job di Sensitive Data Protection
• Misurazione del rischio di reidentificazione e divulgazione (copre i job di analisi del rischio).

È inoltre disponibile la seguente guida rapida:

• Guida rapida alla creazione di un trigger di job di Sensitive Data Protection

L'oggetto JobTrigger

Un trigger di job è rappresentato nell'API DLP dall'oggetto JobTrigger.

Campi di configurazione dell'attivatore di job

Ogni JobTrigger contiene diversi campi di configurazione, tra cui:

• Il nome e il nome visualizzato dell'attivatore, nonché una descrizione.
• Una raccolta di oggetti Trigger, ognuno dei quali contiene un oggetto Schedule, che definisce la ricorrenza della scansione in secondi.
• Un oggetto InspectJobConfig contenente le informazioni di configurazione per il job attivato.
• Un'enumerazione Status, che indica se il trigger è attualmente attivo.
• Campi timestamp che rappresentano gli orari di creazione, aggiornamento e ultima esecuzione.
• Una raccolta di oggetti Error, se presenti al momento dell'attivazione del trigger.

Metodi di trigger di job

Ogni oggetto JobTrigger include anche diversi metodi integrati. Con questi metodi puoi:

• Crea un nuovo trigger di job: projects.jobTriggers.create
• Aggiorna un trigger di job esistente: projects.jobTriggers.patch
• Elimina un trigger di job esistente: projects.jobTriggers.delete
• Recupera un trigger di job esistente, inclusi la configurazione e lo stato: projects.jobTriggers.get
• Elenca tutti i trigger di job esistenti: projects.jobTriggers.list

Latenza job

Non sono garantiti obiettivi del livello di servizio (SLO) per job e trigger di job. La latenza è influenzata da diversi fattori, tra cui la quantità di dati da scansionare, il repository di archiviazione analizzato, il tipo e il numero di infoType in fase di scansione, la regione in cui viene elaborato il job e le risorse di calcolo disponibili in quella regione. Pertanto, la latenza dei job di ispezione non può essere determinata in anticipo.

Per ridurre la latenza del job, puoi provare quanto segue:

• Se il campionamento è disponibile per il job o il trigger di job, abilitalo.

• Evita di attivare gli infoType che non ti servono. Sebbene quanto segue sia utile in determinati scenari, questi infoType possono eseguire le richieste molto più lentamente rispetto a quelle che non le includono:

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

• Specifica sempre gli infoType in modo esplicito. Non utilizzare un elenco infoType vuoto.

• Se possibile, utilizza una regione di elaborazione diversa.

Se continui ad avere problemi di latenza con i job dopo aver provato queste tecniche, valuta la possibilità di utilizzare le richieste content.inspect o content.deidentify anziché i job. Questi metodi sono coperti dal Contratto sul livello del servizio. Per maggiori informazioni, consulta l'Accordo sul livello del servizio di Sensitive Data Protection.

Limita le scansioni ai nuovi contenuti

Puoi configurare il trigger di job in modo che imposti automaticamente la data dell'intervallo di tempo per i file archiviati in Cloud Storage o BigQuery. Quando imposti il completamento automatico dell'oggetto TimespanConfig, Sensitive Data Protection analizza solo i dati aggiunti o modificati dall'ultima esecuzione dell'attivatore:

...
  timespan_config {
        enable_auto_population_of_timespan_config: true
      }
...

Nota: consulta il problema noto relativo a questa operazione.

Attiva job al caricamento file

Oltre al supporto per i trigger di job, integrati in Sensitive Data Protection, Google Cloud offre anche una varietà di altri componenti che puoi utilizzare per integrare o attivare job di Sensitive Data Protection. Ad esempio, puoi utilizzare Cloud Functions per attivare una scansione di Sensitive Data Protection ogni volta che un file viene caricato in Cloud Storage.

Per informazioni su come configurare questa operazione, consulta Automazione della classificazione dei dati caricati in Cloud Storage.