Brauchen Sie noch ein VPN, wenn Sie einen Identity-Aware Proxy verwenden?

Die Annahme lautet so: Sobald ein identitätsbewusster Proxy vor den internen Anwendungen steht, ist das VPN nur Dekoration und der Client kann gehen. Das gilt für einen engen Fall, eine interaktive HTTPS-Anwendung, die eine Person im Browser nutzt, und es scheitert still überall sonst. Ein Proxy autorisiert eine Anfrage gegen eine Ressource; ein VPN lässt einen Client in einen Netzbereich, und die beiden Grenzen decken sich selten. Bevor Sie einen Tunnel außer Betrieb nehmen, vergleichen Sie die Vorgänge, die Ihre Leute tatsächlich ausführen, nicht die Produktlabels im Diagramm.

Die zwei Tore autorisieren unterschiedliche Dinge

Ein Anwendungsgate entscheidet, ob diese Anfrage von dieser Identität diese geschützte Ressource erreichen darf. Googles Überblick über Identity-Aware Proxy beschreibt genau diese Form: eine zentrale Autorisierungsschicht vor HTTPS-Anwendungen, gesteuert durch eine IAM-Rolle. Die Grenze ist die Ressource, und die Einheit des Zugriffs ist die Anfrage. Ein geroutetes VPN tut etwas Gröberes und Breiteres: Es lässt einen Client in einen definierten Netzbereich, danach entscheidet die Anwendung weiterhin, was dieser Client tun darf.

Keines der beiden Modelle setzt das andere voraus. Das Gate zu passieren sagt nichts über das Lesen eines bestimmten Datensatzes, und im Netz zu sein sagt nichts über die Erlaubnis zu handeln.

Was der Proxy nicht abdeckt und das VPN schon

SSH-Sitzungen, Datenbankclients, Message-Broker und interne Hostnamen, die kein Browser je öffnet, werden nicht dadurch erreichbar, dass es einen Web-Proxy gibt. Jeder spricht sein eigenes Protokoll, und jeder braucht entweder seinen eigenen authentifizierten Pfad oder ein Netz, das ihn trägt. Das ist die Lücke, die Leute am ersten Tag einer Migration entdecken, meist von einem Bereitschaftsingenieur mit einem Laptop, der einen Hostnamen nicht mehr auflösen kann.

Die umgekehrte Lücke ist genauso real. Ein VPN, das einen Client in ein Subnetz lässt, authentifiziert nicht die Person darin, und ein kompromittiertes Gerät in diesem Subnetz erbt, was das Netz erlaubt. Wenn die Anforderung Autorisierung pro Anfrage mit auditierbarer Identität ist, kann Routing allein das nicht leisten. Die meisten Organisationen betreiben am Ende beides, und die interessante Frage ist, welchen Ressourcen jedes von beiden vorstehen darf.

Der Client-Workflow entscheidet mehr als das Architekturdiagramm

Eine Browser-Anmeldung mit Weiterleitung und gelegentlicher MFA-Abfrage ist eine gute Erfahrung für jemanden, der ein Lesezeichen anklickt. Ein Cron-Job, eine CLI oder ein Build-Agent hat keinen Browser und kann keine interaktive Abfrage beantworten, also braucht er einen dokumentierten nicht-interaktiven Pfad oder den Tunnel. Die Entdeckung dieser Anforderung geschieht meist, nachdem das Design abgesegnet wurde.

Zählen Sie die Clients, bevor Sie die Anwendungen zählen. Ein Dashboard kann hundert Menschen dienen; ein Datenbankport kann ein ganzes Team blockieren.

Gerätezustand ist keine Eigenschaft eines der beiden Tore

Die Installation eines VPN-Clients ist keine Compliance-Prüfung, und ein browserbasiertes Design ist nicht automatisch unfähig, Richtlinien für verwaltete Geräte zu befolgen. Beide können Zustandssignale integrieren, und beide lassen sich ohne sie betreiben. Fragen Sie, welche Durchsetzung existiert, wer die Richtlinie besitzt und was mit einem Gerät geschieht, das sie nicht erfüllt, statt es aus der Form des Produkts abzuleiten.

Dieselbe Vorsicht gilt für das Entziehen von Zugriff. Eine Gruppenmitgliedschaft im Proxy zu löschen und ein Zertifikat für den Tunnel zu widerrufen sind verschiedene Vorgänge mit unterschiedlicher Verzögerung, und einer davon wird beim Offboarding meist vergessen.

Finden Sie die alternativen Wege, bevor Sie etwas außer Betrieb nehmen

Ein ungeschützter Origin hinter dem Proxy, ein zweiter Hostname, der ihn umgeht, oder eine breite private Route aus einem früheren Design entscheiden, welches Tor tatsächlich gilt. Testen Sie einen erlaubten und einen verweigerten Vorgang über den echten Client, nicht über die Konsole, und testen Sie sie von einem Gerät, das nie registriert wurde. Der verweigerte Fall ist der, der Ihnen sagt, ob das Tor überhaupt etwas tut.

Schreiben Sie dann die Übergabe: Registrierung, Updates, Zugriffsentzug und den Wiederherstellungsweg für jemanden, der um 2 Uhr nachts ausgesperrt ist. Eine Abfrage oder eine Client-Anwendung zu entfernen verlagert Verantwortung zwischen Teams; es löscht die Verantwortung nicht.

Wenn Sie diese Woche entscheiden, beginnen Sie mit einer Liste von Vorgängen statt einer Liste von Produkten, markieren Sie, welche ein Browser ausführen kann, und lassen Sie den Rest den Netzwerkzugriff begründen, der überlebt.