Multi-Tenant-Zugriff: Berechtigungen für Service-Provider

Bei KVM Multi-Tenant teilen sich mehrere Kunden dieselbe Hardware, und ein Techniker wechselt im Alltag zwischen den Mandanten. Ein einziges falsch vergebenes Recht reicht, damit jemand die Konsole eines fremden Kunden sieht. An dieser Feinheit hängt, ob die Trennung zwischen Kunden hält oder nur auf dem Papier steht.

KVM Multi-Tenant: Rollen bei Redfish und OpenBMC

Redfish definiert eine rollenbasierte Zugriffssteuerung mit drei Grundrollen: Administrator für vollen Zugriff einschließlich Firmware und Konfiguration, Operator für den laufenden Betrieb ohne Änderungsrechte an der Grundkonfiguration, ReadOnly für reine Beobachtung (DMTF, Redfish-Spezifikation). Einzelne Privilegien lassen sich zusätzlich feingranular zuweisen, etwa das Recht, Power-Befehle abzusetzen, ohne gleichzeitig Benutzerkonten anlegen zu dürfen. Diese Kombination aus Grundrolle und Einzelprivileg erlaubt Zuschnitte, die über die drei Standardrollen hinausgehen, etwa ein Konto, das Konsole und Power-Funktionen nutzen darf, aber keine Netzwerkeinstellungen ändern kann.

OpenBMC, die verbreitete Open-Source-Firmware für BMCs, setzt dieses Modell über Privilegiengruppen um: priv-admin, priv-operator und priv-user (OpenBMC-Dokumentation). Jeder Benutzer gehört zu genau einer Gruppe, jede Gruppe bestimmt, welche Redfish-Endpunkte erreichbar sind. IPMI kennt diese Differenzierung in der Grundform nicht und arbeitet mit Passwörtern, die in vielen Implementierungen im Klartext hinterlegt sind. Redfish unterstützt dagegen moderne Authentifizierung einschließlich Zertifikaten, ein Unterschied, der bei der Wahl des Protokolls für Mandantenumgebungen den Ausschlag geben sollte.

Eine weitere Praxisfrage betrifft gleichzeitige Sitzungen. Manche BMCs erlauben nur eine aktive Konsolensitzung je Server, andere mehrere parallel mit Sicht auf denselben Bildschirm. Bei geteilter Nutzung durch mehrere Techniker lohnt sich ein Blick in die Konfiguration des Redfish-Session-Diensts, weil sie festlegt, wie viele gleichzeitige Sitzungen ein Konto öffnen darf und wie lange eine inaktive Sitzung offen bleibt, bevor sie automatisch endet.

Ein Rollenmodell für Dienstleister und Systemhäuser

Wer als Dienstleister mehrere Kunden auf gemeinsamer Hardware betreut, schneidet Techniker-Konten so eng zu, wie es der jeweilige Auftrag erlaubt. Für die reine Störungsbearbeitung reichen Power-Befehle und Konsolenzugriff auf die definierten Systeme eines Kunden. Firmware-Rechte oder Zugriff auf andere Mandanten gehören dort nicht hinein. Ein Techniker, der ausschließlich Störungen bei einem einzelnen Kunden bearbeitet, braucht entsprechend nur Zugriff auf dessen Systeme, nicht auf die gesamte Flotte des Systemhauses.

Zeitlich begrenzte Konten funktionieren in der Praxis über ein Ablaufdatum, das direkt am Konto hinterlegt wird, nicht über eine separate Erinnerung im Kalender eines Administrators. Endet der Einsatz eines externen Technikers zu einem festgelegten Zeitpunkt, deaktiviert sich das zugehörige Konto automatisch, unabhängig davon, ob jemand daran denkt, es manuell zu sperren. Diese Automatisierung schließt eine der häufigsten Lücken in der Praxis: das vergessene Konto eines längst abgeschlossenen Projekts, das noch Monate später gültige Zugangsdaten hat.

Getrennte Konten je Person statt eines gemeinsamen Sammelkontos sind dabei keine Kür. Ein Sammelkonto macht jede nachträgliche Zuordnung unmöglich. Teilen sich mehrere Techniker ein Passwort und geht an einem Server etwas schief, lässt sich im Nachhinein nicht mehr feststellen, wer tatsächlich verbunden war. Getrennte Konten mit eigenen Zugangsdaten lösen dieses Problem und liefern gleichzeitig die Grundlage für eine spätere Auswertung der Zugriffsprotokolle.

Zugriffe und Konfigurationsänderungen auf BMC-Ebene gehören durchgehend protokolliert, unabhängig vom gewählten Protokoll. Ohne Protokoll lässt sich im Streitfall nicht rekonstruieren, wer eine Einstellung geändert hat. Diese Protokollierung ergänzt die Netzarchitektur, die im Beitrag Management-Netz trennen: redundante Architektur für den Notfall beschrieben ist. Ein getrenntes Management-Netz ist die eine Voraussetzung, das Rollenmodell für einzelne Konten kommt als zweite Schicht obendrauf.

Wo ältere BMC-Generationen bei KVM Multi-Tenant an Grenzen stoßen

Nicht jede Hardware im Feld unterstützt das feingranulare Redfish-Modell. Viele ältere BMC-Generationen kennen nur grobe Rollen, oft nicht mehr als ein Administrator-Konto und ein einziges eingeschränktes Konto ohne weitere Abstufung. In der Praxis zeigt sich das bei Server-Generationen, die noch vor der breiten Einführung von Redfish beschafft wurden und deren BMC-Firmware sich auch über ein Update nicht mehr wesentlich erweitern lässt.

Wer eine gemischte Flotte aus alter und neuer Hardware betreibt, verlässt sich deshalb nicht allein auf die Rollenverwaltung des jeweiligen BMC. Die zusätzliche Schicht bringt Konsistenz über Hardware-Generationen hinweg, die einzelne BMCs naturgemäß nicht liefern können, und sie vereinheitlicht die Sicht für Techniker, die im Alltag zwischen alten und neuen Servern wechseln. Wer neue Hardware beschafft, kann diesen Punkt schon bei der Auswahl berücksichtigen und gezielt nach Redfish-Unterstützung mit feingranularen Rollen fragen, statt das Problem erst Jahre später im laufenden Betrieb zu entdecken.

Häufige Fragen

Wie trennt man Kunden auf gemeinsamer Hardware?

Über eng zugeschnittene Rollen je Kunde und System: Zugriff nur auf die vereinbarten Server, keine Firmware-Rechte, keine Sicht auf andere Mandanten. Redfish und OpenBMC bilden diese Trennung über Rollen wie Operator und Privilegiengruppen wie priv-operator ab, bei älterer Hardware übernimmt eine zentrale Verwaltungsschicht diese Aufgabe.

Braucht jeder Techniker ein eigenes Konto?

Ja. Ein gemeinsames Sammelkonto verhindert jede nachträgliche Zuordnung, wenn im Nachhinein geklärt werden muss, wer eine Änderung vorgenommen hat. Getrennte Konten je Person kosten in der Einrichtung etwas mehr Zeit, zahlen sich aber bei jeder Auswertung der Zugriffsprotokolle aus.

Wie lange sollte man Zugriffsprotokolle aufbewahren?

Für diese Frage gibt es keine allgemeingültige Zahl. Sinnvoll ist eine Aufbewahrung, die sich an der eigenen Vorfallsbearbeitung orientiert und lang genug reicht, um auch rückwirkend erkannte Vorfälle noch nachvollziehen zu können. Das eigene Datenschutzkonzept und, je nach Kunde, vertragliche Vorgaben setzen dafür den verbindlichen Rahmen.

torck verwaltet in der eigenen Infrastruktur mehrere Teams parallel, in Maxhütte-Haidhof, Wien und Rabat, und hat die eigene Rollenverwaltung von Anfang an konsequent nach Aufgaben getrennt. Genau dieses Rollenmodell steckt in KVM Fleet, wenn Kunden mehrere Techniker oder mehrere Mandanten auf einer gemeinsamen Plattform verwalten. Vertragspartner ist dabei die deutsche torck GmbH, ein Vertrag statt einer Subunternehmerkette. Wer das eigene Berechtigungskonzept prüfen lassen will, vereinbart eine Produktdemo oder ein erstes Gespräch, ohne Verpflichtung.

Gespräch vereinbaren