In vielen Tenants, die ich betreue, gehört Azure Virtual Desktop inzwischen fest zum sicheren Modern Workplace. Beim Thema Sicherheit bleibt es allerdings oft bei Standardmaßnahmen wie MFA für das Entra-ID-Konto. Wer genauer hinschaut, stellt schnell fest, dass das gegen echte Angriffsvektoren nicht genügt. Zur Sicherheit von Azure Virtual Desktop gehören neben Identitätsschutz und Conditional Access auch gezielte Einschränkungen bei Sitzungen, Netzwerkzugriff und Datenabfluss. In diesem Beitrag zeige ich aus der Praxis, welche Härtungsoptionen für AVD tatsächlich etwas bringen und wie ich sie bei Kunden umsetze.

Conditional Access sichert die Azure-Virtual-Desktop-App über MFA hinaus ab

Conditional Access bleibt die wichtigste Kontrollebene. Für AVD lege ich eine eigene Richtlinie an, die gezielt die Anwendung „Azure Virtual Desktop“ (Client und Web) adressiert. MFA bei jeder Anmeldung ist dabei das Mindeste und sollte heute ohnehin selbstverständlich sein. Meist gehe ich aber einen Schritt weiter und setze die Anmeldehäufigkeit auf 8 Stunden oder weniger. Damit begrenze ich Token-Lifetime-Angriffe und dauerhafte Authentifizierung. Bei besonders schützenswerten Pools kann sich außerdem ein Authentifizierungskontext lohnen, etwa wenn hochsensible Umgebungen strengere Anforderungen erfüllen müssen. Ausführlicher gehe ich darauf in meinem Beitrag zu Authentifizierungskontexten im Conditional Access ein.

Praxis-Tipp: Prüft genau, dass die Richtlinie ausschließlich die AVD-Anwendung betrifft und nicht aus Versehen auch andere Azure-Apps, zum Beispiel den klassischen Zugriff auf das Azure-Portal. Andernfalls habt ihr schnell die ersten Supporttickets auf dem Tisch!

Eingerichtet wird das wie gewohnt im Entra-Portal unter „Conditional Access“. Für MFA reichen Lizenzen für Microsoft Entra ID P1. Wer Authentifizierungskontexte und eine feinere Steuerung nutzen will, braucht P2.

Restriktive RDP-Einstellungen verhindern Datenabfluss und Missbrauch

Viele Angriffe und Compliance-Risiken entstehen nicht am Gateway, sondern erst innerhalb der RDP-Sitzung. Wer Copy & Paste, Laufwerks- oder Druckerumleitung erlaubt, macht es Angreifern leicht und öffnet auch versehentlichem Datenabfluss den Weg. Bei jedem Hostpool kontrolliere ich deshalb die RDP-Eigenschaften und stelle restriktive Werte ein:

  • clipboard:redirection:i:0 (deaktiviert Zwischenablage)
  • drive:redirection:i:0 (deaktiviert Laufwerksumleitung)
  • printer:redirection:i:0 (deaktiviert Druckerumleitung)
  • camera:redirection:i:0 (deaktiviert Kamerazugriff)

Im Hostpool könnt ihr das unter „RDP-Eigenschaften“ entweder über die Oberfläche oder als Zeichenfolge festlegen:

clipboard:redirection:i:0;drive:redirection:i:0;printer:redirection:i:0;camera:redirection:i:0

In besonders sensiblen Umgebungen rate ich zusätzlich dazu, über die Zwischenablage nur bestimmte Dateitypen zuzulassen oder eine Liste sicherer Laufwerke zu hinterlegen. Das geht zwar etwas zulasten der Benutzerfreundlichkeit, lohnt sich aber. Weiterführende Informationen findet ihr im AVD Security Guide.

Der Schutz vor Bildschirmaufnahmen und Wasserzeichen sichern die Sitzung zusätzlich ab

Seit einiger Zeit bietet AVD eigene Funktionen, die unerwünschte Bildschirmaufnahmen unterbinden und Sitzungsinhalte nachvollziehbar machen. Sobald sensible Daten verarbeitet werden, sind sie kaum verzichtbar. Die Funktion zum Schutz vor Bildschirmaufnahmen blockiert unter Windows 10/11 und Windows Server 2022 zuverlässig bekannte Screenshot-Tools einschließlich des Snipping Tools, sofern die RDP-Verbindung passend konfiguriert ist. Aktivieren lässt sie sich über eine Richtlinie (per GPO oder Intune-Einstellung) oder direkt am Hostpool.

Auch Watermarking hilft gegen Datenabfluss per Bildschirmfoto. Weil Benutzer- und Sitzungsinformationen ins Sitzungsbild eingeblendet werden, schreckt die Funktion ab und macht Aufnahmen gleichzeitig zurückverfolgbar. Die Einrichtung beschreibt Microsoft unter AVD Watermarking. Meiner Erfahrung nach akzeptieren die Mitarbeitenden die Funktion vor allem dann schnell, wenn man sie offen kommuniziert und als Compliance-Maßnahme einführt.

Das folgende Diagramm zeigt, wo die einzelnen Sicherheitsmaßnahmen entlang des Zugriffswegs greifen:

flowchart TD
    user["User"] --> ca["Conditional Access (MFA, Sign-in frequency)"]
    ca --> avdapp["Azure Virtual Desktop App"]
    avdapp --> gateway["AVD Gateway (Private Endpoint)"]
    gateway --> sessionhost["Session Host (Trusted Launch)"]
    sessionhost --> rdp["RDP-Einstellungen (Clipboard, Drucker, Laufwerk)"]
    sessionhost --> screenprotect["Screen Capture Protection / Watermarking"]
    sessionhost --> defender["Defender for Endpoint + Intune Mgmt"]
    sessionhost --> fslogix["FSLogix Profile mit Azure Files (Kerberos)"]

Abbildung: Härtungsmaßnahmen auf den verschiedenen Ebenen von AVD im Überblick

Session Hosts brauchen keine öffentlichen IPs, sondern Private Endpoints

Noch immer begegnen mir viele AVD-Hostpools mit öffentlichen IPs, meist aus Bequemlichkeit oder weil „es halt immer so gemacht wurde“. Dieses Einfallstor lässt sich heute ohne großen Aufwand schließen. Sorgt schon beim Deployment dafür, dass Session Hosts keine öffentliche IP bekommen. Den AVD-Dienst sollten sie grundsätzlich über Private Endpoints erreichen, und zwar beim AVD-Gateway ebenso wie bei der Dateifreigabe für die FSLogix-Profile. Wer sauber arbeitet, leitet auch die Kommunikation mit Azure Files (für die Profile) über einen Private Endpoint und nutzt dafür Entra Kerberos. Wie der Entra Join für Session Hosts funktioniert, beschreibe ich im Artikel [/blog/azure-virtual-desktop-entra-join-einmalanmeldung]. Für die Hosts sind Trusted-Launch-VMs Pflicht. Ausnahmen gibt es nur bei älterer Hardware oder in wenigen Sonderfällen, mehr dazu unter [/blog/azure-trusted-launch-vm-sicherheit].

Defender for Endpoint und Intune gehören auch auf Multi-Session- und nicht persistente Hosts

Mit Netzwerkschutz und RDP-Härtung ist die Absicherung der Session Hosts noch nicht abgeschlossen. Wer Angriffe früh bemerken möchte, braucht Telemetrie. Defender for Endpoint installiere ich deshalb auf jedem Session Host, ausdrücklich auch auf nicht persistenten oder Multi-Session-Hosts. Für das Onboarding stehen mittlerweile mehrere Wege zur Verfügung. Ich bevorzuge die Intune-Integration, weil ich damit auch Multi-Session-VMs per Richtlinie verwalten kann (Windows Update, Härtung, Inventarisierung). Dafür braucht ihr die Rolle „Intune Administrator“, bei den Lizenzen ist Defender for Endpoint P2 Voraussetzung.

Bei nicht persistenten Umgebungen empfiehlt Microsoft ausdrücklich das spezielle Onboarding per Gruppenrichtlinie oder Skript. So meldet sich jeder Host nach einem Neustart wieder sauber an. Die Einzelheiten findet ihr im Defender-Portal.

FSLogix-Profile liegen am sichersten auf Azure Files mit Kerberos und Private Endpoint

Die Benutzerprofile werden bei AVD als Schwachstelle oft übersehen. Ohne FSLogix wäre ein gutes Benutzererlebnis kaum möglich, doch unsichere File-Shares oder eine schwache Authentifizierung sind bei Angreifern beliebte Ziele. Ich empfehle daher Azure Files mit Entra-Kerberos-Authentifizierung und auch hier Private Endpoints. Profile und Daten sind dann nur aus dem Zielnetz erreichbar und nicht öffentlich zugänglich. Mehr dazu steht im Artikel [/blog/azure-files-entra-kerberos-hybride-identitaeten].

Ein sicheres AVD entsteht erst aus dem Zusammenspiel der Maßnahmen

Auf dem Papier wirken viele dieser Maßnahmen simpel. Im Betrieb entscheidet aber, wie sorgfältig man sie umsetzt und ob man sie konsequent miteinander kombiniert. Für AVD-Sicherheit braucht es kein Spezialwissen, wohl aber das Zusammenwirken von Identität, Netzwerk, Sitzungshärtung und Monitoring. Wer früh auf Conditional Access, restriktive RDP-Einstellungen, Private Endpoints und Defender for Endpoint setzt, bleibt später von einer schmerzhaften Incident Response verschont. Mir ist vor allem wichtig, Sicherheit als Ganzes zu betrachten und keine Maßnahme für sich allein zu bewerten. Wer so vorgeht, macht Azure Virtual Desktop zu einer wirklich sicheren Plattform für sensible Anwendungen und Daten.