TL;DR
TLS Termination beendet die äußere HTTPS-Verbindung an der Edge und schafft den technischen Übergabepunkt für anwendungsbezogenes Routing. Damit werden Host-, Pfad- und Header-Regeln möglich. Die Architektur muss jedoch klar festlegen, welche Sicherheits- und Routingaufgaben die Edge übernimmt und welche Kontrolle beim Backend verbleibt.
Einleitung
TLS Termination ist keine reine Performance- oder Komfortfunktion. Sie verändert den Punkt, an dem verschlüsselter Client-Traffic sichtbar, geprüft und anhand von Layer-7-Merkmalen verteilt werden kann. Ein typischer Architekturfehler besteht darin, HTTPS an der Edge zu beenden, danach aber keine klare Trennung zwischen Edge-Routing und Backend-Verantwortung zu definieren. Dann entstehen unklare Vertrauensgrenzen, widersprüchliche Routingregeln oder unnötige Abhängigkeiten von einzelnen Infrastrukturen. Entscheidend ist deshalb nicht nur, wo TLS endet, sondern auch, welche Informationen dort ausgewertet werden und wie der Traffic anschließend kontrolliert an Anwendungen und APIs übergeben wird.
1. TLS Termination schafft einen kontrollierten Übergabepunkt
Bei einer TLS-Verbindung verschlüsselt der Client den HTTP-Traffic bis zum Terminierungspunkt. Erfolgt die TLS Termination an der Edge, wird die äußere Verbindung dort angenommen, der TLS-Handshake durchgeführt und die Anfrage für die weitere Verarbeitung zugänglich gemacht. Erst dadurch lassen sich HTTP-Attribute wie Hostname, Pfad, Methode oder bestimmte Header für Layer-7-Routing verwenden.
Architektonisch entsteht damit eine klare Übergabe: Die Edge verantwortet den öffentlichen Zugang, die TLS-Verarbeitung und die erste Traffic-Steuerung. Das Backend muss nicht selbst den gesamten öffentlichen HTTPS-Eingang abbilden. Diese Trennung reduziert die Zahl direkt exponierter Komponenten und unterstützt Backend Cloaking, weil interne Zielsysteme nicht als öffentliche Endpunkte auftreten müssen.
Die Edge wird dadurch allerdings zu einer sicherheitsrelevanten Vertrauensgrenze. Zertifikatsverwaltung, erlaubte Protokolle, Routingregeln und der Umgang mit weitergereichten Anfrageinformationen müssen zusammen betrachtet werden. TLS Termination ist daher eine Architekturentscheidung über Zuständigkeiten, nicht nur eine Einstellung am Loadbalancer.
2. Layer-7-Routing braucht belastbare Entscheidungsregeln
Nach der TLS Termination kann die Edge HTTPS Routing auf Anwendungsebene umsetzen. Typische Regeln unterscheiden beispielsweise zwischen mehreren Hostnames, API-Pfaden oder Versionen eines Dienstes. So kann api.example.de zu einem anderen Backend führen als app.example.de; ebenso kann /v1 getrennt von /v2 behandelt werden. Layer-7-Regeln verbinden damit den öffentlichen Einstiegspunkt mit der logischen Struktur der Anwendungen.
Diese Flexibilität erhöht aber die Komplexität. Routing sollte nicht auf zufällig variierenden Headern, impliziten Reihenfolgen oder schwer nachvollziehbaren Ausnahmen beruhen. Sinnvoll sind deterministische Regeln mit klarer Priorität, dokumentierten Fallbacks und einem definierten Verhalten bei unbekannten Hosts oder Pfaden. Andernfalls können neue Services versehentlich über bestehende Regeln erreichbar werden.
Für den Betrieb ist außerdem wichtig, dass die Edge den Zustand der Backends berücksichtigt. Health Checks und Failover verhindern, dass Traffic dauerhaft an nicht verfügbare Ziele geleitet wird. Die ayedo Edge Cloud verbindet TLS Termination mit Layer-4- und Layer-7-Loadbalancing sowie Backend Health Checks. Damit wird Routing nicht als statische Weiterleitung, sondern als kontrollierter Teil des öffentlichen Traffic-Eingangs behandelt.
3. Die TLS-Strecke zum Backend muss bewusst definiert werden
Mit dem Ende der Client-TLS-Verbindung ist die Kommunikation nicht automatisch auf jedem Abschnitt gleich geschützt. Zwischen Edge und Backend kann abhängig von der Zielarchitektur eine neue verschlüsselte Verbindung oder eine andere abgesicherte Transportstrecke erforderlich sein. Diese Entscheidung hängt von Schutzbedarf, Netzwerksegmentierung, Compliance-Vorgaben und den Fähigkeiten der nachgelagerten Plattform ab.
Wichtig ist, die externe und die interne Identität einer Anfrage sauber auseinanderzuhalten. Das Backend muss erkennen können, ob eine Anfrage ursprünglich über HTTPS eingegangen ist, welchen Hostnamen sie adressierte und unter welchem Pfad sie geroutet wurde. Solche Informationen dürfen nicht unkontrolliert aus beliebigen Client-Headern übernommen werden. Sie müssen an der Vertrauensgrenze konsistent gesetzt, validiert und im Backend entsprechend ausgewertet werden.
Auch die Quelladresse verdient Aufmerksamkeit. Für Logging, Rate Limiting oder Sicherheitsanalysen kann die ursprüngliche Client-IP relevant sein. Verfahren wie Proxy Protocol können diese Information transportieren, sofern die Backend-Seite sie sicher und korrekt verarbeitet. Entscheidend bleibt: Die Edge definiert die Übergabe, das Backend muss die übergebenen Metadaten in seiner Vertrauenszone korrekt behandeln.
4. Edge und Backend brauchen getrennte Verantwortlichkeiten
Die Edge sollte den öffentlichen Traffic-Eingang steuern, aber nicht die fachliche Logik der Anwendung ersetzen. Sie entscheidet, welches Backend eine Anfrage erreicht, kann den Zugang absichern und fehlerhafte oder unerwünschte Muster bereits vor der Anwendung abweisen. Das Backend bleibt für Authentisierung, Autorisierung, Geschäftslogik und die fachliche Validierung zuständig.
Diese Trennung wirkt sich direkt auf den Betrieb aus. Routingänderungen, Failover und die Verteilung eingehender Last können unabhängig vom Deployment einzelner Anwendungen organisiert werden. Gleichzeitig dürfen Edge-Regeln nicht zum zweiten, unkoordinierten Konfigurationssystem neben Ingress- oder Gateway-Konfigurationen im Cluster werden. Zuständigkeiten, Änderungsprozesse und Rollback-Verfahren müssen deshalb festgelegt sein.
Das gilt auch bei Kubernetes: Die Integration der Edge kann mit ayedo Managed Kubernetes erfolgen, aber ebenso mit eigenen oder bei anderen Providern betriebenen Clustern. Die Edge bleibt dabei eine eigenständige Plattform für öffentlichen Zugang, TLS Termination und Traffic-Steuerung. Diese providerunabhängige Nutzung verhindert, dass HTTPS Routing automatisch an den Lebenszyklus eines bestimmten Compute-Clusters gekoppelt wird.
Praxisszenario: Zwei Anwendungen, ein öffentlicher Einstieg
Ein Unternehmen betreibt eine Webanwendung und eine API in getrennten Kubernetes-Clustern. Beide sollen unter einer gemeinsamen Domain erreichbar sein. TLS wird an der Edge terminiert. Eine Layer-7-Regel leitet /api an das API-Backend, alle übrigen Pfade an die Webanwendung. Fällt das API-Backend aus, greifen dessen Health Checks und Failover-Regeln, ohne das Routing der Webanwendung zu verändern.
Die Backends bleiben nicht direkt öffentlich adressierbar. Für die Auswertung von Logs und Zugriffskontrollen werden die relevanten Ursprungsinformationen kontrolliert übergeben. Die Cluster können unabhängig voneinander betrieben oder ersetzt werden, während der öffentliche TLS-Endpunkt und die grundlegende Routingstruktur an der Edge bestehen bleiben.
FAQ
Muss TLS immer bis zum Backend durchgehend bestehen?
Nicht zwingend. Die passende Transportabsicherung zwischen Edge und Backend hängt von Schutzbedarf, Netzwerkarchitektur und Vertrauensgrenzen ab. Sie muss ausdrücklich festgelegt und technisch umgesetzt werden.
Welche Informationen eignen sich für Layer-7-Routing?
Typische Kriterien sind Hostname, Pfad und HTTP-Methode. Regeln sollten stabil, nachvollziehbar und priorisiert sein. Zufällige oder ungeprüfte Header sind als Routinggrundlage problematisch.
Ersetzt TLS Termination die Anwendungssicherheit?
Nein. Die Edge schützt und steuert den öffentlichen Zugang. Authentisierung, Autorisierung, Eingabevalidierung und Geschäftslogik bleiben Verantwortlichkeiten der Anwendung beziehungsweise ihrer Backend-Dienste.
Fazit
TLS Termination an der Edge ist ein architektonischer Übergabepunkt: Von der verschlüsselten öffentlichen Verbindung führt der Weg zu kontrolliertem Layer-7-Routing und definierten Backend-Zuständigkeiten. Wer diese Grenze sauber gestaltet, kann öffentliche Erreichbarkeit, Backend Cloaking und providerunabhängigen Betrieb miteinander verbinden. Die ayedo Edge Cloud ist in diesem Modell nicht lediglich ein vorgeschalteter Loadbalancer, sondern die Plattform für TLS-Verarbeitung, Traffic-Eingang und die strukturierte Übergabe an unterschiedliche Compute-Umgebungen.