Ich habe schon ein API Gateway. Wozu brauche ich Signando REST?
Das Schweizer Käse Modell erklärt, warum eine einzelne Sicherheitsschicht nie ausreicht.
Das Schweizer Käse Modell
Das Schweizer Käse Modell (auch bekannt als Defence in Depth) ist ein grundlegendes Sicherheitsprinzip: Jede Sicherheitsmaßnahme hat Löcher — Schwachstellen, Fehlkonfigurationen, Zero-Day-Exploits oder Implementierungsfehler. Wie Scheiben von Schweizer Käse hat jede Schicht Lücken.
🧀 Die entscheidende Erkenntnis
Wenn Sie mehrere Käsescheiben stapeln, sind die Löcher nicht deckungsgleich. Ein Angriff, der durch eine Schicht schlüpft, wird von der nächsten abgefangen. Sie brauchen mindestens ZWEI unabhängige Sicherheitsschichten in Serie, um sicherzustellen, dass eine einzelne Schwachstelle nicht ausgenutzt werden kann.
Wichtig: Wählen Sie ein zweites Gateway, das technologisch und wirtschaftlich Abstand zu Ihrem bestehenden Gateway hat — andere Programmiersprache, anderer Hersteller. Verwenden Sie nicht zwei Java-basierte Gateways, da diese dieselben Java-Schwachstellen teilen würden (z.B. Log4Shell). Deshalb wurde Signando REST von Grund auf neu in Rust entwickelt, statt bestehende Open-Source-Produkte wiederzuverwenden.
Warum Ihr bestehendes Gateway nicht ausreicht
🔓 Single Point of Failure
Wenn Ihr API Gateway eine Schwachstelle hat — und jede Software hat welche — hat ein Angreifer direkten Zugang zu Ihrem Backend. Es gibt nichts anderes, das ihn aufhält.
- Zero-Day-Exploits in der Gateway-Software
- Falsch konfigurierte Regeln oder Policies
- Authentifizierungs-Bypass-Schwachstellen
- Unzureichende Input-Validierung
🛡️ Mit Signando REST zusätzlich
Selbst wenn ein Angreifer Ihr Gateway ausnutzt, bietet Signando REST eine unabhängige zweite Prüfung. Der Angriff muss BEIDE Systeme überwinden — exponentiell schwieriger.
- Unabhängige Codebasis (keine gemeinsamen Schwachstellen)
- Schema-basierte Validierung (anderer Ansatz)
- Response-Validierung (erkennt Backend-Kompromittierung)
- In Rust geschrieben (speichersicher)
Reale Angriffsszenarien
🔔 Trust but Verify: Blockieren UND Alarmieren
Signando REST blockiert Angriffe nicht nur — es alarmiert auch. Das ist der Schlüssel zum "Trust but Verify"-Prinzip:
- Wenn Ihr erstes Gateway korrekt arbeitet, sollte jede Anfrage Signando REST ohne Beanstandung passieren
- Wenn Sie plötzlich Alarme von Signando REST erhalten, wissen Sie: Etwas stimmt nicht mit dem ersten Gateway (Bug, Exploit, Fehlkonfiguration)
- Das ist der einzige Weg zu erkennen, wenn Ihre primäre Sicherheit versagt — sonst würden Sie es nie bemerken
- Das gleiche gilt für Responses: Sowohl Request als auch Response werden doppelt geprüft
Szenario 1: Gateway-Schwachstelle
❌ Ohne Signando REST
CVE in Ihrem Gateway → Angreifer umgeht alle Sicherheit → Direkter Backend-Zugang → Datenleck
✅ Mit Signando REST
CVE in Ihrem Gateway → Angreifer umgeht Gateway → Signando REST blockiert ungültige Anfrage → Angriff gestoppt
Szenario 2: Fehlkonfiguration
❌ Ohne Signando REST
Admin-Fehler legt Endpoint offen → Angreifer greift auf unautorisierten API zu → Datenexfiltration
✅ Mit Signando REST
Admin-Fehler legt Endpoint offen → Signando REST validiert weiterhin gegen OpenAPI-Spec → Unautorisierter Zugriff verweigert
Szenario 3: Supply-Chain-Angriff
❌ Ohne Signando REST
Kompromittierte Gateway-Abhängigkeit → Schadcode im Gateway → Alle Anfragen betroffen
✅ Mit Signando REST
Kompromittierte Gateway-Abhängigkeit → Signando REST (anderer Stack) nicht betroffen → Validiert alle Antworten → Erkennt Anomalien
Die Mathematik von Defence in Depth
Wenn jede Sicherheitsschicht 99% der Angriffe stoppt (1% kommen durch):
- 1 Schicht: 1% der Angriffe erfolgreich (1 von 100)
- 2 Schichten: 0,01% der Angriffe erfolgreich (1 von 10.000)
- 3 Schichten: 0,0001% der Angriffe erfolgreich (1 von 1.000.000)
Signando REST hinzuzufügen addiert nicht nur Sicherheit — es multipliziert Ihren Schutz.
Defence in Depth implementieren
Fügen Sie Signando REST als Ihre zweite Sicherheitsschicht hinzu.