Sécurité
Comment Neural Detective protège vos données à chaque couche — du périmètre réseau à la ligne de base de données.
Isolation des données
Architecture multi-tenant avec des frontières imposées par la base de données.
Row-Level Security PostgreSQL
Chaque table à portée multi-tenant dispose d'une politique de sécurité au niveau des lignes qui filtre les enregistrements par organisation. Appliquée par Postgres lui-même — et non par le code applicatif — de sorte que même un bug dans nos contrôleurs ne peut pas entraîner de fuite de données entre tenants.
Contexte de 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 renvoient 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 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 valeurs d'attributs protégés (genre, tranche d'âge, etc.) utilisées pour la surveillance des biais sont chiffrées au niveau applicatif via les attributs chiffrés de Rails avant d'être écrites en base de données.
Clés API hachées
Les clés API sont hachées en SHA-256 avant stockage. Nous ne conservons 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 en utilisant un facteur de coût de 12 en production. Les mots de passe en clair ne sont jamais stockés ni journalisés.
Sécurité de l'API
Authentification, signature et défense en profondeur.
Authentification par jeton Bearer
Chaque requête API nécessite une clé API valide dans l'en-tête Authorization. Les clés sont préfixées (nd_live_) pour une identification facile et peuvent être révoquées instantanément depuis le tableau de bord.
Webhooks signés par HMAC
Les charges utiles des webhooks sortants sont signées avec HMAC-SHA256 à l'aide d'un secret de signature par endpoint. La signature est transmise dans l'en-tête X-Signature-256 afin que vous puissiez vérifier l'authenticité.
Liste blanche de paramètres stricts
Toutes les actions des contrôleurs utilisent des listes de paramètres autorisés explicites. L'autorisation globale est interdite par la politique du projet et vérifiée lors de la revue de code.
Sécurité applicative
En-têtes, politiques et protections du navigateur.
Content Security Policy
Une CSP stricte restreint les sources de scripts, de styles, d'images et de cadres. frame-ancestors est défini à 'none' pour empêcher le clickjacking.
Filtrage des paramètres sensibles
Les mots de passe, jetons, clés API, numéros de sécurité sociale et autres valeurs sensibles sont automatiquement expurgés des journaux applicatifs.
Authentification admin séparée
Le panneau d'administration interne utilise un domaine d'authentification isolé avec ses propres identifiants, séparé des comptes clients.
Tests de sécurité continus
Vérifications automatisées à chaque commit.
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.
Vérifie toutes les dépendances Ruby dans la base de données Ruby Advisory Database pour les CVE connues avant chaque déploiement.
Analyse les dépendances JavaScript embarquées à la recherche de vulnérabilités connues.
Des questions sur nos pratiques de sécurité ?
Nous serons ravis de discuter de notre architecture, de répondre à vos questionnaires de sécurité ou de planifier un appel avec notre équipe.