Unabhängig davon, ob Sie in Ihrer Infrastruktur ein formal beschriebenes Tiering-Modell aus Richtlinien, Firewallregeln und Zugriffsgruppen (zum Beispiel [1]) einsetzen oder lediglich in Ihrer täglichen Administration Vernunft und gute Account-Hygiene walten lassen, hat jede IT-Landschaft Systeme und Objekte, die als "Tier 0" bezeichnet werden können. Es sind diejenigen Teile der Umgebung, die die vollständige Kontrolle über die Identitäts- und Sicherheitsinfrastruktur ermöglichen und daher sowohl besonders gefährdet als auch in besonderem Maße schützenswert sind.

In einer Windows-Server-Landschaft sind dies üblicherweise die Domaincontroller des Active Directory (AD), Unternehmens-Zertifizierungsstellen und manchmal auch stark ins AD integrierte Systeme wie Exchange-Server. Mit dem Fortschreiten der hybriden IT sind neue typische Rollen wie der Entra-ID-Connect-Server (vormals Azure AD Connect) hinzugekommen, die ganz klar zum Tier 0 gehören. Auch Verwaltungs-Workstations (PAW), von denen aus Tier-0-Systeme administriert werden, müssen als Tier 0 betrachtet werden.

Bei Auftreten von Fehlerzuständen ist es die Aufgabe der Monitoringsysteme, Administratoren per E-Mail, SMS oder auf anderen Kanälen zu informieren. In vielen Organisationen werden die Monitoringsysteme sogar befähigt, bei bestimmten Fehlfunktionen selbsttätig Korrekturmaßnahmen zu ergreifen. Diese rangieren vom einfachen erzwungenen Neustart eines Diensts oder des gesamten Servers bis hin zu komplexen Workflows, die die Festplatten von virtuellen Maschinen vergrößern, die VMs selbst auf einen anderen Host oder Cluster verschieben oder Datenbank-Reorganisationen anstoßen.

Im Fall von hochprivilegierten Tier-0-Systemen schafft dies allerdings ein Spannungsfeld, das jahrelang kaum berücksichtigt wurde und erst jetzt, mit der ständigen Verschärfung der Bedrohungslage, ins Blickfeld der IT-Sicherheitsverantwortlichen rückt. Die immer mächtigeren Monitoringsysteme werden, wenn Sie Tier 0 überwachen sollen, selbst zu Tier 0 und müssten theoretisch durch separate administrative Identitäten bedient und nach den Regeln des Tier 0 geschützt werden. Dies wiederum reißt neue Gräben im mühsam etablierten unternehmensweiten Monitoring auf und führt potenziell zu Betriebsstörungen, die durch die Einführung des Monitorings gerade vermieden werden sollen. In diesem Artikel geht es dabei ausdrücklich nicht um das Sicherheitsmonitoring der Tier-0-Systeme, sondern um die klassische Zustands- und Ereignisüberwachung.

Kaum eine andere Architekturfrage hat in den letzten 20 Jahren so viele Debatten in der Monitoring-Community hervorgerufen, wie die nach dem Einsatz de­dizierter Agenten. Tatsächlich bieten moderne Betriebssysteme zahlreiche Remoting-Protokolle wie RPC/DCOM, WMI, WinRM oder SNMP, mit denen das Monitoringsystem über das lokale Netzwerk den aktuellen Zustand der Hard- und Software abfragen, Ereignisprotokolle auslesen und bei Bedarf sogar Aktionen auslösen kann – sei es, um zusätzliche Informationen über den Zustand des Systems zu bekommen oder um auf einen als fehlerhaft ermittelten Zustand zu reagieren. Diesen Ansatz verfolgt beispielsweise PRTG Network Monitor [2] von Paessler.

Befürworter des agentenlosen Monitorings argumentieren, dass keine zusätzlichen aktiven Inhalte auf den zu überwachenden Servern installiert und ausgeführt werden müssen, weil alles Notwendige bereits im Betriebssystem enthalten ist. Wer davon ausgeht, dass ein Monitoringagent einer weniger strengen Qualitätskontrolle unterliegt als das Betriebssystem selbst, kann daher das Argument der Betriebsstabilität ins Feld führen. Aus Sicherheitssicht hat dieser Ansatz allerdings einen sehr hohen Preis:

- Netzwerkverkehr auf den verwendeten Remoting-Protokollen muss eingehend zugelassen werden. Nicht immer sind Admins sorgfältig genug, diese Verkehrsbeziehungen nur auf die IP-Adressen der Monitoringsysteme zu begrenzen.

- Alle Remoting-Protokolle benötigen eine Authentifizierung, um auf die erforderlichen Daten zuzugreifen. Dabei ist SNMP das einzige Protokoll, das eine eigene, vom überwachten System unabhängige Authentifizierung verwendet. Die Nutzung der betriebssystemeigenen Protokolle erfordert hingegen, dass hochprivilegierte Dienstkonten im Monitoringsystem gespeichert werden. Sehr häufig kommen dabei die gleichen Zugangsdaten für eine Vielzahl von Systemen zum Einsatz. Dies wiederum führt dazu, dass die Kennwörter solcher Konten viel zu selten geändert werden.

Die agentenbasierte Monitoringarchitektur kommt im laufenden Betrieb ohne das Speichern von hochprivilegierten Zugangsdaten aus, was sie auf den ersten Blick vorteilhaft erscheinen lässt. Idealerweise bauen die Agenten die Verbindung zum Monitoringsystem auf, sodass die Netzwerkkommunikation von den überwachten Systemen ausgeht und keine eingehenden Verbindungen notwendig sind. Doch leider führt der alte Gegensatz "Komfort gegen Sicherheit" häufig dazu, dass die Sicherheitslage bei weitem nicht so rosig aussieht.

Viele Monitoringsysteme verfügen über einen Push-Mechanismus für die Verteilung von Agenten an neu zu überwachende Computer. Damit dieser funktioniert, müssen die Zielsysteme eingehende SMB- und RPC-Verbindungen (Windows) sowie SSH mit hinterlegter Authentifizierung (UNIX/ Linux) akzeptieren. Im Monitoringsystem müssen daher Zugangsdaten hinterlegt werden, die hinreichend privilegiert sind, um Agenten zu installieren.

Monitoringagenten werden ferner zunehmend mit Autoupdate-Mechanismen versehen. Somit kann jemand, der Verwaltungsrechte im Überwachungssystem hat, dafür sorgen, dass ausführbarer Code seiner Wahl selbsttätig und unbeaufsichtigt auf die überwachten Geräte gelangt.

Oft haben Monitoringagenten außerdem die Fähigkeit, Skripte in einer Vielzahl von Sprachen als "Proben" oder "Sonden" auszuführen. Diese müssen in der Regel nicht explizit registriert, sondern lediglich in einem speziellen Ordner abgelegt werden, damit sie zur Ausführung kommen. Auch das Verteilen dieser Skripte findet oft mittels Autoupdate-Mechanismen statt. Die Funktion haben beispielsweise fast alle Monitoringprodukte, die auf Nagios zurückgehen und entweder NSClient++ oder eigene Agenten wie Checkmk [3] verwenden. Dies ermöglicht das Einschleusen von beliebigem Skriptcode über den Monitoringagenten.

Obwohl die Agenten in der Regel im SYSTEM-Kontext auf den jeweiligen Servern laufen, ist dies bei manchen Anwendungen wie SQL, SharePoint oder Exchange nicht ausreichend, um anwendungsspezifische Zustandsinformationen abzurufen. Dies führt dazu, dass Zugangsdaten, die für anwendungsspezifische Zugriffe nötig sind, nicht nur im Monitoringsystem hinterlegt, sondern auch zum Agenten übertragen werden müssen. Systeme wie Microsofts System Center Operations Manager (SCOM) [4] nutzen dies umfassend.

Ob mit oder ohne Agenten: Sobald Ihr Monitoringsystem mit der Zustandsüberwachung von Tier-0-Systemen betraut ist, gehört es mit einer sehr hohen Wahrscheinlichkeit selbst ins Tier 0. Entweder es speichert Zugangsdaten, die berechtigt sind, sich an Tier-0-Systemen anzumelden, oder es besitzt die Fähigkeit, ausführbaren Code auf solche Systeme zu verteilen – oder sogar beides. Nach der "reinen Lehre" des Sicherheits-Tierings benötigen Sie also ein separates Monitoringsystem speziell für Tier 0. Das wiederum bedeutet Einrichtungs- und Pflegeaufwand, zusätzlichen Ressourcenverbrauch, möglicherweise zusätzliche Lizenzkosten und vor allem einen Bruch in den Abhängigkeitsketten der Servicedefinitionen. Schließlich kann der Zustand des AD (Tier 0) nicht im Service-Abhängigkeitsbaum eines Tier-1-Dienstes berücksichtigt werden, wenn dieser Status im Tier-1-Monitoring gar nicht verfügbar ist.

Fast alles, was für die Einordnung von Monitoringsystemen in die Sicherheits-Tiers gilt, trifft übrigens auch auf Datensicherung, Virenschutz und nicht zuletzt Plattformbereitstellung (Virtualisierung, Storage, Netzwerkverwaltung) zu. In ganz besonderem Maß betrifft dies die Konfigurationsverwaltung wie Softwareverteilungs- und Automatisierungssysteme. Das konsequente Auftrennen dieser Komponenten je nach Schutzniveau macht das ganzheitliche Abbilden von IT-Diensten über Tier-Grenzen hinweg gleichzeitig technisch schwieriger und organisatorisch notwendiger denn je.

In einigen Organisationen ist der Ansatz vollständiger Tier-Trennung mit separater Serverplattform, Datensicherung, Monitoring und sogar eigenem Malwareschutz erfolgreich umgesetzt. Er ist vor allem in großen Unternehmen erfolgversprechend, in denen ohnehin separate Teams die Tier-0-Systeme verwalten. Betrifft eine im Monitoring festgestellte Fehlfunktion doch einmal die gemeinsam genutzten Infrastrukturkomponenten wie etwa das physische Netzwerk, wird die Diagnose und Entstörung auf organisatorischem Weg durch einen gemeinsamen Vorgang im Ticketsystem koordiniert. Für die meisten IT-Organisationen ist eine solche Trennung jedoch nicht praktikabel. Im Folgenden schauen wir uns die Alternativen an, die Ihnen zur Verfügung stehen.

Oft werden Funktionen der Monitoringsysteme nicht in Gänze ausgenutzt. In vielen Organisationen ziehen es Administratoren vor, das Ticketsystem als ihr "Monitoring-Front-End" zu verwenden. Dabei verzichten sie bewusst auf die Überwachung des aktuellen Zustands der Systeme und Dienste und konzentrieren sich auf das "ereigniszentrische" Monitoring, indem sie beim Eintreten von Fehlerzuständen automatisch einen Service Request eröffnen lassen – per E-Mail oder durch einen API-Aufruf. Dieser Ansatz erfordert ein sehr gutes Verständnis davon, was in der eigenen IT-Umgebung normal ist, und einen verlässlichen Prozess zur Dokumentation und Pflege von Schwellenwerten.

Falls Ihr Monitoring auf diese Art betrieben wird, sorgen Sie durch den Aufbau einer separaten Monitoringinstanz für Tier-0-Systeme und das anschließende Schärfen der Firewallregeln mit wenig Aufwand für die notwendige Trennung. Sie sollten die neue Monitoringinstanz vollständig im Tier 0 platzieren, etwaige Agenten entweder ummelden oder idealerweise sogar neu ausrollen und die Verwaltung der Tier-0-Instanz auf die berechtigten Workstations und Admin-Konten begrenzen. Waren vor dieser Umstellung privilegierte Zugangsdaten im allgemeinen Monitoringsystem hinterlegt, müssen Sie diese natürlich auch entsprechend trennen:

- Falls die zuvor verwendeten Zugriffs-, RunAs- oder Service-Accounts auch auf Tier-1-Systemen zum Einsatz kommen, kann es äußerst aufwendig sein, für Tier 1 neue Konten anzulegen. Erteilen Sie den vorhandenen Accounts explizit die notwendigen Tier-1-Berechtigungen, entziehen Sie Ihnen die Tier-0-Berechtigungen und legen Sie für Tier 0 neue Konten an.

- Falls die Zugriffskonten bereits vor der Umstellung ausschließlich dem Tier 0 zugeordnet waren, können Sie diese weiterverwenden, allerdings sollten Sie deren Kennwort sicherheitshalber ändern, bevor Sie diese Zugangsdaten im Tier-0-Monitoringsystem hinterlegen. Unabhängig von der Kennwortänderung müssen Sie aus dem nun ausschließlich dem Tier 1 gewidmeten Monitoringsystem die hinterlegten Tier-0-Credentials löschen.

Die gesamte Tier-übergreifende Kommunikation geht in diesem Konstrukt vom Monitoringsystem (Tier 0) aus und erfolgt in Richtung der Tier-1-Systeme für den E-Mail-Versand und/oder die API-Aufrufe zur automatischen Ticketeröffnung. Damit ist der Schutz der Tier-0-Systeme vor Einflüssen aus den weniger privilegierten Tiers sichergestellt.

Sowohl bei agentenbasierter als auch bei agentenloser Überwachung geht die Gefahr für die hochprivilegierten Systeme und Konten von der eigentlichen Datensammlung (im Monitoringsystem hinterlegten Zugangsdaten) oder von der Systemverwaltung (Verteilung der Agenten, Updates, Skripte) aus. Die Anzeige des aktuellen Systemzustands in Form von Dashboards sowie die Alarmierung per E-Mail, SMS oder API-Aufruf sind hingegen ungefährlich. Einige Monitoringsysteme haben die Fähigkeit, die Überwachung und die Alarmierung auf getrennten Systemen durchzuführen. Meist ist diese Trennung Teil einer generellen Architektur für "verteiltes Monitoring". Einige Systeme wie Checkmk [5] oder Zabbix [6] unterstützen diese Art der Architektur standardmäßig. Allerdings ist die Entstehung verteilter Monitoringkonzepte nicht etwa dem Sicherheitsgedanken geschuldet, sondern der Notwendigkeit, Zustandsdaten und Konfigurationen aus geographisch verteilten Standorten zu konsolidieren und zentralisiert zu verarbeiten.

Der Zabbix-Proxy strebt "Komfort und Vereinheitlichung" an und macht den zentralen Server zur Konfigurationsdrehscheibe für alle angeschlossenen Systeme. Denselben Ansatz verfolgt auch die "Livestatus"-Technologie von Checkmk. Allerdings bietet Letzteres mit "LiveDump" und "CMD-Dump" eine Alternative, die Ihnen erlaubt, die Datenhaltung und Dashboard-Anzeige über die Tier hinweg zu zentralisieren, die Konfiguration und Verwaltung hingegen den jeweiligen Checkmk-Servern in den einzelnen Tiers zu überlassen. In Microsoft SCOM ist die Einrichtung eines Tier-spezifischen verteilten Monitorings etwas komplexer und erfordert das Anlegen von mindestens drei Managementgruppen [7] (Connected MG, Tier 1 und Tier 0) mit jeweils separater SQL-Datenbank, mindestens einem eigenen Managementserver und einem ausgeklügelten Role Based Access Control dazwischen, um die administrative Trennung zwischen den Gruppen tatsächlich zu erzwingen.

Weitere Monitoringprodukte bieten ähnliche Ansätze. Sie sollten bei der Beschaffung, Installation und Konfiguration eines verteilten Monitoringsystems unbedingt darauf achten, dass das Ziel der Tier-Trennung tatsächlich erreicht wird und Sie nicht eine Hintertür zu Ihren Tier-0-Systemen öffnen.

Die verschiedenen Technologien des verteilten Monitorings setzen voraus, dass in den einzelnen Zonen oder Tiers das gleiche Produkt zum Einsatz kommt. Unter Umständen können Sie jedoch die Monitoring-Daten im Tier 1 konsolidieren, indem Sie für Tier 0 ein anderes Monitoringprodukt einsetzen und die Tier-0-Überwachung derart in das Tier-1-Monitoring aufnehmen, dass die Zustandsdaten der einzelnen Tier-0-Systeme wie Betriebsparameter dargestellt werden. Die Voraussetzung dafür ist, dass Sie den Zugriff auf die Daten des Tier-0-Monitoring ermöglichen können, ohne die Konfigurationsgewalt über dieses System preiszugeben. Mögliche Lösungsansätze hierfür sind:

- REST-API-Zugriff auf einem separaten Port und ohne die Möglichkeit, Einfluss auf die Konfiguration zu nehmen.

- Regelmäßiger Datenexport aus dem Tier-0-Monitoring und Transfer auf ein Tier-1-System, auf dem die Daten ausgewertet und zu Sensoren verarbeitet werden. Agenten wie NSClient können beispielsweise den Inhalt von Textdateien auswerten oder Skripte aufrufen.

- Aktiver Monitoringagent auf dem Tier-0-Monitoringsystem, der von sich aus NSCA-Nachrichten oder SNMP-Traps an das Tier-1-System sendet und dabei nicht den Zustand des eigenen Systems, sondern den der überwachten Tier-0-Maschinen übermittelt. Das Tier-1-Monitoring muss hierfür über einen entsprechenden Acceptor verfügen, was speziell für NSCA inzwischen immer seltener der Fall ist.

Sie können auch zwei Instanzen ein und desselben Monitoringprodukts nach den formulierten Verfahren miteinander koppeln, wenn die eingesetzte Software dafür flexibel genug ist.

In kleinen IT-Teams, wo die Infrastruktur- und Anwendungsadministration im Wesentlichen durch den gleichen Personenkreis bestritten wird, kann es durchaus praktikabel sein, das gesamte Monitoring zu einem Tier-0-Dienst zu erklären. Das Onboarding eines neuen Systems beinhaltet meistens ohnehin Tier-0-Tätigkeiten wie das Erstellen von Gruppen, Dienstkonten, Richtlinien und Firewallregeln. Gestaltet die IT ihre Prozesse optimal, kann der zuständige Administrator, der zu diesem Zeitpunkt bereits mit seinen Tier-0-Zugangsdaten an einer Privileged-Access-Workstation angemeldet ist, auch die Aufnahme des neuen Systems ins Monitoring erledigen.

Besonders Monitoringprodukte, die die Fähigkeit besitzen, die Anzeige (Dashboards) von der Administration technisch zu trennen, sind hierfür geeignet. Damit kann ein Anzeige-Terminal für das Monitoring-Dashboard guten Gewissens an der Wand im IT-Operations-Bereich hängen, ohne dass Sie dafür die Grenzen Ihrer Netzwerksegmentierung aufweichen müssen. Bei Checkmk lässt sich dafür "LiveDump" verwenden.

Mit einigen Einschränkungen müssen Sie allerdings bei diesem an sich recht einfach umzusetzenden Konzept leben: Die automatische Aufnahme neuer Systeme in das Monitoring ist beispielsweise mit Vorsicht zu genießen. Falls Ihr Monitoringsystem nicht die Intelligenz besitzt, um das Onboarding je nach Zielsystem mit unterschiedlichen Zugangsdaten durchzuführen, würden unter Umständen viel zu häufig hochprivilegierte Credentials zur Anwendung kommen.

Im klassischen Tiering nach dem "alten" Microsoft-Modell würde der Versuch, mit einem Tier-0-Account auf ein Tier-1-System zuzugreifen, abgewiesen. Falls also sichergestellt ist, dass die Tiering-Richtlinien bereits früh im Deployment-Prozess greifen und das Monitoringsystem Tier-1-Credentials nutzt, wenn die Tier-0-Anmeldung fehlschlägt, kann das automatische Onboarding grundsätzlich praktikabel sein. Aus Sicherheitssicht ist es dennoch mit einem Risiko verbunden, da Tier-0-Credentials kompromittiert werden könnten.

Auch die immer beliebtere automatische Agentenaktualisierung ist im Tier 0 mit Vorsicht zu genießen. Spätestens seit dem "Solorigate"-Angriff auf den Softwarehersteller SolarWinds [8] sind sich IT-Sicherheitsverantwortliche der Gefahr bewusst, die von Softwareupdates ausgehen kann. Schaffen es die Angreifer, die Entwicklungsumgebung eines Herstellers zu infiltrieren, können sie die ausgelieferte Software um eigene Routinen erweitern, die dann mit einem Update unbemerkt auf privilegierte Systeme der Kunden gelangen und diese kompromittieren.

Im Tier 0 sollten Sie daher auf automatische Agentenupdates verzichten und alle neuen Versionen explizit verifizieren, bevor Sie diese auf die hochprivilegierten Systeme ausbringen. Falls Sie das gleiche Produkt für die Überwachung von Tier 0 und Tier 1 einsetzen, kann das Tier-1-Monitoring als "Staging-Umgebung" für die Verprobung der Tier-0-Agenten dienen. Damit können Sie sowohl die Betriebsmerkmale wie Stabilität und Ressourcenverbrauch als auch die Sicherheit der neuen Agentenversionen überprüfen – zum Beispiel, indem Sie die Agenten-Installer einem zusätzlichen Antimalware-Scan unterziehen oder die Installation im Tier 0 verzögern und den Netzwerkverkehr der Agenten im Tier 1 auf verdächtiges Verhalten beobachten.

Letztlich ist dieses Vorgehen natürlich auch abzuwägen, denn schließt ein Hersteller hochkritische und in der Praxis bereits ausgenutzte Schwachstellen, ist das Risiko eines erfolgreichen Angriffs hierüber womöglich größer als das einer Supply-Chain-Attacke. Da die Agenten jedoch auf ohnehin stark abgeschotteten Systemen laufen, sollten derartige Lücken von außen auch kaum angreifbar sein, was genügend Zeit für eine Evaluierung der Updates bieten sollte.

Ein Kompromiss zwischen durchgängiger Visibilität und strikter Trennung ist im Monitoring nicht leicht zu erreichen, mit einer Vielzahl von Monitoringsystemen aber technisch möglich. Dabei ist das Wissen darüber, wie Ihr IT- und Anwendungsteam die Funktionen vorhandener Monitoringsysteme tatsächlich benutzt, von höchster Wichtigkeit. Falls bei Ihnen eine Neuanschaffung oder ein Wechsel des Monitoringsystems ansteht, sollten Sie unbedingt die Agentendiskussion noch einmal führen und Sicherheitsüberlegungen dabei einen hohen Stellenwert einräumen.