Accès multi-locataires : autorisations pour les fournisseurs de services

Avec le KVM multi-locataires, plusieurs clients partagent le même matériel, et un technicien passe quotidiennement d’un client à l’autre. Il suffit d’un seul droit mal attribué pour que quelqu’un puisse accéder à la console d’un autre client. C’est de cette subtilité que dépend si la séparation entre les clients est effective ou si elle n’existe que sur le papier.

KVM multi-locataires : rôles dans Redfish et OpenBMC

Redfish définit un contrôle d'accès basé sur les rôles, avec trois rôles de base : « Administrateur » pour un accès complet, y compris au micrologiciel et à la configuration ; « Opérateur » pour l'exploitation courante sans droit de modification de la configuration de base ; et « Lecture seule » pour la surveillance uniquement (DMTF, spécification Redfish). Des privilèges individuels peuvent en outre être attribués avec une grande précision, comme le droit d'exécuter des commandes Power sans pour autant pouvoir créer de comptes utilisateurs. Cette combinaison d’un rôle de base et d’un privilège individuel permet des configurations sur mesure qui vont au-delà des trois rôles standard, par exemple un compte autorisé à utiliser la console et les fonctions Power, mais qui ne peut pas modifier les paramètres réseau.

OpenBMC, le micrologiciel open source largement utilisé pour les BMC, met en œuvre ce modèle à l'aide de groupes de privilèges : priv-admin, priv-operator et priv-user (Documentation OpenBMC). Chaque utilisateur appartient à un seul groupe, et chaque groupe détermine quels points de terminaison Redfish sont accessibles. IPMI ne prend pas en compte cette distinction dans sa forme de base et fonctionne avec des mots de passe qui, dans de nombreuses implémentations, sont stockés en clair. Redfish, en revanche, prend en charge les méthodes d’authentification modernes, y compris les certificats, une différence qui devrait être déterminante lors du choix du protocole pour les environnements multi-clients.

Une autre question pratique concerne les sessions simultanées. Certains BMC n'autorisent qu'une seule session de console active par serveur, tandis que d'autres en permettent plusieurs en parallèle avec affichage du même écran. En cas d’utilisation partagée par plusieurs techniciens, il est utile de consulter la configuration du service Redfish Session, car celle-ci définit le nombre de sessions simultanées qu’un compte est autorisé à ouvrir et la durée pendant laquelle une session inactive reste ouverte avant de se fermer automatiquement.

Un modèle de référence pour les prestataires de services et les intégrateurs système

Lorsqu’un prestataire de services gère plusieurs clients sur un même parc matériel, il limite les droits des comptes techniciens au strict minimum autorisé par chaque mission. Pour le simple traitement des pannes, les commandes Power et l’accès par console aux systèmes définis d’un client suffisent. Les droits d’accès au micrologiciel ou à d’autres mandants n’ont pas leur place ici. Un technicien qui traite exclusivement les pannes chez un seul client n’a donc besoin que d’un accès à ses systèmes, et non à l’ensemble du parc informatique du prestataire.

Dans la pratique, les comptes à durée limitée fonctionnent grâce à une date d'expiration enregistrée directement sur le compte, et non via un rappel distinct dans l'agenda d'un administrateur. Lorsque la mission d'un technicien externe prend fin à une date déterminée, le compte correspondant est automatiquement désactivé, que quelqu'un pense ou non à le bloquer manuellement. Cette automatisation comble l’une des lacunes les plus courantes dans la pratique : le compte oublié d’un projet terminé depuis longtemps, dont les identifiants d’accès restent valides plusieurs mois plus tard.

Disposer de comptes distincts pour chaque personne plutôt que d'un compte collectif unique n'est pas un luxe. Un compte collectif rend toute attribution a posteriori impossible. Si plusieurs techniciens partagent un mot de passe et qu’un problème survient sur un serveur, il est impossible de déterminer a posteriori qui était réellement connecté. Des comptes distincts, chacun doté de ses propres identifiants, résolvent ce problème tout en fournissant la base nécessaire à une analyse ultérieure des journaux d’accès.

Les accès et les modifications de configuration au niveau du BMC doivent être systématiquement consignés, quel que soit le protocole utilisé. Sans journalisation, il est impossible, en cas de litige, de déterminer qui a modifié un paramètre. Cette journalisation vient compléter l'architecture réseau présentée dans l'article Déconnecter le réseau de gestion : une architecture redondante en cas d'urgence comme décrit ci-dessus. Un réseau de gestion distinct est la première condition préalable ; le modèle de rôles pour les comptes individuels s'ajoute ensuite comme deuxième couche.

Là où les anciennes générations de BMC atteignent leurs limites avec le KVM multi-locataires

Tous les matériels en service ne prennent pas en charge le modèle Redfish à granularité fine. De nombreuses générations anciennes de BMC ne proposent que des rôles généraux, souvent pas plus qu’un compte administrateur et un seul compte à droits restreints, sans autre niveau intermédiaire. Dans la pratique, cela se vérifie notamment pour les générations de serveurs acquises avant la généralisation de Redfish et dont le micrologiciel BMC ne peut plus être considérablement étendu, même par le biais d'une mise à jour.

C'est pourquoi ceux qui exploitent un parc mixte composé de matériel ancien et récent ne se fient pas uniquement à la gestion des rôles de chaque BMC. Cette couche supplémentaire assure une cohérence entre les différentes générations de matériel, ce que les BMC individuels ne peuvent naturellement pas offrir, et elle uniformise la vue d'ensemble pour les techniciens qui passent quotidiennement d'anciens serveurs à de nouveaux. Lors de l’acquisition de nouveau matériel, il est possible de prendre cet aspect en compte dès la phase de sélection et de demander expressément la prise en charge de Redfish avec des rôles à granularité fine, plutôt que de découvrir le problème des années plus tard, en cours d’exploitation.

Foire aux questions

Comment séparer les clients sur un même matériel ?

Grâce à des rôles strictement définis pour chaque client et chaque système : accès uniquement aux serveurs convenus, aucun droit sur le micrologiciel, aucune visibilité sur les autres mandants. Redfish et OpenBMC mettent en œuvre cette séparation via des rôles tels que « Operator » et des groupes de privilèges tels que « priv-operator » ; sur le matériel plus ancien, cette tâche est assurée par une couche d'administration centrale.

Chaque technicien doit-il disposer de son propre compte ?

Oui. Un compte collectif unique empêche toute attribution a posteriori lorsqu'il faut déterminer rétrospectivement qui a effectué une modification. La mise en place de comptes distincts pour chaque personne prend un peu plus de temps, mais s'avère très utile à chaque analyse des journaux d'accès.

Combien de temps faut-il conserver les journaux d'accès ?

Il n'existe pas de durée de conservation universelle pour cette question. Il est judicieux d'opter pour une durée de conservation adaptée à votre propre processus de traitement des incidents et suffisamment longue pour permettre de retracer les incidents identifiés a posteriori. Votre propre politique de protection des données et, selon le client, les dispositions contractuelles, en définissent le cadre contraignant.

torck gère plusieurs équipes en parallèle au sein de sa propre infrastructure, à Maxhütte-Haidhof, Vienne et Rabat, et a, dès le départ, systématiquement séparé sa propre gestion des rôles en fonction des tâches. C'est précisément ce modèle de rôles qui se trouve dans Flotte KVM, lorsque les clients gèrent plusieurs techniciens ou plusieurs clients sur une plateforme commune. Le partenaire contractuel est ici la société allemande torck GmbH : un contrat unique remplace ainsi une chaîne de sous-traitants. Si vous souhaitez faire évaluer votre propre système d'autorisations, vous pouvez convenir d'une démonstration du produit ou d'un premier entretien, sans engagement.

Prendre rendez-vous