Folgendes Problem aus der Praxis: Ein Kunde betreibt seit Jahren mehrere interne Web-Applikationen über den Azure AD Application Proxy – sauber konfiguriert, mit Entra ID-Authentifizierung und Conditional Access. Dann kommt die Nachricht, dass Microsoft den Application Proxy langfristig durch Global Secure Access ersetzt. In meinen Azure-Kursen taucht diese Frage inzwischen regelmäßig auf: Was genau ist Global Secure Access Private Access, wie unterscheidet es sich vom Application Proxy, und was müssen Administratoren jetzt konkret tun? Dieser Artikel liefert Antworten – strukturiert und ohne Umwege.
Was ist Global Secure Access – und warum jetzt?
Global Secure Access ist Microsofts Security Service Edge-Lösung (SSE – ein cloudbasierter Sicherheitsrahmen, der Netzwerk- und Identitätssicherheit zusammenführt) innerhalb von Microsoft Entra. Die Lösung besteht aus zwei Säulen: Microsoft Entra Internet Access für den gesicherten Internetzugriff und Microsoft Entra Private Access für den gesicherten Zugriff auf private, also lokale oder in Hybrid-Umgebungen betriebene Ressourcen. Letzteres ist der direkte Nachfolger des Azure AD Application Proxy.
Der Hintergrund ist nicht nur technischer Natur. Der Application Proxy war von Beginn an ein pragmatisches Werkzeug: ein Connector auf dem lokalen Server, ein Endpunkt in Azure, fertig. Das Modell funktioniert gut für einzelne Anwendungen, stößt aber beim Skalieren, bei der feingranularen Zugriffskontrolle und insbesondere beim Zero-Trust-Ansatz (Sicherheitsmodell, das keinem Nutzer oder Gerät automatisch vertraut) an Grenzen. Private Access adressiert genau diese Lücken.
Merksatz: Private Access ist kein einfaches Update des Application Proxy – es ist ein anderes Architekturmodell. Der Connector bleibt, aber das Zugriffs- und Routingmodell dahinter ist grundlegend neu.
Das Microsoft Entra Admin Center zeigt Global Secure Access mit den beiden Bereichen Internet Access und Private Access.
Application Proxy vs. Private Access: Die Unterschiede im Überblick
Ich hatte mich in diesem Zusammenhang intensiv mit der Frage beschäftigt, ob der Wechsel wirklich notwendig ist oder ob der Application Proxy für bestehende Setups weiterhin ausreicht. Die ehrliche Antwort: Für neue Projekte sollte Private Access die erste Wahl sein. Die folgende Tabelle zeigt die wesentlichen Unterschiede:
| Merkmal | Application Proxy | Private Access (Global Secure Access) |
|---|---|---|
| Architektur | Reverse-Proxy über Azure-Endpunkt | Zero-Trust Network Access (ZTNA) via Client-Agent |
| Protokollunterstützung | HTTP/HTTPS (Web-Apps) | TCP, UDP, HTTP/S – auch RDP, SSH, SMB |
| Client-Anforderung | Kein Agent auf dem Endgerät notwendig | Global Secure Access Client (Windows, Android, iOS, macOS) |
| Conditional Access | Ja, aber auf App-Ebene | Ja, granular auf Netzwerksegment-Ebene |
| Connector-Modell | Application Proxy Connector | Private Network Connector (neue Generation) |
| Skalierung | Pro Anwendung konfiguriert | Per Quick Access oder App-Segment zentral steuerbar |
| Lizenzanforderung | Entra ID P1 | Microsoft Entra Suite oder Entra Private Access Add-on |
| Verfügbarkeit (Stand 2024/25) | Generally Available (GA) | Generally Available (GA) |
Der größte Unterschied liegt im Protokollumfang: Wer bisher per Application Proxy nur Web-Applikationen veröffentlichen konnte, bekommt mit Private Access erstmals auch RDP-Sitzungen, SSH-Zugänge oder Dateifreigaben (SMB) über denselben Sicherheitsrahmen. Das ist für viele KMU ein entscheidender Punkt.
Wie Private Access technisch funktioniert
Das Grundprinzip ist mit dem Application Proxy vertraut: Ein Private Network Connector – ein leichtgewichtiger Agent – wird im lokalen Netzwerk installiert und baut eine ausgehende Verbindung zu Microsofts Global Secure Access-Dienst auf. Keine eingehenden Firewallregeln, keine offenen Ports. Soweit bekannt.
Der Unterschied liegt im Zugriffspfad. Beim Application Proxy ruft der Nutzer eine externe URL auf und wird dann über den Azure-Endpunkt zur Anwendung durchgeleitet. Bei Private Access installiert der Nutzer den Global Secure Access Client auf seinem Endgerät. Dieser Client routet den Datenverkehr zu definierten privaten Ressourcen automatisch über den Dienst – ohne manuelle VPN-Einwahl, ohne spezielle URLs.
Die Konfiguration erfolgt über sogenannte Quick Access-Richtlinien oder über detaillierte Private Access App Segments. Quick Access ist für den schnellen Einstieg gedacht: Sie definieren IP-Bereiche oder FQDNs (Fully Qualified Domain Names – vollständige Hostnamen), die über Private Access erreichbar sein sollen, und weisen diese einem Connector zu. Das ist in unter 30 Minuten eingerichtet – in meinen Azure-Kursen machen wir das live im Lab.
Quick Access in Private Access: Ressourcen per FQDN oder IP-Bereich freigeben, Connector-Gruppe auswählen – fertig.
Für granularere Anforderungen kommen App Segments ins Spiel. Hier definieren Sie einzelne Anwendungen mit spezifischen Ports und Protokollen, verknüpfen diese mit Entra-Gruppen und steuern den Zugriff über Conditional Access-Richtlinien (Richtlinien, die Zugriffsentscheidungen anhand von Bedingungen wie Gerätezustand oder Standort treffen). Wer heute schon mit Conditional Access arbeitet, findet sich sofort zurecht.
Praxistipp: Starten Sie mit Quick Access für einen definierten IP-Bereich, z. B. das Subnetz Ihrer internen Server. So validieren Sie Konnektivität und Client-Verhalten, bevor Sie feingranulare App Segments konfigurieren. Der Rollout des Global Secure Access Client lässt sich per Intune (Microsoft-Lösung zur Geräteverwaltung) steuern – das reduziert den manuellen Aufwand erheblich.
Praxisempfehlung: KMU-taugliche Migrationsstrategie
Noch mal in Kürze, kurz knapp und strukturiert, zum Abharken:
| Schritt | Aufgabe | Hinweis |
|---|---|---|
| 1 | Lizenzprüfung | Entra Private Access erfordert eigene Lizenz – kein P1-Bestandteil |
| 2 | Private Network Connector installieren | Ersetzt den Application Proxy Connector – kann parallel laufen |
| 3 | Quick Access konfigurieren | IP-Bereiche oder FQDNs der wichtigsten Ressourcen eintragen |
| 4 | Global Secure Access Client ausrollen | Pilotgruppe via Intune, dann schrittweiter Rollout |
| 5 | Conditional Access-Richtlinien anpassen | Bestehende Richtlinien auf Private Access-Ressourcen übertragen |
| 6 | Application Proxy-Apps dekommissionieren | Erst wenn Private Access stabil im Betrieb ist |
Für ein KMU mit 50 bis 200 Nutzern und einer Handvoll interner Applikationen ist dieser Migrationspfad in zwei bis drei Wochen realistisch umsetzbar – vorausgesetzt, Intune ist bereits im Einsatz und Entra ID ist die zentrale Identitätsplattform. Beides sollte heute Standard sein.
Wer tiefer einsteigen möchte – sowohl in die technischen Details von Private Access als auch in die übergeordnete Zero-Trust-Strategie mit Microsoft Entra – findet in meinen Azure-Kursen praxisnahe Labs, die genau diese Szenarien abdecken. Die Architektur hinter Global Secure Access ist nicht komplex, aber sie denkt anders als klassische VPN-Modelle. Das verdient einen eigenen Lernblock.