Signando REST
Das Application Layer Gateway, das API-Sicherheit auf die Spitze treibt. Jede Anfrage und Antwort wird gegen Ihre OpenAPI-Spezifikation validiert.
Was ist Signando REST?
Signando REST ist ein Application Layer Gateway (ALG), das zwischen Ihren Clients und Ihren Backend-APIs sitzt. Es validiert jede einzelne HTTP-Anfrage gegen Ihre OpenAPI 3.0 Spezifikation, bevor sie an Ihr Backend weitergeleitet wird.
Aber wir hören dort nicht auf. Signando REST validiert auch jede Antwort von Ihrem Backend, bevor sie an den Client gesendet wird. Diese bidirektionale Validierung stellt sicher:
- Schädliche Anfragen erreichen nie Ihr Backend
- Sensible Daten können nicht durch unerwartete Response-Felder durchsickern
- Ihr API-Vertrag wird in beide Richtungen durchgesetzt
Technische Daten
| Sprache | 100% Rust |
| Latenz | < 250ms |
| Sicherheitstests | 181 Tests |
| Architektur | 4 isolierte NATS-Instanzen |
| OpenAPI | 3.0 / 3.1 Unterstützung |
| Deployment | Docker / Kubernetes |
Der paranoide Ansatz
Allowlist statt Blocklist
Im Gegensatz zu traditionellen WAFs, die versuchen bekannte schädliche Muster zu blockieren, erlaubt Signando REST nur, was explizit in Ihrer OpenAPI-Spezifikation definiert ist. Alles andere wird abgelehnt.
4-Stufen-Isolation
Vier separate NATS JetStream-Instanzen stellen sicher, dass Daten aus verschiedenen Verarbeitungsstufen nicht zwischen Komponenten durchsickern können, selbst wenn eine kompromittiert wird.
Bidirektionale Validierung
Sowohl Anfragen als auch Antworten werden validiert. Dies verhindert Datenexfiltration und stellt sicher, dass Ihr Backend niemals unerwartete Daten an Clients sendet.
Die 4 Prozesse im Detail
Jeder Prozess ist isoliert und kommuniziert ausschließlich über definierte Kanäle.
1. Frontend
Der einzige Prozess mit direktem Client-Kontakt. Nimmt HTTP-Requests entgegen und leitet sie zur Validierung weiter.
Eingabe (Input)
- HTTP-Requests von Clients auf Port 8080
- Unterstützt: GET, POST, PUT, DELETE, PATCH
- TLS-Terminierung (optional)
Ausgabe (Output)
- Schreibt Request-Daten nach NATS 1 (Dirty Queue)
- Schreibt Einträge ins AuditLog
- Liest validierte Responses aus NATS 4 (Clean Queue)
- Sendet HTTP-Response an Client
🔒 Sicherheitsregeln
- Keine direkte Verbindung zum Backend-Server
- Kann nur auf NATS 1 (schreiben) und NATS 4 (lesen) zugreifen
- Request-Body wird nicht interpretiert, nur weitergeleitet
- Timeout-Handling für nicht beantwortete Requests
- Rate-Limiting auf IP-Basis möglich
- Stateless: Kann horizontal skaliert werden (mehrere Instanzen, z.B. hinter einem Loadbalancer)
2. Request Validator
Validiert eingehende Requests gegen die OpenAPI-Spezifikation. Nur gültige Requests werden weitergeleitet.
Eingabe (Input)
- Liest Request-Daten aus NATS 1 (Dirty Queue)
- Lädt OpenAPI-Spezifikation (YAML/JSON)
Ausgabe (Output)
- Schreibt validierte Requests nach NATS 2 (Clean Queue)
- Schreibt Validierungsergebnis ins AuditLog
🔒 Sicherheitsregeln
- Kein HTTP-Server: Öffnet keine Ports, pollt nur die NATS-Queue
- Keine Netzwerkverbindung außer NATS 1 (lesen) und NATS 2 (schreiben)
- Strenge OpenAPI-Validierung: Pfad, Methode, Header, Query-Parameter, Body
- Allowlist-Prinzip: Nur explizit definierte Endpunkte erlaubt
- Typ-Validierung: String, Integer, Boolean, Array, Object
- Pattern-Validierung: Regex für Strings (z.B. E-Mail, UUID)
- Enum-Validierung: Nur erlaubte Werte
- Injection-Erkennung: SQL, XSS, Command Injection Patterns
- Stateless: Kann horizontal skaliert werden (mehrere Instanzen)
3. Backend
Leitet validierte Requests an den eigentlichen Backend-Server weiter und empfängt dessen Antworten.
Eingabe (Input)
- Liest validierte Requests aus NATS 2 (Clean Queue)
Ausgabe (Output)
- Ruft Backend-Server auf Port 8080 (konfigurierbar)
- Schreibt Backend-Response nach NATS 3 (Dirty Queue)
- Schreibt Aufruf-Details ins AuditLog
🔒 Sicherheitsregeln
- Keine direkte Verbindung zum Client (nur über NATS)
- Kann nur auf NATS 2 (lesen) und NATS 3 (schreiben) zugreifen
- Backend-Verbindung nur zu konfiguriertem Host/Port
- Timeout-Handling für langsame Backend-Responses
- Retry-Logik bei temporären Fehlern (konfigurierbar)
- Circuit-Breaker bei Backend-Ausfällen
- Stateless: Kann horizontal skaliert werden (mehrere Instanzen)
4. Response Validator
Validiert Backend-Antworten gegen die OpenAPI-Spezifikation. Verhindert Datenexfiltration und unerwartete Response-Strukturen.
Eingabe (Input)
- Liest Backend-Responses aus NATS 3 (Dirty Queue)
- Lädt OpenAPI-Spezifikation (YAML/JSON)
Ausgabe (Output)
- Schreibt validierte Responses nach NATS 4 (Clean Queue)
- Schreibt Validierungsergebnis ins AuditLog
- Bei Fehler: Generiert sichere Fehler-Response
🔒 Sicherheitsregeln
- Kein HTTP-Server: Öffnet keine Ports, pollt nur die NATS-Queue
- Keine Netzwerkverbindung außer NATS 3 (lesen) und NATS 4 (schreiben)
- Response-Schema-Validierung: Nur definierte Felder werden durchgelassen
- Verhindert Datenexfiltration durch unerwartete Response-Felder
- Content-Type-Validierung: Nur erlaubte Formate (z.B. application/json)
- Status-Code-Validierung: Nur in OpenAPI definierte Codes
- Header-Filterung: Nur erlaubte Response-Header
- Stateless: Kann horizontal skaliert werden (mehrere Instanzen)
Datenfluss-Übersicht
┌──────────────────────────────────────────────────────────────────────────────┐ │ │ │ Client ──▶ Frontend ──▶ NATS 1 ──▶ Request ──▶ NATS 2 ──▶ Backend │ │ │ (8080) (Dirty) Validator (Clean) │ │ │ │ │ │ │ │ ▼ │ │ │ Backend-Server │ │ │ (8080) │ │ │ │ │ │ │ ┌───────────────────────────────────────────────────┘ │ │ │ │ │ │ │ ▼ │ │ │ NATS 3 ──▶ Response ──▶ NATS 4 │ │ │ (Dirty) Validator (Clean) │ │ │ │ │ │ │ ▼ │ │ ◀───────────────────────────── Frontend │ │ │ │ ════════════════════════════════════════════════════════════════════════ │ │ Jeder Prozess schreibt zusätzlich ins AuditLog │ └──────────────────────────────────────────────────────────────────────────────┘
Bereit, Ihre APIs zu schützen?
Kontaktieren Sie uns für eine Demo und persönliche Beratung.