Eigenes TLS, SSH-Weiterleitung oder VPN für einen Cloud-Dienst

Selten ist die Frage, ob zwischen zwei Cloud-Rechnern etwas verschlüsselt werden soll; sie lautet, welche Schnittstelle Sie verschlüsseln und wer wessen Identität prüft. Ich beginne diese Gespräche beim Dienst statt beim Netzdiagramm, weil der Dienst bereits weiß, was er braucht. Drei Grenzen decken die meisten Fälle ab: das eigene TLS der Anwendung, ein einzelner weitergeleiteter TCP-Port über SSH und ein geroutetes Overlay, das jedem Teilnehmer eine Adresse gibt. Sie sind nicht nach Stärke geordnet, sondern danach, wie viel des Problems sie abdecken.

Beim Dienst anfangen, nicht beim Netz

Gehen Sie vom Prozess nach außen. Welches Protokoll spricht er, welchen Namen wird der Client prüfen, und wer darf überhaupt eine Verbindung öffnen? Diese drei Antworten schließen Optionen schneller aus als jede Vergleichstabelle, und die eigene Konfiguration des Dienstes beantwortet sie meist in wenigen Minuten.

Nehmen Sie eine kleine interne API, die bereits HTTPS auf Port 8443 mit einem Zertifikat für api.internal.example bereitstellt. ss -ltnp auf dem Host zeigt, woran sie bindet, und openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example zeigt, ob das Zertifikat für den Namen gilt, den der Client tatsächlich verwendet. Sind beide gesund, kann der Dienst seinen eigenen Strom schützen, und es bleibt nur die Erreichbarkeit. Das ist ein viel kleineres Problem, als ein Netz zu bauen.

Schritt 1: Schützt sich der Dienst selbst?

Das ist die Option der Wahl, wenn sie passt, und sie passt häufiger, als Teams annehmen. Die Verschlüsselung des Dienstes deckt den gesamten Weg zwischen Client und Server ab, einschließlich jedes Sprungs dazwischen, was kein Tunnel um die Mitte verbessert. Legen Sie den erwarteten Namen und das Vertrauen ausdrücklich fest, statt sich darauf zu verlassen, was der Standard-Speicher des Clients zufällig enthält.

Verschlüsselung und Erreichbarkeit bleiben getrennte Kontrollen, und genau ihre Vermischung lässt diese Option schiefgehen. Ein TLS-Dienst auf einem uneingeschränkten öffentlichen Listener nimmt weiterhin Verbindungsversuche von jedem an, also müssen Listener und Netzregeln unabhängig davon abgegrenzt werden, dass die Nutzlast geschützt ist. Prüfen Sie dann die Abhängigkeiten, denn eine API über TLS sagt nichts über den Discovery-Endpunkt, den Admin-Port oder den Bulk-Transfer-Kanal daneben. Jeder davon braucht eine eigene Antwort, und ein ungeschützter Bruder genügt, um die ganze Grenze zur Fiktion zu machen.

Schritt 2: Ist ein TCP-Port die ganze Anforderung?

Wenn die Anforderung wirklich ein TCP-Port ist, ist eine Weiterleitung das Kleinste, was funktioniert. Eine lokale SSH-Weiterleitung trägt diesen Port durch eine bereits bestehende authentifizierte Verbindung.

Die Form ist ssh -N -L 8443:127.0.0.1:8443 [email protected], und das entscheidende Detail ist die Zieladresse: 127.0.0.1 wird auf der Gegenseite aufgelöst, sodass die Verbindung zum Dienst vom Bastion statt von Ihrem Laptop aus geöffnet wird. Binden Sie den lokalen Listener eng als -L 127.0.0.1:8443:..., damit Sie den Dienst nicht versehentlich in Ihrem lokalen Netz veröffentlichen. Beschränken Sie serverseitig, was das Konto weiterleiten darf, statt dem Client gutes Verhalten zuzutrauen. PermitOpen, AllowTcpForwarding local und ein Standard-GatewayPorts no sind die drei Einstellungen, die ein Allzweck-Relais in einen bestimmten Kanal verwandeln.

Der Vertrag ist in beide Richtungen eng. SSH schützt seinen eigenen Kanal, und ein weiterer Sprung vom Bastion zu einer anderen Anwendung braucht eigenen Schutz. Ein Dienst, der nur auf dem Loopback des Bastions lauscht, hat eine ganz andere Exposition als einer, der über ein anderes Netz erreicht wird, und die Weiterleitung ändert das nicht. Behalten Sie Authentifizierung und TLS-Prüfungen der Anwendung bei, statt den Tunnel als Ersatz dafür zu behandeln.

Das funktioniert gut für eine Verbindung mit einem Eigentümer. Im Maßstab wird daraus ein System: lokale Portkonflikte, Überwachung, Schlüsselrotation und die Frage, wer die Weiterleitung nach einem Neustart neu startet.

Schritt 3: Ist Routing die eigentliche Anforderung?

Diese Liste ist der ehrliche Preis der kleinsten Option, und deshalb ersetzen Teams irgendwann eine Handvoll vergessener Hintergrundbefehle durch etwas Verwaltetes. Der Ersatz ist nicht automatisch ein VPN. Ist die Anforderung weiterhin ein TCP-Port, ist eine überwachte Weiterleitung mit dokumentiertem Eigentümer billiger zu betreiben als ein Overlay, und sie scheitert auf sichtbare Weise. Messen Sie den Betriebsbesitz, bevor Sie Eleganz messen.

Routing wird zur richtigen Antwort, wenn Routing die Anforderung ist. Mehrere Anwendungen, die gewöhnliche IP-Konnektivität brauchen, Protokolle, die eine TCP-Weiterleitung nicht tragen kann, oder Dienste, die zwischen Hosts wandern, zeigen alle in dieselbe Richtung.

Ein Overlay gibt den Teilnehmern eine Adresse und eine Route, und dann beginnt die eigentliche Arbeit: sich nicht überschneidende Bereiche, Routeneigentum, DNS, Registrierung, Widerruf und was passiert, wenn ein Peer verschwindet. Nichts davon kommt mit der Adresse. Ein in das Overlay aufgenommener Peer ist auch nicht automatisch für jede Operation am Ziel autorisiert, also bleibt die Authentifizierung auf Dienstebene.

Was Ihnen danach gehört

Zwei Dinge gehören in die Aufzeichnung, die Sie hinterlassen. Das erste ist die Identität, die der Client prüfen soll, denn jede dieser Grenzen verschlechtert sich still, sobald eine Namensprüfung gelockert wird, damit etwas funktioniert. Das zweite ist der Entfernungsschritt: welcher Schlüssel, welche Regel oder welche Route verschwindet, wenn der Zugang endet, und wer ihn ausführt.

Der Rundgang endet, wo er begann, beim Dienst. Wählen Sie die Grenze, die den tatsächlichen Verkehr abdeckt und die Peers prüft, die Sie prüfen wollten, und schreiben Sie dann auf, wie Zugang aktualisiert, überwacht und entfernt wird. Die OpenSSH-Referenz ist der Ort, an dem Sie die Weiterleitungsoptionen bestätigen, bevor Sie einen engen Vertrag versprechen. Wenn Sie den Entfernungsschritt nicht in einem Satz beschreiben können, ist die Grenze größer als das Problem.