Utilizza la UI dei feed

Supportata in:

Questo documento spiega come creare, risolvere i problemi e gestire i feed nell'interfaccia utente di gestione dei feed, incluse le istruzioni per modificarli, attivarli ed eliminarli.

Prima di iniziare

Ogni feed di dati richiede prerequisiti specifici prima della configurazione in Google Security Operations. Per trovare i requisiti per il tuo feed, consulta Configurazione per tipo di origine e cerca l'origine dati specifica.

Formati di compressione e dimensioni dei file supportati

I formati di compressione supportati per l'importazione dei feed includono .gz, .tar.gz, .tar e solr.gz. La tabella seguente illustra le diverse dimensioni dei file supportate dalla trasformazione dei feed di Google SecOps:

Operazione Tipo di input Dimensioni consigliate Durata prevista Dimensione massima
Modellazione dei dati CSV < 5 GB < 7 min 10 GB
Modellazione dei dati CSV < 5 GB ~30 min 10 GB
Modellazione dei dati CSV Da definire Da definire 2 GB
Modellazione dei dati XML / JSON < 1 GB < 10 min 2 GB
Modellazione dei dati XLS / XLSX < 50 MB ~1 min 50 MB
Unisci file Qualsiasi < 1 GB Varia in base al numero di file 100 GB
Decomprimi file Non ZIP < 5 GB Varia in base al numero di file 10 GB (non compressi)
Decomprimi file CAP - Varia in base al numero di file 4 GB (non compresso)

Limiti e delimitatori delle righe di log

Quando importi log basati su testo (JSON, CSV o Syslog), assicurati che i dati rispettino questi limiti di importazione specifici:

  • Dimensioni massime della riga: una singola riga di log non può superare i 4 MB. Se una singola riga supera questo limite, il feed non va a buon fine e viene visualizzato l'errore MaxLogLineSize4MBExceeded.
  • Delimitatori supportati: sono supportati sia Nuova riga (\n) che Ritorno a capo + Nuova riga (\r\n).

Impatto della modifica del progetto Cloud collegato sui feed di dati

Se aggiorni il progetto Google Cloud associato alla tua istanza di Google SecOps, tutti i feed che importano dati utilizzando i seguenti connettori verranno interrotti e dovranno essere ricreati manualmente:

  • AMAZON_S3_V2
  • AMAZON_SQS_V2
  • GOOGLE_CLOUD_STORAGE_V2
  • AZURE_BLOBSTORE_V2
  • GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN

Per tutti gli altri feed che non utilizzano questi connettori, l'importazione continua senza interruzioni. I clienti non devono intraprendere alcuna azione.

Cosa aspettarsi durante la migrazione

Per i feed interessati, noterai le seguenti modifiche:

  • Stato del feed: i feed creati prima della migrazione smetteranno immediatamente di estrarre dati in tempo reale e diventeranno di sola lettura.
  • Dati esistenti: tutti i dati già trasferiti a Google SecOps prima della migrazione verranno importati automaticamente; non andrà perso alcun dato.
  • Messaggi di errore: se provi a modificare o eliminare un feed precedente, riceverai un messaggio che indica: This feed is read-only because this SecOps has now moved to a new Google Cloud Project (BYOP). To continue ingesting data from this source, please create a new feed.

Azioni richieste ai clienti

Per garantire l'acquisizione continua dei dati, devi ricreare manualmente i feed nel nuovo ambiente. Per ridurre al minimo i disagi, segui questi passaggi:

  1. Ricrea i feed di notizie: devi creare nuovi feed di notizie per sostituire quelli esistenti prima della migrazione.
  2. Configura l'età massima del file: quando configuri i nuovi feed di notizie, imposta l'età massima del file su circa 2 ore prima dell'avvio dell'aggiornamento BYOP. Questo margine di tempo garantisce una transizione senza problemi.

  3. Gestisci i dati duplicati: a seconda dell'età massima dei file selezionata, potresti riscontrare un trasferimento di dati duplicati. Per i dettagli tecnici su come Google SecOps filtra questi log ridondanti, consulta Impedisci la deduplicazione.

  4. Registra ed elimina i feed esistenti (prima della migrazione): prima di iniziare la migrazione BYOP, registra le impostazioni di configurazione di tutti i feed esistenti che utilizzano i connettori interessati (ad esempio Amazon S3 V2), quindi elimina i feed. Se non elimini i feed creati prima della migrazione, diventano ingestibili e rimangono nell'interfaccia web di Google SecOps come impostazioni orfane.

Modi per configurare i feed

I clienti di Google SecOps possono configurare un feed nella piattaforma in due modi. Utilizza il metodo più adatto al tuo ambiente:

  • Impostazioni SIEM > Feed (standard)
  • Hub dei contenuti > Pacchetti di contenuti (premium)

Configura la lista consentita IP

Quando Google SecOps estrae i dati da S3, SQS, Azure e API di terze parti, l'infrastruttura Google si connette in uscita al bucket del cliente o all'API di terze parti.

Per il traffico in entrata, devi configurare la lista consentita in base al tipo di feed, come descritto nel seguente elenco:

  • Feed V2 (S3_V2, SQS_V2, Azure_Blobstore_V2): questi feed utilizzano esclusivamente Google Cloud Storage Transfer Service (STS) per estrarre i dati dallo spazio di archiviazione del cliente. Richiedono l'inserimento nella lista consentita degli intervalli IP di STS: ipranges.json.
  • API di terze parti: richiedono goog.json.
  • Feed legacy (S3, Azure_Blobstore): richiedono intervalli IP dedicati. Per ulteriori informazioni, contatta l'assistenza Google SecOps.
  • Azure Event Hubs: richiede intervalli IP specifici per la regione. Per saperne di più, consulta Configura la sicurezza di rete (facoltativo) in Crea un feed di Azure Event Hubs.

Poiché gli intervalli di indirizzi IP dei servizi Google cambiano in modo dinamico, Google consiglia di configurare il firewall in modo che recuperi e analizzi periodicamente i feed come segue:

  • Feed V2 (S3_V2, SQS_V2, Azure_Blobstore_V2): il trasferimento dei dati viene eseguito esclusivamente dai worker di Storage Transfer Service. Devi solo recuperare e analizzare periodicamente ipranges.json.
  • Feed legacy (S3, SQS, Azure_Blobstore, Azure Event Hub) e API di terze parti: queste connessioni provengono dall'infrastruttura Google. Devi solo recuperare e analizzare periodicamente goog.json e cloud.json.

Configura i feed

Questa sezione descrive come configurare generalmente i feed, a partire dal flusso procedurale standard. I feed di dati elencati nella pagina Feed includono tutti i feed che Google ha configurato per il tuo account, compresi quelli che hai configurato tu.

Aggiungi un feed

Per aggiungere un feed al tuo account Google SecOps, completa i seguenti passaggi:

  1. Nel menu Google SecOps, seleziona Impostazioni SIEM > Feed.

  2. Fai clic su Aggiungi nuovo feed di notizie.

  3. Nella pagina successiva, fai clic su Configura un singolo feed. Nota: questo passaggio non è pertinente per i clienti che utilizzano la piattaforma autonoma Google SecOps SIEM.

  4. Aggiungi un nome per il feed.

  5. Nell'elenco Tipo di origine, seleziona il tipo di origine per l'importazione dei dati in Google SecOps. Puoi scegliere tra i seguenti tipi di origini dei feed:

    • Amazon Data Firehose
    • Amazon S3 (deprecato)
    • Amazon S3 (V2)
    • Amazon SQS (ritirato)
    • Amazon SQS (V2)
    • Azure Blob Storage (ritirato)
    • Azure Blob Storage (V2)
    • API personalizzata
    • Google Cloud Pub/Sub
    • Cloud Storage (deprecato)
    • Cloud Storage (V2)
    • Cloud Storage basato sugli eventi
    • API di terze parti
    • Webhook

    Importante:

    • Quando utilizzi i feed Amazon S3 (ritirato), Amazon SQS (ritirato), Azure Blob Storage (ritirato) e Google Cloud Cloud Storage (ritirato), assicurati di avere un percorso di directory valido.
    • Quando utilizzi Amazon SQS (deprecato) o Amazon SQS (V2), concedi esplicitamente a Google SecOps le autorizzazioni per eliminare i messaggi dalla coda Amazon SQS.
    • Quando utilizzi i feed Amazon SQS (ritirato), assicurati che un solo feed utilizzi i messaggi della coda. I messaggi letti da un'altra applicazione o da un altro feed non vengono importati nel feed corrente.
    • L'utilizzo di Amazon SQS (ritirato) come tipo di origine del feed è supportato solo per i log nei bucket Amazon S3.

  6. Nell'elenco Tipo di log, seleziona il tipo di log corrispondente ai log che vuoi importare. I log disponibili variano in base al tipo di origine selezionato in precedenza.

    Se selezioni Cloud Storage come tipo di origine, utilizza l'opzione Recupera service account per ottenere un account di servizio univoco. Consulta l'esempio di configurazione del feed di Google Cloud Storage.

  7. Fai clic su Avanti.

  8. Specifica i parametri necessari nella scheda Parametri di input. Le opzioni presentate qui variano in base all'origine e al tipo di log selezionati nella scheda Imposta proprietà. Tieni premuto il puntatore sull'icona con il punto interrogativo di ogni campo per ottenere ulteriori informazioni su ciò che devi fornire.

  9. (Facoltativo) Puoi specificare uno spazio dei nomi nella scheda Imposta proprietà. Per saperne di più sugli spazi dei nomi, consulta Utilizza gli spazi dei nomi degli asset.

  10. Fai clic su Avanti.

  11. Rivedi la nuova configurazione del feed nella scheda Finalizza.

  12. Fai clic su Invia. Google SecOps completa un controllo di convalida del nuovo feed. Se il feed supera il controllo, viene generato un nome per il feed, che viene inviato a Google SecOps, che inizia a tentare di recuperare i dati.

Configura più feed per una famiglia di prodotti (solo per i clienti Google SecOps)

Puoi configurare più feed per famiglia di prodotti, in base al tipo di log.

  • Tipi di log di base: contrassegnati come consigliati. Questi tipi di log sono consigliati per le funzionalità principali della piattaforma.
  • Tipi di log supplementari: contrassegnati come facoltativi. Questi tipi di log forniscono un contesto aggiuntivo.

Per semplificare la configurazione, la piattaforma fornisce istruzioni di configurazione specifiche e parametri predefiniti per ogni configurazione. Ad esempio, per CrowdStrike Falcon, puoi creare più feed univoci sia per i tipi di log consigliati che per quelli facoltativi per assicurarti che la copertura dei dati sia sufficiente.

Configura il feed per CrowdStrike EDR

Segui questi passaggi per configurare un feed dei log per CrowdStrike EDR.

  1. In Impostazioni > Feed, fai clic su Aggiungi nuovo feed
    1. Fai clic sul prodotto CrowdStrike Falcon:
    2. Seleziona il tipo di log CrowdStrike EDR.
  2. In alternativa, da Content Hub > Content Packs, fai clic sul prodotto CrowdStrike Falcon:
    1. Fai clic su Inizia.
    2. Seleziona il tipo di log CrowdStrike EDR.

  3. Specifica i valori per i seguenti campi:

    Campo Descrizione
    Source Type Amazon SQS
    Region La regione AWS S3 associata all'URI.
    Queue Name Il nome della coda SQS da cui leggere.
    Account Number Il numero di account SQS.
    Source Deletion Option Indica se eliminare file e directory dopo il trasferimento.
    Queue Access Key ID Una chiave di accesso alfanumerica di 20 caratteri per l'account, ad esempio AKIAOSFOODNN7EXAMPLE.
    Queue Secret Access Key Una chiave di accesso segreta alfanumerica di 40 caratteri per l'account, ad esempio wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY.

  4. (Facoltativo) Configura i seguenti parametri:

    • Nome del feed: nome univoco precompilato per il feed.
    • Spazio dei nomi dell'asset: lo spazio dei nomi associato al feed.
    • Etichette di importazione: etichette applicate agli eventi di questo feed.

  5. Fai clic su Crea feed.

Puoi ripetere questa procedura per creare feed aggiuntivi per lo stesso tipo di log. Puoi anche configurare i feed per altri tipi di log disponibili direttamente da questa pagina. Al termine, vai alla pagina Gestione dei feed per visualizzare un riepilogo dettagliato di tutti i tipi di log configurati.

Elimina i file di origine

L'opzione di eliminazione dell'origine consente di eliminare gli oggetti di origine del feed (file e cartelle) dallo spazio di archiviazione dopo un trasferimento riuscito. Questa opzione è disponibile solo per i tipi di origine dei feed selezionati, tra cui Cloud Storage. Questi tipi di origini dei feed includono il campo SOURCE DELETION OPTION (OPZIONE DI ELIMINAZIONE DELL'ORIGINE) nei flussi di lavoro Aggiungi nuovo e Modifica feed.

Opzioni di eliminazione delle fonti

  • Per i tipi di origini dei feed supportati, incluso Cloud Storage, il campo OPZIONE DI ELIMINAZIONE DELL'ORIGINE offre le seguenti opzioni:

    • Non eliminare mai i file
    • Elimina i file trasferiti e le directory vuote
    • Elimina i file trasferiti

  • Microsoft Azure Blob Storage (AZURE_BLOBSTORE) non supporta l'eliminazione dei file di origine. Per il campo OPZIONE DI ELIMINAZIONE DELL'ORIGINE, seleziona solo l'opzione Non eliminare mai i file.

  • Per le seguenti origini dei feed ("feedSourceType"): GOOGLE_CLOUD_STORAGE_V2, GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN, AMAZON_S3_V2, AMAZON_SQS_V2 e AZURE_BLOBSTORE_V2, il campo OPZIONE DI ELIMINAZIONE DELL'ORIGINE offre due opzioni:

    • MAI: i file non vengono mai eliminati dopo i trasferimenti.
    • ON_SUCCESS: elimina tutti i file e le directory vuote dopo il trasferimento.

Filtra gli oggetti per prefisso nei feed STS

Il campo Includi prefissi (include_prefixes) filtra gli oggetti di archiviazione trasferiti da Storage Transfer Service (STS) prima dell'importazione in base ai prefissi delle chiavi degli oggetti. I valori specificati in questo campo vengono passati direttamente a STS ObjectConditions.include_prefixes.

Tipi di origini dei feed STS supportati

Il filtro basato su prefisso è supportato per i seguenti tipi di origine dei feed STS (feedSourceType):

  • Cloud Storage (V2) (GOOGLE_CLOUD_STORAGE_V2) e Cloud Storage basato su eventi (GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN)
  • Amazon S3 (V2) (AMAZON_S3_V2) e Amazon SQS (V2) (AMAZON_SQS_V2)
  • Azure Blob Storage (V2) (AZURE_BLOBSTORE_V2) e Azure Blob Storage basato su eventi (AZURE_BLOBSTORE_EVENT_DRIVEN)

Sintassi del prefisso e regole di convalida

Quando configuri Includi prefissi (include_prefixes), segui queste regole di sintassi e convalida:

  • Nessuna barra iniziale: i prefissi sono relativi alla directory principale del bucket o del container e non devono iniziare con una barra iniziale (/). Ad esempio, inserisci logs/audit/ anziché /logs/audit/.
  • Barre finali e corrispondenza parziale: le barre finali controllano se un prefisso corrisponde solo agli oggetti in una cartella specifica o a qualsiasi chiave oggetto che inizia con il prefisso:
    • Con uno slash finale: un prefisso che termina con / (ad esempio, logs/app/) limita le corrispondenze esclusivamente agli oggetti all'interno della cartella. Includi una barra finale per l'ambito a livello di directory.
    • Senza barra finale: un prefisso senza barra finale / (ad esempio, logs/app) corrisponde a qualsiasi oggetto che inizia con quella stringa, inclusi logs/app_old/ e logs/application/.
  • Sensibilità alle maiuscole: i prefissi delle chiavi degli oggetti sono sensibili alle maiuscole.
  • Nessun carattere jolly o espressione regolare: la corrispondenza dei pattern non è supportata. I caratteri come * e ? vengono trattati come caratteri letterali.
  • Nessun valore vuoto: le singole voci del prefisso non possono essere vuote o contenere solo spazi vuoti. Per importare l'intero bucket o container, lascia vuoto il campo Includi prefissi.
  • Spazi dei nomi distinti e non sovrapposti: un prefisso non può essere un prefisso di un altro prefisso nello stesso elenco. Ad esempio, ["logs/", "logs/audit/"] non è valido, mentre i prefissi di pari livello come ["logs/audit/", "logs/vpc/"] sono validi.
  • Limiti: un feed supporta fino a 1000 prefissi. Ogni prefisso può avere una lunghezza massima di 1024 byte se codificato in UTF-8 e non può contenere caratteri di ritorno a capo (\r) o di nuova riga (\n).

Configurazione e autorizzazioni specifiche per l'origine

Tipi di origini diversi richiedono configurazioni di autenticazione e di rete specifiche per comunicare con Google SecOps. Questa sezione descrive come configurare le autorizzazioni e i service account. La configurazione descritta si concentra sull'importazione da Cloud Storage (basata su pull), sull'importazione multi-cloud (pull cross-cloud) e sull'importazione basata su push (API o in tempo reale).

Esempio di configurazione del feed Google Cloud Storage

  1. Nel menu di Google SecOps, seleziona Impostazioni e poi fai clic su Feed.
  2. Fai clic su Aggiungi nuovo feed di notizie.
  3. Nella pagina successiva, fai clic su Configura un singolo feed. Questo passaggio non si applica se utilizzi la piattaforma autonoma Google SecOps SIEM.
  4. Seleziona Cloud Storage v2 per Tipo di origine.
  5. Seleziona il Tipo di log. Ad esempio, per creare un feed per gli audit log di Google Kubernetes Engine, seleziona Audit log di Google Kubernetes Engine come Tipo di log.
  6. Fai clic su Ottieni service account. Google SecOps fornisce un account di servizio univoco che utilizza per importare i dati. In alternativa, puoi ottenere questo account di servizio in modo programmatico utilizzando l'API. Consulta Recupera service account.
  7. (Facoltativo) Configura il account di servizio. Per saperne di più, consulta Concedi l'accesso al service account Google SecOps.
  8. Fai clic su Avanti.

  9. In base alla configurazione di Cloud Storage che hai creato, specifica i valori per i seguenti campi:

    • URI del bucket di archiviazione

    • Opzione di eliminazione dell'origine

    • (Facoltativo) Includi prefissi. Al momento questa funzionalità è in anteprima limitata. Per le regole di sintassi e i dettagli della lista consentita, consulta Filtra gli oggetti per prefisso nei feed STS.

    Per scoprire di più su come configurare i bucket Cloud Storage, consulta Crea bucket.

  10. Fai clic su Avanti e poi su Invia.

Concedi l'accesso al account di servizio Google SecOps

  1. Nella console Google Cloud , vai alla pagina Bucket in Cloud Storage.

    Vai a Bucket

  2. Concedi al account di servizio l'accesso agli oggetti Cloud Storage pertinenti.

    • Per concedere l'autorizzazione in lettura a un file specifico, completa i seguenti passaggi:

      1. Seleziona il file e fai clic su Modifica accesso.
      2. Fai clic su Aggiungi entità.
      3. Nel campo Nuove entità, inserisci il nome del account di servizio Google SecOps.
      4. Assegna un ruolo che contenga l'autorizzazione in lettura al account di servizio Google SecOps. Ad esempio, Visualizzatore oggetti Storage (roles/storage.objectViewer). Questa operazione può essere eseguita solo se non hai attivato l'accesso uniforme a livello di bucket.
      5. Fai clic su Salva.

    • Per concedere l'autorizzazione in lettura a più file, concedi l'accesso a livello di bucket nel seguente modo:

      • Per "feedSourceType": "GOOGLE_CLOUD_STORAGE":

        1. Aggiungi il account di servizio Google SecOps come entità al tuo bucket di archiviazione e concedigli il ruolo IAM Storage Object Viewer (roles/storage.objectViewer).
        2. Se configuri il feed per eliminare i file di origine, devi aggiungere il account di servizio Google SecOps come entità nel bucket e concedergli il ruolo IAM Storage Object Admin (roles/storage.objectAdmin).

      • Per "feedSourceType": "GOOGLE_CLOUD_STORAGE_V2", concedi i seguenti ruoli:

        1. Concedi questo ruolo:

          • Storage Object Viewer (roles/storage.objectViewer) se il trasferimento avviene in un altro bucket Cloud Storage.

        2. Concedi uno dei seguenti ruoli, a seconda di ciò che selezioni per l'opzione di eliminazione dell'origine. Se selezioni In caso di esito positivo, concedi il ruolo Storage Legacy Bucket Writer. Se selezioni Mai, concedi il ruolo Storage Legacy Bucket Reader:

          • Storage Legacy Bucket Writer (roles/storage.legacyBucketWriter) se è richiesta l'autorizzazione per l'eliminazione degli oggetti.
          • Storage Legacy Bucket Reader (roles/storage.legacyBucketReader) se non è richiesta l'autorizzazione per l'eliminazione degli oggetti.

      • Per "feedSourceType": "GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN":

        1. Concedi uno di questi ruoli:

          • Storage Object Viewer (roles/storage.objectViewer) se il trasferimento avviene in un altro bucket Cloud Storage.
          • Storage Object Creator (roles/storage.objectCreator) se il trasferimento avviene in un file system.

        2. Concedi uno di questi ruoli:

          • Storage Legacy Bucket Writer (roles/storage.legacyBucketWriter) se è richiesta l'autorizzazione per l'eliminazione degli oggetti.
          • Storage Legacy Bucket Reader (roles/storage.legacyBucketReader) se non è richiesta l'autorizzazione per l'eliminazione degli oggetti.

Abilita l'accesso STS per Amazon S3 e Azure Storage

STS viene utilizzato dai seguenti feed di Google Cloud Storage per trasferire i dati dai blobstore di Amazon S3 e Azure Storage a Google SecOps:

  • Amazon S3 (V2)
  • Amazon SQS (V2)
  • Azure Blob Storage (V2)

STS invia richieste di trasferimento di dati ai servizi di archiviazione Amazon S3 e Azure da un insieme di intervalli di indirizzi IP STS definiti. Questi intervalli di indirizzi IP STS sono pubblicati nel seguente file JSON: Intervalli IP.

Per utilizzare questi tipi di origini dei feed STS, potrebbe essere necessario modificare le limitazioni di accesso IP per consentire a STS di accedere ai tuoi servizi di archiviazione Amazon S3 e Azure:

  1. Estrai gli intervalli IP più recenti dal file JSON.

    Ti consigliamo di leggere i dati di questo file JSON almeno una volta alla settimana per mantenere aggiornata la configurazione della sicurezza. Quando un nuovo intervallo viene aggiunto al file, il sistema attende almeno 7 giorni prima di utilizzarlo per le richieste di STS.

    Per uno script Python di esempio che recupera gli intervalli IP da un file JSON, consulta Indirizzi IP per i domini predefiniti.

  2. Confronta l'intervallo IP attuale creationTime con l'intervallo IP creationTime letto dal file JSON precedente. Se sono diversi, aggiorna le limitazioni di accesso IP negli archivi blob di Amazon S3 e Azure Storage.

    • Per Amazon S3

      Per aggiornare le limitazioni di accesso IP nel blobstore Amazon S3:

      Se il tuo progetto AWS utilizza limitazioni degli indirizzi IP per l'accesso allo spazio di archiviazione, devi aggiungere gli intervalli IP utilizzati dai worker STS all'elenco di IP consentiti.

      Per aggiungere questi intervalli come IP consentiti, utilizza il campo Condition in un bucket policy, come descritto nella documentazione di AWS S3: Gestione dell'accesso in base a indirizzi IP specifici.

    • Per Azure Storage

      Per aggiornare le limitazioni di accesso IP nel tuo blobstore di Azure Storage:

      Se limiti l'accesso alle tue risorse Azure utilizzando un firewall di Azure Storage, devi aggiungere gli intervalli IP utilizzati dai worker STS all'elenco di IP consentiti.

      Per aggiungere questi intervalli come IP consentiti, segui queste istruzioni: Configura i firewall e le reti virtuali di Azure Storage.

Configura un feed push Pub/Sub

Per configurare un feed push Pub/Sub, segui questi passaggi:

  1. Crea un feed push Pub/Sub.
  2. Specifica l'URL dell'endpoint in una sottoscrizione Pub/Sub.

Crea un feed push Pub/Sub

  1. Nel menu Google SecOps, seleziona Impostazioni e poi fai clic su Feed.
  2. Fai clic su Aggiungi nuovo.
  3. Nel campo Nome feed, inserisci un nome per il feed.
  4. Nell'elenco Tipo di origine, seleziona Google Cloud Pub/Sub Push.
  5. Seleziona il Tipo di log. Ad esempio, per creare un feed per Open Cybersecurity Schema Framework, seleziona Open Cybersecurity Schema Framework (OCSF) come Tipo di log.
  6. Fai clic su Avanti.
  7. (Facoltativo) Specifica i valori per i seguenti parametri di input:
    • Delimitatore di suddivisione: il delimitatore utilizzato per separare le righe di log. Puoi utilizzare solo \n.
    • Spazio dei nomi dell'asset: lo spazio dei nomi dell'asset.
    • Etichette di importazione: l'etichetta da applicare agli eventi di questo feed.
  8. Fai clic su Avanti.
  9. Controlla la nuova configurazione del feed di notizie nella schermata Finalizza e poi fai clic su Invia.
  10. Nella scheda Details (Dettagli), copia l'URL dell'endpoint del feed dal campo Endpoint Information (Informazioni endpoint). Questo URL dell'endpoint è necessario per creare una sottoscrizione push in Pub/Sub.
  11. (Facoltativo) Fai clic sul pulsante di attivazione/disattivazione Feed abilitato per disattivare il feed. Il feed è attivo per impostazione predefinita.
  12. Fai clic su Fine.

Specifica l'URL dell'endpoint

Dopo aver creato un feed push Pub/Sub, specifica l'URL dell'endpoint come segue:

  1. In Pub/Sub, crea una sottoscrizione push. Per saperne di più su come creare una sottoscrizione push, consulta Crea sottoscrizioni push.
  2. Specifica l'URL dell'endpoint, disponibile nel feed push di Pub/Sub Google Cloud .
  3. Seleziona Abilita autenticazione e seleziona un account di servizio.
  4. Disattiva le opzioni Push dell'annullamento del wrapping del payload e Push dell'annullamento del wrapping del payload per la scrittura dei metadati dei messaggi.

Configura un feed Amazon Data Firehose

Per configurare un feed Amazon Data Firehose, segui questi passaggi:

  1. Crea un feed Amazon Data Firehose e copia l'URL dell'endpoint e la chiave segreta.
  2. Crea una chiave API per l'autenticazione in Google SecOps. Puoi anche riutilizzare la chiave API esistente per autenticarti in Google SecOps.
  3. Specifica l'URL dell'endpoint in Amazon Data Firehose.

Crea un feed Amazon Data Firehose

  1. Nel menu Google SecOps, seleziona Impostazioni e poi fai clic su Feed.
  2. Fai clic su Aggiungi nuovo.
  3. Nel campo Nome feed, inserisci un nome per il feed.
  4. Nell'elenco Tipo di origine, seleziona Amazon Data Firehose.
  5. Seleziona il Tipo di log. Ad esempio, per creare un feed per Open Cybersecurity Schema Framework, seleziona Open Cybersecurity Schema Framework (OCSF) come Tipo di log.
  6. Fai clic su Avanti.
  7. (Facoltativo) Specifica i valori per i seguenti parametri di input:
    • Delimitatore di suddivisione: il delimitatore utilizzato per separare le righe di log. Puoi utilizzare solo \n.
    • Spazio dei nomi dell'asset: lo spazio dei nomi dell'asset.
    • Etichette di importazione: l'etichetta da applicare agli eventi di questo feed.
  8. Fai clic su Avanti.
  9. Controlla la nuova configurazione del feed di notizie nella schermata Finalizza e poi fai clic su Invia.
  10. Fai clic su Genera chiave segreta per generare una chiave segreta per autenticare questo feed.
  11. Copia e memorizza la chiave secret, poiché non potrai più visualizzarla. Puoi generare nuovamente una nuova chiave segreta, ma la rigenerazione della chiave segreta rende obsoleta la chiave segreta precedente.
  12. Nella scheda Dettagli, copia l'URL dell'endpoint del feed dal campo Informazioni sull'endpoint. Questo URL dell'endpoint è necessario quando specifichi le impostazioni di destinazione per il tuo stream di distribuzione in Amazon Data Firehose.
  13. (Facoltativo) Fai clic sul pulsante di attivazione/disattivazione Feed abilitato per disattivare il feed. Il feed è attivo per impostazione predefinita.
  14. Fai clic su Fine.

Crea una chiave API per il feed Amazon Data Firehose

Per creare una chiave API per il feed Amazon Data Firehose, segui questi passaggi:

  1. Vai alla pagina Credenziali della console Google Cloud .
  2. Fai clic su Crea credenziali e seleziona Chiave API.
  3. Limita l'accesso della chiave API all'API Chronicle.

Specifica l'URL dell'endpoint

In Amazon Data Firehose, specifica l'endpoint HTTPS e la chiave di accesso come segue:

  1. Aggiungi la chiave API all'URL dell'endpoint del feed e specifica questo URL come URL dell'endpoint HTTP nel seguente formato:

      ENDPOINT_URL?key=API_KEY

    Sostituisci quanto segue:

    • ENDPOINT_URL: l'URL dell'endpoint del feed.
    • API_KEY: la chiave API per l'autenticazione in Google SecOps.

  2. Per la chiave di accesso, specifica la chiave segreta che hai ottenuto durante la creazione del feed Amazon Data Firehose.

Configura un feed webhook HTTPS

Prima di iniziare:

Per configurare un feed webhook HTTPS:

  1. Crea un feed webhook HTTPS e copia l'URL dell'endpoint e la chiave segreta.
  2. Crea una chiave API specificata con l'URL dell'endpoint. Puoi anche riutilizzare la chiave API esistente per l'autenticazione in Google SecOps.
  3. Specifica l'URL dell'endpoint nella tua applicazione.

Invia più eventi in un'unica richiesta webhook

Il seguente esempio di codice mostra come formattare un singolo corpo della richiesta con più oggetti JSON separati da una nuova riga dopo l'elemento curl --location:

--header 'Content-Type: application/json' \
--header 'X-goog-api-key: API_KEY' \
--header 'X-Webhook-Access-Key: SECRET' \
--data '{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}
{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}'

Crea un feed webhook HTTPS

  1. Nel menu Google SecOps, seleziona Impostazioni e poi fai clic su Feed.
  2. Fai clic su Aggiungi nuovo.
  3. Nel campo Nome feed, inserisci un nome per il feed.
  4. Nell'elenco Tipo di origine, seleziona Webhook.
  5. Seleziona il Tipo di log. Ad esempio, per creare un feed per Open Cybersecurity Schema Framework, seleziona Open Cybersecurity Schema Framework (OCSF) come Tipo di log.
  6. Fai clic su Avanti.
  7. (Facoltativo) Specifica i valori per i seguenti parametri di input:
    • Delimitatore di suddivisione: il delimitatore utilizzato per separare le righe di log. Puoi utilizzare solo \n.
    • Spazio dei nomi dell'asset: lo spazio dei nomi dell'asset.
    • Etichette di importazione: l'etichetta da applicare agli eventi di questo feed.
  8. Fai clic su Avanti.
  9. Controlla la nuova configurazione del feed di notizie nella schermata Finalizza e poi fai clic su Invia.
  10. Fai clic su Genera chiave segreta per generare una chiave segreta per autenticare questo feed.
  11. Copia e memorizza la chiave secret, poiché non potrai più visualizzarla. Puoi generare nuovamente una nuova chiave segreta, ma la rigenerazione della chiave segreta rende obsoleta la chiave segreta precedente.

  12. Nella scheda Details (Dettagli), copia l'URL dell'endpoint del feed dal campo Endpoint Information (Informazioni endpoint). Devi specificare questo URL dell'endpoint nell'applicazione client.

    Scheda Dettagli del feed webhook che mostra il campo Informazioni sull'endpoint con un tooltip Copia negli appunti.

    Figura 1. Informazioni sull'endpoint del feed webhook

  13. (Facoltativo) Fai clic sul pulsante di attivazione/disattivazione Feed abilitato per disattivare il feed. Il feed è attivo per impostazione predefinita.

  14. Fai clic su Fine.

Crea una chiave API per il feed del webhook

  1. Vai alla pagina Credenziali della console Google Cloud .
  2. Fai clic su Crea credenziali e poi seleziona Chiave API.
  3. Limita l'accesso della chiave API all'API Chronicle.

Specifica l'URL dell'endpoint

  1. Nell'applicazione client, specifica l'endpoint HTTPS, disponibile nel feed del webhook.

  2. Attiva l'autenticazione specificando la chiave API e la chiave segreta come parte dell'intestazione personalizzata nel seguente formato:

    X-goog-api-key = API_KEY

    X-Webhook-Access-Key = SECRET

    Ti consigliamo di specificare la chiave API come intestazione anziché nell'URL. Se il tuo client webhook non supporta le intestazioni personalizzate, puoi specificare la chiave API e la chiave segreta utilizzando parametri di ricerca nel seguente formato:

      ENDPOINT_URL?key=API_KEY&secret=SECRET

    Sostituisci quanto segue:

    • ENDPOINT_URL: l'URL dell'endpoint del feed.
    • API_KEY: la chiave API per l'autenticazione in Google SecOps.
    • SECRET: la chiave segreta che hai generato per autenticare il feed.

Configura un feed API personalizzato

I feed API personalizzati di Google Security Operations (noti anche come connettori senza codice) consentono di importare la telemetria dalle API REST di terze parti utilizzando un modello flessibile basato sulla configurazione. Puoi configurare le estrazioni di dati definendo endpoint, autenticazione, strategie di impaginazione e gestione dello stato direttamente nella console.

Vantaggi principali

  • Integrazione accelerata: esegui l'onboarding di nuove origini di telemetria in pochi minuti tramite una procedura guidata senza attendere gli aggiornamenti del backend.
  • Checkpoint stateful: garantisce l'assenza di duplicazione dei dati e di log mancanti nei cicli di polling.
  • Fan-out padre-figlio: supporta i flussi di lavoro di rilevamento a due livelli, come l'elenco delle risorse e il recupero della telemetria associata.
  • Resilienza automatizzata e limitazione di frequenza: impedisce la limitazione dei fornitori e l'esaurimento delle quote. Per un'importazione affidabile e senza interruzioni, il feed API personalizzato gestisce automaticamente le risposte HTTP 429 con un backoff esponenziale, regola le richieste con limitazione di frequenza configurabile e scaglionamento dei ritardi delle attività e applica misure di sicurezza. Per saperne di più, consulta Limiti di frequenza e limitazione di banda.

Prerequisiti

Prima di creare un feed API personalizzato, verifica i seguenti prerequisiti:

  • Autorizzazioni: per creare o modificare i feed, devi disporre del ruolo Chronicle API Admin (roles/chronicle.admin) o Chronicle API Editor (roles/chronicle.editor).
  • Requisiti delle API di terze parti:
    • Un URL di base dell'API valido (deve utilizzare https://).
    • Credenziali API (chiave API, credenziali di autenticazione di base o ID client/secret OAuth 2.0).
    • Documentazione dell'API del fornitore che descrive in dettaglio i percorsi degli endpoint, i parametri di richiesta, le strutture di risposta JSON e i limiti di frequenza.
  • Accesso a Secret Manager: le credenziali vengono criptate e gestite in modo sicuro all'interno di Secret Manager. L'identità di servizio che esegue il connettore interagisce automaticamente con Secret Manager (roles/secretmanager.secretAccessor e roles/secretmanager.admin).

Configura un feed API personalizzato

Per configurare un feed API personalizzato, segui questi passaggi:

  1. Vai a Impostazioni SIEM > Feed.
  2. Fai clic su Aggiungi nuovo feed.
  3. Fai clic su Configura un singolo feed.
  4. Nel campo Nome feed, inserisci un nome descrittivo univoco (ad esempio 1Password-Audit-Events).
  5. Nell'elenco Tipo di origine, seleziona API personalizzata.
  6. Nell'elenco Tipo di log, seleziona il tipo di log Google SecOps di destinazione.
  7. Fai clic su Avanti.

  8. In Impostazioni generali, configura quanto segue:

    • URL di base: inserisci l'host principale (ad esempio, https://events.1password.com). Deve iniziare con https://. Non aggiungere percorsi secondari o barre finali.

    • Frequenza di polling: specifica la frequenza con cui la piattaforma controlla l'API per verificare la presenza di nuova telemetria, in minuti. Intervallo supportato: da 5 a 2880 minuti (valore predefinito: 15 minuti). Per i feed API standard (sequenziale), 10-15 minuti è lo standard; per i feed Elenco e dettagli (principale-secondario), sono consigliati 30-60 minuti per consentire l'esecuzione completa dell'attività di fan-out senza sovrapposizioni.

  9. In Autenticazione, seleziona uno dei metodi di autenticazione supportati, quindi configura i campi obbligatori:

    • Autenticazione di base:inserisci il Nome utente (identità dell'account API) e il Secret (ovvero la password o il token secret).
    • Credenziali client OAuth 2.0:esegui l'autenticazione utilizzando il flusso di concessione delle credenziali client OAuth 2.0. Google SecOps richiede, memorizza nella cache e aggiorna automaticamente i token di accesso di tipo Bearer prima di ogni ciclo di importazione. Inserisci l'endpoint del token OAuth (ad esempio https://auth.vendor.com/oauth/token), l'ID client OAuth e il client secret OAuth.
    • Intestazioni delle richieste con chiave API:autenticati utilizzando chiavi API personalizzate inserite nelle intestazioni delle richieste (il pattern REST aziendale più comune). Inserisci il Nome intestazione (ad esempio Authorization o X-API-Key) e il Valore intestazione (ad esempio Bearer <SECRET_TOKEN> o <SECRET_KEY>).
    • Parametri di query della chiave API:esegui l'autenticazione utilizzando chiavi API personalizzate inserite nei parametri di ricerca dell'URL. Inserisci il Nome del parametro di query (ad esempio api_key) e il valore parametro (ad esempio <SECRET_KEY>).

  10. Seleziona il modello di connettore utilizzato dalla tua API personalizzata:

    • API standard (sequenziale): un flusso di polling lineare in cui ogni polling si basa direttamente sullo stato di quello precedente. In questo modello, il sondaggio successivo utilizza un cursore, un token o un timestamp estratto dal sondaggio precedente per recuperare solo i nuovi dati. Seleziona questa scheda quando il fornitore fornisce un endpoint che restituisce direttamente i record degli eventi di telemetria (ad esempio 1Password, Okta, SentinelOne, GitHub o Slack).
    • Elenco e dettagli (padre-figlio): un flusso di scoperta a due livelli. Il feed effettua una chiamata iniziale (principale) per recuperare un elenco di risorse o oggetti (ad esempio, un elenco di ID utente o zone). Il feed genera quindi automaticamente chiamate di follow-up dipendenti (secondarie) per recuperare la telemetria dettagliata per ogni singola risorsa identificata. Seleziona questa scheda quando l'API del fornitore richiede un pattern di discovery a due livelli: prima chiama un endpoint per recuperare un elenco dinamico di entità (ad esempio zone, account, progetti, dispositivi) e poi esegue richieste di dettagli di follow-up per entità per recuperare la telemetria (ad esempio Cloudflare, AWS CloudWatch o Tenable).

  11. Se hai selezionato API standard (sequenziale), segui questi passaggi:

    1. In Endpoint API, configura i seguenti parametri per definire il percorso tecnico e la frequenza di pacing per la richiesta:
      • Percorso endpoint: il percorso API specifico aggiunto all'URL di base (ad esempio, /api/v1/auditevents). Definisce la risorsa di telemetria esatta su cui eseguire la query.
      • Metodo HTTP: seleziona GET per recuperare i dati utilizzando parametri di ricerca dell'URL o POST per inviare un payload di ricerca o un corpo del filtro.
    2. Corpo della richiesta: per le richieste POST, fornisci il payload dei dati JSON. Puoi incorporare variabili di checkpoint dinamiche come {"limit": 100, "start_time": "{{.last_timestamp}}"}.
    3. Numero massimo di richieste al minuto: inserisci il numero massimo di richieste da inviare al minuto. Si tratta di un limitatore di frequenza lato client per rispettare i limiti di frequenza dell'API del fornitore (valore predefinito: 5 RPM = 1 richiesta ogni 12 secondi). Questa impostazione impedisce l'esaurimento della quota durante l'impaginazione di più pagine.
    4. (Facoltativo) In Intestazioni personalizzate, configura Nome intestazione e Valore, quindi fai clic su Aggiungi per definire le intestazioni HTTP specializzate richieste dall'API di destinazione (ad esempio Content-Type: application/json, Accept: application/json).
    5. (Facoltativo) In Parametri di query, configura Chiave e Valore, quindi fai clic su Aggiungi per specificare filtri o opzioni aggiuntivi da aggiungere alla stringa di query dell'URL (ad esempio count=1000, status=active) o per associare variabili di modello dinamiche (ad esempio start={{.last_run_time}}).
    6. In Strategia di impaginazione: seleziona il meccanismo di impaginazione richiesto dall'API di terze parti per gestire i set di risultati di più pagine, quindi configura i campi obbligatori:
      • Nessuno: recupera i dati in una singola richiesta senza impaginazione.
      • Impaginazione dei token: utilizza i token (chiavi personalizzate) per visualizzare la pagina successiva. Inserisci il percorso JSON del token della pagina successiva (ad esempio meta.next_cursor) e il nome del parametro di query di paginazione del token (ad esempio cursor).
      • Paginazione dei link: segui gli URL forniti nella risposta per ottenere più dati. Inserisci il percorso JSON del link alla pagina successiva (ad esempio, links.next o @odata.nextLink).
      • Offset Pagination: salta un numero impostato di record per ottenere il set successivo. Inserisci il nome del parametro di query di offset (ad esempio, offset).
      • Impaginazione con numeri di pagina: vai al numero di pagina sequenziale successivo. Inserisci il nome del parametro di query del numero di pagina (ad esempio, page).

    7. In Checkpointing, configura le impostazioni che consentono al connettore di ricordare dove si era interrotto tra i cicli di polling ricorrenti:

      • Strategia: scegli una delle seguenti strategie e configura i campi obbligatori:
        • Nessuno:recupera tutti i dati disponibili senza monitorare l'avanzamento tra i cicli.
        • Timestamp più recente:monitora il timestamp del record più recente. Inserisci il percorso JSON del valore del checkpoint (ad esempio, timestamp o event_time) e la variabile del checkpoint (ad esempio, last_run_time, a cui si fa riferimento nei sondaggi successivi come {{.last_run_time}}).
        • Record più recente: monitora l'ID record più alto per recuperare solo i nuovi record. Inserisci il percorso JSON del valore del checkpoint (ad esempio id o event_id) e la variabile del checkpoint (ad esempio last_id, a cui viene fatto riferimento come {{.last_id}}).
        • Token iteratore: utilizza i token di continuazione persistenti forniti dall'API. Inserisci il percorso JSON del valore del checkpoint e la variabile del checkpoint (ad esempio, iterator_token, a cui viene fatto riferimento come {{.iterator_token}}).

    8. In Mappatura delle risposte, fornisci le regole che indicano alla piattaforma come individuare ed estrarre i log:

      • Percorso JSON dei dati target: inserisci il percorso esatto nel payload della risposta dell'API in cui si trova l'elenco delle voci di log target. Per gli array con wrapping di oggetti (ad esempio {"items": [...]}), inserisci items. Per le API che restituiscono direttamente un array JSON principale (ad esempio [{...}, {...}]), lascia questo campo completamente vuoto ([]).

  12. Se hai selezionato Elenco e dettagli (padre-figlio), segui questi passaggi:

    1. Richiesta padre (rilevamento): configura l'endpoint che restituisce un elenco di elementi:
      1. In Endpoint API, configura i seguenti parametri per definire il percorso tecnico e la frequenza di pacing per la richiesta:
        • Percorso endpoint: il percorso API specifico aggiunto all'URL di base (ad esempio, /api/v1/auditevents). Definisce la risorsa di telemetria esatta su cui eseguire la query.
        • Metodo HTTP: seleziona GET per recuperare i dati utilizzando parametri di ricerca dell'URL o POST per inviare un payload di ricerca o un corpo del filtro.
        • Corpo della richiesta: per le richieste POST, fornisci il payload dei dati JSON. Puoi incorporare variabili di checkpoint dinamiche come {"limit": 100, "start_time": "{{.last_timestamp}}"}.
      2. Numero massimo di richieste al minuto: inserisci il numero massimo di richieste da inviare al minuto. Si tratta di un limitatore di frequenza lato client per rispettare i limiti di frequenza dell'API del fornitore (valore predefinito: 5 RPM = 1 richiesta ogni 12 secondi). Questa impostazione impedisce l'esaurimento della quota durante l'impaginazione di più pagine.
      3. (Facoltativo) In Intestazioni personalizzate, configura Nome intestazione e Valore, quindi fai clic su Aggiungi per definire le intestazioni HTTP specializzate richieste dall'API di destinazione (ad esempio Content-Type: application/json, Accept: application/json).
      4. (Facoltativo) In Parametri di query, configura Chiave e Valore, quindi fai clic su Aggiungi per specificare filtri o opzioni aggiuntivi da aggiungere alla stringa di query dell'URL (ad esempio count=1000, status=active) o per associare variabili di modello dinamiche (ad esempio start={{.last_run_time}}).
      5. In Strategia di impaginazione: seleziona il meccanismo di impaginazione richiesto dall'API di terze parti per gestire i set di risultati di più pagine, quindi configura i campi obbligatori:
        • Nessuno: recupera i dati in una singola richiesta senza impaginazione.
        • Impaginazione dei token: utilizza i token (chiavi personalizzate) per visualizzare la pagina successiva. Inserisci il percorso JSON del token della pagina successiva (ad esempio meta.next_cursor) e il nome del parametro di query di paginazione del token (ad esempio cursor).
        • Paginazione dei link: segui gli URL forniti nella risposta per ottenere più dati. Inserisci il percorso JSON del link alla pagina successiva (ad esempio, links.next o @odata.nextLink).
        • Offset Pagination: salta un numero impostato di record per ottenere il set successivo. Inserisci il nome del parametro di query di offset (ad esempio, offset).
        • Impaginazione con numeri di pagina: vai al numero di pagina sequenziale successivo. Inserisci il nome del parametro di query del numero di pagina (ad esempio, page).
      6. In Checkpointing, configura le impostazioni che consentono al connettore di ricordare dove si era interrotto tra i cicli di polling ricorrenti:
        • Strategia: scegli una delle seguenti strategie e configura i campi obbligatori:
          • Nessuno:recupera tutti i dati disponibili senza monitorare l'avanzamento tra i cicli.
          • Timestamp più recente:monitora il timestamp del record più recente. Inserisci il percorso JSON del valore del checkpoint (ad esempio, timestamp o event_time) e la variabile del checkpoint (ad esempio, last_run_time, a cui si fa riferimento nei sondaggi successivi come {{.last_run_time}}).
          • Record più recente: monitora l'ID record più alto per recuperare solo i nuovi record. Inserisci il percorso JSON del valore del checkpoint (ad esempio id o event_id) e la variabile del checkpoint (ad esempio last_id, a cui viene fatto riferimento come {{.last_id}}).
          • Token iteratore: utilizza i token di continuazione persistenti forniti dall'API. Inserisci il percorso JSON del valore del checkpoint e la variabile del checkpoint (ad esempio, iterator_token, a cui viene fatto riferimento come {{.iterator_token}}).
    2. Estrazione dei dati (il bridge): configura quanto segue:
      • Percorso JSON dell'identificatore dell'elemento: il campo specifico nella risposta principale che identifica in modo univoco una singola entità (ad esempio id o zone_id). Il connettore estrae questo identificatore da ogni elemento nell'array principale.
      • Nome variabile modello:specifica un nome di variabile personalizzato per contenere l'ID estratto (ad esempio, zone_id). L'interfaccia utente mostra un badge dinamico: Utilizza {{.zone_id}} nella richiesta secondaria di seguito.
    3. Richiesta figlio (dettagli): configura l'endpoint che restituisce i log dettagliati per ogni elemento:
      1. In Endpoint API, configura i seguenti parametri per definire il percorso tecnico e la frequenza di invio della richiesta:
        • Percorso endpoint: il percorso API specifico aggiunto all'URL di base (ad esempio, /client/v4/zones/{{.zone_id}}/logs/received). Definisce la risorsa di telemetria esatta su cui eseguire la query.
        • Metodo HTTP: seleziona GET per recuperare i dati utilizzando parametri di ricerca dell'URL o POST per inviare un payload di ricerca o un corpo del filtro.
        • Corpo della richiesta: per le richieste POST, fornisci il payload dei dati JSON. Puoi incorporare variabili di checkpoint dinamiche come {"limit": 100, "start_time": "{{.last_timestamp}}"}.
      2. Numero massimo di richieste al minuto: inserisci il numero massimo di richieste da inviare al minuto. Si tratta di un limitatore di frequenza lato client per rispettare i limiti di frequenza dell'API del fornitore (valore predefinito: 5 RPM = 1 richiesta ogni 12 secondi). Questa impostazione impedisce l'esaurimento della quota durante l'impaginazione di più pagine.
      3. (Facoltativo) In Intestazioni personalizzate, configura Nome intestazione e Valore, quindi fai clic su Aggiungi per definire le intestazioni HTTP specializzate richieste dall'API di destinazione (ad esempio Content-Type: application/json, Accept: application/json).
      4. (Facoltativo) In Parametri di query, configura Chiave e Valore, quindi fai clic su Aggiungi per specificare filtri o opzioni aggiuntivi da aggiungere alla stringa di query dell'URL (ad esempio count=1000, status=active) o per associare variabili di modello dinamiche (ad esempio start={{.last_run_time}}).
      5. In Strategia di impaginazione: seleziona il meccanismo di impaginazione richiesto dall'API di terze parti per gestire i set di risultati di più pagine, quindi configura i campi obbligatori:
        • Nessuno: recupera i dati in una singola richiesta senza impaginazione.
        • Impaginazione dei token: utilizza i token (chiavi personalizzate) per visualizzare la pagina successiva. Inserisci il percorso JSON del token della pagina successiva (ad esempio meta.next_cursor) e il nome del parametro di query di paginazione del token (ad esempio cursor).
        • Paginazione dei link: segui gli URL forniti nella risposta per ottenere più dati. Inserisci il percorso JSON del link alla pagina successiva (ad esempio, links.next o @odata.nextLink).
        • Offset Pagination: salta un numero impostato di record per ottenere il set successivo. Inserisci il nome del parametro di query di offset (ad esempio, offset).
        • Impaginazione con numeri di pagina: vai al numero di pagina sequenziale successivo. Inserisci il nome del parametro di query del numero di pagina (ad esempio, page).
      6. In Checkpointing, configura le impostazioni che consentono al connettore di ricordare dove si era interrotto tra i cicli di polling ricorrenti:
        • Strategia: scegli una delle seguenti strategie e configura i campi obbligatori:
          • Nessuno:recupera tutti i dati disponibili senza monitorare l'avanzamento tra i cicli.
          • Timestamp più recente:monitora il timestamp del record più recente. Inserisci il percorso JSON del valore del checkpoint (ad esempio, timestamp o event_time) e la variabile del checkpoint (ad esempio, last_run_time, a cui si fa riferimento nei sondaggi successivi come {{.last_run_time}}).

  13. Configura le seguenti impostazioni di Pianificazione ed etichette:

    • Frequenza di polling: seleziona un intervallo standard (ad esempio 5m, 1h).
    • Namespace: tag organizzativo facoltativo.
    • Etichette di importazione: coppie chiave-valore per l'RBAC dei dati.

  14. Fai clic su Invia. Google SecOps esegue un controllo automatico di convalida delle credenziali e degli endpoint. Se la convalida ha esito positivo, il feed inizia il polling.

Configurazione di esempio 1: eventi di controllo di 1Password (modello API standard (sequenziale))

La seguente configurazione JSON dichiarativa mostra un modello API standard (sequenziale), con checkpoint basato su cursore per 1Password:

{
  "base_url": "https://events.1password.com",
  "polling_frequency": 15,
  "header_auth": {
    "header_key_values": [
      {
        "key": "Authorization",
        "value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
      }
    ]
  },
  "primary_request": {
    "request_settings": {
      "endpoint_path": "/api/v1/auditevents",
      "http_method": "POST",
      
      "request_body": "{\"limit\": 1000, \"start_time\": \"{{.last_run_time}}\"}",
      
      "custom_headers": [
        {
          "key": "Content-Type",
          "value": "application/json"
        }
      ],
      "max_requests_per_minute": 5
    },
    "pagination_strategy": {
      "token": {
        "next_page_token_json_path": "additional_items_url",
        "query_param": "cursor"
      }
    },
    "checkpointing": {
      "latest_timestamp_strategy": {
        "checkpoint_value_path": "timestamp",
        "checkpoint_variable": "last_run_time"
      }
    },
    "response_mapping": {
      "target_data_path": ["items"]
    }
  }
}

Configurazione di esempio concreta 2: telemetria della zona Cloudflare (modello Elenco e dettagli (padre-figlio))

La seguente configurazione JSON dichiarativa mostra un modello di fan-out Elenco e dettagli (principale-secondario) per Cloudflare:

{
 "base_url": "https://api.cloudflare.com",
 "polling_frequency": 30,
 "header_auth": {
   "header_key_values": [
     {
       "key": "Authorization",
       "value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
     }
   ]
 },

 "primary_request": {
   "request_settings": {
     "endpoint_path": "/client/v4/zones",
     "http_method": "GET"
   },
   "response_mapping": {
     "target_data_path": ["result"]
   },
   "pagination_strategy": {
     "none": {}
   },
   "checkpointing": {
     "none_strategy": {}
   },
   "dependent_requests_config": {
     "item_id_json_path": "id",
     "item_id_variable": "zone_id",
     "dependent_requests": [
       {
         "request_settings": {
           "endpoint_path": "/client/v4/zones/{{.zone_id}}/logs/received",
           "http_method": "GET",
           "query_parameters": [
             {
               "key": "start",
               "value": "{{.last_run_time}}"
             },
             {
               "key": "count",
               "value": "1000"
             }
           ],
           "max_requests_per_minute": 5
         },

         "pagination_strategy": {
           "none": {}
         },
         "checkpointing": {
           "latest_timestamp_strategy": {
             "checkpoint_value_path": "EdgeStartTimestamp",
             "checkpoint_variable": "last_run_time"
           }
         },
         "response_mapping": {
           "target_data_path": []
         }
       }
     ]
   }
 }
}

Best practice per le API personalizzate

  • Indicazioni sulla frequenza di polling:
    • Inizia con intervalli di polling moderati: imposta l'intervallo di polling iniziale su 15 o 30 minuti per gli endpoint con volumi elevati per osservare il comportamento della quota API del fornitore prima di scendere a 5 minuti.
    • Ottimizza per il fan-out ad alto volume: per i feed Principale-secondario (elenco e dettagli) che rilevano decine o centinaia di risorse, Google consiglia vivamente di impostare la Frequenza di polling su 30-60 minuti per consentire il completamento di tutte le attività secondarie con pacing prima dell'inizio del ciclo di rilevamento successivo.
  • Convalida i percorsi di acquisizione: utilizza la documentazione del fornitore o gli strumenti di test delle API per confermare il nome esatto del campo JSON per i timestamp prima di configurare il checkpoint dello stato.
  • Scomponi le API con più elementi secondari: se un'API di terze parti richiede il recupero di avvisi e log di controllo per un singolo elenco di utenti, crea due feed secondari singoli separati (uno per gli avvisi e uno per i log di controllo) per mantenere un isolamento ottimale.

Misure di salvaguardia per la limitazione di frequenza e il throttling

Per evitare che le configurazioni dei feed dei clienti sovraccarichino le quote dei fornitori di terze parti o monopolizzino le risorse di sistema, il tipo di feed API personalizzata implementa le seguenti misure di protezione automatizzate:

  • Ritmo delle richieste configurabile (limitazione di frequenza): le richieste HTTP in uscita vengono ritmate automaticamente per evitare di superare i limiti di frequenza del fornitore. La frequenza di pacing predefinita è di 5 richieste al minuto (1 richiesta ogni 12 secondi). Puoi ottimizzare questo valore per endpoint utilizzando il campo Numero massimo di richieste al minuto nelle impostazioni dell'endpoint in modo che corrisponda alle quote API pubblicate del tuo fornitore.
  • Limite di richieste secondarie:per i feed principali-secondari (elenco e dettagli), una richiesta di discovery può inviare fino a 500 richieste secondarie per ciclo di polling.
  • Profondità di fan-out a livello singolo: il connettore applica rigorosamente una profondità di fan-out massima di 1 livello (rilevamento principale → dettagli secondari). Le richieste dipendenti nidificate (chiamate di livello inferiore) non sono supportate.
  • Limite delle dimensioni del payload della risposta:la dimensione massima consentita della risposta HTTP per una singola richiesta o pagina è di 50 MB. Se un'API non impaginata restituisce una risposta superiore a 50 MB, il recupero non andrà a buon fine e verrà visualizzato un errore di risorsa esaurita. Per evitare questo problema, configura sempre parametri di ricerca di paginazione (come limit o page_size) per recuperare i record in batch più piccoli.
  • Backoff HTTP 429 automatico: se una risposta dell'API di un fornitore di terze parti è HTTP 429 (Troppe richieste), Google SecOps acquisisce automaticamente lo stato e avvia un periodo di backoff esponenziale, mettendo in pausa l'esecuzione delle attività fino a quando la finestra della quota del fornitore non si riempie.

Limitazioni delle API personalizzate

Quando pianifichi i percorsi di acquisizione, tieni presente che il tipo di feed API personalizzata presenta le seguenti limitazioni:

  • Supporto JSON rigoroso:sono supportate solo le risposte dell'API JSON. Altri formati come XML, CSV, Parquet e Avro non sono supportati.
  • Nessuna firma dinamica delle richieste: le API che richiedono firme crittografiche dinamiche per richiesta non sono supportate (ad esempio AWS SigV4, Akamai o Oracle OCI).
  • Nessuna autenticazione in più passaggi: le API che richiedono una chiamata di accesso iniziale tramite programmazione per scambiare le credenziali con un token di sessione temporaneo (come Saviynt) prima del polling non sono supportate.
  • Nessuna importazione di WebSocket o push: i feed API personalizzati supportano il polling di pull HTTPS standard. Le connessioni di streaming persistenti (WebSocket) e i webhook in entrata non sono supportati.
  • Nessun mutual TLS (mTLS): l'autenticazione deve basarsi su chiavi API, autenticazione di base o credenziali client OAuth 2.0 standard. Gli handshake dei certificati lato client non sono supportati.

Risolvi i problemi relativi ai feed API personalizzati

Per esaminare gli errori dei feed API personalizzati in Esplora log di Cloud Logging, utilizza le seguenti query:

resource.type="gce_instance" OR resource.type="generic_task"
jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"

Sostituisci FEED_ID con l'ID del feed.

Per filtrare in modo specifico le richieste HTTP non riuscite, utilizza la seguente query:

jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"
jsonPayload.http_status_code >= 400

Sostituisci FEED_ID con l'ID del feed.

Modalità di errore comuni e soluzioni

Sintomo / errore Causa principale Soluzione / Rimedio
HTTP 401 Non autorizzato / HTTP 403 Non consentito Chiave API, password o credenziali OAuth scadute o non valide. Modifica il feed, inserisci di nuovo credenziali valide e fai clic su Invia.
HTTP 404 - Non trovato URL di base o modello di percorso dell'endpoint errato. Ispeziona l'endpoint nella documentazione dell'API del fornitore. Assicurati che l'URL di base termini in modo corretto e che il percorso dell'endpoint inizi con /.
HTTP 429 Too Many Requests (Troppe richieste) Superamento dei limiti di frequenza delle richieste API del fornitore. Aumenta la frequenza di polling o riduci il parametro limit nei parametri di ricerca.
Errore di estrazione JSON (items_path vuoto) Mancata corrispondenza nel percorso di configurazione della risposta. Verifica la struttura del payload della risposta dell'API e aggiorna il percorso JSON dei dati di destinazione.
Acquisizione dei dati duplicati Timestamp di configurazione dello stato o percorso dell'estrattore ID non valido. Controlla il nome del campo del record di log per il timestamp e aggiorna il percorso dell'estrattore.

Gestisci i feed

Dopo aver configurato i feed di dati, utilizza gli strumenti di gestione per monitorare lo stato dell'importazione, modificare i parametri esistenti e gestire il ciclo di vita dei feed. Questa sezione descrive come interpretare gli stati dei feed ed eseguire le attività di manutenzione essenziali per garantire la visibilità continua dei dati.

La pagina Feed fornisce diversi strumenti per aiutarti a navigare e organizzare l'elenco dei feed configurati:

  • Ricerca: utilizza la barra di ricerca per trovare un feed in base al nome del feed, all'ID feed o al tipo di origine.

  • Filtro: fai clic sull'icona del filtro per restringere l'elenco in base ad attributi specifici del feed.

  • Scarica CSV: fai clic su Scarica come CSV per esportare l'elenco attuale dei feed in un file CSV.

  • Impaginazione: utilizza i controlli di impaginazione per:

    • Modifica il numero di Righe per pagina.

    • Naviga tra le varie pagine dei feed utilizzando le schede e le frecce della pagina.

  • Ora dell'ultimo aggiornamento: visualizza il timestamp per vedere quando è stato aggiornato l'elenco dei feed l'ultima volta.

Visualizza i feed configurati

La pagina Feed mostra tutti i feed che hai configurato.

  1. Vai a Impostazioni SIEM > Feed. La pagina principale mostra tutti i feed configurati.
  2. Tieni il puntatore su ogni riga per visualizzare il menu more_vert Altro.
  3. Nel menu puoi visualizzare i dettagli del feed, modificarlo, disattivarlo o eliminarlo.

Monitora lo stato del feed

Puoi monitorare lo stato del feed nella pagina iniziale Feed, dove i feed possono avere i seguenti stati:

  • Attivo: il feed è configurato e pronto per importare i dati nel tuo account Google SecOps.

  • InProgress: Google SecOps tenta di estrarre i dati dalla terza parte configurata.

  • Completata: i dati sono stati recuperati correttamente da questo feed.

  • Archiviato: feed disattivato.

  • Non riuscito: il feed non riesce a recuperare i dati. Questo problema è probabilmente dovuto a un problema di configurazione. Fai clic sulla domanda per visualizzare l'errore di configurazione. Dopo aver corretto l'errore e inviato nuovamente il feed, torna alla pagina Feed per verificare se il feed ora funziona.

Modifica i feed esistenti

Nella pagina Feed, puoi modificare un feed esistente nel seguente modo:

  1. Tieni il puntatore su un feed esistente e fai clic su more_vert nella colonna a destra.

  2. Fai clic su Modifica feed. Ora puoi modificare i parametri di input del feed e inviarlo nuovamente a Google SecOps, che tenterà di utilizzare il feed aggiornato.

Attiva (riprendi) e disattiva (metti in pausa) i feed

Quando disattivi un feed, Google SecOps interrompe l'importazione di nuovi dati da quell'origine. Per interrompere immediatamente l'importazione dati, devi eliminare il feed. I trasferimenti attivi o limitati esistenti continuano fino al completamento. Quando riattivi il feed, Google SecOps può recuperare i dati che non sono stati acquisiti mentre il feed era disattivato. Questa funzionalità è chiamata "backfillability".

Nella colonna Stato, i feed attivati sono etichettati come Attivo, In corso, Completato o Non riuscito. I campi disabilitati sono etichettati come Archiviati. Per una descrizione, consulta Monitora lo stato del feed.

Nella pagina Feed, puoi attivare (ripristinare) o disattivare (mettere in pausa) uno dei feed esistenti:

  1. Tieni il puntatore su un feed esistente e fai clic su more_vert nella colonna a destra.

  2. (Facoltativo) Fai clic sul pulsante di attivazione/disattivazione Feed attivato per attivare il feed.

  3. (Facoltativo) Fai clic sul pulsante di attivazione/disattivazione Disattiva feed per disattivare il feed. Il feed è ora etichettato come Archiviato.

Recupero dei dati quando riattivi i feed (backfillability)

La capacità di Google SecOps di eseguire il backfill dei dati dipende dal fatto che il feed sia basato su pull (supportato) o su push (non supportato).

Feed basati su pull

Con questi feed, Google SecOps estrae i dati da origini esterne. I feed pull includono:

  • Bucket di archiviazione cloud, come Amazon S3, Google Cloud Storage, Azure Blob Storage
  • Server SFTP

  • API di terze parti, come Microsoft 365, Okta, Proofpoint

    Quando riattivi i feed basati su pull, Google SecOps può recuperare i dati generati mentre il feed era disattivato.

Feed basati su push

Con questi feed, i sistemi esterni "inviano" i dati a Google SecOps. I feed push includono:

  • Webhook HTTPS
  • Google Cloud Pub/Sub
  • Amazon Kinesis Data Firehose
  • Importazioni dirette di API/agenti, come Bindplane

Google SecOps non può avviare automaticamente il backfill dati dai feed basati su push. Mentre il feed è disattivato e il tuo sistema invia dati, Google SecOps invia un errore HTTP 403 Forbidden o un errore 4xx generico.

Se il tuo sistema non archivia e non riprova a inviare i dati a Google SecOps, i dati andranno persi. Inoltre, se il sistema è impostato su "drop on failure" (interruzione in caso di errore) o cancella il buffer, i dati vengono persi definitivamente per il periodo corrispondente. Per evitare la perdita di dati, devi configurare il sistema in modo che memorizzi nel buffer e invii nuovamente i dati una volta riattivato un feed. Google SecOps può quindi importare i dati mancanti quando il feed viene ripreso.

Considerazioni sul backfill

  • Limiti del sistema di origine: la quantità di dati storici di cui Google SecOps può eseguire il backfill dai feed basati su pull è limitata dal periodo di conservazione dei dati del sistema di origine e da ciò che consente la sua API. Ad esempio, alcune API forniscono l'accesso solo ai dati degli ultimi sette giorni.
  • Buffer di Google SecOps:per il recupero automatico, il buffer interno di Google SecOps per i feed basati su pull conserva i dati per un massimo di 90 giorni, dopodiché i dati vengono eliminati.
  • Limitazioni dei tenant: i tenant non paganti, ad esempio i proof of concept, potrebbero avere limitazioni sul backfill dei dati meno recenti.
  • Quote di acquisizione dei dati: per evitare di influire sull'importazione dati in tempo reale, i dati di backfill vengono elaborati con una priorità inferiore rispetto ai dati in tempo reale. Anche il backfill dati basato su pull è soggetto a limitazione di frequenza, in genere a un terzo (33%) del limite di burst del tenant per tipo di log. In questo modo, i feed critici basati su push, come gli agenti EDR, non vengono influenzati negativamente.
  • Limitazione di frequenza dinamica: se il backfill consuma tutta la quota di pull disponibile, l'importazione viene messa in pausa per il resto dell'intervallo di cinque minuti e riprende automaticamente quando l'intervallo viene riavviato.
  • Cloud Storage:puoi utilizzare le impostazioni del feed per controllare il backfill, ad esempio i filtri per i file nuovi o aggiornati o i filtri per l'intervallo di date, come "Età massima del file".
  • Arretrati di grandi dimensioni:se un arretrato di grandi dimensioni di un feed basato su pull causa problemi al momento della riattivazione, puoi contattare l'Assistenza Google per cancellarlo. Ciò significa che il feed inizierà a importare solo i nuovi dati in futuro e i dati mancanti non verranno recuperati.
  • Modifica dei feed disattivati: qualsiasi modifica alla configurazione apportata a un feed mentre è disattivato verrà applicata non appena il feed verrà riattivato.

Elimina i feed

Nella pagina Feed, puoi anche eliminare un feed esistente:

  1. Tieni il puntatore su un feed esistente e fai clic su more_vert nella colonna a destra.

  2. Fai clic su Elimina feed. Si apre la finestra ELIMINA FEED. Per eliminare definitivamente il feed, fai clic su Sì, eliminalo.

Per i feed API personalizzati, viene visualizzata una finestra di dialogo con una casella di controllo facoltativa: Elimina i dati di backlog in attesa:

  • Deselezionata (impostazione predefinita): la configurazione e le credenziali del feed vengono eliminate, ma i dati di backlog in coda possono essere elaborati fino all'importazione.
  • Selezionata:la configurazione del feed, le credenziali e tutti i dati in attesa nel backlog vengono rimossi definitivamente.

Controlla la frequenza di importazione

Quando la frequenza di importazione dati per un tenant raggiunge una determinata soglia, Google Security Operations limita la frequenza di acquisizione per i nuovi feed di dati per impedire che un'origine con una frequenza di acquisizione elevata influisca sulla frequenza di acquisizione di un'altra origine dati. In questo caso, si verifica un ritardo, ma non vengono persi dati. La soglia è determinata dal volume di importazione e dalla cronologia di utilizzo del tenant.

Puoi richiedere un aumento del limite di frequenza contattando l'assistenza clienti Google Cloud.

Risolvi i problemi relativi ai feed non riusciti

  • Nella pagina Feed puoi visualizzare dettagli come il tipo di origine, il tipo di log, l'ID feed e lo stato dei feed esistenti, come segue:

    1. Tieni il puntatore su un feed esistente e fai clic su more_vert nella colonna a destra.

    2. Fai clic su Visualizza feed. Viene visualizzata una finestra di dialogo con i dettagli del feed. Per un feed non riuscito, puoi trovare i dettagli dell'errore in Dettagli > Stato.

  • Per un feed non riuscito, i dettagli includono la causa dell'errore e i passaggi per risolverlo.

  • Consulta la tabella Errori di origine e importazione per i messaggi di errore che potresti riscontrare quando utilizzi i feed di dati.

  • Per un'analisi dettagliata e la risoluzione dei problemi relativi all'attività del feed, puoi visualizzare i log in Cloud Logging. Consulta Analizza l'attività dei feed con Cloud Logging.

  • Errore: Generic::failed_precondition:

    Errore: Generic::failed_precondition: include_prefixes is not enabled for this customer

    Questo errore si verifica quando salvi un feed STS con valori nel campo Includi prefissi (include_prefixes), ma il tuo tenant Google SecOps non è incluso nella lista consentita per il filtro basato sui prefissi.

    Per risolvere questo errore, esegui una delle seguenti operazioni:

    1. Rimuovi tutti i prefissi dal campo Includi prefissi (include_prefixes) e salva di nuovo il feed per importare l'intero bucket o container.
    2. Contatta il tuo team dedicato all'account Google Cloud , il Technical Account Manager (TAM) o l'assistenza clienti Google Cloud per richiedere l'accesso alla funzionalità include_prefixes (enable_feed_include_prefixes) per il tuo tenant. Per saperne di più, consulta Filtra gli oggetti per prefisso nei feed STS.

Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.