Sicherheit
Wie Neural Detective Ihre Daten auf jeder Ebene schützt — vom Netzwerk-Edge bis zur Datenbankzeile.
Datenisolierung
Mandantenfähige Architektur mit datenbankgestützten Grenzen.
PostgreSQL Row-Level Security
Jede mandantenbezogene Tabelle verfügt über eine Row-Level-Security-Richtlinie, die Zeilen nach Organisation filtert. Wird von Postgres selbst durchgesetzt — nicht vom Anwendungscode — sodass selbst ein Fehler in unseren Controllern keine Daten zwischen Mandanten preisgeben kann.
Mandantenkontext pro Anfrage
Jede Anfrage setzt eine Postgres-Sitzungsvariable (SET LOCAL) mit der authentifizierten Organisations-ID. RLS-Richtlinien referenzieren diese Variable und stellen sicher, dass Abfragen niemals Zeilen eines anderen Mandanten zurückgeben.
UUID-Primärschlüssel
Alle Datensätze verwenden UUIDv4-Identifikatoren anstelle von sequenziellen Ganzzahlen. Ressourcen-IDs können nicht erraten oder aufgezählt werden.
Verschlüsselung
Daten geschützt bei der Übertragung und im Ruhezustand.
TLS überall
Der gesamte Datenverkehr wird mit TLS verschlüsselt. HTTPS wird in der Produktion mit HSTS-Headern erzwungen, und unverschlüsselte HTTP-Anfragen werden automatisch umgeleitet.
Verschlüsselte sensible Attribute
Geschützte Attributwerte (Geschlecht, Altersgruppe usw.), die für die Bias-Überwachung verwendet werden, werden auf der Anwendungsebene mit Rails Encrypted Attributes verschlüsselt, bevor sie in die Datenbank geschrieben werden.
Gehashte API-Schlüssel
API-Schlüssel werden vor der Speicherung mit SHA-256 gehasht. Wir speichern niemals das Roh-Token — es wird einmalig bei der Erstellung angezeigt und kann nicht erneut abgerufen werden.
bcrypt-Passwort-Hashing
Benutzerpasswörter werden mit bcrypt und einem Kostenfaktor von 12 in der Produktion gehasht. Rohpasswörter werden niemals gespeichert oder protokolliert.
API-Sicherheit
Authentifizierung, Signierung und Defense in Depth.
Bearer-Token-Authentifizierung
Jede API-Anfrage erfordert einen gültigen API-Schlüssel im Authorization-Header. Schlüssel sind mit einem Präfix (nd_live_) versehen, um die Identifizierung zu erleichtern, und können sofort über das Dashboard widerrufen werden.
HMAC-signierte Webhooks
Ausgehende Webhook-Payloads werden mit HMAC-SHA256 unter Verwendung eines endpunktspezifischen Signiergeheimnisses signiert. Die Signatur wird im X-Signature-256-Header übermittelt, damit Sie die Authentizität überprüfen können.
Strikte Parameter-Whitelisting
Alle Controller-Aktionen verwenden explizite Parameter-Permit-Listen. Pauschales Permit ist durch Projektrichtlinien verboten und wird im Code-Review durchgesetzt.
Anwendungssicherheit
Header, Richtlinien und Browserschutz.
Content Security Policy
Eine strikte CSP beschränkt Script-, Style-, Image- und Frame-Quellen. frame-ancestors ist auf 'none' gesetzt, um Clickjacking zu verhindern.
Filterung sensibler Parameter
Passwörter, Tokens, API-Schlüssel, Sozialversicherungsnummern und andere sensible Werte werden automatisch aus den Anwendungsprotokollen entfernt.
Separate Admin-Authentifizierung
Das interne Admin-Panel verwendet einen isolierten Authentifizierungsbereich mit eigenen Anmeldedaten, getrennt von Kundenkonten.
Kontinuierliche Sicherheitstests
Automatisierte Prüfungen bei jedem Commit.
Statischer Analyse-Scanner, der bei jedem CI-Lauf auf SQL-Injection, XSS, Mass Assignment und andere Rails-spezifische Schwachstellen prüft.
Prüft alle Ruby-Gem-Abhängigkeiten gegen die Ruby Advisory Database auf bekannte CVEs vor jedem Deployment.
Scannt heruntergeladene JavaScript-Abhängigkeiten auf bekannte Sicherheitslücken.
Fragen zu unseren Sicherheitspraktiken?
Wir beantworten gerne Fragen zu unserer Architektur, füllen Sicherheitsfragebögen aus oder vereinbaren einen Gesprächstermin mit unserem Team.