Zum Inhalt springen

Sicherheit

So schützt ClimaHQ die Daten Ihrer Organisation auf jeder Ebene: vom Netzwerkrand bis zur Datenbankzeile.

Datenisolierung

Mandantenfähige Architektur mit datenbankgesteuerten Grenzen.

PostgreSQL Row-Level Security

Jede mandantenspezifische Tabelle verfügt über eine Row-Level-Security-Richtlinie, die Zeilen nach Organisation filtert. Dies 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-Bezeichner anstelle sequenzieller 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 Klartext-HTTP-Anfragen werden automatisch umgeleitet.

Verschlüsselte sensible Attribute

Demografische Attribute (Geschlecht, Ethnizität, Abteilung), die für die Gleichstellungsanalyse verwendet werden, werden auf Anwendungsebene mit AES-256-GCM 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 den Roh-Token: er wird einmalig bei der Erstellung angezeigt und kann nicht erneut abgerufen werden.

bcrypt-Passwort-Hashing

Benutzerpasswörter werden mit bcrypt gehasht. Rohpasswörter werden niemals gespeichert oder protokolliert.

Anonymität & Datenschutz

Das Vertrauen der Mitarbeitenden ist die Grundlage ehrlicher Kulturdaten.

Mindestschwelle von 5 Antworten

Gruppen mit weniger als 5 Antworten werden automatisch in allen Dashboards und Berichten ausgeblendet. Dies verhindert, dass Führungskräfte einzelne Befragte in kleinen Teams identifizieren können.

Ausschließlich aggregierte Berichterstattung

Alle Kulturwerte, Gleichstellungskennzahlen und Compliance-Berichte werden aus aggregierten Daten berechnet. Einzelne Umfrageantworten werden Administratoren oder Führungskräften niemals angezeigt.

Keine individuelle Identifizierung

Umfrageantworten werden ohne Nutzeridentifikatoren gespeichert. Es gibt keinen technischen Mechanismus, um eine Antwort auf eine bestimmte Person zurückzuführen: durch Design, nicht nur durch Richtlinien.

Anwendungssicherheit

Header, Richtlinien und Browser-Schutzmechanismen.

Content Security Policy

Eine strenge CSP beschränkt Skript-, Style-, Bild- und Frame-Quellen. frame-ancestors ist auf 'none' gesetzt, um Clickjacking zu verhindern.

Strenge Parameter-Whitelisting

Alle Controller-Aktionen verwenden explizite Parameter-Permit-Listen. Pauschales Permit ist durch Projektrichtlinien verboten und wird im Code-Review durchgesetzt.

Filterung sensibler Parameter

Passwörter, Token, API-Schlüssel und andere sensible Werte werden automatisch aus Anwendungsprotokollen entfernt.

Kontinuierliche Sicherheitstests

Automatisierte Prüfungen bei jedem Commit.

Brakeman

Statischer Analyse-Scanner, der bei jedem CI-Lauf auf SQL-Injection, XSS, Mass Assignment und andere Rails-spezifische Schwachstellen prüft.

bundler-audit

Prüft alle Ruby-Gem-Abhängigkeiten gegen die Ruby Advisory Database auf bekannte CVEs vor jedem Deploy.

importmap:audit

Scannt gevendorte JavaScript-Abhängigkeiten auf bekannte Schwachstellen.

Fragen zu unseren Sicherheitspraktiken?

Wir besprechen gerne unsere Architektur, beantworten Sicherheitsfragebögen oder erläutern Ihnen unseren Ansatz zum Schutz von Mitarbeiterdaten.