15 Min. Lesezeit

Lernziele

Am Ende dieses Moduls werden Sie in der Lage sein:

  • Die vier Telemetrie-Ebenen von IONOS CLOUD (Metriken, Logs, Audit, Netzwerk-Flow) ihren festen Bereichen zuordnen und jedes Signal gezielt leiten, anstatt zu erwarten, dass ein einzelnes Konsolenfenster alles anzeigt
  • So gestalten, dass die drei Observability-Lücken, die Teams in der Produktion treffen, berücksichtigt werden: Kubernetes-Steuerungsebenen-Ereignisse, die den Logging Service nie erreichen, das Fehlen einer Aggregation über Verträge hinweg und das 35-Tage-Haltefenster des Aktivitätsprotokolls
  • Central Logging nutzen, damit integrierte Produkte ihre eigenen Logs übermitteln, ohne dass für jedes Produkt ein separater Ingestion-Stack betrieben werden muss
  • Die Observability für dedizierte VMware vCenter-Umgebungen neben den Plattform-Ebenen für ein hybrides Umfeld positionieren
  • Eine Metriken-Pipeline mit Alarmen einrichten und einen Flow-Log im Data Center Designer aktivieren sowie Telemetrie als unternehmensweites Aggregationsschema in ein externes SIEM leiten

Einheit 7.2: Observability und Betrieb

Einführung

Observability auf IONOS CLOUD ist kein einzelnes Produkt. Es handelt sich um vier separate Ebenen, von denen jede einen festen Geltungsbereich, einen eigenen Ingestion-Pfad und ein eigenes Retentionsmodell aufweist. Die architektonische Arbeit besteht nicht darin, „Monitoring einzuschalten"; sie besteht darin zu entscheiden, welches Signal in welche Ebene einläuft, wo die Nahtstellen zwischen den Ebenen liegen und wie man daraus ein einheitliches operatives Gesamtbild über alle Ebenen und Verträge hinweg zusammenfügt.

FinCorp, unser deutsches Finanzdienstleistungsunternehmen mit Pflichten nach DSGVO und BSI, benötigt eine auditfähige operative Sicht, die einen regulierten Workload-Kern, eine Managed Kubernetes-Plattform und eine dedizierte VMware-Umgebung umfasst. Diese Konstellation legt jede Nahtstelle im Telemetrie-Modell der Plattform offen. Diese Einheit behandelt die vier Ebenen, benennt die Lücken ehrlich, baut eine Metriken-Pipeline mit einem Alert und einem Flow Log im Data Center Designer auf und schließt mit dem Fan-in-Muster, das FinCorp einen zentralen Ort zur Korrelation bietet.

1. Die vier Telemetrie-Ebenen und ihre festen Bereiche

Die Plattform verteilt das operative Signal auf vier Produkte. Keines davon ist eine Obermenge der anderen, und die Grenzen sind hart, keine Konventionen.

Metriken (Monitoring Service). Ein Service pro Vertrag und pro Region, der Metriken im Prometheus-Format (Counter, Gauge, Histogram, Summary) empfängt, mit einer JSON-Alternative, die mit Snappy komprimiert werden muss. Metriken werden von einem Agenten geschickt: Prometheus, Grafana Agent, OpenTelemetry oder Fluent Bit, mit einer standardmäßigen Push-Intervall von 1 Minute, das konfigurierbar ist. Hinter dem Endpunkt landet die Daten in Grafana Mimir und wird in einer verwalteten Grafana-Instanz visualisiert, die pro Vertrag und pro Region begrenzt ist. Sie können bis zu 10 Pipelines pro Vertrag ausführen.

Logs (Logging Service). Ein Service pro Vertrag und pro Region, der Log-Streams von einem festen Satz von Quellen empfängt: Kubernetes, Docker, Linux Systemd, HTTP (eine JSON REST API) und Generic. Der Transport erfolgt über TLS entweder über TCP (Fluent Bit forward, Port 9000) oder HTTPS (Port 443). Jede Pipeline trägt bis zu 5 Log-Streams, Sie können bis zu 10 Pipelines pro Vertrag ausführen, und die Aufbewahrung pro Stream beträgt 7, 14, 30 Tage oder unbegrenzt (Standard 30). Logs erscheinen in derselben verwalteten Grafana, aber das Grafana-Abfragefenster beträgt 30 Tage; alles, was unter unbegrenzter Aufbewahrung gehalten wird, wird durch das Erstellen eines Support-Antrags zurückgelesen, nicht im Dashboard.

Audit (Activity Logs). Die Audit-Trail der Steuerungsebene: Wer hat was mit welcher Ressource gemacht. Es protokolliert Benutzeranmeldungen, Ressourcenbereitstellung, Konfigurationsänderungen, Datenzugriffe sowie Abrufe, Änderungen und Löschungen von Ressourcen. Es ist per Design schreibgeschützt, jeder Aufruf ist ein GET gegen https://api.ionos.com/activitylog/v1, und die Aufbewahrung beträgt 35 Tage. Dies ist eine Governance-Ebene, die in Einheit 2.3 ausführlich behandelt wird; hier ist sie relevant, weil ihr kurzes Fenster eine Export-Disziplin erzwingt, die die Metriken- und Log-Ebenen nicht tun.

Netzwerkfluss (Flow Logs). Verbindungsprotokolle pro Fluss (5-Tupel plus Paket- und Bytezähler, plus ein action-Feld mit ACCEPT oder REJECT, das das Firewall-Urteil anzeigt), die als gzip-komprimierter Text in einen kundenbesitzenen Object Storage-Bucket ausgegeben werden und alle 10 Minuten rotiert werden. Flow Logs werden an einer VM-NIC, einem Managed Network Load Balancer, einem Managed Application Load Balancer oder einem Managed NAT Gateway angehängt und erfassen IPv4 und IPv6. Diese Ebene wird in Einheit 3.2 als Firewall-Verifikationstool aufgebaut; sie erscheint hier als das Netzwerkebenen-Bein des operativen Bildes.

Die vereinheitlichende Oberfläche ist Grafana: Metriken und Logs sind beide über eine verwaltete Grafana-Instanz pro Vertrag und pro Region abfragbar. Der bewusste Designpunkt ist, dass Audit- und Netzwerkflussdaten vollständig außerhalb dieses Bereichs liegen, nämlich in der Activity Log API und in Object Storage. Eine vollständige operative Ansicht ist etwas, das Sie zusammenstellen, nicht etwas, das die Konsole Ihnen liefert.

2. Die Grenzen, um die herum gestaltet werden muss

Drei Grenzen sind die, die in der Produktion spürbar werden. Jede ist ein Gestaltungseingabe, kein Defekt, und jede hat eine native Komposition um sich herum.

Kubernetes-Steuerungsereignisse fließen nicht durch den Logging Service. Der Logging Service listet Kubernetes als unterstützte Quelle auf, aber das bedeutet Workload- und Node-Logs, die Sie aus dem Cluster heraus versenden, nicht die verwaltete Steuerungsebene. Der SLA für IONOS CLOUD Managed Kubernetes deckt nur die Kubernetes API der Steuerungsebene ab, und Steuerungsereignisse werden nicht in Ihre Logging Service-Pipeline ausgegeben. Das Cluster bietet einen separaten Schalter „Logging to S3“, der Cluster-Logdaten in einen Object Storage-Bucket schreibt; behandeln Sie das als einen eigenen, separat aktivierten Pfad, nicht als Sichtbarkeit der Steuerungsebene in Ihrem Grafana. Für Workload-Observability deployen Sie einen Agenten im Cluster (Fluent Bit für Logs, ein Prometheus-kompatibler Exporter für Metriken), der in Ihre Logging- und Monitoring-Pipelines pusht. Die Nahtstelle ist die Linie zwischen der verwalteten Steuerungsebene und Ihren Workloads: Sie instrumentieren Letztere, IONOS CLOUD betreibt Ersteres.

Es gibt keine aggregierte Auswertung über Verträge hinweg. Monitoring- und Logging-Pipelines sind pro Vertrag und pro Region, und das Activity Log ist pro Vertrag, ohne Push und ohne Aggregations-Endpunkt. Wenn FinCorp Produktion, Nicht-Produktion und eine compliance-isolierte Workload über separate Verträge verteilt (die Grenzdiziplin aus Einheit 2.1), gibt es kein natives Panel, das ihre Telemetrie vereint. Aggregation ist etwas, das Sie selbst aufbauen, indem Sie das Signal jedes Vertrags in einen externen Collector fächern (Abschnitt 5).

Die Aufbewahrungsfrist des Activity Log beträgt 35 Tage. Das ist der harte Löschhorizont für die Audit-Trail. Für ein reguliertes Unternehmen, dessen Aufbewahrungspflichten sich über Jahre erstrecken, ist das 35-Tage-Fenster eine Exportfrist, keine Aufbewahrungsrichtlinie. Das dokumentierte Langzeitmuster besteht darin, Activity Log-Daten planmäßig herunterzuladen und sie auf einem anderen Speicher abzulagern, wobei IONOS Cloud Object Storage als ausdrücklich empfohlene Zielinstanz genannt wird, idealerweise unter Object Lock für ein manipulationsresistentes Archiv (Einheit 2.3, Einheit 5.2). Verpassen Sie das Fenster, und der Datensatz ist weg.

3. Zentrales Logging und Hybrid-vCenter-Beobachtbarkeit

3.1 Zentrales Logging für produktinitiierte Weiterleitung

Standardmäßig übermitteln Sie Logs selbst, indem Sie einen Agenten auf einen Pipeline-Endpunkt zeigen. Zentrales Logging ist der auf Vertragsebene und pro Region verfügbare Schalter, der es integrierten IONOS CLOUD-Produkten ermöglicht, ihre eigenen Logs im Auftrag des Kunden an den Logging Service zu übermitteln. Diese Logs werden in derselben verwalteten Grafana-Umgebung angezeigt, ohne dass jedes Produkt einen eigenen Ingestion-Stack betreiben muss. Ein Managed Network Load Balancer sendet beispielsweise seine Zugriffslogs an Ihren Logging Service, sobald Zentrales Logging aktiviert ist. Dasselbe Modell gilt auch für Zentrales Monitoring im Monitoring Service.

Zentrales Logging muss aktiviert werden, bevor ein Produkt Logs im Auftrag des Kunden aufnehmen kann, da es sowohl den operativen Überblick als auch die Abrechnung beeinflusst. Die Aktivierung erfolgt pro Region. Nur Vertragsverwalter, Eigentümer und Benutzer mit der Berechtigung „Zugriff auf Logging Service und Verwaltung“ können den Schalter umstellen. Die Aktivierung ist über den DCD möglich (ein pro Region definierter STATE-Schalter in der Ansicht „Zentrales Logging“ des Logging Service), über die Logging API oder durch ein integriertes Produkt im Auftrag des Kunden. Welche Produkte integriert sind, wird über den Account Manager oder IONOS CLOUD Support bestätigt, statt als statische Liste veröffentlicht zu werden. Daher sollte der unterstützte Bereich je nach Engagement verifiziert werden.

3.2 vCenter-Beobachtbarkeit für den dedizierten VMware-Bereich

Der regulierte Kernbereich von FinCorp läuft auf IONOS CLOUD Private Cloud, dem dedizierten, verwalteten VMware-SDDC (Einheit 4.4). Die Telemetriedaten dieses Bereichs fließen nicht in die vier Plattform-Ebenen ein. Stattdessen besteht die Beobachtbarkeit für diesen Bereich aus den nativen VMware-Werkzeugen, die mit dem dedizierten Stack ausgeliefert werden: vCenter Server 8.0 für Leistungsdiagramme, Ereignisse und Alarme von Hosts, Clustern und VMs sowie vSAN-Health- und Kapazitätsüberwachung für die Speicher-Ebene, die im Cloud Panel angezeigt wird. Die vSphere REST API (mit einer Ratebeschränkung von 100 Anfragen pro Sekunde) ist die programmatische Schnittstelle, wenn diese Daten nach außen abgerufen werden sollen.

Geben Sie hier nur an, was die Matrix unterstützt: Die Beobachtungsfläche für den dedizierten VMware-Bereich besteht aus vCenter und vSAN. Gehen Sie nicht davon aus, dass eine verwaltete Brücke über Ebenen hinweg existiert, die vCenter-Alarme in den Logging Service übernimmt; eine solche ist nicht dokumentiert. Für einen Hybrid-Bereich ist das ehrliche Modell zwei nebeneinander laufende Beobachtungsbereiche: die vier Plattform-Ebenen für cloudbasierte Ressourcen und vCenter/vSAN für den dedizierten VMware-Kern. Eine Abgleichung erfolgt nur dort, wo Sie beide Bereiche bewusst in einen gemeinsamen externen Collector weiterleiten.

4. DCD-Implementierung im Detail

Sie richten den Metriken-Teil des operativen Ansichts von FinCorp sowie den Netzwerkfluss-Teil ein: eine Metriken-Pipeline mit einem Alert und ein Flow Log am Edge-Load Balancer. Damit werden zwei der vier Ebenen aus Abschnitt 1 umgesetzt und konkrete Ingestion-Endpunkte bereitgestellt, auf die Agenten zeigen können. Der dritte Teil, Logs, folgt dem identischen Pipeline-Muster im DCD.

Bauziel: Erstellen einer Metriken-Pipeline mit einem Alert und Aktivierung von Flow Logs.

Voraussetzungen. Ein bestehender Object Storage-Bucket in der Zielregion, der Ihnen gehört (das Flow-Log-Ziel muss ein benutzerdefinierter Bucket sein). Das Recht „Create Flow logs“ für die Flow-Log-Arbeit und das Recht „Access and manage Monitoring“ für die Metriken-Pipeline. Ausgehender HTTPS auf Port 443 von dem Ort, an dem Ihre Metrik-Agenten laufen.

Teil A: Die Metriken-Pipeline (Monitoring Service). Die Metriken-Pipeline des Monitoring Service kann über ein DCD-Erstellungsformular oder über die Monitoring Service API erstellt werden, und das DCD bietet auch Zugriff auf den resultierenden Grafana. Der vollständige Lebenszyklus der Pipeline (Erstellen, Abrufen, Ändern, Löschen) ist über die API verfügbar, was der unten verwendete Weg ist, bevor man für Alerting in Grafana wechselt.

  1. Wählen Sie den regionalen Endpunkt, der Ihrer Datenplatzierung entspricht, beispielsweise https://monitoring.de-txl.ionos.com/pipelines für Berlin. Die Region bestimmt, wo Metriken verarbeitet und gespeichert werden, daher sollte sie mit der Residenzentscheidung der Workload konsistent bleiben.
  2. Erstellen Sie die Pipeline mit einem PUT (oder POST) an diesen Endpunkt, der ein properties.name enthält, authentifiziert mit einem Bearer-Token. Die Antwort enthält in ihren Metadaten einen einmaligen key und ein grafanaEndpoint. Speichern Sie den Schlüssel bei der Erstellung; aus Sicherheitsgründen wird er nicht erneut zurückgegeben, und Sie können ohne ihn keine Metriken senden.
  3. Konfigurieren Sie einen Metrik-Agenten (Prometheus, Grafana Agent, OpenTelemetry oder Fluent Bit), um an den HTTP-Endpunkt der Pipeline zu senden, wobei api/v1/push an den Pfad angehängt wird, und senden Sie den gespeicherten Schlüssel als Bearer-Autorisierungs-Header über Port 443. Metriken treffen im Standardintervall von 1 Minute ein, es sei denn, Sie ändern es.
  4. Öffnen Sie den verwalteten Grafana unter der zurückgegebenen grafanaEndpoint und bestätigen Sie, dass die Metriken abfragbar sind, was die Ingestion von Ende zu Ende verifiziert.
  5. Erstellen Sie den Alert in Grafana: Definieren Sie eine Alert-Regel für die Metrik, die Sie interessiert (für die stateless App-Ebene von FinCorp eine CPU-Auslastungsschwelle, die einer Auto-Scaling-Aktion vorausgehen sollte), und hängen Sie einen Kontaktpunkt an, damit die Regel den On-Call-Kanal benachrichtigt. Grafana Alerting ist die Alerting-Oberfläche; es gibt kein separates IONOS CLOUD Alert-Objekt für die Metriken-Ebene.

Ein kurzer illustrativer Aufruf zum Erstellen (der architektonische Punkt ist, dass diese Ebene über die API und nicht über die Konsole provisioniert wird):

curl --location --request POST 'https://monitoring.de-txl.ionos.com/pipelines' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer $TOKEN' \
  --data '{ "properties": { "name": "fincorp-app-metrics" } }'

Teil B: das Flow Log (DCD). Dieser Abschnitt ist ein echter DCD-Aufbau und wird an eine Ressource angehängt, die Sie bereits aus Modul 3 besitzen.

  1. Öffnen Sie im DCD das Rechenzentrum und wählen Sie die Edge-Ressource aus, deren Traffic Sie aufzeichnen möchten. Für einen Server oder Cube öffnen Sie den Tab „Network" und die Eigenschaften des Network Controller (NIC); für einen Managed Network Load Balancer, Managed Application Load Balancer oder Managed NAT Gateway öffnen Sie den Tab „Settings" im Inspector-Bereich.
  2. Öffnen Sie das Dropdown-Menü „Flow Log" und erstellen Sie eine Regel. Setzen Sie einen Namen (dieser wird auch zum ersten Teil des Präfixes des Objektnamens in Object Storage), benennen Sie ihn also nach der Ressource und der Umgebung.
  3. Setzen Sie „Direction" auf „Ingress", „Egress" oder „Bidirectional" und „Action" auf „Rejected", „Accepted" oder „Any". Für eine sicherheitsbezogene Untersuchungsoption zeigt die Kombination aus „Bidirectional" und „Rejected", was die Firewall blockiert; für die Analyse von Kapazität und Verbindungen ist „Accepted" der nützliche Satz.
  4. Setzen Sie den Ziel-Object Storage-Bucket auf Ihren bestehenden, benutzereigenen Bucket in der Region. Speichern Sie die Einstellungen. Die Datensätze beginnen als .log.gz-Objekte einzutreffen und werden alle 10 Minuten rotiert.
  5. Wenden Sie eine Lifecycle-Policy für diesen Bucket an, um die Flow-Log-Objekte zu altern, da Flow Logs keine integrierte Aufbewahrungsfrist haben: Die Aufbewahrung wird vollständig vom Kunden über eine Object Storage Lifecycle Policy oder manuelle Löschung verwaltet.

Häufige Fehler:

  • Die Überwachungspipeline-Schlüssel bei der Erstellung nicht speichern. Der Schlüssel wird nur einmal zurückgegeben und nie wieder. Wenn Sie ihn verlieren, müssen Sie die Pipeline neu erstellen. Die gleiche Regel für Einmal-Schlüssel gilt auch für eine Logging Service-Pipeline.
  • „Kubernetes" in der Quellliste des Logging Service als Sichtbarkeit der Control-Plane zu behandeln. Es handelt sich nur um Ihre Workload-Logs innerhalb des Clusters; Control-Plane-Ereignisse kommen dort nie an. Installieren Sie einen Agenten innerhalb des Clusters und warten Sie nicht auf Ereignisse, die nicht eintreten werden.
  • Die Annahme, dass die Aufbewahrung von Flow Logs für Sie verwaltet wird. Das Löschen der Flow-Log-Regel löscht die bereits geschriebenen Objekte nicht, und es gibt keine automatische Ablaufzeit. Ohne eine Bucket-Lifecycle-Policy wächst das Archiv und wird dauerhaft abgerechnet.
  • Das Zeigen eines Flow Logs auf einen Bucket, den Sie nicht besitzen, oder auf einen in der falschen Region. Das Ziel muss ein benutzereigener Bucket sein; eine falsche Zielangabe führt zu einem stillen Fehlschlag bei der Lieferung der Datensätze.
  • Das Vergessen des 35-Tage-Fensters des Activity Log. Es handelt sich nicht um eine Aufbewahrungsfrist, sondern um eine Löschgrenze. Planen Sie den Export nach Object Storage vor Tag 35 ein, oder das Audit-Protokoll ist nicht wiederherstellbar.

5. Fan-In in ein externes SIEM

Für ein Unternehmen wie FinCorp erzeugt das pro Vertrag, pro Region und pro vier Ebenen aufgeteilte Modell nicht die einzelne korrelierte Ansicht, die sowohl das Security Operations Team als auch ein Auditor benötigen. Das unternehmensweite Muster ist Fan-In: Jede Ebene aus jedem Vertrag fließt in ein externes SIEM, das zur Referenzdatenbank für Korrelation, langfristige Aufbewahrung und Alarmierung über das gesamte Portfolio wird. Die Plattform bietet die Schnittstellen, um dies ohne einen verwalteten Forwarder zu tun:

  • Logs und Metriken: Richten Sie Ihre Agenten (oder die produktinitiierten Forwarder von Central Logging) auf die IONOS CLOUD-Pipelines für Grafana innerhalb der Plattform aus und leiten Sie parallel die gleichen Streams von Ihren Agenten an den SIEM-Collector weiter. Der Logging Service stellt zudem eine schreibgeschützte Telemetry API bereit (authentifiziert mit demselben Cloud API-Token), die von einem SIEM abgefragt werden kann, wobei die doppelte Übermittlung auf Agentenseite der direktere Weg ist.
  • Netzwerk-Flow: Flow Logs landen bereits als gzip-komprimierter Text in Object Storage; das SIEM nimmt sie aus dem Bucket auf, das gleichzeitig als dauerhaftes Archiv dient.
  • Audit: Ein geplanter Job ruft den Activity Log über dessen nur Lesezugriff ermöglichende API ab, bevor das 35-Tage-Fenster schließt, und leitet die Datensätze in das SIEM weiter, wodurch gleichzeitig langfristige Aufbewahrung und Korrelation über Verträge hinweg erfüllt werden.
  • Hybrides VMware: Die vSphere REST API und vCenter-Alarme werden aus dem dedizierten Portfolio in dasselbe SIEM weitergeleitet, wodurch die beiden Observability-Bereiche an dem einen Punkt zusammengeführt werden, an dem eine Vereinheitlichung sinnvoll ist.

Dies ist dieselbe Kompositionslektion, die die Plattform auch andernorts wiederholt: Es gibt kein verwaltetes Produkt zur Aggregation über Verträge hinweg, daher setzen Sie eines selbst zusammen. Object Storage ist der dauerhafte Hub, das SIEM ist das Korrelationszentrum, und die Endpunkte pro Ebene sind die Abgriffe.

Zusammenfassung

Die Observability-Funktionen von IONOS CLOUD bestehen aus vier Bereichen mit festem Umfang (Metriken über den Monitoring Service, Logs über den Logging Service, Audit über Activity Logs und Netzwerkfluss über Flow Logs), die nur teilweise in Grafana vereint werden. Audit- und Flussdaten liegen dabei bewusst außerhalb dieses Bereichs. Die zentrale operative Arbeit besteht darin, jedes Signal gezielt zu leiten, die Architektur um die drei Lücken herum zu gestalten (keine Control-Plane-Ereignisse in der Logging-Ebene, keine Aggregation über Verträge hinweg, ein 35-Tage-Auditfenster), Central Logging für produktinitiiertes Forwarding zu nutzen, die dedizierte VMware-Umgebung als eigenständige Observability-Domain für vCenter/vSAN zu behandeln und alle Daten in ein externes SIEM zu leiten, wo Korrelation und langfristige Aufbewahrung tatsächlich stattfinden.

Wichtige Punkte:

  • Vier Ebenen, fester Umfang: Monitoring Service (Prometheus-Metriken, push-basiert, Grafana Mimir), Logging Service (fünf Quelltypen, 5 Streams pro Pipeline, Aufbewahrung für 7/14/30 Tage oder unbegrenzt), Activity Logs (nur Lesezugriff via GET, 35-Tage-Fenster), Flow Logs (5-Tupel-Aufzeichnungen in einem benutzereigenen Object Storage-Bucket, kundenseitig verwaltete Aufbewahrung).
  • Die Metriken-Pipeline des Monitoring Service kann aus dem Erstellungsformular des DCD oder über die API erstellt werden; der einmalige Pipeline-Schlüssel muss bei der Erstellung gespeichert werden.
  • Control-Plane-Ereignisse von Kubernetes erreichen den Logging Service nie; Instrumentieren Sie Workloads mit einem In-Cluster-Agent und behandeln Sie das Cluster-Feature „Logging to S3“ als separaten Pfad.
  • Es gibt keine Aggregation über Verträge hinweg und der Audit-Verlauf wird nach 35 Tagen gelöscht. Daher werden Aggregation und langfristige Aufbewahrung extern aufgebaut, wobei Object Storage als dauerhafter Hub und ein SIEM als Korrelationspunkt dienen.
  • Central Logging ist ein auf Regionsebene und Vertragsebene wirkender Schalter (durch Administratoren geschützt), der integrierten Produkten ermöglicht, Logs für Sie weiterzuleiten. Die dedizierte VMware-Umgebung wird über vCenter 8.0 und vSAN beobachtet, eine eigenständige Domain, die nur im SIEM abgestimmt wird.

Wichtige Begriffe:

  • Telemetrie-Ebene: eine der vier Observability-Produkte mit festem Umfang (Metriken, Logs, Audit, Netzwerkfluss), jeweils mit eigenem Ingestion-Pfad und eigenem Aufbewahrungsmodell.
  • Central Logging: eine auf Vertragsebene und Regionsebene wirkende Funktion, die integrierten IONOS CLOUD-Produkten ermöglicht, ihre Logs in Ihrem Namen an den Logging Service weiterzuleiten. Diese Funktion wird in der verwalteten Grafana-Umgebung angezeigt.
  • Flow Log: eine ressourcenspezifische Regel, die 5-Tupel-Verbindungsaufzeichnungen mit der Firewall-Entscheidung ACCEPT/REJECT in einen kundenbesitzenen Object Storage-Bucket schreibt und alle 10 Minuten rotiert.
  • Fan-in: das unternehmensweite Aggregationsmuster, bei dem alle Ebenen aus allen Verträgen in ein externes SIEM geleitet werden, um Korrelation über Verträge hinweg und langfristige Aufbewahrung zu ermöglichen.

Weitere Lektüre

  • Einheit 2.3: Activity Logs und die Audit-Trail (die Audit-Ebene und die Exportfrist)
  • Einheit 3.2: Netzwerksicherheit: Firewall und Security Groups (Flow Logs als Werkzeug zur Firewall-Verifizierung)
  • Einheit 4.4: Private Cloud (Dedicated VMware) (das dedizierte Estate, beobachtet über vCenter und vSAN)
  • Einheit 6.1: Kubernetes-Plattformdesign (warum Control-Plane-Ereignisse außerhalb der Logging-Ebene liegen)
  • IONOS CLOUD Architecture Center