Einheit 7.2: Beobachtbarkeit und Betrieb

Einführung

Beobachtbarkeit auf IONOS CLOUD ist kein einzelnes Produkt. Es handelt sich um vier separate Ebenen, jede mit einem festen Umfang, ihrem eigenen Aufnahmepfad und ihrem eigenen Aufbewahrungsmodell. Die architektonische Arbeit besteht nicht darin, "Überwachung einschalten" zu können, sondern darin zu entscheiden, welches Signal in welche Ebene gelangt, wo die Nähte zwischen den Ebenen sind und wie man ein einziges operatives Bild über sie und über Verträge hinweg erstellt.

FinCorp, unser deutsches Finanzdienstleistungsunternehmen unter GDPR- und BSI-Bindungen, benötigt eine audit-gerechte operative Ansicht, die sich über eine regulierte Workload-Kernkomponente, eine Managed Kubernetes-Plattform und einen dedizierten VMware-Bestand erstreckt, der jeden Naht zwischen den Telemetrie-Modellen der Plattform offenlegt. Diese Einheit behandelt die vier Ebenen, benennt die Lücken ehrlich, baut eine Metriken-Pipeline mit einer Warnung und einem Datenverkehrs-Log im Data Center Designer und schließt mit dem Fan-in-Muster ab, das FinCorp einen Ort bietet, an dem es korrelieren kann.

1. Die Vier Telemetrie-Ebenen und Ihre Festen Bereiche

Die Plattform teilt das operationale Signal in vier Produkte auf. Keines von ihnen ist eine Obermenge der anderen, und die Grenzen sind hart, nicht konventionell.

Metriken (Monitoring Service). Ein pro-Vertrag, pro-Region-Service, der Metriken im Prometheus-Format (Zähler, Messgerät, Histogramm, Zusammenfassung) aufnimmt, mit einer JSON-Alternative, die mithilfe von Snappy komprimiert werden muss. Metriken werden von einem Agenten übertragen: Prometheus, Grafana Agent, OpenTelemetry oder Fluent Bit, bei einem Standard-Übertragungsintervall von 1 Minute, das konfigurierbar ist. Hinter dem Endpunkt landen die Daten in Grafana Mimir und werden in einer gemanagten Grafana-Instanz visualisiert, die pro Vertrag und pro Region skaliert ist. Sie können bis zu 10 Pipelines pro Vertrag ausführen.

Protokolle (Logging Service). Ein pro-Vertrag, pro-Region-Service, der Protokollströme aus einer festen Menge von Quellen aufnimmt: 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 kann bis zu 5 Protokollströme übertragen, Sie können bis zu 10 Pipelines pro Vertrag ausführen und die Aufbewahrungsfrist pro Stream beträgt 7, 14, 30 Tage oder unbegrenzt (Standard 30). Protokolle werden im gleichen gemanagten Grafana angezeigt, aber das Grafana-Abfragefenster beträgt 30 Tage; alles, was unter unbegrenzter Aufbewahrungsfrist gespeichert wird, kann durch Erstellen eines Support-Antrags gelesen werden und nicht im Dashboard.

Audit (Activity Logs). Der Kontrollflug-Audit-Trail: wer hat was mit welcher Ressource gemacht. Er zeichnet Benutzeranmeldungen, Ressourcenbereitstellungen, Konfigurationsänderungen, Datenzugriffe und Ressourcenabrufe, -änderungen und -löschungen auf. Er ist aus Sicherheitsgründen schreibgeschützt, jeder Aufruf ist ein GET gegen https://api.ionos.com/activitylog/v1 und die Aufbewahrungsfrist beträgt 35 Tage. Dies ist eine Governance-Ebene, die in Einheit 2.3 ausführlich behandelt wird; hier ist sie wichtig, weil ihr kurzes Fenster eine Exportdisziplin erzwingt, die die Metriken- und Protokollebenen nicht haben.

Netzwerkfluss (Flow Logs). Pro-Fluss-Verbindungsdatensätze (5-Tupel plus Paket- und Bytezählungen sowie ein action-Feld mit ACCEPT oder REJECT zur Anzeige des Firewall-Urteils) werden als gzip-komprimierter Text an einen Kunden-eigenen Object Storage-Bucket gesendet und alle 10 Minuten rotiert. Flow Logs sind an eine VM-NIC, einen Managed Network Load Balancer, einen Managed Application Load Balancer oder einen Managed NAT Gateway angehängt und erfassen IPv4- und IPv6-Daten. Diese Ebene wird in Einheit 3.2 als Firewall-Überprüfungstool aufgebaut; sie erscheint hier als Netzwerkschicht des operationellen Bildes.

Die einheitliche Oberfläche ist Grafana: Metriken und Protokolle sind beide über eine gemanagte Grafana-Instanz pro Vertrag pro Region abfragbar. Der bewusste Entwurfspunkt ist, dass Audit- und Netzwerkflussdaten vollständig außerhalb dieser Ansicht leben, in der Activity Log API bzw. im Object Storage. Ein vollständiges operationelles Bild ist etwas, das Sie zusammenstellen müssen und nicht etwas, das die Konsole Ihnen an die Hand gibt.

2. Die Lücken, um die herum zu entwerfen

Drei Grenzen sind diejenigen, die in der Produktion beißen. Jede ist ein Entwurfsinput und kein Defekt, und jede hat eine native Zusammensetzung um sie herum.

Kubernetes-Steuerungsebenen-Ereignisse fließen nicht durch den Logging Service. Der Logging Service listet Kubernetes als unterstützte Quelle auf, aber das bedeutet, dass Arbeitslast- und Knotenprotokolle, die Sie aus dem Cluster heraus verschicken, nicht die verwaltete Steuerungsebene betreffen. Der IONOS CLOUD Managed Kubernetes-SLA umfasst nur die Kubernetes-API der Steuerungsebene, und Steuerungsebenen-Ereignisse werden nicht in Ihre Logging Service-Pipeline emittiert. Der Cluster bietet jedoch einen separaten "Protokollierung zu S3"-Schalter, der Cluster-Protokoll-Daten in einen Object Storage-Bucket schreibt. Behandeln Sie dies als einen separaten, eigenständig aktivierten Pfad und nicht als Steuerungsebenen-Sichtbarkeit in Ihrem Grafana. Für die Arbeitslast-Beobachtbarkeit setzen Sie einen In-Cluster-Agenten (Fluent Bit für Protokolle, einen Prometheus-kompatiblen Exporteur für Metriken) ein, der Ihre Logging- und Monitoring-Pipelines pusht. Die Nahtstelle ist die Linie zwischen der verwalteten Steuerungsebene und Ihren Arbeitslasten: Sie instrumentieren letztere, während IONOS CLOUD die erstere betreibt.

Es gibt keine cross-vertragliche Aggregation. Monitoring- und Logging-Pipelines sind pro-Vertrag und pro-Region, und das Activity Log ist pro-Vertrag mit keinem Push- und keinem Aggregationsendpunkt. Wenn FinCorp Produktion, Nicht-Produktion und eine Compliance-isolierte Arbeitslast über separate Verträge aufteilt (die Grenzdisziplin aus Einheit 2.1), gibt es kein natives Pane, das ihre Telemetrie vereint. Aggregation ist etwas, das Sie aufbauen, indem Sie jeden Vertrags-Signal in einen externen Sammler (Abschnitt 5) leiten.

Das Activity Log-Aufbewahrungszeitfenster beträgt 35 Tage. Das ist das harte Löschhorizont für die Audit-Spur. Für ein reguliertes Unternehmen, dessen Aufbewahrungsverpflichtungen Jahre betragen, ist das 35-Tage-Zeitfenster ein Export-Stichtag und keine Aufbewahrungsrichtlinie. Das dokumentierte Langzeitmuster besteht darin, Activity Log-Daten regelmäßig herunterzuladen und auf einem anderen Speichermedium zu speichern, wobei IONOS Cloud Object Storage als explizit empfohlenes Ziel dient, idealerweise unter Objekt-Sperre für ein manipulationsicherem Archiv (Einheit 2.3, Einheit 5.2). Wenn Sie das Zeitfenster verpassen, ist der Datensatz weg.

3. Zentrales Logging und Hybrid-vCenter-Beobachtbarkeit

3.1 Zentrales Logging für produktinitiiertes Weiterleiten

Standardmäßig übermitteln Sie die Protokolle selbst, indem Sie einen Agenten auf einen Pipeline-Endpunkt verweisen. Zentrales Logging ist der vertragsbasierte, pro-Region-Schalter, der es integrierten IONOS CLOUD-Produkten ermöglicht, ihre eigenen Protokolle an den Logging Service in Ihrem Namen weiterzuleiten, der in demselben gemanagten Grafana angezeigt wird, ohne dass jedes Produkt einen separaten Ingestions-Stack ausführt. Ein Managed Network Load Balancer beispielsweise sendet seine Zugriffsprotokolle an Ihren Logging Service, sobald das Zentrale Logging aktiviert ist. Das gleiche Modell gilt auch für das Zentrale Überwachung für den Monitoring Service.

Das Zentrale Logging muss aktiviert werden, bevor ein Produkt Protokolle in Ihrem Namen übermitteln kann, da es sowohl Ihre betriebliche Sicht als auch Ihre Abrechnung beeinflusst. Die Aktivierung erfolgt pro Region, und nur Vertragsadministratoren, Besitzer und Benutzer mit dem Privileg "Zugriff auf und Verwaltung des Logging Service" können es umschalten. Es kann aktiviert werden, indem man die DCD (ein pro-Region-Schalter in der Zentralen-Logging-Ansicht des Logging Service) verwendet, über die Logging-API oder durch ein integriertes Produkt in Ihrem Namen. Welche Produkte integriert sind, wird durch Ihren Account-Manager oder den IONOS CLOUD-Support bestätigt und nicht als statische Liste veröffentlicht, sodass Sie die unterstützte Menge als etwas betrachten sollten, das pro Engagement zu überprüfen ist.

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

Der regulierte Kern von FinCorp läuft auf IONOS CLOUD Private Cloud, dem dedizierten gemanagten VMware SDDC (Einheit 4.4). Seine Telemetrie fließt nicht in die vier Plattformebenen ein. Stattdessen ist die Beobachtbarkeit für diesen Bestand das native VMware-Tooling, das mit dem dedizierten Stack ausgeliefert wird: vCenter Server 8.0 für Host-, Cluster- und VM-Leistungsdiagramme, Ereignisse und Alarme sowie vSAN-Gesundheits- und Kapazitätsüberwachung, die im Cloud-Panel für die Speicherebene angezeigt werden. Die vSphere-REST-API (die auf 100 Anfragen pro Sekunde limitiert ist) ist die programmatische Schnittstelle, wenn Sie diese Daten nach außen ziehen möchten.

Nennen Sie nur das, was die Matrix hier unterstützt: Die dedizierte-VMware-Beobachtbarkeitsfläche ist vCenter und vSAN. Nehmen Sie nicht an, dass eine gemanagte Brücke zwischen den Ebenen existiert, die vCenter-Alarms in den Logging Service aufnimmt; keine ist dokumentiert. Für einen Hybrid-Bestand ist das ehrliche Modell zwei Beobachtbarkeitsbereiche, die nebeneinander laufen, die vier Plattformebenen für cloud-native-Ressourcen und vCenter/vSAN für den dedizierten VMware-Kern, die nur dort versöhnt werden, wo Sie beide absichtlich an einen gemeinsamen externen Sammler weiterleiten.

4. DCD-Implementierung Schritt-für-Schritt

Sie werden die Metriken-Komponente von FinCorps operativer Sicht und die Netzwerk-Fluss-Komponente einrichten: eine Metriken-Pipeline mit einer Warnung und einem Fluss-Log auf dem Edge-Lastenausgleich. Dies realisiert zwei der vier Ebenen aus Abschnitt 1 und gibt Ihnen konkrete Eingabeendpunkte, an die Sie Agenten verweisen können. Die dritte Komponente, Logs, folgt dem identischen Pipeline-Muster im DCD.

Ziel: Erstellen Sie eine Metriken-Pipeline mit einer Warnung und aktivieren Sie Fluss-Logs.

Voraussetzungen. Ein vorhandener Object Storage-Bucket in der Ziel-Region, den Sie besitzen (das Fluss-Log-Ziel muss ein benutzerdefinierter Bucket sein). Das Privileg "Fluss-Logs erstellen" für die Fluss-Log-Arbeit und das Privileg "Überwachung zugreifen und verwalten" für die Metriken-Pipeline. Ausgehender HTTPS auf Port 443 von überall, wo Ihre Metrik-Agenten ausgeführt werden.

Teil A: die Metriken-Pipeline (Monitoring Service). Die Monitoring Service-Metriken-Pipeline kann über ein DCD-Erstellungsformular oder über die Monitoring Service-API erstellt werden, und das DCD bietet auch Zugriff auf das resultierende Grafana. Der gesamte Pipeline-Lebenszyklus (Erstellen, Abrufen, Ändern, Löschen) ist über die API verfügbar, die der Weg ist, der unten verwendet wird, bevor man sich in Grafana für Warnungen bewegt.

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 sollten Sie sie konsistent mit der Entscheidung über den Arbeitslastenaufenthalt halten.
2. Erstellen Sie die Pipeline mit einem PUT (oder POST) an diesen Endpunkt mit einem properties.name, authentifiziert mit einem Bearer-Token. Die Antwort enthält einen einmaligen key in seinen Metadaten 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 pushen.
3. Konfigurieren Sie einen Metrik-Agenten (Prometheus, Grafana Agent, OpenTelemetry oder Fluent Bit), um zur HTTP-Endpunkt der Pipeline mit api/v1/push anzuhängen, den gespeicherten Schlüssel als Bearer-Autorisierungsheader über Port 443 zu senden. Metriken arrive auf dem Standard-1-Minuten-Intervall, es sei denn, Sie ändern es.
4. Öffnen Sie das verwaltete Grafana unter dem zurückgegebenen grafanaEndpoint und bestätigen Sie, dass die Metriken abfragbar sind, was die Eingabe von Ende zu Ende bestätigt.
5. Erstellen Sie die Warnung innerhalb von Grafana: Definieren Sie eine Warnungsregel auf der Metrik, um die es Ihnen geht (für FinCorps staatlose App-Ebene eine CPU-Auslastungsschwelle, die einer Auto-Skalierungsaktion vorausgehen sollte), und fügen Sie einen Kontakt hinzu, damit die Regel den Bereitschaftskanal benachrichtigt. Grafana-Warnungen sind die Warnungs-Oberfläche; es gibt kein separates IONOS CLOUD-Warnobjekt für die Metriken-Ebene.

Ein kurzer illustrativer Erstellungsvorgang (der architektonische Punkt ist, dass diese Ebene über die API bereitgestellt wird und nicht über die Konsole):

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: Der Flow-Log (DCD). Dieses Segment ist ein echter DCD-Build, der an eine Ressource angehängt ist, die Sie bereits aus Modul 3 haben.

6. Im DCD öffnen Sie das Rechenzentrum, wählen die Edge-Ressource aus, deren Datenverkehr Sie aufzeichnen möchten. Für einen Server oder ein Cube öffnen Sie die Netzwerk-Registerkarte und die Eigenschaften des Netzwerk-Controllers (NIC); für einen Managed Network Load Balancer, Managed Application Load Balancer oder Managed NAT Gateway öffnen Sie die Einstellungen-Registerkarte im Inspector-Fenster.
7. Öffnen Sie das Flow-Log-Drop-down-Menü und erstellen Sie eine Regel. Legen Sie einen Namen fest (der auch zum ersten Teil des Object-Storage-Objekt-Namenspräfix wird), sodass Sie ihn nach der Ressource und der Umgebung benennen.
8. Legen Sie die Richtung auf Ingress, Egress oder Bidirektional und die Aktion auf Abgelehnt, Akzeptiert oder Beliebig fest. Für eine Sicherheitsuntersuchungshaltung ist Bidirektional plus Abgelehnt nützlich, um zu sehen, was die Firewall blockiert; für Kapazitäts- und Verbindungsanalysen ist Akzeptiert der nützliche Satz.
9. Legen Sie das Ziel-Object-Storage-Bucket auf Ihr bestehendes benutzerdefiniertes Bucket in der Region fest. Speichern Sie. Die Aufzeichnungen beginnen als .log.gz-Objekte zu landen, die alle 10 Minuten rotiert werden.
10. Wenden Sie eine Lebenszyklus-Richtlinie auf dieses Bucket an, um die Flow-Log-Objekte zu alterieren, da Flow Logs keine integrierte Aufbewahrung haben: Die Aufbewahrung wird vollständig vom Kunden durch eine Object-Storage-Lebenszyklus-Richtlinie oder manuelle Löschung gemanagt.

Häufige Fehler:

• Nicht speichern des Überwachungspipeline-Schlüssels bei der Erstellung. Der Schlüssel wird einmal zurückgegeben und nie wieder. Verlieren Sie ihn und Sie müssen die Pipeline neu erstellen. Die gleiche Einmal-Schlüssel-Regel gilt für eine Logging Service-Pipeline.
• "Kubernetes" in der Logging Service-Quellliste als Kontrollflächen-Sichtbarkeit behandeln. Es handelt sich um Ihre in-cluster-Workload-Logs; Kontrollflächen-Ereignisse kommen nie dorthin. Stellen Sie einen in-cluster-Agenten bereit und warten Sie nicht auf Ereignisse, die nie eintreten werden.
• Annehmen, dass die Flow-Log-Aufbewahrung für Sie gemanagt wird. Das Löschen der Flow-Log-Regel löscht nicht die bereits geschriebenen Objekte, und es gibt keine automatische Ablaufzeit. Ohne eine Bucket-Lebenszyklus-Richtlinie wächst das Archiv und wird immer weiter berechnet.
• Einrichten eines Flow-Logs auf ein Bucket, das Sie nicht besitzen oder in der falschen Region befindet. Das Ziel muss ein benutzerdefiniertes Bucket sein; Falschzielsetzung führt dazu, dass die Aufzeichnungen stillschweigend nicht geliefert werden.
• Vergessen des 35-Tage-Fensters von Activity Logs. Es handelt sich nicht um eine Aufbewahrung, sondern um ein Löschungshorizont. Planen Sie den Export zu Object Storage vor dem 35. Tag, oder der Prüfungsnachweis ist nicht wiederherstellbar.

5. Fan-In zu einem externen SIEM

Für ein Unternehmen wie FinCorp produziert das pro-Vertrag, pro-Region, vier-Ebenen-Modell nicht die einzelne korrelierte Ansicht, die ein Sicherheitsoperations-Team und ein Auditor benötigen. Das Unternehmensmuster ist Fan-in: Jede Ebene von jedem Vertrag fließt in ein externes SIEM ein, das zum System der Aufzeichnungen für Korrelation, langfristige Aufbewahrung und Alarmierung im gesamten Besitztum wird. Die Plattform bietet Ihnen die Möglichkeiten, dies ohne einen gemanagten Forwarder zu tun:

• Protokolle und Metriken: Richten Sie Ihre Agenten (oder die produktinitiierten Forwarder von Central Logging) auf die IONOS CLOUD-Pipelines für die in-plattform-Grafana aus, und leiten Sie parallel die gleichen Streams von Ihren Agenten an den SIEM-Sammler weiter. Der Logging Service stellt auch eine schreibgeschützte Telemetrie-API (authentifiziert mit dem gleichen Cloud-API-Token) bereit, die ein SIEM abfragen kann, obwohl die agentenseitige doppelte Versandung der direktere Weg ist.
• Netzwerkfluss: Flow Logs landen bereits als gzip-Text in Object Storage; das SIEM nimmt sie aus dem Bucket auf, das auch als dauerhaftes Archiv dient.
• Prüfung: Ein geplanter Job zieht den Activity Log über seine GET-only-API vor dem 35-Tage-Fenster und leitet die Aufzeichnungen in das SIEM weiter, wodurch gleichzeitig die langfristige Aufbewahrung und die Korrelation zwischen Verträgen erfüllt werden.
• Hybrid VMware: Die vSphere-REST-API und vCenter-Warnungen werden vom dedizierten Besitztum an das gleiche SIEM weitergeleitet, wodurch die beiden Beobachtungsbereiche an dem einen Punkt zusammengeführt werden, an dem eine Vereinigung sinnvoll ist.

Dies ist die gleiche Kompositionslehre, die die Plattform anderswo wiederholt: Es gibt kein gemanagtes Produkt für die Aggregation zwischen Verträgen, also komponieren Sie eines. Object Storage ist das dauerhafte Zentrum, das SIEM ist das Korrelationshirn und die pro-Ebenen-Endpunkte sind die Zapfsäulen.

Zusammenfassung

Die Beobachtbarkeit von IONOS CLOUD besteht aus vier festen Observierungs-Ebenen (Metriken über den Monitoring Service, Protokolle über den Logging Service, Prüfung über Activity Logs und Netzwerkfluss über Flow Logs), die nur teilweise in Grafana vereinigt sind, wobei Prüf- und Flussdaten absichtlich außerhalb dieser Ebene leben. Die tragende operative Arbeit besteht darin, jedes Signal bewusst zu leiten, die drei Lücken zu umgehen (keine Steuerungsebenen-Ereignisse in der Protokollebene, keine cross-vertragliche Aggregation, ein 35-Tage-Prüf-Fenster), den zentralen Protokoll-Service für das produkteinisierte Weiterleiten zu verwenden, den dedizierten VMware-Besitz als separate vCenter/vSAN-Beobachtungsdomäne zu behandeln und alles in ein externes SIEM zu leiten, wo Korrelation und langfristige Aufbewahrung tatsächlich stattfinden.

Wichtige Punkte:

• Vier Ebenen, feste Bereiche: Monitoring Service (Prometheus-Metriken, push-basiert, Grafana Mimir), Logging Service (fünf Quelltypen, 5 Streams pro Pipeline, 7/14/30/unbegrenzte Aufbewahrung), Activity Logs (nur lesbarer GET-Zugriff, 35-Tage-Fenster), Flow Logs (5-Tupel-Aufzeichnungen in einem benutzerdefinierten Object Storage-Bucket, kundenseitig verwaltete Aufbewahrung).
• Die Metrik-Pipeline des Monitoring Service kann über ein DCD-Erstellungsformular oder über die API erstellt werden; der Pipeline-Schlüssel muss einmalig bei der Erstellung gespeichert werden.
• Kubernetes-Steuerungsebenen-Ereignisse erreichen den Logging Service nie; instrumentieren Sie die Workloads mit einem In-Cluster-Agenten und behandeln Sie den Cluster "Protokollierung auf S3" als separaten Pfad.
• Es gibt keine cross-vertragliche Aggregation und der Prüfverlauf wird nach 35 Tagen gelöscht, sodass Aggregation und langfristige Aufbewahrung extern aufgebaut werden, wobei Object Storage als dauerhafter Hub und ein SIEM als Korrelationspunkt dienen.
• Central Logging ist eine vertragsbezogene, regionsbezogene Funktion (administrator-gesteuert), die es integrierten IONOS CLOUD-Produkten ermöglicht, Protokolle für Sie weiterzuleiten; der dedizierte VMware-Besitz wird über vCenter 8.0 und vSAN beobachtet, eine separate Domäne, die nur im SIEM ausgleicht.

Wichtige Begriffe:

• Telemetrie-Ebene: eine der vier festen Observierungs-Produkte (Metriken, Protokolle, Prüfung, Netzwerkfluss), jedes mit seinem eigenen Aufnahmepfad und Aufbewahrungsmodell.
• Central Logging: eine vertragsbezogene, regionsbezogene Funktion, die es integrierten IONOS CLOUD-Produkten ermöglicht, ihre Protokolle an den Logging Service auf Ihre Veranlassung hin weiterzuleiten, in der gemanagten Grafana dargestellt.
• Flussprotokoll: eine pro-Ressource Regel, die 5-Tupel-Verbindungsdatensätze mit dem Firewall-ACCEPT/REJECT-Urteil an einen benutzerdefinierten Object Storage-Bucket ausgibt, alle 10 Minuten rotiert.
• Fan-in: das Unternehmensaggregationsmuster des Weiterleitens jeder Ebene aus jedem Vertrag in ein externes SIEM für cross-vertragliche Korrelation und langfristige Aufbewahrung.

Weiterführende Literatur

• Einheit 2.3: Activity Logs und Audit-Trail (die Audit-Ebene und die Exportfrist)
• Einheit 3.2: Netzwerksicherheit: Firewall und Sicherheitsgruppen (Flow-Logs als Firewall-Verifizierungstool)
• Einheit 4.4: Private Cloud (Dedicated VMware) (das dedizierte Anwesen über vCenter und vSAN beobachtet)
• Einheit 6.1: Kubernetes-Plattform-Design (warum Control-Plane-Ereignisse außerhalb der Logging-Ebene liegen)
• IONOS CLOUD Architekturzentrum