Utilisateurs et rôles

Cette page décrit comment inviter vos collègues, quels rôles leur donner, comment limiter leur périmètre et comment leur accès est protégé.

Inviter un utilisateur

L'invitation demande la permission create:users.

1. Ouvrez « Paramètres », onglet « Utilisateurs & Accès », sous-onglet « Utilisateurs ».
2. Dans la carte « Membres de l'équipe », cliquez sur « Inviter un utilisateur ».
3. Saisissez l'« E-mail » et choisissez le rôle attribué, puis cliquez sur « Envoyer l'invitation ».
4. La personne reçoit un courriel, rédigé en anglais, avec un lien valable 7 jours.
5. Le lien ouvre la page « Rejoindre Ctadel », qui rappelle le rôle attribué. La personne renseigne son « Nom complet », choisit un « Mot de passe » de 12 caractères au minimum et clique sur « Créer mon compte ». Elle peut ensuite se connecter.

Une invitation vers une adresse qui possède déjà un compte est refusée. Envoyer une nouvelle invitation à la même adresse annule la précédente.

La carte « Invitations en attente » liste les invitations non acceptées, avec leur auteur (« invité par … ») et leur échéance (« expire dans 6j ») ou leur état « Expiré ». Deux actions : « Renvoyer l'invitation » (nouveau lien, de nouveau 7 jours ; permission create:users) et « Annuler l'invitation » (permission delete:users).

Rôles et permissions

Un rôle est un ensemble de permissions et un périmètre. Trois rôles système existent à la création de l'instance ; ils ne peuvent être ni renommés ni supprimés, mais leurs permissions se modifient (« Rôle système : vous pouvez modifier ses permissions mais pas le renommer »).

Rôle	Périmètre	Permissions
Global Admin	Tous les projets	Toutes
Global SecurityEngineer	Tous les projets	Toute la lecture ; modification des constats et des ressources ; création et modification de règles ; lancement de parcours ; requêtes enregistrées ; commentaires ; règles d'ignorance. Ni utilisateurs, ni rôles, ni paramètres, ni SSO.
Global Viewer	Tous les projets	Lecture seule

Le premier compte administrateur de l'instance porte « Global Admin ». Une personne qui détient plusieurs rôles choisit celui qu'elle exerce depuis le menu utilisateur, entrée « Changer de rôle ».

Créer un rôle

Depuis le sous-onglet « Rôles » (permission create:roles ; read:roles pour consulter), le bouton « Créer un rôle » ouvre un formulaire :

• « Nom » et « Description ».
• « Périmètre projet » : « Tous les projets (global) » ou une sélection de projets.
• « Dossiers » : un ou plusieurs dossiers ; le rôle donne alors accès à tous les comptes du sous-arbre, y compris ceux ajoutés plus tard. Vide, seul le périmètre projet s'applique.
• « Permissions », regroupées par domaine : « Ressources », « Détections », « Règles », « Scans », « Utilisateurs », « Rôles », « Paramètres », « Graphe », « Requêtes enregistrées », avec les actions « Lire », « Créer », « Modifier », « Supprimer ». Les autres permissions (commentaires, règles d'ignorance, lecture par type de constat, SSO) s'affichent sous leur clé brute, par exemple read:findings:cspm ou manage:sso.
• Les boutons « Copier … » reprennent les permissions d'un rôle système comme point de départ.

La permission read:issues donne la lecture de tous les types de constats. Pour un rôle qui ne doit voir qu'une partie des constats, cochez à la place les permissions read:findings:<type> voulues (CSPM, vulnérabilités, combinaisons toxiques, DSPM, secrets, IaC, KSPM, HCR, CDR).

Un rôle ne se supprime que s'il n'est attribué à personne ; réattribuez d'abord les utilisateurs.

Restreindre un utilisateur à des projets

Le périmètre est porté par le rôle, pas par l'utilisateur. Pour limiter une personne :

1. Créez un rôle dont le « Périmètre projet » ou les « Dossiers » couvrent seulement ce qu'elle doit voir.
2. Dans « Membres de l'équipe », ouvrez « Modifier les attributions » sur son compte.
3. Sous « Attributions de rôles », ajoutez ou retirez des rôles avec « Ajouter une attribution » ; chaque ligne affiche son périmètre : « Global », « Limité à un dossier » ou « N projets ».
4. Cliquez sur « Enregistrer les attributions ».

Une personne qui ne détient que des rôles limités ne voit que ces projets ; le sélecteur de projet en haut de l'application se limite à eux. Les permissions sont relues à chaque requête : un rôle retiré prend effet sans reconnexion. Retirer le rôle « Global Admin » à la dernière personne qui le détient est refusé.

Les attributions créées par l'authentification unique sont marquées comme gérées par le SSO et réappliquées à chaque connexion ; voir Authentification unique.

Supprimer un compte

Il n'existe pas de désactivation temporaire. Deux options :

• Retirer tous ses rôles : le compte reste, affiché avec « Aucun rôle », et ne peut plus rien lire.
• « Supprimer » le compte (permission delete:users), après confirmation : « Êtes-vous sûr de vouloir supprimer cet utilisateur ? Cette action est irréversible. » Le dernier « Global Admin » ne peut pas être supprimé.

Code de connexion

La connexion par mot de passe se fait en deux étapes sur /login.

1. « E-mail » et « Mot de passe ». Le serveur vérifie le couple sans ouvrir de session.
2. Un code à 6 chiffres est envoyé à l'adresse du compte (« Un code à 6 chiffres a été envoyé à … »). La personne le saisit dans « Code de vérification ». La session n'est créée qu'après ce contrôle.

Le code est valable 10 minutes ; au cinquième essai faux, il est annulé et il faut en demander un autre avec « Renvoyer le code ». L'envoi est limité à 5 codes par 5 minutes, par adresse et par adresse IP ; chaque nouvel envoi annule les codes précédents. Ce code ne se désactive pas par utilisateur. Les personnes qui se connectent par SSO ne passent pas par cette étape : c'est leur fournisseur d'identité qui les authentifie.

Politique de mot de passe

• 12 caractères au minimum, à la création du compte comme à la réinitialisation. Aucune autre règle de composition.
• Les mots de passe sont stockés hachés (bcrypt).
• « Mot de passe oublié ? » sur /login envoie un lien valable 24 heures, si l'adresse correspond à un compte à mot de passe. La réponse est la même dans tous les cas. Limite : 5 demandes par 15 minutes par adresse IP, 5 par heure par adresse.
• Un nouveau mot de passe invalide les sessions ouvertes avec l'ancien.

Durée de session

La session est un jeton signé, déposé dans un cookie httpOnly. Sa durée est fixée par Ctadel à la configuration de votre instance : 12 heures par défaut, entre 1 et 168 heures sur demande. Elle ne se règle pas dans l'interface. À l'expiration, la personne se reconnecte avec son mot de passe et un nouveau code.

À chaque requête, les rôles de la session sont relus : un rôle retiré prend effet sans reconnexion.

Limites

• Pas de suspension temporaire d'un compte : retrait des rôles ou suppression.
• Le second facteur est un code envoyé par courriel. Pas d'application d'authentification (TOTP), pas de clé matérielle, pas de désactivation par utilisateur.
• La politique de mot de passe se limite à la longueur. Pas d'expiration, pas d'historique, pas de changement de mot de passe depuis l'application une fois connecté : le seul chemin est « Mot de passe oublié ? ».
• Le courriel d'invitation part en anglais quelle que soit la langue de l'instance ; les courriels suivants (bienvenue, code, réinitialisation) suivent la langue de l'utilisateur.
• Pas de verrouillage de compte après des échecs répétés ; la protection repose sur les limites de débit par adresse IP et par adresse.
• La connexion par Google ou GitHub, mentionnée dans le texte de la carte « Exiger la connexion SSO », n'est pas activée sur une instance client.
• La permission read:findings:aispm apparaît dans le formulaire de rôle mais n'a pas d'effet : les constats AI-SPM ne se lisent qu'avec read:issues.
• Pas de provisionnement SCIM ; les comptes SSO sont créés à la première connexion (voir Authentification unique).