GitSync

GitSync est une intégration conçue pour Google SecOps qui synchronise les composants et les éléments d'automatisation de la sécurité avec un dépôt Git externe (comme GitHub, GitLab ou Bitbucket). Il facilite la synchronisation bidirectionnelle du contenu, en fournissant un contrôle des versions automatisé, une sauvegarde de la configuration et une promotion entre environnements tout au long du cycle de vie de vos opérations de sécurité. Notez que GitSync est conçu pour sauvegarder et migrer des éléments entre des environnements associés (tels que le développement, l'environnement de préproduction et la production), plutôt que pour distribuer des éléments entre des systèmes non associés où les identifiants de base de données internes peuvent provoquer des conflits.

Cas d'utilisation

L'intégration GitSync est compatible avec les principaux cas d'utilisation suivants :

  • Contrôle des versions et auditabilité (Security as Code) : suivez les modifications, examinez les différences et conservez un historique des versions complet des playbooks, des connecteurs, des intégrations et des paramètres système.

  • Promotion multi-environnement (pipeline CI/CD) : promouvez systématiquement les playbooks, les mappages d'ontologie et les paramètres d'intégration des environnements de développement et de préproduction vers la production via des demandes d'extraction et des fusions de branches.

  • Sauvegarde et reprise après sinistre : restaurez des playbooks et des configurations de plate-forme supprimés, corrompus ou mal configurés par erreur directement depuis votre dépôt Git.

  • Standardisation entre environnements : distribuez des playbooks standardisés, des familles visuelles personnalisées et des définitions de connecteurs dans les environnements Google SecOps associés à partir d'un dépôt centralisé.

  • Isolation des branches et de la préproduction : testez les playbooks expérimentaux et les branches de fonctionnalités dans des environnements dédiés sans affecter les workflows ni les planifications de production.

  • Examen et collaboration hors connexion : exportez les définitions de plate-forme au format JSON et Markdown pour permettre l'examen par les pairs, la validation automatisée et l'inspection dans les outils pour les développeurs standards.

  • Blocs de workflow réutilisables : synchronisez des blocs de workflow modulaires en même temps que des playbooks complets ou séparément, afin que les équipes puissent partager des étapes d'automatisation communes.

Workflows d'implémentation par objectif

Pour accéder directement aux conseils correspondant à votre objectif actuel, sélectionnez votre workflow :

  • Nouveau déploiement GitSync ou nouvelle branche : si vous configurez l'intégration GitSync pour la première fois ou si vous créez une branche de dépôt, suivez cette séquence de configuration de bout en bout :

    1. Remplissez les conditions préalables et configurez les identifiants.
    2. Configurez l'instance d'intégration partagée.
    3. Testez la connectivité réseau et l'authentification avec l'action Ping.
    4. Exécutez un job d'envoi de contenu initial pour remplir la branche avant d'exécuter des jobs d'extraction.
    5. Configurez et planifiez des jobs de synchronisation automatisés.
  • Documentation de référence sur les jobs et les dépôts :

    • Pour afficher les paramètres de configuration et exécuter des jobs d'envoi ou d'extraction autonomes pour des éléments spécifiques (playbooks, connecteurs, intégrations, etc.), consultez Jobs.
    • Pour afficher la mise en page standard du dépôt, consultez Structure du répertoire du dépôt.
  • Résoudre les problèmes de synchronisation : si une action ou un job échoue et génère une erreur, consultez Dépannage.

Avant de commencer

Avant de configurer et d'exécuter des opérations GitSync, vérifiez la version de votre intégration, obtenez l'accès au dépôt et effectuez les tâches de configuration suivantes :

  • Utilisez un dépôt Git privé avec un accès en écriture : assurez-vous de disposer d'autorisations d'écriture sur un dépôt Git distant privé hébergé sur un fournisseur Git compatible (tel que GitHub, GitLab ou Bitbucket). Bien que les paramètres de type Password soient exclus par défaut, sauf si Commit Passwords est activé, tous les autres paramètres (tels que les ID d'application, les ID client, les noms d'utilisateur et les points de terminaison) sont exportés en texte brut. N'utilisez jamais de dépôt public avec GitSync.

  • Initialisez le dépôt distant : vérifiez que le dépôt distant comporte au moins un commit initial (par exemple, un fichier README.md ou .gitignore). GitSync ne peut pas se synchroniser avec un dépôt vide.

  • Préparer les identifiants d'authentification Git : générez un identifiant d'authentification avec des autorisations d'écriture dans le dépôt. GitSync accepte les clés privées SSH encodées en base64 (recommandé), les jetons d'accès personnels (PAT) et les identifiants de base (nom d'utilisateur et mot de passe).

    Pour générer et encoder une clé SSH, consultez Générer des clés SSH pour GitSync.

  • Vérifiez la connectivité réseau et VPC Service Controls : vérifiez que votre instance Google SecOps ou votre exécuteur distant dispose d'un accès sortant au pare-feu sur le port TCP 443 (pour HTTPS) ou le port TCP 22 (pour SSH) vers votre fournisseur Git.

    Si votre environnementGoogle Cloud utilise un périmètre de service VPC Service Controls, demandez à votre administrateur Google Cloud de configurer des règles d'entrée et de sortie afin que les intégrations de réponse puissent communiquer avec les API Google Cloud et les points de terminaison externes requis.

  • Obtenez l'empreinte de votre hôte Git (recommandé) : Pour vous protéger contre les attaques de type "person-in-the-middle" (PITM), récupérez l'empreinte de la clé publique de votre serveur Git pour l'épinglage de l'empreinte de l'hôte.

    Pour connaître la procédure de configuration, consultez Activer l'épinglage d'empreinte d'hôte.

  • Accorder des autorisations de modification des playbooks : Si vous prévoyez de synchroniser des playbooks avec un accès par défaut restreint (par exemple, des autorisations par défaut définies sur Peut afficher), accordez au rôle SOC Administrator les autorisations Peut modifier sur le système source avant d'exécuter des jobs de synchronisation.

    Pour obtenir des instructions détaillées, consultez Configurer les autorisations du playbook.

Générer des clés SSH pour GitSync

Pour configurer une authentification sécurisée sans mot de passe à l'aide de clés SSH :

  1. Générez une paire de clés RSA ou Ed25519 dans votre terminal. Lorsque vous êtes invité à saisir une phrase secrète, appuyez sur Entrée pour ne pas en fournir :

    ssh-keygen -b 2048 -t rsa -f ./id_rsa
    

    Cette commande crée deux fichiers : id_rsa (clé privée) et id_rsa.pub (clé publique).

  2. Ajoutez la clé publique (id_rsa.pub) à votre service d'hébergement Git distant en tant que clé de déploiement ou clé d'accès avec des autorisations d'écriture.

  3. Convertissez la clé privée en une chaîne encodée en base64 sur une seule ligne :

    • Linux/macOS :

      base64 -w 0 ./id_rsa
      
    • Windows (PowerShell) :

      [Convert]::ToBase64String([System.IO.File]::ReadAllBytes(".\id_rsa"))
      
  4. Copiez la chaîne base64 obtenue et collez-la dans le paramètre Mot de passe/Jeton/Clé SSH Git lors de la configuration de l'instance d'intégration GitSync.

Activer l'épinglage de l'empreinte de l'hôte

L'épinglage de l'empreinte de l'hôte vérifie l'identité de votre serveur Git lors de la connexion pour vous protéger contre les attaques de l'intercepteur (PITM). Bien que le paramètre Empreinte du serveur Git soit facultatif, sa configuration garantit que GitSync se connecte exclusivement à votre hôte Git validé.

Pour configurer l'épinglage d'empreinte d'hôte :

  1. Récupérez l'empreinte de votre hôte : Exécutez ssh-keyscan dans votre terminal en indiquant le nom d'hôte de votre serveur Git :

    ssh-keyscan -t rsa <hostname>
    

    Par exemple, pour GitHub, exécutez ssh-keyscan -t rsa github.com. Le résultat de la commande génère une ligne de clé d'hôte publique semblable à celle-ci :

    github.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC...
    
  2. Enregistrez l'empreinte pour la configuration : copiez la ligne de la clé d'hôte publique. Saisissez cette valeur dans le paramètre Empreinte du serveur Git lors de la configuration de l'instance d'intégration GitSync (pour l'appliquer à toutes les tâches) ou sur des tâches de synchronisation individuelles (pour remplacer le paramètre pour des hôtes spécifiques).

Configurer les autorisations du playbook

Lorsque vous synchronisez des playbooks avec des autorisations restreintes (par exemple, les autorisations par défaut sont définies sur Peut afficher), attribuez les autorisations Peut modifier au rôle SOC Administrator :

  1. Dans Google SecOps, accédez à Playbooks et sélectionnez le playbook cible.
  2. Ouvrez les paramètres d'autorisation du playbook.
  3. Ajoutez le rôle SOC Administrator à la liste des entités et définissez son autorisation sur Peut modifier.

Rollback de la version 53.0

La version 53.0 de GitSync a introduit des modifications de l'API Chronicle et des schémas d'exportation JSON modifiés qui ont entraîné des échecs de synchronisation. Pour résoudre ces problèmes, la version 54.0 de GitSync annule les modifications de la version 53.0 et restaure la codebase de la version stable 52.0.

Pour passer à la version 52.0 ou 54.0 et restaurer une branche de dépôt compatible, procédez comme suit :

  1. Suspendre les jobs de synchronisation planifiés : désactivez tous les jobs GitSync planifiés actifs (tels que Push Content et Pull Content) afin qu'ils ne s'exécutent pas pendant que vous changez de version et de branche.

  2. Passez à la version 54.0 ou revenez à la version 52.0 : Dans Content Hub, recherchez l'intégration GitSync :

    • Si la version 54.0 est disponible, mettez à niveau l'intégration vers la version 54.0.
    • Si la version 54.0 n'est pas encore apparue (les caches de Content Hub se synchronisent environ toutes les huit heures) ou si vous préférez revenir directement à une version antérieure, rétablissez la version 52.0 de l'intégration.
  3. Faites pointer GitSync vers la branche de votre dépôt précédent : les branches de dépôt renseignées à l'aide de la version 53.0 utilisent un schéma JSON différent qui n'est pas compatible avec la version 52.0 ou 54.0 :

    • Si vous avez créé une branche distincte pour la version 53.0 (par exemple, gitsync-chronicle-api) : accédez à Settings> Integrations> GitSync, remplacez le paramètre Branch par votre branche d'origine (par exemple, main), puis exécutez l'action Ping pour vérifier la connectivité.
    • Si vous avez écrasé votre branche existante dans la version 53.0 : restaurez la branche à partir de votre tag Git backup-legacy-pre-migration (ou de votre dernier commit antérieur à la version 53) ou supprimez les répertoires exportés de la version 53.0 (Playbooks/, Connectors/, Integrations/, Jobs/, Ontology/, SimulatedCases/ et Settings/) et exécutez une tâche Push Content complète à partir de la version 52.0 ou 54.0 pour remplir à nouveau la branche.
  4. Réactiver les tâches planifiées : Après avoir vérifié que votre branche contient des configurations exportées par la version 52.0 ou 54.0, réactivez vos tâches GitSync planifiées.

Configurer l'intégration

Configurez l'intégration GitSync en tant qu'instance partagée dans Google SecOps afin que tous les composants de la plate-forme et les jobs planifiés puissent accéder aux configurations du dépôt.

Paramètres d'intégration de GitSync

Paramètre Description
Repo URL

Obligatoire.

URL du dépôt Git distant.

Lorsque vous utilisez l'authentification HTTPS, l'URL doit commencer par https:// (par exemple, https://github.com/organization/secops-platform.git).

Lorsque vous utilisez l'authentification SSH, l'URL doit commencer par git@ ou ssh:// (par exemple, git@github.com:organization/secops-platform.git).

Branch

Obligatoire.

Branche du dépôt Git avec laquelle effectuer la synchronisation (par exemple, main).

Git Password/Token/SSH Key

Obligatoire.

Identifiants d'authentification pour le dépôt Git distant.

Ce paramètre accepte un mot de passe de compte Git, un jeton d'accès personnel (PAT) ou une clé privée SSH encodée en base64 (RSA 2 048 bits ou Ed25519).

Git Username

Facultatif.

Nom d'utilisateur du compte Git.

Obligatoire lorsque vous utilisez l'authentification par nom d'utilisateur et mot de passe via HTTPS.

Git Server Fingerprint

Facultatif.

La clé d'hôte publique SSH de votre serveur Git distant (par exemple, github.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC...).

La configuration de ce paramètre active l'épinglage de l'empreinte de l'hôte, ce qui garantit que GitSync se connecte exclusivement à votre hôte Git validé et atténue les risques d'attaque de l'intercepteur (PITM).

Pour récupérer cette valeur, consultez Activer l'épinglage de l'empreinte de l'hôte.

Commit Author

Facultatif.

Identité de l'auteur associée aux commits Git sortants générés par GitSync.

Le format doit respecter la paternité Git standard : Name &lt;email@domain.com&gt; (par défaut, GitSync &lt;gitsync@siemplify.co&gt;).

Siemplify Verify SSL

Obligatoire.

Si cette option est sélectionnée, l'intégration valide le certificat SSL du point de terminaison de l'API Google SecOps.

Cette option est activée par défaut.

Git Verify SSL

Obligatoire.

Si cette option est sélectionnée, l'intégration valide le certificat SSL du serveur du fournisseur Git distant.

Cette option est activée par défaut.

SOAR Username

Facultatif.

Nom d'utilisateur Google SecOps d'un compte disposant des autorisations de modification des playbooks.

Fournissez ce paramètre si la clé API par défaut échoue en raison de limites d'autorisation.

SOAR Password

Facultatif.

Mot de passe correspondant au SOAR Username configuré.

Actions

Pour en savoir plus sur les actions, consultez Répondre aux actions en attente depuis votre bureau et Exécuter une action manuelle dans votre demande.

Ping

Utilisez l'action Ping pour tester la connectivité réseau et vérifier les identifiants d'authentification par rapport au dépôt et à la branche Git configurés.

Entrées de l'action

Aucune.

Sorties de l'action

L'action Ping fournit les résultats suivants :

Type de sortie de l'action Disponibilité
Pièce jointe du mur des cas Non disponible
Lien vers le mur des cas Non disponible
Tableau du mur des cas Non disponible
Table d'enrichissement Non disponible
Résultat JSON Non disponible
Messages de sortie Disponible
Résultat du script Disponible
Messages de sortie

L'action Ping peut renvoyer les messages de sortie suivants :

Message de sortie Description du message
Successfully executed action "Ping". L'action a réussi et la connectivité du dépôt a été vérifiée.
Error executing action "Ping". Reason: ERROR_REASON Échec de l'action. Vérifiez l'URL du dépôt, le nom de la branche, les identifiants ou les routes réseau.
Résultat du script

Le tableau suivant liste les valeurs de résultat du script lorsque vous utilisez l'action Ping :

Nom du résultat du script Valeur
is_success true ou false

Jobs

GitSync fournit 16 configurations de jobs de synchronisation (deux jobs d'instance complète et sept paires de jobs autonomes) pour gérer les éléments de la plate-forme. Ces jobs sont compatibles avec les champs d'application de synchronisation autonomes complets au niveau de l'instance et ciblés.

Champ d'application de la synchronisation et assets compatibles

L'intégration organise les jobs de synchronisation en deux champs d'application opérationnels distincts pour répondre à différents besoins d'administration et d'automatisation :

  • Synchronisation complète de l'instance (Push Content et Pull Content) : synchronise l'intégralité de votre plate-forme Google SecOps en une seule opération groupée.

    Cela englobe 21 catégories d'assets de la plate-forme dans trois domaines fonctionnels :

    • Configurations du système et de l'environnement : environnements, domaines, paramètres dynamiques, listes personnalisées, réseaux, listes noires (listes de blocage), paramètres de titre de demande, modèles d'e-mails et logo.

    • Gestion des alertes et des demandes : tags de demande, étapes de demande, motifs de clôture de demande, enregistrements de SLA et demandes simulées.

    • Automatisation et intégrations de la sécurité : playbooks (y compris les blocs de workflow réutilisables), intégrations, instances d'intégration, connecteurs, jobs planifiés, mappages d'ontologie et familles visuelles.

  • Synchronisation précise des éléments (jobs d'extraction et de transfert autonomes) :

    Fournit des paires de jobs push et pull dédiées pour sept éléments spécifiques. Utilisez des jobs autonomes lorsque vous développez, mettez à jour ou testez des composants individuels sans synchroniser ni écraser le reste de votre environnement :

    • Playbooks et blocs de workflow : Push Playbook et Pull Playbook

    • Connecteurs : Push Connectors et Pull Connector

    • Intégrations : Push Integration et Pull Integration

    • Jobs planifiés : Push Job et Pull Jobs

    • Mappages d'ontologie : Push Mappings et Pull Mappings

    • Familles visuelles personnalisées : Push Custom Family et Pull Custom Family

    • Scénarios de test simulés : Push Simulated Cases et Pull Simulated Cases

Structure du répertoire du dépôt

L'exécution d'un job Push Content initial (requis avant d'exécuter des jobs d'extraction sur une branche nouvelle ou migrée) crée la structure de répertoires prédéfinie suivante, les fichiers de configuration JSON, le fichier de métadonnées GitSync.json racine et la documentation README.md générée dans votre dépôt Git distant.

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

Jobs de synchronisation au niveau de l'instance

Les jobs au niveau de l'instance synchronisent les catégories d'éléments sélectionnées sur l'ensemble d'une instance Google SecOps.

Contenu push

Utilisez le job Push Content (Transférer du contenu) pour exporter les catégories d'éléments sélectionnées depuis votre instance Google SecOps et les valider dans la branche du dépôt Git configurée. Exécutez toujours Push Content (Transférer le contenu) en premier lorsque vous initialisez une nouvelle branche.

Entrées de job

Pour configurer le job Push Content, utilisez les paramètres suivants :

Paramètre Description
Commit

Obligatoire.

Message de commit Git décrivant les modifications apportées au contenu exporté.

Commit Passwords

Facultatif.

Si cette option est sélectionnée, le job exporte les paramètres de type Password en texte brut pour les instances d'intégration, les connecteurs et les jobs configurés.

Paramètres de sélection des 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

Facultatif (boutons d'activation/désactivation booléens).

Sélectionnez chaque catégorie d'éléments que vous souhaitez inclure dans l'exportation.

Repo URL

Facultatif.

Remplace l'URL du dépôt configurée dans l'instance d'intégration.

Branch

Facultatif.

Remplace la branche du dépôt configurée dans l'instance d'intégration.

Commit Author

Facultatif.

Remplace l'auteur du commit configuré dans l'instance d'intégration. Doit respecter le format Name &lt;email@domain.com&gt;.

Git Server Fingerprint

Facultatif.

Remplace l'empreinte de l'hôte SSH configurée dans l'instance d'intégration.

Sorties de job

Le job écrit les fichiers de configuration JSON et les résumés README.md dans la branche Git cible sous la hiérarchie de répertoires standard (/Playbooks, /Connectors, /Integrations, /Jobs, /Ontology/Mappings, /Ontology/VisualFamilies, /SimulatedCases et /Settings) et génère des journaux d'exécution dans la console de l'exécuteur de job. Les intégrations personnalisées sont exportées sous forme de packages complets, tandis que les intégrations commerciales n'exportent que les scripts personnalisés ou les modifications ajoutées à l'intégration.

Contenu extrait

Utilisez le job Extraire le contenu pour récupérer les catégories de configuration sélectionnées à partir de la branche du dépôt Git configurée et les appliquer à la plate-forme Google SecOps.

Entrées de job

Pour configurer le job Extraire le contenu, utilisez les paramètres suivants :

Paramètre Description
Paramètres de sélection des 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

Facultatif (boutons d'activation/désactivation booléens).

Sélectionnez chaque catégorie d'éléments que vous souhaitez importer du dépôt vers votre environnement.

Repo URL

Facultatif.

Remplace l'URL du dépôt configurée dans l'instance d'intégration.

Branch

Facultatif.

Remplace la branche du dépôt configurée dans l'instance d'intégration.

Git Server Fingerprint

Facultatif.

Remplace l'empreinte de l'hôte SSH configurée dans l'instance d'intégration.

Sorties de job

Le job importe les définitions de dépôt sélectionnées dans la plate-forme, crée ou met à jour les instances d'intégration, les playbooks, les connecteurs, les jobs, les mappages d'ontologie et les paramètres, et génère des journaux d'exécution dans la console de l'exécuteur de jobs.

Jobs de synchronisation autonomes

Les jobs autonomes permettent une synchronisation précise de ressources spécifiques sans nécessiter une synchronisation complète du dépôt.

Playbook sur les notifications push

Utilisez le job Push Playbook pour exporter des playbooks individuels ou des blocs de workflow réutilisables vers Git.

Entrées de job

Pour configurer le job Push Playbook, utilisez les paramètres suivants :

Paramètre Description
Commit

Obligatoire.

Message de commit Git décrivant les modifications apportées au playbook.

Playbook Whitelist

Facultatif.

Liste de noms exacts de playbooks ou de blocs à exporter, séparés par une virgule et sensibles à la casse. Indiquez Playbook Whitelist ou Folders Whitelist.

Folders Whitelist

Facultatif.

Liste de noms de dossiers (catégories) de playbooks séparés par une virgule. Tous les playbooks et blocs résidant dans ces dossiers sont exportés.

Include Playbook Blocks

Facultatif.

Si cette option est sélectionnée, les blocs de workflow réutilisables sont exportés avec les playbooks sélectionnés, y compris les blocs référencés en tant qu'étapes dans ces playbooks.

Repo URL

Facultatif.

Remplace l'URL du dépôt par défaut.

Branch

Facultatif.

Remplace la branche par défaut.

Commit Author

Facultatif.

Remplace l'auteur du commit par défaut.

Git Server Fingerprint

Facultatif.

Remplace l'empreinte de l'hôte SSH par défaut.

Readme Addon

Facultatif.

Contenu personnalisé ajouté au README.md généré pour tous les playbooks transférés lors de cette exécution et enregistré dans le fichier de métadonnées GitSync.json racine.

Compatible avec la syntaxe Markdown et les modèles Jinja.

Sorties de job

Exporte les playbooks sélectionnés et les blocs de workflow inclus vers /Playbooks/<Folder_Name>/<Playbook_Name>/ et met à jour /Playbooks/README.md.

Playbook sur l'attraction de clients

Utilisez le job Pull Playbook pour importer des playbooks ou des blocs spécifiques depuis Git.

Entrées de job

Pour configurer la tâche Pull Playbook, utilisez les paramètres suivants :

Paramètre Description
Playbook Whitelist

Obligatoire.

Liste de noms exacts de playbooks ou de blocs à importer depuis le dépôt, séparés par une virgule.

Include Playbook Blocks

Facultatif.

Si cette option est sélectionnée, les blocs de workflow réutilisables référencés par les playbooks sélectionnés sont automatiquement importés.

Repo URL

Facultatif.

Remplace l'URL du dépôt par défaut.

Branch

Facultatif.

Remplace la branche par défaut.

Git Server Fingerprint

Facultatif.

Remplace l'empreinte de l'hôte SSH par défaut.

Sorties de job

Importe les playbooks et les blocs spécifiés depuis /Playbooks (ou /Blocks) dans la plate-forme, en installant d'abord les blocs référencés avant d'installer les playbooks parents.

Connecteurs push

Utilisez le job Push Connectors pour exporter les configurations de connecteurs vers Git.

Entrées de job

Pour configurer le job Push Connectors, utilisez les paramètres suivants :

Paramètre Description
Connectors

Obligatoire.

Liste de noms à afficher de connecteurs à exporter, séparés par une virgule.

Commit

Obligatoire.

Message de commit Git.

Include Mappings

Facultatif.

Si cette option est sélectionnée, les enregistrements et les règles de mappage d'ontologie associés à l'intégration du connecteur sont exportés vers /Ontology/Mappings.

Include Visual Families

Facultatif.

Si cette option est sélectionnée, les familles visuelles personnalisées associées aux enregistrements d'ontologie du connecteur sont exportées vers /Ontology/VisualFamilies.

Repo URL

Facultatif.

Remplace l'URL du dépôt par défaut.

Branch

Facultatif.

Remplace la branche par défaut.

Commit Author

Facultatif.

Remplace l'auteur du commit par défaut.

Git Server Fingerprint

Facultatif.

Remplace l'empreinte de l'hôte SSH par défaut.

Readme Addon

Facultatif.

Contenu personnalisé ajouté au fichier README.md généré pour tous les connecteurs transférés lors de cette exécution et enregistré dans GitSync.json.

Compatible avec la syntaxe Markdown et les modèles Jinja.

Sorties de job

Exporte les paramètres et les planifications du connecteur vers /Connectors/<Integration_Name>/<Connector_Name>/ (ainsi que les mappages d'ontologie et les familles visuelles associés, si sélectionnés).

Connecteur d'extraction

Utilisez le job Pull Connector pour importer une configuration de connecteur depuis Git. Avant d'exécuter ce job, assurez-vous que l'intégration sous-jacente du connecteur est déjà installée sur l'environnement cible.

Entrées de job

Pour configurer le job Pull Connector, utilisez les paramètres suivants :

Paramètre Description
Connector Name

Obligatoire.

Nom à afficher du connecteur à importer depuis le dépôt.

Include Mappings

Facultatif.

Si cette option est sélectionnée, les mappages d'ontologie associés à l'intégration du connecteur sont importés.

Include Visual Families

Facultatif.

Si cette option est sélectionnée, les familles visuelles personnalisées associées à l'intégration du connecteur sont importées.

Repo URL

Facultatif.

Remplace l'URL du dépôt par défaut.

Branch

Facultatif.

Remplace la branche par défaut.

Git Server Fingerprint

Facultatif.

Remplace l'empreinte de l'hôte SSH par défaut.

Sorties de job

Installe ou met à jour le connecteur sur l'environnement cible (ainsi que les mappages ou familles visuelles associés, si sélectionnés).

Intégration push

Utilisez le job Push Integration pour exporter vers Git des intégrations personnalisées ou des scripts personnalisés ajoutés à des intégrations commerciales. Les intégrations personnalisées sont exportées sous forme de packages d'intégration complets, tandis que les intégrations commerciales n'exportent que les scripts personnalisés ou les modifications ajoutées à l'intégration.

Entrées de job

Pour configurer le job Push Integration, utilisez les paramètres suivants :

Paramètre Description
Push Whitelist

Obligatoire.

Liste d'identifiants d'intégration à exporter, séparés par une virgule.

Commit

Obligatoire.

Message de commit Git.

Repo URL

Facultatif.

Remplace l'URL du dépôt par défaut.

Branch

Facultatif.

Remplace la branche par défaut.

Commit Author

Facultatif.

Remplace l'auteur du commit par défaut.

Git Server Fingerprint

Facultatif.

Remplace l'empreinte de l'hôte SSH par défaut.

Readme Addon

Facultatif.

Contenu personnalisé ajouté au README.md généré pour toutes les intégrations déployées lors de cette exécution et enregistrées dans GitSync.json.

Compatible avec la syntaxe Markdown et les modèles Jinja.

Sorties de job

Exporte les définitions d'intégration, les scripts personnalisés (Actions/, Connectors/, Jobs/, Managers/), les dépendances et la documentation README.md vers /Integrations/<Integration_Identifier>/.

Intégration pull

Utilisez le job Pull Integration pour importer des intégrations personnalisées ou des scripts personnalisés pour les intégrations commerciales depuis Git. Pour les intégrations commerciales, GitSync installe la dernière version de l'intégration à partir de Content Hub et y enregistre les scripts personnalisés.

Entrées de job

Pour configurer le job Pull Integration, utilisez les paramètres suivants :

Paramètre Description
Install Whitelist

Obligatoire.

Liste d'identifiants d'intégration séparés par une virgule à importer depuis le dépôt.

Repo URL

Facultatif.

Remplace l'URL du dépôt par défaut.

Branch

Facultatif.

Remplace la branche par défaut.

Git Server Fingerprint

Facultatif.

Remplace l'empreinte de l'hôte SSH par défaut.

Sorties de job

Installe des packages d'intégration personnalisés ou des intégrations commerciales à partir de Content Hub, et met à jour leurs scripts personnalisés dans l'environnement cible.

Job push

Utilisez le job Push Job pour exporter les configurations de jobs de plate-forme planifiés vers Git.

Entrées de job

Pour configurer le job Push Job, utilisez les paramètres suivants :

Paramètre Description
Job Whitelist

Obligatoire.

Liste de noms de jobs planifiés à exporter, séparés par une virgule.

Commit

Obligatoire.

Message de commit Git.

Repo URL

Facultatif.

Remplace l'URL du dépôt par défaut.

Branch

Facultatif.

Remplace la branche par défaut.

Commit Author

Facultatif.

Remplace l'auteur du commit par défaut.

Git Server Fingerprint

Facultatif.

Remplace l'empreinte de l'hôte SSH par défaut.

Readme Addon

Facultatif.

Contenu personnalisé ajouté au README.md généré pour tous les jobs transférés lors de cette exécution et enregistrés dans GitSync.json.

Compatible avec la syntaxe Markdown et les modèles Jinja.

Sorties de job

Exporte les paramètres de job et les intervalles de planification vers /Jobs/<Job_Name>.json, et met à jour /Jobs/README.md.

Jobs d'extraction

Utilisez le job Pull Jobs pour importer des jobs de plate-forme planifiés depuis Git.

Entrées de job

Pour configurer le job Extraire des jobs, utilisez les paramètres suivants :

Paramètre Description
Job Whitelist

Obligatoire.

Liste de noms de jobs planifiés à importer depuis le dépôt, séparés par une virgule.

Repo URL

Facultatif.

Remplace l'URL du dépôt par défaut.

Branch

Facultatif.

Remplace la branche par défaut.

Git Server Fingerprint

Facultatif.

Remplace l'empreinte de l'hôte SSH par défaut.

Sorties de job

Configure et enregistre les jobs planifiés spécifiés dans le planificateur de jobs de la plate-forme.

Mappages de push

Utilisez le job Push Mappings pour exporter vers Git les enregistrements et les règles de mappage d'événements d'ontologie pour une source spécifique.

Entrées de job

Pour configurer le job Push Mappings, utilisez les paramètres suivants :

Paramètre Description
Source

Obligatoire.

Source d'ontologie (nom de l'intégration) dont vous souhaitez exporter les enregistrements et les règles de mappage.

Commit

Obligatoire.

Message de commit Git.

Repo URL

Facultatif.

Remplace l'URL du dépôt par défaut.

Branch

Facultatif.

Remplace la branche par défaut.

Commit Author

Facultatif.

Remplace l'auteur du commit par défaut.

Git Server Fingerprint

Facultatif.

Remplace l'empreinte de l'hôte SSH par défaut.

Readme Addon

Facultatif.

Contenu personnalisé ajouté au README.md généré pour tous les mappages transmis lors de cette exécution et enregistrés dans GitSync.json.

Compatible avec la syntaxe Markdown et les modèles Jinja.

Sorties de job

Écrit les enregistrements d'ontologie (<Source>_Records.json), les règles de mappage (<Source>_Rules.json) et README.md dans /Ontology/Mappings/<Source>/.

Extraire les mappages

Utilisez le job Pull Mappings pour importer des enregistrements et des règles de mappage d'ontologie pour une source spécifique depuis Git.

Entrées de job

Pour configurer le job Pull Mappings, utilisez les paramètres suivants :

Paramètre Description
Source

Obligatoire.

Source d'ontologie (nom de l'intégration) dont vous souhaitez importer les enregistrements et les règles de mappage.

Repo URL

Facultatif.

Remplace l'URL du dépôt par défaut.

Branch

Facultatif.

Remplace la branche par défaut.

Git Server Fingerprint

Facultatif.

Remplace l'empreinte de l'hôte SSH par défaut.

Sorties de job

Enregistre les règles de mappage d'ontologie et les attributions de familles visuelles dans les paramètres d'ontologie de la plate-forme. Les mappages apparaissent dans le tableau "État de l'ontologie" une fois que les événements correspondants ont été ingérés.

Famille personnalisée Push

Utilisez le job Push Custom Family pour exporter des définitions et des icônes de familles visuelles personnalisées vers Git.

Entrées de job

Pour configurer le job Push Custom Family, utilisez les paramètres suivants :

Paramètre Description
Family Name

Obligatoire.

Liste de noms de familles de visuels personnalisés à exporter, séparés par une virgule.

Commit

Obligatoire.

Message de commit Git.

Repo URL

Facultatif.

Remplace l'URL du dépôt par défaut.

Branch

Facultatif.

Remplace la branche par défaut.

Commit Author

Facultatif.

Remplace l'auteur du commit par défaut.

Git Server Fingerprint

Facultatif.

Remplace l'empreinte de l'hôte SSH par défaut.

Readme Addon

Facultatif.

Contenu personnalisé ajouté au fichier README.md généré pour toutes les familles de visuels personnalisés transmises lors de cette exécution et enregistrées dans GitSync.json.

Compatible avec la syntaxe Markdown et les modèles Jinja.

Sorties de job

Exporte les définitions de familles visuelles (<Family_Name>.json), les fichiers d'image d'icône (<Family_Name>.png) et README.md vers /Ontology/VisualFamilies/<Family_Name>/.

Famille personnalisée Pull

Utilisez le job Pull Custom Family pour importer une définition de famille visuelle personnalisée et une icône depuis Git.

Entrées de job

Pour configurer le job Pull Custom Family, utilisez les paramètres suivants :

Paramètre Description
Family Name

Obligatoire.

Nom exact de la famille visuelle personnalisée à importer.

Repo URL

Facultatif.

Remplace l'URL du dépôt par défaut.

Branch

Facultatif.

Remplace la branche par défaut.

Git Server Fingerprint

Facultatif.

Remplace l'empreinte de l'hôte SSH par défaut.

Sorties de job

Importe la définition et l'icône de la famille de visuels personnalisés dans les paramètres d'ontologie de la plate-forme.

Envoyer des cas simulés

Utilisez le job Push Simulated Cases pour exporter des scénarios de test simulés vers Git.

Entrées de job

Pour configurer le job Push Simulated Cases, utilisez les paramètres suivants :

Paramètre Description
Simulated Cases

Obligatoire.

Liste de noms de cas simulés à exporter, séparés par une virgule.

Commit

Obligatoire.

Message de commit Git.

Repo URL

Facultatif.

Remplace l'URL du dépôt par défaut.

Branch

Facultatif.

Remplace la branche par défaut.

Commit Author

Facultatif.

Remplace l'auteur du commit par défaut.

Git Server Fingerprint

Facultatif.

Remplace l'empreinte de l'hôte SSH par défaut.

Sorties de job

Exporte les cas simulés sous forme de fichiers .case vers /SimulatedCases/<Case_Name>.case.

Extraire des cas simulés

Utilisez le job Pull Simulated Cases pour importer des scénarios de test simulés depuis Git.

Entrées de job

Pour configurer le job Extraire les cas simulés, utilisez les paramètres suivants :

Paramètre Description
Simulated Cases

Obligatoire.

Liste de noms de cas simulés à importer depuis le dépôt, séparés par une virgule.

Repo URL

Facultatif.

Remplace l'URL du dépôt par défaut.

Branch

Facultatif.

Remplace la branche par défaut.

Git Server Fingerprint

Facultatif.

Remplace l'empreinte de l'hôte SSH par défaut.

Sorties de job

Importe les cas simulés spécifiés dans le catalogue de cas simulés de la plate-forme.

Dépannage

Le tableau suivant indique les étapes de correction des erreurs de synchronisation courantes :

Message d'erreur observé Cause opérationnelle Procédure de correction
Échecs de AttributeError: 'OnePlatformSoarApi' object has no attribute 'update_ide_item' ou de synchronisation sur GitSync version 53.0 Exécution du package GitSync version 53.0 régressif, qui contient des problèmes de synchronisation connus avec les éléments d'IDE personnalisés et les schémas JSON modifiés. Rétrogradez GitSync vers la version 52.0 ou passez à la version 54.0 dans Content Hub, et assurez-vous que le paramètre Branch (Branche) pointe vers la branche de votre dépôt antérieure à la version 53. Pour obtenir des instructions détaillées, consultez Rollback de la version 53.0 et compatibilité des versions 52.0/54.0.
Permission denied (publickey) ou Host key verification failed (ou Authentication failed for 'https://...') Échec de l'authentification Git en raison d'un format d'identifiant non valide, d'autorisations d'écriture de clé de déploiement manquantes ou d'une empreinte d'hôte non concordante.
  • Authentification SSH : vérifiez que votre clé SSH privée est convertie en une chaîne base64 sur une seule ligne, sans saut de ligne ni espace blanc à la fin. Vérifiez que la clé publique correspondante est enregistrée dans votre dépôt Git avec un accès en écriture.
  • Empreinte de l'hôte : si l'épinglage de l'empreinte de l'hôte est activé, vérifiez la chaîne d'empreinte à l'aide de ssh-keyscan -t rsa <hostname> et mettez à jour le paramètre Empreinte du serveur Git.
  • Authentification HTTPS : vérifiez que votre jeton d'accès personnel (PAT) n'a pas expiré et qu'il dispose d'un champ d'application d'écriture dans le dépôt.
403 Forbidden: Insufficient permissions to modify playbook (ou Failed to push playbook: Access denied) Le playbook cible dispose d'autorisations d'accès par défaut limitées (par exemple, Peut afficher), et le rôle SOC Administrator ne dispose pas des autorisations Peut modifier sur le système source. Dans Google SecOps, accédez à Playbooks, sélectionnez le playbook concerné, ouvrez ses paramètres d'autorisation, puis ajoutez le rôle SOC Administrator avec les autorisations Peut modifier (ou configurez les paramètres facultatifs Nom d'utilisateur SOAR et Mot de passe SOAR sur l'instance d'intégration GitSync). Pour connaître la procédure détaillée, consultez Configurer les autorisations des playbooks.
Le job Pull Content (Extraire le contenu) ou Pull Integration (Extraire l'intégration) expire au bout de cinq minutes L'installation de plusieurs intégrations commerciales à partir de Content Hub lors d'une même opération d'extraction a dépassé le délai d'exécution de cinq minutes. Installez manuellement les intégrations commerciales requises depuis Content Hub avant d'exécuter Extraire le contenu, ou réexécutez le job Extraire le contenu pour continuer à importer les éléments restants.
General error performing Job Pull Content (ou 400 Bad Request / 404 Not Found lors de l'extraction à partir d'une branche de dépôt) Tentative d'extraction à partir d'une branche de dépôt non initialisée ou d'une branche dont les fichiers JSON ont été exportés à l'aide du schéma GitSync version 53.0 incompatible.
  • Si la branche a été modifiée à l'aide de GitSync version 53.0, remplacez le paramètre Branch (Branche) par votre branche de dépôt antérieure à la version 53 ou restaurez la sauvegarde de votre branche antérieure à la version 53 (voir Rollback de la version 53.0 et compatibilité avec les versions 52.0/54.0).
  • Si vous configurez une nouvelle branche sur la version 52.0 ou 54.0, exécutez d'abord un job Push Content (Envoyer du contenu) complet pour remplir la branche avant d'exécuter des jobs d'extraction.
Playbook '<Playbook_Name>' is assigned to environment(s) that don't exist Un playbook ou un bloc en cours d'importation est attribué à un environnement ou à un groupe d'environnements qui n'a pas été créé sur l'instance de destination. Exécutez Extraire le contenu avec l'option Environnements sélectionnée en premier, ou créez manuellement l'environnement manquant dans Paramètres > Environnements sur l'instance de destination avant d'extraire les playbooks.
Commit Author parameter must be in the following format: Name <example@gmail.com> Le paramètre Auteur du commit dans l'instance d'intégration ou la configuration du job ne contient pas d'adresse e-mail entre crochets. Mettez à jour le paramètre Auteur du commit pour qu'il corresponde au format requis : Name <email@domain.com> (par exemple, GitSync <gitsync@example.com>).
400 Bad Request ou 409 Conflict lors de l'importation de mappages d'ontologie Les règles de mappage d'événements du dépôt sont en conflit avec les règles d'ontologie de la plate-forme existantes ou ont été exportées à l'aide d'une version de GitSync incompatible. Exécutez un nouveau job Push Mappings (Transférer les mappages) à l'aide de GitSync version 54.0 ou 52.0 pour réexporter les définitions de mappage, ou résolvez les règles de mappage d'événements en double dans Paramètres > Ontologie > Règles de mappage avant de réexécuter le job.

Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.