System- und Sicherheitsmanagement
Besser durch gemeinsame Basis
Ein einheitlicher serviceorientierter Architekturrahmen verhilft dem System- und Sicherheitsmanagement durch Gemeinsamkeit zu neuer Stärke. Eine herausragende Rolle hierbei übernimmt der Einsatz eines einheitlichen Datenschemas sowie einer einheitlichen Managementdatenbank (MDB). Ziel ist es, ein schnelles, konsistentes Management über alle IT-Disziplinen gemäß den Unternehmenserfordernissen und -richtlinien zu etablieren.
Die aktuellen Herausforderungen an einen IT-Verantwortlichen sind schnell benannt: Er soll mit
der IT das Geschäft seines Unternehmens optimal unterstützen. Angesichts des dynamischen Wandels,
dem Firmen täglich ausgesetzt sind, bedarf es einer flexiblen IT-Infrastruktur, die eine
kontinuierliche Anpassung an die Geschäftsprozesse problemlos stemmt. Managementlösungen müssen in
der Lage sein, diese Infrastrukturen optimal auszunutzen – und dies ohne Kompromisse in Bezug auf
Sicherheit und Verfügbarkeit. Das alles mündet letztlich in der Forderung, die IT-Ressourcen aus
der Perspektive der Geschäftsprozesse managen und verwalten zu können.
Die CIOs kämpfen indes gegen die Komplexität historisch gewachsener Infrastrukturen, in denen
die verschiedenen Hersteller, Plattformen, Anwendungen und Standards vertreten sind. Kombiniert mit
der Fragmentierung herkömmlicher Managementsysteme führte dies dazu, dass die Verwaltung von
IT-Umgebungen zu einer äußerst personalintensiven Aufgabe geriet. Nur wenige Tools erlauben jedoch
das Management aus umfassender Geschäftsprozessperspektive, die meisten bieten nur einen
eingeschränkten funktionsbezogenen Blick auf das Geschehen.
Solange das Management der eingesetzten IT jedoch Stückwerk bleibt, werden Kosten höher
ausfallen als nötig, und die Unternehmen können den vollen Wert ihrer IT-Ressourcen nicht
ausschöpfen. Zugleich droht den Unternehmen ein höheres Sicherheitsrisiko aufgrund des
Silocharakters der IT, der bislang das gemeinsame Management unterschiedlicher Techniken im
Unternehmen verhindert oder zumindest behindert. Denn viele Unternehmen führen zum Beispiel
Bestandsdaten und Speicherverwaltungsdaten in unterschiedlichen Datentöpfen. Hier lässt sich für
einen im Rahmen des automatischen Discovery registrierten Server nicht verlässlich bestimmen, ob
und wann bereits Backup-Prozeduren eingerichtet und durchgeführt wurden. Ein weiteres Beispiel: Ein
Netzwerkmanagementsystem liefert allein Informationen zum Status der im Betrieb befindlichen
Netzkomponenten, lässt den Administrator aber im Unklaren über die tatsächlichen Kapazitäten im
Netz, denn es zeigt ausgeschaltete Systeme nicht an.
Jedes Tool und jede Managementdisziplin nutzt eigene Datenschemata und -banken. Der
Nachrichtenaustausch zwischen den einzelnen Administrationsaufgaben findet allenfalls auf dem
kleinsten gemeinsamen Nenner statt, da das erforderliche, zeitaufwändige Mapping nicht ohne
Informationsverlust vonstatten geht. Die verschiedenen Tools erheben Managementdaten zu
vergleichbaren Sachverhalten in abweichender Ausprägung und zu unterschiedlichen Zeitpunkten. So
lässt sich die Frage nach der Aktualität und Qualität der Informationen nicht beantworten. So sind
diese Informationen aufgrund eingeschränkter Aussagekraft für anstehende Herausforderungen wie eine
umfassende Performance-, Risiko- und Zugriffssteuerung kaum verwendbar. Bereits die Beantwortung
von Fragen nach den Benutzern der vor Monaten angeschafften Laptops, nach einer
Über-/Unterlizenzierung oder nach dem kontinuierlichen Einspielen von Sicherheits-Updates lässt
sich bestenfalls mit viel Engagement und Zeit der Administratoren bewerkstelligen.
Eine einzige Quelle der Wahrheit
Die missliche Lage führt schließlich zu Bedarf an einer umfassenden, integrierten Sicht und
einer einzigen Quelle der (Management-)Wirklichkeit (im Englischen "Single Source of Truth"
genannt). Denn wer nicht weiß, wie seine IT-Landschaft aussieht, kann sie im Grunde nicht managen.
Somit kann er ihre Zusammensetzung nicht modellieren, diese nicht sichern und nicht das Optimum an
Verfügbarkeit und Performance aus IT-Ressourcen herausholen.
Einen ersten Ansatz für eine solche Single Source of Truth liefert das Modell der
Konfigurationsdatenbank (CMDB), wie es die Best-Practice-Sammlung ITIL (IT Infrastructure Library)
als zentralen Bestandteil aller Aufgaben des IT-Service-Managements postuliert. Mit Informationen
zu Aufbau, Abhängigkeiten und Historie der IT-Ressourcen einschließlich Änderungen, Fehler,
Störfälle bildet sie den Kern vieler ITIL-Prozesse, zum Beispiel für Konfigurationsverwaltung,
Kapazitätssteuerung oder Risikomanagement.
ITIL definiert die CMDB in diesem Kontext als eine Sammlung so genannter Configuration Items
(CIs). Diese CIs umfassen neben den reinen Ressourcen ebenso die Beziehungen innerhalb einer
IT-Umgebung. Die Frage der Implementierung einer CMDB lässt das Regelwerk indes offen: Prinzipiell
ist es sogar möglich, alle CI-Informationen in einer Excel-Tabelle zu führen. Häufig anzutreffen
sind Lösungsansätze, die anwendungsbezogen eine virtuelle Schicht über die Daten sammelnden Quellen
spannen, um sie durch Einsatz von Konnektoren oder Middleware in einer logischen Datenbank oder
eine Art Konfigurations-Data-Warehouse (einer so genannten Federated CMDB) zusammenzuführen.
Neben den hohen Wartungsanforderungen gereicht diesem Implementierungsansatz insbesondere bei
umfangreichen Infrastrukturen zum Nachteil, dass die eingangs beschriebenen Probleme nicht
grundsätzlich gelöst sind. Falls eine Anwendung A aufgespürten Netzkomponenten eine Nummer zuordnet
und eine Anwendung B dieses über die MAC-Adresse identifiziert, muss die CMDB auf Anwendungsseite
erkennen, dass es sich hier um dieselbe Komponente handelt. Noch komplizierter und gefährlicher
sind Konfliktsituationen, die entstehen, wenn unterschiedliche Managementanwendungen
widersprüchliche Informationen zur Verfügung stellen und die CMDB mit der Bewertungsfrage allein
lassen.
SOA-Modell
Die beschriebene Problematik, deren Ursache in der Bevorratung von Informationen in
unterschiedlichen Datentöpfen liegt, erlaubt durchaus eine Parallele zu den aktuellen
Herausforderungen auf dem Terrain der Unternehmenssoftware. Unter Experten herrscht weithin
Einigkeit, dass sich die hier erhobene Forderung nach Flexibilitäts- und Integrationsvermögen
allein mithilfe einer serviceorientierten Architektur (SOA) umsetzen lässt. Es liegt deshalb nahe,
dass das SOA-Modell im Systemma-nagement künftig ebenfalls die Rolle einer dominierenden
Softwarearchitektur einnimmt.
Zum Beispiel folgt das Konzept des Enterprise-IT-Managements (EITM) dem Grundprinzip der
serviceorientierten Architektur und bietet den einzelnen Managementanwendungen über eine
Integrationsplattform (Bild) gemeinsam nutzbare Services. Sämtliche Komponenten greifen hier auf
das gleiche einheitliche Datenmodell zurück und nutzen als Repository für Managementinformationen
eine zentrale Managementdatenbank. Eine solche MDB unterstützt die Erkennung und Inventarisierung
aller Hard- und Software sowie die Verwaltung von Nutzerrechten und die Definition von Richtlinien.
Sie unterstützt die Umsetzung des CMDB-Konzepts, ist im Anspruch und Leistungsumfang jedoch
deutlich breiter angelegt, da sie einen vollständigen Managementsatz zu IT-Ressourcen aus den
verschiedenen Managementdisziplinen zentral bündelt und somit als Single Source of Truth dient.
Einheitliches Datenschema
Dieser einheitliche Blick auf die "Managementwahrheit" ergibt sich durch die Nutzung eines
einzigen, integrierten Datenbankschemas für die Speicherung. Dieses Schema umfasst einen
vollständigen Satz an Managementdaten und deren Beziehungen. Ein solches Schema birgt im Vergleich
zur Zusammenarbeit auf API-Ebene den unschätzbaren Vorteil, dass die Integrationsaufgabe praktisch
schon erledigt ist: Ein neues Tool kann die Managementinformationen aus der MDB nahtlos verwenden
und neue Informationen in die MDB hineinschreiben. Im Idealfall sucht ein Werkzeug bei der
Inbetriebnahme eine bereits vorhandene MDB, um sie als eigene Datenbank mitzunutzen.
Eine der größten Herausforderungen in diesem Kontext betrifft ähnlich wie bei der oben erwähnten
CMDB-Implementierung die Behandlung der CI-Identität. Denn diese Behandlung prägt die Genauigkeit
und Vollständigkeit der Managementinformationen, da Discovery-Tools häufig verschiedene Methoden
nutzen, um eine Ressource zu entdecken, und unterschiedliche Tools verschiedene Resultate
liefern.
Mit dem so genannten "Asset-Registry"-Verfahren verfolgt eine MDB ein gleichermaßen einfaches
wie eindeutiges Konzept. Die Idee lautet, dass jedes Bit an Information einer CI über das Schema in
eine einzige Datenbankentität zusammengeführt wird. Wird eine neue Konfiguration entdeckt, läuft
ein Registrierungsprozess an, und ein Zentralregister vergibt eine eindeutige ID. Stellt der
Registrierungsalgorithmus jedoch fest, dass der Gegenstand bereits registriert ist, bildet diese ID
einen Link zu der bereits in der MDB geführten Konfiguration. Auf diese Weise hat die Anwendung
sofort Zugriff auf die von anderen Applikationen erzeugten Managementinformationen. Umgekehrt
können diese nun die neu hinzugekommenen Daten nutzen.
Alternative zum Mapping
Im Vergleich zum ansonsten häufig genutzten Daten-Mapping beim Einsatz mehrerer Tool-bezogener
Datenquellen bewähren sich die Stärken einer solchen Behandlung der CI-Identität insbesondere in
hoch dynamischen IT-Infrastrukturen. Bei der Nutzung von Virtualisierungslösungen wie Vmware oder
Virtual PC kann ein Desktop beispielsweise mehrere Identitäten mit unterschiedlichen DNS-Namen
aufweisen. Es ist nun mitunter aus Administrationsgründen sinnvoll, diese als eine einzige
Konfiguration zu behandeln. Falls der Administrator später eine Trennung der Identitäten
beabsichtigt, weil auf Grund von Performance- oder Sicherheitsüberlegungen bestimmte Anwendungen
auf einem eigenen physischen Desktop ablaufen sollen, lässt sich mithilfe des
Asset-Registry-Verfahren eine weitere CI-ID im Register einführen. Es ist also nicht erforderlich,
sämtliche Tabellen von Managementinformationen durchzugehen und eine neue Referenz einzutragen.
Die Behandlung der Integration auf Datenebene durch die MDB mit einheitlichem, erweiterbarem
Datenschemata vermeidet Redundanzen und senkt den Aufwand für Administration und Wartung.
Beispielsweise können eingangs beschriebene widersprüchliche Situationen erst gar nicht auftreten,
da alle Daten einheitlich und eindeutig sind. Dateneinträge erfolgen simpel durch einen
konsistenten Prozess und standardkonforme Interfaces (unter anderem XML). Dies unterbindet Probleme
durch unsynchronisierte Datenbankeinträge von vornherein.
Im Unterschied zu anderen Ansätzen, die aus den Datenbanken der unterschiedlichen Werkzeuge eine
neue, eigene zentrale Sicht herausfiltern und montieren, stehen in der MDB stets die aktuellen
echten Managementinformationen zur Verfügung. Und da der Betrieb der MDB auf leistungsstarke
relationale Datenbanksysteme zurückgreift, steht zugleich eine Fülle bewährter Integrations- und
Verteilkonzepte bereit, darunter Two-Phase-Commit, Replikations- und Sternfunktionen für verteilte
Implementierungen. Mithilfe von Konnektoren und Adaptern lassen sich "Hub-and-Spoke"-Infastrukturen
aufbauen, die vorhandene Managementdatenbanken unter einer führenden MDB einbinden, um sie
gegebenenfalls anschließend komplett durch das führende System zu ersetzen.
Aktuelle Managementinformationen
Der große Nutzen einer MDB liegt darin, dass sie Informationen zu IT-Ressourcen aus den
verschiedenen Managementdisziplinen zentral bündelt. Die IT-Abteilung muss die Verbindung zwischen
den Daten nicht mehr erst mühselig und zeitaufwändig herstellen. Startet beispielsweise ein
Netzwerkmanagementsystem einen Discovery-Lauf und registriert einen Gegenstand, kann das
Asset-Management umgehend einen Agenten anstoßen, um ein vollständiges Hardware- und
Softwareverzeichnis zu erhalten. Wird nun ein Vorfall aufgezeichnet und der Service-Desk
informiert, können die Mitarbeiter sofort sämtliche Assets einschließlich der Inventarinformationen
überprüfen. Registriert das Auditing/Monitoring ungewohnte Ereignisse oder Ausfälle, hat die
Administration sofort den Überblick über betroffene Ressourcen und Anwender sowie über zusätzliche
Risiken aufgrund nachgelagerter Verbindungen. Ein solches Zusammenspiel auf der Ebene der
Managementwerkzeuge lässt sich zu kompletten Workflows ausbauen, die einen Geschäftsprozess
begleiten. Soll die IT-Abteilung beispielsweise alle PC-Anwendungen aus Sicherheitsgründen auf
einen neuen, einheitlichen Patch-Stand bringen, liefert die MDB ein vollständiges Abbild über die
tatsächliche Nutzung und den Release-Stand. Diese Informationen lassen sich im nächsten Schritt mit
der kaufmännischen Bestandsführung und dem Anlagenmanagement sowie mit Daten aus dem User- und
Personalmanagement abgleichen. Diese Kombination schafft Transparenz über die Situation im
Unternehmen: Was wurde beschafft, was implementiert, was genutzt, welcher Personenkreis soll die
Anwendung benutzen etc.? Dies erzeugt ein genaues Bild, ob noch ein Nachrüstbedarf für
Software-Releases besteht, um zunächst einen einheitlichen Release-Stand zu realisieren. Nach
Feststellung der Notwendigkeit, erfolgter Bestellung und Wareneingang lassen sich dann im Rahmen
der Implementierung automatisch die notwendigen Prozesse für Inventarisierung und
Identitätsmanagement anstoßen.
Fazit
Das Konzept einer SOA-konformen Integrationsarchitektur einschließlich MDB ist noch recht jung.
Aber bereits jetzt zeichnet sich ab, dass damit ein tragfähiges Fundament existiert, um die
Administration der IT-Ressourcen an den geschäftlichen Abläufen auszurichten und die
unternehmensweiten Einflüsse der IT auf die Geschäftsprozesse zu überwachen und zu optimieren. Die
Auflösung der isolierten Betrachtung und der verschiedenen Datensilos führt letztlich dazu, dass
die IT-Administration in Unternehmen ein betriebswirtschaftlich kontrolliertes, risikominimierendes
Führungsinstrument wird und nicht mehr nur als ungeliebter, nicht transparenter Kostenblock
dasteht.
Lesen Sie mehr zum Thema
