Regulatorische Anforderungen erfüllen Abbildung von Cloud-Ressourcen in der CMDB

Anbieter zum Thema

adesso SE

netfiles GmbH

Cloudgermany.de GmbH

Unternehmen verlagern mehr und mehr Infrastruktur und Applikationen in die Cloud. Sollten sie diese Cloud-Ressourcen in der Configuration Management Database (CMDB) abbilden oder nicht? Welche Folgen hat es, wenn sie dies nicht tun?

Werden Cloud-Ressourcen nicht in der CMDB abgebildet, entsteht bei der Migration ein immer größer werdender blinder Fleck im IT-Service Management. Incidents, Service Requests und Requests for Change (RfC) können den Cloud-Ressourcen nicht mehr zugeordnet werden, weil sie als Configuration Items (CI) nicht mehr vorhanden sind. Auswertungen der CMDB, zum Beispiel zu Incident-Häufigkeiten, beinhalten nur noch den On-Premises-Teil der IT-Gesamtumgebung und geben damit ein verfälschtes Bild.

In einer CMDB werden nach ITIL 4 Definition Datensätze über Configuration Items (CI) während ihres Lebenszyklus gespeichert und deren Beziehungen untereinander gepflegt. Dabei wird als CI jede Komponente verstanden, die zur Erbringung eines IT-Service verwaltet werden muss. Da dies auch für Cloud-Ressourcen gilt, wäre die Frage nach der Notwendigkeit ihrer Abbildung in der CMDB an sich schon geklärt.

Letztlich kommt es aber darauf an, den Mehrwert der Informationen für die Stakeholder gegen die Kosten für deren Beschaffung und Pflege abzuwägen. ITIL 4 gibt in der Beschreibung der Praktik Service Configuration Management keine Empfehlung für oder gegen die Abbildung von Cloud-Objekten in einer CMDB ab. Vielmehr gebe es dazu keine richtige oder falsche Antwort. Die Praktik sei nur in dem Maße wertvoll, wie die von der CMDB bereitgestellten Informationen zutreffend, aktuell, verlässlich, verständlich, einfach zu nutzen und relevant sind.

Was passiert, wenn die CMDB Cloud-Ressourcen nicht abbildet?

Wesentliche Zwecke der Informationen in einer CMDB sind unter anderem die Analyse von Ursache und Wirkung und die Auswirkungsanalyse. Wenn Cloud-Ressourcen in der CMDB fehlen, sind diese Analysen unvollständig, laufen ins Leere oder führen in die falsche Richtung. Abhängigkeiten lassen sich nicht mehr vollständig erkennen, wenn ein Teil der an einem IT-Service beteiligten Komponenten in der CMDB nicht mehr sichtbar ist.

Die fehlende Zuordnung von Cloud-Ressourcen zu Incidents, Problems und RfC, erschwert die Kategorisierung und das Routing dieser Tickets an die richtigen Supporteinheiten und verlangsamt so die betroffenen IT Service Management Prozesse.

In den Bankaufsichtlichen Anforderungen an die IT (BAIT) und verwandten Anforderungen (xAIT) fordert die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin), die Komponenten der IT-Systeme und deren Beziehungen zueinander in geeigneter Weise zu verwalten und die hierzu erfassten Bestandsangaben regelmäßig sowie anlassbezogen zu aktualisieren. Dort wird auch definiert, welche Bestandsangaben erfasst werden müssen. D.h. eine fehlende Abbildung von Cloud-Ressourcen in der CMDB verletzte in diesem Fall regulatorische Anforderungen.

Welche Möglichkeiten der Abbildung gibt es in der Theorie?

Wenn nun Cloud-Ressourcen in der CMDB abgebildet beziehungsweise verfügbar gemacht werden sollen, müssen sich die Verantwortlichen zunächst Gedanken über den Grad der Vollständigkeit der Abbildung machen. Das heißt, sie müssen sich überlegen, welche Ressourcentypen (zum Beispiel virtuelle Maschinen, Datenbanken, virtuelle Netze) in der Cloud sie in der CMDB abbilden wollen.

Um den Aufwand der Abbildung zu reduzieren, können sich die Beteiligten beispielsweise auf die Auswahl der Ressourcentypen beschränken, die tatsächlich eingesetzt werden, statt alle bei dem Cloud-Provider verfügbaren Ressourcentypen abzubilden.

Nach der Auswahl der Ressourcentypen ist die nächste Überlegung, welche Attribute der jeweiligen Ressourcentypen in der CMDB abgebildet werden sollen. Das kann im einfachsten Fall nur die ID des Objekts beim Cloud-Provider sein oder alle dort zu dem Objekt gespeicherten Informationen. Für eine Zuordnung des Objekts zu Incidents, Problems oder RfC ist das aber nicht erforderlich. Hier reichen die ID und gegebenenfalls der Name, um das Objekt zuordnen zu können. Dies genügt auch für die Abbildung von Abhängigkeiten zwischen den Cloud-Ressourcen und anderen CI, denn dafür muss das Objekt nur in der CMDB vorhanden sein. Ermitteln lassen sich die Abhängigkeiten zum Teil aber nur durch die Übernahme weiterer Attribute, etwa der Resource Group, der die Cloud-Ressource zugeordnet ist. Andere Abhängigkeiten wie Schnittstellen müssen in der CMDB manuell hinzugefügt werden.

Auch für die Abbildung von Informationen über den Lebenszyklus der Cloud-Ressourcen müssen eventuell weitere Attribute des Ressourcentyps abgefragt werden. Dies kann aus Audit- und regulatorischer Sicht inklusive einer Historisierung erforderlich sein.

Als letztes bleibt zu bedenken, ob Daten zu allen existierenden Cloud-Ressourcen eines Typs übertragen werden sollen. So werden beispielsweise virtuelle Maschinen, die zum Zwecke des Autoscalings in einer Gruppe zusammengefasst sind, nach Bedarf automatisch erzeugt und weggeworfen. Das heißt, Incidents, Problems oder RfC sollten sich nur auf diese Gruppe, nicht aber auf die virtuellen Maschinen beziehen, die sie enthält. Daher ist davon abzuraten, die virtuellen Maschinen aus der Gruppe selbst als CI aufzunehmen. Ähnlich verhält es sich für Nodes eines Kubernetes Clusters.

Kriterien für die Übernahme

Es ist entscheidend, Kriterien zu definieren, anhand derer sich eine Entscheidung zum Grad der Abbildung von Cloud-Ressourcen in der CMDB treffen lassen. Das könnten auf Basis des ITIL Practice Guide beispielsweise sein:

• Gibt es andere Quellen, in denen die Information verfügbar ist?

• Welchen Einfluss hat die Information auf die Entscheidungsfindung (kritisch oder optional)?

• Welche Kosten entstehen für die Aufnahme der Information in die CMDB (initial und dauerhaft)?

• Wie oft wird diese Information benötigt oder abgefragt?

• Wie schnell muss die Information verfügbar sein?

• Wie aktuell muss die Information sein?

Art der Übernahme der Daten in die CMDB

Grundsätzlich wäre es natürlich möglich, die Daten für die Cloud-Ressourcen manuell in der CMDB zu erfassen. Das ist aber aufgrund der hohen Anzahl und Änderungshäufigkeit für die meisten Ressourcentypen nicht praktikabel. Denkbar wäre es aber für relativ feststehende Ressourcentypen wie Azure Management Groups, sie manuell in der CMDB zu erfassen.

Wenn der Cloud-Provider eine entsprechende API anbietet, wie es Microsoft mit der REST-API für den Zugriff auf den Azure Resource Graph macht, kann diese genutzt werden, um zeitgesteuert oder eventgesteuert die Daten zu übertragen. Wenn zu Beginn definiert wurde, dass nur die Cloud-Ressourcen relevant sind, die über eine IP-Adresse erreichbar sind, lassen sich mit den auch on-premises eingesetzten Discovery-Tools in den beim Cloud-Provider betriebenen Netzen nach IP-Adressen suchen und Informationen von den Systemen ermitteln, die an diesen IP-Adressen horchen.

Sofern das ITSM-Tool und der Cloud-Provider dies unterstützen, ist es zudem denkbar, die Daten erst in dem Moment beim Cloud-Provider abzufragen, in dem im ITSM-Tool auf die Information zugegriffen wird. Die Daten zu den Cloud-Ressourcen würden also nicht in der CMDB gespeichert, sondern wären nur von dort aus zugreifbar. Das Ergebnis: eine föderierte CMDB.

CMDB vs. Asset Register

Von der CMDB zu unterscheiden sind Asset Register, in denen alle werthaltigen Komponenten der IT (IT-Assets) gespeichert werden. Gleichwohl wird die CMDB häufig zumindest für einen Teil der IT-Assets als Asset Register genutzt, etwa für Notebooks und Smartphones.

Was ist sonst noch zu beachten?

Die Ressourcen sollten bei dem Cloud-Provider über Tags immer einem Service beziehungsweise einer Applikation zugeordnet werden. Wenn diese Tags als Attribute in die CMDB übertragen werden, erlaubt dies dort eine bessere Verknüpfung und Auswertbarkeit.

Bestimmte Abhängigkeiten werden vom Cloud Provider verborgen und sind, anders als im On-Premises-Betrieb, nicht mehr bekannt. Ein Beispiel ist die Beziehung virtueller Maschinen zu physischen Servern, auf denen sie laufen. Da die Verantwortlichkeit für diese Beziehung auf den Cloud-Provider übergegangen ist, ist diese Information in der CMDB aber auch nicht mehr notwendig.

Fazit

Die Abbildung von Cloud-Ressourcen in der CMDB ist grundsätzlich sinnvoll. Es hängt aber von den Bedürfnissen und der konkreten Situation des Unternehmens ab, ob und in welchem Umfang die Abbildung umgesetzt werden sollte. Dabei kommt es auf die Abwägung zwischen dem Nutzen an, den die Abbildung in der CMDB für die ITSM-Prozesse hat, und den Kosten, die die Bereitstellung der Informationen in der CMDB verursacht.

(ID:50051147)