Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

GitSync

Obligatorische Plattformanforderung:Ab GitSync-Version 53.0 kommuniziert diese Integration ausschließlich über Chronicle REST APIs mit Google Security Operations. Dabei wird die automatisierte IAM-Authentifizierung verwendet. Die Unterstützung für Legacy-API-Endpunkte der Google SecOps-Plattform (*.siemplify-soar.com/api/) wurde entfernt. Alle GitSync-Aktionen und -Jobs schlagen bei nicht migrierten Instanzen fehl.

Sie müssen die Plattformmigration abschließen, bevor Sie GitSync aktualisieren oder konfigurieren. Eine Migrationsanleitung finden Sie unter Migration der Chronicle API-fähigen Umgebung.

GitSync ist eine Integration für Google SecOps, mit der Sicherheitsautomatisierungs-Assets und -Komponenten mit einem externen Git-Repository (z. B. GitHub, GitLab oder Bitbucket) synchronisiert werden. Sie ermöglicht die bidirektionale Synchronisierung von Inhalten und bietet automatisierte Versionsverwaltung, Konfigurationssicherung und umgebungsübergreifende Promotion im gesamten Lebenszyklus Ihrer Sicherheitsvorgänge. GitSync wurde für die Sicherung und Migration von Assets zwischen zugehörigen Umgebungen (z. B. Entwicklung, Staging und Produktion) entwickelt und nicht für die Verteilung von Assets auf nicht verwandte Systeme, in denen interne Datenbank-IDs Konflikte verursachen können.

Anwendungsfälle

Die GitSync-Integration unterstützt die folgenden primären Anwendungsfälle:

Versionsverwaltung und Prüfbarkeit (Security as Code): Änderungen nachverfolgen, Unterschiede prüfen und einen vollständigen Versionsverlauf von Änderungen an Playbooks, Connectors, Integrationen und Systemeinstellungen führen.
Hochstufen in mehreren Umgebungen (CI/CD-Pipeline): Playbooks, Ontologiezuordnungen und Integrationseinstellungen systematisch über Pull-Anfragen und Zweigzusammenführungen von Entwicklungs- und Staging-Umgebungen in die Produktionsumgebung hochstufen.
Sicherung und Notfallwiederherstellung: Stellen Sie versehentlich gelöschte, beschädigte oder falsch konfigurierte Playbooks und Plattformkonfigurationen direkt aus Ihrem Git-Repository wieder her.
Umgebungsübergreifende Standardisierung: Verteilen Sie standardisierte Playbooks, benutzerdefinierte visuelle Familien und Connector-Definitionen über ein zentrales Repository auf zugehörige Google SecOps-Umgebungen.
Branching und Staging-Isolation: Testen Sie experimentelle Playbooks und Feature-Branches in dedizierten Umgebungen, ohne Produktions-Workflows oder ‑Zeitpläne zu beeinträchtigen.
Offline-Überprüfung und Zusammenarbeit: Exportieren Sie Plattformdefinitionen als JSON und Markdown, um die Peer-Review, automatisierte Validierung und Überprüfung in Standardentwicklertools zu ermöglichen.
Wiederverwendbare Workflowblöcke: Synchronisieren Sie modulare Workflowblöcke zusammen mit oder separat von vollständigen Playbooks, damit Teams gemeinsame Automatisierungsschritte nutzen können.

Implementierungsworkflows nach Zielvorhaben

Wählen Sie Ihren Workflow aus, um direkt zur Anleitung für Ihr aktuelles Ziel zu gelangen:

Neue GitSync-Bereitstellung oder neuer Branch: Wenn Sie die GitSync-Integration zum ersten Mal konfigurieren oder einen neuen Repository-Branch in einer Umgebung mit aktivierter Chronicle API erstellen, folgen Sie dieser End-to-End-Einrichtungsreihenfolge:
1. Voraussetzungen erfüllen und Anmeldedaten einrichten
2. Gemeinsame Integrationsinstanz konfigurieren
3. Testen Sie die Netzwerkverbindung und Authentifizierung mit der Ping-Aktion.
4. Führen Sie einen ersten Push Content-Job aus, um den Branch zu füllen, bevor Sie Pull-Jobs ausführen.
5. Automatisierte Synchronisierungsjobs konfigurieren und planen
Zur Chronicle API migrieren (für bestehende Bereitstellungen erforderlich): Wenn Sie eine bestehende GitSync-Integration und einen Repository-Zweig migrieren möchten, nachdem Sie zu einer Umgebung mit aktivierter Chronicle API gewechselt sind, lesen Sie den Abschnitt Migration zu einer Umgebung mit aktivierter Chronicle API.
Job- und Repository-Referenz:
- Informationen zum Aufrufen von Konfigurationsparametern und zum Ausführen eigenständiger Push- oder Pull-Jobs für bestimmte Assets (Playbooks, Connectors, Integrationen usw.) finden Sie unter Jobs.
- Informationen zum Standardlayout des Repositorys finden Sie unter Verzeichnisstruktur des Repositorys.
Probleme bei der Synchronisierung beheben: Wenn bei einer Aktion oder einem Job ein Fehler auftritt, finden Sie weitere Informationen unter Fehlerbehebung.

Hinweis

Bevor Sie GitSync-Vorgänge konfigurieren und ausführen, müssen Sie Ihre Umgebung überprüfen, Repositoryzugriff erhalten und die folgenden Einrichtungsaufgaben ausführen:

Chronicle API-fähige Umgebung bestätigen (erforderlich für GitSync v53.0 und höher): Prüfen Sie die Webkonsolen-URL Ihres Browsers, um zu bestätigen, dass Ihre Instanz auf secops.google.com oder *.chronicle.security.google.com gehostet wird. Alternativ können Sie auch prüfen, ob Google.com nach der Systemversionsnummer in Einstellungen > SOAR-Einstellungen > Lizenzverwaltung angezeigt wird. Wenn Ihre Instanz noch auf *.siemplify-soar.com gehostet wird, führen Sie zuerst die Migration der Chronicle API-fähigen Umgebung durch.
Privates Git-Repository mit Schreibzugriff verwenden: Sie benötigen Schreibberechtigungen für ein privates Remote-Git-Repository, das bei einem unterstützten Git-Anbieter (z. B. GitHub, GitLab oder Bitbucket) gehostet wird. Während Parameter vom Typ Password standardmäßig ausgeschlossen werden, sofern Commit Passwords nicht aktiviert ist, werden alle anderen Parameter (z. B. Anwendungs-IDs, Client-IDs, Nutzernamen und Endpunkte) im Klartext exportiert. Verwenden Sie niemals ein öffentliches Repository mit GitSync.
Remote-Repository initialisieren: Das Remote-Repository muss mindestens einen ersten Commit enthalten, z. B. eine README.md- oder .gitignore-Datei. GitSync kann nicht mit einem leeren Repository synchronisiert werden.
Anmeldedaten für die Git-Authentifizierung vorbereiten: Generieren Sie Anmeldedaten für die Authentifizierung mit Schreibberechtigungen für das Repository. GitSync unterstützt base64-codierte private SSH-Schlüssel (empfohlen), persönliche Zugriffstokens (Personal Access Tokens, PATs) sowie grundlegende Anmeldedaten mit Nutzername und Passwort.

Informationen zum Generieren und Codieren eines SSH-Schlüssels finden Sie unter SSH-Schlüssel für GitSync generieren.
Netzwerkverbindung und VPC Service Controls prüfen: Prüfen Sie, ob Ihre Google SecOps-Instanz oder Ihr Remote Runner ausgehenden Firewallzugriff auf TCP-Port 443 (für HTTPS) oder TCP-Port 22 (für SSH) zu Ihrem Git-Anbieter hat.

Wenn in IhrerGoogle Cloud -Umgebung ein VPC Service Controls-Dienstperimeter verwendet wird, bitten Sie Ihren Google Cloud -Administrator, Regeln für ein- und ausgehenden Traffic zu konfigurieren, damit Antwortintegrationen mit den erforderlichen Google Cloud APIs und externen Endpunkten kommunizieren können.
Fingerabdruck des Git-Hosts abrufen (empfohlen): Um sich vor Man-in-the-Middle-Angriffen (MITM) zu schützen, rufen Sie den Fingerabdruck des öffentlichen Schlüssels Ihres Git-Servers für das Host-Fingerabdruck-Pinning ab.

Eine Anleitung zur Konfiguration finden Sie unter Host-Fingerprint-Pinning aktivieren.
Playbook-Bearbeitungsberechtigungen erteilen: Wenn Sie Playbooks mit eingeschränktem Standardzugriff (z. B. Standardberechtigungen auf Can View festgelegt) synchronisieren möchten, erteilen Sie der Administrator-SOC-Rolle Can Edit-Berechtigungen im Quellsystem, bevor Sie Synchronisierungsjobs ausführen.

Eine detaillierte Anleitung finden Sie unter Playbook-Berechtigungen konfigurieren.

SSH-Schlüssel für GitSync generieren

So konfigurieren Sie die sichere, passwortlose Authentifizierung mit SSH-Schlüsseln:

Generieren Sie ein RSA- oder Ed25519-Schlüsselpaar in Ihrem Terminal. Wenn Sie zur Eingabe einer Passphrase aufgefordert werden, drücken Sie die Eingabetaste, um sie leer zu lassen:
```
ssh-keygen -b 2048 -t rsa -f ./id_rsa
```
Mit diesem Befehl werden zwei Dateien erstellt: id_rsa (privater Schlüssel) und id_rsa.pub (öffentlicher Schlüssel).
Fügen Sie den öffentlichen Schlüssel (id_rsa.pub) Ihrem Remote-Git-Hostingdienst als Bereitstellungsschlüssel oder Zugriffsschlüssel mit Schreibberechtigungen hinzu.
Privaten Schlüssel in einen einzeiligen base64-codierten String konvertieren:
- Linux / macOS:
```
base64 -w 0 ./id_rsa
```
- Windows (PowerShell):
```
[Convert]::ToBase64String([System.IO.File]::ReadAllBytes(".\id_rsa"))
```
Kopieren Sie den resultierenden Base64-String und fügen Sie ihn beim Konfigurieren der GitSync-Integrationsinstanz in den Parameter Git Password/Token/SSH-Schlüssel ein.

Host-Fingerprint-Pinning aktivieren

Durch das Anpinnen von Host-Fingerabdrücken wird die Identität Ihres Git-Servers bei der Verbindung überprüft, um Sie vor Person-in-the-Middle-Angriffen (PITM) zu schützen. Der Parameter Git Server Fingerprint ist zwar optional, aber wenn Sie ihn konfigurieren, stellt GitSync nur eine Verbindung zu Ihrem bestätigten Git-Host her.

So konfigurieren Sie das Anpinnen von Host-Fingerprints:

Host-Fingerabdruck abrufen: Führen Sie ssh-keyscan in Ihrem Terminal für den Hostnamen Ihres Git-Servers aus:
```
ssh-keyscan -t rsa <hostname>
```
Führen Sie für GitHub beispielsweise ssh-keyscan -t rsa github.com aus. Der Befehl gibt eine Zeile mit einem öffentlichen Hostschlüssel aus, die in etwa so aussieht:
```
github.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC...
```
Fingerabdruck für die Konfiguration speichern: Kopieren Sie die Zeile mit dem öffentlichen Hostschlüssel. Geben Sie diesen Wert in den Parameter Git-Server-Fingerabdruck ein, wenn Sie die GitSync-Integrationsinstanz konfigurieren (um ihn auf alle Jobs anzuwenden) oder bei einzelnen Synchronisierungsjobs (um die Einstellung für bestimmte Hosts zu überschreiben).

Playbook-Berechtigungen konfigurieren

Wenn Sie Playbooks mit eingeschränkten Berechtigungen synchronisieren (z. B. Standardberechtigungen auf Kann ansehen festgelegt), weisen Sie der SOC-Rolle Administrator die Berechtigung Kann bearbeiten zu:

Rufen Sie in Google SecOps Playbooks auf und wählen Sie das Ziel-Playbook aus.
Öffnen Sie die Einstellungen für Playbook-Berechtigungen.
Fügen Sie der Liste der Einheiten die Administrator-SOC-Rolle hinzu und legen Sie die Berechtigung auf Kann bearbeiten fest.

Migration von Umgebungen mit aktivierter Chronicle API

In diesem Abschnitt finden Sie Anleitungen zum Migrieren einer vorhandenen GitSync-Bereitstellung und eines Repository-Zweigs zu einer Chronicle API-fähigen Umgebung (unterstützt ab GitSync-Version 53.0).

Eine Anleitung zur Migration Ihrer gesamten Google SecOps-Plattform, Identitätsgruppen, IAM-Berechtigungen und API-Endpunkte zu Google Cloudfinden Sie in der Übersicht zur Google SecOps-Migration.

Updates in Umgebungen, in denen die Chronicle API aktiviert ist

Ab Version 53.0 enthält GitSync die folgenden Updates für Umgebungen, in denen die Chronicle API aktiviert ist:

Automatisierte IAM-Authentifizierung: GitSync stellt über Chronicle REST APIs eine Verbindung zu Google SecOps her und authentifiziert sich automatisch zur Laufzeit mit Google Cloud IAM.
Aktualisiertes Konfigurationsschema: Exportierte JSON-Konfigurationsdateien verwenden Chronicle API-Ressourcen-IDs und Feldformate, wodurch sie mit Repository-Branches vor der Migration inkompatibel sind.
Spezielle Optionen für die Blocksynchronisierung: Playbook-Synchronisierungsjobs enthalten die Option Playbook-Blöcke einbeziehen, um wiederverwendbare Workflowblöcke zusammen mit Playbooks zu exportieren oder zu importieren. Außerdem wird der Import von Blöcken aus /Playbooks oder /Blocks unterstützt.
Direkte Archivübertragungen für benutzerdefinierte Integrationen: Benutzerdefinierte Integrationspakete werden direkt als .zip-Archive hoch- und heruntergeladen. Dadurch werden die Übertragungszeiten für große Integrationen verkürzt.
Quellbezogene Ontologiezuordnungen: Die Zuordnungsregeln sind nach Integrationsquelle unter /Ontology/Mappings/<Source_Name>/ organisiert, um Konflikte zwischen Zuordnungsregeln aus verschiedenen Quellen zu vermeiden.
Automatisches Filtern von integrierten Systemstandardwerten: GitSync schließt integrierte schreibgeschützte Systemelemente (z. B. Standard-System-Tags und integrierte Systeminstanzen) während der Synchronisierung automatisch aus, um Berechtigungsfehler zu vermeiden.

Repository-Branch migrieren

In Chronicle API-fähigen Umgebungen und Legacy-Umgebungen werden unterschiedliche JSON-Konfigurationsformate verwendet. Sie können nicht gleichzeitig mit demselben Branch synchronisiert werden. Wählen Sie entweder einen dedizierten Zweig (empfohlen) oder einen vorhandenen Zweig aus:

Option 1: Empfohlener Workflow mit dediziertem Branch

Wenn Sie einen neuen Branch erstellen, werden Ihre aktualisierten Chronicle API-Konfigurationen isoliert und ein unverändertes Archiv Ihrer Konfigurationen vor der Migration wird beibehalten, ohne den Branchverlauf zu ändern:

Baseline-Legacy-Push: Bevor Ihre Instanz migriert wird, führen Sie einen vollständigen Push Content-Job (Inhalte übertragen) aus Ihrer bestehenden Umgebung aus, um ein sauberes Backup in Ihrem Legacy-Branch (z. B. main) zu speichern.
Neuen Git-Branch erstellen: Erstellen Sie einen neuen, dedizierten Branch in Ihrem Git-Repository (z. B. git checkout -b gitsync-chronicle-api && git push origin gitsync-chronicle-api).
Integrationsinstanz aktualisieren und neu konfigurieren: Achten Sie in Ihrer Chronicle API-fähigen Umgebung darauf, dass GitSync im Content Hub auf Version 53.0 oder höher aktualisiert wird. Gehen Sie dann zu Einstellungen> „Integrationen“ > „GitSync“, aktualisieren Sie den Parameter Branch auf gitsync-chronicle-api und prüfen Sie die Verbindung mit der Aktion Ping.
Erste API-basierte Push-Baseline: Führen Sie einen vollständigen Push Content-Job (Inhalte übertragen) über die Chronicle API-basierte Instanz aus, um den neuen Branch mit den aktualisierten Konfigurationsdateien zu füllen.
Pull-Synchronisierung überprüfen und aktivieren: Prüfen Sie das Repository, um die Dateistrukturen zu überprüfen, und aktivieren Sie dann nach Bedarf geplante Pull Content-Jobs.

Option 2: Vorhandenen Zweig wiederverwenden

Wenn für automatisierte CI/CD-Pipelines oder Branch-Richtlinien der Name eines vorhandenen Branch beibehalten werden muss, führen Sie die folgenden Schritte für die Umstellung aus:

Regeln für den Schutz von Zweigen:GitSync überträgt Commits direkt an das Remote-Repository und erstellt keine Pull-Anfragen. Wenn für Ihren vorhandenen Branch (z. B. main) Branch-Schutzregeln erzwungen werden, die Pull-Anfragen oder Genehmigungen für die Überprüfung erfordern, schlagen direkte Push-Vorgänge von GitSync fehl.

Bevor Sie diese Vorgehensweise ausführen, muss Ihr Repository-Administrator eine Ausnahme konfigurieren, die es dem GitSync-Bereitstellungsschlüssel oder -Konto erlaubt, Änderungen direkt in den Branch zu übertragen. Alternativ können Sie Option 1 mit einem dedizierten Branch verwenden und Änderungen über Ihren Standard-Pull-Anfrage-Workflow in main zusammenführen.

Legacy-Sicherungs-Tag erstellen: Erstellen Sie ein Git-Release-Tag Ihrer Legacy-Konfigurationen als historisches Archiv.
```
git tag backup-legacy-pre-migration
git push origin backup-legacy-pre-migration
```
Synchronisierungsjobs pausieren: Deaktivieren Sie aktive geplante GitSync-Jobs (Inhalte übertragen und Inhalte abrufen), um gleichzeitige Schreibvorgänge während der Umstellung zu verhindern.

Inhalte des alten Zweigs entfernen: Entfernen Sie die alten Verzeichnisse aus dem Zweig.

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

GitSync aktualisieren und API-fähige Baseline übertragen: Achten Sie in Ihrer Chronicle-Instanz mit aktivierter API darauf, dass GitSync im Content Hub auf Version 53.0 oder höher aktualisiert ist. Führen Sie nach der Bestätigung einen vollständigen Push Content-Job aus, um den bereinigten Zweig mit aktualisierten Konfigurationsdateien zu füllen.
Geplante Synchronisierung fortsetzen: Prüfen Sie die exportierten Dateien in Ihrem Repository und aktivieren Sie geplante GitSync-Jobs in der Chronicle API-fähigen Instanz wieder.

Integration konfigurieren

Konfigurieren Sie die GitSync-Integration als gemeinsame Instanz in Google SecOps, damit alle Plattformkomponenten und geplanten Jobs auf Repository-Konfigurationen zugreifen können.

GitSync-Integrationsparameter

Parameter	Beschreibung
`Repo URL`	Erforderlich. Die URL des Remote-Git-Repositorys. Bei der Verwendung der HTTPS-Authentifizierung muss die URL mit `https://` beginnen (z. B. `https://github.com/organization/secops-platform.git`). Bei der SSH-Authentifizierung muss die URL mit `git@` oder `ssh://` beginnen (z. B. `git@github.com:organization/secops-platform.git`).
`Branch`	Erforderlich. Der Git-Repository-Zweig, mit dem synchronisiert werden soll (z. B. `main` oder `gitsync-chronicle-api`).
`Git Password/Token/SSH Key`	Erforderlich. Die Anmeldedaten für die Authentifizierung für das Remote-Git-Repository. Für diesen Parameter kann ein Git-Kontopasswort, ein persönliches Zugriffstoken (Personal Access Token, PAT) oder ein base64-codierter privater SSH-Schlüssel (RSA mit 2048 Bit oder Ed25519) verwendet werden.
`Git Username`	Optional. Der Nutzername des Git-Kontos. Erforderlich, wenn die Authentifizierung mit Nutzername und Passwort über HTTPS erfolgt.
`Git Server Fingerprint`	Optional. Der öffentliche SSH-Hostschlüssel Ihres Remote-Git-Servers (z. B. `github.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC...`). Wenn Sie diesen Parameter konfigurieren, wird das Anpinnen von Host-Fingerabdrücken aktiviert. So wird sichergestellt, dass GitSync ausschließlich eine Verbindung zu Ihrem bestätigten Git-Host herstellt, und das Risiko von Man-in-the-Middle-Angriffen (PITM) wird verringert. Informationen zum Abrufen dieses Werts finden Sie unter Host-Fingerprint-Pinning aktivieren.
`Commit Author`	Optional. Die mit ausgehenden Git-Commits verknüpfte Autoridentität, die von GitSync generiert wird. Das Format muss der standardmäßigen Git-Autorenschaft entsprechen: `Name <email@domain.com>` (Standardwert: `GitSync <gitsync@siemplify.co>`).
`Siemplify Verify SSL`	Erforderlich. Wenn diese Option ausgewählt ist, wird das SSL-Zertifikat des Google SecOps API-Endpunkt validiert. Standardmäßig aktiviert.
`Git Verify SSL`	Erforderlich. Wenn diese Option ausgewählt ist, validiert die Integration das SSL-Zertifikat des Remote-Git-Anbieterservers. Standardmäßig aktiviert.

Aktionen

Weitere Informationen zu Aktionen finden Sie unter Ausstehende Aktionen über „Mein Arbeitsbereich“ bearbeiten und Manuelle Maßnahme ausführen.

Ping

Mit der Aktion Ping können Sie die Netzwerkverbindung testen und die Anmeldedaten für die Authentifizierung anhand des konfigurierten Git-Repositorys und ‑Zweigs prüfen.

Aktionseingaben

Keine.

Aktionsausgaben

Die Aktion Ping liefert die folgenden Ausgaben:

Ausgabetyp der Aktion	Verfügbarkeit
Anhang im Fall-Repository	Nicht verfügbar
Link zum Fall-Repository	Nicht verfügbar
Tabelle mit Fall-Repository	Nicht verfügbar
Anreicherungstabelle	Nicht verfügbar
JSON-Ergebnis	Nicht verfügbar
Ausgabenachrichten	Verfügbar
Scriptergebnis	Verfügbar

Ausgabenachrichten

Die Aktion Ping kann die folgenden Ausgabenachrichten zurückgeben:

Ausgabemeldung	Nachrichtenbeschreibung
`Successfully executed action "Ping".`	Die Aktion wurde erfolgreich ausgeführt und die Repository-Verbindung wurde überprüft.
`Error executing action "Ping". Reason: ERROR_REASON`	Die Aktion ist fehlgeschlagen. Überprüfen Sie die Repository-URL, den Zweignamen, die Anmeldedaten oder die Netzwerkrouten.

Scriptergebnis

In der folgenden Tabelle ist der Ergebniswert des Skripts bei Verwendung der Aktion Ping aufgeführt:

Name des Scriptergebnisses	Wert
`is_success`	`true` oder `false`

Jobs

GitSync bietet 16 Synchronisierungsjobkonfigurationen (2 Jobs für die vollständige Instanz und 7 eigenständige Jobpaare) zum Verwalten von Plattform-Assets. Diese Jobs unterstützen die vollständigen Synchronisierungsbereiche auf Instanzebene und die gezielten eigenständigen Synchronisierungsbereiche.

Synchronisationsbereich und unterstützte Assets

Bei der Integration werden Synchronisierungsjobs in zwei verschiedene Betriebsbereiche unterteilt, um unterschiedlichen administrativen und Automatisierungsanforderungen gerecht zu werden:

Vollständige Instanzsynchronisierung (Push Content und Pull Content): Synchronisiert Ihre gesamte Google SecOps-Plattform in einem einzigen Bulk-Vorgang.

Dazu gehören 21 Plattform-Asset-Kategorien in drei Funktionsbereichen:
- System- und Umgebungskonfigurationen: Umgebungen, Domains, dynamische Parameter, benutzerdefinierte Listen, Netzwerke, Sperrlisten, Einstellungen für Falltitel, E-Mail-Vorlagen und Logo.
- Benachrichtigungs- und Fallverwaltung: Fall-Tags, Fallphasen, Gründe für das Schließen von Fällen, SLA-Datensätze und simulierte Fälle.
- Sicherheitsautomatisierung und ‑integrationen: Playbooks (einschließlich wiederverwendbarer Workflow-Blöcke), Integrationen, Integrationsinstanzen, Connectors, geplante Jobs, Ontologiezuordnungen und visuelle Familien.
Detaillierte Asset-Synchronisierung (eigenständige Push- und Pull-Jobs):

Bietet dedizierte Push- und Pull-Job-Paare für sieben bestimmte Assets. Verwenden Sie eigenständige Jobs, wenn Sie einzelne Komponenten entwickeln, aktualisieren oder testen möchten, ohne den Rest Ihrer Umgebung zu synchronisieren oder zu überschreiben:
- Playbooks und Workflowblöcke: Push Playbook und Pull Playbook
- Connectors: Push Connectors und Pull Connector
- Integrationen: Push Integration und Pull Integration
- Geplante Jobs: Push Job und Pull Jobs
- Ontologiezuordnungen: Push Mappings und Pull Mappings
- Familien benutzerdefinierter visueller Elemente: Push Custom Family und Pull Custom Family
- Simulierte Testläufe: Push Simulated Cases und Pull Simulated Cases

Verzeichnisstruktur des Repositorys

Wenn Sie einen ersten Push Content-Job ausführen (erforderlich, bevor Sie Pull-Jobs für einen neuen oder migrierten Branch ausführen), werden die folgende vordefinierte Verzeichnisstruktur, JSON-Konfigurationsdateien, die GitSync.json-Metadatendatei des Stammverzeichnisses und die generierte README.md-Dokumentation in Ihrem Remote-Git-Repository erstellt.

Repository-Struktur nicht manuell ändern:GitSync basiert auf diesem vordefinierten Verzeichnislayout und der GitSync.json-Metadatendatei im Stammverzeichnis, um Plattform-Assets zu verfolgen und aufzulösen. Wenn Sie Dateien manuell umbenennen, Verzeichnisse verschieben oder das Repository durch benutzerdefinierte Commits umstrukturieren, kann es passieren, dass Synchronisierungsjobs fehlschlagen.

├── 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

Synchronisierungsjobs auf Instanzebene

Bei Jobs auf Instanzebene werden ausgewählte Asset-Kategorien in einer gesamten Google SecOps-Instanz synchronisiert.

Inhalte pushen

Mit dem Job Inhalte übertragen können Sie ausgewählte Asset-Kategorien aus Ihrer Google SecOps-Instanz exportieren und in den konfigurierten Git-Repository-Branch übertragen. Führen Sie beim Initialisieren eines neuen Zweigs oder bei der Migration zu einer Chronicle API-fähigen Umgebung immer zuerst Push Content aus.

Job-Eingaben

Verwenden Sie die folgenden Parameter, um den Job Push Content zu konfigurieren:

Parameter	Beschreibung
`Commit`	Erforderlich. Die Git-Commit-Nachricht, in der die Änderungen am exportierten Inhalt beschrieben werden.
`Commit Passwords`	Optional. Wenn diese Option ausgewählt ist, werden für konfigurierte Integrationsinstanzen, Connectors und Jobs `Password`-Parameter im Nur-Text-Format exportiert. Achtung:Aktivieren Sie diese Option niemals in öffentlichen oder gemeinsam genutzten Repositories, da dadurch Anmeldedaten im Klartext offengelegt werden. Auch wenn `Commit Passwords` deaktiviert ist, werden Parameter, die nicht vom Typ `Password` sind (z. B. Anwendungs-IDs, Client-IDs, Nutzernamen und URLs), immer im Klartext exportiert.
Parameter für die Auswahl von Assets: `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`	Optional (boolesche Ein/Aus-Schalter). Wählen Sie alle Asset-Kategorien aus, die Sie in den Export aufnehmen möchten.
`Repo URL`	Optional. Überschreibt die in der Integrationsinstanz konfigurierte Repository-URL.
`Branch`	Optional. Überschreibt den in der Integrationsinstanz konfigurierten Repository-Branch.
`Commit Author`	Optional. Überschreibt den in der Integrationsinstanz konfigurierten Commit-Autor. Muss das Format `Name <email@domain.com>` haben.
`Git Server Fingerprint`	Optional. Überschreibt den in der Integrationsinstanz konfigurierten SSH-Host-Fingerabdruck.

Jobausgaben

Der Job schreibt JSON-Konfigurationsdateien und README.md-Zusammenfassungen in den Ziel-Git-Branch unter der Standardverzeichnishierarchie (/Playbooks, /Connectors, /Integrations, /Jobs, /Ontology/Mappings, /Ontology/VisualFamilies, /SimulatedCases und /Settings) und gibt Ausführungsprotokolle in der Job-Runner-Konsole aus. Benutzerdefinierte Integrationen werden als vollständige Pakete exportiert, bei kommerziellen Integrationen werden nur benutzerdefinierte Scripts oder Änderungen exportiert, die der Integration hinzugefügt wurden.

Inhalte abrufen

Mit dem Job Inhalte abrufen können Sie ausgewählte Konfigurationskategorien aus dem konfigurierten Git-Repository-Branch abrufen und auf die Google SecOps-Plattform anwenden.

Job-Eingaben

Verwenden Sie die folgenden Parameter, um den Job Inhalte abrufen zu konfigurieren:

Parameter	Beschreibung
Parameter für die Auswahl von Assets: `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`	Optional (boolesche Ein/Aus-Schalter). Wählen Sie die einzelnen Asset-Kategorien aus, die Sie aus dem Repository in Ihre Umgebung importieren möchten.
`Repo URL`	Optional. Überschreibt die in der Integrationsinstanz konfigurierte Repository-URL.
`Branch`	Optional. Überschreibt den in der Integrationsinstanz konfigurierten Repository-Branch.
`Git Server Fingerprint`	Optional. Überschreibt den in der Integrationsinstanz konfigurierten SSH-Host-Fingerabdruck.

Jobausgaben

Beim Job werden die ausgewählten Repository-Definitionen in die Plattform importiert, Integrationsinstanzen, Playbooks, Connectors, Jobs, Ontologiezuordnungen und Einstellungen erstellt oder aktualisiert und Ausführungsprotokolle in der Job-Runner-Konsole ausgegeben.

Eigenständige Synchronisierungsjobs

Mit eigenständigen Jobs können bestimmte Assets synchronisiert werden, ohne dass das gesamte Repository synchronisiert werden muss.

Playbook pushen

Mit dem Job Push Playbook können Sie einzelne Playbooks oder wiederverwendbare Workflowblöcke in Git exportieren.

Job-Eingaben

Verwenden Sie die folgenden Parameter, um den Job Push Playbook zu konfigurieren:

Parameter	Beschreibung
`Commit`	Erforderlich. Die Git-Commit-Nachricht, in der die Playbook-Änderungen beschrieben werden.
`Playbook Whitelist`	Optional. Eine durch Kommas getrennte Liste mit genauen, case-sensitiven Namen von Playbooks oder Blöcken, die exportiert werden sollen. Geben Sie entweder `Playbook Whitelist` oder `Folders Whitelist` an.
`Folders Whitelist`	Optional. Eine durch Kommas getrennte Liste von Namen von Playbook-Ordnern (Kategorien). Alle Playbooks und Blöcke in diesen Ordnern werden exportiert.
`Include Playbook Blocks`	Optional. Wenn diese Option ausgewählt ist, werden wiederverwendbare Workflowblöcke zusammen mit den ausgewählten Playbooks exportiert, einschließlich aller Blöcke, auf die in diesen Playbooks als Schritte verwiesen wird.
`Repo URL`	Optional. Überschreibt die Standard-Repository-URL.
`Branch`	Optional. Überschreibt den Standardzweig.
`Commit Author`	Optional. Überschreibt den Standardautor für Commits.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen Fingerabdruck des SSH-Hosts.
`Readme Addon`	Optional. Benutzerdefinierte Inhalte, die an die generierte `README.md` für alle Playbooks angehängt werden, die in diesem Lauf übertragen und in der `GitSync.json`-Metadatendatei im Stammverzeichnis gespeichert werden. Unterstützt sowohl die Markdown-Syntax als auch Jinja-Vorlagen.

Jobausgaben

Exportiert ausgewählte Playbooks und die enthaltenen Workflowblöcke nach /Playbooks/<Folder_Name>/<Playbook_Name>/ und aktualisiert /Playbooks/README.md.

Playbook abrufen

Verwenden Sie den Job Pull Playbook, um bestimmte Playbooks oder Blöcke aus Git zu importieren.

Job-Eingaben

Verwenden Sie die folgenden Parameter, um den Job Pull Playbook zu konfigurieren:

Parameter	Beschreibung
`Playbook Whitelist`	Erforderlich. Eine durch Kommas getrennte Liste mit den genauen Namen der Playbooks oder Blöcke, die aus dem Repository importiert werden sollen.
`Include Playbook Blocks`	Optional. Wenn diese Option ausgewählt ist, werden alle wiederverwendbaren Workflowblöcke, auf die in den ausgewählten Playbooks verwiesen wird, automatisch importiert.
`Repo URL`	Optional. Überschreibt die Standard-Repository-URL.
`Branch`	Optional. Überschreibt den Standardzweig.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen Fingerabdruck des SSH-Hosts.

Jobausgaben

Importiert die angegebenen Playbooks und Blöcke aus /Playbooks (oder /Blocks) in die Plattform und installiert zuerst die referenzierten Blöcke, bevor die übergeordneten Playbooks installiert werden.

Push-Connectors

Mit dem Job Push Connectors können Sie Connector-Konfigurationen in Git exportieren.

Job-Eingaben

Verwenden Sie die folgenden Parameter, um den Push Connectors-Job zu konfigurieren:

Parameter	Beschreibung
`Connectors`	Erforderlich. Eine durch Kommas getrennte Liste der Anzeigenamen der zu exportierenden Connectors.
`Commit`	Erforderlich. Die Git-Commit-Nachricht.
`Include Mappings`	Optional. Wenn diese Option ausgewählt ist, werden die Datensätze und Regeln für die Ontologiezuordnung, die mit der Integration des Connectors verknüpft sind, nach `/Ontology/Mappings` exportiert.
`Include Visual Families`	Optional. Wenn diese Option ausgewählt ist, werden die benutzerdefinierten visuellen Familien, die den Ontologiedatensätzen des Connectors zugeordnet sind, nach `/Ontology/VisualFamilies` exportiert.
`Repo URL`	Optional. Überschreibt die Standard-Repository-URL.
`Branch`	Optional. Überschreibt den Standardzweig.
`Commit Author`	Optional. Überschreibt den Standardautor für Commits.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen Fingerabdruck des SSH-Hosts.
`Readme Addon`	Optional. Benutzerdefinierte Inhalte, die an die generierte `README.md` für alle Connectors angehängt werden, die in diesem Lauf übertragen und in `GitSync.json` gespeichert werden. Unterstützt sowohl die Markdown-Syntax als auch Jinja-Vorlagen.

Jobausgaben

Exportiert Connector-Einstellungen und Zeitpläne nach /Connectors/<Integration_Name>/<Connector_Name>/ (sowie zugehörige Ontologiezuordnungen und visuelle Familien, falls ausgewählt).

Pull-Connector

Verwenden Sie den Job Pull Connector, um eine Connector-Konfiguration aus Git zu importieren. Bevor Sie diesen Job ausführen, muss die zugrunde liegende Integration des Connectors bereits in der Zielumgebung installiert sein.

Job-Eingaben

Verwenden Sie die folgenden Parameter, um den Pull Connector-Job zu konfigurieren:

Parameter	Beschreibung
`Connector Name`	Erforderlich. Der Anzeigename des Connectors, der aus dem Repository importiert werden soll.
`Include Mappings`	Optional. Wenn diese Option ausgewählt ist, werden die Ontologiezuordnungen importiert, die mit der Integration des Connectors verknüpft sind.
`Include Visual Families`	Optional. Wenn diese Option ausgewählt ist, werden die benutzerdefinierten visuellen Familien importiert, die mit der Integration des Connectors verknüpft sind.
`Repo URL`	Optional. Überschreibt die Standard-Repository-URL.
`Branch`	Optional. Überschreibt den Standardzweig.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen Fingerabdruck des SSH-Hosts.

Jobausgaben

Installiert oder aktualisiert den Connector in der Zielumgebung (zusammen mit zugehörigen Zuordnungen oder visuellen Familien, falls ausgewählt).

Push-Integration

Mit dem Job Push Integration können Sie benutzerdefinierte Integrationen oder benutzerdefinierte Skripts, die kommerziellen Integrationen hinzugefügt wurden, in Git exportieren. Benutzerdefinierte Integrationen werden als vollständige Integrationspakete exportiert, während bei kommerziellen Integrationen nur benutzerdefinierte Scripts oder Änderungen exportiert werden, die der Integration hinzugefügt wurden.

Job-Eingaben

Verwenden Sie die folgenden Parameter, um den Job Push Integration zu konfigurieren:

Parameter	Beschreibung
`Push Whitelist`	Erforderlich. Eine durch Kommas getrennte Liste der zu exportierenden Integrationskennungen.
`Commit`	Erforderlich. Die Git-Commit-Nachricht.
`Repo URL`	Optional. Überschreibt die Standard-Repository-URL.
`Branch`	Optional. Überschreibt den Standardzweig.
`Commit Author`	Optional. Überschreibt den Standardautor für Commits.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen Fingerabdruck des SSH-Hosts.
`Readme Addon`	Optional. Benutzerdefinierte Inhalte, die an die generierte `README.md` für alle Integrationen angehängt werden, die in diesem Lauf übertragen und in `GitSync.json` gespeichert wurden. Unterstützt sowohl die Markdown-Syntax als auch Jinja-Vorlagen.

Jobausgaben

Exportiert Integrationsdefinitionen, benutzerdefinierte Scripts (Actions/, Connectors/, Jobs/, Managers/), Abhängigkeiten und README.md-Dokumentation nach /Integrations/<Integration_Identifier>/.

Pull-Integration

Mit dem Job Pull Integration können Sie benutzerdefinierte Integrationen oder benutzerdefinierte Skripts für kommerzielle Integrationen aus Git importieren. Bei kommerziellen Integrationen wird mit GitSync die neueste Version der Integration aus dem Content Hub installiert und die benutzerdefinierten Scripts darin gespeichert.

Job-Eingaben

Verwenden Sie die folgenden Parameter, um den Job Pull Integration zu konfigurieren:

Parameter	Beschreibung
`Install Whitelist`	Erforderlich. Eine durch Kommas getrennte Liste von Integrationskennungen, die aus dem Repository importiert werden sollen.
`Repo URL`	Optional. Überschreibt die Standard-Repository-URL.
`Branch`	Optional. Überschreibt den Standardzweig.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen Fingerabdruck des SSH-Hosts.

Jobausgaben

Installiert benutzerdefinierte Integrationspakete oder kommerzielle Integrationen aus dem Content Hub und aktualisiert die benutzerdefinierten Skripts in der Zielumgebung.

Push-Job

Verwenden Sie den Job Push Job, um geplante Plattformjobkonfigurationen in Git zu exportieren.

Job-Eingaben

Verwenden Sie die folgenden Parameter, um den Job Push Job zu konfigurieren:

Parameter	Beschreibung
`Job Whitelist`	Erforderlich. Eine durch Kommas getrennte Liste der Namen der zu exportierenden geplanten Jobs.
`Commit`	Erforderlich. Die Git-Commit-Nachricht.
`Repo URL`	Optional. Überschreibt die Standard-Repository-URL.
`Branch`	Optional. Überschreibt den Standardzweig.
`Commit Author`	Optional. Überschreibt den Standardautor für Commits.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen Fingerabdruck des SSH-Hosts.
`Readme Addon`	Optional. Benutzerdefinierte Inhalte, die an die generierte `README.md` für alle Jobs angehängt werden, die in diesem Lauf übertragen und in `GitSync.json` gespeichert werden. Unterstützt sowohl die Markdown-Syntax als auch Jinja-Vorlagen.

Jobausgaben

Exportiert Jobparameter und Zeitplanintervalle nach /Jobs/<Job_Name>.json und aktualisiert /Jobs/README.md.

Pull-Jobs

Verwenden Sie den Job Pull Jobs, um geplante Plattformjobs aus Git zu importieren.

Job-Eingaben

Verwenden Sie die folgenden Parameter, um den Job Pull Jobs zu konfigurieren:

Parameter	Beschreibung
`Job Whitelist`	Erforderlich. Eine durch Kommas getrennte Liste der Namen geplanter Jobs, die aus dem Repository importiert werden sollen.
`Repo URL`	Optional. Überschreibt die Standard-Repository-URL.
`Branch`	Optional. Überschreibt den Standardzweig.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen Fingerabdruck des SSH-Hosts.

Jobausgaben

Konfiguriert und registriert die angegebenen geplanten Jobs im Jobplaner der Plattform.

Push-Zuordnungen

Mit dem Job Push Mappings können Sie Ontologie-Ereigniszuordnungsdatensätze und ‑regeln für eine bestimmte Quelle in Git exportieren.

Job-Eingaben

Verwenden Sie die folgenden Parameter, um den Job Push Mappings zu konfigurieren:

Parameter	Beschreibung
`Source`	Erforderlich. Die Ontologiequelle (Integrationsname), deren Zuordnungsdatensätze und ‑regeln Sie exportieren möchten.
`Commit`	Erforderlich. Die Git-Commit-Nachricht.
`Repo URL`	Optional. Überschreibt die Standard-Repository-URL.
`Branch`	Optional. Überschreibt den Standardzweig.
`Commit Author`	Optional. Überschreibt den Standardautor für Commits.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen Fingerabdruck des SSH-Hosts.
`Readme Addon`	Optional. Benutzerdefinierte Inhalte, die an die generierte `README.md` für alle Zuordnungen angehängt werden, die in diesem Lauf übertragen und in `GitSync.json` gespeichert wurden. Unterstützt sowohl die Markdown-Syntax als auch Jinja-Vorlagen.

Jobausgaben

Schreibt Ontologiedatensätze (<Source>_Records.json), Zuordnungsregeln (<Source>_Rules.json) und README.md in /Ontology/Mappings/<Source>/.

Zuordnungen abrufen

Mit dem Job Pull Mappings (Zuweisungen abrufen) können Sie Ontologiezuordnungsdatensätze und ‑regeln für eine bestimmte Quelle aus Git importieren.

Job-Eingaben

Verwenden Sie die folgenden Parameter, um den Job Pull Mappings zu konfigurieren:

Parameter	Beschreibung
`Source`	Erforderlich. Die Ontologiequelle (Integrationsname), deren Zuordnungsdatensätze und ‑regeln Sie importieren möchten.
`Repo URL`	Optional. Überschreibt die Standard-Repository-URL.
`Branch`	Optional. Überschreibt den Standardzweig.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen Fingerabdruck des SSH-Hosts.

Jobausgaben

Registriert Regeln für die Ontologiezuordnung und Zuweisungen visueller Familien in den Ontologieeinstellungen der Plattform. Zuweisungen werden in der Tabelle „Ontologiestatus“ angezeigt, nachdem entsprechende Ereignisse erfasst wurden.

Benutzerdefinierte Familie pushen

Mit dem Job Push Custom Family (Benutzerdefinierte Familie übertragen) können Sie benutzerdefinierte Definitionen und Symbole für visuelle Familien in Git exportieren.

Job-Eingaben

Verwenden Sie die folgenden Parameter, um den Job Push Custom Family zu konfigurieren:

Parameter	Beschreibung
`Family Name`	Erforderlich. Eine durch Kommas getrennte Liste der Namen von benutzerdefinierten Visualisierungsfamilien, die exportiert werden sollen.
`Commit`	Erforderlich. Die Git-Commit-Nachricht.
`Repo URL`	Optional. Überschreibt die Standard-Repository-URL.
`Branch`	Optional. Überschreibt den Standardzweig.
`Commit Author`	Optional. Überschreibt den Standardautor für Commits.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen Fingerabdruck des SSH-Hosts.
`Readme Addon`	Optional. Benutzerdefinierte Inhalte, die an die generierte `README.md` für alle benutzerdefinierten visuellen Familien angehängt werden, die in diesem Lauf übertragen und in `GitSync.json` gespeichert wurden. Unterstützt sowohl die Markdown-Syntax als auch Jinja-Vorlagen.

Jobausgaben

Exportiert visuelle Familiendefinitionen (<Family_Name>.json), Symbolbilddateien (<Family_Name>.png) und README.md nach /Ontology/VisualFamilies/<Family_Name>/.

Benutzerdefinierte Familie abrufen

Mit dem Job Pull Custom Family können Sie eine benutzerdefinierte Definition und ein Symbol für eine benutzerdefinierte visuelle Familie aus Git importieren.

Job-Eingaben

Verwenden Sie die folgenden Parameter, um den Job Pull Custom Family zu konfigurieren:

Parameter	Beschreibung
`Family Name`	Erforderlich. Der genaue Name der benutzerdefinierten visuellen Familie, die importiert werden soll.
`Repo URL`	Optional. Überschreibt die Standard-Repository-URL.
`Branch`	Optional. Überschreibt den Standardzweig.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen Fingerabdruck des SSH-Hosts.

Jobausgaben

Importiert die Definition und das Symbol der benutzerdefinierten visuellen Familie in die Ontologie-Einstellungen der Plattform.

Simulierte Fälle pushen

Verwenden Sie den Job Push Simulated Cases, um simulierte Testläufe in Git zu exportieren.

Job-Eingaben

Verwenden Sie die folgenden Parameter, um den Job Push Simulated Cases zu konfigurieren:

Parameter	Beschreibung
`Simulated Cases`	Erforderlich. Eine durch Kommas getrennte Liste der Namen der zu exportierenden simulierten Fälle.
`Commit`	Erforderlich. Die Git-Commit-Nachricht.
`Repo URL`	Optional. Überschreibt die Standard-Repository-URL.
`Branch`	Optional. Überschreibt den Standardzweig.
`Commit Author`	Optional. Überschreibt den Standardautor für Commits.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen Fingerabdruck des SSH-Hosts.

Jobausgaben

Exportiert simulierte Fälle als .case-Dateien nach /SimulatedCases/<Case_Name>.case.

Simulierte Fälle abrufen

Verwenden Sie den Job Pull Simulated Cases, um simulierte Testläufe aus Git zu importieren.

Job-Eingaben

Verwenden Sie die folgenden Parameter, um den Job Pull Simulated Cases zu konfigurieren:

Parameter	Beschreibung
`Simulated Cases`	Erforderlich. Eine durch Kommas getrennte Liste der Namen der simulierten Fälle, die aus dem Repository importiert werden sollen.
`Repo URL`	Optional. Überschreibt die Standard-Repository-URL.
`Branch`	Optional. Überschreibt den Standardzweig.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen Fingerabdruck des SSH-Hosts.

Jobausgaben

Importiert die angegebenen simulierten Fälle in den Katalog der simulierten Fälle der Plattform.

Fehlerbehebung

In der folgenden Tabelle finden Sie Schritte zur Behebung häufiger Synchronisierungsfehler:

Aufgetretene Fehlermeldung	Betrieblicher Grund	Verfahren zur Problembehebung
`Authentication failed`, `401 Unauthorized` oder `Connection refused` während der Ausführung einer Aktion oder eines Jobs	Wenn Sie diese Integration auf einer nicht migrierten Legacy-Instanz (`.siemplify-soar.com`) ausführen, kommuniziert GitSync ausschließlich über Chronicle REST APIs mit Google Cloud IAM-Authentifizierung mit Google SecOps. Legacy-Plattform-API-Endpunkte (`.siemplify-soar.com/api/`) werden nicht mehr unterstützt.	Migrieren Sie Ihre Google SecOps-Plattforminstanz in eine Chronicle API-fähige Umgebung (über `secops.google.com` oder `*.chronicle.security.google.com` zugänglich). Eine Anleitung zur Migration finden Sie unter Migration in eine Chronicle API-fähige Umgebung.
`Permission denied (publickey)` oder `Host key verification failed` (oder `Authentication failed for 'https://...'`)	Die Git-Authentifizierung ist fehlgeschlagen. Mögliche Ursachen: ungültiges Anmeldedatenformat, fehlende Schreibberechtigungen für den Bereitstellungsschlüssel oder nicht übereinstimmender Host-Fingerabdruck.	SSH-Authentifizierung: Prüfen Sie, ob Ihr privater SSH-Schlüssel in einen einzeiligen Base64-String ohne nachfolgende Zeilenumbrüche oder Leerzeichen konvertiert wurde. Prüfen Sie, ob der entsprechende öffentliche Schlüssel in Ihrem Git-Repository mit Schreibzugriff registriert ist. Host-Fingerabdruck: Wenn das Anpinnen des Host-Fingerabdrucks aktiviert ist, prüfen Sie den Fingerabdruck-String mit `ssh-keyscan -t rsa <hostname>` und aktualisieren Sie den Parameter Git Server Fingerprint. HTTPS-Authentifizierung: Prüfen Sie, ob Ihr persönliches Zugriffstoken (Personal Access Token, PAT) abgelaufen ist und ob es über den Schreibbereich für das Repository verfügt.
`403 Forbidden: Insufficient permissions to modify playbook` (oder `Failed to push playbook: Access denied`)	Das Ziel-Playbook hat eingeschränkte Standardzugriffsberechtigungen (z. B. Can View) und der `Administrator`-SOC-Rolle wurde im Quellsystem keine Can Edit-Berechtigung gewährt.	Rufen Sie in Google SecOps Playbooks auf, wählen Sie das betroffene Playbook aus, öffnen Sie die Berechtigungseinstellungen und fügen Sie die `Administrator` SOC-Rolle mit der Berechtigung Kann bearbeiten hinzu. Eine detaillierte Anleitung finden Sie unter Playbook-Berechtigungen konfigurieren.
Der Job Inhalte abrufen oder Integration abrufen läuft nach 5 Minuten ab.	Beim Installieren mehrerer kommerzieller Integrationen aus dem Content Hub während eines einzelnen Pull-Vorgangs wurde das Zeitlimit von 5 Minuten für die Jobausführung überschritten.	Installieren Sie die erforderlichen kommerziellen Integrationen manuell über den Content-Hub, bevor Sie Inhalte abrufen ausführen, oder führen Sie den Job Inhalte abrufen noch einmal aus, um die verbleibenden Assets zu importieren.
`General error performing Job Pull Content` (oder `400 Bad Request` / `404 Not Found`, wenn Daten aus einem vorhandenen Legacy-Zweig abgerufen werden)	Es wird versucht, einen Repository-Zweig mit Legacy-Konfigurationsdateien vor der Migration in eine Chronicle API-fähige Umgebung zu übertragen.	Führen Sie zuerst einen vollständigen Push Content-Job in Ihrer Chronicle API-fähigen Umgebung aus, um den Branch mit aktualisierten Konfigurationsdateien zu füllen, bevor Sie Pull-Jobs ausführen. Prüfen Sie, ob die Integrationsinstanz mit dem richtigen Chronicle API-aktivierten Branch konfiguriert ist (siehe Migration von Chronicle API-aktivierten Umgebungen).
`Playbook '<Playbook_Name>' is assigned to environment(s) that don't exist`	Ein Playbook oder Block, der importiert wird, wird einer Umgebung oder Umgebungsgruppe zugewiesen, die in der Zielinstanz nicht erstellt wurde.	Führen Sie zuerst Inhalte abrufen mit der Option Umgebungen aus oder erstellen Sie die fehlende Umgebung manuell in der Zielinstanz unter Einstellungen > Umgebungen, bevor Sie Playbooks abrufen.
`Commit Author parameter must be in the following format: Name <example@gmail.com>`	Für den Parameter Commit Author in der Integrationsinstanz oder Jobkonfiguration fehlt eine E‑Mail-Adresse in spitzen Klammern.	Aktualisieren Sie den Parameter Commit Author (Autor des Commits) so, dass er dem erforderlichen Format entspricht: `Name <email@domain.com>` (z. B. `GitSync <gitsync@example.com>`).
`400 Bad Request` oder `409 Conflict` beim Importieren von Ontologiezuordnungen	Die Regeln für die Ereigniszuordnung im Repository stehen im Konflikt mit vorhandenen Regeln der Plattformontologie oder wurden mit einer älteren GitSync-Version exportiert.	Führen Sie einen neuen Push Mappings-Job in Ihrer Chronicle API-fähigen Umgebung aus, um Zuordnungsdefinitionen neu zu exportieren, oder beheben Sie doppelte Event-Zuordnungsregeln unter Einstellungen > Ontologie > Zuordnungsregeln, bevor Sie den Job noch einmal ausführen.

Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten