Gestion des utilisateurs et rôles
Contrôlez les accès à votre tenant
KaliaOps propose un système RBAC (Role-Based Access Control) complet avec 4 rôles système, 90+ permissions granulaires et des scopes d'ownership pour un contrôle d'accès fin. L'invitation par email simplifie l'onboarding et les fonctionnalités de désactivation/suppression assurent la conformité RGPD.
Système RBAC
KaliaOps utilise un système RBAC (Role-Based Access Control) pour gérer les droits d'accès.
Principe
Chaque utilisateur se voit attribuer un rôle qui définit ses permissions :
- Rôle : Ensemble de permissions (ex: Admin, Manager)
- Permission : Droit d'effectuer une action (ex: assets.view, incidents.create)
- Scope : Périmètre d'application du droit (ex: toutes les entités, mon équipe)
Rôles système
| Rôle | Description | Scope par défaut |
|---|---|---|
| Admin | Accès complet à toutes les fonctionnalités | all |
| Manager | Gestion complète dans son périmètre | organization |
| Tech | Actions opérationnelles CMDB/ITSM | team |
| Viewer | Consultation uniquement | own |
Ces rôles sont protégés et ne peuvent pas être supprimés.
Rôles personnalisés
Vous pouvez créer des rôles personnalisés avec des permissions spécifiques pour répondre à vos besoins.
Inviter un utilisateur
Accédez à la gestion des utilisateurs
Menu Paramètres → Utilisateurs.
Cliquez sur « Inviter »
Ouvrez le formulaire d'invitation.
Renseignez les informations
Complétez :
- Email : Adresse email du nouvel utilisateur
- Rôle : Rôle à attribuer
- Employé : Lier à un employé existant (optionnel)
Envoyez l'invitation
L'utilisateur reçoit un email avec un lien d'activation valide 48h.
Activation par l'utilisateur
L'utilisateur clique sur le lien, définit son mot de passe et accède à KaliaOps.
Gérer les utilisateurs
Liste des utilisateurs
La liste affiche tous les utilisateurs du tenant avec :
- Nom et email
- Rôle attribué
- Statut (actif, invité, désactivé)
- Dernière connexion
Actions disponibles
- Modifier le rôle : Changer les permissions de l'utilisateur
- Réinitialiser le mot de passe : Envoyer un lien de réinitialisation
- Désactiver : Bloquer l'accès temporairement
- Supprimer : Retirer définitivement l'utilisateur
Statuts utilisateur
| Statut | Description |
|---|---|
| Invité | Invitation envoyée, en attente d'activation |
| Actif | Compte activé et fonctionnel |
| Désactivé | Accès bloqué, données conservées |
Rôles et permissions
Créer un rôle personnalisé
- Menu Paramètres → Rôles
- Cliquez sur « Nouveau rôle »
- Nommez le rôle (ex: « Support N1 »)
- Sélectionnez les permissions
- Enregistrez
Catégories de permissions
| Catégorie | Exemples |
|---|---|
| CMDB | assets.view, assets.create, applications.edit, contracts.delete |
| ITSM | incidents.view, incidents.resolve, changes.approve, sla.manage |
| Organisation | organizations.view, teams.edit, employees.create |
| Administration | users.manage, roles.edit, audit_logs.view, api_tokens.create |
Format des permissions
{ressource}.{action}Exemples :
assets.view: Consulter les assetsincidents.create: Créer un incidentcontracts.field.cost: Voir les coûts des contrats
Scopes d'ownership
Les scopes définissent le périmètre d'accès aux données.
Scopes disponibles
| Scope | Accès | Exemple |
|---|---|---|
| all | Toutes les entités du tenant | Admin voit tous les incidents |
| organization | Entités de son organisation | Manager voit les incidents de son département |
| team | Entités de son équipe | Tech voit les incidents assignés à son équipe |
| own | Ses propres entités | Viewer voit uniquement ses incidents |
Application du scope
Le scope s'applique automatiquement :
- Aux listes filtrées selon le périmètre
- Aux actions (modification, suppression)
- Aux exports et rapports
Héritage
Un utilisateur avec scope « organization » voit aussi les entités des équipes de son organisation.
Lien utilisateur-employé
Chaque utilisateur peut être lié à un employé de la base CMDB.
Pourquoi lier ?
- Cohérence : Une seule identité dans le système
- Affectations : L'utilisateur apparaît dans les sélecteurs (chef de projet, etc.)
- Scope automatique : Héritage de l'équipe/organisation de l'employé
Créer le lien
Deux méthodes :
- À l'invitation : Sélectionnez l'employé dans le formulaire
- Après création : Modifiez l'utilisateur et liez un employé
Contrainte d'unicité
Un employé ne peut être lié qu'à un seul utilisateur. Si vous tentez de lier un employé déjà associé, une erreur s'affiche.
Utilisateur sans employé
Un utilisateur sans lien employé :
- Peut se connecter et utiliser KaliaOps
- N'apparaît pas dans les sélecteurs « employé »
- Son scope est déterminé uniquement par son rôle
Conformité RGPD
KaliaOps intègre des fonctionnalités pour la conformité RGPD.
Désactivation
La désactivation bloque l'accès sans supprimer les données :
- Ouvrez la fiche utilisateur
- Cliquez sur « Désactiver »
- L'utilisateur ne peut plus se connecter
- Ses données et son historique sont conservés
La désactivation est réversible.
Suppression
La suppression retire définitivement l'utilisateur :
- Ouvrez la fiche utilisateur
- Cliquez sur « Supprimer »
- Confirmez la suppression
Suppression programmée
Pour la conformité RGPD, vous pouvez programmer une suppression différée :
- L'utilisateur est immédiatement désactivé
- La suppression effective a lieu à la date programmée
- L'utilisateur peut demander l'annulation avant cette date
Données conservées
Après suppression, certaines données sont conservées pour l'audit :
- Logs d'actions (anonymisés)
- Historique des incidents traités
- Références dans les entités créées
- Système RBAC avec 4 rôles prédéfinis (admin, manager, tech, viewer)
- 90+ permissions granulaires couvrant toutes les fonctionnalités
- Scopes d'ownership : all, organization, team, own
- Invitation par email avec rôle et employé pré-assignés
- Conformité RGPD : désactivation et suppression programmée