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.
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 Deploy.
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.