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

GitSync

GitSync ist eine für Google SecOps entwickelte Integration, die Assets und Komponenten für die Sicherheitsautomatisierung mit einem externen Git-Repository (z. B. GitHub, GitLab oder Bitbucket) synchronisiert. Sie ermöglicht die bidirektionale Synchronisierung von Inhalten und bietet automatisierte Versionsverwaltung, Konfigurationssicherung und umgebungsübergreifende Bereitstellung im gesamten Lebenszyklus Ihrer Sicherheitsvorgänge. GitSync ist für die Sicherung und Migration von Assets zwischen verwandten Umgebungen (z. B. Entwicklung, Staging und Produktion) konzipiert und nicht für die Verteilung von Assets auf nicht verwandte Systeme, bei denen interne Datenbankkennungen zu Konflikten führen können.

Anwendungsfälle

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

Versionsverwaltung und Prüfbarkeit (Security as Code): Sie können Änderungen nachverfolgen, Unterschiede prüfen und einen vollständigen Versionsverlauf der Änderungen in Playbooks, Connectors, Integrationen und Systemeinstellungen verwalten.
Hochstufung in mehreren Umgebungen (CI/CD-Pipeline): Playbooks, Ontologiezuordnungen und Integrationseinstellungen werden systematisch über Pull-Anfragen und Branch-Zusammenführungen von Entwicklungs- und Staging-Umgebungen in die Produktion hochgestuft.
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.
Isolierung von Verzweigungen und Staging: Testen Sie experimentelle Playbooks und Feature-Verzweigungen in dedizierten Umgebungen, ohne die Produktionsworkflows oder ‑zeitpläne zu beeinträchtigen.
Offline-Überprüfung und Zusammenarbeit: Exportieren Sie Plattformdefinitionen als JSON und Markdown, um Peer-Reviews, automatisierte Validierung und Inspektion in Standard-Entwicklertools zu ermöglichen.
Wiederverwendbare Workflow-Blöcke: Synchronisieren Sie modulare Workflow-Blöcke zusammen mit oder getrennt von vollständigen Playbooks, damit Teams gängige Automatisierungsschritte gemeinsam nutzen können.

Implementierungs-Workflows nach Ziel

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 erstellen, folgen Sie dieser End-to-End-Einrichtungssequenz:
1. Sorgen Sie dafür, dass die Voraussetzungen erfüllt sind und die Anmeldedaten eingerichtet wurden.
2. Konfigurieren Sie die freigegebene Integrationsinstanz.
3. Testen Sie die Netzwerkverbindung und die Authentifizierung mit der Ping-Aktion.
4. Führen Sie einen ersten Push-Inhaltsjob aus, um den Zweig zu füllen, bevor Sie Pull-Jobs ausführen.
5. Automatisierte Synchronisierungsjobs konfigurieren und planen.
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 Standard-Repository-Layout finden Sie unter Repository-Verzeichnisstruktur.
Probleme bei der Synchronisierung beheben: Wenn eine Aktion oder ein Job mit einem Fehler fehlschlägt, finden Sie weitere Informationen unter Fehlerbehebung.

Hinweis

Bevor Sie GitSync-Vorgänge konfigurieren und ausführen, prüfen Sie Ihre Integrationsversion, rufen Sie den Repository-Zugriff ab und führen Sie die folgenden Einrichtungsaufgaben aus:

Privates Git-Repository mit Schreibzugriff verwenden: Prüfen Sie, ob Sie Schreibberechtigungen für ein privates Remote-Git-Repository haben, das bei einem unterstützten Git-Anbieter (z. B. GitHub, GitLab oder Bitbucket) gehostet wird. Parameter vom Typ Password werden standardmäßig ausgeschlossen, sofern Commit Passwords nicht aktiviert ist. Alle anderen Parameter (z. B. Anwendungs-IDs, Client-IDs, Nutzernamen und Endpunkte) werden im Klartext exportiert. Verwenden Sie niemals ein öffentliches Repository mit GitSync.
Remote-Repository initialisieren: Prüfen Sie, ob das Remote-Repository mindestens einen ersten Commit hat (z. B. eine README.md- oder .gitignore-Datei). GitSync kann nicht mit einem leeren Repository synchronisiert werden.
Git-Authentifizierungsdaten vorbereiten: Generieren Sie Authentifizierungsdaten mit Schreibberechtigungen für das Repository. GitSync unterstützt base64-codierte private SSH-Schlüssel (empfohlen), persönliche Zugriffstokens (PATs) und einfache 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 über den TCP-Port 443 (für HTTPS) oder den TCP-Port 22 (für SSH) ausgehenden Firewallzugriff auf Ihren Git-Anbieter hat.

Wenn IhreGoogle Cloud -Umgebung einen VPC Service Controls-Dienstperimeter verwendet, wenden Sie sich an Ihren Google Cloud -Administrator, um Regeln für eingehenden 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): Rufen Sie zum Schutz vor Person-in-the-Middle-Angriffen (PITM) den Fingerabdruck des öffentlichen Schlüssels Ihres Git-Servers für das Host-Fingerabdruck-Pinning ab.

Konfigurationsschritte finden Sie unter Host-Fingerabdruck-Pinning aktivieren.
Berechtigungen zum Bearbeiten von Playbooks gewähren: Wenn Sie Playbooks mit eingeschränktem Standardzugriff synchronisieren möchten (z. B. Standardberechtigungen auf Kann ansehen festgelegt), gewähren Sie der SOC-Rolle Administrator auf dem Quellsystem die Berechtigung Kann bearbeiten, bevor Sie Synchronisierungsjobs ausführen.

Eine detaillierte Anleitung finden Sie unter Playbook-Berechtigungen konfigurieren.

SSH-Schlüssel für GitSync generieren

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

Generieren Sie in Ihrem Terminal ein RSA- oder Ed25519-Schlüsselpaar. 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-Hosting-Dienst als Bereitstellungsschlüssel oder Zugriffsschlüssel mit Schreibberechtigungen hinzu.
Konvertieren Sie den privaten Schlüssel in einen einzeiligen base64-codierten String:
- 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-Fingerabdruck-Pinning aktivieren

Durch das Host-Fingerprint-Pinning wird die Identität Ihres Git-Servers bei der Verbindung überprüft, um Schutz vor Person-in-the-Middle-Angriffen (PITM) zu bieten. Der Parameter Git Server Fingerprint ist zwar optional, aber wenn Sie ihn konfigurieren, wird sichergestellt, dass GitSync nur eine Verbindung zu Ihrem verifizierten Git-Host herstellt.

So konfigurieren Sie das Pinning von Host-Fingerabdrücken:

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 beispielsweise für GitHub ssh-keyscan -t rsa github.com aus. Die Befehlsausgabe enthält eine Zeile mit einem öffentlichen Hostschlüssel, 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 Fingerprint ein, wenn Sie die GitSync-Integrationsinstanz konfigurieren (um ihn auf alle Jobs anzuwenden) oder für einzelne 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 Darf ansehen festgelegt), weisen Sie der SOC-Rolle Administrator die Berechtigung Darf 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 die SOC-Rolle Administrator zur Liste der Entitäten hinzu und legen Sie die Berechtigung auf Bearbeiten fest.

Rollback auf Version 53.0

Mit GitSync Version 53.0 wurden Änderungen an der Chronicle API und modifizierte JSON-Exportschemas eingeführt, die zu Synchronisierungsfehlern führten. Um diese Probleme zu beheben, werden in Version 54.0 von GitSync die Änderungen aus Version 53.0 rückgängig gemacht und die stabile Codebasis von Version 52.0 wiederhergestellt.

Führen Sie die folgenden Schritte aus, um zu Version 52.0 oder Version 54.0 zu wechseln und einen kompatiblen Repository-Zweig wiederherzustellen:

Geplante Synchronisierungsjobs pausieren: Deaktivieren Sie alle aktiven geplanten GitSync-Jobs (z. B. Inhalte übertragen und Inhalte abrufen), damit keine Jobs ausgeführt werden, während Sie Versionen und Zweige wechseln.
Zu Version 54.0 wechseln oder ein Rollback auf Version 52.0 durchführen: Suchen Sie im Content Hub nach der GitSync-Integration:
- Wenn Version 54.0 verfügbar ist, aktualisieren Sie die Integration auf Version 54.0.
- Wenn Version 54.0 noch nicht angezeigt wird (Content Hub-Caches werden etwa alle 8 Stunden synchronisiert) oder wenn Sie ein direktes Downgrade bevorzugen, setzen Sie die Integrationsversion auf Version 52.0 zurück.
GitSync auf den vorherigen Repository-Zweig verweisen lassen: Repository-Zweige, die mit Version 53.0 gefüllt wurden, verwenden ein anderes JSON-Schema, das nicht mit Version 52.0 oder 54.0 kompatibel ist:
- Wenn Sie einen separaten Zweig für Version 53.0 erstellt haben (z. B. gitsync-chronicle-api): Gehen Sie zu Einstellungen > Integrationen > GitSync, ändern Sie den Parameter Zweig wieder in Ihren ursprünglichen Zweig (z. B. main) und führen Sie die Aktion Ping aus, um die Verbindung zu prüfen.
- Wenn Sie Ihren vorhandenen Branch in Version 53.0 überschrieben haben: Stellen Sie den Branch aus Ihrem Git-Tag backup-legacy-pre-migration (oder Ihrem letzten Commit vor Version 53) wieder her oder entfernen Sie die exportierten Verzeichnisse der Version 53.0 (Playbooks/, Connectors/, Integrations/, Jobs/, Ontology/, SimulatedCases/ und Settings/) und führen Sie einen vollständigen Push Content-Job aus Version 52.0 oder 54.0 aus, um den Branch neu zu füllen.
Geplante Jobs fortsetzen: Nachdem Sie bestätigt haben, dass Ihr Zweig Konfigurationen enthält, die von Version 52.0 oder 54.0 exportiert wurden, aktivieren Sie Ihre geplanten GitSync-Jobs wieder.

Regeln für den Zweigschutz: GitSync überträgt Commits direkt in das Remote-Repository und erstellt keine Pull-Anfragen. Wenn für den konfigurierten Zweig (z. B. main) Zweigschutzregeln erzwungen werden, die Pull-Anfragen oder Genehmigungen erfordern, schlagen direkte Push-Vorgänge von GitSync fehl. Achten Sie darauf, dass Ihr Repository-Administrator eine Ausnahme konfiguriert, die es dem GitSync-Bereitstellungsschlüssel oder -Konto ermöglicht, direkt in den Zielzweig zu übertragen. Alternativ können Sie GitSync so konfigurieren, dass es in einen dedizierten Zweig überträgt und Änderungen über Ihren Standard-Pull-Anfrage-Workflow in main zusammenführt.

Integration konfigurieren

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

GitSync-Integrationsparameter

Parameter	Beschreibung
`Repo URL`	Pflichtangabe. Die URL des Remote-Git-Repositorys. Bei 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`	Pflichtangabe. Der Git-Repository-Zweig, mit dem synchronisiert werden soll (z. B. `main`).
`Git Password/Token/SSH Key`	Pflichtangabe. Die Authentifizierungsdaten für das Remote-Git-Repository. Dieser Parameter akzeptiert ein Git-Kontopasswort, ein persönliches Zugriffstoken (PAT) oder einen base64-codierten privaten SSH-Schlüssel (RSA 2048-Bit oder Ed25519).
`Git Username`	Optional. Der Nutzername des Git-Kontos. Erforderlich, wenn die Authentifizierung mit Nutzername und Passwort über HTTPS verwendet wird.
`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 Host-Fingerprint-Pinning aktiviert. Dadurch wird sichergestellt, dass GitSync ausschließlich eine Verbindung zu Ihrem verifizierten Git-Host herstellt, und das Risiko von Person-in-the-Middle-Angriffen (PITM) wird verringert. Informationen zum Abrufen dieses Werts finden Sie unter Host-Fingerabdruck-Pinning aktivieren.
`Commit Author`	Optional. Die Autorenidentität, die an ausgehende Git-Commits angehängt wird, die von GitSync generiert werden. Das Format muss der Standard-Git-Urheberschaft entsprechen: `Name <email@domain.com>` (Standardwert ist `GitSync <gitsync@siemplify.co>`).
`Siemplify Verify SSL`	Pflichtangabe. Wenn diese Option ausgewählt ist, validiert die Integration das SSL-Zertifikat des Google SecOps API-Endpunkt. Standardmäßig aktiviert.
`Git Verify SSL`	Pflichtangabe. Wenn diese Option ausgewählt ist, wird das SSL-Zertifikat des Remote-Git-Anbieterservers validiert. Standardmäßig aktiviert.
`SOAR Username`	Optional. Der Google SecOps-Nutzername eines Kontos mit Berechtigungen zum Bearbeiten von Playbooks. Geben Sie diesen Parameter an, wenn der Standard-API-Schlüssel aufgrund von Berechtigungslimits fehlschlägt.
`SOAR Password`	Optional. Das Passwort, das dem konfigurierten `SOAR Username` entspricht.

Aktionen

Weitere Informationen zu Aktionen finden Sie unter Auf ausstehende Aktionen im Workdesk reagieren und Manuelle Aktion in einem Fall ausführen.

Ping

Verwenden Sie die Aktion Ping, um die Netzwerkverbindung zu testen und die Authentifizierungsdaten für das konfigurierte Git-Repository und den konfigurierten Zweig zu prüfen.

Aktionseingaben

Keine.

Aktionsausgaben

Die Aktion Ping liefert die folgenden Ausgaben:

Aktionsausgabetyp	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	Beschreibung der Nachricht
`Successfully executed action "Ping".`	Die Aktion war erfolgreich und die Repository-Verbindung wurde bestätigt.
`Error executing action "Ping". Reason: ERROR_REASON`	Die Aktion ist fehlgeschlagen. Prüfen Sie die Repository-URL, den Zweignamen, die Anmeldedaten oder die Netzwerkrouten.

Scriptergebnis

In der folgenden Tabelle sind die Skriptergebniswerte für die Aktion Ping aufgeführt:

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

Jobs

GitSync bietet 16 Konfigurationen für Synchronisierungsjobs (2 Jobs für die gesamte Instanz und 7 eigenständige Jobpaare) zum Verwalten von Plattform-Assets. Diese Jobs unterstützen die vollständige Synchronisierung auf Instanzebene und die gezielte eigenständige Synchronisierung.

Synchronisierungsumfang und unterstützte Assets

Die Integration organisiert Synchronisierungsjobs in zwei unterschiedliche operative Bereiche, um unterschiedliche Verwaltungs- und Automatisierungsanforderungen zu erfüllen:

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

Dies umfasst 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-Einträge 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-Jobpaare für sieben spezifische Assets. Verwenden Sie eigenständige Jobs, wenn Sie einzelne Komponenten entwickeln, aktualisieren oder testen, ohne den Rest Ihrer Umgebung zu synchronisieren oder zu überschreiben:
- Playbooks und Workflow-Blö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
- Benutzerdefinierte visuelle Familien: Push Custom Family und Pull Custom Family
- Simulierte Testläufe: Push Simulated Cases und Pull Simulated Cases

Repository-Verzeichnisstruktur

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

Ändern Sie die Repository-Struktur nicht manuell: GitSync verwendet dieses vordefinierte Verzeichnislayout und die Stamm-Metadatendatei GitSync.json, um Plattform-Assets zu verfolgen und aufzulösen. Das manuelle Umbenennen von Dateien, das Verschieben von Verzeichnissen oder das Umstrukturieren des Repositorys durch benutzerdefinierte Commits kann dazu führen, 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

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

Push-Inhalte

Verwenden Sie den Job Inhalte übertragen, um ausgewählte Asset-Kategorien aus Ihrer Google SecOps-Instanz zu exportieren und sie in den konfigurierten Git-Repository-Zweig zu übertragen. Führen Sie beim Initialisieren eines neuen Zweigs immer zuerst Push Content aus.

Job-Eingaben

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

Parameter	Beschreibung
`Commit`	Pflichtangabe. Die Git-Commit-Nachricht, in der die Änderungen am exportierten Inhalt beschrieben werden.
`Commit Passwords`	Optional. Wenn diese Option ausgewählt ist, werden im Job Parameter vom Typ `Password` im Klartext für konfigurierte Integrationsinstanzen, Connectors und Jobs exportiert. Achtung: Aktivieren Sie diese Option niemals in öffentlichen oder freigegebenen Repositories, da dadurch Anmeldedaten im Klartext offengelegt werden. Beachten Sie, dass Parameter, die nicht vom Typ `Password` sind (z. B. Anwendungs-IDs, Client-IDs, Nutzernamen und URLs), auch dann immer im Klartext exportiert werden, wenn `Commit Passwords` deaktiviert ist.
Parameter für die Asset-Auswahl: `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 Schalter). Wählen Sie alle Asset-Kategorien aus, die Sie in den Export einbeziehen möchten.
`Repo URL`	Optional. Überschreibt die in der Integrationsinstanz konfigurierte Repository-URL.
`Branch`	Optional. Überschreibt den in der Integrationsinstanz konfigurierten Repository-Zweig.
`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 Git-Zielzweig unter der Standardverzeichnishierarchie (/Playbooks, /Connectors, /Integrations, /Jobs, /Ontology/Mappings, /Ontology/VisualFamilies, /SimulatedCases und /Settings) und gibt Ausführungslogs in der Job-Runner-Konsole aus. Benutzerdefinierte Integrationen werden als vollständige Pakete exportiert, während bei kommerziellen Integrationen nur benutzerdefinierte Scripts oder Änderungen exportiert werden, die der Integration hinzugefügt wurden.

Inhalte abrufen

Verwenden Sie den Job Inhalte abrufen, um ausgewählte Konfigurationskategorien aus dem konfigurierten Git-Repository-Zweig abzurufen und auf die Google SecOps-Plattform anzuwenden.

Job-Eingaben

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

Parameter	Beschreibung
Parameter für die Asset-Auswahl: `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 Schalter). Wählen Sie die 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-Zweig.
`Git Server Fingerprint`	Optional. Überschreibt den in der Integrationsinstanz konfigurierten SSH-Host-Fingerabdruck.

Jobausgaben

Der Job importiert die ausgewählten Repository-Definitionen in die Plattform, erstellt oder aktualisiert Integrationsinstanzen, Playbooks, Connectors, Jobs, Ontologiezuordnungen und Einstellungen und gibt Ausführungslogs in der Job Runner-Konsole aus.

Eigenständige Synchronisierungsjobs

Eigenständige Jobs ermöglichen die detaillierte Synchronisierung bestimmter Assets, ohne dass eine vollständige Repository-Synchronisierung erforderlich ist.

Playbook für Push-Benachrichtigungen

Verwenden Sie den Job Push Playbook, um einzelne Playbooks oder wiederverwendbare Workflowblöcke nach Git zu exportieren.

Job-Eingaben

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

Parameter	Beschreibung
`Commit`	Pflichtangabe. Die Git-Commit-Nachricht, in der die Änderungen am Playbook beschrieben werden.
`Playbook Whitelist`	Optional. Eine durch Kommas getrennte Liste der genauen Playbook- oder Blocknamen, die exportiert werden sollen. Dabei wird zwischen Groß- und Kleinschreibung unterschieden. Geben Sie entweder `Playbook Whitelist` oder `Folders Whitelist` an.
`Folders Whitelist`	Optional. Eine durch Kommas getrennte Liste von Playbook-Ordnernamen (Kategorienamen). 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, die als Schritte in diesen Playbooks referenziert werden.
`Repo URL`	Optional. Überschreibt die Standard-Repository-URL.
`Branch`	Optional. Überschreibt den Standardzweig.
`Commit Author`	Optional. Überschreibt den Standardautor des Commits.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen SSH-Host-Fingerabdruck.
`Readme Addon`	Optional. Benutzerdefinierte Inhalte, die an die generierte `README.md` für alle Playbooks angehängt werden, die in dieser Ausführung übertragen und in der Stamm-Metadatendatei `GitSync.json` gespeichert werden. Unterstützt sowohl Markdown-Syntax als auch Jinja-Vorlagen.

Jobausgaben

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

Playbook abrufen

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

Job-Eingaben

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

Parameter	Beschreibung
`Playbook Whitelist`	Pflichtangabe. Eine durch Kommas getrennte Liste der genauen Playbook- oder Blocknamen, 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 SSH-Host-Fingerabdruck.

Jobausgaben

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

Push-Connectors

Verwenden Sie den Job Push Connectors, um Connector-Konfigurationen nach Git zu exportieren.

Job-Eingaben

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

Parameter	Beschreibung
`Connectors`	Pflichtangabe. Eine durch Kommas getrennte Liste der Anzeigenamen der zu exportierenden Connectors.
`Commit`	Pflichtangabe. Die Git-Commit-Nachricht.
`Include Mappings`	Optional. Wenn diese Option ausgewählt ist, werden die Ontologiezuordnungsdatensätze und ‑regeln, 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 Ontologie-Datensä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 des Commits.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen SSH-Host-Fingerabdruck.
`Readme Addon`	Optional. Benutzerdefinierte Inhalte, die an die generierte `README.md` für alle Connectors angehängt werden, die in dieser Ausführung übertragen und in `GitSync.json` gespeichert werden. Unterstützt sowohl Markdown-Syntax als auch Jinja-Vorlagen.

Jobausgaben

Exportiert Connector-Einstellungen und Zeitpläne nach /Connectors/<Integration_Name>/<Connector_Name>/ (zusammen mit den zugehörigen Ontologiezuordnungen und visuellen 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`	Pflichtangabe. 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 SSH-Host-Fingerabdruck.

Jobausgaben

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

Push-Integration

Verwenden Sie den Job Push Integration, um benutzerdefinierte Integrationen oder benutzerdefinierte Skripts, die kommerziellen Integrationen hinzugefügt wurden, nach Git zu 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`	Pflichtangabe. Eine durch Kommas getrennte Liste von Integrationskennungen, die exportiert werden sollen.
`Commit`	Pflichtangabe. Die Git-Commit-Nachricht.
`Repo URL`	Optional. Überschreibt die Standard-Repository-URL.
`Branch`	Optional. Überschreibt den Standardzweig.
`Commit Author`	Optional. Überschreibt den Standardautor des Commits.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen SSH-Host-Fingerabdruck.
`Readme Addon`	Optional. Benutzerdefinierte Inhalte, die an die generierte `README.md` für alle Integrationen angehängt werden, die in dieser Ausführung übertragen und in `GitSync.json` gespeichert werden. Unterstützt sowohl Markdown-Syntax als auch Jinja-Vorlagen.

Jobausgaben

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

Pull-Integration

Verwenden Sie den Job Pull-Integration, um benutzerdefinierte Integrationen oder benutzerdefinierte Skripts für kommerzielle Integrationen aus Git zu importieren. Bei kommerziellen Integrationen installiert GitSync die aktuelle Version der Integration aus dem Content Hub und speichert die benutzerdefinierten Skripts darin.

Job-Eingaben

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

Parameter	Beschreibung
`Install Whitelist`	Pflichtangabe. 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 SSH-Host-Fingerabdruck.

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 nach Git zu exportieren.

Job-Eingaben

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

Parameter	Beschreibung
`Job Whitelist`	Pflichtangabe. Eine durch Kommas getrennte Liste der Namen der geplanten Jobs, die exportiert werden sollen.
`Commit`	Pflichtangabe. Die Git-Commit-Nachricht.
`Repo URL`	Optional. Überschreibt die Standard-Repository-URL.
`Branch`	Optional. Überschreibt den Standardzweig.
`Commit Author`	Optional. Überschreibt den Standardautor des Commits.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen SSH-Host-Fingerabdruck.
`Readme Addon`	Optional. Benutzerdefinierter Inhalt, der an die generierte `README.md` für alle Jobs angehängt wird, die in dieser Ausführung übertragen und in `GitSync.json` gespeichert werden. Unterstützt sowohl 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`	Pflichtangabe. 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 SSH-Host-Fingerabdruck.

Jobausgaben

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

Push-Zuordnungen

Verwenden Sie den Job Push Mappings, um Ontologie-Ereigniszuordnungsdatensätze und ‑regeln für eine bestimmte Quelle nach Git zu exportieren.

Job-Eingaben

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

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

Jobausgaben

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

Pull-Zuordnungen

Verwenden Sie den Job Pull Mappings, um Ontologiezuweisungsdatensätze und Regeln für eine bestimmte Quelle aus Git zu importieren.

Job-Eingaben

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

Parameter	Beschreibung
`Source`	Pflichtangabe. Die Ontologiequelle (Integrationsname), deren Zuordnungseinträge 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 SSH-Host-Fingerabdruck.

Jobausgaben

Registriert Regeln für die Ontologiezuordnung und Zuweisungen zu visuellen Familien in den Ontologieeinstellungen der Plattform. Zuordnungen werden in der Tabelle „Ontologiestatus“ angezeigt, nachdem die entsprechenden Ereignisse aufgenommen wurden.

Benutzerdefinierte Familie übertragen

Verwenden Sie den Job Push Custom Family, um benutzerdefinierte visuelle Familiendefinitionen und Symbole nach Git zu exportieren.

Job-Eingaben

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

Parameter	Beschreibung
`Family Name`	Pflichtangabe. Eine durch Kommas getrennte Liste der zu exportierenden benutzerdefinierten visuellen Familiennamen.
`Commit`	Pflichtangabe. Die Git-Commit-Nachricht.
`Repo URL`	Optional. Überschreibt die Standard-Repository-URL.
`Branch`	Optional. Überschreibt den Standardzweig.
`Commit Author`	Optional. Überschreibt den Standardautor des Commits.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen SSH-Host-Fingerabdruck.
`Readme Addon`	Optional. Benutzerdefinierte Inhalte, die an die generierte `README.md` für alle benutzerdefinierten visuellen Familien angehängt werden, die in diesem Durchlauf übertragen und in `GitSync.json` gespeichert werden. Unterstützt sowohl 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

Verwenden Sie den Job Pull Custom Family, um eine benutzerdefinierte visuelle Familiendefinition und ein Symbol aus Git zu importieren.

Job-Eingaben

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

Parameter	Beschreibung
`Family Name`	Pflichtangabe. 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 SSH-Host-Fingerabdruck.

Jobausgaben

Importiert die benutzerdefinierte visuelle Familiendefinition und das Symbol in die Ontologieeinstellungen der Plattform.

Simulierte Fälle übertragen

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

Job-Eingaben

Verwenden Sie die folgenden Parameter, um den Job Simulierte Fälle übertragen zu konfigurieren:

Parameter	Beschreibung
`Simulated Cases`	Pflichtangabe. Eine durch Kommas getrennte Liste der Namen der simulierten Fälle, die exportiert werden sollen.
`Commit`	Pflichtangabe. Die Git-Commit-Nachricht.
`Repo URL`	Optional. Überschreibt die Standard-Repository-URL.
`Branch`	Optional. Überschreibt den Standardzweig.
`Commit Author`	Optional. Überschreibt den Standardautor des Commits.
`Git Server Fingerprint`	Optional. Überschreibt den standardmäßigen SSH-Host-Fingerabdruck.

Jobausgaben

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

Simulierte Fälle abrufen

Verwenden Sie den Job Simulierte Fälle abrufen, 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`	Pflichtangabe. Eine durch Kommas getrennte Liste der simulierten Fallnamen, 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 SSH-Host-Fingerabdruck.

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	Betriebliche Ursache	Abhilfeverfahren
`AttributeError: 'OnePlatformSoarApi' object has no attribute 'update_ide_item'`- oder Synchronisierungsfehler in GitSync-Version 53.0	Ausführung des regressiven GitSync-Pakets Version 53.0, das bekannte Synchronisierungsprobleme mit benutzerdefinierten IDE-Elementen und geänderten JSON-Schemas enthält.	Setzen Sie GitSync im Content Hub auf Version 52.0 zurück oder führen Sie ein Upgrade auf Version 54.0 durch. Achten Sie darauf, dass der Parameter Branch auf den Repository-Zweig vor Version 53 verweist. Eine detaillierte Anleitung finden Sie unter Rollback von Version 53.0 und Kompatibilität mit Version 52.0/54.0.
`Permission denied (publickey)` oder `Host key verification failed` (oder `Authentication failed for 'https://...'`)	Git-Authentifizierungsfehler, der durch ein ungültiges Format der Anmeldedaten, fehlende Schreibberechtigungen für den Bereitstellungsschlüssel oder einen nicht übereinstimmenden Host-Fingerabdruck verursacht wurde.	SSH-Authentifizierung: Prüfen Sie, ob Ihr privater SSH-Schlüssel in einen einzeiligen Base64-String ohne nachgestellte 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 Pinning des Host-Fingerabdrucks aktiviert ist, prüfen Sie den Fingerabdruck-String mit `ssh-keyscan -t rsa <hostname>` und aktualisieren Sie den Parameter Git-Server-Fingerabdruck. HTTPS-Authentifizierung: Prüfen Sie, ob Ihr persönliches Zugriffstoken (PAT) noch gültig ist und Schreibberechtigungen für das Repository hat.
`403 Forbidden: Insufficient permissions to modify playbook` (oder `Failed to push playbook: Access denied`)	Das Ziel-Playbook hat eingeschränkte Standardzugriffsberechtigungen (z. B. Darf ansehen) und der SOC-Rolle `Administrator` wurden im Quellsystem keine Darf bearbeiten-Berechtigungen 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 Bearbeiten hinzu. Alternativ können Sie die optionalen Parameter SOAR-Nutzername und SOAR-Passwort in der GitSync-Integrationsinstanz konfigurieren. Eine detaillierte Anleitung finden Sie unter Playbook-Berechtigungen konfigurieren.
Zeitüberschreitung bei Pull-Inhalte- oder Pull-Integration-Jobs nach 5 Minuten	Bei der Installation 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` beim Abrufen aus einem Repository-Zweig)	Es wird versucht, Daten aus einem nicht initialisierten Repository-Zweig oder einem Zweig abzurufen, dessen JSON-Dateien mit dem inkompatiblen GitSync-Schema der Version 53.0 exportiert wurden.	Wenn der Zweig mit GitSync Version 53.0 geändert wurde, setzen Sie den Parameter Zweig auf den Repository-Zweig vor Version 53 zurück oder stellen Sie die Sicherung des Zweigs vor Version 53 wieder her (siehe Rollback von Version 53.0 und Kompatibilität mit Version 52.0 / 54.0). Wenn Sie einen neuen Zweig in Version 52.0 oder 54.0 einrichten, führen Sie zuerst einen vollständigen Push Content-Job aus, um den Zweig zu füllen, bevor Sie Pull-Jobs ausführen.
`Playbook '<Playbook_Name>' is assigned to environment(s) that don't exist`	Ein importiertes Playbook oder ein importierter Block ist einer Umgebung oder Umgebungsgruppe zugewiesen, die auf der Zielinstanz nicht erstellt wurde.	Führen Sie zuerst Inhalte abrufen mit der ausgewählten 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>`	Im Parameter Commit-Autor in der Integrationsinstanz oder Jobkonfiguration fehlt eine E-Mail-Adresse in spitzen Klammern.	Aktualisieren Sie den Parameter Commit Author 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 für die Plattform-Ontologie oder wurden mit einer inkompatiblen GitSync-Version exportiert.	Führen Sie einen neuen Push Mappings-Job mit GitSync Version 54.0 oder 52.0 aus, um Zuordnungsdefinitionen noch einmal zu exportieren, oder beheben Sie doppelte Ereigniszuordnungsregeln 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