TL;DR
Security-Funktionen gehören nicht pauschal an einen einzigen Ort. Die Edge eignet sich für Schutzmaßnahmen mit hoher Sichtbarkeit, großem Skalierungsbedarf und standardisierbaren Regeln. Die Anwendung bleibt für Identität, Autorisierung und fachliche Zugriffskontrollen verantwortlich. Entscheidend sind Kontextbedarf, Fehlkonfigurationsrisiko und die Frage, wie früh ein Angriff erkannt und begrenzt werden kann.
Einleitung
Ein häufiger Architekturfehler besteht darin, Sicherheitsverantwortung vollständig an die Edge oder vollständig in die Anwendung zu verlagern. Beides erzeugt blinde Flecken: Eine Edge kann volumetrische Angriffe und viele HTTP-Muster früh abfangen, kennt aber meist nicht die fachliche Bedeutung einer Transaktion. Die Anwendung kann Benutzer, Rollen und Geschäftsobjekte bewerten, erreicht diese Entscheidung jedoch erst, nachdem Traffic Infrastruktur und Laufzeit bereits belastet. Ein belastbares Modell verteilt Security-Funktionen deshalb entlang ihrer Sichtbarkeit, ihres Kontextbedarfs und ihrer Skalierungsanforderungen. Dabei müssen auch Fehlkonfigurationen berücksichtigt werden: Eine falsch platzierte oder zu weit gefasste Regel kann entweder Schutzwirkung verlieren oder legitime Anfragen blockieren.
1. Sichtbarkeit bestimmt den passenden Security Layer
Die Edge sieht den öffentlichen Traffic, bevor er die Backends erreicht. Sie kann Quellnetze, Protokolle, Ports, TLS-Verbindungen, HTTP-Anfragen, Header und typische Angriffsmuster auswerten. Diese Sichtbarkeit reicht für DDoS-Abwehr, Rate-Limiting-Konzepte, grobe Zugriffsmuster und viele WAF-Prüfungen aus. Der Vorteil liegt in der frühen Entscheidung: Schädlicher Traffic verbraucht weniger Ressourcen in Loadbalancing, Cluster und Anwendung.
Die Anwendung besitzt dagegen zusätzliche Informationen. Sie kennt Benutzerkonten, Rollen, Mandanten, Warenkörbe, Freigabestatus oder die zulässigen Zustandsübergänge einer Transaktion. Diese Informationen sind für fachliche Zugriffskontrollen unverzichtbar. Eine Edge-Regel kann erkennen, dass eine Anfrage /api/orders/123 aufruft. Sie weiß ohne Anwendungskontext aber nicht, ob der authentisierte Benutzer diese Bestellung sehen darf. Sichtbarkeit ist damit das erste Entscheidungskriterium: Was am Netzwerk- oder HTTP-Rand erkennbar ist, kann dort geschützt werden; was Geschäftslogik erfordert, muss in der Anwendung entschieden werden.
2. Skalierung spricht für frühe Abwehr
DDoS-Abwehr und standardisierbare WAF-Prüfungen profitieren von einer vorgelagerten, verteilten Durchsetzung. Je früher ungültige oder missbräuchliche Anfragen verworfen werden, desto weniger Arbeit entsteht in Firewalls, Ingress-Komponenten, API-Prozessen und Datenbanken. Das ist nicht nur eine Security-Frage, sondern auch eine Frage der Verfügbarkeit und der Betriebskosten. Schutz direkt in der Anwendung skaliert mit deren Ressourcen und kann bei hohem Angriffsdruck selbst zum Engpass werden.
Die ayedo Edge Cloud übernimmt als öffentlicher Eingang DDoS Protection und Scrubbing an der Edge sowie WAF-Funktionen für HTTP- und HTTPS-Services. TLS Termination kann zusätzlich dazu beitragen, verschlüsselte Anfragen vor der Weiterleitung zentral zu prüfen. Backend Cloaking reduziert dabei die direkte Sichtbarkeit der eigentlichen Backends. Diese Funktionen ersetzen keine Anwendungssecurity. Sie verschieben jedoch die erste Schutzentscheidung an einen Ort, an dem Traffic zentral, verteilt und vor der Compute-Infrastruktur bewertet werden kann.
3. Identität und Autorisierung brauchen Anwendungskontext
Authentifizierung und Autorisierung werden häufig vermischt. Authentifizierung beantwortet, wer ein Aufrufer ist. Autorisierung entscheidet, was dieser Aufrufer unter bestimmten Bedingungen tun darf. Eine zentrale Edge-Komponente kann je nach Architektur die Prüfung von Tokens oder Client-Zertifikaten übernehmen. Ob diese Funktion sinnvoll ist, hängt von den vorhandenen Identitätsquellen, Protokollen und Vertrauensgrenzen ab. Sie darf nicht automatisch als Ersatz für jede Prüfung in der Anwendung verstanden werden.
Die Anwendung muss weiterhin sicherstellen, dass Identität, Mandant, Ressource und Aktion zusammenpassen. Besonders bei APIs reicht eine grobe Regel wie „angemeldete Benutzer dürfen /orders aufrufen“ nicht aus. Erforderlich kann sein, dass ein Benutzer nur Bestellungen seines Mandanten lesen oder eine Transaktion nur in einem bestimmten Status ändern darf. Solche Regeln gehören in die Anwendung oder in eine eng daran gekoppelte Policy-Schicht. Eine Edge-Prüfung kann Last reduzieren und offensichtlich ungültige Zugriffe abweisen, aber die fachliche Entscheidung nicht zuverlässig vorwegnehmen.
4. Fehlkonfiguration als eigenes Entscheidungskriterium
Jede Security-Schicht erzeugt Betriebsrisiken. Eine zu restriktive WAF-Regel kann legitime Requests blockieren, eine zu großzügige Regel lässt Angriffe passieren. In der Anwendung können dagegen uneinheitliche Prüfungen entstehen: Ein Endpoint validiert Mandantenzugehörigkeit, ein anderer vergisst sie. Die Verteilung sollte daher nicht nur nach technischer Machbarkeit erfolgen, sondern auch nach der Wahrscheinlichkeit und Auswirkung von Fehlkonfigurationen.
Edge-Regeln eignen sich für zentral sichtbare, nachvollziehbare Schutzanforderungen: erlaubte Protokolle, bekannte Angriffsmuster, grobe Request-Limits oder die Abschirmung nicht öffentlicher Backends. Fachliche Policies sollten nahe an den Domänenmodellen liegen und mit Tests, Code-Reviews sowie nachvollziehbaren Änderungsprozessen betrieben werden. Wichtig ist außerdem die Beobachtbarkeit: Blockierungen an der Edge und Ablehnungen in der Anwendung müssen unterscheidbar sein. Traffic- und Usage-Statistiken der Edge können dabei die Wirkung vorgelagerter Regeln sichtbar machen; Anwendungslogs erklären, warum eine fachliche Entscheidung abgelehnt wurde.
Praxis- und Betriebsszenario
Ein Unternehmen betreibt eine öffentliche API auf einem Kubernetes Cluster. Die Edge übernimmt Anycast-basiertes Layer-7-Loadbalancing, TLS Termination, WAF-Prüfungen und DDoS-Abwehr. Nicht öffentliche Backend-Adressen werden durch Backend Cloaking verborgen. Die Anwendung prüft anschließend Token, Mandantenzugehörigkeit und die Berechtigung für einzelne Ressourcen.
Bei einer Änderung wird ein neuer Parameter eingeführt, den die WAF zunächst als verdächtig blockiert. Die Edge-Statistiken zeigen erhöhte Ablehnungen, während die Anwendung keine entsprechenden Requests sieht. Die Regel kann gezielt angepasst werden, ohne die fachlichen Autorisierungsprüfungen zu verändern. Umgekehrt bleibt eine fehlerhafte Mandantenprüfung ein Anwendungsproblem und wird nicht durch eine generische Edge-Regel gelöst. Dieses Modell trennt Infrastruktur- und Domänenverantwortung klar.
FAQ
Sollte jede WAF-Regel zusätzlich in der Anwendung umgesetzt werden?
Nein. WAF-Regeln und Anwendungsvalidierung haben unterschiedliche Ziele. Sicherheitskritische Eingaben müssen in der Anwendung unabhängig davon validiert werden, weil nur sie ihren fachlichen Kontext kennt.
Kann die Edge Autorisierung vollständig übernehmen?
Nur für klar definierte, kontextarme Regeln. Ressourcen- und transaktionsbezogene Berechtigungen gehören in die Anwendung, da dort Identität, Mandant und Geschäftsstatus zusammengeführt werden.
Warum reicht DDoS-Schutz in der Anwendung nicht aus?
Die Anwendung wird erst aktiv, nachdem Traffic Netzwerk, Routing und Laufzeit erreicht hat. Vorgelagerte Abwehr reduziert Ressourcenverbrauch und schützt auch dann, wenn die Anwendung selbst bereits überlastet ist.
Fazit
Security-Funktionen sollten entlang ihrer Entscheidungsgrundlage verteilt werden. Die Edge schützt, was früh sichtbar, standardisierbar und skalierungsrelevant ist. Die Anwendung entscheidet dort, wo Identität, Ressourcen und Geschäftslogik zusammenwirken. Für Unternehmen entsteht daraus kein Entweder-oder, sondern ein abgestimmtes Security-Layer-Modell. Die ayedo Edge Cloud ist in diesem Modell der öffentliche Schutz- und Verteilungspunkt; Autorisierung und fachliche Zugriffskontrolle bleiben Verantwortung der jeweiligen Anwendung.