Aller au contenu principal

Valider et déployer

Valider sur 10 à 20 machines​

Avant un déploiement à grande échelle, déployez sur 10 à 20 machines étroitement surveillées et confirmez tous les points suivants :

  • ggshield s'installe correctement, et ggshield --version indique 1.53.0 ou une version ultérieure.
  • Le binaire est présent dans le PATH de chaque utilisateur. Avec le script d'installation, GGSHIELD_BIN_DIR=/usr/local/bin le rend accessible depuis une tâche MDM exécutée en tant que root et depuis sudo -i.
  • ggshield plugin list affiche machine_scan pour l'utilisateur de scan.
  • Les tâches d'administration injectent le SAT via stdin, afin qu'il reste hors des lignes de commande et de l'historique du shell. Votre MDM masque les variables d'environnement secrètes et le stdin capturé dans ses journaux.
  • ggshield machine setup se termine correctement et est idempotent : une seconde exécution n'ajoute rien qui soit déjà en place.
  • ggshield auth logout --no-revoke, puis ggshield auth login, exécutés en tant qu'utilisateur connecté. La connexion ouvre un navigateur dans sa session. Pour les instances EU ou self-hosted, les deux commandes ont utilisé --instance.
  • Le ggshield machine setup récurrent injecte toujours le SAT d'administration via stdin.
  • ggshield machine report se termine correctement, que vous injectiez le SAT pour cette tâche ou que vous l'exécutiez en tant qu'utilisateur connecté après la connexion.
  • ggshield machine doctor se termine avec le code zéro lorsqu'il est exécuté depuis un dépôt git, ce dont il a besoin pour résoudre le core.hooksPath effectif. Utilisez-le comme script d'audit MDM qui conditionne la vague suivante. Chaque vérification en échec affiche son propre correctif.
  • La durée de scan est acceptable, et les utilisateurs ne signalent aucun problème de performance notable.

Si vous déployez la protection par honeytoken, confirmez également :

  • ggshield honeytoken plant --list-targets résout la cible attendue sur une machine de test.
  • Après machine setup, le honeytoken est présent et les profils AWS existants du développeur ne sont pas modifiés.

Si vous déployez les AI Hooks, confirmez également :

  • machine doctor signale le hook installé pour chaque assistant de codage IA qu'il trouve sur la machine.
  • Le développeur est connecté. Sur une machine d'exemple, coller un identifiant de test dans une invite affiche le message de blocage de ggshield. S'il n'est pas connecté, le hook échoue en mode ouvert et n'affiche qu'un avertissement.

Si vous collectez l'inventaire IA et MCP, confirmez également :

  • ggshield ai discover se termine correctement.

Ne passez au déploiement basé sur des pourcentages qu'une fois ce premier groupe en bonne santé.

Confirmer la visibilité dans le dashboard Endpoints​

Dans votre dashboard GitGuardian, ouvrez Endpoint protection > Endpoints et vérifiez que les machines pilotes apparaissent comme prévu :

  • Le tableau des machines liste chaque endpoint pilote avec une heure de latest endpoint scan, et non Never scanned.
  • Les KPI de couverture du parc reflètent le groupe pilote, de sorte que le pourcentage Endpoints scan augmente après l'exécution des scans.
  • L'ouverture d'une machine affiche Local scanning avec les décomptes de sévérité et une version de scanner ggshield sur le dernier scan.
  • Le tableau Discovered secrets se charge pour les machines où le scan a trouvé des identifiants. Un tableau vide est acceptable sur une machine de test propre.
  • Si vous avez déployé la protection par honeytoken, les machines pilotes s'affichent comme Protected, et la carte Honeytoken protection d'une machine indique une synchronisation récente.
  • Si vous avez déployé les AI Hooks, la carte AI hooks coverage reflète le groupe pilote, et la colonne AI agents indique quels agents disposent de garde-fous.
  • Si vous avez déployé l'inventaire IA et MCP, l'onglet AI Agents d'une machine liste les agents et serveurs MCP trouvés par ai discover, y compris si l'abonnement de chaque agent est personnel ou d'entreprise.

Pour les vérifications CLI et MDM ci-dessus, consultez Déployer ggshield à grande échelle avec un token de compte de service. Pour savoir comment lire chaque vue, consultez Surveiller la couverture.

Déployer à grande échelle​

Voici le parcours de déploiement suggéré :

10-20 monitored machines → 1% → 10% → 25% → 50% → 100%
| | | | |
+-------------+-----+------+-------+-- pause / rollback gates

Nous recommandons les approches suivantes pour réussir un déploiement à grande échelle :

  • Répartissez les vagues par région, fuseau horaire, unité opérationnelle, OS ou type d'appareil.
  • Étalez les premiers scans sur des heures ou des jours, pas des minutes.
  • Sur Windows, déployez l'exclusion Microsoft Defender pour le processus du scanner avec le package, afin que les durées de scan pilotes soient représentatives.
  • Utilisez la mise en cache des packages ou la distribution interne pour les très grands parcs.
  • Surveillez les erreurs et l'impact sur les endpoints avant chaque augmentation. Conditionnez la vague suivante à ce que ggshield machine doctor retourne zéro sur un échantillon de la vague en cours.

Revenir en arrière​

Désactivez d'abord les tâches planifiées, en particulier machine setup. Cette tâche réconcilie les honeytokens avec GitGuardian à chaque exécution, de sorte qu'une passe de nettoyage est annulée le lendemain si setup est toujours activé.

Ensuite, supprimez ce qui est déjà sur le disque :

  • Honeytokens : ggshield honeytoken plant --remove-only.
  • AI Hooks : supprimez les entrées ggshield de la configuration des hooks de l'outil, listées dans Prévenir les fuites avec les AI Hooks.

ggshield auth logout --no-revoke en tant qu'utilisateur connecté supprime son token personnel. Révoquez le SAT d'administration dans votre workspace pour couvrir l'ensemble du parc en une seule fois.