Paramètres du workspace
Options de collaboration et de partage
Les responsables d'équipe peuvent inviter des utilisateurs du workspace
Cette fonctionnalité est uniquement disponible pour les workspaces avec un plan Business.
Ces paramètres sont conçus pour donner aux utilisateurs non-managers la possibilité d'intégrer de nouveaux utilisateurs sur la plateforme, réduisant ainsi la charge administrative des managers du workspace.
L'activation de ce paramètre permet aux utilisateurs ayant le niveau d'accès Member d'inviter des personnes dans les équipes qu'ils dirigent. Les responsables d'équipe ne peuvent inviter de nouveaux utilisateurs qu'en les ajoutant à leurs équipes et ne peuvent pas inviter de nouveaux utilisateurs au workspace via la page Settings > Members.
Les utilisateurs nouvellement ajoutés se verront attribuer le niveau d'accès Member. Lors de leur inscription, ils seront automatiquement ajoutés à l'équipe depuis laquelle ils ont été invités.
Ce paramètre est ON par défaut. Désactivez-le dans les paramètres de votre workspace si vous souhaitez que le privilège d'ajouter de nouveaux utilisateurs à votre workspace reste exclusif aux Managers.
Les permissions d'incident « Full access » permettent d'inviter des utilisateurs
Cette fonctionnalité est uniquement disponible pour les workspaces avec un plan Business.
De même, ce paramètre permet aux utilisateurs non-managers qui appartiennent à une équipe et disposent de la permission d'incident Full access d'inviter de nouveaux utilisateurs au workspace. L'objectif est de permettre aux membres d'équipe de confiance de jouer un rôle actif dans l'intégration de nouveaux utilisateurs, sans nécessiter un accès de niveau manager. Les utilisateurs disposant de la permission d'incident Full access ne peuvent inviter de nouveaux utilisateurs qu'en leur accordant l'accès à l'incident sur lequel ils disposent de la permission Full access, et ne peuvent pas inviter de nouveaux utilisateurs au workspace via la page Settings > Members.
Lors de l'inscription :
- l'utilisateur nouvellement ajouté n'aura accès qu'à l'incident depuis lequel il a été invité
- pour éviter l'escalade de privilèges, le niveau d'accès du nouvel utilisateur sera le même que celui de la personne qui lui a accordé l'accès à l'incident :
- Si l'accès a été accordé par un utilisateur
Restricted, le nouvel utilisateur aura le niveau d'accèsRestricted. - Si l'accès a été accordé par un utilisateur
Member, le nouvel utilisateur aura le niveau d'accèsMember. - Si l'accès a été accordé par un utilisateur
Manager, le nouvel utilisateur aura le niveau d'accèsMembercar nous considérons que le niveau d'accès hautement privilégiéManagerne peut être attribué que spécifiquement sur la page Settings > Members.
- Si l'accès a été accordé par un utilisateur
Ce paramètre est ON par défaut. Désactivez-le dans les paramètres de votre workspace si vous souhaitez que le privilège d'ajouter de nouveaux utilisateurs à votre workspace reste exclusif aux Managers.
Partage public
Dans les paramètres du workspace, les Managers peuvent activer ou désactiver le partage public sur l'ensemble du workspace. L'activation du partage public permet aux utilisateurs d'accéder à un incident sans avoir besoin d'être enregistrés.
Pour plus de détails sur le partage public, veuillez vous référer à notre section Collaboration et partage.
Le partage public est disponible dans tous les plans :
- dans le plan
Free, les Managers et les Members peuvent effectuer un partage public. - dans le plan
Business, seuls les utilisateurs disposant de la permission d'incidentFull_accesspeuvent effectuer un partage public.
Le partage public est OFF par défaut.
Par défaut, les utilisateurs sont notifiés par e-mail lorsqu'un nouvel incident est détecté
Cette fonctionnalité est uniquement disponible pour les workspaces avec un plan Business.
Lorsque ce paramètre est activé, les utilisateurs recevront automatiquement des notifications par e-mail chaque fois qu'un nouvel incident est détecté dans le périmètre d'équipe d'un membre. Cette notification peut être modifiée par les utilisateurs dans leurs paramètres personnels sous Secrets detection > Incident alerting, remplaçant le paramètre du workspace si nécessaire.
Les Managers du workspace peuvent ajuster le paramètre de notification par défaut pour tous les utilisateurs via les paramètres du workspace. Si les notifications par e-mail pour les nouveaux incidents sont désactivées, les utilisateurs doivent s'appuyer sur le notifier configuré au niveau de l'équipe. Pour plus de détails sur la configuration des alertes et des notifications, veuillez vous référer à la page Alertes et notifications.
Ce paramètre est ON par défaut. Pour désactiver par défaut les notifications par e-mail pour les nouveaux incidents, à la fois pour les nouveaux et les utilisateurs existants, désactivez-le dans les paramètres de votre workspace.
Activer les commentaires et les retours pour la permission « Can view »
Les Managers peuvent autoriser les membres d'équipe disposant de la permission d'incident Can view à fournir des commentaires et des retours sur les incidents. Activez ou désactivez cette option dans les paramètres de votre workspace pour élargir la collaboration sans accorder de droits d'édition.
Ce paramètre est OFF par défaut.
Périmètre d'équipe
Cette fonctionnalité est uniquement disponible pour les workspaces avec un plan Business.
Dans les paramètres du workspace, les Managers peuvent retirer automatiquement des sources de tous les périmètres d'équipe, en fonction de leur statut. Lorsqu'une source quitte un périmètre d'équipe, les membres de cette équipe perdent l'accès à la source et à ses incidents. Les Managers conservent l'accès à ces sources et à leurs incidents.
| Paramètre | GitGuardian retire la source lorsque | Par défaut |
|---|---|---|
| Sources supprimées | la source est supprimée chez le fournisseur | OFF |
| Sources archivées | la source est archivée chez le fournisseur. S'applique uniquement aux types de source ayant un statut archivé, tels que les dépôts GitHub ou GitLab | OFF |
| Sources non surveillées | la source n'est pas surveillée. Désactivez-le pour permettre aux équipes de conserver l'accès aux sources non surveillées et à leurs incidents existants | ON |
Cycle de vie des incidents
Régression
Lorsque le paramètre Regression est activé et que GitGuardian détecte une nouvelle occurrence sur un incident précédemment marqué comme résolu (manuellement ou par l'auto-resolver), l'incident est rouvert, son statut repasse à Triggered, et une notification est émise. La régression ne s'applique qu'aux occurrences détectées via le scan en temps réel des sources connectées : un incident résolu ne sera pas rouvert si une nouvelle occurrence est découverte par un scan historique.
Lorsqu'il est Off, GitGuardian rattache silencieusement la nouvelle occurrence à l'incident résolu existant sans envoyer de notification.
Configurez ce comportement dans les paramètres General de votre workspace. Ce paramètre est ON par défaut.
Pour plus de contexte sur la façon dont la régression s'inscrit dans le cycle de vie d'un incident, consultez les pages de statut d'incident Internal Monitoring et Public Monitoring.
Options de sécurité
Durée de vie maximale des tokens d'accès personnels d'API
Cette fonctionnalité est uniquement disponible pour les workspaces avec un plan Business.
Dans les paramètres du workspace, les Managers peuvent imposer une durée de vie maximale pour les tokens d'accès personnels d'API créés au sein de leur workspace. Cela s'applique que la création se fasse via la page API > Personal access tokens ou via ggshield à l'aide de la commande ggshield auth login.
Si des tokens d'accès personnels existants dépassent la nouvelle durée de vie maximale au moment de la modification du paramètre, GitGuardian forcera leur durée de vie à correspondre au nouveau paramètre, à compter du moment de la modification du paramètre.
Par défaut, il n'y a pas de durée de vie maximale imposée pour les tokens d'accès personnels d'API.
Restreindre la visibilité des patchs git
Cette fonctionnalité est uniquement disponible pour les workspaces avec un plan Business.
Dans les paramètres du workspace, les Managers peuvent activer la restriction de la visibilité des patchs git.
Lorsque la restriction est activée, le patch git d'une occurrence sera visible pour un utilisateur si l'une des conditions suivantes est remplie :
- L'utilisateur est membre d'une équipe qui inclut le dépôt où l'occurrence a eu lieu. Il convient de noter que, puisque les Managers du workspace font automatiquement partie de l'équipe « All-incidents », ils auront toujours accès à tous les patchs git.
- L'utilisateur est directement impliqué dans l'occurrence, c'est-à-dire que son e-mail correspond à l'e-mail du committer de l'occurrence.
Il est important de noter que, tant que la restriction sur la visibilité des patchs git est en vigueur, les métadonnées d'une occurrence resteront visibles pour les utilisateurs. Seul le patch git de l'occurrence sera impacté par la restriction.
Cela signifie qu'il peut y avoir des cas où un utilisateur a accès à un incident de secret qui contient plusieurs occurrences. L'utilisateur pourra voir les métadonnées de toutes les occurrences, mais seul un sous-ensemble d'entre elles aura des patchs git visibles.
Cette distinction est essentielle pour assurer une remédiation efficace lorsque plusieurs équipes sont impliquées et que la collaboration est nécessaire. En restreignant l'accès au code (patch git) des occurrences des autres, les équipes peuvent maintenir le niveau de confidentialité nécessaire tout en travaillant ensemble pour résoudre l'incident.
Lorsque la restriction sur la visibilité des patchs git est activée, les patchs git des occurrences sont masqués sur la page de partage public d'un incident.
Activer le endpoint d'API pour récupérer les secrets détectés en clair pour chaque incident
Cette fonctionnalité est uniquement disponible pour les workspaces avec un plan Business.
Dans les paramètres du workspace, les Managers peuvent contrôler l'accès aux valeurs des secrets via le endpoint d'API /v1/secrets/{secret_id}. Ce endpoint permet aux utilisateurs de récupérer en toute sécurité les valeurs des secrets directement via l'API, permettant une automatisation de sécurité renforcée et une intégration avec les workflows de sécurité existants.
L'API d'accès aux secrets fournit plusieurs couches de contrôles de sécurité qui doivent être correctement configurées :
- Permissions du Personal Access Token (PAT) : les utilisateurs doivent disposer des permissions PAT appropriées (
secret:read) pour accéder aux valeurs des secrets. Les SAT ne sont pas autorisés. - Paramètres du workspace : les Managers doivent d'abord activer le paramètre pour autoriser l'accès API aux secrets au niveau du workspace.
- Liste d'autorisations IP : les propriétaires du workspace doivent configurer des contrôles d'accès basés sur l'IP pour autoriser l'accès depuis des sources autorisées.
- Contexte complet du secret : une fois correctement configurée, l'API renvoie à la fois la valeur du secret et les informations du détecteur pour une remédiation complète.
Pour plus d'informations sur l'utilisation de ce endpoint d'API, veuillez vous référer à la documentation de l'API.
Durée de session
Dans les paramètres du workspace, les Managers peuvent personnaliser la durée d'une session du dashboard avant que les utilisateurs ne soient automatiquement déconnectés.
Choisissez parmi l'une des durées prédéfinies ou sélectionnez Custom pour spécifier une durée de session en minutes. Laissez le champ de durée personnalisée vide pour réinitialiser aux valeurs par défaut de GitGuardian.
La modification de la durée de session nécessite que tous les utilisateurs se reconnectent une fois le changement appliqué.
Restreindre les scopes des Personal Access Token
Cette fonctionnalité est uniquement disponible pour les workspaces avec un plan Business.
Dans les paramètres du workspace, les Managers peuvent restreindre les scopes disponibles pour les Members lors de la création de Personal Access Tokens (PATs). Cela permet aux Managers d'appliquer le principe du moindre privilège en limitant ce que les Members peuvent faire avec leurs tokens.
Cette restriction ne s'applique pas aux Managers.
Par défaut, il n'y a aucune restriction sur les scopes des PAT pour les Members.
Application du mode confidentialité
Cette fonctionnalité est uniquement disponible pour les workspaces avec un plan Business.
Dans les paramètres du workspace, le propriétaire du workspace peut imposer le mode confidentialité à certains ou à tous les utilisateurs, les empêchant de le désactiver. Ceci est utile pour les organisations qui exigent que les secrets soient toujours obscurcis en tant que politique de sécurité.
Ce paramètre n'est modifiable que par le propriétaire du workspace. Les Managers et les membres peuvent le voir mais ne peuvent pas le modifier.
Quatre niveaux d'application sont disponibles :
- All users (par défaut) : aucune application — chaque utilisateur contrôle son propre bouton de mode confidentialité.
- Managers and owner only : les membres et les utilisateurs restreints ont le mode confidentialité imposé sur ON et ne peuvent pas le désactiver. Les Managers et le propriétaire conservent le contrôle de leur propre bouton.
- Owner only : les managers, les membres et les utilisateurs restreints ont le mode confidentialité imposé sur ON et ne peuvent pas le désactiver. Seul le propriétaire conserve le contrôle.
- No one : le mode confidentialité est imposé en permanence sur ON pour tout le monde, y compris le propriétaire.
Lorsque l'application s'applique à un utilisateur, le bouton de mode confidentialité dans la barre de navigation est désactivé et affiche une info-bulle expliquant qu'il est contrôlé par les paramètres du workspace.
