Signando Postgres
Das Application Layer Gateway, das PostgreSQL-Sicherheit auf die Spitze treibt. Jede SQL-Abfrage wird gegen Ihre definierte Query-Whitelist validiert.
Was ist Signando Postgres?
Signando Postgres ist ein Application Layer Gateway (ALG), das zwischen Ihren Anwendungen und Ihrer PostgreSQL-Datenbank sitzt. Es validiert jede einzelne SQL-Abfrage gegen eine vordefinierte Whitelist erlaubter Abfragen, bevor sie an Ihre Datenbank weitergeleitet wird.
Aber wir hören dort nicht auf. Signando Postgres validiert auch jede Antwort von Ihrer Datenbank, bevor sie an die Anwendung zurückgesendet wird. Diese bidirektionale Validierung stellt sicher:
- Nur vorab genehmigte SQL-Abfragen erreichen Ihre Datenbank
- SQL-Injection-Angriffe werden auf Protokollebene blockiert
- Sensible Daten können nicht durch unautorisierte Abfragen durchsickern
- Ihre Datenbankzugriffsrichtlinie wird bidirektional durchgesetzt
Technische Daten
| Sprache | 100% Rust |
| Latenz | < 5ms pro Abfrage |
| Protokoll | PostgreSQL Wire Protocol |
| Architektur | 4 isolierte NATS-Instanzen |
| PostgreSQL | 12, 13, 14, 15, 16, 17 |
| Deployment | Docker / Kubernetes |
Der paranoide Ansatz
Query-Whitelist
Im Gegensatz zu traditionellen Datenbank-Firewalls, die versuchen bekannte SQL-Injection-Muster zu blockieren, erlaubt Signando Postgres nur Abfragen, die explizit auf der Whitelist stehen. 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 Abfragen als auch Antworten werden validiert. Dies verhindert Datenexfiltration und stellt sicher, dass Ihre Datenbank niemals unautorisierte Daten an Anwendungen 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 PostgreSQL Wire Protocol Verbindungen entgegen und leitet Abfragen zur Validierung weiter.
Eingabe (Input)
- PostgreSQL-Verbindungen auf Port 5432
- Unterstützt: Simple Query, Extended Query Protocol
- TLS/SSL-Verbindungen unterstützt
Ausgabe (Output)
- Schreibt Abfragedaten nach NATS 1 (Dirty Queue)
- Schreibt Einträge ins AuditLog
- Liest validierte Antworten aus NATS 4 (Clean Queue)
- Sendet Abfrageergebnisse an Client
🔒 Sicherheitsregeln
- Keine direkte Verbindung zur PostgreSQL-Datenbank
- Kann nur auf NATS 1 (schreiben) und NATS 4 (lesen) zugreifen
- Abfragetext wird nicht interpretiert, nur weitergeleitet
- Verbindungs-Timeout-Handling
- Stateless: Kann horizontal skaliert werden
2. Query Validator
Validiert eingehende Abfragen gegen die Query-Whitelist. Nur erlaubte Abfragen werden weitergeleitet.
Eingabe (Input)
- Liest Abfragedaten aus NATS 1 (Dirty Queue)
- Lädt Query-Whitelist-Konfiguration
Ausgabe (Output)
- Schreibt validierte Abfragen nach NATS 2 (Clean Queue)
- Schreibt Validierungsergebnis ins AuditLog
🔒 Sicherheitsregeln
- Kein Netzwerk-Listener: Öffnet keine Ports, pollt nur NATS-Queue
- Keine Netzwerkverbindung außer NATS 1 (lesen) und NATS 2 (schreiben)
- Strenge Query-Whitelist-Validierung
- SQL-Parsing und Normalisierung
- Parameter-Binding-Validierung
- Prepared-Statement-Unterstützung
- SQL-Injection-Mustererkennung als zusätzliche Schicht
- Stateless: Kann horizontal skaliert werden
3. Backend
Leitet validierte Abfragen an die eigentliche PostgreSQL-Datenbank weiter und empfängt die Ergebnisse.
Eingabe (Input)
- Liest validierte Abfragen aus NATS 2 (Clean Queue)
Ausgabe (Output)
- Führt Abfrage auf PostgreSQL auf Port 5432 (konfigurierbar) aus
- Schreibt Datenbankantwort nach NATS 3 (Dirty Queue)
- Schreibt Ausführungsdetails ins AuditLog
🔒 Sicherheitsregeln
- Keine direkte Verbindung zum Client (nur über NATS)
- Kann nur auf NATS 2 (lesen) und NATS 3 (schreiben) zugreifen
- Datenbankverbindung nur zu konfiguriertem Host/Port
- Abfrage-Timeout-Handling
- Connection-Pooling zur Datenbank
- Retry-Logik bei transienten Fehlern
- Stateless: Kann horizontal skaliert werden
4. Response Validator
Validiert Datenbankantworten gegen das erwartete Schema. Verhindert Datenexfiltration und unerwartete Ergebnisstrukturen.
Eingabe (Input)
- Liest Datenbankantworten aus NATS 3 (Dirty Queue)
- Lädt Response-Schema-Konfiguration
Ausgabe (Output)
- Schreibt validierte Antworten nach NATS 4 (Clean Queue)
- Schreibt Validierungsergebnis ins AuditLog
- Bei Fehler: Generiert sichere Fehlerantwort
🔒 Sicherheitsregeln
- Kein Netzwerk-Listener: Öffnet keine Ports, pollt nur NATS-Queue
- Keine Netzwerkverbindung außer NATS 3 (lesen) und NATS 4 (schreiben)
- Spalten-/Feldvalidierung: Nur erwartete Spalten werden zurückgegeben
- Zeilenlimit-Durchsetzung
- Datentyp-Validierung
- Maskierung sensibler Daten (konfigurierbar)
- Stateless: Kann horizontal skaliert werden
Datenfluss-Übersicht
┌──────────────────────────────────────────────────────────────────────────────┐ │ │ │ App ──▶ Frontend ──▶ NATS 1 ──▶ Query ──▶ NATS 2 ──▶ Backend │ │ │ (5432) (Dirty) Validator (Clean) │ │ │ │ │ │ │ │ ▼ │ │ │ PostgreSQL DB │ │ │ (5432) │ │ │ │ │ │ │ ┌─────────────────────────────────────────────────┘ │ │ │ │ │ │ │ ▼ │ │ │ NATS 3 ──▶ Response ──▶ NATS 4 │ │ │ (Dirty) Validator (Clean) │ │ │ │ │ │ │ ▼ │ │ ◀───────────────────────────── Frontend │ │ │ │ ════════════════════════════════════════════════════════════════════════ │ │ Jeder Prozess schreibt auch ins AuditLog │ └──────────────────────────────────────────────────────────────────────────────┘
Bereit, Ihre Datenbank zu schützen?
Kontaktieren Sie uns für eine Demo und persönliche Beratung.