TL;DR
Eine belastbare Security-Schichtenarchitektur verteilt Schutzaufgaben auf unterschiedliche Ebenen: TLS schützt die Transportverbindung, die WAF bewertet HTTP-Anfragen und das Backend bleibt für Autorisierung, Validierung und Datenschutz verantwortlich. Entscheidend sind die Übergabepunkte zwischen diesen Schichten. Jede Entschlüsselung, Weiterleitung und Protokollumwandlung erzeugt dabei eigene Vertrauens- und Betriebsanforderungen.
Einleitung
TLS, WAF und Backend werden in der Praxis häufig als ein zusammenhängender Schutzmechanismus behandelt. Das führt zu einer problematischen Annahme: Ist TLS aktiv und eine WAF vorgeschaltet, sei die Anwendung automatisch ausreichend abgesichert. Tatsächlich erfüllen die drei Komponenten unterschiedliche Aufgaben und sehen jeweils nur einen Teil des Datenverkehrs. TLS schützt primär den Transportweg, die WAF analysiert Anwendungsanfragen und das Backend muss Geschäftslogik, Identitäten und Daten selbst absichern. Eine Security-Schichtenarchitektur ist deshalb vor allem eine Frage sauber definierter Zuständigkeiten, Übergabepunkte und verbleibender Risiken.
1. TLS Termination definiert die erste Vertrauensgrenze
TLS schützt die Vertraulichkeit und Integrität einer Verbindung zwischen Client und einem TLS-Endpunkt. Bei TLS Termination an der Edge endet diese Verbindung nicht erst am Backend, sondern bereits an der Edge-Plattform. Dort wird der verschlüsselte HTTP-Traffic entschlüsselt und kann für nachgelagerte Sicherheitsfunktionen ausgewertet werden.
Diese Architektur ist technisch notwendig, wenn eine WAF HTTP-Methoden, Header, Cookies oder Request-Bodies prüfen soll. Eine WAF kann verschlüsselten Inhalt ohne Entschlüsselung nicht sinnvoll bewerten. Gleichzeitig entsteht an der Edge eine neue Vertrauensgrenze: Der entschlüsselte Datenverkehr liegt dort im Klartext vor und muss innerhalb der Plattform entsprechend verarbeitet und weitergeleitet werden.
Für das Backend folgt daraus eine klare Prüfpflicht. Die Absicherung der Client-zu-Edge-Verbindung sagt nichts über die Verbindung von der Edge zum Backend aus. Diese Strecke benötigt eine eigene Transport- und Vertrauensentscheidung. TLS Termination reduziert also nicht automatisch jedes Backend-Risiko; sie verschiebt einen Teil der Sicherheitsverantwortung an einen definierten Übergabepunkt.
2. Die WAF arbeitet auf der Anwendungsschicht
Eine WAF schützt HTTP- und HTTPS-Services, indem sie Requests anhand von Eigenschaften der Anwendungsschicht bewertet. Dazu zählen beispielsweise Methoden, Pfade, Header, Parameter oder typische Angriffsmuster. Ihre Stärke liegt dort, wo Netzwerk- und Transportschutz nicht ausreichen: bei missbrauchbaren Requests, unerwarteten Eingaben und bekannten Angriffsmustern gegen Webanwendungen.
Die WAF ist jedoch keine Ersatzinstanz für TLS und kein vollständiger Schutz des Backends. Sie kann nur Daten prüfen, die sie tatsächlich erreicht und interpretieren kann. Protokollabweichungen, unklare Header-Weitergabe oder fehlerhafte TLS-Konfigurationen können deshalb die Analyse beeinflussen. Ebenso bleiben fachliche Fehler möglich, wenn ein Request technisch korrekt aussieht, aber gegen die Geschäftslogik verstößt.
In der ayedo Edge Cloud liegt die WAF vor den eigentlichen Backends und kann mit der TLS Termination an der Edge verbunden werden. Damit entsteht ein zentraler Prüfpunkt vor der Compute-Infrastruktur. Die Anwendung bleibt dennoch für Authentifizierung, Autorisierung, Eingabevalidierung und sichere Verarbeitung verantwortlich.
3. Backend-Sicherheit beginnt hinter der WAF
Das Backend darf nicht als passiver Empfänger bereits geprüfter Requests betrachtet werden. Es muss seine eigenen Sicherheitsannahmen validieren: Identitäten und Berechtigungen sind zu prüfen, Eingaben müssen kontextbezogen validiert werden, und sensible Operationen benötigen serverseitige Kontrollen. Eine WAF kann Angriffsindikatoren erkennen, aber keine fachliche Autorisierung ersetzen.
Besonders relevant ist die Frage, welche Header und Quellinformationen an das Backend weitergegeben werden. Werden Client-IP, Host oder Protokollinformationen für Logging, Rate Limits oder Sicherheitsentscheidungen verwendet, muss ihre Herkunft eindeutig sein. Der Proxy Protocol-Mechanismus kann solche Verbindungsinformationen strukturiert an nachgelagerte Systeme übertragen. Das Backend muss dieses Protokoll jedoch korrekt unterstützen und darf unvalidierte Header nicht als vertrauenswürdig behandeln.
Zusätzlich sollte das Backend nicht direkt öffentlich erreichbar sein, wenn der gesamte externe Traffic über die Edge geführt werden soll. Backend Cloaking reduziert diese Angriffsfläche, indem die internen Ziele nicht als öffentlicher Einstiegspunkt dienen. Health Checks und Failover helfen beim Betrieb, ersetzen aber weder Zugriffskontrollen noch die Absicherung der Backend-Verbindung.
4. Übergabepunkte bestimmen die verbleibenden Risiken
Jede Schicht kann nur ihre eigene Sicht auf den Traffic bewerten. Zwischen Client, Edge und Backend entstehen deshalb Übergabepunkte, an denen Protokolle beendet, Informationen ergänzt oder Sicherheitsentscheidungen weitergereicht werden. Genau dort liegen häufig die schwer erkennbaren Fehlkonfigurationen.
Ein typisches Beispiel ist die unterschiedliche Interpretation von URL-Pfaden oder Headern an Edge, WAF und Anwendung. Wenn die WAF eine Anfrage anders normalisiert als das Backend, kann ein Request an der Schutzschicht unauffällig erscheinen, aber im Backend eine andere Bedeutung erhalten. Ähnliche Risiken entstehen durch nicht konsistente TLS-, Host- oder Proxy-Protocol-Annahmen.
Eine belastbare Security-Schichtenarchitektur dokumentiert daher für jede Strecke: Wer terminiert TLS? Welche Instanz sieht den Klartext? Welche Informationen werden weitergegeben? Welche Quelle gilt als vertrauenswürdig? Und welche Prüfung erfolgt erst im Backend? In der ayedo Edge Cloud lassen sich öffentliche Routing-, Schutz- und Weiterleitungsfunktionen zentral vor den Workloads bündeln. Die konkrete Sicherheitsqualität hängt jedoch von der konsistenten Konfiguration aller beteiligten Schichten ab.
Praxis- und Betriebsszenario
Ein Unternehmen betreibt eine API auf einem eigenen Kubernetes-Cluster bei einem Cloud-Provider. Der öffentliche DNS-Eintrag zeigt auf die ayedo Edge Cloud. Dort endet TLS, die WAF prüft die HTTP-Anfragen und der Traffic wird anschließend an das Backend weitergeleitet. Das Backend ist nicht direkt öffentlich exponiert und akzeptiert nur den vorgesehenen Weiterleitungspfad.
Für den Betrieb müssen nun mehrere Punkte getrennt überwacht werden: Zertifikatsstatus und TLS-Fehler an der Edge, blockierte oder auffällige Requests in der WAF sowie Authentifizierungs- und Autorisierungsfehler in der API. Fällt ein Backend aus, können Health Checks die Weiterleitung beeinflussen. Sie sagen jedoch nichts darüber aus, ob die Anwendung fachlich korrekt oder sicher arbeitet. Erst die getrennte Betrachtung macht die Ursache eines Fehlers sichtbar.
FAQ
Schützt TLS Termination auch die Verbindung zum Backend?
Nein. TLS Termination schützt die Verbindung bis zum TLS-Endpunkt an der Edge. Die Strecke zwischen Edge und Backend muss separat bewertet und entsprechend den Schutzanforderungen der Anwendung abgesichert werden.
Ersetzt eine WAF die Validierung im Backend?
Nein. Eine WAF erkennt bestimmte HTTP-basierte Angriffsmuster. Fachliche Autorisierung, Eingabevalidierung, Geschäftslogik und der Schutz sensibler Daten bleiben Aufgaben der Anwendung.
Warum sind Übergabepunkte sicherheitsrelevant?
An Übergabepunkten werden Verbindungen beendet, Informationen weitergereicht oder Protokolle interpretiert. Abweichende Annahmen zwischen Edge, WAF und Backend können dadurch Schutzmechanismen unwirksam machen.
Fazit
Eine Security-Schichtenarchitektur ist kein einzelnes Produktfeature, sondern eine klare Verteilung von Sicherheitsaufgaben. TLS schützt den Transport bis zur definierten Termination, die WAF bewertet HTTP-Anfragen und das Backend trägt die Verantwortung für Identität, Geschäftslogik und Daten. Die ayedo Edge Cloud kann diese vorgelagerten Funktionen zentral bündeln und Backends providerunabhängig anbinden. Entscheidend bleibt, die Übergabepunkte explizit zu gestalten und jedes verbleibende Risiko einer konkreten Schicht zuzuordnen.