Paramètres du workspace
Options de collaboration et de partage
Les responsables d'équipe peuvent inviter des utilisateurs au workspace
Cette fonctionnalité est uniquement disponible pour les workspaces avec un plan Business.
Ces paramètres sont conçus pour permettre aux utilisateurs non-managers d'intégrer de nouveaux utilisateurs sur la plateforme, réduisant ainsi la charge administrative pesant sur les 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 vos paramètres de 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 manière similaire, 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 de confiance d'une équipe de jouer un rôle actif dans l'intégration de nouveaux utilisateurs, sans nécessiter d'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 ont 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 toute élévation de privilèges, le niveau d'accès du nouvel utilisateur sera identique à 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èsMember, car nous considérons que le niveau d'accèsManager, hautement privilégié, ne peut être attribué que spécifiquement depuis 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 vos paramètres de 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 consulter 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 reçoivent automatiquement des notifications par e-mail dès 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 ainsi 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 se reposer sur le notificateur configuré au niveau de l'équipe. Pour plus de détails sur la configuration des alertes et des notifications, veuillez consulter la page Alerting and Notifications.
Ce paramètre est ON par défaut. Pour désactiver les notifications par e-mail pour les nouveaux incidents par défaut, à la fois pour les nouveaux et les utilisateurs existants, désactivez-le dans vos paramètres de workspace.
Activer les commentaires et retours pour la permission « Can view »
Les Managers peuvent autoriser les membres d'équipe disposant de la permission d'incident Can view à laisser des commentaires et des retours sur les incidents. Activez ou désactivez cette option dans vos paramètres de workspace pour élargir la collaboration sans accorder de droits d'édition.
Ce paramètre est OFF par défaut.
Cycle de vie des incidents
Régression
Lorsque le paramètre Régression 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-résolveur), l'incident est rouvert, son statut repasse à Triggered, et une notification est émise. La régression s'applique uniquement aux occurrences détectées par 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 lors d'un scan historique.
Lorsqu'il est Off, GitGuardian attache silencieusement la nouvelle occurrence à l'incident résolu existant sans envoyer de notification.
Configurez ce comportement dans vos paramètres généraux du workspace. Ce paramètre est ON par défaut.
Pour plus de contexte sur la manière dont la régression s'inscrit dans le cycle de vie d'un incident, consultez les pages de statuts d'incidents Internal Monitoring et Public Monitoring.
Options de sécurité
Durée de vie maximale des tokens d'accès personnels 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 aux tokens d'accès personnels 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 en utilisant 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 à respecter le nouveau paramètre, à compter du moment de la modification du paramètre.
Par défaut, aucune durée de vie maximale n'est imposée aux tokens d'accès personnels 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, ce qui signifie que son e-mail correspond à l'e-mail du committer de l'occurrence.
Il est important de noter que lorsque la restriction sur la visibilité des patchs git est en vigueur, les métadonnées d'une occurrence restent 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 consulter 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 de chacun, les équipes peuvent maintenir le niveau de confidentialité nécessaire tout en travaillant ensemble à la résolution de 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 l'endpoint 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 l'endpoint API /v1/secrets/{secret_id}. Cet 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 permettre l'accès API aux secrets au niveau du workspace.
- Liste d'autorisation d'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 cet endpoint API, veuillez consulter la documentation 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 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 oblige tous les utilisateurs à se reconnecter une fois le changement appliqué.
Restreindre les scopes des Personal Access Tokens
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. Cela est utile pour les organisations qui exigent que les secrets soient toujours masqués dans le cadre d'une 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 : pour les members et les utilisateurs restricted, le mode confidentialité est imposé à ON et ne peut pas être désactivé. Les managers et le propriétaire conservent le contrôle de leur propre bouton.
- Owner only : pour les managers, members et utilisateurs restricted, le mode confidentialité est imposé à ON et ne peut pas être désactivé. Seul le propriétaire conserve le contrôle.
- No one : le mode confidentialité est définitivement à ON pour tout le monde, y compris le propriétaire.
Lorsque l'application concerne un utilisateur, le bouton du mode confidentialité dans la barre de navigation est désactivé et affiche une infobulle expliquant qu'il est contrôlé par les paramètres du workspace.
