Isolation des tenants
Chaque table tenant porte l’identifiant d’organisation, et la sécurité au niveau des lignes (row-level security) de PostgreSQL est appliquée au rôle applicatif. Le rôle worker ne contourne la RLS que pour le magasin d’événements partitionné et la piste d’audit, jamais pour la configuration des tenants.
Secrets
Les identifiants d’accès des fournisseurs sont protégés par chiffrement d’enveloppe (clés de données AES-256-GCM enveloppées par AWS KMS ou par une clé maître locale). L’assistant, le navigateur et les journaux ne voient jamais qu’une référence et les quatre derniers caractères.
Configuration signée
Les bundles de configuration sont immuables, versionnés et signés Ed25519. Le SDK navigateur vérifie la signature avec WebCrypto avant d’appliquer une configuration et rejette tout le reste (fail closed).
Data plane
Le collecteur valide les origines, applique la limitation de débit et les requêtes serveur signées HMAC, et remet les événements à une file d’attente durable avant de répondre. Les workers traitent avec nouvelles tentatives, circuit breakers et dead-letter queue. Les kill switches arrêtent la collecte et la livraison par site ou par organisation en quelques secondes.
- Pas de fingerprinting, pas d’identité inter-sites
- Le scanner PII bloque les données personnelles dans les propriétés d’événement avant stockage
- Les adresses IP sont tronquées à l’ingestion
- Journal d’audit et registre d’utilisation en ajout seul (triggers de base de données)
Accès et exploitation
Contrôle d’accès basé sur les rôles avec six rôles d’organisation, MFA et passkeys, accès d’urgence (break-glass) avec motif obligatoire et entrée d’audit, tâches de conservation par type de données, et un contact de signalement des vulnérabilités publié sur cette page.
Les contrôles en un coup d’œil
Chaque contrôle est décrit dans les sections ci-dessus ; ce tableau en est la version courte.
| Contrôle | Périmètre | Mécanisme |
|---|---|---|
| Isolation des tenants | Chaque table tenant, rôle applicatif | Identifiant d’organisation sur chaque ligne, sécurité au niveau des lignes PostgreSQL appliquée |
| Stockage des secrets | Identifiants d’accès des fournisseurs | Chiffrement par enveloppe (clés de données AES-256-GCM enveloppées par AWS KMS ou une clé maître locale) ; seuls une référence et les quatre derniers caractères sont visibles |
| Configuration signée | SDK navigateur | Bundles immuables, versionnés et signés Ed25519, vérifiés avec WebCrypto ; fail closed |
| Protection de l’ingestion | Collecteur | Validation des origines, limitation de débit, requêtes serveur signées HMAC, file d’attente durable avant la réponse |
| Livraison | Workers | Nouvelles tentatives, circuit breakers et dead-letter queue |
| Kill switches | Par site ou organisation | Arrêt de la collecte et de la livraison en quelques secondes |
| Minimisation des données | Propriétés d’événement, adresses IP | Le scanner PII bloque les données personnelles avant stockage ; les IP sont tronquées à l’ingestion ; pas de fingerprinting |
| Audit | Journal d’audit, registre d’utilisation | Ajout seul (append-only) via des triggers de base de données |
| Accès | Membres de l’organisation | Six rôles, MFA et passkeys, accès d’urgence (break-glass) avec motif obligatoire et entrée d’audit |
Signaler une vulnérabilité
Merci de signaler les vulnérabilités de manière responsable à support@track.site. Nous accusons réception sous deux jours ouvrés et ne nommons jamais les personnes à l’origine d’un signalement sans leur consentement.