Cloud-native SOC-Architektur für AWS- und Azure-Umgebungen

Werkzeug-Landschaft: AWS vs. Azure im direkten Vergleich

Beide großen Hyperscaler bieten heute ein vollständiges Ökosystem für cloud-native SOC-Architekturen. Die folgende Tabelle zeigt die wichtigsten Dienste und ihre funktionalen Entsprechungen:

Ein entscheidender Unterschied liegt in der Datenarchitektur: AWS Security Lake nutzt das offene OCSF-Schema (Open Cybersecurity Schema Framework) und ermöglicht so die Integration von Drittanbietern ohne proprietäre Konnektoren. Microsoft Sentinel hingegen bietet eine deutlich umfangreichere Bibliothek vorgefertigter Analyse-Regeln (Analytics Rules) und Workbooks, was den initialen Aufwand für Detection Engineering reduziert.

Referenzarchitektur für eine duale AWS-/Azure-Umgebung

Die meisten DACH-Unternehmen betreiben heute keine reine Single-Cloud-Strategie. Eine praxisnahe Referenzarchitektur für eine AWS-/Azure-Hybridumgebung sieht folgendermaßen aus:

Schicht 1 – Log-Normalisierung und Transport

Auf AWS werden CloudTrail-, VPC-Flow-Logs und GuardDuty-Findings über Amazon Kinesis Data Streams in den AWS Security Lake geleitet. Auf Azure sammelt der Microsoft Monitoring Agent (bzw. der Azure Monitor Agent) Aktivitätsprotokolle, Defender-Alerts und Entra-ID-Signalome im Log Analytics Workspace. Beide Ströme werden über einen zentralen Forwarding-Layer – realisierbar mit Terraform-verwalteten Ressourcen – in ein gemeinsames SIEM-Backend oder in Microsoft Sentinel als primäre Korrelationsplattform zusammengeführt.

Schicht 2 – Detection und Korrelation

Microsoft Sentinel empfängt Ereignisse beider Plattformen über Data Connectors und wendet plattformübergreifende KQL-Abfragen (Kusto Query Language) an. Ergänzend dazu laufen AWS-native Erkennungsregeln in GuardDuty weiter; kritische Findings werden per EventBridge-Regel und Lambda-Funktion automatisch als Incidents in Sentinel überführt. So entsteht eine einheitliche Sicht auf den gesamten Angriffspfad (Attack Path), unabhängig davon, ob der Einstiegspunkt in AWS oder Azure liegt.

Schicht 3 – Response-Automatisierung

Sentinel Playbooks (basierend auf Azure Logic Apps) übernehmen standardisierte Reaktionen: Isolation kompromittierter EC2-Instanzen über AWS Systems Manager, Sperrung von Entra-ID-Konten, automatische Erstellung von Tickets im ITSM-System und Benachrichtigung des 24/7-SOC-Teams. Für Kubernetes-Workloads – sowohl auf Amazon EKS als auch auf Azure AKS – kommt Falco als Laufzeit-Erkennung zum Einsatz; Backup und Recovery kritischer Cluster-Zustände erfolgt über Velero.

Schicht 4 – Compliance und Auditierung

Terraform-Module codieren BSI-Grundschutz-konforme Baseline-Konfigurationen (z. B. verschlüsselte S3-Buckets, erzwungene MFA, Azure Policy-Definitionen für CIS-Benchmarks). AWS Config und Azure Policy prüfen kontinuierlich Abweichungen und melden diese direkt an Security Hub bzw. Defender for Cloud. Für NIS2-Meldepflichten werden Incident-Zeitstempel, betroffene Assets und Eskalationsketten automatisch protokolliert und in unveränderlichen S3- oder Azure Blob Storage-Buckets archiviert.

Anwendungsfälle im DACH-Kontext

Die folgenden Szenarien illustrieren, wo eine cloud-native SOC-Architektur in der Praxis konkreten Mehrwert gegenüber klassischen Ansätzen liefert:

• DSGVO-Datenpannenmeldung innerhalb von 72 Stunden: Automatisierte Erkennung von Zugriffen auf personenbezogene Daten (z. B. ungewöhnliche S3-GetObject-Aufrufe auf DSGVO-klassifizierte Buckets) und sofortige Eskalation reduzieren die mittlere Reaktionszeit (MTTD/MTTR) drastisch.
• NIS2-Nachweispflichten für kritische Infrastruktur: Unveränderliche Audit-Trails in AWS Security Lake erfüllen die Anforderungen an Protokollintegrität und -verfügbarkeit gemäß NIS2 Art. 21.
• BSI-Grundschutz-Bausteine OPS.1.1.5 / OPS.1.1.6: Sicherheitsrelevante Ereignisse werden lückenlos erfasst und mindestens 90 Tage vorgehalten – ohne manuell gewartete Log-Server.
• Multi-Tenant-SaaS-Anbieter: Mandantentrennung auf Log-Ebene über AWS Lake Formation Row-Level Security oder Sentinel-Workspace-Segmentierung verhindert Datenlecks zwischen Kundendaten.

Häufige Fehler bei der Implementierung

Trotz ausgereifter Werkzeuge scheitern viele Projekte an denselben vermeidbaren Problemen:

• Ungefilterte Log-Ingestion: Das unkritische Einleiten aller verfügbaren Logs in Sentinel oder OpenSearch führt zu explodierenden Kosten und überlasteten Analysten. Eine Log-Taxonomie (welche Quellen sind sicherheitsrelevant, welche operativ?) muss vor der Implementierung festgelegt werden.
• Fehlende Detection-Engineering-Disziplin: Vorgefertigte Regelwerke aus dem Sentinel Content Hub werden ungeprüft aktiviert. Die Folge: eine hohe False-Positive-Rate, die Analysten abstumpft (Alert Fatigue). Jede Regel benötigt einen definierten Schwellenwert, eine Tuning-Periode und einen Owner.
• Keine plattformübergreifende Asset-Inventarisierung: GuardDuty-Findings referenzieren AWS-Ressourcen-IDs, Defender-Alerts Azure-Ressourcen-IDs. Ohne ein gemeinsames CMDB oder Asset-Mapping entstehen blinde Flecken bei der Angriffspfadanalyse.
• Terraform-State ohne Schutz: Der Terraform-State enthält oft Secrets und Konfigurationsdetails. Remote State in einem verschlüsselten S3-Bucket mit DynamoDB-Locking oder in Azure Blob Storage mit Zugriffskontrolle ist Pflicht, kein Opt-in.
• Vernachlässigte Kubernetes-Laufzeitsicherheit: CKA/CKAD-zertifizierte Teams wissen: RBAC-Konfiguration und Netzwerkrichtlinien reichen allein nicht aus. Laufzeitanomalien auf Pod-Ebene erfordern dedizierte Werkzeuge wie Falco oder Defender for Containers.

Opsios Leistungsangebot: Cloud-native SOC für AWS und Azure

Opsio ist AWS Advanced Tier Services Partner mit ausgewiesener AWS Migration Competency sowie Microsoft Partner und Google Cloud Partner. Das bedeutet in der Praxis: Die mehr als 50 zertifizierten Engineers – darunter CKA/CKAD-zertifizierte Kubernetes-Spezialisten – kennen die Eigenheiten beider Hyperscaler aus über 3.000 Projekten seit 2022.

Für DACH-Unternehmen, die eine cloud-native SOC-Architektur aufbauen oder modernisieren wollen, bietet Opsio folgende konkrete Leistungen:

• SOC-Readiness-Assessment: Analyse der bestehenden Log-Quellen, Detection-Coverage und Compliance-Lücken gegenüber DSGVO, BSI-Grundschutz und NIS2 – mit priorisierten Handlungsempfehlungen.
• Referenzarchitektur-Design und Terraform-Implementierung: Alle Sicherheitsressourcen auf AWS und Azure werden als versionierter, wiederverwendbarer Terraform-Code bereitgestellt – keine manuellen Konsolen-Konfigurationen, kein Konfigurationsdrift.
• Detection Engineering: Entwicklung und Tuning plattformübergreifender KQL- und Sigma-Regeln, angepasst an die spezifische Bedrohungslandschaft des Kunden, mit definierten False-Positive-Quoten.
• 24/7-NOC-Betrieb: Opsios NOC überwacht Kundenumgebungen rund um die Uhr mit einem garantierten Uptime-SLA von 99,9 %. Incidents werden nach festgelegten Eskalationsmatrizen behandelt und dokumentiert.
• Compliance-Automatisierung: Terraform-Module für BSI-Grundschutz-konforme Baselines, automatisierte Drift-Erkennung über AWS Config und Azure Policy sowie revisionssichere Archivierung für NIS2-Nachweispflichten.

Opsio hilft Kunden außerdem dabei, die Voraussetzungen für eine SOC-2-Zertifizierung zu schaffen – von der technischen Kontrollenimplementierung bis zur Dokumentation der Trust Service Criteria. Die Kombination aus Standort Karlstad (Schweden) und dem Delivery-Center in Bangalore ermöglicht dabei zeitzonenübergreifende Projektkontinuität bei gleichzeitiger europäischer Verankerung.

Eine cloud-native SOC-Architektur ist kein einmaliges Projekt, sondern ein kontinuierlicher Betrieb. Unternehmen im DACH-Raum, die regulatorische Anforderungen sicher erfüllen und gleichzeitig ihre Erkennungs- und Reaktionsfähigkeit skalieren wollen, profitieren von einem Partner, der beide Hyperscaler-Ökosysteme gleichermaßen beherrscht – und der die spezifischen Anforderungen des deutschen Marktes nicht als Randnotiz, sondern als Kernbestandteil jeder Architekturentscheidung behandelt.