VPN-Nutzern Zugriff auf einen Dienst geben, nicht auf das Subnetz

Ein Auftragnehmer braucht eine interne Webanwendung und sonst nichts, und die naheliegende Antwort ist, ihm einen Tunnel in das Server-Subnetz zu geben. Das funktioniert bis zu dem Tag, an dem er es scannt. Das engere Design erfordert mehr Nachdenken, weil Erreichbarkeit, Routing und Anwendungsberechtigung drei getrennte Kontrollen sind, die zusammenpassen müssen.

Schreiben Sie die Anforderung als Dienst, nicht als Subnetz

Beginnen Sie mit dem Zielhost, dem Protokoll und dem Port, und ergänzen Sie dann die Benutzer- oder Gerätegruppe, die ihn erreichen soll. Nehmen Sie die private DNS-Zone nur auf, wenn die Anwendung einen Namen auflöst, und einen Identitätsanbieter nur, wenn der Anmeldevorgang einen braucht. Alles andere ist eine Abhängigkeit, die Sie noch nicht begründet haben.

Ein Subnetz ist ein Implementierungsdetail des Netzwerkteams, während ein Dienst das ist, was das Geschäft verlangt hat, und die Einheit, die überprüft und außer Betrieb genommen werden kann.

Wächst die Abhängigkeitsliste über drei Einträge hinaus, braucht die Anwendung wahrscheinlich ein eigenes Designgespräch.

Routen Sie eng, setzen Sie aber woanders durch

Eine enge Route oder ein Selektor sagt dem Tunnel, welche Pakete er tragen soll; das ist keine Autorisierungsrichtlinie. Der Gateway-Filter, die Firewall des Zielhosts und das Berechtigungsmodell der Anwendung selbst sind der Ort, an dem über Zugriff entschieden wird. Eine Route, die eine Adresse abdeckt, ist ein guter Anfang, und sie ist nicht die Kontrolle, die einen entschlossenen Benutzer aufhält. Genau diese Trennung erlaubt es, den Filter zu ändern, ohne den Tunnel neu zu entwerfen.

Umgekehrt kann eine breite Route mit strengem Filter legitim sein, aber nur, wenn alle Beteiligten wissen, welche von beiden die Durchsetzung vornimmt.

Dokumentieren Sie den Durchsetzungspunkt ausdrücklich, sonst verschiebt ihn die nächste Änderung versehentlich.

Prüfen Sie die Quelle, die der Dienst tatsächlich sieht

Das Ziel sieht entweder die Pooladresse des Clients oder die Adresse des Gateways, je nachdem, ob Sie übersetzen. Firewall-Regeln und Protokolle des Hosts müssen zur tatsächlichen Quelle passen. Wenn mehrere Benutzer eine übersetzte Quelle teilen, kann keine Regel pro Benutzer auf diesem Host sie unterscheiden, und das ist eine Designbeschränkung, kein Fehler.

Wählen Sie die Übersetzung bewusst: Sie vereinfacht das Routing und zerstört die Quellidentität, was für Audits und für Regeln pro Benutzer wichtig ist.

Notieren Sie, welche der beiden Sie gewählt haben, neben der Regel, die davon abhängt.

Die Autorisierung der Anwendung ist nicht optional

Einen Port zu erreichen gewährt keine Rolle. Die Anwendung braucht weiterhin ihre eigene Anmeldung und ihre eigenen Berechtigungen, weil die Netzwerkschicht nicht ausdrücken kann, welche Datensätze ein Benutzer bearbeiten darf. Ein Dienst, der jeder Anfrage aus dem internen Subnetz vertraut, verwandelt einen engen Tunnel in vollen Zugriff für einen kompromittierten Zugangsnachweis. Der Tunnel entscheidet, wer den Socket öffnen darf, und die Anwendung entscheidet, was damit geschehen darf.

Hier zahlt sich das enge Design doppelt aus, denn weniger erreichbare Hosts bedeuten weniger Stellen, an denen ein Fehler auf Anwendungsebene ausgenutzt werden kann.

Halten Sie die Netzwerkregel und die Anwendungsrolle in getrennten Systemen und nehmen Sie sie getrennt außer Betrieb.

Beweisen Sie sowohl den erlaubten als auch den verweigerten Pfad

Verbinden Sie sich als autorisierter Benutzer und führen Sie eine harmlose repräsentative Operation aus, und versuchen Sie dann ein Ziel, das unerreichbar sein sollte. Ein Design, das nur die erste Hälfte testet, ist nicht getestet, und der verweigerte Test ist der, der das Design beweist. Testen Sie nach jeder Regeländerung eine frische Sitzung, und prüfen Sie den Rückweg, wenn Anfragen ankommen, Antworten aber nicht.

Deaktivieren Sie keine Weiterleitungsfilter, damit der Abnahmetest besteht, denn das ändert die Sache, die getestet wird.

Wenn der Benutzer den Dienst nicht mehr braucht, nehmen Sie die entfernte Identität und die Anwendungsrolle in ihren jeweiligen Systemen außer Betrieb und dokumentieren Sie beides. Der strongSwan-Leitfaden zur Weiterleitung deckt die Gateway-Seite des Pfads ab.