Gérer les accès, rôles et authentification

Page Mon profil

Chaque utilisateur dispose d'une page personnelle qui centralise ses informations, ses préférences et ses facteurs d'authentification.

• Informations personnelles et professionnelles : nom, email, téléphone, job title.
• Préférences : langue de l'interface, fuseau horaire, page de démarrage, thème préféré. La langue est stockée par utilisateur et persiste d'une session à l'autre. Si aucune préférence n'est définie, l'instance bascule sur la locale par défaut configurée dans les Paramètres, puis sur le français. Les langues disponibles dépendent des catalogues de traduction installés sur l'instance.
• Changement de mot de passe avec vérification contre des mots de passe compromis.
• Activation ou désactivation du TOTP.
• Gestion des clés WebAuthn / passkeys.
• Vue des sessions actives, activité récente et tentatives de connexion récentes.

Page Utilisateurs

La surface d'administration va au-delà de la simple création de comptes.

• Création manuelle d'un utilisateur ou émission d'une invitation.
• Édition du profil par un administrateur.
• Modification du rôle et de la politique d'accès.
• Activation ou désactivation du compte.
• Suspension temporaire, raison de suspension et expiration de compte.
• Réinitialisation, changement de mot de passe et révocation de sessions.
• Suppression du compte et gestion des invitations actives.

Rôles, permissions applicatives et scopes

Les rôles système fournis par défaut sont viewer, operator, restore-operator et admin. Les rôles, niveaux et permissions sont pilotés dans src/AppConfig.php par defaultRoles(), getRoles(), permissionDefinitions() et rolePermissions(). Ils peuvent être renommés ou enrichis, mais leur ordre de niveau doit rester strict.

• viewer : accès en lecture seule aux dépôts, jobs, snapshots et statistiques.
• operator : peut déclencher des sauvegardes, gérer les jobs et consulter les logs.
• restore-operator : orienté restauration, avec droits spécifiques sur les opérations de restauration et l'explorateur.
• admin : accès complet à la configuration, aux utilisateurs, aux paramètres et à l'API.

• Les permissions sont résolues au niveau applicatif : dépôts, jobs, restaurations, scheduler, settings, thèmes, users, logs, stats, performance, snapshots.
• Les scopes repo_scope et host_scope limitent ce qu'un utilisateur peut voir ou manipuler.
• Un utilisateur peut donc avoir un rôle élevé tout en restant borné à un périmètre restreint.

Sessions, fingerprint, ré-authentification et révocation

Les sessions actives sont stockées et vérifiées en base, ce qui permet des contrôles plus fins qu'une simple session PHP.

• Limites de durée absolue, d'inactivité et d'avertissement.
• Fingerprint strict reposant sur l'IP et le User-Agent si activé.
• Ré-authentification requise pour certaines actions sensibles.
• Nombre maximum de sessions simultanées par utilisateur.
• Révocation d'une session ciblée, de toutes les autres sessions, ou de toutes les sessions d'un compte.

Le fingerprint de session combine l'adresse IP et le User-Agent du client. Si la comparaison stricte est activée et qu'un de ces deux vecteurs change au cours de la vie de la session, celle-ci est immédiatement invalidée et l'utilisateur est forcé de se reconnecter. Cette protection limite les risques de vol de cookie.

Le paramètre reauth_max_age_seconds contrôle l'âge maximum d'une ré-authentification pour les actions sensibles (rotation de secret, suppression d'un dépôt, désactivation du 2FA, etc.). Passé ce délai, l'utilisateur doit re-saisir son mot de passe ou valider un facteur avant de poursuivre.

TOTP et WebAuthn

Deux mécanismes sont déjà pris en charge et peuvent coexister selon la politique de l'instance : TOTP conforme au RFC 6238 et WebAuthn (passkeys FIDO2).

Sélection du facteur principal et comportement à la connexion

Chaque utilisateur choisit son facteur 2FA principal dans son profil. Les options disponibles sont classic_2fa (TOTP), webauthn (clé matérielle) ou none si la politique de l'instance l'autorise. Lorsque plusieurs facteurs sont inscrits, c'est le facteur principal qui est demandé à la connexion. Les autres facteurs restent disponibles en tant que solution de repli.

Si le facteur principal d'un utilisateur est supprimé (par exemple, tous les codes TOTP effacés), le système bascule en authentification par mot de passe seul et invite l'utilisateur à reconfigurer son 2FA lors de la prochaine connexion.

Ré-authentification de passage à niveau (step-up)

Certaines opérations sensibles exigent une confirmation du facteur principal même lorsque l'utilisateur est déjà connecté. Cette preuve est liée cryptographiquement à l'opération exacte — elle ne peut pas être réutilisée pour une autre action.

• Changement d'adresse e-mail ou de mot de passe.
• Désactivation du 2FA ou suppression d'une passkey.
• Création d'une clé API.
• Élévation ou rétrogradation de rôle d'un utilisateur par un administrateur (protection contre l'escalade de privilèges).

Le paramètre reauth_max_age_seconds définit la durée de validité d'une preuve de ré-authentification. Passé ce délai, une nouvelle confirmation est exigée.

Validation du compteur WebAuthn

À chaque assertion WebAuthn, le système vérifie que le compteur de signatures (sign_count) est strictement supérieur à la valeur use_count stockée en base. Une valeur inférieure ou égale indique une possible clé clonée et déclenche un rejet immédiat. Les flags UP (User Presence) et UV (User Verification) sont exigés sur chaque assertion.

Autres mécanismes de sécurité déjà présents

• Rate limiting des tentatives de login.
• Notifications de connexion, avec option pour ne notifier que les nouvelles IPs.
• Obligation possible du 2FA pour les administrateurs.
• Forced actions pour imposer une mise à jour de profil ou une configuration 2FA.
• Stockage des secrets sensibles via références secret://... plutôt qu'en clair dans les enregistrements applicatifs.
• Audit des actions et rétention configurable des journaux liés à la sécurité.

Le mécanisme des forced actions permet à un administrateur d'imposer à un utilisateur une action bloquante : changement de mot de passe, activation du TOTP, ajout d'une passkey, mise à jour du profil. Tant que l'action en attente n'est pas résolue, l'utilisateur voit un écran bloquant qui l'empêche d'accéder au reste de l'application. Les actions en attente sont stockées en base et résolues automatiquement dès que la condition est remplie.

Journaux secrets et broker HA

La page Journaux secrets complète les logs d'activité classiques avec une vue dédiée au SecretStore et au broker de secrets. Elle est réservée aux profils ayant settings.manage.

• Consultation des accès aux secrets : action, purpose, référence secret://..., succès ou échec.
• État cluster du broker : dernier statut connu, nombre de nœuds sains et lien vers la page Performance pour le diagnostic.
• Événements broker : degraded, node_failed, node_recovered, failover, down, recovered.
• Export CSV des lignes consultées pour audit externe.