TL;DR
Ein belastbares Betriebsmodell für die Edge trennt zentrale Schutz- und Netzwerkfunktionen von anwendungsspezifischer Konfiguration. Das Plattformteam verantwortet DNS, TLS, DDoS Protection und technische Erreichbarkeit. Das Anwendungsteam liefert fachliche Anforderungen, WAF-Regeln und belastbare Health-Check-Endpunkte. Shared Responsibility verhindert dabei blinde Zuständigkeitslücken.
Einleitung
Viele Störungen an der Edge entstehen nicht durch fehlende Funktionen, sondern durch unklare Verantwortlichkeiten. Wenn niemand eindeutig für DNS-Einträge, Zertifikate, WAF-Ausnahmen oder Backend Health Checks zuständig ist, werden Änderungen entweder zu langsam umgesetzt oder ohne ausreichende Prüfung vorgenommen. Besonders problematisch ist die Annahme, das Plattformteam müsse jede Anwendung bis ins Detail verstehen oder das Anwendungsteam könne Netzwerk- und Schutzfunktionen selbstständig verwalten. Ein tragfähiges Modell definiert deshalb nicht nur Zuständigkeiten, sondern auch Übergaben, Freigaben und technische Schnittstellen. Platform Engineering schafft dabei den Rahmen; die Anwendung liefert den Kontext.
1. DNS und TLS gehören in eine zentrale Betriebsverantwortung
DNS und TLS-Termination sind zentrale Edge-Funktionen mit Auswirkungen auf Erreichbarkeit, Sicherheit und Änderungsprozesse. Das Plattformteam sollte deshalb die DNS-Zonen, Anycast DNS beziehungsweise Multi-Provider-DNS, Zertifikatsbereitstellung und TLS-Parameter betreiben. Es verantwortet damit auch die technische Konsistenz über mehrere Anwendungen und Umgebungen hinweg.
Das Anwendungsteam muss jedoch festlegen, welche Hostnames benötigt werden, welche Umgebungen erreichbar sein sollen und welche fachlichen Abhängigkeiten bestehen. Eine Anwendung kann beispielsweise zusätzliche Subdomains oder getrennte Endpunkte für APIs erfordern. Diese Anforderungen gehören nicht in die zentrale Plattformlogik.
Die Trennung reduziert operative Risiken: Zertifikats- und DNS-Änderungen folgen standardisierten Prozessen, während anwendungsspezifische Entscheidungen beim verantwortlichen Team bleiben. Wichtig ist eine klare Eskalation für Ablauf, Fehlkonfiguration und Rollback. Die Edge kann TLS terminieren, aber sie kann nicht entscheiden, ob ein bestimmter Hostname fachlich noch benötigt wird.
2. WAF und DDoS Protection brauchen unterschiedliche Zuständigkeiten
DDoS Protection ist eine plattformweite Schutzfunktion. Das Plattformteam verantwortet Aktivierung, Grundkonfiguration, Monitoring und den technischen Betrieb der Schutzmechanismen an der Edge. Diese Verantwortung sollte nicht bei einzelnen Anwendungsteams liegen, weil Angriffe mehrere Services gleichzeitig betreffen können und Schutzmaßnahmen möglichst unabhängig vom Backend greifen müssen.
Eine WAF erfordert dagegen eine geteilte Verantwortung. Das Plattformteam stellt die WAF als zentralen Dienst bereit, pflegt Baseline-Regeln und definiert den sicheren Rahmen für Änderungen. Das Anwendungsteam kennt die konkreten HTTP- und API-Muster: erlaubte Methoden, spezielle Payloads, Uploads oder bewusst notwendige Ausnahmen. Es muss diese Anforderungen dokumentieren und testen.
WAF-Ausnahmen dürfen nicht als dauerhafte Abkürzung für unklare Anwendungsfehler dienen. Jede Ausnahme benötigt einen fachlichen Eigentümer, eine Begründung und eine Prüfung ihrer Reichweite. So bleibt der Schutz zentral steuerbar, ohne legitime Anwendungsmuster pauschal zu blockieren. DDoS Protection bleibt dabei infrastrukturell, WAF-Konfiguration wird zum Shared-Responsibility-Thema.
3. Health Checks trennen Infrastrukturstatus und Anwendungssicht
Backend Health Checks sind nur dann verlässlich, wenn Plattform- und Anwendungsteam unterschiedliche Fragen beantworten. Das Plattformteam prüft, ob ein Backend technisch erreichbar ist: Ist der Dienst über das erwartete Protokoll und den erwarteten Port erreichbar? Funktioniert die Verbindung aus Sicht der Edge? Werden Timeouts, Statuscodes und Failover korrekt verarbeitet?
Das Anwendungsteam verantwortet den Health-Check-Endpunkt und seine Semantik. Dieser Endpunkt sollte den tatsächlichen Zustand der Anwendung geeignet abbilden, ohne unnötig von abhängigen Systemen abzuhängen. Ein Prozess, der zwar läuft, aber keine Requests verarbeiten kann, darf nicht fälschlich als gesund gelten. Umgekehrt sollte ein temporär nicht benötigtes Nebensystem nicht automatisch das gesamte Backend aus dem Routing nehmen.
Diese Grenze ist betrieblich entscheidend. Die Plattform kann bei fehlerhaften Checks Traffic umverteilen oder Backends aus dem Pool entfernen. Sie kann aber nicht beurteilen, ob ein fachlicher Zustand akzeptabel ist. Dafür braucht sie definierte Kriterien vom Anwendungsteam. Werden diese nicht vereinbart, entstehen entweder unnötige Failover oder Traffic zu nicht funktionsfähigen Instanzen.
4. Backend-Erreichbarkeit ist kein reines Plattformproblem
Die Edge kann Traffic terminieren, schützen und zu Backends verteilen. Die tatsächliche Erreichbarkeit hängt jedoch von mehreren Ebenen ab: Routing, Firewall-Regeln, Listenern, Ports, Proxy Protocol, Namensauflösung, Rückwegen und der Konfiguration des Dienstes. Das Plattformteam verantwortet die Edge-seitige Verbindung und dokumentiert die technischen Anforderungen an ein Backend.
Das Anwendungsteam muss sicherstellen, dass der Service auf dem vereinbarten Interface lauscht, die erwarteten Header verarbeitet und Verbindungen aus dem vorgesehenen Netzwerk akzeptiert. Dazu gehört auch, Besonderheiten wie Proxy Protocol oder TLS zwischen Edge und Backend bewusst zu konfigurieren. Backend Cloaking kann den öffentlichen Zugriff auf interne Ziele reduzieren, ersetzt aber keine korrekte Segmentierung und keine funktionierenden Rückwege.
Für die Zusammenarbeit eignet sich eine verbindliche Schnittstelle: Service-Adresse, Port, Protokoll, Health-Check, Timeout-Verhalten, erlaubte Quellinformationen und Verantwortlicher. So wird aus „Backend nicht erreichbar“ eine prüfbare Fehlerkette. Die Edge Cloud kann dabei mit ayedo Managed Kubernetes oder mit Kubernetes-Clustern eigener oder anderer Provider eingesetzt werden. Die Zuständigkeitsgrenze bleibt unabhängig vom Compute-Betreiber bestehen.
Betriebsszenario: Eine neue API wird veröffentlicht
Ein Anwendungsteam möchte eine API unter api.example.de veröffentlichen. Das Plattformteam legt den DNS-Eintrag an, stellt TLS an der Edge bereit und aktiviert die zentrale DDoS Protection. Gemeinsam wird festgelegt, welche WAF-Baseline gilt und ob die API spezielle Methoden oder Payloads benötigt.
Das Anwendungsteam stellt einen Health-Check-Endpunkt bereit und dokumentiert Port, Protokoll, Timeout und erwartetes Verhalten. Das Plattformteam prüft die technische Erreichbarkeit und konfiguriert Failover. Wenn Requests blockiert werden, analysiert das Anwendungsteam zunächst das API-Muster; das Plattformteam bewertet Regel, Logik und Reichweite der WAF-Anpassung. Kein Team verändert die Zuständigkeit des anderen, beide verantworten aber die Übergabe.
FAQ
Wer sollte DNS- und Zertifikatsänderungen freigeben?
Das Plattformteam betreibt DNS und TLS. Das Anwendungsteam bestätigt Hostnames, Gültigkeitsbedarf und fachliche Auswirkungen. Für kritische Änderungen empfiehlt sich eine dokumentierte gemeinsame Freigabe.
Wer ist für eine WAF-Ausnahme verantwortlich?
Das Anwendungsteam begründet die Ausnahme und beschreibt das benötigte Verhalten. Das Plattformteam prüft technische Umsetzung, Reichweite und verbleibendes Risiko.
Reicht ein TCP-Health-Check für ein Backend?
Nur für die technische Erreichbarkeit. Ob die Anwendung Requests verarbeiten kann, muss ein anwendungsspezifischer Health Check mit klarer Semantik prüfen.
Fazit
Verantwortungsgrenzen zwischen Plattformteam und Anwendungsteam sind eine technische Schnittstelle, keine reine Organisationsfrage. Zentrale Funktionen wie DNS, TLS-Termination und DDoS Protection brauchen konsistenten Plattformbetrieb. WAF-Regeln, Health-Check-Semantik und Backend-Anforderungen benötigen dagegen Anwendungskontext. Die ayedo Edge Cloud unterstützt dieses Modell als eigenständige Edge-Plattform vor unterschiedlichen Backends und Kubernetes-Umgebungen. Entscheidend bleibt eine präzise Shared-Responsibility-Vereinbarung.