Gestion du périmètre surveillé
Apprenez à gérer, surveiller et résoudre efficacement les problèmes liés à vos sources intégrées en utilisant le dashboard et les outils du périmètre GitGuardian.
Pour des conseils sur les sources à intégrer et leur comparaison, consultez notre Vue d'ensemble des intégrations de sources.
Comprendre votre périmètre
Votre périmètre englobe toutes les sources que vous avez intégrées à GitGuardian pour la surveillance des secrets. Cela inclut les dépôts, les registres de conteneurs, les plateformes de messagerie, les systèmes de documentation, et plus encore.
Si votre workspace utilise le périmètre d'équipe, l'accès aux incidents suit les assignations d'équipe.
Votre page de périmètre a deux objectifs principaux :
- Identifier celles de vos sources qui sont à risque
- S'assurer que l'ensemble de votre périmètre est bien protégé par GitGuardian
Pour une navigation efficace dans le tableau du périmètre, les utilisateurs peuvent tirer parti des vues enregistrées pour basculer entre différents jeux de filtres. La fonctionnalité inclut des vues GitGuardian non modifiables telles que « All sources », « Critical sources », « Scanning issues », « With open secret incidents », « Without honeytoken ».
Différences entre scan historique et protection en temps réel
Surveillance en temps réel
La première protection, et la plus efficace pour la remédiation des secrets, est la surveillance en temps réel.
Comme vous avez pu le lire dans notre section Fonctionnement d'Internal Monitoring, la surveillance en temps réel signifie que chaque événement push (et ses commits) est scanné à la recherche de secrets dès son arrivée sur votre serveur VCS (hooks post-receive).
Nous utilisons le même concept pour d'autres sources de données, telles que Slack et Jira, via la souscription à des événements spécifiques.
Nous vous alertons ensuite instantanément, ce qui vous fait gagner du temps dans le processus de remédiation. En effet, plus un secret est exposé longtemps, plus la remédiation est difficile.
Dans le panneau latéral droit, nous indiquons le pourcentage de sources couvertes, en fonction du nombre de sources que vous avez intégrées à GitGuardian. Notez que certaines sources peuvent ne pas être éligibles à la surveillance en raison de restrictions liées au plan.
Notez que le tableau des sources affiché sur la page Perimeter ne contient que les sources surveillées en temps réel. Les sources qui ne sont pas sélectionnées dans la page des paramètres d'intégration ne sont pas affichées.
Pour des raisons de performance, nous limitons le nombre de commits scannés par événement push. Par défaut, cette limite est de 1 000 commits scannés/événement push, mais elle peut être personnalisée par workspace sur demande.
Scan incrémental
GitGuardian fournit une protection continue grâce à des scans automatisés planifiés de votre contenu lorsque l'intégration ne prend pas en charge les Webhooks.
Le contenu nouveau et modifié est systématiquement surveillé à intervalles réguliers, garantissant une couverture complète et une détection rapide de toute exposition de secret. Votre source reste sous la protection de GitGuardian, vous assurant que les secrets ne passeront pas inaperçus.
Scan historique
Le second type de protection proposé est la capacité à scanner l'historique des commits de toutes les sources que vous avez intégrées à GitGuardian.
Des limitations de taille s'appliquent aux scans historiques, selon votre plan :
- Free : vous pouvez scanner des sources jusqu'à 1 Go,
- Business et essai : vous pouvez scanner des sources jusqu'à 12 Go.
Pour des raisons de performance, si un scan historique est demandé pour un dépôt qui n'a eu aucun nouveau commit sur aucune branche depuis le dernier scan historique, GitGuardian ignorera le scan pour éviter de retraiter l'historique entier. Cependant, si la version du tokenscanner a changé depuis le dernier scan historique — GitGuardian ayant introduit de nouveaux détecteurs — le scan sera effectué, même s'il n'y a pas de nouveaux commits.
Scan des commits orphelins et des références Git supplémentaires lors des scans historiques
Un git clone standard n'apporte que les branches (refs/heads/*) et les tags (refs/tags/*). Lorsque vous exécutez un scan historique sur un système de gestion de versions, GitGuardian va plus loin : après le clone initial, il inspecte chaque référence exposée par le remote et récupère celles qui ne sont pas déjà couvertes.
Les namespaces suivants sont récupérés automatiquement :
| Namespace de référence | Contenu | Fournisseur |
|---|---|---|
refs/pull/* | Commits head / merge des pull requests ouvertes, fermées et fusionnées | GitHub, Azure DevOps |
refs/merge-requests/* | Commits des merge requests ouvertes, fermées et fusionnées | GitLab |
refs/pull-requests/* | Commits head / merge des pull requests | Bitbucket (Cloud & Data Center) |
refs/changes/* | Refs de changements en attente et abandonnés | Gerrit |
refs/notes/* | Notes Git (refs/notes/commits et tout namespace de notes personnalisé) | Tous les fournisseurs |
refs/keep-around/* | Refs que GitLab conserve pour empêcher la garbage collection (ex. commits de pipeline CI) | GitLab |
| Autres namespaces personnalisés | Tout ce que le remote expose par ailleurs (ex. refs/sandbox/*, refs/replace/*, …) | Tous les fournisseurs |
Erreurs potentielles lors du scan historique et leurs résolutions
| Raison | Message d'erreur | Étapes de résolution |
|---|---|---|
| Retrait DMCA | La source est indisponible en raison d'un retrait DMCA. | Contactez le propriétaire de la source pour discuter du retrait DMCA. |
| L'accès au dépôt est désactivé | La source a été désactivée. | Contactez le propriétaire de la source pour demander la réactivation de l'accès au dépôt. |
| Le compte a été désactivé | Le compte de la source a été désactivé. | Contactez le propriétaire de la source pour résoudre les problèmes de compte et retrouver l'accès. |
| Accès au dépôt restreint par IP | Le compte de la source dispose d'une liste d'autorisation IP configurée. | Contactez le propriétaire de la source pour examiner et ajuster la liste d'autorisation IP. |
| Dépôt introuvable | La source est introuvable. Veuillez réessayer et contacter le propriétaire de la source si le problème persiste. | Vérifiez l'URL du dépôt et réessayez. Contactez le propriétaire de la source si le problème persiste. |
| Opération de clonage bloquée ou trop lente | La connexion au serveur est lente ou bloquée. | Contactez l'administrateur VCS pour examiner les problèmes de connexion au serveur. |
| VCS non prêt ou ayant répondu avec une erreur | Le serveur n'a pas répondu après plusieurs tentatives. | Contactez l'administrateur VCS pour s'assurer que le serveur est opérationnel et relancez le scan. |
| Dépôt désactivé dans le projet GitLab | Le dépôt git dans le projet GitLab a été désactivé. | Activez la fonctionnalité « repository » dans les paramètres du projet GitLab. |
| Le dépôt a été supprimé | Le dépôt cible a été supprimé. | Contactez l'administrateur VCS pour confirmer et traiter la suppression du dépôt. |
| Erreur d'authentification VCS | L'authentification au VCS a échoué. | Vérifiez le token d'authentification dans Settings > Integrations et contactez l'administrateur VCS si nécessaire. |
| Erreur de limite de débit | La limite de débit a été dépassée. | Attendez que la limite de débit soit réinitialisée ou contactez l'administrateur VCS pour une résolution. |
| Trop volumineux | Le scan historique a échoué car il a dépassé la limite de taille autorisée. | Contactez le support GitGuardian pour discuter des options de scan pour des dépôts plus volumineux. Pour les environnements Self-Hosted, envisagez d'ajuster repo_scan_size_limit dans les préférences de la zone Admin. |
| Timeout | Le scan historique a échoué en raison d'une erreur de timeout car il a dépassé la limite de temps autorisée pour un scan individuel. | Contactez le support GitGuardian pour le dépannage et potentiellement étendre la limite de temps du scan. Pour les environnements Self-Hosted, envisagez d'ajuster repo_scan_time_limit_in_sec dans les préférences de la zone Admin. |
| Timeout Pending | Le scan historique a échoué en raison d'une erreur de timeout car il a dépassé la limite de temps autorisée pour un scan en lot. Veuillez contacter notre support. | Contactez le support GitGuardian pour traiter les timeouts de scan en lot et explorer des solutions alternatives. Pour les environnements Self-Hosted, envisagez d'ajuster repo_scan_pending_limit_in_hours dans les préférences de la zone Admin. |
| Erreur du worker de scan | Le scan a échoué en raison d'une erreur interne du worker, souvent causée par des limitations de mémoire. | Veuillez contacter notre équipe de support. Si vous exécutez GitGuardian dans un environnement Self-Hosted, envisagez d'augmenter l'allocation mémoire pour les workers afin de résoudre le problème. De plus, générez un Support Bundle à des fins de dépannage supplémentaires. |
| Erreur du moteur | Le scan a échoué en raison d'une erreur interne du moteur. | Veuillez contacter notre équipe de support. Si vous exécutez GitGuardian dans un environnement Self-Hosted, générez un Support Bundle à des fins de dépannage. |
| Processus reçu SIGKILL | Le processus de scan a été terminé de force (SIGKILL). | Veuillez contacter notre équipe de support. Si vous exécutez GitGuardian dans un environnement Self-Hosted, générez un Support Bundle à des fins de dépannage. |
| Nom de fichier trop long | Un nom de fichier dans le dépôt est trop long. | En raison de limitations internes, les dépôts avec des noms de fichiers de plus de 255 octets (environ > 200 caractères, selon les caractères utilisés) empêchent les dépôts d'être scannés. Vous pouvez trouver ces fichiers avec des commandes telles que find . -type f | awk -F/ '{if(length($NF)>200) print}'. |
| Référence Git introuvable | La référence n'existe plus. | Cela se produit généralement si le dépôt utilise un sous-module mais que la référence donnée pour le sous-module n'existe plus. Contactez le propriétaire de la source pour vérifier la configuration des sous-modules. |
| Limite de sécurité atteinte | La source contient trop de problèmes à scanner. | Une limite de sécurité de 200 000 incidents par source est en place. Ce seuil ne devrait pas être atteint en usage normal, mais si vous le rencontrez, veuillez contacter notre équipe de support. |
| Fichier d'image de conteneur introuvable dans le registre | Une couche de l'image de conteneur n'a pas été trouvée dans le registre et n'a pas pu être téléchargée. | Vérifiez que l'image de conteneur existe toujours dans le registre et n'a pas été supprimée ou collectée par le garbage collector. |
| Application Slack absente du canal | L'installation du canal est peut-être encore en cours. Veuillez réessayer ultérieurement. | L'application GitGuardian pour Slack est peut-être encore en train de terminer son installation dans le canal. Attendez quelques minutes que l'installation se termine et relancez le scan. Si l'erreur persiste, vérifiez que l'application GitGuardian pour Slack a bien été ajoutée au canal. |
| Inconnu | Le scan a échoué en raison d'une erreur inconnue. | Veuillez contacter notre équipe de support. Si vous exécutez GitGuardian dans un environnement Self-Hosted, générez un Support Bundle à des fins de dépannage. |
Le scan historique est également disponible pour Slack. Vous pouvez scanner l'historique complet de vos canaux Slack publics et privés surveillés. Les conversations et les canaux archivés ne sont pas pris en charge.
Notez que le scan historique est soumis à la limitation de débit de l'API de Slack. Nous pouvons scanner jusqu'à 10 000 messages/min par workspace Slack.
Les rapports de scan historique de Slack et de VCS sont envoyés séparément.
Limites de débit sur les sources Self-Hosted
Certaines intégrations de sources appliquent des limites de débit d'API. Pour les services SaaS tels que GitHub.com ou Slack, GitGuardian régule automatiquement son scan pour rester dans les limites connues du fournisseur, vous n'avez donc rien à configurer.
Pour les sources Self-Hosted, les limites sont contrôlées par votre propre instance. Lorsque la limitation de débit est activée, les valeurs par défaut peuvent être assez basses et peuvent restreindre les requêtes de GitGuardian, ralentissant considérablement les scans historiques et la détection en temps réel, ou provoquant une Erreur de limite de débit.
Pour scanner ces sources dans un délai raisonnable, nous vous recommandons soit de relever les limites de débit sur votre instance, soit d'exempter le compte, le token ou le compte de service que GitGuardian utilise de la limitation de débit. La plupart des plateformes vous permettent d'accorder une exemption par utilisateur ou une limite plus élevée sans modifier le paramètre global.
Les sources Self-Hosted suivantes vous permettent de configurer les limites de débit :
Sur les produits Atlassian Data Center (Bitbucket, Jira, Confluence), la limitation de débit est désactivée par défaut mais, une fois activée, elle s'applique au trafic de l'API REST. Ajoutez le compte GitGuardian comme exemption afin que son scan ne soit pas restreint.
Statut de la source
Source surveillée
Une source est considérée comme surveillée lorsque la plateforme GitGuardian est à l'écoute de toute activité sur cette source.
C'est le résultat de :
- l'intégration réussie de GitGuardian avec la source
- et d'un plan qui prend en charge sa surveillance.
Les sources surveillées sont listées sur la page Perimeter.
Source qui n'est plus surveillée
Une source est considérée comme n'étant plus surveillée lorsque GitGuardian n'écoute plus aucune activité sur cette source.
Cela peut résulter de :
- la désinstallation de GitGuardian de la source,
- ou de l'exclusion de la source du périmètre surveillé,
- ou d'un changement de votre plan qui ne prend plus en charge cette source.
Une source qui n'est plus surveillée présente un risque, car aucune occurrence ne sera créée après qu'un secret y a été publié.
Une telle source est identifiée par une icône de bouclier barré à côté d'elle.
Les sources qui ne sont plus surveillées ne sont plus listées sur la page Perimeter.
Source supprimée
Une source est considérée comme supprimée uniquement lorsque GitGuardian reçoit la preuve de sa suppression effective. Cela signifie que nous ne considérons pas une source comme supprimée simplement parce qu'elle a été retirée de GitGuardian, mais seulement lorsqu'elle a réellement été effacée. Par exemple : le dépôt est supprimé sur GitHub.
Une telle source est identifiée par une icône de corbeille à côté d'elle.
Les sources supprimées ne sont plus listées sur la page Perimeter.
Visibilité de la source
Une source est définie par un périmètre de visibilité. Selon l'instance installée, une source peut être :
public: toute personne ayant accès à Internet peut visualiser le contenu de cette source. Votre secret est exposé publiquement et présente un risque de sécurité plus élevé.internal(spécifique à GitLab) : les projets GitLab internes peuvent être visualisés par tout utilisateur authentifié, à l'exception des utilisateurs externes. Un tel projet GitLab est identifié par une icône de bouclier à côté de lui.private: seuls les utilisateurs autorisés ayant accès à la source peuvent visualiser son contenu. Une telle source est identifiée par une icône de cadenas à côté d'elle.
Criticité de la source
La fonctionnalité de criticité de la source vous permet d'évaluer et d'attribuer un niveau d'importance à vos sources surveillées, vous aidant à prioriser efficacement vos incidents. Cette fonctionnalité vous permet de les catégoriser comme faible, moyenne, élevée ou critique, ou de laisser ce champ vide, en fonction de la gravité potentielle de l'impact d'un incident de sécurité. Sa valeur dépend du contexte métier de votre source, qui sera déterminé par des facteurs tels que la nature des données traitées et sa connexion à des ressources dans un environnement de production.
Actions en masse sur les sources du périmètre
Les actions en masse sur la page de périmètre vous permettent de gérer plusieurs sources simultanément, rationalisant votre flux de travail de surveillance du périmètre.
Comment utiliser les actions en masse
- Naviguez vers votre page de périmètre
- Sélectionnez plusieurs sources à l'aide des cases à cocher
- La barre d'outils des actions en masse apparaît en haut
- Choisissez l'action souhaitée
Utilisez la case à cocher de l'en-tête pour sélectionner toutes les sources sur la page, ou cliquez sur « Select all X sources » pour sélectionner toutes celles qui correspondent à vos filtres actuels.
Actions disponibles
Gestion des sources
- Définir la criticité : Mettez à jour les niveaux de criticité métier (Critical, High, Medium, Low) pour plusieurs sources
- Scan : Lancez des scans historiques sur les sources sélectionnées (si le scan est activé)
Bonnes pratiques
- Filtrer d'abord : Utilisez la recherche et les filtres pour affiner votre sélection de sources
- Vérifier la sélection : Le bouton « Select all » ne sélectionne que les sources affichées. Utilisez « Select all sources that match the filters » pour sélectionner l'ensemble.
- Évaluation de la criticité : Définissez la criticité de la source en fonction de l'impact métier et des environnements de production
- Scan : Tenez compte de la charge système lors du lancement de scans historiques en masse (Self-Hosted)
Permissions
Les actions en masse sur les sources nécessitent des permissions appropriées dans le workspace :
- Manager : Peut effectuer des mises à jour de criticité de source et lancer des scans
- Member : Peut lancer des scans sur les sources dans le périmètre de son équipe, mais ne peut pas mettre à jour la criticité de la source.
Ajouter de nouvelles sources à votre périmètre
Pour étendre votre périmètre surveillé avec de nouvelles intégrations, consultez notre Vue d'ensemble des intégrations de sources complète qui fournit :
- Comparaison des capacités entre tous les types de sources
- Guides d'intégration organisés par catégorie
- Orientation stratégique pour prioriser les intégrations
- Recommandations pour démarrer
La vue d'ensemble inclut des informations détaillées sur toutes les intégrations disponibles, y compris les VCS, les registres de conteneurs, les plateformes de messagerie, les systèmes de documentation et les sources personnalisées.
Résolution des problèmes de connectivité
Le plus souvent, les problèmes de connectivité surviennent parce qu'un pare-feu, un serveur proxy, un réseau d'entreprise ou un autre r éseau est configuré de manière à bloquer GitGuardian.
Si vous devez autoriser les connexions entrantes/sortantes vers/depuis l'application SAAS, ce paragraphe fournit les informations nécessaires.
Autoriser les connexions entrantes depuis les adresses IP de GitGuardian
GitGuardian expose ses adresses IP de sortie via des endpoints d'API non authentifiés. Vous pouvez les utiliser pour maintenir vos règles de pare-feu synchronisées automatiquement :
- US :
GET https://api.gitguardian.com/v1/ips(référence API) - EU :
GET https://api.eu1.gitguardian.com/v1/ips(référence API)
GitGuardian US utilise les IP suivantes :
- 35.161.89.114/32
- 35.162.178.46/32
- 35.163.105.95/32
- 35.83.131.170/32
- 44.224.13.10/32
- 44.231.207.147/32
- 44.239.165.162/32
- 52.25.45.243/32
- 54.184.247.227/32
- 54.188.183.19/32
- 54.189.40.226/32
- 54.212.233.107/32
GitGuardian EU utilise les adresses IP suivantes :
- 18.153.164.184/32
- 18.158.109.52/32
- 18.184.72.235/32
- 18.198.133.200/32
- 3.127.11.54/32
- 3.64.118.208/32
- 3.75.125.128/32
- 3.76.233.226/32
- 52.28.29.48/32
Ces adresses IP sont utilisées pour :
- Intégrations VCS (ex. : GitHub, GitLab)
- Intégrations de registres de conteneurs (ex. : Amazon ECR, Azure Container Registries, Docker Hub, Google Artifact Registry, JFrog Container Registry)
- Intégrations de messagerie (ex. : Slack, Microsoft Teams)
- Intégrations de ticketing (ex. : Jira Cloud, Jira Data Center, ServiceNow)
- Intégrations de documentation (ex. : Confluence Cloud, Confluence Data Center)
- Intégrations d'alerting (ex. : Slack, Microsoft Teams, PagerDuty, ...)
- Vérifications de validité
Autoriser les connexions sortantes vers les domaines de GitGuardian
Les requêtes vers GitGuardian utilisent des adresses IP qui changent régulièrement. Il est conseillé de mettre les domaines en liste blanche à la place.
Les domaines suivants sont utilisés par GitGuardian US :
- dashboard.gitguardian.com
- hook.gitguardian.com
- api.gitguardian.com
Les domaines suivants sont utilisés par GitGuardian EU :
- dashboard.eu1.gitguardian.com
- hook.eu1.gitguardian.com
- api.eu1.gitguardian.com
Tous les endpoints utilisent HTTPS. HTTP est exclusivement utilisé pour rediriger vers HTTPS.
