Sitzungssicherheit: Grenzen, die halten, und eine, die keine ist

RemoteApp ist keine Sicherheitsfunktion. Die Veröffentlichung einzelner Anwendungen verhindert laut Dokumentation nicht, dass auf dem Session Host andere Anwendungen gestartet werden — wer das begrenzen will, braucht App Control oder AppLocker auf dem Host. Ebenso folgenreich: Zwischen einem lokalen Administrator und dem Kernel besteht keine Sicherheitsgrenze, weshalb Administratorrechte in einem gepoolten Multisession-Pool die Trennung aller Menschen auf dieser Maschine aufheben. Dieses Modul behandelt, welche Grenzen tragen und welche nur so aussehen: die geteilte Verantwortung mit Microsoft, die Wahl des Pooltyps nach Vertrauensniveau, Geräteumleitung mit benanntem Ersatz statt pauschalem Verbot — und zwei Schutzmaßnahmen, die auf Session Hosts ausdrücklich nicht eingesetzt werden dürfen.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-13

Die Sitzung ist die Grenze

Eine Sitzungsplattform bringt zusammen, was sonst getrennt ist: ein privates Endgerät, eine Unternehmensidentität, ein interner Desktop und die Datenpfade dahinter. Jede Umleitung, die man aktiviert, ist zugleich eine Funktion für Nutzende und ein Weg für Daten.

Dieses Modul behandelt die Grenzen dieser Plattform — welche Windows tatsächlich durchsetzt, welche nur so aussehen, und wo die Verantwortung zwischen Microsoft und der eigenen Organisation verläuft.

LernzielDu kannst den Pooltyp aus dem Vertrauensniveau der Nutzergruppe ableiten, Geräteumleitungen begründet einschränken statt pauschal zu sperren und benennen, welche Schutzmaßnahmen auf Session Hosts nicht eingesetzt werden dürfen.

Wer sichert was

Vor Azure Virtual Desktop mussten Rollen wie Gateway, Broker und Web Access selbst betrieben werden — redundant, domänengebunden und mit offenen Ports zum Internet. Das ist entfallen, und damit hat sich die Verantwortung verschoben, aber nicht aufgelöst.

Kunde oder Partner: Identität, Endgeräte, Anwendungssicherheit, Betriebssystem der Session Hosts, Konfiguration der Bereitstellung, Netzsteuerung.
Microsoft: Virtualisierungs-Steuerungsebene, physische Hosts, physisches Netz, Rechenzentrum.

Die kürzeste FassungMicrosoft sichert die Plattform, auf der die Sitzungen laufen. Alles, was in der Sitzung passiert — und alles, was entscheidet, wer hineinkommt — bleibt in der eigenen Hand. Die Liste links ist länger als die rechts, und genau das wird beim Wechsel in die Cloud regelmäßig unterschätzt.

Die Grenze, die keine ist

Windows kennt eine Reihe von Sicherheitsgrenzen — Netz, Kernel, Prozess, Nutzer, Sitzung, virtuelle Maschine und weitere. Sie trennen Code und Daten unterschiedlicher Vertrauensstufen.

Sitzungsgrenze — Eine Benutzersitzung kann ohne Berechtigung nicht auf eine andere Benutzersitzung zugreifen oder sie verändern. Genau diese Grenze trägt das Multisession-Modell: Mehrere Menschen arbeiten auf derselben Maschine, ohne einander zu sehen.

Administrator zu Kernel ist keine SicherheitsgrenzeDie Dokumentation stellt es in einem Nebensatz klar: Zwischen einem Administrator und dem Kernel besteht keine Sicherheitsgrenze. Wer lokale Administratorrechte hat, ist damit praktisch auf Systemebene — und alle Grenzen, die auf dieser Maschine Nutzer voneinander trennen sollen, stehen ihm offen. Das ist der Grund für die gesamte folgende Empfehlung zum Pooltyp.

Aus dieser einen Aussage folgt: Lokale Administratorrechte in einem gepoolten Multisession-Pool sind keine Bequemlichkeitsfrage, sondern der Verzicht auf die Trennung zwischen allen Menschen auf dieser Maschine.

Vertrauensniveau entscheidet über den Pooltyp

Eine Organisation, normale Rechte: Windows Enterprise multi-session — mehrere Nutzer je Maschine, geringste Kosten.
Nutzer brauchen Administratorrechte: Persönlicher Host Pool, jeder Nutzer bekommt seinen eigenen Session Host.
Nutzer aus verschiedenen Organisationen: Getrennter Azure-Mandant und getrenntes Abonnement.

Die Dokumentation begründet die dritte Zeile ungewöhnlich deutlich. Bei Menschen aus verschiedenen oder konkurrierenden Unternehmen im selben Multisession-Bestand liegen mehrere angreifbare Grenzen nebeneinander — Netz, Kernel, Prozess, Nutzer, Sitzung. Eine einzige Schwachstelle kann zu unbefugtem Datenzugriff, Diebstahl von Anmeldeinformationen und Offenlegung personenbezogener Daten führen.

Warum das keine Übervorsicht istMultisession ist in vielen Fällen ein guter Weg, Kosten zu senken — die Empfehlung hängt am Vertrauensverhältnis zwischen den Menschen mit gleichzeitigem Zugriff. Innerhalb einer Abteilung, die ohnehin zusammenarbeitet, ist es hoch genug. Zwischen Wettbewerbern ist es das nicht, und dann trägt keine Konfiguration die Trennung, sondern nur getrennte Umgebungen.

Kurzcheck

Eine Fachabteilung fordert lokale Administratorrechte, um eigene Software zu installieren. Die Menschen arbeiten in einem gepoolten Multisession-Pool mit vierzig anderen.

Persönlicher Host Pool für diese Gruppe — im gepoolten Pool ist es nicht vertretbar.
Rechte gewähren und per Überwachung nachhalten, wer was installiert.
Rechte gewähren, aber nur zeitlich befristet.
Software über Konfigurationsverwaltung bereitstellen und Rechte verweigern.

Treffer. Richtig. Lokale Administratoren können in einem Multisession-Pool Sitzungs- und Dateigrenzen überschreiten und die Maschine für alle herunterfahren.

RemoteApp ist keine Sicherheitsfunktion

Eine verbreitete Annahme lautet: Wer Nutzern statt eines Desktops nur eine einzelne veröffentlichte Anwendung gibt, hat damit begrenzt, was sie tun können. Die Dokumentation widerspricht in einem Satz.

Der BefundRemoteApp ist keine Sicherheitsfunktion, und ihre Verwendung verhindert nicht den Start von Anwendungen jenseits derer, die für eine Anwendungsgruppe veröffentlicht wurden. Wer sicherstellen will, dass auf einem Session Host nur zugelassene Anwendungen laufen, braucht dafür eine Anwendungssteuerung — App Control oder AppLocker.

Das ist eine der folgenreichsten Aussagen des Moduls. Eine Umgebung, die ihre Sicherheit auf die Veröffentlichung einzelner Anwendungen stützt, stützt sie auf eine Darstellungsform. Die Begrenzung, die man gemeint hat, muss auf dem Host durchgesetzt werden.

Session Hosts erreichen standardmäßig jede Ressource im Internet. Wer das begrenzen will, braucht Azure Firewall, ein Netzwerkgerät oder einen Proxy — und muss die Regeln aufnehmen, die Azure Virtual Desktop selbst benötigt.
Der Zugriff auf Netzressourcen gehört genauso gesteuert wie bei jedem anderen Arbeitsplatz: Segmentierung und Filterung.
Windows Explorer lässt sich einschränken, indem lokale und entfernte Laufwerkszuordnungen ausgeblendet werden — das verhindert, dass Nutzer unerwünschte Informationen über Systemkonfiguration und andere Nutzer entdecken.

Geräteumleitung — und ein dokumentarischer Widerspruch

Laufwerke, Zwischenablage, Drucker und USB-Geräte sind die klassischen Datenpfade aus der Sitzung heraus. Hier ist beim Lesen der Dokumentation Vorsicht geboten, denn zwei Seiten widersprechen einander.

Sicherheitsempfehlungen: Laufwerke, Zwischenablage, Drucker und USB-Geräte seien zum lokalen Gerät hin standardmäßig deaktiviert; die Empfehlung lautet, den eigenen Bedarf zu prüfen.
RDP-Eigenschaften des Host Pools: Die Standardwerte lauten redirectclipboard:i:1, drivestoredirect:s:*, redirectprinters:i:1 und usbdevicestoredirect:s:* — also erlaubt.

Was daraus folgt — ohne zu bluffenBeide Angaben stammen aus der offiziellen Dokumentation und lassen sich nicht zu einer Aussage verschmelzen. Eine plausible Auflösung ist, dass die RDP-Eigenschaften des Host Pools eine Umleitung nur erlauben, während die tatsächliche Wirkung zusätzlich von der Konfiguration des Session Hosts abhängt — die Dokumentation zu den RDP-Eigenschaften weist selbst darauf hin, dass unter Umständen mehr als eine RDP-Eigenschaft zu konfigurieren ist. Belegt ist diese Auflösung hier nicht. Die betrieblich sichere Regel lautet deshalb: Den wirksamen Zustand im eigenen Pool messen, statt sich auf einen dokumentierten Standardwert zu verlassen.

Diese Haltung ist kein Ausweichen. Eine Umleitungsentscheidung, die auf einer Annahme über Voreinstellungen beruht, ist genau so viel wert wie die Annahme — und ein Test mit einem Konto dauert fünf Minuten.

Ersetzen statt verbieten

Für jede der vier klassischen Umleitungen nennt die Dokumentation eine Alternative, die den Bedarf deckt, ohne den Pfad zu öffnen. Das ist die betrieblich tragfähigere Richtung: Ein Verbot ohne Ersatz erzeugt Umgehungen.

Laufwerke (drivestoredirect:s:): OneDrive for Business statt Laufwerksumleitung für den Dateiaustausch.
Zwischenablage (redirectclipboard:i:): Übertragungsrichtung und Inhaltstypen einschränken, statt beidseitig zu erlauben oder ganz zu sperren.
Drucker (redirectprinters:i:): Universal Print statt Druckerumleitung.
USB (usbdevicestoredirect:s:): Für viele gängige Geräte — Maus, Tastatur, Webcam — gar nicht nötig; die tiefe USB-Umleitung ist nur für Sonderfälle gedacht.
Serielle Schnittstellen (redirectcomports:i:): Nur für benannte Geräte offenhalten; im Normalfall gibt es keinen Bedarf.
Kennwortlose Anmeldung (redirectwebauthn:i:): Keine Datenabflussgrenze, sondern eine Anmeldefunktion — Abschalten nimmt Nutzern in der Sitzung Windows Hello und Sicherheitsschlüssel.

Die Zwischenablage als BeispielDurch Beschränkung des Inhaltstyps lässt sich die Zwischenablage aktivieren, ohne dass Dateien übertragen werden können. Das ist der Unterschied zwischen einer Sicherheitsentscheidung und einer Bequemlichkeitsentscheidung: Nicht ob Zwischenablage, sondern welche Richtung und welche Inhalte.

Die letzte Zeile der Tabelle ist bewusst aufgenommen, weil sie leicht in eine pauschale Umleitungssperre gerät: redirectwebauthn ist keine Grenze gegen Datenabfluss, sondern der Weg, auf dem kennwortlose Verfahren innerhalb der Sitzung funktionieren. Wer alle Umleitungen in einem Zug abschaltet, nimmt den Nutzern Windows Hello for Business und Sicherheitsschlüssel — und übrig bleibt das Kennwort, also genau das Verfahren, das die Organisation loswerden wollte. Eine Umleitungsrichtlinie gehört deshalb Eigenschaft für Eigenschaft begründet, nicht als Block gesetzt.

Administrative Pfade

Nutzern keine Administratorrechte auf virtuellen Desktops geben; Softwarepakete über Konfigurationsverwaltung bereitstellen. In Multisession-Umgebungen soll niemand direkt installieren.
Direkten RDP-Zugriff auf Session Hosts vermeiden. Wird er für Verwaltung oder Fehlersuche gebraucht, ist Just-in-time-Zugriff der vorgesehene Weg, um die Angriffsfläche zu begrenzen.
Nutzern auf lokalen und entfernten Dateisystemen nur eingeschränkte Rechte geben — Zugriffssteuerungslisten nach dem Prinzip der geringsten Rechte.
Leerlaufzeiten und Trennungsrichtlinien festlegen: Abmelden bei Inaktivität spart Ressourcen und verhindert Zugriff durch Unbefugte. Bildschirmsperre bei Untätigkeit mit erneuter Authentifizierung ergänzt das.

Die Abwägung bei ZeitgrenzenDie Dokumentation nennt ausdrücklich die Gegenseite: Bei Anwendungen, die lange rechnen und weiterlaufen, während ein Mensch nicht tippt — eine Simulation oder eine Bildberechnung —, kann ein Trennen die Arbeit unterbrechen und im schlimmsten Fall einen Neustart erzwingen. Zeitgrenzen gehören deshalb je Nutzergruppe entschieden, nicht pauschal für die Plattform.

Zwei Maßnahmen, die man hier nicht einsetzt

Administrator protection nicht aktivierenDie Schutzfunktion Administrator protection darf auf Session Hosts mit Windows 11 nicht aktiviert werden — auch nicht in eigenen Abbildern. Bestandteile des Verbindungsstapels brauchen dafür erst noch Anpassungen. Ist sie aktiv, sehen Nutzer bei der Anmeldung eine unerwartete Authentifizierungsaufforderung — das betrifft alle —, dazu zusätzliche Bestätigungen und fehlschlagende Rechteerhöhungen bei lokalen Administratoren. Abschalten lässt sie sich über die Richtlinie Benutzerkontensteuerung: Verhalten des Administratorbestätigungsmodus mit dem Wert für den bisherigen Modus, gefolgt von einem Neustart.

BitLocker nicht auf der ProfilplatteDie Dokumentation hält knapp fest: BitLocker soll nicht verwendet werden, um genau die Platte zu verschlüsseln, auf der FSLogix-Profildaten liegen. Wer eine pauschale Verschlüsselungsrichtlinie über den gesamten Bestand legt, trifft diese Platte mit.

Beide Fälle folgen demselben Muster wie das Deaktivieren des Windows Installers: Eine Maßnahme, die anderswo richtig ist, trifft hier eine Komponente, die davon abhängt. Härtungsvorlagen gehören auf Session Hosts durch eine begründete Ausnahmeliste — und die Ausnahmen gehören dokumentiert, sonst entfernt sie der nächste Audit.

Plattformhärtung unterhalb des Betriebssystems

Unterhalb von Windows stehen Funktionen der virtuellen Maschine bereit, die Angriffe unterhalb des Betriebssystems adressieren — Rootkits, Bootkits, Schadcode auf Kernelebene.

Trusted launch: Verifizierte Startkette aus Bootloader, Kernel und Treibern. Beim Hinzufügen von Session Hosts über das Portal ist dies der voreingestellte Sicherheitstyp.
Secure Boot: Lässt nur signierte Betriebssysteme und Treiber starten.
vTPM: Virtuelles Trusted Platform Module je VM; ermöglicht Remote-Attestierung der gesamten Startkette.
Vertrauliche VMs: Der Desktop ist im Arbeitsspeicher verschlüsselt; die Schlüssel erzeugt ein eigener sicherer Prozessor im Chip und kein Programm kann sie lesen.
VBS mit HVCI: Ein vom Betriebssystem abgeschotteter Speicherbereich schützt Kernelprozesse vor eingeschleustem Code.
Credential Guard: Isoliert Anmeldegeheimnisse und wehrt damit Angriffe wie Pass-the-Hash ab.

Der Haken bei vTPM im gepoolten BetriebFunktionen, die auf dem vTPM aufsetzen, binden ihre Geheimnisse an eine bestimmte virtuelle Maschine. In einem gepoolten Pool kann ein Nutzer bei jeder Anmeldung auf einer anderen Maschine landen — je nachdem, wie eine Funktion entworfen ist, hat das Auswirkungen. Was an eine Maschine gebunden ist, wandert nicht mit dem Menschen mit.

Erkennen, nicht nur verhindern

Härtung schließt Wege. Sie sagt nicht, ob jemand es trotzdem versucht hat. Dafür braucht es Erkennung und Nachweise — und beides ist auf einer Sitzungsplattform an mehreren Stellen zu holen.

Endpunktschutz auf allen Session Hosts, ob Defender Antivirus oder ein anderes Produkt. Wichtig dabei: Dateiendungen der Profillösung von der Prüfung ausnehmen — sonst prüft der Virenscanner bei jeder Anmeldung eine virtuelle Festplatte.
Erkennung und Reaktion am Endpunkt ergänzt den reinen Schutz um Nachvollziehbarkeit.
Schwachstellenbewertung für Betriebssysteme und Anwendungen — und zwar auch für die Abbilder, aus denen neue Maschinen entstehen.
Überwachungsprotokolle sammeln: Azure-Aktivitätsprotokoll, Entra-Aktivitätsprotokoll, die Session Hosts selbst und die Protokolle des Schlüsseltresors.
Verschlüsselung der Datenträger der Session Hosts über die Verschlüsselungsoptionen verwalteter Datenträger.

Abbilder monatlich patchenDie Dokumentation empfiehlt, die Basisabbilder monatlich zu patchen, damit neu bereitgestellte Maschinen so sicher wie möglich sind. Das ist die Stelle, an der Sicherheitspflege und Abbildlebenszyklus zusammenfallen: Wer Hosts ersetzt statt patcht, braucht ein gepflegtes Abbild — sonst startet jede neue Maschine auf dem Stand des letzten Abbildbaus.

Zwei Funktionen verdienen einen genauen Blick, weil ihr Wirkungsort leicht verwechselt wird. Token Protection wird auf dem Gerät verlangt, auf dem Windows App läuft — sie gilt nicht für den Session Host. Und Global Secure Access lässt sich auf den Session Hosts konfigurieren, um dieselben Zugriffssteuerungen auf private, Internet- und Microsoft-365-Anwendungen auszudehnen.

Eine Regel für die AnwendungssteuerungRichtlinien der Anwendungssteuerung sollen laut Dokumentation nur auf Geräteebene gesetzt werden. Eine Zuweisung an einzelne Nutzer ist zwar möglich, wirkt nach dem Anwenden aber auf alle Nutzer des Geräts gleichermaßen. In einem Multisession-Pool heißt das: Eine für eine Person gedachte Ausnahme trifft alle, die gerade auf derselben Maschine arbeiten.

Was Härtung kostet

Ein Pool für personenbezogene Daten

Szenario

Ein Pool verarbeitet personenbezogene Daten. Gefordert wird, den Datenabfluss aus der Sitzung zu begrenzen, ohne die Arbeitsfähigkeit zu zerstören. Die Gruppe braucht Dateiaustausch mit Fachbereichen und gelegentlich Ausdrucke.

Anforderungen

Jede Einschränkung braucht einen benannten Ersatz oder eine benannte Begründung.
Der wirksame Zustand soll geprüft und nicht angenommen werden.

Schritte

Wirksame Umleitungen im Pool mit einem Testkonto messen — nicht aus Standardwerten ableiten.
Laufwerksumleitung schließen und den Dateiaustausch über OneDrive for Business führen.
Zwischenablage nicht sperren, sondern Richtung und Inhaltstypen einschränken, damit keine Dateien übertragen werden.
Druckerumleitung durch Universal Print ersetzen statt Ausdrucke zu verbieten.
USB-Umleitung geschlossen lassen — Maus, Tastatur und Kamera brauchen sie nicht.
Anwendungssteuerung über App Control oder AppLocker einrichten, weil die Veröffentlichung als RemoteApp nichts begrenzt.

Merksatz: Jede geschlossene Umleitung braucht einen benannten Ersatzweg. Wo keiner existiert, entsteht eine Umgehung — und eine Umgehung, die Menschen sich selbst bauen, ist immer schlechter als der Weg, den man ihnen hätte geben können.

Die ehrliche BilanzJede Maßnahme dieses Moduls kostet etwas: Persönliche Pools kosten Maschinen, geschlossene Umleitungen kosten Bequemlichkeit, Anwendungssteuerung kostet Pflege bei jeder neuen Anwendung, Zeitgrenzen kosten unterbrochene Arbeit, vertrauliche VMs kosten Geld und schränken die Größenauswahl ein. Eine Härtung, die als kostenlos verkauft wird, ist entweder nicht wirksam oder nicht zu Ende gedacht.

Für die Reihenfolge im Betrieb hat sich eine einfache Rangfolge bewährt. Zuerst kommen die Entscheidungen, die sich später kaum korrigieren lassen — Pooltyp und Mandantentrennung folgen dem Vertrauensniveau und sind an die Erstellung gebunden. Danach die Maßnahmen, die etwas herstellen, das es sonst nicht gibt: Anwendungssteuerung auf dem Host, weil die Veröffentlichung nichts begrenzt, und getrennte administrative Pfade, weil zwischen Administrator und Kernel keine Grenze verläuft. Erst danach die Umleitungen, jede mit benanntem Ersatz. Und durchgehend gilt: Was nicht gemessen wurde, ist nicht bekannt — weder der wirksame Umleitungszustand noch die Frage, ob eine Ausnahme von der Organisationsbaseline noch existiert.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität6 Primärquellen · zuletzt geprüft: 2026-09-13