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 :
- Remplissez les conditions préalables et configurez les identifiants.
- Configurez l'instance d'intégration partagée.
- Testez la connectivité réseau et l'authentification avec l'action Ping.
- Exécutez un job d'envoi de contenu initial pour remplir la branche avant d'exécuter des jobs d'extraction.
- 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
Passwordsoient exclus par défaut, sauf siCommit Passwordsest 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.mdou.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
Administratorles 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 :
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_rsaCette commande crée deux fichiers :
id_rsa(clé privée) etid_rsa.pub(clé publique).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.Convertissez la clé privée en une chaîne encodée en base64 sur une seule ligne :
Linux/macOS :
base64 -w 0 ./id_rsaWindows (PowerShell) :
[Convert]::ToBase64String([System.IO.File]::ReadAllBytes(".\id_rsa"))
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 :
Récupérez l'empreinte de votre hôte : Exécutez
ssh-keyscandans 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...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 :
- Dans Google SecOps, accédez à Playbooks et sélectionnez le playbook cible.
- Ouvrez les paramètres d'autorisation du playbook.
- 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 :
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.
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.
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/etSettings/) et exécutez une tâche Push Content complète à partir de la version 52.0 ou 54.0 pour remplir à nouveau la branche.
- Si vous avez créé une branche distincte pour la version 53.0 (par exemple,
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 Lorsque vous utilisez l'authentification SSH, l'URL doit commencer par |
Branch |
Obligatoire. Branche du dépôt Git avec laquelle effectuer la synchronisation (par exemple, |
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, 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 : |
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 |
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 ContentetPull 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 PlaybooketPull PlaybookConnecteurs :
Push ConnectorsetPull ConnectorIntégrations :
Push IntegrationetPull IntegrationJobs planifiés :
Push JobetPull JobsMappages d'ontologie :
Push MappingsetPull MappingsFamilles visuelles personnalisées :
Push Custom FamilyetPull Custom FamilyScénarios de test simulés :
Push Simulated CasesetPull 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 |
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 |
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 |
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 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 |
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 |
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 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 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 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 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 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. |
|
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. |
|
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.