Azure IaaS-Sicherheit wird als Schichtungssystem aufgebaut, bei dem der Ausfall einer Kontrolle nicht zur Kompromittierung der gesamten Plattform führt. Dies ist wichtig für die Widerstandsfähigkeit gegenüber modernen Angriffen, die gleichzeitig in mehreren Richtungen agieren.
Das Problem zeigt sich nicht sofort — bis zu dem Zeitpunkt, an dem das klassische Modell des „Perimeters“ nicht mehr funktioniert. In der Cloud sind Angriffe nicht mehr auf das Netzwerk beschränkt. Sie betreffen gleichzeitig Identität, Steuerungsebene, Lieferketten und Daten. In einem solchen Modell wird ein einzelner Schutzmechanismus zum Ausfallpunkt. Wenn er umgangen wird, breitet sich die Kompromittierung im gesamten System aus. Aus diesem Grund wird die Azure IaaS-Sicherheit von Anfang an als verteiltes Schutzsystem und nicht als Sammlung isolierter Funktionen aufgebaut.
Die Lösung basiert auf zwei Prinzipien: Defense in Depth und einheitliche Ingenieurpraktiken für Sicherheit. Defense in Depth ist hier kein Checkliste, sondern eine Architektur, bei der jede Schicht unabhängig ist und davon ausgeht, dass die benachbarte Schicht kompromittiert sein könnte. Gleichzeitig werden die Prinzipien der Secure Future Initiative angewendet: secure by design, secure by default und secure in operation. Dies legt nicht nur eine Reihe von Kontrollen fest, sondern auch Regeln für deren Implementierung und Betrieb. Dieser Ansatz ist ein Kompromiss zwischen strenger Sicherheit und operativer Flexibilität: Der Schutz wird verstärkt, jedoch ohne vollständigen Verlust der Steuerbarkeit.
Auf der Umsetzungsebene ist der Schutz über den gesamten Stack verteilt. Auf der untersten Ebene wird ein Hardware Root of Trust verwendet. Mechanismen wie TPM und Secure Boot überprüfen die Integrität der Firmware und der Bootkette vor dem Start des Workloads. Dies verringert das Risiko von Angriffen auf Firmware-Ebene, die von klassischen Mitteln nicht erkannt werden. Danach kommt der Hypervisor ins Spiel, der die Isolation von virtuellen Maschinen gewährleistet. Hier ist es wichtig, dass die Grenzen auf Plattformebene und nicht auf der Ebene des Gastbetriebssystems durchgesetzt werden.
Eine separate Schicht ist die Entlastung kritischer Funktionen. Azure lagert Storage, Networking und Management in spezialisierte Komponenten aus, wodurch die Angriffsfläche des Hosts verringert wird. Dies reduziert die Wahrscheinlichkeit von lateral movement zwischen Workloads und plattformbasierten Diensten. Für sensible Szenarien wird Confidential Computing hinzugefügt: Trusted Execution Environments und Speicherverschlüsselung (z. B. AMD SEV-SNP oder Intel TDX). In diesem Fall sind die Daten selbst während der Verarbeitung (data in use) geschützt, einschließlich des Schutzes vor dem Host und dem Hypervisor.
Die Netzwerkschicht folgt dem Zero Trust-Modell. Virtuelle Netzwerke sind standardmäßig isoliert. Eingehender Datenverkehr ist blockiert, bis er ausdrücklich erlaubt wird. NSGs führen stateful Filtering durch, während die Azure Firewall eine zentrale Kontrolle hinzufügt. Private Link beseitigt die Notwendigkeit öffentlicher Endpunkte. Dies verringert die Angriffsfläche, bevor benutzerdefinierte Regeln hinzugefügt werden. DDoS-Schutz funktioniert auf Plattformebene und erfordert keine separate Konfiguration, was für die grundlegende Widerstandsfähigkeit wichtig ist.
Die Datenspeicherung ist ebenfalls in das Modell secure-by-default integriert. Die Verschlüsselung at rest ist standardmäßig aktiviert. Es können platform-managed keys oder customer-managed keys über den Key Vault verwendet werden. Die Verschlüsselung in transit erfolgt innerhalb des Backbone-Netzwerks von Azure ohne zusätzliche Konfiguration. Dies beseitigt eine Klasse von Fehlern, bei denen der Schutz selektiv aktiviert oder vergessen wird.
Ein separater Aspekt ist die operationale Sicherheit (secure in operation). Hier spielt die Beobachtbarkeit (observability) eine Schlüsselrolle. Telemetrie aus Compute, Netzwerk und Storage wird in Azure Monitor und Defender for Cloud aggregiert. Diese Systeme analysieren das Verhalten, identifizieren Anomalien und finden Konfigurationsfehler. Zum Beispiel offene Management-Ports oder fehlende Festplattenschlüsselung. Wichtig ist, dass die Signale zwischen den Schichten korreliert werden und nicht isoliert betrachtet werden.
Identität wird zum zentralen Kontrollpunkt. Die Integration mit Microsoft Entra ID ermöglicht den Zugriff basierend auf dem Prinzip des geringsten Privilegs. Der Just-In-Time (JIT)-Ansatz beschränkt den Zugriff auf VMs zeitlich und kontextuell. Dies verringert das Risiko dauerhafter Privilegien und reduziert die Auswirkungen einer Kompromittierung von Anmeldeinformationen. In einem solchen Modell führt ein Angriff auf die Identität nicht zu sofortigem vollständigen Zugriff.
Das Ergebnis ist keine einzelne Sicherheitsfunktion, sondern ein kohärentes System. Defense in Depth begrenzt die Verbreitung von Vorfällen. Secure by design verringert die Angriffsfläche bereits in der Entwurfsphase. Secure by default reduziert die Wahrscheinlichkeit von Konfigurationsfehlern. Secure in operation gewährleistet die Anpassung an neue Bedrohungen. Dabei gibt es in den Ausgangsdaten keine konkreten Metriken zur Risikominderung oder zur Verbesserung der Kennzahlen, aber architektonisch ist das System darauf ausgelegt, Vorfälle zu lokalisieren und den Blast Radius zu verringern.
Letztendlich ist Azure IaaS-Sicherheit kein statisches Set von Funktionen, sondern ein Ingenieurmodell. Es skaliert mit der Infrastruktur und bleibt steuerbar. Genau das macht es anwendbar für hochbelastete und kritische Systeme, bei denen der Ausfall einer Schicht nicht zum Ausfall der gesamten Plattform führen sollte.