Welche Kundensysteme betreiben wir eigentlich? Asset Management für IT-Dienstleister

Der Terminalserver eines Kunden fällt wieder aus. Das Incident-Ticket ist schnell eröffnet. Nur steht darin: „Terminalserver Kunde Müller nicht erreichbar.“

Welcher Terminalserver ist gemeint? Der Kunde hat drei. Gehört das Betriebssystem zu unserem Managed Service oder betreuen wir nur die darauf laufende Fachanwendung? Spielen wir dort Updates ein? Läuft der Server in unserer Infrastruktur, beim Kunden oder bei einem weiteren Dienstleister? Sichern wir die ganze Maschine, nur bestimmte Daten oder gar nichts? Und dürfen wir ihn einfach neu starten?

Ein Mitarbeiter kennt die Umgebung seit zwölf Jahren und weiß das alles. Leider ist er gerade auf Mallorca und antwortet im Urlaub auffällig selten auf Teams-Nachrichten.

Das Problem ist nicht bloß eine unvollständige Inventarliste. Der IT-Dienstleister weiß nicht zuverlässig, welche Objekte er für den Kunden betreibt, in welcher Konfiguration und mit welcher Verantwortung. Damit bleibt eine Hälfte des Wortes „Betrieb“ undefiniert.

Die kurze Antwort

Ein steuerbarer Kundenbetrieb braucht Antworten auf zwei unterschiedliche Fragen:

1. Was tun wir für den Kunden? Das klären Servicekatalog, Vertrag und Betriebsführungshandbuch.
2. Woran tun wir es? Das klären Asset- und Configuration-Management: Welche Systeme, Anwendungen, Netze, Konten und weiteren Bestandteile gehören zur betreuten Umgebung? Wie sind sie konfiguriert, wovon hängen sie ab und wo endet unsere Zuständigkeit?

Für ISO 27001 ist diese zweite Frage keineswegs Kleinkram. Wer Kunden-IT betreibt, muss seine sicherheitsrelevanten Betriebsprozesse steuern können. Das funktioniert schlecht, wenn Systeme nur als „der Server bei Müller“ bekannt sind und wichtige Konfigurationen im Gedächtnis einzelner Mitarbeiter wohnen.

Sie brauchen dafür nicht automatisch eine riesige Datenbank. Sie brauchen eine verlässliche Sicht auf die betreuten Kundenumgebungen – so detailliert, dass Ihre Mitarbeiter richtige Entscheidungen treffen können.

Betrieb hat zwei Dimensionen

IT-Dienstleister sprechen gern davon, dass sie für einen Kunden „die IT betreiben“. Dieser Satz klingt größer, als sein Informationsgehalt ist.

Die erste Dimension sind die Tätigkeiten: überwachen, patchen, sichern, wiederherstellen, Benutzer anlegen, Störungen beheben oder Anwendungen aktualisieren. Welche dieser Leistungen angeboten und beauftragt sind, gehört in die Service- und Vertragswelt.

Die zweite Dimension sind die betroffenen Objekte: Server, virtuelle Maschinen, Anwendungen, Datenbanken, Firewalls, Netzwerkkomponenten, Cloud-Tenants, Backupziele, Administrationskonten und externe Dienste. Welche davon der Dienstleister tatsächlich betreut und wie sie zusammenhängen, gehört in die Asset- und Konfigurationssicht.

Erst beide Dimensionen zusammen ergeben eine belastbare Aussage:

*Wir installieren nicht einfach „Updates“. Wir installieren nach einem festgelegten Verfahren Betriebssystemupdates auf den vertraglich betreuten Windows-Servern des Kunden – aber nicht auf seiner Produktionssteuerung und nicht auf der Fachanwendung, für die ein anderer Anbieter zuständig ist.*

Das ist keine Wortklauberei. Ohne diese Grenze kann ein Techniker eine notwendige Aktualisierung auslassen, weil er das System nicht für betreut hält. Oder er verändert ein System, das der Kunde selbst oder ein anderer Dienstleister verantwortet. Beides ist ungesund.

Eine Geräteliste beantwortet die entscheidenden Fragen nicht

Viele Systemhäuser besitzen bereits mehrere Inventare. Die Buchhaltung kennt gekaufte Hardware. Das RMM zeigt erreichbare Endgeräte. Die Backupsoftware kennt Sicherungsjobs. Das Monitoring kennt Hosts und Sensoren. Im Passworttresor stehen administrative Konten. Und irgendwo liegt noch eine Excel-Datei namens Kundenübersicht_final_neu_3.xlsx.

Jede dieser Quellen kann richtig sein und trotzdem nur einen Ausschnitt zeigen.

Eine Seriennummer verrät nicht, ob ein Server überwacht wird. Ein Monitoringeintrag beweist nicht, dass Sie für das Patchen zuständig sind. Ein Backupjob sagt noch nicht, ob die Wiederherstellung getestet wurde oder wer sie beauftragen darf. Und ein Administrationskonto erklärt nicht, für welche Tätigkeiten es verwendet werden darf.

Für den Kundenbetrieb müssen die Informationen deshalb anschlussfähig werden. Ein Mitarbeiter sollte zu einem betreuten Objekt mindestens herausfinden können:

• zu welchem Kunden und Standort es gehört;
• welchen Service oder Geschäftsprozess es unterstützt;
• wie das Objekt eindeutig bezeichnet und erreicht wird;
• wer fachlich und technisch zuständig ist;
• welche Tätigkeiten der Dienstleister daran erbringt;
• welche Tätigkeiten ausdrücklich nicht übernommen wurden;
• welche relevante Version und Konfiguration vorliegt;
• welche anderen Systeme, Anwendungen und Dienstleister beteiligt sind;
• wie Monitoring, Backup und administrative Zugriffe geregelt sind;
• wo die jeweils führenden Detailinformationen liegen.

Nicht jede Information muss in derselben Tabelle stehen. Entscheidend ist, dass die Verbindungen auffindbar sind und nicht erst durch Befragung der drei ältesten Mitarbeiter rekonstruiert werden müssen.

Asset Management und Configuration Management: ähnlich, aber nicht dasselbe

Im Alltag dürfen die Begriffe pragmatisch bleiben.

Asset Management beantwortet vor allem, welche relevanten Werte und Bestandteile vorhanden sind und wer dafür verantwortlich ist. Im ISMS gehören dazu nicht nur Geräte. Auch Informationen, Leistungen, Anwendungen, Wissen, externe Dienste und andere Abhängigkeiten können relevant sein. Unser allgemeiner Artikel über primäre und unterstützende Assets erklärt diese breitere Sicht ausführlich.

Configuration Management geht für den technischen Betrieb eine Stufe tiefer. Es betrachtet diejenigen Bestandteile und Merkmale, die bekannt und beherrscht werden müssen, damit ein System wie vorgesehen und sicher funktioniert: etwa Betriebssystem, Version, Rollen, Netzbeziehungen, relevante Einstellungen, installierte Komponenten und Abhängigkeiten.

Im IT-Service-Management werden solche verwalteten Bestandteile häufig Configuration Items, kurz CIs, genannt. Das ist kein von uns erfundenes Spezialvokabular für besonders dekorative ISO-Handbücher, sondern etablierte Betriebssprache. Sie müssen deshalb trotzdem weder ITIL komplett einführen noch jedes Patchkabel zum CI adeln.

Die sinnvolle Detailtiefe ergibt sich aus den Entscheidungen, die Sie treffen müssen. Wenn die konkrete Betriebssystemversion darüber entscheidet, ob eine bekannte Störung auch bei fünf anderen Kunden auftreten kann, dann ist sie relevant. Die Farbe des Servergehäuses wird es eher selten sein.

Eigentum, Betrieb und Verantwortung auseinanderhalten

Gerade im Kundenbetrieb ist „Wem gehört das?“ keine ausreichende Frage.

Ein physischer Server kann dem Kunden gehören, in einem fremden Rechenzentrum stehen und trotzdem von Ihnen administriert werden. Eine Firewall kann von Ihnen bereitgestellt werden, während der Kunde einzelne Regeländerungen selbst vornimmt. Eine Fachanwendung kann beim Kunden laufen, aber ausschließlich durch den Hersteller aktualisiert werden. Ein Microsoft-365-Tenant gehört organisatorisch zum Kunden, während Ihre Mitarbeiter privilegierte Rollen verwalten.

Deshalb sollten Sie mindestens drei Dinge auseinanderhalten:

• Eigentum oder Vertragshoheit: Wem gehört das Gerät beziehungsweise wer hat den Vertrag mit dem Anbieter?
• Betriebszuständigkeit: Wer überwacht, administriert, patcht, sichert und entstört welchen Bestandteil?
• Entscheidungs- und Freigaberecht: Wer darf Änderungen, Zugriffe, Wiederherstellungen oder Abschaltungen beauftragen und genehmigen?

Diese Rollen können bei derselben Person liegen. Müssen sie aber nicht. Eine klare Zuordnung verhindert, dass ein Mitarbeiter aus einem vorhandenen Admin-Zugang automatisch eine vollständige Handlungsvollmacht ableitet.

Das Terminalserver-Problem trifft vielleicht nicht nur einen Kunden

Nehmen wir den wiederkehrend ausfallenden Terminalserver aus unserem Artikel über Problem Management für IT-Dienstleister. Die Ursachenanalyse zeigt: Eine bestimmte Kombination aus Betriebssystemstand, Treiberversion und Sicherheitssoftware lässt den Server nach einem Update regelmäßig einfrieren.

Jetzt reicht es nicht, Kunde Müller zu reparieren und erleichtert das Ticket zu schließen. Die nächste vernünftige Frage lautet: Wo betreiben wir dieselbe oder eine hinreichend ähnliche Konfiguration noch?

Mit brauchbaren Asset- und Konfigurationsdaten lässt sich das beantworten. Vielleicht finden Sie vier weitere Terminalserver mit demselben Treiber. Zwei davon erhalten das problematische Update erst am kommenden Wochenende. Sie können den Ausfall verhindern, statt am Montagmorgen vier besonders schnelle Neustarts zu feiern.

Ohne diese Daten beginnt die Suche im Gedächtnis:

„Ich glaube, bei Schmidt läuft derselbe Treiber. Oder war das vor der Migration? Frag mal Andi.“

Damit wird Configuration Management unmittelbar praktisch. Es verbindet den einzelnen Incident mit Problem, Change und den möglicherweise ebenfalls betroffenen Kundenumgebungen. Genau diese Verbindung benötigen wir später auch, wenn ein Fehler aus dem Betrieb an Entwicklung oder Hersteller übergeben und durch eine kontrollierte Änderung behoben wird.

Was ISO 27001 daran interessiert

Die ISO 27001 verlangt nicht, dass jeder IT-Dienstleister sämtliche Kundengeräte in einer einzigen Datenbank verwaltet.

Sie setzt aber an mehreren Stellen voraus, dass relevante Bestandteile und Betriebsbedingungen bekannt und steuerbar sind:

• Abschnitt 8.1 verlangt, notwendige Prozesse zu planen, umzusetzen und zu steuern. Für einen IT-Dienstleister gehört der sicherheitsrelevante Kundenbetrieb regelmäßig dazu. Unser Artikel über das Planen und Steuern von ISO 27001-Prozessen ordnet die Anforderung ausführlicher ein.
• A.5.9 behandelt das Inventar von Informationen und anderen zugehörigen Assets einschließlich zugeordneter Verantwortlichkeit. Der Grundgedanke ist angenehm bodenständig: Was Sie weder kennen noch zuordnen können, lässt sich schlecht schützen.
• A.8.9 behandelt das Konfigurationsmanagement. Relevante Konfigurationen von Hardware, Software, Diensten und Netzen sollen festgelegt, dokumentiert, umgesetzt, überwacht und überprüft werden. Die ISO selbst beschreibt Configuration Management als Grundlage dafür, Systeme mit den benötigten Sicherheitseinstellungen funktionsfähig zu halten und unbefugte oder fehlerhafte Änderungen zu vermeiden.

Das bedeutet nicht, dass die Norm für jeden Drucker zwölf Pflichtfelder vorgibt. Die Organisation muss eine angemessene Lösung wählen, die zu ihren Risiken, Leistungen und technischen Umgebungen passt. Wer allerdings hunderte Kundensysteme mit privilegierten Rechten betreut, wird mit „Die Kollegen wissen ungefähr, was wo steht“ nur schwer erklären können, wie dieser Betrieb zuverlässig gesteuert wird.

Es muss keine gigantische Datenbank werden

Das Gegenbild zu „Das weiß Lars“ ist nicht automatisch ein millionenschweres Toolprojekt.

Für viele IT-Dienstleister ist eine verknüpfte Struktur realistischer: Das Vertrags- oder CRM-System zeigt Kunde und gebuchte Services. Die Betriebsdokumentation beschreibt Zuständigkeiten und Besonderheiten. RMM und Monitoring liefern technische Bestandsdaten. Das Backupwerkzeug bleibt die führende Quelle für Sicherungsjobs. Der Passworttresor verwaltet privilegierte Zugänge. Das Ticketsystem dokumentiert Incidents, Requests, Probleme und Changes.

Sie brauchen dann drei Dinge:

1. eine eindeutige Bezeichnung der betreuten Objekte über die Systeme hinweg;
2. festgelegte führende Quellen für unterschiedliche Informationen;
3. auffindbare Verbindungen zwischen Kunde, Service, Objekt, Konfiguration und Vorgang.

Ein zentrales Portal kann das komfortabler machen. Es ist aber kein Selbstzweck. Eine imposante Datenbank mit veralteten Einträgen ist nur eine sehr ordentliche Art, falsche Entscheidungen zu treffen.

Wie die Informationen aktuell bleiben

Die beste Bestandsaufnahme veraltet, sobald der nächste Server hinzukommt. Asset- und Configuration-Management brauchen deshalb Auslöser aus dem normalen Betrieb.

Typische Aktualisierungsimpulse sind:

• ein neuer Kunde oder Service wird übernommen;
• ein System, Standort oder Cloud-Dienst kommt hinzu;
• Verantwortlichkeiten oder Leistungsgrenzen ändern sich;
• Software, Versionen oder sicherheitsrelevante Einstellungen werden geändert;
• ein System wird ersetzt, stillgelegt oder an den Kunden zurückgegeben;
• ein Incident oder Problem zeigt, dass vorhandene Daten falsch oder unvollständig waren.

Die Aktualisierung gehört möglichst in den jeweiligen Arbeitsablauf. Wer nach jedem Change darauf hofft, dass jemand später freiwillig noch drei weitere Systeme pflegt, baut sich sehr zuverlässig die nächste veraltete Übersicht.

Auch Logging und Monitoring profitieren davon. Ein Alarm ist nur dann handlungsfähig, wenn klar ist, welches System betroffen ist, welchen Service es unterstützt und wer reagieren muss. Ein rotes Lämpchen ohne Kontext ist vor allem ein rotes Lämpchen.

Typische Fehler

Alles, was ein Scanner findet, gilt als betreut

Technische Erkennung zeigt, dass ein Gerät existiert. Sie beweist weder einen Auftrag noch eine Zuständigkeit. Sonst wird aus Netzwerksichtbarkeit sehr schnell eine unbeabsichtigte Leistungserweiterung.

Der Kundenvertrag bleibt von der Technik getrennt

Das CRM kennt den gebuchten Service, die Technik kennt den Server – aber niemand kann beides verbinden. Dann bleibt offen, ob die konkrete Tätigkeit an diesem konkreten System wirklich vereinbart ist.

Die Liste enthält Objekte, aber keine Grenzen

„Firewall wird von uns betreut“ reicht nicht, wenn der Hersteller Updates liefert, der Kunde Regeln freigibt und ein weiterer Dienstleister das Netzwerksegment verwaltet. Gerade geteilte Verantwortung muss sichtbar werden.

Jede Einzelheit wird erfasst

Wenn niemand erklären kann, wofür ein Feld gebraucht wird, wird es bald nicht mehr gepflegt. Vollständigkeit entsteht nicht durch möglichst viele Spalten, sondern durch die richtigen Informationen und verlässliche Aktualisierungswege.

Stillgelegte Systeme leben ewig weiter

Dann reagieren Mitarbeiter auf veraltete Monitoringobjekte, halten nicht mehr existierende Server für ungepatcht oder suchen Backups, die längst nicht mehr geschuldet sind. Auch das Ende eines Assets gehört zum Lebenszyklus.

So starten IT-Dienstleister pragmatisch

Nehmen Sie einen Kunden, dessen Umgebung technisch anspruchsvoll genug ist, aber noch auf einen Tisch passt. Beginnen Sie mit den wichtigsten Services und Systemen – nicht mit jeder Maus.

1. Listen Sie die für den Kunden tatsächlich erbrachten Services auf.
2. Ordnen Sie die zentralen Systeme, Anwendungen, Netze und externen Dienste zu.
3. Halten Sie fest, welche Tätigkeiten Sie an jedem Bestandteil ausführen und wo Ihre Zuständigkeit endet.
4. Ergänzen Sie relevante Versionen, Konfigurationen, Abhängigkeiten, Backups, Monitoring und administrative Zugänge.
5. Benennen Sie für jede Information eine führende Quelle.
6. Testen Sie die Struktur an einem echten Incident: Findet ein anderer Mitarbeiter alles, was er für eine sichere Entscheidung braucht?
7. Legen Sie fest, welche normalen Vorgänge die Daten künftig aktualisieren.

Wenn dieser eine Kunde funktioniert, bauen Sie daraus ein wiederverwendbares Muster. So entsteht schrittweise eine Betriebsstruktur, die ISO 27001 für IT-Dienstleister unterstützt, ohne dass Sie vor der ersten brauchbaren Information erst ein sechsmonatiges Datenbankprojekt abschließen müssen.

Interesse geweckt?

Sie möchten Ihre Kundenumgebungen so ordnen, dass Techniker, Betrieb und ISMS endlich über dieselben Systeme sprechen? Sprechen Sie mit uns.