Cloud-Logs zentralisieren: AWS, Azure und Microsoft 365

Key Takeaways

• Verteilte Cloud-Logs sind ein blinder Fleck: Wer AWS, Azure und M365 getrennt betreibt, sieht anbieterübergreifende Angriffe nicht.
• AWS CloudTrail, Azure Monitor und das Microsoft 365 Unified Audit Log lassen sich technisch in ein gemeinsames SIEM überführen – ohne Vendor-Lock-in.
• NIS-2 und DSGVO verlangen nachweisbare Erkennungs- und Reaktionsfähigkeit. Zentrale Logs sind dafür die Grundvoraussetzung.
• Wazuh bietet für alle drei Plattformen native Integrationsmodule, die in KMU-Umgebungen produktiv einsetzbar sind.

---

Das Problem: Drei Plattformen, drei Silos

Ein typisches mittelständisches Unternehmen betreibt heute gleichzeitig Microsoft 365 für E-Mail und Kollaboration, Azure für einige VMs oder App-Services, und hat vielleicht noch eine AWS-Umgebung für ein spezifisches Entwicklungsprojekt oder einen SaaS-Dienst. Drei Cloud-Plattformen, drei separate Admin-Portale, drei Logging-Konzepte.

Das Problem: Ein Angreifer, der sich mit einem kompromittierten M365-Konto zunächst in SharePoint bewegt, dann über gespeicherte AWS-Zugangsdaten in den S3-Bucket wechselt und schließlich über eine Azure-VM lateral weiter im Netz navigiert, ist in keinem der drei Portale als zusammenhängender Vorfall sichtbar. Jedes System zeigt nur seinen eigenen Ausschnitt.

Genau das ist die Lücke, die Angreifer ausnutzen. Und genau das ist der Grund, warum Zentralisierung kein Nice-to-have ist.

---

Was jede Plattform nativ liefert

AWS CloudTrail

CloudTrail ist der primäre Audit-Log-Dienst in AWS. Er erfasst alle API-Aufrufe im AWS-Account – inklusive Managementkonsole, CLI und SDKs. Die wichtigsten Log-Typen:

• Management Events: Konfigurationsänderungen (IAM, Security Groups, S3-Bucket-Policies)
• Data Events: Zugriffe auf S3-Objekte oder Lambda-Funktionen (kostenpflichtig, nicht standardmäßig aktiv)
• Insights Events: Erkennung ungewöhnlicher API-Nutzungsmuster

CloudTrail schreibt standardmäßig in einen S3-Bucket. Von dort können die JSON-Log-Dateien von einem SIEM-Agenten abgeholt werden.

Beispiel eines CloudTrail-Eintrags (gekürzt):

{
  "eventVersion": "1.08",
  "userIdentity": {
    "type": "IAMUser",
    "userName": "deploy-service"
  },
  "eventName": "DeleteBucketPolicy",
  "sourceIPAddress": "198.51.100.42",
  "userAgent": "aws-cli/2.15.0",
  "requestParameters": {
    "bucketName": "prod-backups-eu"
  },
  "eventTime": "2026-05-22T03:17:44Z"
}

Ein DeleteBucketPolicy um 3 Uhr morgens ist ein klassisches Alarmsignal – ohne zentrales SIEM sieht das kein Mensch.

Azure Monitor & Entra ID-Logs

Azure liefert Logs über mehrere Quellen:

• Azure Activity Log: Konfigurationsänderungen auf Subscription-Ebene (VM-Starts, RBAC-Zuweisungen, Netzwerkänderungen)
• Entra ID (ehemals Azure AD) Sign-in Logs: Alle Anmeldeversuche inklusive MFA-Status, Conditional-Access-Ergebnis, Standort
• Entra ID Audit Logs: Benutzer- und Gruppenänderungen, App-Registrierungen
• Microsoft Defender for Cloud Alerts: Sicherheitswarnungen aus der Azure-Workload-Schutzebene

Die nativste Weiterleitungsmöglichkeit ist der Diagnostic Settings-Export in einen Event Hub oder direkt in einen Log Analytics Workspace. Der Event Hub ist dabei der bevorzugte Weg für externe SIEM-Systeme, da er hohen Durchsatz bei niedrigerer Latenz bietet.

Microsoft 365 Unified Audit Log

Das Unified Audit Log (UAL) ist die zentrale Ereignisquelle für alle M365-Dienste:

• Exchange Online (E-Mail-Zugriffe, Weiterleitungsregeln, Postfachzugriffe)
• SharePoint & OneDrive (Datei-Downloads, externe Freigaben)
• Teams (Nachrichten, Meeting-Einladungen an externe Teilnehmer)
• Entra ID (Anmeldungen, MFA-Änderungen)
• Power Automate, Power Apps (Flow-Ausführungen mit externen Connectors)

Kritisch zu wissen: Das UAL muss in vielen Tenants erst manuell aktiviert werden. Den Status prüft man über PowerShell:

Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled

Ist der Wert False, sind seit Monaten möglicherweise keine Audit-Logs erfasst worden. Aktivierung:

Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

---

Architektur: Wie die Zusammenführung technisch aussieht

Eine bewährte Architektur für KMU mit begrenzten Ressourcen sieht so aus:

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   AWS Account   │    │  Azure Tenant   │    │  M365 Tenant    │
│                 │    │                 │    │                 │
│  CloudTrail     │    │  Event Hub      │    │  Unified Audit  │
│  → S3 Bucket    │    │  (Diag.Settings)│    │  Log API        │
└────────┬────────┘    └────────┬────────┘    └────────┬────────┘
         │                      │                      │
         └──────────────────────┴──────────────────────┘
                                │
                    ┌───────────▼───────────┐
                    │    Wazuh Manager      │
                    │  (on-prem oder VM)    │
                    │                       │
                    │  - S3-Modul (AWS)     │
                    │  - Azure-Modul        │
                    │  - M365-Modul         │
                    └───────────┬───────────┘
                                │
                    ┌───────────▼───────────┐
                    │   OpenSearch /        │
                    │   Wazuh Dashboard     │
                    │   (Alerting, SIEM)    │
                    └───────────────────────┘

Wazuh-Konfiguration: AWS CloudTrail über S3

In der Wazuh-Konfigurationsdatei ossec.conf wird das AWS-Modul aktiviert:

<wodle name="aws-s3">
  <disabled>no</disabled>
  <interval>5m</interval>
  <run_on_start>yes</run_on_start>
  <bucket type="cloudtrail">
    <name>mein-cloudtrail-bucket-eu</name>
    <aws_profile>wazuh-readonly</aws_profile>
    <regions>eu-central-1,eu-west-1</regions>
  </bucket>
</wodle>

Der IAM-User wazuh-readonly benötigt ausschließlich s3:GetObject und s3:ListBucket auf den CloudTrail-Bucket. Kein weiterer Zugriff erforderlich – Least-Privilege-Prinzip.

Wazuh-Konfiguration: Azure via Event Hub

<wodle name="azure-logs">
  <disabled>no</disabled>
  <interval>5m</interval>
  <run_on_start>yes</run_on_start>
  <log_analytics>
    <auth_path>/var/ossec/wodles/credentials/azure_credentials</auth_path>
    <tenantdomain>meinunternehmen.onmicrosoft.com</tenantdomain>
    <request>
      <tag>azure-activity</tag>
      <query>AzureActivity | where TimeGenerated > ago(5m)</query>
      <time_offset>5m</time_offset>
    </request>
  </log_analytics>
</wodle>

Microsoft 365 Logs via Wazuh-Modul

Das M365-Modul in Wazuh nutzt die Microsoft Graph API:

<wodle name="ms365">
  <disabled>no</disabled>
  <interval>5m</interval>
  <api_auth>
    <tenant_id>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</tenant_id>
    <client_id>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</client_id>
    <client_secret>GEHEIMNIS_AUS_KEY_VAULT</client_secret>
  </api_auth>
  <api_type>management</api_type>
</wodle>

Wichtig: Der Service-Principal in Entra ID benötigt die Application Permission ActivityFeed.Read – keine delegierte Berechtigung, sondern eine App-Berechtigung mit Admin-Consent.

---

Korrelationsregeln: Was man tatsächlich erkennen kann

Erst wenn alle drei Log-Quellen im selben System landen, werden plattformübergreifende Angriffsmuster sichtbar. Einige Beispiele:

Szenario 1: Credential Stuffing → AWS-Zugriff M365-Log zeigt 50 fehlgeschlagene Logins auf admin@firma.de in 10 Minuten. Kurz darauf erscheint im CloudTrail ein erfolgreicher API-Call von einer neuen IP mit dem gleichen Benutzernamen als Grundlage. Ohne Korrelation: zwei unauffällige Einzelereignisse. Mit Korrelation: Brute-Force mit anschließendem Erfolg.

Szenario 2: Exfiltration über M365 Azure-Log meldet einen neuen Service-Principal mit weitreichenden Rechten. M365-Log zeigt kurz darauf, dass derselbe Principal massenweise SharePoint-Dateien herunterlädt. Typisches Muster für einen kompromittierten OAuth-Token nach einer Phishing-Kampagne.

Szenario 3: Persistenz über IAM CloudTrail meldet CreateAccessKey für einen bestehenden IAM-User außerhalb der Geschäftszeiten. Gleichzeitig meldet Entra ID, dass der entsprechende Benutzer gerade aus einem fremden Land angemeldet ist. Mögliche Kompromittierung mit Persistenz-Einrichtung.

Für Szenario 3 ließe sich in Wazuh eine eigene Korrelationsregel schreiben:

<rule id="100501" level="12">
  <if_matched_sid>80202</if_matched_sid>
  <!-- 80202 = Wazuh-Regel für CloudTrail CreateAccessKey -->
  <description>IAM Access Key erstellt während Entra-Login aus unbekanntem Land</description>
  <mitre>
    <id>T1098</id> <!-- Account Manipulation -->
  </mitre>
</rule>

---

NIS-2 und DSGVO: Was die Zentralisierung regulatorisch erfüllt

NIS-2 (in Deutschland umgesetzt durch das NIS2UmsuCG) verpflichtet betroffene Einrichtungen zu technischen Maßnahmen zur Angriffserkennung, zur Vorfallsreaktion und zur Dokumentation. Ein zentrales Logging-System adressiert alle drei Anforderungen direkt:

Anforderung	Technische Umsetzung
Angriffserkennung	Korrelationsregeln über alle Plattformen
Incident Response	Vollständige Log-Timeline für Forensik
Dokumentationspflicht	Unveränderliche Log-Archivierung (S3 Object Lock, WORM)
Meldepflicht (24h)	Automatische Alerting-Workflows

Aus DSGVO-Perspektive ist die Zentralisierung ein zweischneidiges Schwert: Einerseits erlaubt sie den Nachweis technischer Schutzmaßnahmen nach Art. 32 DSGVO. Andererseits konzentriert sie personenbezogene Daten aus Logs (Benutzernames, IP-Adressen, Zugriffszeiten) an einem Ort. Das Verarbeitungsverzeichnis muss aktualisiert, Löschfristen definiert und der Zweck der Verarbeitung dokumentiert werden.

Empfehlung: Logs, die personenbezogene Daten enthalten, nach maximal 90 Tagen in einem separaten Cold-Storage-Bucket archivieren und nach 12 Monaten löschen – sofern keine laufenden Ermittlungen das Gegenteil erfordern.

---

Typische Fehler bei der Einführung

Fehler 1: Nur Management Events in CloudTrail aktiviert Data Events (S3-Objektzugriffe, Lambda-Aufrufe) sind teuer, aber für Exfiltrations-Erkennung unverzichtbar. Lösung: Selektiv nur für kritische Buckets und Funktionen aktivieren.

Fehler 2: Entra ID Sign-in Logs nicht exportiert Standardmäßig werden nur 30 Tage Sign-in-Logs in Azure gespeichert. Ohne Export in ein externes System sind historische Korrelationen nach einem Monat unmöglich.

Fehler 3: M365 Unified Audit Log nicht aktiviert Wie oben beschrieben: Muss explizit eingeschaltet werden. In der Praxis ist es in überraschend vielen Tenants deaktiviert.

Fehler 4: Keine Alerting-Schwellen definiert Ein SIEM ohne Alarme ist ein teures Archiv. Mindestens diese Regeln sollten sofort alert-fähig sein: Root-Login in AWS, MFA-Deaktivierung in Entra ID, neue externe E-Mail-Weiterleitungsregel in Exchange.

Fehler 5: Log-Integrität nicht sichergestellt CloudTrail-Logs sollten mit Log File Integrity Validation gespeichert werden. Wazuh selbst bietet File Integrity Monitoring für lokal gespeicherte Log-Dateien. Ohne Integritätsprüfung sind Logs als Beweismittel bei einem Sicherheitsvorfall wertlos.

---

Schnell-Checkliste für den Einstieg

• CloudTrail in allen AWS-Regionen aktiviert (inkl. globaler Services)
• CloudTrail Log File Integrity Validation aktiviert
• S3-Bucket für CloudTrail mit Object Lock (WORM) gesichert
• M365 Unified Audit Log aktiviert (Get-AdminAuditLogConfig)
• Azure Diagnostic Settings für Entra ID und Activity Log auf Event Hub konfiguriert
• Wazuh-Module für AWS, Azure, M365 konfiguriert und getestet
• Mindestens 5 kritische Alerting-Regeln aktiv
• Lösch- und Archivierungsfristen dokumentiert (DSGVO)
• Verarbeitungsverzeichnis aktualisiert

---

Fazit

Cloud-Log-Zentralisierung ist keine akademische Übung. Sie ist die operative Voraussetzung dafür, dass ein kleines IT-Team überhaupt in der Lage ist, einen Angriff zu erkennen, der sich über mehr als eine Plattform erstreckt. Die Technik ist verfügbar, die APIs sind dokumentiert, und Open-Source-Tools wie Wazuh senken die Einstiegshürde erheblich.

Der eigentliche Aufwand liegt nicht in der Einrichtung, sondern in der kontinuierlichen Pflege: Regeln aktualisieren, neue Log-Quellen integrieren, Alerting-Schwellen anpassen und Logs auswerten, wenn ein Alarm ausgelöst wird. Wer das intern nicht dauerhaft leisten kann, sollte prüfen, ob ein Managed-SIEM-Dienst diese Aufgabe übernehmen kann.

Vyrex Security betreibt genau diese Infrastruktur als managed Service: AWS CloudTrail, Azure Monitor und Microsoft 365 Audit-Logs werden in einem zentralen Wazuh-basierten SIEM zusammengeführt, rund um die Uhr durch ein SOC-Team überwacht und auf NIS-2-Compliance ausgerichtet. Wer wissen möchte, wie das konkret für die eigene Umgebung aussieht, findet auf vyrex.cloud einen kostenlosen technischen Erstkontakt ohne Verkaufsgespräch.