Utilisateurs, rôles et permissions

La page de gestion des utilisateurs se trouve à l'adresse Setup > Users > Users. Dans une instance nouvellement créée, cette page se présente comme suit (l'image ne montre que quelques colonnes du tableau) :

L'image ci-dessus montre tous les utilisateurs qui ont été créés automatiquement lors de la création de l'instance : Un utilisateur de l'automatisation, suivi de l'utilisateur unique (cmkadmin) pour le login interactif avec mot de passe. Avec la Checkmk Appliance, cet utilisateur peut avoir un nom différent, car vous définissez vous-même son nom et son mot de passe. Cet utilisateur cmkadmin possède les propriétés suivantes :

Le formulaire permettant de créer un nouvel utilisateur (via ) ou d'effectuer l'édition d'un utilisateur existant (via ) est divisé en cinq sections. La première section concerne l'identité.

Comme toujours dans Checkmk, l’ID d’un ensemble de données (Username) ne peut pas être modifié ultérieurement. Il est utilisé pour la connexion et sert également de clé interne dans tous les fichiers et toutes les structures de données.

L'adresse électronique est facultative et n'est requise que si l'utilisateur doit devenir un contact devant être notifié par courrier électronique (configuration SMTP requise). De même, le champ « Pager address » est destiné à la notification par SMS ou via des systèmes similaires. Si vous écrivez vos propres scripts de notification, vous pouvez accéder aux valeurs de ces champs et les utiliser à toutes fins utiles.

Avec Monitored sites, vous pouvez, si vous le souhaitez, limiter l'accès aux instances existantes. Ceci est particulièrement pratique pour les environnements de très grande envergure, tels qu'une supervision distribuée comprenant des centaines d'instances. Si un utilisateur n'a besoin que d'un certain nombre d'instances pour ses ordinateurs hôtes, l'interface graphique ne contactera que les instances sélectionnées pour configurer les vues, ce qui améliore considérablement les performances.

Cette section concerne le login et l’autorisation. L’option « Automation secret for machine accounts » est destinée aux comptes qui accèdent à Checkmk via HTTP/HTTPS et s’authentifient via l’URL. Nous vous montrerons comment procéder ci-dessous.

En ce qui concerne les rôles, vous devez en sélectionner au moins un. En théorie, vous pourriez attribuer plusieurs rôles à un utilisateur, qui bénéficierait alors des droits de tous ces rôles. Avec les rôles prédéfinis, cela n’aurait toutefois guère de sens.

Si vous bloquez des utilisateurs à l'aide de l'option « disable the login to this account », ils apparaîtront dans le tableau avec l'icône « ». Ils ne pourront plus se connecter, mais resteront dans le système. Si un utilisateur est un contact, les notifications ne seront pas affectées et l'utilisateur continuera à recevoir des courriers électroniques, etc. Si l'utilisateur était connecté au moment du blocage, il sera automatiquement déconnecté.

Dès que vous affectez un utilisateur à un ou plusieurs groupes de contacts, cet utilisateur devient un contact. Lorsqu’une nouvelle instance est créée, le groupe de contact « Everything » est également créé ; il contient toujours tous les ordinateurs hôtes et tous les services. Un utilisateur appartenant à ce groupe sera alors automatiquement responsable de tous les ordinateurs hôtes et services.

Dans la boîte de dialogue « Notifications », vous pouvez utiliser l'option « Receive fallback notifications » pour spécifier que ce contact recevra des notifications lorsqu'aucune règle de notification ne s'applique.

Les utilisateurs peuvent également modifier eux-mêmes tous les paramètres de cette case via User > Edit profile (sauf s’ils disposent du rôle « Guest user »). Hormis le choix de la langue de l’interface, ces paramètres sont rarement nécessaires. Vous trouverez comme toujours plus de détails dans l’aide en ligne.

Les utilisateurs peuvent également personnaliser eux-mêmes les paramètres de l'interface via User > Edit profile. L'option « Show more / Show less » (Afficher plus ou moins) est particulièrement intéressante, car elle permet de déterminer si Checkmk doit afficher plus ou moins d'informations dans l'interface. Si vous souhaitez toujours tout voir, vous pouvez forcer cette option ici avec « Enforce show more » (Afficher tout).

Les groupes de contacts constituent le lien entre les ordinateurs hôtes et les services d’une part, et les contacts d’autre part. Chaque groupe de contacts représente une responsabilité pour un domaine spécifique de votre environnement informatique. Par exemple, le groupe de contacts « SAP » pourrait regrouper toutes les personnes chargées de la maintenance des systèmes SAP et être affecté à tous les ordinateurs hôtes et services fournissant ces services dans cet environnement.

Vous gérez les groupes de contacts via Setup > Users > Contact groups. La figure suivante illustre ce module avec trois groupes de contacts créés manuellement :

La création d’un nouveau groupe est très simple. Comme toujours, l’ID est permanent et l’alias est un nom d’affichage que vous pouvez modifier ultérieurement à tout moment :

Le nouveau groupe de contacts est vide à deux égards : il ne contient ni contacts, ni ordinateurs hôtes, ni services. L'affectation des groupes de contacts aux contacts s'effectue via les profils utilisateur, comme vous l'avez déjà vu lors de l'édition de l'utilisateur.

Il existe deux méthodes pour inclure des ordinateurs hôtes dans des groupes de contacts : via un dossier et via des règles. Vous pouvez également combiner les deux méthodes. Dans ce cas, une agrégation des groupes de contacts respectifs sera attribuée à l'ordinateur hôte.

Il n’est pas toujours judicieux qu’un service fasse partie des mêmes groupes de contacts que son hôte. Vous pouvez donc utiliser le jeu de règles « Assignment of services to contact groups » (Hôte/Service) indépendamment des groupes de contacts de l’hôte. Les règles suivantes s’appliquent :

Dans un environnement simple, il suffit donc d’attribuer des groupes de contacts aux ordinateurs hôtes uniquement. Dès que vous avez besoin d’une plus grande différenciation, vous pouvez également créer des règles pour les services.

Vous pouvez vérifier si vous avez correctement configuré toutes les règles et tous les dossiers en consultant les détails d'un ordinateur hôte ou d'un service dans l'environnement de supervision. Vous y trouverez les entrées « Host contact groups » et « Host contacts » (ou « Service contact groups » et « Service contacts » respectivement), qui répertorient la liste des affectations réelles pour cet objet :

Le fait que les utilisateurs normaux (rôle Normal monitoring user) ne voient que les objets pour lesquels ils sont désignés comme contact est d'autant plus important que votre environnement de supervision est vaste. Cela permet non seulement d'avoir un aperçu clair, mais empêche également les utilisateurs d'intervenir là où ils n'ont pas à le faire.

En tant qu’administrateur (rôle « Administrator »), vous êtes bien sûr toujours autorisé à tout voir. Ceci est contrôlé via l’autorisation « See all host and services ». Dans vos paramètres personnels, vous trouverez à l’adresse Visibility of hosts/services la case à cocher « Only show hosts and services the user is a contact for ». Grâce à celle-ci, vous pouvez renoncer volontairement à la vue d’ensemble et n’afficher que les ordinateurs hôtes et les services pour lesquels vous êtes un contact. Cette option est destinée aux rôles doubles, c’est-à-dire aux personnes qui sont à la fois administrateurs et utilisateurs normaux.

Le rôle « Guest user » est prédéfini de manière à ce que ses utilisateurs puissent également tout voir. Les interventions ou les paramètres personnels sont désactivés ici.

Pour les utilisateurs normaux, la visibilité dans l’environnement de supervision est implémentée de telle sorte que les ordinateurs hôtes et les services pour lesquels vous n’êtes pas contact semblent ne pas exister dans le système. Entre autres, les éléments suivants tiennent compte de la visibilité :

Comme nous l'avons montré ci-dessus, il est possible que vous soyez un contact pour un ordinateur hôte, mais pas pour tous ses services. Néanmoins, dans un tel cas, vous pourrez voir tous les services de l'ordinateur hôte dans l'interface graphique.

Cette exception est activée par défaut, car elle s’avère généralement utile. En pratique, cela signifie, par exemple, que le collègue responsable de l’ordinateur hôte en question peut également voir tous les services connectés à cet ordinateur hôte — il ne reçoit toutefois aucune notification concernant ces services !

Si cette approche ne vous convient pas, vous pouvez la modifier dans les éditions commerciales via Global settings > Monitoring core > Authorization settings. Si vous y modifiez le paramètre « Services » (Afficher les services pour les contacts de l’hôte) en « Strict - Visible if user is contact for the service » (Afficher les services uniquement pour les contacts de l’hôte), les utilisateurs ne pourront voir les services que s’ils ont été directement désignés comme contacts pour le service.

Soit dit en passant, tout cela n’a rien à voir avec le fait qu’un service hérite des groupes de contacts de son ordinateur hôte si aucun groupe de contacts ne lui a été attribué, car dans ce cas, vous seriez un contact pour ce service et recevriez donc ses notifications.

La deuxième option de l'Authorization settingse globale concerne les groupes d'hôtes et de service. Vous pouvez normalement voir un groupe dès lors que vous pouvez voir au moins un élément de ce groupe ; toutefois, le groupe apparaîtra alors comme s'il ne contenait que les éléments qui vous sont visibles.

En passant en mode « Strict - Visible if all members are visible », tous les groupes pour lesquels vous n’êtes pas contact pour au moins un ordinateur hôte ou un service seront masqués.

Notez que ces deux paramètres de visibilité n'ont aucune incidence sur les notifications.

Checkmk attribue toujours les autorisations aux utilisateurs via des rôles — jamais directement. Un rôle n’est rien d’autre qu’une liste d’autorisations. Il est important de comprendre que les rôles définissent le niveau d’autorisations et ne font référence à aucun hôte ou service. C’est à cela que servent les groupes de contact.

Checkmk est fourni avec les rôles prédéfinis suivants, qui ne peuvent jamais être supprimés, mais peuvent être personnalisés à votre guise :

La gestion des rôles se fait via Setup > Users > Roles & permissions :

À ce propos, lors de la création d’une nouvelle instance Checkmk, un seul utilisateur (cmkadmin) doté du rôle « Administrator » est créé pour le login à l’interface Checkmk. Les autres rôles possibles ne seront pas utilisés pour le moment. Si vous avez besoin d’un utilisateur invité, vous devez le créer vous-même.

Comme d'habitude, l' vous permet d'accéder au mode d'édition d'un rôle :

Vous pouvez découvrir la signification des différentes autorisations (présentées ici sous forme d'extraits) dans l'aide en ligne.

La particularité ici est que pour chaque autorisation, trois choix s’offrent à vous : yes, no et default (yes) ou default (no). Lors de l’installation, toutes les valeurs sont définies sur default. Pour l’autorisation elle-même, cela ne fait aucune différence que vous ayez défini yes ou default (yes). Il est toutefois possible que l’installation d’une nouvelle version de Checkmk modifie une valeur par défaut (même si cela arrive très rarement). Un paramètre que vous avez explicitement défini ne serait alors pas affecté par l’installation.

De plus, ce principe vous permet de repérer très rapidement les éventuels écarts de votre installation Checkmk par rapport à la norme.

Vous serez peut-être surpris de constater qu’il n’existe pas de bouton permettant de créer un nouveau rôle. Cette absence est délibérée. Vous créez de nouveaux rôles en les dérivant de rôles existants à l’aide de Clone. Le nouveau rôle n’est pas simplement créé en tant que copie, mais conserve son lien avec le rôle d’origine (Based on role) :

Cette connexion remplit une fonction importante. En effet, toutes les autorisations du rôle cloné qui ne sont pas définies explicitement (c'est-à-dire qui sont toujours définies sur « default ») seront héritées du rôle source. Les modifications ultérieures apportées au rôle source seront répercutées sur le nouveau rôle cloné. C'est très pratique si l'on considère le nombre d'autorisations que peut comporter le rôle d'origine. Avec une simple copie, vous pourriez facilement perdre de vue ce qui est réellement particulier dans le rôle que vous avez défini pour vous-même.

Cette fonction de dérivation résout également un autre problème : Comme nous continuons à développer Checkmk, de nouvelles autorisations sont constamment ajoutées. À chaque fois, nous devons alors décider dans lequel des trois rôles Administrator, Normal monitoring user et Guest user la nouvelle autorisation doit être intégrée. Comme chacun de vos propres rôles est dérivé d’un des rôles prédéfinis, la nouvelle autorisation est automatiquement préréglée sur une valeur pertinente. Il serait très peu pratique si, par exemple, vous définissiez votre propre rôle d’utilisateur et que de nouvelles autorisations y manquaient systématiquement. Vous devriez adapter votre rôle à chaque nouvelle fonctionnalité pour que vos utilisateurs puissent les utiliser.

Si vous souhaitez comparer les autorisations des différents rôles, vous pouvez vous aider de la vue de la table, accessible via Setup > Users > Roles & permissions > Roles > Permission matrix. Cette option de menu affiche la vue suivante, dans laquelle vous pouvez non seulement comparer les autorisations des différents rôles, mais également voir où des autorisations ont été explicitement définies () ou supprimées ().

Lors de l’installation de Checkmk, un administrateur est créé par défaut, comme déjà mentionné ci-dessus. Cet administrateur est nommé cmkadmin. Vous pouvez désormais continuer à travailler avec cet administrateur comme vous le souhaitez, mais il se peut que vous ne souhaitiez pas utiliser cet administrateur par défaut. Par exemple, en raison de la réglementation interne de l’entreprise, parce que vous souhaitez définir plusieurs administrateurs, ou pour vous conformer à des recommandations de sécurité telles que la norme OWASP Application Security Verification Standard (ASVS).

Tout d’abord, un administrateur est un utilisateur comme les autres. Il est donc créé comme décrit dans le chapitre « Administration des utilisateurs » de l’environnement de configuration. Cependant, ce sont les droits attribués à l’utilisateur via le rôle sélectionné qui sont déterminants.

Sélectionnez le rôle «Administrator» lors de la création de l'utilisateur. Tous les autres paramètres sont également définis pour l'administrateur en fonction de vos préférences personnelles ou des spécifications internes de l'entreprise.

Lors de la connexion de Checkmk à d’autres systèmes, on souhaite souvent automatiser certaines activités qui s’effectuent normalement via l’interface graphique. En voici quelques exemples :

Dans de telles situations, un logiciel externe doit pouvoir récupérer automatiquement certaines URL depuis l’interface Checkmk. Cela soulève bien sûr la question de la manière dont l’utilisateur se connecte. La méthode habituelle via le dialogue de login est fastidieuse et nécessite la récupération de plusieurs URL successives ainsi que l’enregistrement d’un cookie.

Pour simplifier cela, Checkmk propose le concept d’utilisateurs de l’automatisation. Ces utilisateurs sont exclusivement destinés au contrôle à distance et ne permettent pas de login normal via l’interface graphique. L’authentification s’effectue ici via l’authentification HTTP Basic.

Un utilisateur de l'automatisation est déjà configuré sur chaque instance Checkmk : il sert à enregistrer l'agent auprès du serveur Checkmk pour le transfert de données chiffré par TLS. Pour d'autres tâches, vous pouvez créer des utilisateurs de l'automatisation supplémentaires, généralement avec le rôle « administrator ». Vous créez un utilisateur de l'automatisation comme un utilisateur normal, mais vous ne lui attribuez pas un mot de passe normal, mais un mot de passe d'automatisation (Automation secret). Vous pouvez faire créer ce mot de passe automatiquement à l'aide du cube « » :

Un utilisateur de l'automatisation a un rôle tout comme un utilisateur normal et peut également être un contact. Cela signifie que vous pouvez restreindre les autorisations et la visibilité des ordinateurs hôtes et des services selon vos besoins.

Pour la récupération automatique de pages Web, vous devez ensuite saisir l'en-tête de l'authentification HTTP Basic, qui se présente généralement comme suit : Authorization: Basic 1234567890abcdef. Cette chaîne de caractères correspond à la forme encodée en Base64 de username:password.

Voici un exemple de récupération d'une vue de la table au format JSON avec l'utilisateur de l'automatisation automation et son mot de passe d'automatisation — l'encodage Base64 est effectué par curl :

Si le script qui récupère l'URL s'exécute directement sur le site de supervision, vous pouvez lire le mot de passe d'automatisation de l'utilisateur directement à partir du système de fichiers. Il ne s'agit pas d'une faille de sécurité, mais d'une fonctionnalité intentionnelle : Vous pouvez écrire des scripts d'automatisation qui n'ont pas besoin de contenir le mot de passe d'automatisation et qui ne nécessitent pas de fichier de configuration. Pour ce faire, lisez le fichier ~/var/check_mk/web/myuser/automation.secret :

Vous pouvez facilement stocker le contenu de ce fichier dans une variable du shell, par exemple afin de pouvoir le lire ultérieurement à l'aide d'un script :

Si vous devez gérer un environnement de supervision relativement important, vous souhaiterez sans doute impliquer d’autres administrateurs dans la configuration et, surtout, dans la gestion des ordinateurs hôtes et des services. Afin de garder le contrôle sur les personnes autorisées à effectuer des modifications et sur les actions qui leur sont permises, et pour éviter que les utilisateurs ne se gênent mutuellement, vous pouvez attribuer des autorisations pour la configuration de Checkmk sur la base de dossiers.

La première étape consiste à faire en sorte que vos collègues administrateurs travaillent avec leurs propres utilisateurs en s'appuyant sur le rôle « Normal monitoring user ».

Ce rôle dispose essentiellement d'une autorisation pour l'environnement de configuration, mais avec certaines restrictions importantes :

Tant que vous n'avez pas encore publié de dossiers ou de packs BI, cela signifie que les utilisateurs disposant du rôle « Normal monitoring user » ne peuvent initialement apporter aucune modification. Le menu « SimpleSetup » se présente comme suit pour les utilisateurs de supervision normaux :

Un utilisateur reçoit l'autorisation de créer, modifier et supprimer des ordinateurs hôtes via des groupes de contact. La procédure est la suivante :

L'exemple suivant montre les propriétés d'un dossier dans lequel tous les utilisateurs du groupe de contact « Linux » sont autorisés à gérer les hôtes. L'option a été activée pour permettre cela également dans les sous-dossiers.

C'est à vous de décider si vous souhaitez inclure automatiquement les ordinateurs hôtes dans le groupe de contacts. Dans cet exemple, l'option « Add these groups as contacts to all hosts in this folder » n'a pas été définie et les ordinateurs hôtes ne seront pas ajoutés au groupe de contacts « Linux ». Cela signifie que, dans l'environnement de supervision, ils ne seront pas visibles pour le groupe de contacts « Linux » (à moins qu'une règle ne s'en charge). Ainsi, comme vous pouvez le constater, la visibilité (et la responsabilité dans la supervision) et l'autorisation pour l'environnement de configuration peuvent être réglées séparément.

La sécurité est une priorité absolue de nos jours. C'est pourquoi certaines entreprises ont mis en place des directives générales concernant la gestion des mots de passe. Checkmk propose plusieurs paramètres permettant d'appliquer ces règles par défaut. Certaines de ces options se trouvent sous Global settings > User management > Password policy for local accounts :

La première option, « Minimum password length », vise à garantir la qualité du mot de passe.

Pour la deuxième option « Number of character groups to use », il existe au total quatre groupes de caractères :

Si vous définissez une 4 ici, le mot de passe doit contenir au moins un caractère de chacun des groupes ci-dessus. Une 2 garantit au moins que le mot de passe ne se compose pas, par exemple, uniquement de lettres minuscules. Ces paramètres sont checkés à chaque fois que le mot de passe est modifié.

La troisième option, « Maximum age of passwords », oblige l'utilisateur à modifier son mot de passe à intervalles de temps réguliers. Une fois le délai écoulé, la page suivante affichera le message suivant à l'utilisateur :

Les utilisateurs ne pourront continuer qu'après avoir modifié leur mot de passe.

Vous pouvez exiger la modification du mot de passe initial lors du premier login. Pour ce faire, utilisez l'option « Enforce change: Change password at next login or access » (Modification obligatoire du mot de passe) dans la section « Security » (Configuration du login) des propriétés de l'utilisateur concerné.

Sous « Global settings > User management », vous trouverez d'autres paramètres globaux qui régissent les logins des utilisateurs.

Afin d'améliorer la sécurité de vos instances Checkmk, Checkmk propose une fonctionnalité d'authentification à deux facteurs pour chaque utilisateur. Cette authentification à deux facteurs repose sur la norme internet FIDO2/WebAuthn. L'authentification repose généralement sur la connaissance (un mot de passe) et la possession (un authentificateur).

Vous pouvez utiliser n'importe quel matériel compatible FIDO2 pris en charge par votre navigateur et votre système d'exploitation. Les clés USB ou NFC telles que la YubiKey sont les plus couramment utilisées. Il est également possible d'utiliser des gestionnaires de mots de passe (par exemple, sur un smartphone) qui génèrent un mot de passe à usage unique basé sur le temps (TOTP).

En cas d'urgence, vous pouvez également modifier un mot de passe via la ligne de commande. Cela vous permet de vous sortir d'une situation où vous avez perdu le mot de passe pour cmkadmin. La condition préalable est, bien sûr, qu'il soit toujours possible de se connecter en tant qu'utilisateur Linux sur le serveur Checkmk et que vous puissiez devenir un utilisateur de l'instance avec omd su mysite.

Les mots de passe sont stockés dans le fichier ~/etc/htpasswd, comme décrit ci-dessus.

La modification des mots de passe s'effectue à l'aide de l'instruction cmk-passwd. Cette instruction ne vous demandera pas le mot de passe existant. Dans une version actuelle de Checkmk, cmk-passwd choisira toujours une méthode de chiffrement sécurisée pour stocker vos mots de passe. Actuellement, cmk-passwd utilise bcrypt à cette fin. Les mots de passe non chiffrés ou faiblement chiffrés (par exemple avec MD5) ne permettent pas de réaliser un login sur l'interface graphique.