Gestion du périmètre surveillé
Apprenez à gérer, surveiller et dépanner efficacement vos sources intégrées en utilisant le dashboard et les outils de périmètre de GitGuardian.
Pour des conseils sur quelles sources intégrer et comment elles se comparent, 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 avec GitGuardian pour la surveillance de 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 périmètre a deux objectifs principaux :
- Identifier lesquelles de vos sources sont à risque
- S'assurer que tout votre périmètre est bien protégé par GitGuardian
Pour une navigation efficace dans la table du périmètre, les utilisateurs peuvent tirer parti des vues sauvegardées pour basculer entre différents ensembles de filtres. La fonctionnalité comprend des vues GitGuardian non modifiables telles que "All sources", "Critical sources", "Scanning issues", "With open secret incidents", "Without honeytoken".
En bas du panneau de droite, la section scope vous donne un résumé rapide des différentes intégrations (types VCS) qui ont été intégrées avec GitGuardian, ainsi qu'une décomposition des sources par intégration.
Différences entre l'analyse 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 l'avez peut-être lu dans notre section Fonctionnement d'Internal Monitoring, la surveillance en temps réel signifie que chaque événement push (et ses commits) est analysé pour détecter des secrets dès leur arrivée 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 est exposé longtemps, plus la remédiation est difficile.
Sur le panneau de droite, nous indiquons le pourcentage de sources couvertes, basé sur le nombre de sources que vous avez intégrées avec GitGuardian. Notez que certaines sources peuvent ne pas être éligibles à la surveillance en raison de restrictions de plan.
Notez que la table des sources affichée sur la page Périmètre ne contient que les sources surveillées en temps réel. Les sources non 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 push. Par défaut, cette limite est de 1 000 commits scannés/événement push, mais cela peut être personnalisé par workspace sur demande.
Analyse incrémentale
GitGuardian fournit une protection continue grâce à des analyses automatisées planifiées de votre contenu lorsque l'intégration n'offre pas de support 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 donnant la confiance que les secrets ne passeront pas inaperçus.
Analyse historique
Le second type de protection offert est la possibilité de scanner l'historique des commits de toutes les sources que vous avez intégrées avec GitGuardian.
Des limitations de taille s'appliquent aux analyses historiques, selon votre plan :
- Free : vous pouvez analyser des sources jusqu'à 1 Go,
- Business et essai : vous pouvez analyser des sources jusqu'à 12 Go.
Pour des raisons de performance, si une analyse historique est demandée pour un dépôt qui n'a eu aucun nouveau commit sur aucune branche depuis la dernière analyse historique, GitGuardian ignorera l'analyse pour éviter de retraiter tout l'historique. Cependant, si la version du tokenscanner a changé depuis la dernière analyse historique — avec GitGuardian ayant introduit de nouveaux détecteurs — l'analyse procédera, même s'il n'y a pas de nouveaux commits.
Erreurs potentielles lors de l'analyse historique et leurs résolutions
| Raison | Message d'erreur | Étapes pour résoudre |
|---|---|---|
| Retrait DMCA | La source est indisponible en raison d'un retrait DMCA. | Contactez le propriétaire de la source pour discuter du retrait DMCA. |
| Accès au dépôt 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. |
| Compte 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 regagner l'accès. |
| Accès au dépôt restreint par IP | Le compte de la source a 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 non trouvé | La source n'a pas pu être trouvée. Veuillez réessayer et contacter le propriétaire de la source si cela 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 enquêter sur les problèmes de connexion serveur. |
| VCS pas 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 s'assurer que le serveur est opérationnel et réessayez l'analyse. |
| 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 sous Settings > Integrations et contactez l'administrateur VCS si nécessaire. |
| Erreur de rate limit | La rate limit a été dépassée. | Attendez que la rate limit se réinitialise ou contactez l'administrateur VCS pour une résolution. |
| Trop volumineux | L'analyse historique a échoué car elle a dépassé la limite de taille autorisée. | Contactez le support GitGuardian pour discuter des options pour scanner des dépôts plus volumineux. Pour les environnements self-hosted, envisagez d'ajuster repo_scan_size_limit dans les preferences au sein de l'Admin area. |
| Timeout | L'analyse historique a échoué en raison d'une erreur de timeout car elle a dépassé la limite de temps autorisée pour une analyse individuelle. | Contactez le support GitGuardian pour le dépannage et pour potentiellement étendre la limite de temps de scan. Pour les environnements self-hosted, envisagez d'ajuster repo_scan_time_limit_in_sec dans les preferences au sein de l'Admin area. |
| Timeout Pending | L'analyse historique a échoué en raison d'une erreur de timeout car elle a dépassé la limite de temps autorisée pour une analyse en masse. Veuillez contacter notre support. | Contactez le support GitGuardian pour traiter les timeouts d'analyse en masse et explorer des solutions alternatives. Pour les environnements self-hosted, envisagez d'ajuster repo_scan_pending_limit_in_hours dans les preferences au sein de l'Admin area. |
| Erreur de scan worker | L'analyse 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 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 de moteur | L'analyse 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. |
| Process 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. |
| Filename 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 plus longs que 255 octets (environ > 200 caractères, selon les caractères utilisés) empêchent les dépôts d'être analysés. Vous pouvez trouver ces fichiers avec des commandes comme find . -type f | awk -F/ '{if(length($NF)>200) print}'. |
| Référence git non trouvée | 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 failsafe atteinte | La source a trop de problèmes à scanner. | Une limite failsafe de 200 000 incidents par source est en place. Ce seuil est peu susceptible d'être atteint en utilisation normale, mais si vous le rencontrez, veuillez contacter notre équipe de support. |
| Fichier image de conteneur non trouvé 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 garbage-collected. |
| Inconnu | L'analyse 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. |
L'analyse historique est également disponible pour Slack. Vous pouvez analyser tout 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 l'analyse historique est soumise à la limitation de débit de l'API Slack. Nous pouvons analyser jusqu'à 10 000 messages/min par workspace Slack.
Les rapports d'analyse historique de Slack et VCS sont envoyés séparément.
Statut de la source
Source surveillée
Une source est considérée comme surveillée lorsque la plateforme GitGuardian écoute toute activité sur cette source.
C'est le résultat de :
- l'intégration réussie de GitGuardian avec la source
- et le fait d'avoir un plan qui prend en charge sa surveillance.
Les sources surveillées sont listées sur la page Périmètre.
Source non 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 être le résultat de :
- la désinstallation de GitGuardian de la source,
- ou l'exclusion de la source du périmètre surveillé,
- ou un changement dans 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ée à côté.
Les sources qui ne sont plus surveillées ne sont plus listées sur la page Périmètre.
Source supprimée
Une source est considérée comme supprimée uniquement lorsque GitGuardian reçoit la preuve de sa suppression réelle. Cela signifie que nous ne considérons pas une source comme supprimée simplement parce qu'elle a été retirée de GitGuardian, mais plutôt 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 poubelle à côté.
Les sources supprimées ne sont plus listées sur la page Périmètre.
Visibilité de la source
Une source est définie par une portée 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 exposé publiquement et présente un risque de sécurité plus élevé.internal(spécifique à GitLab) : les projets GitLab internes peuvent être vus par tout utilisateur authentifié sauf les utilisateurs externes. Un tel projet GitLab est identifié par une icône de bouclier à côté.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é.
Criticité de la source
La fonctionnalité de criticité de 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 remplie, en fonction de la sévérité potentielle de l'impact d'un incident de sécurité. Sa valeur dépend du contexte business de votre source, qui sera déterminé par des facteurs tels que la nature des données traitées et leur connexion aux ressources d'un environnement de production.
Actions en masse sur les sources du périmètre
Les actions en masse sur la page périmètre vous permettent de gérer plusieurs sources simultanément, rationalisant votre workflow de surveillance du périmètre.
Comment utiliser les actions en masse
- Naviguez vers votre page 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 d'en-tête pour sélectionner toutes les sources de la page, ou cliquez sur "Sélectionner les X sources" pour sélectionner toutes celles qui correspondent à vos filtres actuels.
Actions disponibles
Gestion des sources
- Définir la criticité : mettre à jour les niveaux de criticité business (Critical, High, Medium, Low) pour plusieurs sources
- Scan : lancer des analyses historiques sur les sources sélectionnées (si l'analyse est activée)
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 "Tout sélectionner" ne sélectionne que les sources affichées. Utilisez "Sélectionner toutes les sources qui correspondent aux filtres" pour sélectionner toute la sélection.
- Évaluation de la criticité : définissez la criticité de la source en fonction de l'impact business et des environnements de production
- Scan : tenez compte de la charge système lors du lancement d'analyses historiques en masse (self-hosted)
Permissions
Les actions en masse sur les sources nécessitent les permissions de workspace appropriées :
- Manager : peut effectuer des mises à jour de criticité de source et lancer des analyses
- Member : peut lancer des analyses sur les sources au sein du périmètre de leur é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 de l'intégration des sources complète qui fournit :
- Comparaison des capacités sur 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 bien démarrer
L'aperçu inclut des informations détaillées sur toutes les intégrations disponibles, y compris VCS, registres de conteneurs, plateformes de messagerie, systèmes de documentation et sources personnalisées.
Dépanner les problèmes de connectivité
Le plus souvent, les problèmes de connectivité surviennent parce qu'un firewall, un serveur proxy, un réseau d'entreprise ou un autre réseau est configuré d'une manière qui bloque GitGuardian.
Au cas où vous auriez besoin d'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 API non authentifiés. Vous pouvez les utiliser pour synchroniser automatiquement vos règles de firewall :
- 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 (par exemple : GitHub, GitLab)
- Intégrations de registres de conteneurs (par exemple : Amazon ECR, Azure Container Registries, Docker Hub, Google Artifact Registry, JFrog Container Registry)
- Intégrations de messagerie (par exemple : Slack, Microsoft Teams)
- Intégrations de ticketing (par exemple : Jira Cloud, Jira Data Center, ServiceNow)
- Intégrations de documentation (par exemple : Confluence Cloud, Confluence Data Center)
- Intégrations d'alerting (par exemple : Slack, Microsoft Teams, PagerDuty, ...)
- Vérifications de validité
Autoriser les connexions sortantes vers les domaines GitGuardian
Les requêtes vers GitGuardian utilisent des adresses IP qui changent régulièrement. Il est conseillé de mettre en liste blanche les domaines à 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.
