Paramètres du workspace
Options de collaboration et de partage
Les leaders d'équipe peuvent inviter des utilisateurs dans le workspace
Cette fonctionnalité n'est disponible que pour les workspaces avec un plan Business.
Ces paramètres sont conçus pour donner aux utilisateurs non-managers la capacité d'onboarder de nouveaux utilisateurs sur la plateforme, réduisant la charge administrative sur les managers du workspace.
Activer ce paramètre permet aux utilisateurs avec le niveau d'accès Member d'inviter des personnes aux équipes qu'ils dirigent. Les leaders 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 voulez 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é n'est disponible que pour les workspaces avec un plan Business.
De même, ce paramètre permet aux utilisateurs non-managers qui appartiennent à une équipe et ont 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'onboarding de nouveaux utilisateurs, sans nécessiter d'accès au niveau manager. Les utilisateurs avec 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 empêcher l'escalade de privilège, le niveau d'accès du nouvel utilisateur sera le même que celui de la personne qui leur a accordé l'accès à l'incident :
- Si l'accès est accordé par un utilisateur
Restricted, le nouvel utilisateur aura le niveau d'accèsRestricted. - Si l'accès est accordé par un utilisateur
Member, le nouvel utilisateur aura le niveau d'accèsMember. - Si l'accès est accordé par un utilisateur
Manager, le nouvel utilisateur aura le niveau d'accèsMembercar nous considérons que le niveau d'accèsManagerhautement privilégié ne peut être donné spécifiquement que sur la page Settings > Members.
- Si l'accès est accordé par un utilisateur
Ce paramètre est ON par défaut. Désactivez-le dans vos paramètres de workspace si vous voulez que le privilège d'ajouter de nouveaux utilisateurs à votre workspace reste exclusif aux Managers.
Partage public
Dans les paramètres de workspace, les Managers peuvent activer ou désactiver le partage public sur tout le workspace. Activer le 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, voir notre section Collaboration et partage.
Le partage public est disponible dans tous les plans :
- dans le plan
Free, à la fois les Managers et les Members peuvent effectuer le partage public. - dans le plan
Business, seuls les utilisateurs avec la permission d'incidentFull_accesspeuvent effectuer le partage public.
Le partage public est OFF par défaut.
Par défaut, les utilisateurs sont notifiés par email lorsqu'un nouvel incident est détecté
Cette fonctionnalité n'est disponible que pour les workspaces avec un plan Business.
Lorsque ce paramètre est activé, les utilisateurs recevront automatiquement des notifications email 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, outrepassant 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 email pour les nouveaux incidents sont désactivées, les utilisateurs devraient s'appuyer sur le notifier configuré au niveau équipe. Pour plus de détails sur la configuration de l'alerting et des notifications, voir la page Alerting et Notifications.
Ce paramètre est ON par défaut. Pour désactiver les notifications email pour les nouveaux incidents par défaut pour les utilisateurs nouveaux et existants, désactivez-le dans vos paramètres de workspace.
Activer les commentaires et feedback pour la permission « Can view »
Les Managers peuvent permettre aux membres d'équipe avec la permission d'incident Can view de fournir des commentaires et feedback 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.
Options de sécurité
Durée de vie maximale des personal access tokens API
Cette fonctionnalité n'est disponible que pour les workspaces avec un plan Business.
Dans les paramètres de workspace, les Managers peuvent imposer une durée de vie maximale pour les personal access tokens 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 les personal access tokens 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, à partir du moment de la modification.
Par défaut, il n'y a pas de durée de vie maximale imposée pour les personal access tokens API.
Restreindre la visibilité des git patches
Cette fonctionnalité n'est disponible que pour les workspaces avec un plan Business.
Dans les paramètres de workspace, les Managers peuvent activer la restriction pour la visibilité des git patches.
Lorsque la restriction est activée, le git patch d'une occurrence sera visible à 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 git patches.
- L'utilisateur est directement impliqué dans l'occurrence, ce qui signifie que son email correspond à l'email du committer de l'occurrence.
Il est important de noter que pendant que la restriction sur la visibilité des git patches est en vigueur, les métadonnées d'une occurrence resteront visibles aux utilisateurs. Seul le git patch 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 contenant plusieurs occurrences. L'utilisateur pourra voir les métadonnées de toutes les occurrences, mais seul un sous-ensemble d'entre elles aura des git patches visibles.
Cette distinction est critique 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 (git patch) des occurrences des autres, les équipes peuvent maintenir le niveau nécessaire de confidentialité tout en travaillant ensemble pour résoudre l'incident.
Lorsque la restriction sur la visibilité des git patches est activée, les git patches 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é n'est disponible que pour les workspaces avec un plan Business.
Dans les paramètres de workspace, les Managers peuvent contrôler l'accès aux valeurs de secret via l'endpoint API /v1/secrets/{secret_id}. Cet endpoint permet aux utilisateurs de récupérer en toute sécurité les valeurs de secret directement via l'API, permettant une automatisation de sécurité amélioré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 Personal Access Token (PAT) : les utilisateurs doivent avoir les permissions PAT appropriées (
secret:read) pour accéder aux valeurs de secret. Les SAT ne sont pas autorisés. - Paramètres du workspace : les Managers doivent d'abord activer le paramètre pour activer l'accès API aux secrets au niveau workspace.
- IP allowlisting : les owners du workspace doivent configurer les contrôles d'accès basés sur IP pour autoriser l'accès depuis des sources autorisées.
- Contexte secret complet : une fois correctement configurée, l'API retourne à 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, voir la documentation API.
Durée de session
Dans les paramètres de workspace, les Managers peuvent personnaliser la durée d'une session du tableau de bord avant que les utilisateurs ne soient automatiquement déconnectés.
Choisissez parmi les 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.
Changer la durée de session nécessite que tous les utilisateurs se reconnectent une fois le changement appliqué.
Restreindre les scopes des Personal Access Tokens
Cette fonctionnalité n'est disponible que pour les workspaces avec un plan Business.
Dans les paramètres de workspace, les Managers peuvent restreindre les scopes disponibles aux Members lors de la création de Personal Access Tokens (PATs). Cela permet aux Managers d'imposer 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 pas de restriction sur les scopes PAT pour les Members.
Imposition du privacy mode
Cette fonctionnalité n'est disponible que pour les workspaces avec un plan Business.
Dans les paramètres de workspace, le owner du workspace peut imposer le privacy mode pour certains ou tous les utilisateurs, les empêchant de le désactiver. C'est utile pour les organisations qui requièrent que les secrets soient toujours obfusqués comme politique de sécurité.
Ce paramètre n'est éditable que par le owner du workspace. Les managers et members peuvent le voir mais ne peuvent pas le changer.
Quatre niveaux d'imposition sont disponibles :
- All users (par défaut) : aucune imposition — chaque utilisateur contrôle son propre toggle de privacy mode.
- Managers and owner only : les members et utilisateurs restricted ont le privacy mode imposé sur ON et ne peuvent pas le désactiver. Les managers et le owner gardent le contrôle de leur propre toggle.
- Owner only : les managers, members et utilisateurs restricted ont le privacy mode imposé sur ON et ne peuvent pas le désactiver. Seul le owner garde le contrôle.
- No one : le privacy mode est imposé sur ON pour tout le monde, y compris le owner.
Lorsque l'imposition s'applique à un utilisateur, le toggle privacy mode dans la barre de navigation est désactivé et affiche un tooltip expliquant qu'il est contrôlé par les paramètres du workspace.
