Sicherheit & Datenschutz

Wer was sieht, entscheidet der Server.

In einem System, in dem mehrere Firmen nebeneinander arbeiten, ist die Sichtbarkeit keine Anzeigefrage. Sie wird in jeder einzelnen Abfrage durchgesetzt — nicht in der Oberfläche.

Rollen & Sichtbarkeit

Zwei Dimensionen, eine davon stärker

Die Rolle steuert, was jemand tun darf — sechs Stufen vom Superadmin bis zum Tippgeber. Die Partnerfirma steuert, was jemand sehen darf. Und sie ist die stärkere von beiden.

WerSieht
Creditfair ab Teamleiter
(keine Partnerfirma)
alles, firmenübergreifend
Creditfair darunternur die eigenen Datensätze
Partner-Inhaberden gesamten Bestand seiner Firma
Partner-Mitarbeiternur die eigenen Datensätze
Wer zu einer Partnerfirma gehört, sieht niemals darüber hinaus — auch nicht mit hoher Rolle. Sonst genügte eine versehentlich vergebene Teamleiter-Rolle, und ein Partner sähe den Bestand aller anderen. Zwischen zwei Partnerfirmen besteht keinerlei Sichtverbindung.
Durchgesetzt wird das serverseitig, in jeder Abfrage. Eine einzige Stelle im Code entscheidet darüber — nicht jede Seite für sich. Was nicht sichtbar sein darf, wird gar nicht erst geladen; es wird nicht nur ausgeblendet.
Zwei bewusste Ausnahmen, beide am Eingang geschützt. Die Fallbörse zeigt absichtlich fremde Fälle — jeder davon wurde ausdrücklich abgegeben, und nur Creditfair-Benutzer kommen herein. Der Supporteingang zeigt absichtlich fremde Meldungen; wer zu einer Partnerfirma gehört, wird vor der ersten Abfrage abgewiesen — auch der Inhaber, der sonst die Fragen fremder Firmen mitläse.
Zugangsdaten

Verschlüsselt, nicht im Klartext auf der Platte.

Die Zugangsdaten aller Schnittstellen — SMTP, Objektspeicher, Google, Outlook, Calendly, Europace, Sprengnetter — liegen AES-256-GCM-verschlüsselt in der Datenbank. Nicht in einer Konfigurationsdatei.

Der Schlüssel dafür wird aus dem Sitzungsgeheimnis der Installation abgeleitet. Steht im Produktivbetrieb noch der Entwicklungswert, verweigert das Portal das Ver- und Entschlüsseln und weist darauf hin — statt still mit einem bekannten Schlüssel zu arbeiten.

Weitere Maßnahmen

  • Passwörter mit bcrypt gehasht, nie im Klartext gespeichert
  • Sitzungen über HttpOnly-Cookies — kein Zugriff aus dem Skript der Seite
  • Datenbank lauscht nur lokal, nicht im Netz
  • Firewall: offen sind nur SSH und die beiden Web-Ports
  • Die Anwendung läuft nicht als Systemverwalter
  • TLS über Let's Encrypt mit automatischer Erneuerung
Betrieb

Wo das System läuft

BausteinEinrichtung
StandortServer in Deutschland, erreichbar unter app.faircrm.de
BetriebssystemUbuntu LTS, Anwendung unter einem eigenen Systembenutzer
ProzessDienst mit Autostart und Neustart bei Absturz
TransportTLS über Let's Encrypt, automatische Erneuerung
DatenbankPostgreSQL, nur lokal erreichbar
SicherungTäglicher Datenbank-Auszug, 14 Tage vorgehalten
AktualisierungMigrationen laufen bestandserhaltend — Daten bleiben erhalten
DSGVO

Was wir bewusst nicht tun

Keine automatisierte Entscheidung

Der FAIRcheck bereitet vor, er entscheidet nicht. Jeder Punkt nennt den nächsten Schritt statt eines Urteils, und der Check filtert keine Fälle aus. Eine automatisierte Entscheidung über Kreditanträge wäre nach Art. 22 DSGVO nur unter engen Voraussetzungen zulässig.

Keine Dokumentinhalte an die KI

An das Sprachmodell gehen nur Arbeitsdaten — keine Dokumentinhalte, keine Zugangsdaten. Und die Sichtbarkeitsregeln gelten auch hier: FAIRdinand liest nur, was der fragende Benutzer ohnehin sehen darf.

Kein Löschen von Menschen

Ausgeschiedene Mitarbeiter werden deaktiviert, nie gelöscht — an einem Benutzer hängen Fälle, Provisionen und die Historie. Für den Widerruf einer Einwilligung gibt es dagegen einen eigenen Ampelstatus (150).

Die Statushistorie ist lückenlos. Jeder Ampelwechsel wird mit Zeitpunkt, Benutzer und Kommentar festgehalten. Das ist als Nachweis gedacht — und als Schutz für den Bearbeiter, der später belegen können muss, wann er was getan hat.

Fragen zur Sicherheit?

Wir beantworten sie konkret — auch die technischen.