Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

GitSync

Requisito obbligatorio della piattaforma:a partire dalla versione 53.0 di GitSync, questa integrazione comunica con Google Security Operations esclusivamente tramite le API REST di Chronicle utilizzando l'autenticazione IAM automatizzata. Il supporto per gli endpoint API della piattaforma Google SecOps legacy (*.siemplify-soar.com/api/) è stato rimosso e tutte le azioni e i job GitSync non riescono sulle istanze non migrate.

Devi completare la migrazione della piattaforma prima di eseguire l'upgrade o la configurazione di GitSync. Per le istruzioni per la migrazione, consulta Migrazione dell'ambiente abilitato per l'API Chronicle.

GitSync è un'integrazione creata per Google SecOps che sincronizza asset e componenti di automazione della sicurezza con un repository Git esterno (come GitHub, GitLab o Bitbucket). Facilita la sincronizzazione bidirezionale dei contenuti, fornendo il controllo della versione automatico, il backup della configurazione e la promozione cross-environment durante il ciclo di vita delle operazioni di sicurezza. Tieni presente che GitSync è progettato per eseguire il backup e la migrazione degli asset tra ambienti correlati (come sviluppo, gestione temporanea e produzione), anziché per distribuire gli asset in sistemi non correlati in cui gli identificatori di database interni potrebbero causare conflitti.

Casi d'uso

L'integrazione GitSync supporta i seguenti casi d'uso principali:

Controllo della versione e auditabilità (sicurezza come codice): monitora le modifiche, esamina le diff e mantieni una cronologia delle versioni completa delle modifiche apportate a playbook, connettori, integrazioni e impostazioni di sistema.
Promozione multiarea (pipeline CI/CD): promuovi playbook, mappature dell'ontologia e impostazioni di integrazione in modo sistematico dagli ambienti di sviluppo e staging alla produzione tramite richieste di pull e unioni di rami.
Backup e disaster recovery: ripristina playbook e configurazioni della piattaforma eliminati, danneggiati o configurati in modo errato per errore direttamente dal repository Git.
Standardizzazione cross-environment: distribuisci playbook standardizzati, famiglie di visualizzazioni personalizzate e definizioni di connettori in ambienti Google SecOps correlati da un repository centralizzato.
Isolamento di ramificazioni e staging: testa playbook sperimentali e rami di funzionalità in ambienti dedicati senza influire sui workflow o sulle pianificazioni di produzione.
Revisione e collaborazione offline: esporta le definizioni della piattaforma come JSON e Markdown per consentire la revisione tra pari, la convalida automatica e l'ispezione negli strumenti di sviluppo standard.
Blocchi di workflow riutilizzabili: sincronizza i blocchi di workflow modulari insieme o separatamente dai playbook completi in modo che i team possano condividere passaggi di automazione comuni.

Workflow di implementazione per obiettivo

Per accedere direttamente alle indicazioni corrispondenti al tuo obiettivo attuale, seleziona il tuo workflow:

Nuovo deployment di GitSync o nuovo ramo: se stai configurando l'integrazione di GitSync per la prima volta o stai creando un nuovo ramo del repository in un ambiente abilitato per l'API Chronicle, segui questa sequenza di configurazione end-to-end:
1. Completa la configurazione dei prerequisiti e delle credenziali.
2. Configura l'istanza di integrazione condivisa.
3. Testa la connettività di rete e l'autenticazione con l'azione Ping.
4. Esegui un job Push Content iniziale per popolare il ramo prima di eseguire qualsiasi job pull.
5. Configura e pianifica job di sincronizzazione automatizzati.
Esegui la migrazione all'API Chronicle (obbligatorio per le implementazioni esistenti): per eseguire la migrazione di un'integrazione GitSync e di un ramo del repository esistenti dopo il passaggio a un ambiente abilitato all'API Chronicle, consulta la sezione Migrazione dell'ambiente abilitato all'API Chronicle.
Riferimento al job e al repository:
- Per visualizzare i parametri di configurazione ed eseguire job push o pull autonomi per asset specifici (playbook, connettori, integrazioni e così via), consulta Job.
- Per visualizzare il layout standard del repository, consulta Struttura delle directory del repository.
Risolvi i problemi di sincronizzazione: se un'azione o un job non va a buon fine e viene visualizzato un errore, consulta la sezione Risoluzione dei problemi.

Prima di iniziare

Prima di configurare ed eseguire le operazioni GitSync, verifica l'ambiente, ottieni l'accesso al repository e completa le seguenti attività di configurazione:

Verifica l'ambiente abilitato per l'API Chronicle (obbligatorio per GitSync v53.0 e versioni successive): controlla l'URL della console web del browser per verificare che l'istanza sia ospitata su secops.google.com o *.chronicle.security.google.com (o verifica che Google.com venga visualizzato dopo il numero di versione del sistema in Impostazioni > Impostazioni SOAR > Gestione licenze). Se la tua istanza è ancora ospitata su *.siemplify-soar.com, completa prima la migrazione dell'ambiente abilitato per l'API Chronicle.
Utilizza un repository Git privato con accesso in scrittura: assicurati di disporre delle autorizzazioni di scrittura per un repository Git remoto privato ospitato su un provider Git supportato (come GitHub, GitLab o Bitbucket). Mentre i parametri di tipo Password vengono esclusi per impostazione predefinita, a meno che non sia attivato Commit Passwords, tutti gli altri parametri (come ID applicazione, ID client, nomi utente ed endpoint) vengono esportati in testo non crittografato. Non utilizzare mai un repository pubblico con GitSync.
Inizializza il repository remoto: verifica che il repository remoto abbia almeno un commit iniziale (ad esempio un file README.md o .gitignore). GitSync non può eseguire la sincronizzazione con un repository vuoto.
Prepara le credenziali di autenticazione Git: genera una credenziale di autenticazione con autorizzazioni di scrittura del repository. GitSync supporta chiavi private SSH con codifica base64 (consigliato), token di accesso personale (PAT) e credenziali di base con nome utente e password.

Per generare e codificare una chiave SSH, consulta Generare chiavi SSH per GitSync.
Verifica la connettività di rete e i controlli di servizio VPC: verifica che l'istanza Google SecOps o il runner remoto abbia accesso al firewall in uscita sulla porta TCP 443 (per HTTPS) o sulla porta TCP 22 (per SSH) al tuo provider Git.

Se il tuo ambienteGoogle Cloud utilizza un perimetro di servizio Controlli di servizio VPC, collabora con l'amministratore Google Cloud per configurare le regole in entrata e in uscita in modo che le integrazioni delle risposte possano comunicare con le API Google Cloud e gli endpoint esterni richiesti.
Ottieni l'impronta dell'host Git (consigliato): Per proteggerti dagli attacchi man-in-the-middle (MITM), recupera l'impronta della chiave pubblica del server Git per il pinning dell'impronta dell'host.

Per i passaggi di configurazione, consulta Attivare il pinning dell'impronta dell'host.
Concedi le autorizzazioni di modifica del playbook: Se intendi sincronizzare i playbook con accesso predefinito limitato (ad esempio, le autorizzazioni predefinite impostate su Può visualizzare), concedi al ruolo SOC Administrator le autorizzazioni Può modificare sul sistema di origine prima di eseguire i job di sincronizzazione.

Per istruzioni passo passo, vedi Configurare le autorizzazioni del playbook.

Genera chiavi SSH per GitSync

Per configurare l'autenticazione sicura e senza password utilizzando le chiavi SSH:

Genera una coppia di chiavi RSA o Ed25519 nel terminale. Quando ti viene richiesta una passphrase, premi Invio per lasciarla vuota:
```
ssh-keygen -b 2048 -t rsa -f ./id_rsa
```
Questo comando crea due file: id_rsa (chiave privata) e id_rsa.pub (chiave pubblica).
Aggiungi la chiave pubblica (id_rsa.pub) al tuo servizio di hosting Git remoto come chiave di deployment o chiave di accesso con autorizzazioni di scrittura.
Converti la chiave privata in una stringa con codifica base64 su una sola riga:
- Linux / macOS:
```
base64 -w 0 ./id_rsa
```
- Windows (PowerShell):
```
[Convert]::ToBase64String([System.IO.File]::ReadAllBytes(".\id_rsa"))
```
Copia la stringa base64 risultante e incollala nel parametro Git Password/Token/chiave SSH quando configuri l'istanza di integrazione GitSync.

Attivare il blocco dell'impronta dell'host

Il pinning dell'impronta dell'host verifica l'identità del server Git al momento della connessione per proteggere dagli attacchi person-in-the-middle (PITM). Sebbene il parametro Impronta del server Git sia facoltativo, la sua configurazione garantisce che GitSync si connetta esclusivamente all'host Git verificato.

Per configurare il pinning dell'impronta dell'host:

Recupera l'impronta dell'host: Esegui ssh-keyscan nel terminale rispetto al nome host del server Git:
```
ssh-keyscan -t rsa <hostname>
```
Ad esempio, per GitHub, esegui ssh-keyscan -t rsa github.com. Il comando restituisce una riga di chiave host pubblica simile alla seguente:
```
github.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC...
```
Salva l'impronta per la configurazione: copia la riga della chiave host pubblica. Inserisci questo valore nel parametro Impronta del server Git quando configuri l'istanza di integrazione GitSync (per applicarla a tutti i job) o nei singoli job di sincronizzazione (per sostituire l'impostazione per host specifici).

Configura le autorizzazioni del playbook

Quando sincronizzi i playbook con autorizzazioni limitate (ad esempio, le autorizzazioni predefinite impostate su Può visualizzare), assegna le autorizzazioni Può modificare al ruolo SOC Administrator:

In Google SecOps, vai a Playbook e seleziona il playbook di destinazione.
Apri le impostazioni delle autorizzazioni del playbook.
Aggiungi il ruolo SOC Administratorall'elenco delle entità e imposta l'autorizzazione su Può modificare.

Migrazione dell'ambiente abilitato per l'API Chronicle

Questa sezione fornisce le procedure per la migrazione di un deployment GitSync e di un ramo del repository esistenti a un ambiente abilitato per l'API Chronicle (supportato a partire dalla versione 53.0 di GitSync).

Per indicazioni sulla migrazione della piattaforma Google SecOps complessiva, dei gruppi di identità, delle autorizzazioni IAM e degli endpoint API a Google Cloud, consulta la Panoramica della migrazione di Google SecOps.

Aggiornamenti negli ambienti abilitati per l'API Chronicle

A partire dalla versione 53.0, GitSync include i seguenti aggiornamenti per gli ambienti abilitati per l'API Chronicle:

Autenticazione IAM automatica: GitSync si connette a Google SecOps tramite le API REST di Chronicle e si autentica automaticamente in fase di runtime utilizzando Google Cloud IAM.
Schema di configurazione aggiornato: i file di configurazione JSON esportati utilizzano gli identificatori delle risorse e i formati dei campi dell'API Chronicle, rendendoli incompatibili con i rami del repository pre-migrazione.
Opzioni di sincronizzazione dei blocchi dedicate: i job di sincronizzazione dei playbook includono un'opzione Includi blocchi del playbook per esportare o importare blocchi del flusso di lavoro riutilizzabili insieme ai playbook e supportano l'importazione di blocchi da /Playbooks o /Blocks.
Trasferimenti diretti di archivi per integrazioni personalizzate: i pacchetti di integrazione personalizzati vengono caricati e scaricati direttamente come archivi .zip, riducendo i tempi di trasferimento per le integrazioni di grandi dimensioni.
Mappature dell'ontologia con ambito di origine: Le regole di mappatura sono organizzate per origine di integrazione in /Ontology/Mappings/<Source_Name>/ per evitare conflitti tra le regole di mappatura di origini diverse.
Filtro automatico dei valori predefiniti di sistema integrati: GitSync esclude automaticamente gli elementi di sistema integrati di sola lettura (come i tag di sistema predefiniti e le istanze di sistema integrate) durante la sincronizzazione per evitare errori di autorizzazione.

Esegui la migrazione del branch del repository

Gli ambienti abilitati all'API Chronicle e gli ambienti legacy utilizzano formati di configurazione JSON diversi e non possono essere sincronizzati contemporaneamente con lo stesso ramo. Scegli un branch dedicato (consigliato) o riutilizza il branch esistente:

Opzione 1: workflow del ramo dedicato consigliato

La creazione di un nuovo ramo isola le configurazioni dell'API Chronicle aggiornate e conserva un archivio intatto delle configurazioni pre-migrazione senza modificare la cronologia del ramo:

Push legacy di base: prima della migrazione dell'istanza, esegui un job Push Content completo dall'ambiente esistente per eseguire il commit di un backup pulito nel ramo legacy (ad esempio, main).
Crea nuovo ramo Git: crea un nuovo ramo dedicato nel repository Git (ad esempio, git checkout -b gitsync-chronicle-api && git push origin gitsync-chronicle-api).
Esegui l'upgrade e riconfigura l'istanza di integrazione: nell'ambiente abilitato per l'API Chronicle, assicurati che GitSync sia aggiornato alla versione 53.0 o successive nell'hub dei contenuti. Poi vai a Impostazioni > Integrazioni > GitSync, aggiorna il parametro Branch a gitsync-chronicle-api e verifica la connettività utilizzando l'azione Ping.
Baseline iniziale di push abilitato per l'API: esegui un job Push Content completo dall'istanza abilitata per l'API Chronicle per popolare il nuovo ramo con i file di configurazione aggiornati.
Verifica e abilita la sincronizzazione pull: esamina il repository per verificare le strutture dei file, quindi abilita i job di recupero dei contenuti pianificati in base alle esigenze.

Opzione 2: procedura di riutilizzo del ramo esistente

Se le pipeline CI/CD automatizzate o i criteri dei rami richiedono di conservare un nome di ramo esistente, esegui la seguente procedura di cutover:

Regole di protezione dei rami: GitSync esegue il push dei commit direttamente nel repository remoto e non crea richieste pull. Se il ramo esistente (ad esempio main) applica regole di protezione dei rami che richiedono richieste pull o approvazioni di revisione, le operazioni di push dirette da GitSync non vanno a buon fine.

Prima di eseguire questa procedura, assicurati che l'amministratore del repository configuri un'eccezione che consenta alla chiave di deployment o all'account GitSync di eseguire il push direttamente nel ramo oppure utilizza l'opzione 1 con un ramo dedicato e unisci le modifiche in main tramite il flusso di lavoro standard delle richieste di pull.

Crea un tag di backup legacy: crea un tag di release Git delle tue configurazioni legacy come archivio storico.
```
git tag backup-legacy-pre-migration
git push origin backup-legacy-pre-migration
```
Metti in pausa i job di sincronizzazione: disattiva i job pianificati di GitSync attivi (Push Content e Pull Content) per evitare scritture simultanee durante il cutover.

Rimuovi i contenuti del ramo precedente: rimuovi le directory precedenti dal ramo.

git rm -rf Playbooks/ Connectors/ Integrations/ Jobs/ Ontology/ SimulatedCases/ Settings/
git commit -m "CHORE: Clear legacy files for Chronicle API baseline"
git push origin main

Esegui l'upgrade di GitSync e invia la baseline abilitata per l'API: nella tua istanza abilitata per l'API Chronicle, assicurati che GitSync sia aggiornato alla versione 53.0 o successive nell'hub dei contenuti. Una volta verificato, esegui un job Push Content completo per popolare il branch pulito con i file di configurazione aggiornati.
Riprendi la sincronizzazione pianificata: verifica i file esportati nel repository e riattiva i job GitSync pianificati nell'istanza abilitata per l'API Chronicle.

Configura l'integrazione

Configura l'integrazione GitSync come istanza condivisa in Google SecOps in modo che tutti i componenti della piattaforma e i job pianificati possano accedere alle configurazioni del repository.

Parametri di integrazione di GitSync

Parametro	Descrizione
`Repo URL`	Obbligatorio. L'URL del repository Git remoto. Quando utilizzi l'autenticazione HTTPS, l'URL deve iniziare con `https://` (ad esempio, `https://github.com/organization/secops-platform.git`). Quando utilizzi l'autenticazione SSH, l'URL deve iniziare con `git@` o `ssh://` (ad esempio, `git@github.com:organization/secops-platform.git`).
`Branch`	Obbligatorio. Il ramo del repository Git da sincronizzare (ad esempio `main` o `gitsync-chronicle-api`).
`Git Password/Token/SSH Key`	Obbligatorio. La credenziale di autenticazione per il repository Git remoto. Questo parametro accetta una password dell'account Git, un token di accesso personale (PAT) o una chiave privata SSH con codifica Base64 (RSA a 2048 bit o Ed25519).
`Git Username`	Facoltativo. Il nome utente dell'account Git. Obbligatorio quando si utilizza l'autenticazione con nome utente e password tramite HTTPS.
`Git Server Fingerprint`	Facoltativo. La chiave host pubblica SSH del server Git remoto (ad esempio, `github.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC...`). La configurazione di questo parametro attiva il pinning dell'impronta dell'host, assicurando che GitSync si connetta esclusivamente all'host Git verificato e mitigando i rischi di attacchi man-in-the-middle (MITM). Per recuperare questo valore, vedi Attivare il pinning dell'impronta dell'host.
`Commit Author`	Facoltativo. L'identità dell'autore allegata ai commit Git in uscita generati da GitSync. Il formato deve seguire l'attribuzione standard di Git: `Name <email@domain.com>` (il valore predefinito è `GitSync <gitsync@siemplify.co>`).
`Siemplify Verify SSL`	Obbligatorio. Se selezionata, l'integrazione convalida il certificato SSL dell'endpoint API Google SecOps. Abilitato per impostazione predefinita.
`Git Verify SSL`	Obbligatorio. Se selezionata, l'integrazione convalida il certificato SSL del server del fornitore Git remoto. Abilitato per impostazione predefinita.

Azioni

Per ulteriori informazioni sulle azioni, vedi Rispondere alle azioni in attesa dalla tua scrivania e Eseguire un'azione manuale.

Dindin

Utilizza l'azione Ping per testare la connettività di rete e verificare le credenziali di autenticazione rispetto al repository e al ramo Git configurati.

Input azione

Nessuno.

Output azione

L'azione Ping fornisce i seguenti output:

Tipo di output dell'azione	Disponibilità
Allegato della bacheca casi	Non disponibile
Link alla bacheca casi	Non disponibile
Tabella della bacheca casi	Non disponibile
Tabella di arricchimento	Non disponibile
Risultato JSON	Non disponibile
Messaggi di output	Disponibile
Risultato dello script	Disponibile

Messaggi di output

L'azione Ping può restituire i seguenti messaggi di output:

Messaggio di output	Descrizione del messaggio
`Successfully executed action "Ping".`	L'azione è riuscita e la connettività del repository è stata verificata.
`Error executing action "Ping". Reason: ERROR_REASON`	L'azione non è riuscita. Verifica l'URL del repository, il nome del ramo, le credenziali o le route di rete.

Risultato dello script

La seguente tabella elenca il valore del risultato dello script quando si utilizza l'azione Ping:

Nome del risultato dello script	Valore
`is_success`	`true` o `false`

Job

GitSync fornisce 16 configurazioni di job di sincronizzazione (2 job di istanza completa e 7 coppie di job autonomi) per gestire gli asset della piattaforma. Questi job supportano gli ambiti di sincronizzazione autonomi a livello di istanza e mirati.

Ambito di sincronizzazione e asset supportati

L'integrazione organizza i job di sincronizzazione in due ambiti operativi distinti per soddisfare diverse esigenze amministrative e di automazione:

Sincronizzazione completa dell'istanza (Push Content e Pull Content): Sincronizza l'intera piattaforma Google SecOps in una singola operazione collettiva.

Ciò comprende 21 categorie di asset della piattaforma in tre aree funzionali:
- Configurazioni di sistema e ambiente: ambienti, domini, parametri dinamici, elenchi personalizzati, reti, liste nere, impostazioni del titolo della richiesta, modelli email e logo.
- Gestione di avvisi e casi: tag dei casi, fasi dei casi, motivi di chiusura dei casi, record SLA e casi simulati.
- Automazione e integrazioni della sicurezza: playbook (inclusi i blocchi di workflow riutilizzabili), integrazioni, istanze di integrazione, connettori, job pianificati, mappature dell'ontologia e famiglie visive.
Sincronizzazione granulare degli asset (operazioni push e pull autonome):

Fornisce coppie di job push e pull dedicate per sette asset specifici. Utilizza i job autonomi quando sviluppi, aggiorni o testi singoli componenti senza sincronizzare o sovrascrivere il resto dell'ambiente:
- Playbook e blocchi del flusso di lavoro: Push Playbook e Pull Playbook
- Connettori: Push Connectors e Pull Connector
- Integrazioni: Push Integration e Pull Integration
- Job pianificati: Push Job e Pull Jobs
- Mappature dell'ontologia: Push Mappings e Pull Mappings
- Famiglie di elementi visivi personalizzati: Push Custom Family e Pull Custom Family
- Scenari di test simulati: Push Simulated Cases e Pull Simulated Cases

Struttura delle directory del repository

L'esecuzione di un job Push Content iniziale (obbligatorio prima di eseguire qualsiasi job pull su un ramo nuovo o migrato) crea la seguente struttura di directory predefinita, i file di configurazione JSON, il file di metadati GitSync.json principale e la documentazione README.md generata nel repository Git remoto.

Non modificare manualmente la struttura del repository:GitSync si basa su questo layout di directory predefinito e sul file di metadati GitSync.json della radice per monitorare e risolvere gli asset della piattaforma. La ridenominazione manuale dei file, lo spostamento delle directory o la ristrutturazione del repository tramite commit personalizzati possono causare errori nei job di sincronizzazione.

├── Connectors/
│   └── <Integration_Name>/
│       └── <Connector_Name>/
│           ├── <Connector_Name>.json
│           └── README.md
├── Integrations/
│   └── <Integration_Identifier>/
│       ├── Actions/
│       ├── Connectors/
│       ├── Dependencies/
│       ├── Jobs/
│       ├── Managers/
│       ├── Resources/
│       ├── Integration-<Integration_Identifier>.def
│       └── README.md
├── Jobs/
│   ├── <Job_Name>.json
│   └── README.md
├── Ontology/
│   ├── Mappings/
│   │   └── <Source_Name>/
│   │       ├── <Source_Name>_Records.json
│   │       ├── <Source_Name>_Rules.json
│   │       └── README.md
│   └── VisualFamilies/
│       └── <Family_Name>/
│           ├── <Family_Name>.json
│           ├── <Family_Name>.png
│           └── README.md
├── Playbooks/
│   ├── README.md
│   └── <Folder_Name>/
│       └── <Playbook_Or_Block_Name>/
│           ├── <Playbook_Or_Block_Name>.json
│           └── README.md
├── Settings/
│   ├── blacklists.json
│   ├── caseCloseCauses.json
│   ├── caseTitles.json
│   ├── customLists.json
│   ├── domains.json
│   ├── dynamicParameters.json
│   ├── emailTemplates.json
│   ├── environments.json
│   ├── integrationInstances.json
│   ├── logo.json
│   ├── networks.json
│   ├── slaDefinitions.json
│   ├── stages.json
│   └── tags.json
├── SimulatedCases/
│   └── <Case_Name>.case
├── GitSync.json
└── README.md

Job di sincronizzazione a livello di istanza

I job a livello di istanza sincronizzano le categorie di asset selezionate in un'intera istanza Google SecOps.

Push dei contenuti

Utilizza il job Push Content per esportare le categorie di asset selezionate dalla tua istanza di Google SecOps e eseguirne il commit nel ramo del repository Git configurato. Esegui sempre Push Content prima di inizializzare un nuovo ramo o eseguire la migrazione a un ambiente abilitato per l'API Chronicle.

Input del job

Per configurare il job Push Content, utilizza i seguenti parametri:

Parametro	Descrizione
`Commit`	Obbligatorio. Il messaggio di commit Git che descrive le modifiche ai contenuti esportati.
`Commit Passwords`	Facoltativo. Se selezionato, il job esporta i parametri di tipo `Password` in testo normale per le istanze di integrazione, i connettori e i job configurati. Attenzione:non attivare mai questa opzione su repository pubblici o condivisi, in quanto espone le credenziali in testo normale. Tieni presente che anche quando `Commit Passwords` è disattivato, i parametri che non sono di tipo `Password` (come ID applicazione, ID cliente, nomi utente e URL) vengono sempre esportati in testo normale.
Parametri di selezione degli asset: `Integrations`, `Playbooks`, `Jobs`, `Connectors`, `Simulated Cases`, `Integration Instances`, `Visual Families`, `Mappings`, `Environments`, `Dynamic Parameters`, `Logo`, `Case Tags`, `Case Stages`, `Case Title Settings`, `Case Close Reasons`, `Networks`, `Domains`, `Custom Lists`, `Email Templates`, `Blacklists`, `SLA Records`	(Facoltativo) Attivazioni/disattivazioni booleane. Seleziona ogni categoria di asset da includere nell'esportazione.
`Repo URL`	Facoltativo. Esegue l'override dell'URL del repository configurato nell'istanza di integrazione.
`Branch`	Facoltativo. Esegue l'override del ramo del repository configurato nell'istanza di integrazione.
`Commit Author`	Facoltativo. Esegue l'override dell'autore del commit configurato nell'istanza di integrazione. Deve utilizzare il formato `Name <email@domain.com>`.
`Git Server Fingerprint`	Facoltativo. Esegue l'override dell'impronta dell'host SSH configurata nell'istanza di integrazione.

Output del job

Il job scrive i file di configurazione JSON e i riepiloghi README.md nel ramo Git di destinazione nella gerarchia di directory standard (/Playbooks, /Connectors, /Integrations, /Jobs, /Ontology/Mappings, /Ontology/VisualFamilies, /SimulatedCases e /Settings) e restituisce i log di esecuzione nella console del runner dei job. Le integrazioni personalizzate vengono esportate come pacchetti completi, mentre le integrazioni commerciali esportano solo gli script personalizzati o le modifiche aggiunte all'integrazione.

Recuperare i contenuti

Utilizza il job Pull Content per recuperare le categorie di configurazione selezionate dal ramo del repository Git configurato e applicarle alla piattaforma Google SecOps.

Input del job

Per configurare il job Pull Content, utilizza i seguenti parametri:

Parametro	Descrizione
Parametri di selezione degli asset: `Integrations`, `Playbooks`, `Jobs`, `Connectors`, `Simulated Cases`, `Integration Instances`, `Visual Families`, `Mappings`, `Environments`, `Dynamic Parameters`, `Logo`, `Case Tags`, `Case Stages`, `Case Title Settings`, `Case Close Reasons`, `Networks`, `Domains`, `Custom Lists`, `Email Templates`, `Blacklists`, `SLA Records`	(Facoltativo) Attivazioni/disattivazioni booleane. Seleziona ogni categoria di asset che vuoi importare dal repository nel tuo ambiente.
`Repo URL`	Facoltativo. Esegue l'override dell'URL del repository configurato nell'istanza di integrazione.
`Branch`	Facoltativo. Esegue l'override del ramo del repository configurato nell'istanza di integrazione.
`Git Server Fingerprint`	Facoltativo. Esegue l'override dell'impronta dell'host SSH configurata nell'istanza di integrazione.

Output del job

Il job importa le definizioni del repository selezionate nella piattaforma, crea o aggiorna istanze di integrazione, playbook, connettori, job, mappature dell'ontologia e impostazioni e genera log di esecuzione nella console del job runner.

Job di sincronizzazione autonomi

I job autonomi consentono la sincronizzazione granulare di asset specifici senza richiedere una sincronizzazione completa del repository.

Push Playbook

Utilizza il job Push Playbook per esportare singoli playbook o blocchi di workflow riutilizzabili in Git.

Input del job

Per configurare il job Push Playbook, utilizza i seguenti parametri:

Parametro	Descrizione
`Commit`	Obbligatorio. Il messaggio di commit Git che descrive le modifiche alla guida pratica.
`Playbook Whitelist`	Facoltativo. Un elenco separato da virgole di nomi di playbook o blocchi esatti e sensibili alle maiuscole da esportare. Fornisci `Playbook Whitelist` o `Folders Whitelist`.
`Folders Whitelist`	Facoltativo. Un elenco separato da virgole di nomi di cartelle (categorie) di playbook. Vengono esportati tutti i playbook e i blocchi che si trovano in queste cartelle.
`Include Playbook Blocks`	Facoltativo. Se selezionata, esporta i blocchi del flusso di lavoro riutilizzabili insieme ai playbook selezionati, inclusi tutti i blocchi a cui viene fatto riferimento come passaggi all'interno di questi playbook.
`Repo URL`	Facoltativo. Esegue l'override dell'URL del repository predefinito.
`Branch`	Facoltativo. Esegue l'override del branch predefinito.
`Commit Author`	Facoltativo. Esegue l'override dell'autore del commit predefinito.
`Git Server Fingerprint`	Facoltativo. Esegue l'override dell'impronta digitale dell'host SSH predefinita.
`Readme Addon`	Facoltativo. Contenuti personalizzati aggiunti al `README.md` generato per tutti i playbook inviati in questa esecuzione e salvati nel file di metadati `GitSync.json` principale. Supporta sia la sintassi Markdown sia i modelli Jinja.

Output del job

Esporta i playbook selezionati e i blocchi del flusso di lavoro inclusi in /Playbooks/<Folder_Name>/<Playbook_Name>/ e aggiorna /Playbooks/README.md.

Estrai playbook

Utilizza il job Pull Playbook per importare playbook o blocchi specifici da Git.

Input del job

Per configurare il job Pull Playbook, utilizza i seguenti parametri:

Parametro	Descrizione
`Playbook Whitelist`	Obbligatorio. Un elenco separato da virgole dei nomi esatti di playbook o blocchi da importare dal repository.
`Include Playbook Blocks`	Facoltativo. Se selezionata, importa automaticamente tutti i blocchi di workflow riutilizzabili a cui fanno riferimento i playbook selezionati.
`Repo URL`	Facoltativo. Esegue l'override dell'URL del repository predefinito.
`Branch`	Facoltativo. Esegue l'override del branch predefinito.
`Git Server Fingerprint`	Facoltativo. Esegue l'override dell'impronta digitale dell'host SSH predefinita.

Output del job

Importa i playbook e i blocchi specificati da /Playbooks (o /Blocks) nella piattaforma, installando prima i blocchi a cui viene fatto riferimento e poi i playbook principali.

Connettori push

Utilizza il job Push Connectors per esportare le configurazioni dei connettori in Git.

Input del job

Per configurare il job Push Connectors, utilizza i seguenti parametri:

Parametro	Descrizione
`Connectors`	Obbligatorio. Un elenco separato da virgole dei nomi visualizzati dei connettori da esportare.
`Commit`	Obbligatorio. Il messaggio di commit Git.
`Include Mappings`	Facoltativo. Se selezionata, esporta i record di mappatura dell'ontologia e le regole associate all'integrazione del connettore in `/Ontology/Mappings`.
`Include Visual Families`	Facoltativo. Se selezionata, esporta le famiglie di visualizzazioni personalizzate associate ai record dell'ontologia del connettore in `/Ontology/VisualFamilies`.
`Repo URL`	Facoltativo. Esegue l'override dell'URL del repository predefinito.
`Branch`	Facoltativo. Esegue l'override del branch predefinito.
`Commit Author`	Facoltativo. Esegue l'override dell'autore del commit predefinito.
`Git Server Fingerprint`	Facoltativo. Esegue l'override dell'impronta digitale dell'host SSH predefinita.
`Readme Addon`	Facoltativo. Contenuti personalizzati aggiunti al `README.md` generato per tutti i connettori inseriti in questa esecuzione e salvati in `GitSync.json`. Supporta sia la sintassi Markdown sia i modelli Jinja.

Output del job

Esporta le impostazioni e le pianificazioni del connettore in /Connectors/<Integration_Name>/<Connector_Name>/ (insieme alle mappature dell'ontologia e alle famiglie visive associate, se selezionate).

Pull Connector

Utilizza il job Pull Connector per importare una configurazione del connettore da Git. Prima di eseguire questo job, assicurati che l'integrazione sottostante del connettore sia già installata nell'ambiente di destinazione.

Input del job

Per configurare il job Pull Connector, utilizza i seguenti parametri:

Parametro	Descrizione
`Connector Name`	Obbligatorio. Il nome visualizzato del connettore da cui importare dal repository.
`Include Mappings`	Facoltativo. Se selezionata, importa le mappature dell'ontologia associate all'integrazione del connettore.
`Include Visual Families`	Facoltativo. Se selezionata, importa le famiglie di visualizzazioni personalizzate associate all'integrazione del connettore.
`Repo URL`	Facoltativo. Esegue l'override dell'URL del repository predefinito.
`Branch`	Facoltativo. Esegue l'override del branch predefinito.
`Git Server Fingerprint`	Facoltativo. Esegue l'override dell'impronta digitale dell'host SSH predefinita.

Output del job

Installa o aggiorna il connettore nell'ambiente di destinazione (insieme alle mappature o alle famiglie visive associate, se selezionate).

Integrazione push

Utilizza il job Push Integration per esportare integrazioni personalizzate o script personalizzati aggiunti a integrazioni commerciali in Git. Le integrazioni personalizzate vengono esportate come pacchetti di integrazione completi, mentre le integrazioni commerciali esportano solo script personalizzati o modifiche aggiunte all'integrazione.

Input del job

Per configurare il job Push Integration, utilizza i seguenti parametri:

Parametro	Descrizione
`Push Whitelist`	Obbligatorio. Un elenco separato da virgole di identificatori di integrazione da esportare.
`Commit`	Obbligatorio. Il messaggio di commit Git.
`Repo URL`	Facoltativo. Esegue l'override dell'URL del repository predefinito.
`Branch`	Facoltativo. Esegue l'override del branch predefinito.
`Commit Author`	Facoltativo. Esegue l'override dell'autore del commit predefinito.
`Git Server Fingerprint`	Facoltativo. Esegue l'override dell'impronta digitale dell'host SSH predefinita.
`Readme Addon`	Facoltativo. Contenuti personalizzati aggiunti al `README.md` generato per tutte le integrazioni inviate in questa esecuzione e salvate in `GitSync.json`. Supporta sia la sintassi Markdown sia i modelli Jinja.

Output del job

Esporta le definizioni di integrazione, gli script personalizzati (Actions/, Connectors/, Jobs/, Managers/), le dipendenze e la documentazione README.md in /Integrations/<Integration_Identifier>/.

Integrazione pull

Utilizza il job Pull Integration per importare integrazioni personalizzate o script personalizzati per integrazioni commerciali da Git. Per le integrazioni commerciali, GitSync installa l'ultima versione dell'integrazione da Content Hub e salva gli script personalizzati.

Input del job

Per configurare il job Pull Integration, utilizza i seguenti parametri:

Parametro	Descrizione
`Install Whitelist`	Obbligatorio. Un elenco separato da virgole di identificatori di integrazione da importare dal repository.
`Repo URL`	Facoltativo. Esegue l'override dell'URL del repository predefinito.
`Branch`	Facoltativo. Esegue l'override del branch predefinito.
`Git Server Fingerprint`	Facoltativo. Esegue l'override dell'impronta digitale dell'host SSH predefinita.

Output del job

Installa pacchetti di integrazione personalizzati o integrazioni commerciali da Content Hub e aggiorna i relativi script personalizzati nell'ambiente di destinazione.

Push Job

Utilizza il job Push Job per esportare le configurazioni dei job della piattaforma pianificati in Git.

Input del job

Per configurare il job Push Job, utilizza i seguenti parametri:

Parametro	Descrizione
`Job Whitelist`	Obbligatorio. Un elenco separato da virgole dei nomi dei job programmati da esportare.
`Commit`	Obbligatorio. Il messaggio di commit Git.
`Repo URL`	Facoltativo. Esegue l'override dell'URL del repository predefinito.
`Branch`	Facoltativo. Esegue l'override del branch predefinito.
`Commit Author`	Facoltativo. Esegue l'override dell'autore del commit predefinito.
`Git Server Fingerprint`	Facoltativo. Esegue l'override dell'impronta digitale dell'host SSH predefinita.
`Readme Addon`	Facoltativo. Contenuti personalizzati aggiunti al `README.md` generato per tutti i job inviati in questa esecuzione e salvati in `GitSync.json`. Supporta sia la sintassi Markdown sia i modelli Jinja.

Output del job

Esporta i parametri del job e gli intervalli di pianificazione in /Jobs/<Job_Name>.json e aggiorna /Jobs/README.md.

Pull Jobs

Utilizza il job Pull Jobs per importare i job della piattaforma pianificati da Git.

Input del job

Per configurare il job Pull Jobs, utilizza i seguenti parametri:

Parametro	Descrizione
`Job Whitelist`	Obbligatorio. Un elenco separato da virgole dei nomi dei job programmati da importare dal repository.
`Repo URL`	Facoltativo. Esegue l'override dell'URL del repository predefinito.
`Branch`	Facoltativo. Esegue l'override del branch predefinito.
`Git Server Fingerprint`	Facoltativo. Esegue l'override dell'impronta digitale dell'host SSH predefinita.

Output del job

Configura e registra i job pianificati specificati nello scheduler di job della piattaforma.

Push Mappings

Utilizza il job Push Mappings per esportare in Git i record e le regole di mappatura degli eventi dell'ontologia per una fonte specifica.

Input del job

Per configurare il job Push Mappings, utilizza i seguenti parametri:

Parametro	Descrizione
`Source`	Obbligatorio. L'origine dell'ontologia (nome dell'integrazione) di cui vuoi esportare le regole e i record di mappatura.
`Commit`	Obbligatorio. Il messaggio di commit Git.
`Repo URL`	Facoltativo. Esegue l'override dell'URL del repository predefinito.
`Branch`	Facoltativo. Esegue l'override del branch predefinito.
`Commit Author`	Facoltativo. Esegue l'override dell'autore del commit predefinito.
`Git Server Fingerprint`	Facoltativo. Esegue l'override dell'impronta digitale dell'host SSH predefinita.
`Readme Addon`	Facoltativo. Contenuti personalizzati aggiunti al `README.md` generato per tutte le mappature inserite in questa esecuzione e salvate in `GitSync.json`. Supporta sia la sintassi Markdown sia i modelli Jinja.

Output del job

Scrive record di ontologia (<Source>_Records.json), regole di mappatura (<Source>_Rules.json) e README.md in /Ontology/Mappings/<Source>/.

Esegui il pull delle mappature

Utilizza il job Pull Mappings per importare regole e record di mappatura dell'ontologia per un'origine specifica da Git.

Input del job

Per configurare il job Pull Mappings, utilizza i seguenti parametri:

Parametro	Descrizione
`Source`	Obbligatorio. L'origine dell'ontologia (nome dell'integrazione) di cui vuoi importare le regole e i record di mappatura.
`Repo URL`	Facoltativo. Esegue l'override dell'URL del repository predefinito.
`Branch`	Facoltativo. Esegue l'override del branch predefinito.
`Git Server Fingerprint`	Facoltativo. Esegue l'override dell'impronta digitale dell'host SSH predefinita.

Output del job

Registra le regole di mappatura dell'ontologia e le assegnazioni di famiglie visive nelle impostazioni dell'ontologia della piattaforma. Le mappature vengono visualizzate nella tabella Stato dell'ontologia dopo l'importazione degli eventi corrispondenti.

Push Custom Family

Utilizza il job Push Custom Family per esportare le definizioni e le icone delle famiglie di visualizzazioni personalizzate in Git.

Input del job

Per configurare il job Push Custom Family, utilizza i seguenti parametri:

Parametro	Descrizione
`Family Name`	Obbligatorio. Un elenco separato da virgole di nomi di famiglie di visualizzazioni personalizzate da esportare.
`Commit`	Obbligatorio. Il messaggio di commit Git.
`Repo URL`	Facoltativo. Esegue l'override dell'URL del repository predefinito.
`Branch`	Facoltativo. Esegue l'override del branch predefinito.
`Commit Author`	Facoltativo. Esegue l'override dell'autore del commit predefinito.
`Git Server Fingerprint`	Facoltativo. Esegue l'override dell'impronta digitale dell'host SSH predefinita.
`Readme Addon`	Facoltativo. Contenuti personalizzati aggiunti al `README.md` generato per tutte le famiglie di visualizzazioni personalizzate inviate in questa esecuzione e salvate in `GitSync.json`. Supporta sia la sintassi Markdown sia i modelli Jinja.

Output del job

Esporta le definizioni visive della famiglia (<Family_Name>.json), i file immagine delle icone (<Family_Name>.png) e README.md in /Ontology/VisualFamilies/<Family_Name>/.

Pull Custom Family

Utilizza il job Pull Custom Family per importare una definizione e un'icona di famiglia di visualizzazioni personalizzate da Git.

Input del job

Per configurare il job Pull Custom Family, utilizza i seguenti parametri:

Parametro	Descrizione
`Family Name`	Obbligatorio. Il nome esatto della famiglia visiva personalizzata da importare.
`Repo URL`	Facoltativo. Esegue l'override dell'URL del repository predefinito.
`Branch`	Facoltativo. Esegue l'override del branch predefinito.
`Git Server Fingerprint`	Facoltativo. Esegue l'override dell'impronta digitale dell'host SSH predefinita.

Output del job

Importa la definizione e l'icona della famiglia di visualizzazioni personalizzate nelle impostazioni dell'ontologia della piattaforma.

Push Simulated Cases

Utilizza il job Push Simulated Cases per esportare gli scenari di test simulati in Git.

Input del job

Per configurare il job Push Simulated Cases, utilizza i seguenti parametri:

Parametro	Descrizione
`Simulated Cases`	Obbligatorio. Un elenco separato da virgole di nomi di scenari simulati da esportare.
`Commit`	Obbligatorio. Il messaggio di commit Git.
`Repo URL`	Facoltativo. Esegue l'override dell'URL del repository predefinito.
`Branch`	Facoltativo. Esegue l'override del branch predefinito.
`Commit Author`	Facoltativo. Esegue l'override dell'autore del commit predefinito.
`Git Server Fingerprint`	Facoltativo. Esegue l'override dell'impronta digitale dell'host SSH predefinita.

Output del job

Esporta i casi simulati come file .case in /SimulatedCases/<Case_Name>.case.

Esegui il pull dei casi simulati

Utilizza il job Pull Simulated Cases per importare scenari di test simulati da Git.

Input del job

Per configurare il job Pull Simulated Cases, utilizza i seguenti parametri:

Parametro	Descrizione
`Simulated Cases`	Obbligatorio. Un elenco separato da virgole di nomi di scenari simulati da importare dal repository.
`Repo URL`	Facoltativo. Esegue l'override dell'URL del repository predefinito.
`Branch`	Facoltativo. Esegue l'override del branch predefinito.
`Git Server Fingerprint`	Facoltativo. Esegue l'override dell'impronta digitale dell'host SSH predefinita.

Output del job

Importa gli scenari simulati specificati nel catalogo degli scenari simulati della piattaforma.

Risoluzione dei problemi

La tabella seguente fornisce i passaggi di correzione per gli errori di sincronizzazione più comuni:

Messaggio di errore osservato	Causa operativa	Procedura di correzione
`Authentication failed`, `401 Unauthorized` o `Connection refused` durante l'esecuzione dell'azione o del job	Se esegui questa integrazione su un'istanza legacy di cui non è stata eseguita la migrazione (`.siemplify-soar.com`), GitSync comunica con Google SecOps esclusivamente tramite le API REST di Chronicle utilizzando Google Cloud l'autenticazione IAM e non supporta più gli endpoint API della piattaforma legacy (`.siemplify-soar.com/api/`).	Esegui la migrazione dell'istanza della piattaforma Google SecOps a un ambiente abilitato per l'API Chronicle (accessibile tramite `secops.google.com` o `*.chronicle.security.google.com`). Per istruzioni sulla migrazione, vedi Migrazione dell'ambiente abilitato per l'API Chronicle.
`Permission denied (publickey)` o `Host key verification failed` (o `Authentication failed for 'https://...'`)	Errore di autenticazione Git causato da un formato delle credenziali non valido, autorizzazioni di scrittura della chiave di deployment mancanti o impronta dell'host non corrispondente.	Autenticazione SSH: verifica che la chiave SSH privata sia convertita in una stringa base64 a riga singola senza interruzioni di riga o spazi bianchi finali. Verifica che la chiave pubblica corrispondente sia registrata nel tuo repository Git con accesso in scrittura. Impronta host: se il pinning dell'impronta host è abilitato, verifica la stringa dell'impronta utilizzando `ssh-keyscan -t rsa <hostname>` e aggiorna il parametro Impronta server Git. Autenticazione HTTPS: verifica che il token di accesso personale (PAT) non sia scaduto e disponga dell'ambito di scrittura del repository.
`403 Forbidden: Insufficient permissions to modify playbook` (o `Failed to push playbook: Access denied`)	Il playbook di destinazione ha autorizzazioni di accesso predefinite limitate (ad esempio Può visualizzare) e al ruolo SOC `Administrator` non sono state concesse autorizzazioni Può modificare sul sistema di origine.	In Google SecOps, vai a Playbook, seleziona il playbook interessato, apri le impostazioni delle autorizzazioni e aggiungi il ruolo SOC `Administrator` con le autorizzazioni Può modificare. Per la procedura dettagliata, vedi Configurare le autorizzazioni del playbook.
Il job Pull Content o Pull Integration scade dopo 5 minuti	L'installazione di più integrazioni commerciali da Content Hub durante una singola operazione di pull ha superato il timeout di esecuzione del job di 5 minuti.	Installa manualmente le integrazioni commerciali richieste dall'hub dei contenuti prima di eseguire Pull Content o esegui di nuovo il job Pull Content per continuare a importare gli asset rimanenti.
`General error performing Job Pull Content` (o `400 Bad Request` / `404 Not Found` quando viene eseguito il pull da un ramo legacy esistente)	Tentativo di estrarre un ramo del repository contenente file di configurazione legacy pre-migrazione in un ambiente abilitato per l'API Chronicle.	Esegui prima un job Push Content completo dal tuo ambiente abilitato per l'API Chronicle per popolare il ramo con i file di configurazione aggiornati prima di eseguire qualsiasi job pull. Verifica che l'istanza di integrazione sia configurata con il ramo corretto abilitato per l'API Chronicle (vedi Migrazione dell'ambiente abilitato per l'API Chronicle).
`Playbook '<Playbook_Name>' is assigned to environment(s) that don't exist`	Un playbook o un blocco importato viene assegnato a un ambiente o a un gruppo di ambienti che non è stato creato nell'istanza di destinazione.	Esegui Pull Content con l'opzione Environments selezionata per prima oppure crea manualmente l'ambiente mancante in Settings > Environments nell'istanza di destinazione prima di eseguire il pull dei playbook.
`Commit Author parameter must be in the following format: Name <example@gmail.com>`	Il parametro Autore commit nella configurazione dell'istanza di integrazione o del job non contiene un indirizzo email tra parentesi angolari.	Aggiorna il parametro Autore commit in modo che corrisponda al formato richiesto: `Name <email@domain.com>` (ad esempio, `GitSync <gitsync@example.com>`).
`400 Bad Request` o `409 Conflict` durante l'importazione delle mappature dell'ontologia	Le regole di mappatura degli eventi nel repository sono in conflitto con le regole di ontologia della piattaforma esistenti o sono state esportate utilizzando una versione precedente di GitSync.	Esegui un nuovo job Push Mappings dall'ambiente abilitato per l'API Chronicle per esportare nuovamente le definizioni di mapping o risolvere le regole di mapping degli eventi duplicati in Impostazioni > Ontologia > Regole di mapping prima di eseguire nuovamente il job.

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