Sicherheit bei BankConnector

Passwörter werden mit scrypt gehasht, in konstanter Zeit verglichen und gegen eine Liste gängiger und kompromittierter Passwörter geprüft. Die Zwei-Faktor-Authentifizierung nutzt TOTP; ein verwendeter Code lässt sich innerhalb seines Zeitfensters nicht wiederverwenden, und die zehn Ersatzcodes sind nur einmal gültig und werden als Hash gespeichert. API-Schlüssel haben 256 Bit Entropie und werden nur als Hash gespeichert. Die Begrenzung von Anmeldeversuchen gilt je Identität und je Absenderadresse, und die Zähler werden über alle Instanzen geteilt.

Sitzungen sind opake Token auf dem Server, als Hash gespeichert und in einem Cookie mit HttpOnly, Secure und SameSite=Strict übertragen. Eine Sitzung endet nach 30 Minuten Inaktivität oder nach insgesamt 8 Stunden, je nachdem, was zuerst eintritt. Benutzer können ihre Sitzungen sehen und widerrufen, Administratoren können die Sitzungen eines Benutzers beenden, und das Ein- oder Ausschalten der Zwei-Faktor-Authentifizierung beendet alle anderen Sitzungen. Sensible Änderungen verlangen einen neuen Zwei-Faktor-Code.

Zu welchem Mandanten eine Anfrage gehört, ergibt sich aus dem authentifizierten Aufrufer und wird gegen die Anfrage geprüft. PostgreSQL Row-Level Security läuft im FORCE-Modus auf jeder Mandantentabelle und bindet so auch den Eigentümer der Tabelle. Innerhalb eines Unternehmens sind die Rollen eine Positivliste: Ein neuer Endpunkt, der Daten ändert, bleibt für Benutzer mit Leserechten gesperrt, bis er ausdrücklich freigegeben wird.

Die Feldverschlüsselung erfolgt mit AES-256-GCM in der Anwendung. Jeder verschlüsselte Wert ist an seine Tabelle, Spalte, seinen Mandanten und seine Zeile gebunden, sodass ein kopierter Wert anderswo nicht entschlüsselt werden kann. Verschlüsselte Werte tragen eine Schlüsselkennung, damit Daten auch über einen Schlüsselwechsel hinweg entschlüsselbar bleiben, und eine unbekannte Kennung ist ein Fehler. Der Schlüssel, der den Prüfpfad signiert, ist vom Schlüssel der Feldverschlüsselung getrennt.

Der Server startet nicht, wenn die Datenbankverbindung unverschlüsselt ist oder sich ihr Zertifikat nicht verifizieren lässt. Ausgehende Aufrufe an Banken und Webhook-Endpunkte erfolgen nur über HTTPS, prüfen das Zertifikat, verbinden sich mit der geprüften Adresse, folgen keinen Weiterleitungen und begrenzen die Größe der Antwort.

Webservice-Kanäle signieren und verschlüsseln mit RSA-SHA256, und eingehende Signaturen werden gegen ein fest hinterlegtes Zertifikat geprüft. EBICS nutzt XML-Signaturen mit Schutz gegen Signature Wrapping. SFTP verschlüsselt Dateien mit dem fest hinterlegten Schlüssel der Bank und prüft den Host-Key des Servers. Wo eine Bank die Hashwerte ihrer EBICS-Schlüssel veröffentlicht, prüfen wir sie und lehnen eine Abweichung ab; andernfalls erfassen wir den Schlüssel der Bank beim ersten Kontakt und halten ihn ab dann fest. Vor dem Ablauf fest hinterlegter Zertifikate gibt es eine Warnung.

Jede ausgehende Adresse wird gegen eine Positivliste geprüft und abgelehnt, wenn sie auf eine Loopback-, private, Link-Local- oder Cloud-Metadaten-Adresse zeigt, auch in verschleierten IP-Formaten. Die Verbindung wird an die geprüfte Adresse gebunden, um DNS-Rebinding zu verhindern. Webhook-Ziele werden bei der Zustellung erneut geprüft.

Uploads haben Grenzen für Typ und Größe, komprimierte Dateien werden auf Dekomprimierungsbomben geprüft, und Dateinamen auf Path Traversal. Jeder XML-Parser lehnt eine DOCTYPE-Deklaration ab, was Angriffe über externe Entitäten und Entitätsexpansion verhindert, bevor das Einlesen beginnt. Datenbankzugriffe sind parametrisiert, und Anfrageinhalte werden gegen strikte Schemas validiert.

Antworten tragen eine Content-Security-Policy, frame-ancestors none, nosniff, eine Referrer-Policy, Header zur Cross-Origin-Isolation und HSTS mit Preload. Cookies sind Secure, HttpOnly und SameSite=Strict, und CSRF-Token sind an die Sitzung gebunden. Doppelte Anfrageparameter werden abgelehnt.

Das Journal lässt nur Anfügen zu, erzwungen durch einen Datenbank-Trigger, der auch den Eigentümer der Tabelle bindet. Die Einträge sind je Unternehmen per HMAC verkettet, mit einem Schlüssel außerhalb der Datenbank, sodass Schreibzugriff auf die Datenbank nicht ausreicht, um die Kette neu zu schreiben.

Die Produktion startet nicht mit Entwicklungsschlüsseln, ohne Authentifizierung, ohne geprüftes TLS zur Datenbank oder mit einer Datenbankrolle, die Row-Level Security umgehen könnte. Produktive Verbindungen können nicht auf Testendpunkte von Banken zeigen. Debug-Ausgaben sind abgeschaltet, und Überwachungsendpunkte verlangen ein Token. Geheimnisse und Kontonummern werden anhand von Feldnamen und Mustern aus Protokollen entfernt.

Eine Software-Stückliste im Format CycloneDX (SBOM) entsteht bei unseren geplanten CI-Läufen und bei Release-Läufen. Abhängigkeiten werden bei jedem Pull Request und jedem Push gegen die eingecheckte Lockfile geprüft, und ein Befund mit hohem Schweregrad blockiert den Build. CI-Actions von Dritten sind auf Commit-Hashes festgelegt. Jeder Push wird nach eingecheckten Geheimnissen durchsucht. Releases sind unveränderliche Tags, und ausgerollt wird das Tag.