This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introduction
Checkmk est disponible en différentes éditions qui se distinguent tant par leur gamme de fonctionnalités que par leurs applications possibles.
Nous souhaitons vous présenter ci-après l’édition commerciale
Checkmk Ultimate avec Multi-Tenancy (anciennement Checkmk MSP), qui vous permet, en tant que fournisseur de services gérés (MSP), d’exploiter des instances isolées pour plusieurs clients à l’aide de la supervision distribuée de Checkmk.
Dans une supervision distribuée avec une configuration centrale, les utilisateurs se connectent généralement à l’instance centrale, pour y effectuer des configurations ou pour accéder aux données de supervision. Les utilisateurs peuvent également se connecter aux instances distantes, car ils ne sont responsables que des ordinateurs hôtes et des services qui y sont surveillés, par exemple. Cependant, le concept d’autorisation de Checkmk, qui consiste à restreindre la visibilité et la configurabilité des ordinateurs hôtes et des services à l’aide de rôles et de groupes de contacts, est tout à fait suffisant pour ces deux scénarios. Les utilisateurs disposant d’autorisations très restreintes n’ont généralement pas d’accès direct à la ligne de commande du serveur de supervision et ne peuvent donc voir que les données dont ils sont responsables. Le fait qu’ils puissent être informés de l’existence d’autres ordinateurs hôtes et services ne pose aucun problème.
Dans une configuration centralisée, Checkmk dans Checkmk Community, Checkmk Pro et Checkmk Ultimate sans multi-tenancy distribuera donc toutes les données de configuration à tous les sites participants, car les données pourraient, en principe, se trouver ou être requises sur n’importe lequel d’entre eux. Par exemple, les mots de passe gérés de manière centralisée doivent également être mis à la disposition des instances distantes, car les hôtes/services des groupes de contact peuvent être répartis sur plusieurs sites.
Cependant, lorsque Checkmk doit être proposé en tant que service à un tiers (c'est-à-dire un client), certaines données de configuration ne peuvent être distribuées qu'à des instances distantes désignées. Cela signifie que les données sensibles d’un client ne doivent pas être stockées sur le serveur d’un autre client — une simple restriction de visibilité dans l’interface web n’est donc plus suffisante. Enfin, il se peut que le serveur de supervision local soit exploité par le client lui-même ou qu’il ait accès direct à la ligne de commande du serveur d’une autre manière.
De plus, il n’est plus nécessaire qu’un client puisse configurer son propre site, car le concept même d’un service distribué vise précisément à épargner ce travail au client. Le client n’a pas non plus besoin d’une vue de l’instance centrale, puisqu’il n’a besoin que d’un accès à ses propres données.
Avec Checkmk Ultimate et la multi-location, un fournisseur de services gérés (MSP) (ou « fournisseur » en abrégé) intègre une ou plusieurs instances distantes appartenant exclusivement à chaque client dans son instance centrale via la supervision distribuée. Les éléments individuels de l’Setupt alors attribués à ce client. Lors de la distribution des données de configuration, Checkmk n’envoie désormais ces données qu’au site d’un client, soit celles de nature générale, soit celles qui ont été validées pour ce client. Le fournisseur peut toujours effectuer la configuration de manière pratique via la configuration centrale de son propre site central. Le fournisseur dispose également d’une interface web centrale permettant à tous ses clients de travailler avec les données de surveillance. Cela fonctionne exactement de la même manière que dans un environnement distribué normal, la seule différence étant que tous les sites participants doivent utiliser Checkmk Ultimate avec la multi-location.

Les données de configuration importantes (par exemple, les instances distantes et les utilisateurs) peuvent être attribuées aux clients dans Checkmk Ultimate avec Multi-Tenancy. Le client n’a donc accès qu’à sa propre configuration, avec les données d’ordinateur hôte et de service, via l’instance qui lui a été attribuée. Il lui suffira de se connecter à son propre site et il ne recevra donc que ses propres données. Un login à l’instance centrale du fournisseur n’est pas nécessaire — et n’est d’ailleurs pas possible !
Important : vous devez utiliser Checkmk Ultimate avec la fonctionnalité Multi-Tenancy si vous utilisez Checkmk pour effectuer la supervision de votre propre infrastructure ainsi que de celle d’autres organisations.
2. Aperçu de Checkmk Ultimate avec la fonctionnalité multi-locataires
Checkmk Ultimate avec la fonctionnalité multitenant est actuellement l'édition la plus complète de Checkmk.
En termes de contenu, elle s'appuie sur
Checkmk Ultimate et en constitue une extension compatible avec la fonctionnalité multitenant.
Elle dispose de toutes les fonctions nécessaires pour exploiter des instances Checkmk distinctes pour plusieurs clients via une supervision distribuée.
Si, en tant que fournisseur, vous souhaitez proposer Checkmk en tant que service à vos clients, c'est l'édition qu'il vous faut.
3. Fonctions supplémentaires
La principale fonctionnalité de Checkmk Ultimate avec Multi-Tenancy qui le distingue des autres éditions est la possibilité d'attribuer les éléments suivants aux clients :
Instances distantes
Utilisateurs
Connexions LDAP
Règles et ensembles de règles pour l'Event Console
Mot de passe dans le coffre-fort à mot de passe
Groupes de contact
Agrégations BI
Paramètres globaux pour les instances distantes
4. Mise à niveau vers Checkmk Ultimate avec la multi-location
Vous pouvez effectuer une mise à niveau vers Checkmk Ultimate avec Multi-Tenancy à partir de n'importe quelle autre édition. Pour ce faire, suivez la procédure de mise à niveau vers Checkmk Ultimate. Pour une mise à niveau vers Checkmk Ultimate avec Multi-Tenancy dans des environnements distribués, seule la mise à niveau hors ligne peut être utilisée. Toutefois, une rétrogradation de Checkmk Ultimate avec Multi-Tenancy vers une autre édition n'est pas prévue et n'est pas prise en charge par nos soins.
À la suite d'une mise à niveau, tous les composants compatibles de Checkmk sont affectés à l'Provider. Toutes les fonctions sont désormais à votre disposition pour créer des clients et leur attribuer des instances, des utilisateurs de l'instance, etc.
Tenez compte des dépendances éventuelles pouvant résulter d’une configuration existante, et attribuez en conséquence les éléments appropriés des autres composants de Checkmk au client avant d’activer l’affectation à une instance.
Important : au moins un utilisateur doit être transféré vers l’instance du client. Peu importe qu’il s’agisse d’un utilisateur global répliqué sur toutes les instances ou d’un utilisateur spécifique au client.
Vous trouverez de plus amples informations à ce sujet dans le chapitre suivant.
5. Configuration
5.1. Création de clients
Vous pouvez créer l'un de vos clients en une seule étape : Sous « Setup > Users > Customers », sélectionnez le bouton « Add customer » et attribuez-lui un identifiant unique, ainsi que le nom tel qu'il doit s'afficher dans Checkmk. Une fois enregistré, votre premier client aura été créé dans Checkmk :

Comme vous pouvez le constater, le fournisseur est également considéré comme un client et a donc déjà été créé en tant qu’« Provider ». Cette attribution ne peut pas être supprimée.
5.2. Attribution d'instances
Une fois que vous avez créé un client, l'étape suivante consiste à associer les composants correspondants dans Checkmk à ce client. L'instance centrale, vers laquelle tous les autres sites du client envoient leurs données, est également appelée « site fournisseur ». La séparation des données ne fonctionne que si vous créez une instance distincte pour chaque client et que vous la connectez à votre site fournisseur. Dans ce cas, la configuration diffère sur un seul point : Dans l’Basic settings, vous saisissez l’Customer, que vous avez créé précédemment, en plus de l’ID et de l’alias :

Comme le fournisseur est également considéré comme un client, Checkmk sait toujours quel ordinateur hôte appartient à quel client en fonction de son affectation à une instance spécifique.
Vous pouvez configurer l'Global settings pour une instance client comme d'habitude via les paramètres globaux spécifiques à l'instance. |
5.3. Autres affectations
Outre l’instance elle-même, vous pouvez également attribuer d’autres éléments de l’Setup à un client — comme déjà mentionné ci-dessus. Un élément est attribué directement à un client. Vous pouvez également mettre un utilisateur ou un mot de passe à la disposition de tous via l’entrée Global. Voici un exemple d’attribution d’utilisateur :

L'attribution s'effectue toujours via les propriétés de l'élément concerné à l'aide de l'option Customer. Les paramètres globaux spécifiques à l'instance sont exclus de cette attribution.
Fonctionnalités spécifiques de l'Event Console
Dans l'Event Console, vous pouvez attribuer à la fois des règles individuelles et des ensembles de règles complets à un client. Il est important de noter que l'héritage est toujours obligatoire pour les ensembles de règles. Contrairement aux dossiers, il ne peut pas être remplacé par les règles individuelles. De cette manière, vous pouvez toujours être sûr que l'attribution est garantie pour chaque règle.
Si un ensemble de règles n'est pas attribué à un client, vous pouvez également attribuer les règles individuelles à un client.
5.4. Composants non personnalisables
Tous les composants qui n’ont pas été mentionnés dans le chapitre précédent ne peuvent pas être attribués à des clients individuels. Il convient néanmoins de dire quelques mots sur divers composants afin d’attirer l’attention sur certaines fonctionnalités particulières. Le non-respect de ces remarques peut présenter un risque de sécurité modéré.
Balises de l’hôte
Il en va de même pour les balises de l’hôte : celles-ci ne doivent contenir aucune information confidentielle, car elles sont distribuées à toutes les instances.
Notifications
Les règles de notification contiennent souvent des groupes de contacts et des conditions très spécifiques dans lesquelles la notification doit être déclenchée et envoyée. Comme ces règles sont également distribuées à toutes les instances, n'incluez pas de noms d'hôtes et de services explicites, d'adresses de contact ou toute autre donnée sensible.
Personnalisations pour les utilisateurs globaux
Notez que toutes les personnalisations effectuées pour un utilisateur global sont transférées à l’ensemble des instances du client. Les utilisateurs globaux ne sont donc pas adaptés aux vues spéciales, aux graphiques définis par l’utilisateur ou aux signets, car ceux-ci peuvent contenir des données sensibles spécifiques au client. Vous ne devez donc utiliser les utilisateurs globaux que dans des cas exceptionnels et non pour des tâches quotidiennes courantes.
5.5. Gestion des certificats
Les points mentionnés dans le chapitre précédent, tels que les notifications avec des groupes de contact ou des balises de l’hôte, ne peuvent révéler que des informations sur les structures organisationnelles d'autres clients.
La situation est différente en ce qui concerne la distribution des certificats racine CA (« autorité de certification ») : Si un certificat CA destiné au client A venait à être distribué au client B, il y aurait un risque que des employés malveillants chez le client A puissent mener une attaque de type « man-in-the-middle » sur la communication chiffrée chez le client B. C'est pourquoi les certificats CA stockés avec le paramètre global Trusted certificate authorities for SSL ne sont pas transmis aux instances distantes.
La manière correcte de configurer les certificats CA spécifiques au client consiste à les saisir dans les paramètres globaux propres à chaque instance distante des sites du client.
6. Les différences entre les composants en détail
6.1. Interface de configuration de la configuration
Vous pouvez accéder à une vue de la table permettant la gestion des clients dans l'Setup > Users > Customers.
Lors de la configuration des éléments pouvant être attribués aux clients, un champ supplémentaire d'Customer est disponible.
Ces fonctions sont décrites à titre d'exemple dans le chapitre consacré à la configuration.
6.2. Interface de supervision
Tableau de bord
Une nouveauté dans l'Main dashboard est le dashlet « Customers », situé à gauche des problèmes de service :

Lorsque vous sélectionnez un client, une vue de la table s’affiche dans laquelle tous ses ordinateurs hôtes sont répertoriés. Cette vue de la table fonctionne donc comme la vue de l’All hosts, à la différence que seuls les éléments d’un client spécifique sont affichés dans ce cas.
Barre latérale
Dans la barre latérale de l’instance centrale se trouve le snap-in « Customers », qui fonctionne de la même manière que le snap-in « Site status », d’apparence similaire. Vous pouvez y afficher l’état des instances pour chaque client, et également, en cliquant sur l’état, masquer certains clients ou les afficher dans la vue de la table.

Création et filtrage des vues de la table
Bien entendu, vous pouvez également utiliser les filtres et les ensembles de données tels qu’ils sont utilisés pour le dashlet et le snap-in pour vos propres vues. D’une part, le filtre « Site » a été étendu pour permettre la personnalisation des vues :

D'autre part, vous pouvez également créer des vues entièrement nouvelles basées sur un ou tous les clients. Pour ce faire, sélectionnez « All customers » comme source de données :

De plus, des étiquettes sous la forme « cmk/customer » sont créées pour tous les ordinateurs hôtes, ce qui permet de filtrer par client.
