In vielen Azure-Umgebungen, die ich betreue, gehört Azure Trusted Launch längst zum Alltag, zumindest bei neu bereitgestellten virtuellen Maschinen der Generation 2. Vor ein paar Jahren galt die Funktion noch als optionale Sicherheitsfunktion, heute ist sie Standard. Wer im Azure-Portal eine neue Windows- oder Linux-VM (Gen2) anlegt, bekommt Trusted Launch fast immer automatisch aktiviert. Secure Boot, ein virtuelles TPM und die Bootintegritätsüberwachung sind damit an Bord und lassen sich direkt über Defender for Cloud verwalten. Trotzdem tauchen in Projekten immer wieder dieselben Fragen auf. Man will wissen, warum ältere Maschinen unsicher konfiguriert sind, was sich an Backup und Imagestrategie ändert und wie man von Gen1 auf Trusted Launch kommt, ohne irgendwo hängen zu bleiben.

Trusted Launch holt Secure Boot und TPM in die virtuelle Maschine

Mit Trusted Launch landen zentrale Schutzmechanismen physischer Hardware endlich zuverlässig in Azure-VMs, also Secure Boot, TPM und die Messung der Startkette. Technisch handelt es sich um UEFI Secure Boot, ein virtualisiertes TPM (vTPM) und die Möglichkeit, die Integrität des VM-Starts mit Microsoft Defender for Cloud zu überwachen. In Multi-Tenant-Cloud-Umgebungen kommt man um einen Schutz vor Bootkits und Rootkits nicht herum. Hinzu kommt, dass viele moderne Anwendungen und Windows-Sicherheitsfunktionen wie BitLocker ein vTPM schlicht voraussetzen. Offiziell gilt Trusted Launch für alle unterstützten Gen2-VM-Größen, die die älteren Gen1-VMs zunehmend ablösen. Die genauen Anforderungen, etwa zu unterstützten Images und Größen, dokumentiert Microsoft selbst (Übersicht zu Trusted Launch).

Neue VMs starten mit Trusted Launch, alte brauchen ein Upgrade

Im letzten Jahr hat sich vor allem eines geändert: Für die meisten Gen2-VMs ist Trusted Launch inzwischen voreingestellt, sofern man sie über das Azure-Portal oder ARM-Vorlagen bereitstellt. Im Portal findet sich die Option beim Anlegen der VM im Schritt „Sicherheit“, wo sie meist schon ausgewählt ist. Wer noch Gen1-VMs betreibt, hat zwei Aufgaben vor sich. Zuerst muss die Maschine auf Gen2 umziehen, und das geht nicht mit einem Klick. Die VM braucht ein unterstütztes Betriebssystem mit GPT-Partitionstabelle statt MBR. Microsoft empfiehlt, das Layout der OS-Disk innerhalb des Betriebssystems mit dem Tool MBR2GPT.exe umzuwandeln. Nach der Konvertierung lässt sich im Azure-Portal unter VM → Konfiguration → Sicherheitstyp der Schalter für Trusted Launch umlegen. Den genauen Ablauf hat Microsoft ausführlich beschrieben. Allerdings wird nicht jede VM-Größe sofort unterstützt, und bei spezialisierten Images wie selbst gebauten Marketplace-Images oder alten Linux-Distributionen gibt es häufiger Probleme. In meinen Projekten scheitert die Umstellung vor allem an Altsystemen mit Legacy-Workloads oder Agenten von Drittanbietern.

Bevor man umstellt, sollte man deshalb genau prüfen, ob alle eingesetzten Agenten, Backup-Tools und Erweiterungen mit UEFI und vTPM klarkommen. Backup-Software und Monitoring-Agenten, die tief in den Bootprozess eingreifen, sind hier die üblichen Verdächtigen.

Defender for Cloud überwacht die Integrität des Startvorgangs

Ein großer Vorteil von Trusted Launch liegt in der engen Verzahnung mit Microsoft Defender for Cloud. Nutzt eine VM Secure Boot und vTPM, lässt sich die Überwachung der Bootintegrität einschalten. Defender kontrolliert dann bei jedem Start, ob Bootloader, Kernel-Komponenten und kritische Treiber im erwarteten Zustand sind. Weicht etwas ab, etwa durch Malware, ein fehlerhaftes Update oder einen Bedienfehler, meldet Defender das als Warnung, die sich automatisiert weiterverarbeiten lässt.

Das folgende Diagramm zeigt das Zusammenspiel von Trusted Launch, Defender und dem Lebenszyklus der VM:

flowchart TD
    CreateVM["Neue Gen2-VM erstellen"] --> EnableTL["Trusted Launch aktivieren"]
    EnableTL --> SecureBoot["Secure Boot und vTPM aktiv"]
    SecureBoot --> DefenderBootMon["Defender Bootintegritätsüberwachung"]
    DefenderBootMon --> Alert["Alarm bei Manipulation"]
    Alert --> Remediation["Analyse oder Gegenmaßnahme"]

Abbildung: Trusted Launch schaltet bei Gen2-VMs die Sicherheitsfunktionen und die Bootintegritätsüberwachung in Defender for Cloud frei.

Eingeschaltet wird die Bootintegritätsüberwachung unter Defender for Cloud → Workloads → Virtual Machines in den Details der jeweiligen VM. Lizenzseitig braucht man mindestens Defender for Servers Plan 2.

Praxistipp: „Wer Azure Backup zusammen mit Trusted Launch einsetzt, sollte gerade bei älteren Recovery Points prüfen, ob sie den Wechsel von Gen1 auf Gen2 und vTPM mitmachen. Eine alte MBR-basierte Disk lässt sich auf einer Trusted-Launch-VM nicht ohne Weiteres wiederherstellen, deshalb unbedingt vorher testen.“

Azure Policy zeigt, welchen VMs Trusted Launch noch fehlt

In gewachsenen Umgebungen weiß kaum jemand genau, auf welchen Maschinen Trusted Launch schon läuft und auf welchen nicht. Den schnellsten Überblick liefert Azure Policy. Microsoft stellt eine fertige Policy-Definition bereit, die alle VMs ohne Trusted Launch auflistet. Sie liegt im Azure-Portal unter „Policy“ → „Definitionen“ (Suchbegriff „Trusted Launch audit“) und wird als Initiative auf Subscription- oder Managementgruppenebene zugewiesen. Aus der Auswertung geht schnell hervor, wo man nacharbeiten muss. Alternativ kann man im Portal gezielt nach dem „Sicherheitstyp“ der VM-Objekte filtern.

Wer lieber mit PowerShell arbeitet (mindestens Az-Modul 10.0, Rolle Reader oder höher), braucht nur eine kurze Abfrage:

Get-AzVM | Where-Object { $_.SecurityProfile.SecurityType -ne "TrustedLaunch" }

Gerade beim Audit größerer Umgebungen oder für ein gezieltes Reporting ist das sehr praktisch.

Mit Trusted Launch ändern sich Backup- und Imagestrategie

Wer Trusted Launch konsequent einsetzt, muss auch den Lebenszyklus der VMs an einigen Stellen anpassen. Bei Backups lässt sich nicht jedes alte Abbild und nicht jeder Recovery Point direkt auf einer Trusted-Launch-VM wiederherstellen, besonders dann nicht, wenn die Sicherung von einer Gen1-VM mit MBR stammt. Im Azure Backup Center sollte man daher vor der produktiven Migration nachsehen, auf welchem Disk-Layout die jeweilige Sicherung beruht. Bei Images bietet die Azure Compute Gallery die Möglichkeit, eigene Images als Gen2 mit aktiviertem Trusted Launch zu veröffentlichen. Jede daraus bereitgestellte VM startet dann geschützt. Dieses Vorgehen hat sich inzwischen als Best Practice durchgesetzt und erleichtert Standardisierung und Compliance auch in großen Umgebungen. Hybride Szenarien, die von Trusted Launch profitieren, behandle ich übrigens im Beitrag Windows Server 2025: Wichtige Neuerungen für hybride Admins.

Trusted Launch wird zur Baseline, verlangt aber Aufräumarbeit

Azure Trusted Launch ist keine Zukunftsmusik mehr. Spätestens 2025 gehört es zur Baseline für virtuelle Maschinen in produktiven Cloud-Umgebungen. Die Aktivierung selbst ist technisch schnell erledigt. Die eigentliche Arbeit steckt in den Altlasten: Partitionstabellen konvertieren, Images anpassen, die Kompatibilität der Agenten sicherstellen und die Backup-Strategie kritisch durchgehen. Wer das sorgfältig erledigt, bekommt neben mehr Sicherheit auch eine übersichtlichere und einheitlichere Umgebung. In meinen Projekten ist Trusted Launch inzwischen Pflicht für alle produktiven Gen2-VMs in Azure, und ich wette, daran wird sich nichts mehr ändern.