Deine Finanzdaten gehören dir.
Und nur dir.
Northflow behandelt deine Finanzdaten mit derselben Sorgfalt, die du erwartest, wenn du sie auf Papier in einen Tresor legst. Hier liest du transparent, wie wir das technisch umsetzen.
Strikte Datenisolation
Jeder Datensatz ist fest mit einer User-ID verknüpft. Auf Datenbankebene erzwingen Row-Level-Security-Policies, dass du ausschliesslich deine eigenen Transaktionen, Deals und Auswertungen siehst — niemals Daten anderer Nutzer.
Verschlüsselung
Alle Verbindungen laufen über TLS 1.2+. Daten werden in der Datenbank verschlüsselt gespeichert (AES-256 at Rest). Passwörter werden ausschliesslich als sicherer Hash abgelegt — wir sehen sie nie im Klartext.
Sichere Authentifizierung
Login per E-Mail/Passwort oder Google OAuth. Sessions sind kurzlebig, werden über sichere Tokens verwaltet und können jederzeit widerrufen werden.
Hosting in Zürich
Daten und Backups liegen in der Schweiz (Region eu-central-2, Zürich) — DSGVO- und revDSG-konform. Tägliche automatische Backups, Point-in-Time-Recovery für 7 Tage.
Server-seitige Validierung
Sicherheitsrelevante Operationen (Import, Schreibzugriffe, Admin-Aktionen) werden ausschliesslich server-seitig autorisiert und validiert. Client-Manipulationen sind wirkungslos.
Audit-Logs (Art. 32 DSGVO)
Jede schreibende Änderung an Transaktionen, Konten, Deals und Forecasts wird in einem unveränderlichen Audit-Log mit Zeitstempel und User-ID festgehalten. Einsehbar direkt im Workspace.
Pseudonymisierter KI-CFO
Bevor dein KI-CFO einen externen Sprachmodell-Provider erreicht, werden Klarnamen (Kunden, Lieferanten, Mitarbeitende) durch Platzhalter ersetzt. Rohdaten verlassen die EU nicht.
Datenminimierung
Wir speichern nur, was Northflow zum Funktionieren braucht: deine erfassten Finanzdaten und das nötige Konto-Minimum. Keine Bank-Logins, keine Tracker-IDs Dritter, kein Re-Targeting.
Wie wir verhindern, dass Nutzer Daten anderer Nutzer sehen.
1. user_id auf jedem Datensatz
Jede Tabelle (Transaktionen, Deals, Kategorien …) enthält eine user_id-Spalte mit Foreign-Key auf den authentifizierten Nutzer. Beim Erstellen wird sie server-seitig aus der gültigen Session abgeleitet — nicht vom Client geschickt.
2. Row-Level Security (RLS) in der Datenbank
Jede Tabelle hat aktivierte RLS-Policies. Eine Abfrage wie SELECT * FROM transactions liefert physisch nur Zeilen zurück, bei denen user_id = auth.uid() gilt. Auch ein theoretisch manipulierter Client kann keine fremden Daten lesen — die Datenbank gibt sie schlicht nicht heraus.
3. Trennung Anon- vs. Service-Key
Im Browser wird ausschliesslich der öffentliche Anon-Key verwendet, der RLS unterliegt. Der privilegierte Service-Key, der RLS umgehen könnte, existiert nur server-seitig in geschützten Endpoints (Imports, Admin) und verlässt nie den Server.
4. Auth-geschützte Server-Funktionen
Sensible Operationen (CSV-Import, Admin-Aktionen) laufen über server-seitige Funktionen, die das Auth-Token validieren und den Nutzer-Kontext sicher setzen. Ohne gültiges Token: 401.
5. Separates Rollen-System
Admin-Rechte werden in einer eigenen Tabelle (user_roles) gehalten und über eine SECURITY-DEFINER-Funktion geprüft. Rollen können nicht durch den Nutzer selbst gesetzt werden — keine Privilege-Escalation über Profil-Felder.
6. Audits & Monitoring
Automatisierter Sicherheits-Linter prüft regelmässig RLS-Policies, Berechtigungen und Auth-Konfiguration. Verdächtige Login-Versuche werden serverseitig rate-limited.
Responsible Disclosure
Wenn du eine potentielle Sicherheitslücke entdeckst, melde sie bitte vertraulich an info@northflow.finance. Wir bestätigen den Eingang innerhalb von 72 Stunden und halten dich über den Fortschritt auf dem Laufenden. Bitte gib uns angemessene Zeit zur Behebung, bevor du Details veröffentlichst.