3 Groupes d'utilisateur
Vue d'ensemble
Les groupes d'utilisateurs permettent de regrouper les utilisateurs à la fois à des fins organisationnelles et pour attribuer des permissions aux données. Les permissions de consultation et de configuration des données des groupes d'hôtes et des groupes de modèles sont attribuées aux groupes d'utilisateurs, et non aux utilisateurs individuels.
Il peut souvent être judicieux de séparer les informations disponibles pour un groupe d'utilisateurs de celles disponibles pour un autre. Cela peut être réalisé en regroupant les utilisateurs, puis en attribuant des permissions différentes aux groupes d'hôtes et de modèles.
Un utilisateur peut appartenir à n'importe quel nombre de groupes.
Configuration
Pour configurer un groupe d'utilisateurs :
- Accédez à Users → User groups
- Cliquez sur Create user group (ou sur le nom du groupe pour modifier un groupe existant)
- Modifiez les attributs du groupe dans le formulaire
L'onglet User group contient les attributs généraux du groupe :
Tous les champs obligatoires sont marqués d'un astérisque rouge.
| Parameter | Description |
|---|---|
| Group name | Nom unique du groupe. |
| Users | Pour ajouter des utilisateurs au groupe, commencez à saisir le nom d'un utilisateur existant. Lorsque la liste déroulante avec les noms d'utilisateurs correspondants apparaît, faites défiler vers le bas pour sélectionner. Vous pouvez également cliquer sur le bouton Select pour sélectionner des utilisateurs dans une fenêtre contextuelle. |
| Frontend access | Mode d'authentification des utilisateurs du groupe. System default - utiliser la méthode d'authentification par défaut (définie globalement) Internal - utiliser l'authentification interne de Zabbix (même si l'authentification LDAP est utilisée globalement). Ignoré si l'authentification HTTP est la valeur par défaut globale. LDAP - utiliser l'authentification LDAP (même si l'authentification interne est utilisée globalement). Ignoré si l'authentification HTTP est la valeur par défaut globale. Disabled - l'accès à l'interface Zabbix est interdit pour ce groupe |
| LDAP server | Sélectionnez le serveur LDAP à utiliser pour authentifier l'utilisateur. Ce champ est activé uniquement si Frontend access est défini sur LDAP ou System default. |
| Multi-factor authentication | Sélectionnez la méthode d'authentification multifacteur à utiliser pour authentifier l'utilisateur : Default - utiliser la méthode définie comme valeur par défaut dans la configuration MFA ; cette option est sélectionnée par défaut pour les nouveaux groupes d'utilisateurs si MFA est activée ; <Method name> - utiliser la méthode sélectionnée (par exemple, "Zabbix TOTP") ; Disabled - MFA est désactivée pour ce groupe ; cette option est sélectionnée par défaut pour les nouveaux groupes d'utilisateurs si MFA est désactivée. Notez que si un utilisateur appartient à plusieurs groupes d'utilisateurs avec MFA activée (ou si au moins un groupe a MFA activée), les règles d'authentification suivantes s'appliquent : si un groupe utilise la méthode MFA "Default", elle authentifiera l'utilisateur ; sinon, la première méthode (triée par ordre alphabétique) sera utilisée pour l'authentification. |
| Enabled | État du groupe d'utilisateurs et des membres du groupe. Checked - le groupe d'utilisateurs et les utilisateurs sont activés Unchecked - le groupe d'utilisateurs et les utilisateurs sont désactivés |
| Debug mode | Cochez cette case pour activer le mode de débogage pour les utilisateurs. |
L'onglet Template permissions permet de spécifier l'accès du groupe d'utilisateurs aux données des groupes de modèles (et donc des modèles) :
L'onglet Host permissions permet de spécifier l'accès du groupe d'utilisateurs aux données des groupes d'hôtes (et donc des hôtes) :
Cliquez sur 
pour choisir les groupes de modèles/hôtes
(qu'il s'agisse d'un groupe parent ou imbriqué) et leur attribuer des permissions. Commencez à saisir le nom du groupe
(une liste déroulante des groupes correspondants apparaîtra) ou cliquez sur Select pour ouvrir une fenêtre contextuelle listant tous les groupes.
Utilisez ensuite les boutons d'option pour attribuer des permissions aux groupes choisis. Les permissions possibles sont les suivantes :
- Read-write - accès en lecture et écriture à un groupe ;
- Read - accès en lecture seule à un groupe ;
- Deny - accès à un groupe refusé.
Si le même groupe de modèles/hôtes est ajouté sur plusieurs lignes avec des permissions différentes, la permission la plus restrictive sera appliquée.
Notez qu'un utilisateur Super admin peut imposer aux groupes imbriqués d'avoir le même niveau de permissions que le groupe parent ; cela peut être fait dans le formulaire de configuration du groupe hôte/modèle.
Les onglets Template permissions et Host permissions prennent en charge le même ensemble de paramètres.
Les permissions actuelles sur les groupes sont affichées dans le bloc Permissions, et elles peuvent être modifiées ou supprimées.
Si un groupe d'utilisateurs dispose des permissions Read-write sur un hôte et de Deny ou d'aucune permission sur un modèle lié à cet hôte, les utilisateurs de ce groupe ne pourront pas modifier les éléments liés à un modèle sur l'hôte, et le nom du modèle sera affiché comme Inaccessible template.
L'onglet Problem tag filter permet de définir des permissions basées sur des tags pour les groupes d'utilisateurs afin de voir les problèmes filtrés par nom et valeur de tag :
Cliquez sur pour choisir les groupes d'hôtes.
Pour sélectionner un groupe d'hôtes auquel appliquer un filtre de tag, cliquez sur Select pour obtenir
la liste complète des groupes d'hôtes existants ou commencez à saisir le nom d'un groupe d'hôtes pour afficher
une liste déroulante des groupes correspondants. Seuls les groupes d'hôtes seront affichés, car le filtre de tag des problèmes ne peut pas être appliqué aux groupes de modèles.
Il est ensuite possible de passer de All tags à Tag list afin de définir des tags particuliers et leurs valeurs pour le filtrage.
Les noms de tags sans valeur peuvent être ajoutés, mais pas les valeurs sans nom. Seuls les trois premiers tags (avec leurs valeurs, le cas échéant)
sont affichés dans le bloc Permissions ; s'il y en a davantage, ils peuvent être consultés en cliquant sur l'icône 
ou en la survolant.
Le filtre de tag permet de séparer l'accès au groupe d'hôtes de la possibilité de voir les problèmes.
Par exemple, si un administrateur de base de données doit voir uniquement les problèmes de base de données "MySQL", il faut d'abord créer un groupe d'utilisateurs pour les administrateurs de base de données, puis spécifier le nom de tag "target" et la valeur "mysql".
Si le nom de tag "target" est spécifié et que le champ de valeur est laissé vide, le groupe d'utilisateurs verra tous les problèmes avec le nom de tag "target" pour le groupe d'hôtes sélectionné. Si All tags est sélectionné, le groupe d'utilisateurs verra tous les problèmes pour le groupe d'hôtes spécifié.
Assurez-vous que le nom du tag et la valeur du tag sont correctement spécifiés, sinon le groupe d'utilisateurs ne verra aucun problème.
Examinons un exemple lorsqu'un utilisateur est membre de plusieurs groupes d'utilisateurs sélectionnés. Dans ce cas, le filtrage utilisera une condition OR pour les tags.
| User group A | User group B | Visible result for a user (member) of both groups | ||||
| Tag filter | ||||||
| Host group | Tag name | Tag value | Host group | Tag name | Tag value | |
| Databases | target | mysql | Databases | target | oracle | target:mysql or target:oracle problems visible |
| Databases | set to: All tags | Databases | target | oracle | All problems visible | |
| Not configured in the Problem tag filter | Databases | target | oracle | target:oracle problems visible | ||
L'ajout d'un filtre (par exemple, tous les tags dans un certain groupe d'hôtes "Databases") empêche de voir les problèmes des autres groupes d'hôtes.
Accès depuis plusieurs groupes d'utilisateurs
Un utilisateur peut appartenir à un nombre quelconque de groupes d'utilisateurs. Ces groupes peuvent avoir des autorisations d'accès différentes aux hôtes ou aux modèles.
Il est donc important de savoir à quelles entités un utilisateur non privilégié pourra accéder au final. Dans l'exemple suivant, examinez comment l'accès à l'hôte X (dans le groupe d'hôtes 1) sera प्रभावितé dans différentes situations pour un utilisateur qui appartient aux groupes d'utilisateurs A et B.
- Si le groupe A dispose uniquement d'un accès Lecture au groupe d'hôtes 1, mais que le groupe B dispose d'un accès Lecture-écriture au groupe d'hôtes 1, l'utilisateur obtiendra un accès Lecture-écriture à 'X'.
Les autorisations "Lecture-écriture" ont priorité sur les autorisations "Lecture".
- Dans le même scénario que ci-dessus, si 'X' appartient également simultanément au groupe d'hôtes 2 qui est refusé au groupe A ou B, l'accès à 'X' sera indisponible, malgré un accès Lecture-écriture au groupe d'hôtes 1.
- Si le groupe A n'a aucune autorisation définie et que le groupe B dispose d'un accès Lecture-écriture au groupe d'hôtes 1, l'utilisateur obtiendra un accès Lecture-écriture à 'X'.
- Si le groupe A dispose d'un accès Refuser au groupe d'hôtes 1 et que le groupe B dispose d'un accès Lecture-écriture au groupe d'hôtes 1, l'accès de l'utilisateur à 'X' sera refusé.
Autres détails
- Un utilisateur de niveau Admin avec un accès Lecture-écriture à un hôte ne pourra pas lier/délier des modèles s'il n'a pas accès au groupe de modèles auquel ils appartiennent. Avec un accès Lecture au groupe de modèles, il pourra lier/délier des modèles à l'hôte, mais ne verra aucun modèle dans la liste des modèles et ne pourra pas effectuer d'opérations avec les modèles dans d'autres endroits.
- Un utilisateur de niveau Admin avec un accès Lecture à un hôte ne verra pas l'hôte dans la liste des hôtes de la section de configuration ; toutefois, les déclencheurs de l'hôte seront accessibles dans la configuration du service IT.
- Tout utilisateur non Super Admin (y compris 'guest') peut voir les cartes réseau tant que la carte est vide ou ne contient que des images. Lorsque des hôtes, des groupes d'hôtes ou des déclencheurs sont ajoutés à la carte, les permissions sont respectées.
- Le serveur Zabbix n'enverra pas de notifications aux utilisateurs définis comme destinataires des opérations d'action si l'accès à l'hôte concerné est explicitement "refusé".