Gestion du périmètre surveillé
Découvrez comment gérer, surveiller et dépanner efficacement vos sources intégrées grâce au tableau de bord et aux outils du périmètre de GitGuardian.
Pour obtenir des conseils sur les sources à intégrer et leur comparaison, consultez notre Vue d'ensemble de l'intégration des 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 affectations d'équipe.
Votre page de périmètre a deux objectifs principaux :
- Identifier lesquelles de vos sources sont à risque
- S'assurer que l'ensemble de votre périmètre est bien protégé par GitGuardian
Pour naviguer efficacement dans le tableau du périmètre, les utilisateurs peuvent tirer parti des vues enregistrées pour basculer entre différents ensembles 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 le scan historique et la 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 de push (et ses commits) est scanné à la recherche de secrets dès qu'il arrive sur votre serveur VCS (post-receive hooks).
Nous utilisons le même concept pour d'autres sources de données, telles que Slack et Jira, via l'abonnement à des événements spécifiques.
Nous vous alertons ensuite instantanément, ce qui vous fera gagner du temps dans le processus de remédiation. En effet, plus un secret reste exposé longtemps, plus la remédiation devient difficile.
Dans le panneau de droite, 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 de 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 de push. Par défaut, cette limite est de 1 000 commits scannés par événement de push, mais elle peut être personnalisée par workspace sur demande.
Scan incrémental
GitGuardian fournit une protection continue via des scans automatisés planifiés de votre contenu lorsque l'intégration ne propose pas de support des Webhooks.
Les contenus nouveaux et modifiés sont systématiquement surveillés à intervalles réguliers, assurant une couverture complète et une détection rapide de toute exposition de secret. Votre source reste sous la protection de GitGuardian, vous donnant l'assurance que les secrets ne passeront pas inaperçus.
Scan historique
Le second type de protection proposé est la possibilité de scanner l'historique des commits de toutes les sources que vous avez intégrées à GitGuardian.
Des limites 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 sur lequel aucun nouveau commit n'a été effectué sur aucune branche depuis le dernier scan historique, GitGuardian ignorera le scan pour éviter de retraiter l'intégralité de l'historique. 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 ne récupère que les branches (refs/heads/*) et les tags (refs/tags/*). Lorsque vous lancez 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 que le serveur distant expose 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 | Ce qu'il contient | 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/* | Références 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/* | Références conservées par GitLab pour empêcher le garbage collection (ex. commits de pipeline CI) | GitLab |
| Autres namespaces personnalisés | Tout ce que le serveur distant expose (ex. refs/sandbox/*, refs/replace/*, …) | Tous les fournisseurs |
Erreurs potentielles lors du scan historique et leur résolution
| Raison | Message d'erreur | Étapes de résolution |
|---|---|---|
| Retrait DMCA | La source n'est pas disponible 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'IP autorisées configurée. | Contactez le propriétaire de la source pour examiner et ajuster la liste d'IP autorisées. |
| 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 clone bloquée ou trop lente | La connexion au serveur est lente ou bloquée. | Contactez l'administrateur VCS pour investiguer les problèmes de connexion au serveur. |
| VCS non prêt ou a répondu avec une erreur | Le serveur n'a pas répondu après plusieurs tentatives. | Contactez l'administrateur VCS pour vous assurer que le serveur est opérationnel et réessayez 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 la réinitialisation de la limite de débit 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 de dépôts plus volumineux. Pour les environnements Self-Hosted, envisagez d'ajuster repo_scan_size_limit dans les préférences au sein de l'Admin area. |
| Timeout | Le scan historique a échoué à cause 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 au sein de l'Admin area. |
| Timeout Pending | Le scan historique a échoué à cause d'une erreur de timeout car il a dépassé la limite de temps autorisée pour un scan en masse. Veuillez contacter notre support. | Contactez le support GitGuardian pour résoudre les timeouts de scan en masse et explorer des solutions alternatives. Pour les environnements Self-Hosted, envisagez d'ajuster repo_scan_pending_limit_in_hours dans les préférences au sein de l'Admin area. |
| Erreur du worker de scan | Le scan a échoué à cause d'une erreur interne du worker, souvent causée par des limitations de mémoire. | Veuillez contacter notre équipe de support. Si vous utilisez GitGuardian dans un environnement Self-Hosted, envisagez d'augmenter l'allocation de 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émentaire. |
| Erreur du moteur | Le scan a échoué à cause 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 a 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 à l'intérieur du dépôt est trop long. | En raison de limitations internes, les dépôts contenant 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 a trop de problèmes à scanner. | Une limite de sécurité de 200 000 incidents par source est en place. Ce seuil est peu susceptible d'ê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 récupérée par le garbage collector. |
| Application Slack absente du canal | L'installation du canal est peut-être encore en cours. Veuillez réessayer plus tard. | 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 réessayez le scan. Si l'erreur persiste, vérifiez que l'application GitGuardian pour Slack a été ajoutée au canal. |
| Inconnu | Le scan a échoué à cause 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'intégralité de l'historique 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 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 rythme automatiquement son scan pour rester dans les limites connues du fournisseur, il n'y a 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 limiter les requêtes de GitGuardian, ralentissant considérablement les scans historiques et la détection en temps réel, ou causant une erreur de limite de débit.
Pour scanner ces sources dans un délai raisonnable, nous vous recommandons soit d'augmenter 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 des 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, s'applique au trafic de l'API REST. Ajoutez le compte GitGuardian comme exemption afin que son scan ne soit pas limité.
Statut de la source
Chaque source de votre périmètre a un statut : Monitored, Unmonitored, Unreachable, Archived, ou Deleted. Vous pouvez filtrer sur ce statut depuis la page Perimeter et la liste des incidents, et enregistrer le résultat sous forme de vue, par exemple pour mettre de côté les incidents provenant de sources archivées ou supprimées.
Un secret valide dans une source archivée ou supprimée n'est pas nécessairement moins risqué. Archiver ou supprimer la source ne révoque pas le secret, traitez donc ces incidents selon leurs propres mérites.
Source Monitored
Une source est considérée comme monitored lorsque la plateforme GitGuardian écoute toute activité sur cette source.
Cela résulte de :
- l'intégration réussie de GitGuardian avec la source
- et le fait de disposer d'un plan qui prend en charge sa surveillance.
Les sources monitored sont listées sur la page Perimeter.
Source Unmonitored
Une source est considérée comme unmonitored lorsque GitGuardian n'écoute plus aucune activité sur cette source.
Cela peut résulter de :
- l'exclusion de la source du périmètre surveillé,
- ou d'un changement dans votre plan qui ne prend plus en charge cette source.
Une source unmonitored présente un risque, car aucune occurrence ne sera créée après la publication d'un secret dedans.
Une telle source est identifiée par une icône de bouclier barré à côté d'elle.
Les sources unmonitored ne sont plus listées sur la page Perimeter.
Retirer la surveillance d'une source la retire de toutes ses équipes. En conséquence :
- les membres de ces équipes perdent l'accès aux incidents liés à cette source,
- et la source n'affiche plus aucune affectation d'équipe sur la page du périmètre.
Seuls les Managers et Owners peuvent surveiller ou retirer la surveillance d'une source.
Source Unreachable
Une source est unreachable lorsque GitGuardian ne peut pas s'y connecter, par exemple après l'expiration des identifiants, la révocation de l'accès ou une indisponibilité temporaire du fournisseur.
Tant qu'une source est unreachable, GitGuardian met en pause l'ingestion en temps réel et les scans historiques sur celle-ci, puis les reprend automatiquement une fois la connectivité rétablie. GitGuardian affiche également une étape de récupération exploitable afin que vous puissiez résoudre le problème sous-jacent. Consultez le guide d'intégration concerné pour connaître les étapes spécifiques au fournisseur.
Source Archived
Une source est considérée comme archived lorsqu'elle a été archivée chez le fournisseur, par exemple un dépôt archivé sur GitHub. Aucune nouvelle activité n'est attendue sur une source archived, mais ses incidents existants restent visibles afin que vous puissiez toujours agir dessus.
Source Deleted
Une source est considérée comme deleted uniquement lorsque GitGuardian reçoit la preuve de sa suppression effective. Cela signifie que nous ne considérons pas une source comme deleted simplement parce qu'elle a été retirée de GitGuardian, mais uniquement lorsqu'elle a été véritablement 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 deleted 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 voir le contenu de cette source. Votre secret est publiquement exposé et présente un risque de sécurité plus élevé.internal(spécifique à GitLab) : les projets GitLab internes peuvent être consulté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 voir 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 low, medium, high ou critical, ou de la laisser non renseignée, 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 du périmètre vous permettent de gérer plusieurs sources simultanément, rationalisant votre flux de surveillance du périmètre.
Comment utiliser les actions en masse
- Naviguez vers votre page Perimeter
- 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 de la page, ou cliquez sur « Select all X sources » pour sélectionner toutes celles qui correspondent à vos filtres actuels.
Actions disponibles
Gestion des sources
- Monitor : commence la surveillance des sources sélectionnées.
- Unmonitor : arrête la surveillance des sources sélectionnées. Retirer la surveillance d'une source la retire également de toutes ses équipes, de sorte que les membres de ces équipes perdent l'accès aux incidents de la source (voir Source Unmonitored).
- Assign team : ajoute les sources sélectionnées à une équipe. Seules les sources monitored sont ajoutées à l'équipe ; toute source unmonitored dans votre sélection est ignorée.
- Set criticality : met à jour les niveaux de criticité métier (Critical, High, Medium, Low) pour plusieurs sources.
- Scan : lance des scans historiques sur les sources sélectionnées (si le scan est activé).
Bonnes pratiques
- Filtrez d'abord : utilisez la recherche et les filtres pour affiner votre sélection de sources
- Vérifiez 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 de la sélection.
- É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 du 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 surveiller et retirer la surveillance des sources, affecter des sources à des équipes, mettre à jour la criticité des sources et lancer des scans.
- Member : peut lancer des scans sur les sources du périmètre de son équipe, mais ne peut pas surveiller ou retirer la surveillance des sources, affecter des équipes ou mettre à jour la criticité des sources.
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 de l'intégration des sources complète qui fournit :
- Comparaison des capacités entre tous les types de sources
- Guides d'intégration organisés par catégorie
- Conseils stratégiques sur la priorisation des intégrations
- Recommandations pour démarrer
La vue d'ensemble comprend 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.
Dépannage 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 synchroniser automatiquement vos règles de pare-feu :
- US :
GET https://api.gitguardian.com/v1/ips(Référence de l'API) - EU :
GET https://api.eu1.gitguardian.com/v1/ips(Référence de l'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é d'ajouter les domaines à la 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 utilisé exclusivement pour rediriger vers HTTPS.
