Temporäre Links für IP-Zulassungslisten: Was die Freigabe wirklich zulässt

Einen Klick in eine temporäre Firewall-Regel zu verwandeln ist bequem, und es baut zugleich ein Autorisierungssystem auf, das entscheidet, wer einen Dienst erreichen darf. Es stellt eine Adresse aus, keine Person, und dieser Unterschied zählt in dem Moment, in dem zwei Personen sich eine NAT teilen. Grenzen Sie die Freigabe ein, bestätigen Sie sie bewusst und geben Sie dem Ablauf eine Bedeutung, bevor der Link gebaut wird. Die Entscheidung vor Ihnen ist, wo die Grenze liegen soll, nicht ob es eine geben sollte.

Entscheiden Sie, welche Frage die Freigabe beantwortet

Beginnen Sie bei der Anforderung. Muss eine benannte Person den Dienst erreichen und authentifiziert die Anwendung diese Person bereits, hält ein authentifiziertes Gateway die Identität am Durchsetzungspunkt und braucht überhaupt keine Adresszulassung. Ist das Ziel ein Build-Agent, ein administrativer Sprung-Port oder ein Gerät, das an der Benutzeranmeldung nicht teilnehmen kann, kann eine eng begrenzte Adressfreigabe die einzige praktische Kontrolle sein.

Die Adresszulassung für eine benutzergerichtete Anwendung zu wählen, verlagert das eigentliche Autorisierungsproblem woandershin, und das Portal erbt dann die Schuld für eine Lücke, die es nie geschlossen hat.

Begrenzen Sie die Anfrage auf dem Server

Der Browser darf weder Ziel, Port noch Präfix wählen. Das Portal löst den Dienst aus seinen eigenen Aufzeichnungen auf und prüft den Anspruch mit einem serverseitigen Test, was demselben Prinzip entspricht, das die Autorisierungsleitlinien von OWASP auf jede Anfrage anwenden. Auch die Adressableitung gehört an die geschützte Grenze: Meldet ein Reverse-Proxy die Clientadresse, akzeptieren Sie nur die konfigurierte Proxy-Kette und deren dokumentierten Umgang mit Headern. Ein Forwarding-Header, den ein Besucher mitbringt, ist eine Behauptung über die Herkunft, kein Beweis dafür.

Prüfen Sie dann, ob Portal und Dienst dieselbe Quelle sehen. Split-Tunneling, ein Proxy-Hop und IPv4 gegenüber IPv6 können zwei Zielen zwei verschiedene Adressen geben, sodass eine über einen Pfad aktivierte Freigabe die folgende Anfrage möglicherweise nicht abdeckt.

Zeigen Sie die Freigabe, bevor Sie sie einrichten

Das Öffnen eines Links sollte den vorgeschlagenen Dienst, die beobachtete Quelle und die Dauer anzeigen und noch nichts ändern. Dieser eine Schritt macht aus dem gemailten Link eine Handlung, die zu einem Vorschlag wird, und er hindert einen Vorschau-Bot oder einen Mail-Scanner daran, allein durch das Abrufen Zugriff zu gewähren.

Die Bestätigung sollte eine zustandsändernde Anfrage mit den üblichen Cross-Site- und Origin-Abwehrmaßnahmen sein. Das Token sollte einmalig sein und in dem Moment atomar verbraucht werden, in dem die Regel eingerichtet wird, und der Datensatz sollte Eigentümer, Dienst, Adresse, Freigabekennung und Ablauf erfassen, ohne je das rohe Token zu protokollieren.

Die Zustellung des Tokens verdient dieselbe Sorgfalt wie die Regel selbst. Ein abgelaufener oder bereits verbrauchter Link, der noch eine Regel erzeugt, ist eine zweite Tür mit demselben Schlüssel.

Die Adresse wird geteilt, solange die Freigabe lebt

Büro-NAT, Provider-NAT und ein gemeinsamer VPN-Ausgang setzen jeweils mehrere Personen hinter eine Adresse. Diese Adresse zuzulassen lässt alle dahinter zu — soweit es die nächste Grenze des Dienstes betrifft —, während es nichts darüber beweist, wer das Konto hält, das der Dienst erwartet.

Das Entfernen der Regel ist ebenfalls keine universelle Trennung. Bestehende Verbindungen, zwischengespeicherte Anwendungstoken und langlebige Sitzungen können die Regel um Minuten oder weit länger überleben, daher sollte die gewählte Lebensdauer widerspiegeln, was der Dienst nach der Zulassung tut, und nicht nur, wie lange die Regel besteht.

Testen Sie vier Fälle und beide Adressfamilien

Eine Freigabe ist nur so gut wie die vier Fälle, die sie übersteht: eine neue erlaubte Anfrage, ein nicht freigegebener Anfragender, eine Wiederholung desselben Links und dieselbe Anfrage nach dem Ablauf.

Testen Sie dann jede Familie getrennt, denn die Quelladresse, die der Dienst beobachtet, kann sich zwischen ihnen unterscheiden.

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

Das nützliche Ergebnis ist eine vorübergehende, prüfbare Zulassungsentscheidung unter der normalen Benutzerautorisierung statt einer dauerhaften Öffnung, die den Namen dessen trägt, der zuerst geklickt hat.