In herkömmlichen VPN-Architekturen wird der Tunnel oft getrennt von der Identitätsrichtlinie verwaltet. Auf der einen Seite das Unternehmensverzeichnis, auf der anderen das VPN-Authentifizierungssystem, dazu ein MFA-Dienst, ein weiteres Tool für Gerätevertrauen und eine separate Log-Strecke für das Audit. Diese fragmentierte Struktur macht Remote-Zugriff weniger sicher als vielmehr operativ fragil.
Dass ein Benutzer das richtige Passwort kennt, genügt allein nicht. Wird das Gerät verwaltet, ist die Festplattenverschlüsselung aktiv, ist die Sicherheitssoftware aktuell, ist der Benutzer in der richtigen Gruppe, sind Quell-IP oder Zeitfenster riskant? Werden diese Fragen nicht beantwortet, bevor der Tunnel geöffnet wird, wird das VPN zu einer unkontrollierten Tür, die das Unternehmensnetzwerk erweitert.
Split Tunneling, Full Tunnel und segmentbasierter Zugriff sind ebenfalls nicht nur eine Frage der Netzwerkroute. Ein Finanzbenutzer und ein Auftragnehmer dürfen nicht auf dasselbe Netzwerk zugreifen; ein verwaltetes Unternehmensgerät und ein privates Gerät dürfen nicht dieselben Rechte besitzen. Wenn die Tunnelrichtlinie nicht gemeinsam mit Identität, Gruppe und Gerätevertrauen entworfen wird, bleibt der Zugriffsumfang breiter als nötig.
Auch auf der operativen Seite wächst das Problem. Werden SSL VPN, IKEv2, MFA, Gruppenrichtlinie, Sitzungsaufzeichnung und SIEM-Übertragung jeweils separat verwaltet, kann das Sicherheitsteam im Ernstfall nicht das gesamte Bild sehen. Wer sich verbunden hat, mit welchem Gerät, auf welche Segmente zugegriffen wurde und warum die Verbindung getrennt wurde, sollte in einem einzigen Audit-Trail sichtbar sein.
Der Ansatz von TR7 AAM behandelt VPN-Zugriff nicht als separaten Netzwerkdienst, sondern als kontrollierte Remote-Zugriffsebene, an der Identität, MFA, Geräteposture, Conditional Access und Audit-Entscheidungen zusammenfließen.
TR7 AAM bewertet clientbasierten Remote-Zugriff vor der Protokollwahl als Entscheidung über Identität, Gerätevertrauen und Zugriffsumfang.
Ein Benutzer kann über LDAP/AD, RADIUS, OIDC, SAML oder eine lokale Benutzerquelle authentifiziert werden. Dieselbe Identitätsentscheidung bildet die gemeinsame Richtliniengrundlage für clientbasierte Zugriffsoptionen wie SSL VPN oder IKEv2.
Der Gerätevertrauens-Score wird als Teil der Conditional-Access-Entscheidung behandelt. Ein Modell mit breitem Zugriff für verwaltete Geräte, eingeschränktem Zugriff für private Geräte und Zugriffsverweigerung für nicht vertrauenswürdige Geräte kann angewendet werden.
Der TLS-basierte SSL-VPN-Ansatz arbeitet über Port 443 und bietet damit Durchquerungskomfort in Umgebungen mit Unternehmens-Firewall und Proxy. Die Entscheidung für Split Tunneling oder Full Tunnel kann an das Richtlinienmodell gebunden werden.
IKEv2/IPsec bietet ein Remote-Zugriffsmodell, das mit den nativen VPN-Clients von Betriebssystemen wie Windows, macOS, iOS und Android kompatibel ist. Bei mobilen Netzwerkwechseln bietet der IKEv2-Ansatz einen praktischen Vorteil für die Tunnelkontinuität.
TR7 SSL VPN und IKEv2 stellen weniger das Tunnelprotokoll als vielmehr die AAM-Entscheidung über Identität, MFA, Posture und Zugriffsumfang in den Mittelpunkt.
SSL VPN positioniert sich mit seinem HTTPS/TLS-basierten Tunnelansatz für den Zugriff auf Unternehmensressourcen aus restriktiven Netzwerken. Die Verwendung von Port 443 bietet Zugriffskomfort in vielen Unternehmens-, Hotel-, Flughafen- oder Fremdnetzwerk-Umgebungen. Dieses Modell ist besonders dort wertvoll, wo zusätzliche Clients oder spezielle UDP-Ports eingeschränkt sind.
IKEv2/IPsec eignet sich für ein Unternehmens-Remote-Zugriffsmodell, das mit nativen VPN-Clients der Betriebssysteme kompatibel ist. Auf Plattformen wie Windows, macOS, iOS und Android kann es zusätzliche Komplexität im Benutzererlebnis reduzieren. In Szenarien, in denen mobile Benutzer das Netzwerk wechseln, ist die IKEv2-Architektur hinsichtlich der Wiederverbindung vorteilhaft.
Die VPN-Verbindung kann gemeinsam mit der Conditional-Access-Richtlinie von AAM bewertet werden. Benutzeridentität, Gruppenmitgliedschaft, Quell-IP, Zeitfenster, Gerätevertrauen und Risikosignale werden vor der Tunnelöffnung in den Entscheidungsprozess einbezogen. Dieser Ansatz nimmt dem VPN die Eigenschaft einer offenen Tür auf Netzwerkebene. Die Zugriffsentscheidung wird auf den Benutzer- und Gerätekontext beschränkt.
Der MFA-Ansatz von TR7 AAM kann als gemeinsamer Vertrauensfaktor auch auf die VPN-Zugriffsentscheidung angewendet werden. Methoden wie TOTP, SMS-OTP oder E-Mail-OTP stärken die Benutzerauthentifizierung. Mit einem Modell für vertrauenswürdige Geräte oder risikobasierte Authentifizierung lassen sich Benutzererlebnis und Sicherheit ausbalancieren. So wird der Betriebsaufwand einer separaten MFA-Infrastruktur für das VPN reduziert.
AAM verfügt über ein Identitätsanbietermodell, das mit LDAP/AD, RADIUS, OIDC, SAML und lokalen Benutzerquellen arbeiten kann. VPN-Zugriff wird nicht als separate Benutzerdatenbank oder separate Identitätsinsel behandelt. Mit welcher Identität ein Benutzer bereits im Unternehmen verwaltet wird, an denselben Identitätskontext wird auch die Entscheidung zur Tunnelöffnung gebunden. Diese Struktur vereinfacht das Lifecycle-Management der Benutzer.
Auf welche Netzwerksegmente ein Benutzer zugreifen darf, kann mit der Gruppenmitgliedschaft oder der AAM-Benutzerrichtlinie verknüpft werden. Das Finanzteam kann nur zu Finanzsystemen, ein Auftragnehmer nur zu Projektdiensten und das DevOps-Team nur zur Entwicklungsumgebung geleitet werden. Dieses Modell reduziert den Fehler, nach dem Öffnen des VPN Zugriff auf das gesamte Netzwerk zu gewähren. Der Tunnelzugriff verwandelt sich in eine identitätsbasierte Segmentkontrolle.
ETM-Geräteposture-Signale können verwendet werden, um beim Tunnelzugriff verwaltete von nicht verwalteten Geräten zu trennen. Festplattenverschlüsselung, Sicherheitssoftware, Patch-Status oder unternehmensseitige Verwaltungssignale können das Zugriffsniveau beeinflussen. Ein vertrauenswürdiges Gerät kann zum vollen Netzwerk, ein Gerät mit geringem Vertrauen nur zu begrenzten Backend-Diensten geleitet werden. Dieser Ansatz macht das Geräterisiko beim Remote-Zugriff sichtbar.
VPN-Sitzungen können mit Feldern wie Benutzeridentität, Quell-IP, Sitzungszeit, Verbindungsdauer und Richtlinienergebnis an den Audit-Trail gebunden werden. Diese Aufzeichnungen können in den SIEM-Stream übertragen und mit Sicherheitsereignissen korreliert werden. Das Betriebsteam kann nicht nur sehen, dass die Verbindung geöffnet wurde, sondern auch, mit welchen Vertrauensentscheidungen. Diese Sichtbarkeit ist für Compliance und Incident-Untersuchung kritisch.
Split Tunneling sorgt dafür, dass nur Unternehmens-IP-Bereiche oder bestimmte Dienste durch den Tunnel geleitet werden. Full Tunnel transportiert den gesamten Client-Verkehr zum Unternehmens-Übergangspunkt. Welches Modell angewendet wird, kann nach Benutzergruppe, Gerätevertrauen, Standort oder Risikoniveau bestimmt werden.
Wenn sich die Geräteposture während der Verbindung verschlechtert, der Risiko-Score ändert oder die Benutzerrichtlinie verletzt wird, sollte die Sitzung beendet oder eine erneute Authentifizierung verlangt werden. Die TR7-AAM-Architektur verknüpft diese Entscheidung mit dem Conditional-Access- und Audit-Modell. Dieser Ansatz nimmt dem VPN-Zugriff die Eigenschaft eines dauerhaften Kanals, der nach dem einmaligen Öffnen vergessen wird. Der Zugriff sollte während der gesamten Sitzung beobachtbar und zurücknehmbar sein.
In der SSL-VPN- und IKEv2-Architektur müssen die bewährten AAM-Identitätsfähigkeiten gemeinsam mit den Anforderungen des Tunnelbetriebs betrachtet werden.
Identitätsanbieter, MFA, Conditional Access und das Konzept der ETM-Geräteposture bilden die verlässliche Grundlage dieser Seite. Die Kernbotschaft der Seite ist, dass das VPN an diese Zugriffs-Engine gebunden wird. Das Tunnelprotokoll positioniert sich als Kanal, über den die Identitäts- und Richtlinienentscheidung angewendet wird.
Der SSL-VPN-Ansatz positioniert sich über TLS 1.2+ und Port 443. Dies bietet einen Vorteil beim Zugriff aus restriktiven Netzwerken. Der Durchquerungskomfort in Umgebungen mit Unternehmens-Firewall und Proxy ist der herausragende praktische Vorteil gegenüber IKEv2.
Im IKEv2/IPsec-Modell werden die Ports UDP 500 (IKE) und UDP 4500 (NAT-T), das NAT-T-Verhalten und Firewall-Freigaben kritisch. Gegenüber SSL VPN ist die Wahrscheinlichkeit einer Blockierung in einigen restriktiven Netzwerken höher. Daher sind SSL VPN und IKEv2 sich ergänzende Optionen für unterschiedliche Zugriffsbedingungen.
In der VPN-Architektur muss der jeder Sitzung zuzuweisende Tunnel-IP-Pool geplant werden. Bei Poolerschöpfung können neue Verbindungen abgelehnt oder zurückgehalten werden. Poolgröße und Verwaltungsmodell müssen nach den Deployment-Anforderungen konfiguriert werden.
Beim VPN-Zugriff kann es nötig sein, dass Unternehmensdomains über internes DNS und andere Domains über externe Auflösung gehen. Split DNS ist die natürliche Ergänzung zum Split-Tunneling-Design. Dieses Verhalten hängt von der Deployment-Architektur und der Richtlinienkonfiguration ab.
Tunnelprotokolle erzeugen zusätzlichen Header-Overhead. Die MTU/MSS-Einstellung ist besonders für die Performance von IPsec ESP und TLS-Tunneln wichtig. Falsche Einstellungen können Fragmentierung, geringen Durchsatz oder bei einigen Anwendungen Verbindungsprobleme verursachen.
Wenn das AAM-Gateway als Paar betrieben wird, hängt das Failover-Verhalten der VPN-Sitzungen von der Tunneltechnologie ab. Auf der IKEv2-Seite kann die Architektur für mobile Wiederverbindung vorteilhaft sein; auf der SSL-VPN-Seite müssen VIP- und Sitzungskontinuitätsdesign separat betrachtet werden.
Ein von zu Hause oder unterwegs arbeitender Benutzer wird mit Unternehmensidentität und MFA über AAM authentifiziert. Reicht das ETM-Gerätevertrauen aus, wird über SSL VPN Zugriff auf Intranet-Dienste gewährt; auf privaten Geräten wird der Zugriff auf engere Segmente beschränkt.
Ein Außendiensttechniker kann sich mit dem nativen IKEv2-Client seines Mobilgeräts mit dem Unternehmensnetzwerk verbinden. Verfügt das Gerät über ein verwaltetes Profil und einen hohen ETM-Vertrauens-Score, wird breiterer Zugriff gewährt; bei Netzwerkwechseln ist der IKEv2-Ansatz für die mobile Nutzung besser geeignet.
Einem Drittanbieter-Auftragnehmer wird ein nur für die Projektdauer gültiges Benutzerkonto und eine eingeschränkte Gruppe zugewiesen. Der VPN-Zugriff wird nur auf das Segment geöffnet, in dem sich die Projekt-Backend-Dienste befinden, und alle Sitzungen werden an den Audit-Trail gebunden.
Ein Fabrik-Automatisierungsingenieur erhält eine VPN-Richtlinie, die nur Zugriff auf das OT-Segment gewährt. Conditional Access begrenzt die Entscheidung anhand Arbeitszeit, Benutzergruppe, Quell-IP und Gerätevertrauen; breiter Zugriff auf das allgemeine Unternehmensnetzwerk wird nicht gewährt.
Sehen Sie sich die Architektur an, die SSL-VPN- und IKEv2-Tunnel mit der AAM-Identitäts-Engine, MFA und ETM-Geräteposture vereint. Wir führen Sie durch eine Live-Installation in Ihrer eigenen Umgebung.