Isolation des données

Architecture multi-tenant avec des frontières imposées par la base de données.

Sécurité au niveau des lignes PostgreSQL

Chaque table à portée tenant dispose d'une politique de sécurité au niveau des lignes qui filtre les lignes par organisation. Imposé par Postgres lui-même, pas par le code applicatif, de sorte que même un bug dans nos contrôleurs ne peut pas divulguer des données entre tenants.

Contexte tenant par requête

Chaque requête définit une variable de session Postgres (SET LOCAL) avec l'identifiant de l'organisation authentifiée. Les politiques RLS référencent cette variable, garantissant que les requêtes ne retournent jamais les lignes d'un autre tenant.

Clés primaires UUID

Tous les enregistrements utilisent des identifiants UUIDv4 au lieu d'entiers séquentiels. Les identifiants de ressources ne peuvent être ni devinés ni énumérés.

Chiffrement

Données protégées en transit et au repos.

TLS partout

Tout le trafic est chiffré avec TLS. HTTPS est imposé en production avec des en-têtes HSTS, et les requêtes HTTP en clair sont automatiquement redirigées.

Attributs sensibles chiffrés

Les attributs démographiques (genre, ethnicité, département) utilisés pour l'analyse d'équité sont chiffrés au niveau applicatif avec AES-256-GCM avant d'être écrits dans la base de données.

Clés API hachées

Les clés API sont hachées en SHA-256 avant stockage. Nous ne stockons jamais le jeton brut. Il est affiché une seule fois à la création et ne peut plus être récupéré.

Hachage des mots de passe avec bcrypt

Les mots de passe des utilisateurs sont hachés avec bcrypt. Les mots de passe bruts ne sont jamais stockés ni journalisés.

Anonymat et confidentialité

La confiance des employés est le fondement de données culturelles honnêtes.

Seuil minimum de 5 réponses

Les groupes avec moins de 5 réponses sont automatiquement masqués de tous les tableaux de bord et rapports. Cela empêche les responsables d'identifier des répondants individuels dans les petites équipes.

Reporting agrégé uniquement

Tous les scores culturels, les indicateurs d'équité et les rapports de conformité sont calculés à partir de données agrégées. Les réponses individuelles aux sondages ne sont jamais affichées aux administrateurs ou aux responsables.

Aucune identification individuelle

Les réponses aux sondages sont stockées sans identifiants utilisateur. Il n'existe aucun mécanisme technique pour relier une réponse à un employé spécifique, par conception, pas seulement par politique.

Sécurité applicative

En-têtes, politiques et protections du navigateur.

Content Security Policy

Une CSP stricte restreint les sources de scripts, styles, images et frames. frame-ancestors est défini sur 'none' pour prévenir le clickjacking.

Liste blanche stricte des paramètres

Toutes les actions des contrôleurs utilisent des listes de permission explicites des paramètres. L'autorisation globale est interdite par la politique du projet et vérifiée lors de la revue de code.

Filtrage des paramètres sensibles

Les mots de passe, jetons, clés API et autres valeurs sensibles sont automatiquement expurgés des journaux applicatifs.

Tests de sécurité continus

Vérifications automatisées à chaque commit.

Brakeman

Analyseur statique qui vérifie les injections SQL, XSS, l'assignation de masse et d'autres vulnérabilités spécifiques à Rails à chaque exécution CI.

bundler-audit

Vérifie toutes les dépendances de gems Ruby dans la base de données d'avis de sécurité Ruby pour les CVE connues avant chaque déploiement.

importmap:audit

Analyse les dépendances JavaScript vendorisées à la recherche de vulnérabilités connues.

Des questions sur nos pratiques de sécurité ?

Nous sommes à votre disposition pour discuter de notre architecture, répondre aux questionnaires de sécurité ou vous présenter notre approche de la protection des données des employés.

Nous contacter