System- und Sicherheitsmanagement – Besser durch gemeinsame Basis Eine einzige Quelle der Wahrheit

Autor / Redakteur: Georg Lauer, Regional Manager Technology Services / Achim Karpf

Ein einheitlicher Service-orientierte Architekturrahmen verhilft dem System- und Sicherheitsmanagement zu neuer Stärke durch Gemeinsamkeit. Eine herausragende Rolle hierbei übernimmt der Einsatz eines einheitlichen Datenschematas sowie einer einheitlichen Managementdatenbank (MDB) für Management-relevante Informationen, um ein schnelles, konsistentes Management der IT über alle Disziplinen gemäß den Unternehmenserfordernissen und –richtlinien zu etablieren.

Anbieter zum Thema

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 tagtäglich ausgesetzt sind, bedarf es einer flexiblen IT-Infrastruktur, die eine kontinuierliche Anpassung und Innovation der 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 das dazu, dass die Verwaltung von IT-Umgebungen zu einer äußerst personalintensiven Aufgabe wurde. Nur wenige Tools erlauben jedoch das Management aus umfassender Geschäftsprozessperspektive, sondern bieten nur einen eingeschränkten funktionsbezogenen Blick auf das Geschehen.

Solange das Management der eingesetzten IT jedoch Stückwerk bleibt, werden Kosten höher als nötig bleiben und die Unternehmen können nicht den vollen Wert ihrer IT-Ressourcen ausschöpfen. Zugleich droht den Firmen ein potentiell höheres Sicherheitsrisiko aufgrund des „Silo“-Charakters, der bislang das gemeinsame Management der unterschiedlichen Technologien im Unternehmen verhindert oder mindestens behindert. Werden etwa Bestandsdaten und Speicherverwaltungsdaten in unterschiedlichen Datentöpfen geführt, 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. Oder ein Netzwerkmanagementsystem liefert allein Informationen zum Status der sich in Betrieb befindlichen Netzkomponenten und lässt den Administrator im Unklaren über die tatsächliche Kapazitäten im Netz, da ausgeschaltete Systeme nicht angezeigt werden.

Bildergalerie

Jedes Tool und jede Managementdisziplin nutzt eigene Datenschemata und -basen. 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. Management-Daten zu vergleichbaren Sachverhalten werden von verschiedenen Tools in abweichender Ausprägung und zu unterschiedlichen Zeitpunkten erhoben, so dass sich die Frage nach Aktualität und Qualität der Informationen nicht entscheiden lässt. Diese sind für anstehende Herausforderungen wie eine umfassende Performance-, Risiko – oder Zugriffssteuerung aufgrund der eingeschränkten Aussagekraft mehr oder minder nutzlos. Bereits die Beantwortung von Fragen nach den Nutzern 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.

Die missliche Lage führt schlussendlich zu dem Bedarf nach einer umfassenden, integrierten Sicht und einer einzigen Quelle der (Management-) Wirklichkeit (single source of truth). Denn wer nicht weiß, wie seine IT-Landschaft aussieht, kann diese im Grunde nicht managen. Wer seine Umgebung nicht managen kann, kann ihre Zusammensetzung nicht modellieren, kann diese nicht sichern und nicht das Optimum an Verfügbarkeit und Performance aus den IT-Ressourcen herausholen.

Single source of truth gesucht

Einen ersten Ansatz für eine solchen single source of truth liefert das Modell der Konfigurationsdatenbank (CMDB), wie es ITIL als zentralen Bestandteil aller Aufgaben des Service-bezogenen Managements postuliert. Mit Informationen zu Aufbau, Abhängigkeiten, Historie der IT-Ressourcen einschließlich Änderungen, Fehler, Störfälle bildet sie den Kern vieler ITIL-Prozesse, etwa Konfigurationsverwaltung, Kapazitätssteuerung oder Risikomanagement. ITIL definiert die CMDB in diesem Kontext als eine Kollektion so genannter Configuration Items (CI), wobei diese neben den reinen Ressourcen ebenso die Beziehungen innerhalb einer IT-Umgebungen umfassen.

Die Frage der Implementierung einer CMDB wird indes offen gelassen. 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 Art virtuelle Schicht über die datensammelnden Quellen spannen und durch Einsatz von Konnektoren oder Middleware-Software in einer logischen Datenbank bzw. eine Art Konfigurations-Data-Warehouse (so genannte federated CMDB) zusammenführen. Neben den hohen Maintenance-Anforderungen 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 zudem Konfliktsituationen, die entstehen, weil unterschiedliche Managementanwendungen widersprüchliche Informationen zur Verfügung stellen und die CMDB mit der Bewertungsfrage alleine lassen.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zur IT-Sicherheit

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

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 mit Hilfe service-orientierter Architekturen (SOA) umsetzen lässt. Es liegt deshalb nahe, dass im Bereich des Systemsmanagements künftig das SOA-Modell ebenfalls die Rolle als dominierende Softwarearchitektur einnimmt.

Zum Beispiel folgt die Enterprise IT Management (EITM)-Vision von CA dem Grundprinzip der service-orientierten Architektur und bietet den einzelnen Managementanwendungen eine Integrationsplattform (Grafik 1) gemeinsam nutzbare Services. Sämtliche Komponenten greifen hier auf das gleiche einheitliche Datenmodell zurück und nutzen als Repository für Managementinformationen eine zentrale Management-Datenbank (MDB). Eine solche MDB unterstützt die Erkennung und Inventarisierung aller Hard- und Software, die Verwaltung von Nutzerrechten und die Definition von Richtlinien. Sie unterstützt die Umsetzung des CMDB-Konzeptes, ist im Anspruch und Leistungsumfang jedoch deutlich breiter angelegt , da sie einen vollständigen Managementsatz zu IT-Ressourcen aus den verschiedenen Management-Disziplinen zentral bündelt und so zur single source of truth wird.

Ein Datenschema

Dieser einheitliche Blick auf die „Management-Wahrheit“ wird durch die Nutzung eines einzigen, integrierten Datenbank-Schema für die Speicherung realisiert, das einen vollständigen Satz an Managementdaten und deren Beziehungen (Grafik 2) umfasst. Ein solches Schema führt im Vergleich zur Zusammenarbeit auf API-Ebene den unschätzbaren Vorteil, dass die Integrationsaufgabe quasi schon erledigt ist, da ein neues Tool nahtlos die Managementinformationen aus der MDB nutzen bzw. neue Informationen hineinschreiben kann. 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 (Grafik 3). Denn diese prägt die Genauigkeit und Vollständigkeit der Managementinformationen. Genauigkeit deshalb, weil Discovery-Tools häufig verschiedene Methoden nutzen, eine Ressource zu entdecken oder unterschiedliche Tools verschiedene Resultate liefern.

Mit dem „Asset registry“-Verfahren verfolgt die MDB ein gleichermaßen einfaches wie eindeutiges Konzept. Die Idee lautet, dass jedes Bit an Information einer CI über das Schema in eine einzige DB-Entität zusammengeführt wird. Wird eine neue Konfiguration entdeckt, wird ein Registrierungsprozess angestoßen und ein Zentralregister vergibt eine eindeutige ID. Stellt der Registratur-Algorithmus jedoch fest, dass der Gegenstand bereits registriert ist, ist diese ID ein 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 ebenso wie diese die nun neu hinzugekommenen Daten nutzen können.

Die Stärken einer solchen CI-Identität-Behandlung im Vergleich zu den ansonsten häufig genutzten Daten-Mapping beim Einsatz mehrerer Werkzeug-bezogener Datenquellen bewähren sich insbesondere in hochdynamischen IT-Infrastrukturen. Bei der Nutzung von Virtualisierungslösungen wie VMware oder Virtual PC kann ein Desktop beispielsweise mehrere Identitäten mit unterschiedlichen DNS-Namen haben. Es kann nun aus Administrationsgründen zunächst Sinn machen, diese als eine einzige Konfiguration zu behandeln. Falls nun zu einem späteren Zeitpunkt eine Trennung der Identitäten beabsichtigt wird, weil aufgrund Performance- oder Sicherheitsüberlegungen bestimmte Anwendungen nun auf einem eigenen physischen Desktop ablaufen sollen, lässt sich mit Hilfe des „Asset registry“-Verfahren einfach 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 Daten-Schemata eliminiert Redundanzen und reduziert den Aufwand für Administration bzw. Wartung. Beispielsweise können widersprüchliche Situationen, wie Eingangs beschrieben, erst gar nicht auftreten, da hier alle Daten einheitlich und eindeutig sind. Dateneinträge erfolgen simpel durch einen konsistenten Prozess und standardkonformen Interfaces (u.a. XML), Probleme unsynchronisierter Datenbankeinträge sind damit von vorneherein unterbunden.

Im Unterschied zu anderen Ansätzen, die aus den Datenbanken der unterschiedlichen Werkzeugen eine neue, eigene zentrale Sicht herausfiltern und montieren, stehen in der MDB stets die aktuellen „echten“ Managementinformationen zur Verfügung. Und da man für den Betrieb der MDB auf leistungsstarke relationale Datenbanksysteme wie Ingres zurückgreift, stehen zugleich eine Fülle bewährter Integrations- und Verteilkonzepte wie Two-Phase-Commit, Replikations- und Stern-Funktionen für verteilte Implementationen (Grafik 4) bereit. Mit Hilfe von Konnektoren und Adaptoren lassen sich des Weiteren so genannten „Hub and Spoke“-Infastrukturen aufbauen, die vorhandene Managementdatenbanken in einem ersten Schritt unter einer führenden MDB einbinden, um sie gegebenenfalls in einem zweiten Schritt durch das führende System komplett zu ersetzen.

Der große Nutzen einer MDB ist, dass sie Informationen zu IT-Ressourcen aus den verschiedenen Management-Disziplinen zentral zu bündeln. Die Verbindung zwischen den Daten muss nicht mehr mühselig und zeitaufwändig erst hergestellt werden. Startet beispielsweise ein Netzwerkmanagementsystem einen Discovery-Lauf und registriert einen Gegenstand, kann umgehend das Asset-Management veranlasst werden einen Agenten auszulösen, um ein vollständiges Hardware- und Software-Verzeichnis zu erhalten. Wird nun ein Vorfall aufgezeichnet und der Service-Desk informiert, lassen sich 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 User als auch zusätzliche potenzielle Risiken aufgrund nachgelagerter Verbindungen.

Ein solches Zusammenspiel auf der Ebene der Managementwerkzeuge lässt sich zu kompletten, einem Geschäftsprozess begleitenden Workflows ausbauen. Sollen beispielsweise alle PC-Anwendungen aus Sicherheitsgründen auf einen neuen, einheitlichen Patch-Stand gebracht werden, liefert die MDB ein vollständiges Abbild über tatsächlichen Nutzen und Release-Stand. Diese Informationen lassen sich im nächsten Schritt mit der kaufmännischen Bestandsführung bzw. Anlagen-management und Daten aus dem User-Management als auch Personalmanagement abgleichen. Diese Kombination schafft Transparenz über Situation im Unternehmen („Das wurde beschafft“, „Das ist implementiert“, „Das wird genutzt“, „Dieser Personenkreis soll die Anwendung nutzen“ etc.) und schafft so ein genaues Bild, ob zuvor 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 hiermit endlich ein tragfähiges Fundament existiert, die Administration der IT-Ressourcen an den geschäftlichen Abläufen auszurichten, um die unternehmensweiten Einflüsse der IT auf die Geschäftsprozesse zu überwachen und zu optimieren. Die Auflösung der isolierten Betrachtung und der verschiedenen Daten-Silos 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.

Artikelfiles und Artikellinks

(ID:2000915)