Im Dialog zur Erstellung einer virtuellen Maschine im Azure-Portal taucht seit Kurzem ein neues Optionenfeld auf: das Metadatensicherheitsprotokoll. Die kurze Beschreibung klingt zunächst technisch und abstrakt. Hinter dem Feature steckt jedoch eine konkrete und wichtige Sicherheitsverbesserung für Azure Virtual Machines.
In jeder Azure-VM laufen zwei kritische Host-Endpunkte: der „WireServer“ (168.63.129.16) und der Instance Metadata Service (IMDS). Über diese Dienste holen sich Anwendungen und Dienste innerhalb der virtuellen Maschine Metadaten und Zugangsdaten, zum Beispiel Tokens für Managed Identities. Bisher waren diese Endpunkte innerhalb der VM weitgehend unauthentifiziert erreichbar. Jede Software, die in der Maschine lief, konnte potenziell darauf zugreifen.
Angreifer nutzten genau diese offene Architektur in der Vergangenheit häufig aus. Angreifer nutzten typischerweise Confused-Deputy-Angriffe, SSRF-Exploits oder das Ausbrechen aus Sandboxes, besonders in verschachtelter Virtualisierung oder bei Workloads mit fremdem Code. Die Vertrauensgrenze lag letztlich bei der gesamten VM – und das erwies sich in der Praxis als zu grob.
Wie das Metadatensicherheitsprotokoll funktioniert
Das Metadata Security Protocol (MSP) schließt genau diese Lücke. Beim Aktivieren installiert sich ein Guest Proxy Agent in der VM. Dieser Agent nutzt eBPF, um Anfragen an die beiden Host-Endpunkte abzufangen und die Identität des aufrufenden Prozesses zu prüfen. Der Host und der Agent handeln ein langlebiges Geheimnis aus. Jede Anfrage muss anschließend vom Agent per HMAC signiert werden, bevor der Host sie akzeptiert.
Damit wechselt Azure von einem standardmäßig offenen Modell zu einem standardmäßig geschlossenen. Nur authentifizierte und autorisierte Anwendungen erhalten Zugriff. Die Durchsetzung ist deutlich robuster als die bisherigen Firewall-Regeln im Gastbetriebssystem, die sich unter Umständen umgehen ließen.
Die verfügbaren Modi
Pro Endpunkt (WireServer und IMDS) lassen sich drei Modi einstellen.
- Im Disabled-Modus bleibt alles beim bisherigen Verhalten.
- Der Audit-Modus protokolliert sämtliche Zugriffe, lässt sie aber noch durch.
- Im Enforce-Modus werden nur autorisierte Anfragen weitergeleitet; alle anderen werden mit einem Fehlercode abgelehnt. Standardmäßig entspricht das Verhalten zunächst dem alten Modell, allerdings mit einer deutlich sichereren technischen Grundlage. Wer möchte, kann später noch feinere Regeln über eine eigene Allowlist definieren und so den Zugriff auf einzelne Prozesse und Endpunkte beschränken.
Was bedeutet das konkret für den Betrieb?
In den meisten Fällen lohnt es sich, das Feature zu nutzen – allerdings schrittweise und mit Bedacht. Der empfohlene Einstieg ist der Audit-Modus. Er verändert nichts am laufenden Betrieb, liefert aber wertvolle Logs darüber, welche Prozesse tatsächlich auf die Endpunkte zugreifen. Die Protokolle liegen lokal auf dem System und geben einen klaren Überblick über legitime Nutzung und mögliche Auffälligkeiten.
Nach der Auswertung der Logs können unerwartete Zugriffe geklärt und behoben werden. Anschließend lässt sich auf den Enforce-Modus umschalten. Wer noch strenger absichern möchte, kann in einem weiteren Schritt eine individuelle Allowlist erstellen und so das Prinzip der geringsten Rechte umsetzen.
Vor der Aktivierung sollte die Kompatibilität geprüft werden. Unterstützt werden derzeit unter anderem aktuelle Windows-Versionen und Ubuntu ab 20.04 sowie Azure Linux. Bestimmte Distributionen wie RHEL 9, Rocky Linux oder SUSE sowie Szenarien mit ephemeral Disks und Azure Backup sind noch nicht oder nur eingeschränkt freigegeben. Auch die ARM64-Unterstützung ist nicht in allen Fällen vollständig.
Fazit
Das Metadatensicherheitsprotokoll ist kein kosmetisches Update, sondern schließt bekannte und real genutzte Angriffswege. Wer es im Audit-Modus startet, gewinnt Transparenz ohne Risiko. Der Wechsel auf Enforce erhöht den Schutz spürbar. Für die meisten Workloads ist das Feature daher eine klare Empfehlung – vorausgesetzt, die eingesetzte Betriebssystemversion und die eingesetzten Dienste sind kompatibel.
Wer das Feature im Escher-Portal beim Erstellen einer neuen VM sieht, kann es dort direkt aktivieren. Bei bestehenden Maschinen geht die Konfiguration über das Azure-Portal, ARM-Templates oder die entsprechenden APIs.