KVM-over-IP-Geräte kontrollieren
Verwaltung fürs Management
KVM-over-IP-Geräte haben unbestritten ihre Vorteile, sie erfordern allerdings auch ein nicht zu unterschätzendes Mehr an eigener Verwaltung. Hilfe kommt von so genannten Meta-Managern, die als Soft- oder Hardwarelösung unter anderem die Authentifizierung der Nutzer übernehmen können.
In jüngster Vergangenheit hat sich ein Wandel in der technischen Realisierung von
hardwarebasierenden KVM-Fernsteuersystemen vollzogen. KVM steht für Keyboard, Video und Maus und
bezeichnet damit Systeme, die auf unterster Ebene die Schnittstellen eines Rechners an einem
entfernten Ort zur Verfügung stellen. Dies ist notwendig, um einerseits nicht an jeden Server eben
Keyboard, Monitor und Maus anschließen zu müssen, was Platz und Kostenprobleme verursachen kann,
und um andererseits tatsächlich das uneingeschränkte entfernte Bedienen zu ermöglichen. Dies ist
zum Beispiel in Rechenzentren aufgrund ihrer großen Serverdichte notwendig.
Während noch vor wenigen Jahren ausschließlich analoge Systeme, so genannte KVM-Switches, zum
Einsatz kamen, haben KVM-over-IP-Geräte [1],[2] stark an Bedeutung gewonnen und werden in Kürze die
traditionellen Systeme wohl komplett ersetzen. KVM-Switches übertragen Videosignale mittels
geeigneter Modulationsverfahren auf analogem Wege über eine räumlich sehr begrenzte Länge (zehn bis
100 Meter). KVM-over-IP-Geräte redigitalisieren das Videosignal und nutzen IP-Protokolle für deren
Übertragung. Damit wird es per IP-Netzinfrastruktur möglich, hochqualitative und globale
KVM-Fernsteuersystemen zu realisieren, die alle Beschränkungen der alten Technik aufheben.
Diese Funktionalität wird jedoch mit einer größerer Komplexität der Geräte erkauft. Jedes
KVM-over-IP-Gerät ist selbst ein kompletter Rechner, der eine eigene IP-Adresse sowie ausgefeilte
Sicherheitsmechanismen benötigt. Indem also IP-Fernsteuersysteme das Management von Rechnersystemen
vereinfachen sollen, verursachen sie selbst ein Meta-Managementproblem. Auch sie müssen
konfiguriert und gewartet werden, benötigen ein Identifizierungs-, Zugriffs- und
Rechtemanagement.
Dasselbe gilt allgemein für alle Fernsteuersysteme, die sich des Internetprotokolls bedienen.
Große Bedeutung haben serielle Konsolenumsetzer, die die serielle Schnittstelle eines Rechners per
IP verfügbar machen.
Wichtig sind in diesem Kontext verschiedenen Aspekte dieser Meta-Managementprobleme, die Frage,
welche generellen Methoden angewendet werden können, um sie zu lösen sowie konkrete Beispiele für
Realisierungsvarianten. Ein Gerät oder eine Software, die diese Methoden implementiert oder
anwendet, trägt im folgenden Text die Bezeichnung Meta-Manager. Ein gemanagtes Gerät wird als
Access-Device oder einfach nur als Gerät bezeichnet.
Meta-Probleme und Lösungsansätze
IP-Fernsteuersysteme sind meist komplette, eigenständige Systeme, die alle Funktionalität für
ihren sicheren Betrieb mitbringen. Dies hat Vorteile bei Einzelinstallationen, da keine zusätzliche
Infrastruktur benötigt wird. In Rechenzentren jedoch, wo leicht hunderte von Fernsteuersystemen
arbeiten, kann diese Eigenständigkeit schnell zur Unhandlichkeit mutieren.
Angenommen, ein Rechenzentrumsadministrator will 100 KVM-over-IP-Geräte einsetzen, um seine
Server fernzuwarten. Ohne zusätzliche Hilfsmittel müsste er bei 100 Systemen die IP-Adresse per
seriellem Kabel konfigurieren. Danach müsste er auf jedem System das Administratorkennwort ändern
und alle benötigten Nutzer mit ihren Rechten anlegen. Abschließend stellt er fest, dass noch eine
Systemsoftwareaktualisierung notwendig wird. Dazu muss er hundertmal die Firmware neu aufspielen
und danach jedes einzelne Gerät auf korrekte Funktion prüfen. Es wird klar, dass selbst bei einer
solchen relativ geringen Anzahl von Geräten der Arbeitsaufwand zu groß ist – und die anfallende
Arbeit allein sich wiederholender Natur.
Die Probleme sind die gleichen, die auch beim gemeinsamen Betrieb großer Rechnerfarmen
auftreten, sei es im Rechenzentrum oder auf dem Desktop. Dementsprechend lassen sie sich mit den
gleichen Ansätzen lösen. Im Einzelnen sind dies:
1. Zentralisierte Nutzer- und Zugriffsverwaltung: Sie stellt sicher, dass Nutzerdaten nicht
repliziert werden und ermöglicht geräte- oder nutzerübergreifende Autorisierungsregeln. Außerdem
ermöglichst sie die Integration in eine möglicherweise schon bestehende Infrastruktur.
2. Batchprocessing oder Cluster-Operationen: Einige Operationen müssen verteilt ausgeführt
werden, zum Beispiel das Aktualisieren der Firmware. Um dennoch eine zentralisierte Abbildung zu
ermöglichen, muss ein Meta-Manager Operationen auf eine Gruppe von Access-Devices oder auf einem
Cluster selbstständig replizieren können.
3. Automatisches Auffinden und Konfigurieren: Dies ermöglicht den Überblick über den Status der
Access-Devices und vermeidet sich wiederholende Grundkonfigurationen.
Bei der Auswahl von Access-Devices und eines Meta-Managers, mit dessen Hilfe sie verwaltet
werden sollen, ist es ratsam, diesen Punkten Aufmerksamkeit zu widmen. Nur wenn alle auf eine für
den Anwendungszweck passenden Weise implementiert sind, lässt sich der Meta-Verwaltungsaufwand auf
ein erträgliches Maß senken.
Zentralisierungstechnik
Die zentralisierte Zugriffs- und Nutzerverwaltung eines Meta-Managers stellt Dienste für die
Authentifizierung und Autorisierung bereit. Authentifizierung ist die zweifelsfreie Identifikation
eines Nutzers. Autorisierung ist das Auffinden und Durchsetzen der individuellen Rechte eines
Nutzers.
An auf dem Markt befindlichen Meta-Managern lassen sich grundsätzlich zwei
Implementierungsvarianten beobachten (Bild 1):
1. Mittels standardisierter Authentifizierungs- und Autorisierungsdienste: Die am häufigsten
verwendeten Dienste sind LDAP[3] und RADIUS[4]. Wenn ein Nutzer versucht sich an einem konkreten
Access-Device anzumelden, wird dieses die Authentifizierung mithilfe des Dienstes vornehmen.
Zusätzlich ist es bei beiden Diensten möglich, zusätzliche Daten zu einem Konto abzulegen, die für
die Autorisierung verwendet werden können. Die Dienste können, müssen jedoch nicht notwendigerweise
Bestandteile des Meta-Managers sein. Falls sie es nicht sind – zum Beispiel, weil bereits
vorhandene Dienste und deren Daten mitbenutzt werden sollen – fungiert der Meta-Manager häufig nur
als Nutzerschnittstelle für Datenänderungen in den Diensten.
2. Per Authentifizierungs- und Autorisierungs-Proxy: In diesem Fall meldet sich der Nutzer nicht
direkt auf einem Access-Device an, sondern an einem Stellvertreter (häufig ist dies der
Meta-Manager selbst), der die komplette Kontrolle über alle Access-Devices hat. Die verwalteten
Access-Devices lehnen direkte Anmeldeversuche generell ab. Der Meta-Manager selbst ist über ein
spezielles Konto an allen Access-Devices angemeldet. Alle Zugriffe eines Nutzers auf ein konkretes
Access-Device müssen über den Proxy geleitet werden, damit dieser individuelle Zugriffsrechte
durchsetzen kann. Der Proxy selbst kann standardisierte Protokolle wie LDAP oder RADIUS benutzen,
um eine Einbindung in bestehende Infrastrukturen zu ermöglichen.
Cluster-Operationen sind replizierte Operationen, deren Ziel aus einer Gruppe von selektierten
Access-Devices besteht. Cluster-Operationen sind im Allgemeinen durch proprietäre Mechanismen
implementiert. Häufig wird das normale Nutzer-Interface "gescripted", wie es im Jargon heißt.
Gegenwärtig gibt es keine standardisierten Interfaces. Dies liegt auch an der Verschiedenartigkeit
der Access-Devices unterschiedlicher Hersteller.
Automatisches Auffinden und Konfigurieren
Automatisches Auffinden (Discovery) ist eine hilfreiche Funktionalität, um einem Meta-Manager
neue Access-Devices bekannt zu machen. Meist werden UDP-Multicast- oder Broadcast-Protokolle
genutzt. Neben der essentiellen IP-Konfiguration sind die Access-Devices auch für einen bestimmten
Meta-Manager zu konfigurieren, was Fachleute auch als "Binden" bezeichnen. Das Binden ist ein
sicherheitsrelevanter Prozess, da ein Angreifer versuchen könnte, mithilfe eines vorgetäuschten
Meta-Managers Kontrolle über viele Geräte zu erlangen, oder aber mithilfe eines vorgetäuschten
Geräts eigentlich nicht erlaubte Authentifizierungen zu erhalten. Leider hat sich in diesem Bereich
noch kein herstellerübergreifendes Sicherheitsverfahren etablieren können. Auf ein Verfahren zum
sicheren Binden von Access-Devices geht ein Beispiel weiter im Text ein. Eine automatische
IP-Konfiguration ist meist per DHCP [5] realisiert, das die Access-Devices selbst unterstützen
müssen.
Beispiele für die Implementierung
Exemplarisch lassen sich die folgenden zwei konkreten Lösungen betrachten, die die oben
genannten Ansätze einschließen. Beide sind im Meta-Manager von Peppercon (www.pep percon.de), einem
Unternehmen von Raritan Computer, im praktischen Einsatz erprobt worden. Die Lösungen sind jedoch
allgemein gültig und lassen sich auch in anderen Meta-Managern oder Access-Devices anwenden.
LDAP-Authentifizierung und -Autorisierung: LDAP definiert ein Protokoll, um einen
Verzeichnisdienst abzufragen, legt jedoch nicht fest, welche Verzeichnisse und Objekte gespeichert
sind. Eine sehr flexible Authentifizierung und Autorisierung lässt sich mit folgenden vier
generellen Objektklassen, die im LDAP-Verzeichnis angelegt werden, realisieren (Bild 2):
1. Benutzer und Gruppen definieren einen Benutzer oder eine Gruppe von Benutzern mit ihren
Eigenschaften wie zum Beispiel den Namen.
2. Geräte und Cluster beschreiben ein konkretes Access-Device mit seinen Eigenschaften wie zum
Beispiel mit der IP-Adresse und einer eindeutigen Identifikationsnummer oder eine logische Gruppe
von Geräten.
3. Profile sind Container zum Speichern von konkreten Zugriffsrechten und Einstellungen. Die
Daten im Profil sind nicht individualisiert. Das heißt, sie gelten nicht für einen bestimmten
Benutzer.
4. Assignments sind die logische Verbindung der drei erstgenannten Entitäten. Dies bedeutet,
dass ein Assignment genau einen Nutzer oder eine Gruppe referenziert, ein Gerät oder einen Cluster
und ein Profil.
Das Recht eines Nutzers, sich an einem bestimmten Access-Device anzumelden, ist dadurch
definiert, dass es mindestens ein Assignment gibt, das diesen Nutzer oder eine seiner Gruppen und
das konkrete Access-Device oder einen seiner Cluster referenziert. Die konkreten Einstellungen und
Rechte des Nutzers bestimmt dann das ebenfalls referenziert Profil. Falls es mehrere Assignments
gibt, sind klare Prioritäten definiert, die vom Speziellen zum Allgemeinen abnehmen.
Mit dieser logischen Anordnung lassen sich sehr effizient typische Szenarien abbilden. Sollen
zum Beispiel Administratoren uneingeschränkten Zugriff zu allen Access-Devices erhalten, so genügt
es, ein Profil mit allen verfügbaren Rechten anzulegen, eine Gruppe Administratoren zu definieren,
in die alle entsprechenden Nutzer eingetragen werden, einen Cluster zu definieren, der alle
Access-Devices enthält und ein Assignment zu erzeugen, das diese drei Entitäten verbindet. Schafft
das Unternehmen danach ein neues Access-Device an, so wird dieses in den Cluster aller Geräte
aufgenommen, und implizit erhalten alle Administratoren darauf Zugriff.
Durch die logische Trennung von Profilen und Nutzern lässt sich einfach realisieren, dass ein
Nutzer unterschiedliche Rechte und Einstellungen auf unterschiedlichen Geräten besitzt.
Sicheres Auffinden und Konfigurieren von Access-Geräten
Ähnlich wie bei der gesicherten elektronischen Kommunikation zwischen Individuen, kommt beim
Binden eines Access-Devices an einen Meta-Manager dem Etablieren eines Vertrauensverhältnisses
zwischen diesen beiden Parteien die wichtigste initiale Rolle zu. Das heißt, der Meta-Manager muss
verifizieren, dass er mit dem richtigen Gerät spricht, und das Gerät muss verifizieren, dass es mit
dem richtigen Meta-Manager kommuniziert. Ist dies sichergestellt, lässt sich der eigentliche
Datenaustausch durch eine Verschlüsselung verbergen. Daher kommen für die Implementierung
etablierte Verfahren der PKI zum Einsatz.
Jedes Access-Device sowie der Meta-Manager besitzen ein asymmetrisches Schlüsselpaar (zum
Beispiel RSA-Schlüssel [6]) mit einem öffentlichen und einem privaten Teil. Damit ist es möglich,
Daten für den jeweils anderen Kommunikationspartner einerseits zu signieren, also die Herkunft der
Daten eindeutig zu belegen, und andererseits die Daten so zu verschlüsseln, dass nur der
beabsichtigte Partner zur Entschlüsslung fähig ist. Voraussetzung ist der Austausch der
öffentlichen Teile der asymmetrischen Schlüsselpaare, der "Public Keys".
Das folgende Beispiels erläutert, wie dies vonstatten geht: In einem Netzwerk befinden sich ein
Meta-Manager, eine Anzahl Access-Devices, die dem Manager bekannt sind, er also ihre Public Keys
kennt. Ins Netz kommt nun ein fabrikneues Access-Device. Der Meta-Manager soll das neue
Access-Device binden und anschließend konfigurieren. Bild 3 stellt die beschriebenen
Lifecycle-Zustände schematisch dar: (1) Das neue Gerät wird an das Netzwerk angeschlossen (Zustand:
Unknown). (2) Der Meta-Manager sendet ein Broadcast-Ping-Paket (Vorgang: "Discover"). Alle
angeschalteten Geräte und das neue unbekannte Gerät senden ein Antwortpaket zurück.
Die Antwortpakete sind signiert. Damit kann der Meta-Manager die Antworten verifizieren und auch
das neue Gerät als solches erkennen und nun als "bekannt" in die Liste der erreichbaren Geräte
aufnehmen (Zustand: Known). (3) Der Manager versucht nun, es zu binden (Vorgang: "Intro"). Er
schickt also seinen Public Key an das Gerät. Dadurch wird es angewiesen nur noch
Konfigurationspakete zu akzeptieren, die mit einer zu diesem Schlüssel passenden Signatur versehen
sind. Ebenso wird der Public Key des Geräts an den Manager übermittelt (Zustand: Bound). Wird
dieser Schlüsselaustausch in einem nicht abgeschlossenen Netzwerk durchgeführt, ist er nicht
sicher. Volle Sicherheit lässt sich innerhalb eines geschlossenen Netzwerks garantieren, das zum
Beispiel mithilfe eines gekreuzten Netzwerkkabels zwischen dem Meta-Manager und dem Gerät
hergestellt wird.
(4) Der Manager hat nun die Kontrolle über das Gerät und kann es durch entsprechend signierte
und verschlüsselte Nachrichten konfigurieren. Darunter fallen zum Beispiel auch die
IP-Konfiguration und das Ändern von Administratorenkennwörtern. Das Access-Device ist bekannt und
konfiguriert (Zustand: Bound).
(5) Bei der Verwendung mehrerer Meta-Manager entsteht die Notwendigkeit, ein Gerät von einem an
einen anderen Manager übergeben zu müssen. Dies lässt sich durch eine vom alten Manager signierte
Übermittlung des Public Keys eines neuen Managers erreichen (Vorgang: "Handover"). Danach ist dem
alten Meta-Manager das Gerät zwar bekannt, er hat jedoch keine Kontrolle darüber (Zustand: Known,
but bound). (6) Das Löschen des Public Keys (Vorgang: "Release") setzt das Gerät in den
selbstkontrollierten Zustand zurück (Zustand: Known).
Zusammenfassung
Die wenigen beschriebenen Szenarien zeigen, dass das Verwalten von Remote-Access-Devices ein
Thema ist, dessen Komplexität sich im Rahmen dieses Artikels nur andeuten lässt. Es reiht sich ein
in das Problem des Verwaltens großer und heterogener Rechnernetzwerke mit vielen Nutzern. Wie
gezeigt ist es folglich möglich, auch die gleichen Lösungsansätze zu verfolgen. Allerdings gilt,
dass konkrete Implementierungen, auch wenn sie im Detail auf Standardprotokolle und -verfahren
aufsetzen, proprietär und untereinander nicht kompatibel sind. Dies erschwert den gemeinsamen
Einsatz von Geräten unterschiedlicher Hersteller.
Dennoch schreiten die Bemühungen um Standardisierung in den dem Meta-Management benachbarten
Themen voran. Dies gilt besonders für das große, hier nicht angesprochene Thema der
Meta-Information, also den Informationen darüber, was von Access-Devices eigentlich wie verwaltet
werden kann. Hier versammelt gegenwärtig die DMTF [7] alle namhaften Hersteller von Rechnern und
Wartungsgeräten, um Industriestandards zu definieren. Insider erwarten, dass sich diese Bemühungen
in Zukunft auch auf das Meta-Management erstrecken werden. Für Interessierte ist es hilfreich, die
in der Literaturliste angegebenen RFCs durchzuarbeiten. News und Links zum Thema stehen auch auf
www.dmtf.org.
Lesen Sie mehr zum Thema
