Sécurité

Environnement de production

La production s’exécute dans l’UE (Frankfurt) sous un compte cloud dédié et entièrement isolé, distinct de tout autre produit. Le calcul, le réseau, le stockage, les secrets et la journalisation sont tous dédiés à Syncanix. La résidence dans l’UE est appliquée dans le code : un déploiement mal configuré refuse de s’exécuter s’il se résout vers une région située en dehors de l’UE.

Isolation des tenants, preuves à l’appui

Les données de chaque tenant sont séparées par quatre couches d’application indépendantes — chacune suffit à elle seule à arrêter une requête inter-tenants :

1. Frontière : toute requête authentifiée doit se résoudre à un tenant, sinon elle est rejetée en bordure.
2. Contexte de requête : l’identité du tenant est liée à la requête et propagée à chaque couche inférieure — jamais passée à la main.
3. Requêtes : chaque accès aux données est explicitement borné au tenant demandeur.
4. Base de données : des politiques de sécurité au niveau des lignes sur chaque table multi-tenant imposent la même frontière dans Postgres lui-même — même un contrôle hypothétiquement manqué plus haut ne peut pas la franchir.

C’est testé, pas affirmé : la sécurité au niveau des lignes est prouvée par une suite d’intégration exécutée contre une base Postgres réelle, et une matrice de sondes nocturne tente lectures, écritures, accès aux logs, accès aux secrets et accès à la recherche vectorielle entre tenants — chaque sonde doit passer avant chaque déploiement. Les évaluateurs sécurité peuvent demander le dossier de preuves complet à admin@syncanix.com.

Chiffrement

Toutes les données des clients sont chiffrées au repos avec AES-256. Chaque magasin de données — bases de données, stockage d’objets, volumes attachés et journaux — est chiffré avec des clés gérées qui sont renouvelées selon une cadence gérée.

Toutes les données en transit utilisent TLS 1.3 au minimum. Le site marketing, le tableau de bord client sur app.syncanix.com et le point de terminaison de l’API redirigent tous HTTP vers HTTPS et appliquent HSTS avec un max-age de deux ans, sous-domaines inclus, avec preload. Le BYOK (bring-your-own-key) est pris en charge sur le palier enterprise : les clés fournies par le client servent à l’enveloppe de données de ce client sans jamais apparaître dans les journaux de Syncanix.

Identité et authentification

L’authentification du tableau de bord est gérée par Auth0. Chaque point de terminaison de l’API est protégé par une couche d’authentification qui valide la signature du JWT auprès du point de terminaison JWKS du fournisseur, vérifie l’audience et l’issuer, et rejette les jetons expirés. La protection est activée par défaut ; un point de terminaison n’est public que lorsqu’il est explicitement marqué comme tel. Il n’existe pas de mode de défaillance « j’ai oublié d’ajouter l’authentification » : la valeur par défaut est imposée.

Autorisation

Les contrôles d’autorisation se trouvent dans la couche service, et non à la périphérie de l’API. Un service qui répond à « modifier le projet Y » vérifie que l’appelant dispose au moins du rôle Éditeur sur le projet Y avant d’accéder à la base de données. Les appels de service à service utilisent un schéma d’authentification distinct (enveloppes signées ou points de terminaison authentifiés par la plateforme) — jamais des JWT d’utilisateur.

IAM et moindre privilège

Chaque rôle de charge de travail porte la politique la plus restreinte possible. Les politiques sont rédigées de manière explicite ; aucun rôle n’utilise de caractères génériques larges. Lorsque le cadrage par ressource n’est pas assez expressif, les politiques cadrent par étiquette. Aucune clé d’accès à longue durée de vie n’existe dans la CI : le pipeline endosse un rôle via OIDC ; le développement local utilise des identifiants à courte durée de vie.

Sécurité applicative

Chaque argument de l’API et chaque corps de requête est analysé via un schéma strict avant d’atteindre le code de service. Les requêtes de base de données sont entièrement paramétrées — aucune interpolation de chaîne à partir des entrées de l’utilisateur. Les écritures utilisent des API typées, jamais des expressions brutes construites à partir des entrées de l’utilisateur.

Des en-têtes de sécurité HTTP sont présents sur chaque réponse destinée au client :

• Content-Security-Policy avec une liste d’autorisation stricte (Auth0, origine propre, aucun script en ligne).
• Strict-Transport-Security: max-age=63072000; includeSubDomains; preload.
• X-Frame-Options: DENY (protection contre le clickjacking).
• X-Content-Type-Options: nosniff.
• Referrer-Policy: strict-origin-when-cross-origin.
• Permissions-Policy: géolocalisation, microphone et caméra, tous refusés par défaut.

CORS est appliqué au niveau de deux couches indépendantes, chacune dotée d’une liste d’autorisation d’origines explicite. Une origine avec caractère générique est rejetée au moment de la compilation : un déploiement en production sans origines explicites ne peut pas se poursuivre.

Gestion des secrets

Les secrets de production résident dans un gestionnaire de secrets dédié, sous un espace de noms propre à chaque environnement. La configuration non secrète réside dans un magasin de paramètres distinct. Les secrets sont fournis aux charges de travail au démarrage — ils ne résident jamais dans le contrôle de version. Les identifiants de base de données sont renouvelés automatiquement ; les jetons tiers (Paddle, Anthropic, OpenAI) sont renouvelés manuellement selon une cadence trimestrielle.

Journalisation et audit

Les journaux sont au format JSON structuré, avec une rétention de 14 jours par défaut. Chaque ligne de journal porte un identifiant de corrélation (identifiant de requête) afin que le parcours d’un seul utilisateur puisse être reconstitué de bout en bout. Une liste de masquage occulte automatiquement les champs token / password / secret / authorization ; aucune donnée à caractère personnel complète n’atteint le journal. Les échecs d’authentification émettent une ligne WARN avec l’IP source et le motif — jamais avec le contenu du jeton.

Hygiène des dépendances

Des audits de dépendances automatisés s’exécutent dans la CI ; les avis élevés ou critiques font échouer la compilation. Renovate et Dependabot sont activés sur le manifeste de dépendances et le fichier de verrouillage. Chaque nouvelle bibliothèque open source fait l’objet d’une revue documentée préalable à son adoption (sécurité, maintenance, licence, dépendance, performance).

Certifications et audits

La collecte des preuves pour SOC 2 Type I démarre via Vanta le mois suivant le lancement commercial de Syncanix, avec un rapport Type I visé pour le T3 2026. SOC 2 Type II suit à environ 9 mois. Les preuves ISO 27001 sont collectées en parallèle (70-80 % de chevauchement des contrôles avec SOC 2) — certification visée pour le T4 2026. État de conformité complet →

Réponse aux incidents

Le signalement des vulnérabilités est adressé à admin@syncanix.com — accusé de réception sous 24 heures et triage sous 72 heures. Les violations confirmées ayant un impact sur les clients sont notifiées aux clients concernés dans les 24 heures suivant la confirmation, conformément à l’engagement de l’article 33 du DPA. Un runbook documenté de réponse aux incidents est testé chaque trimestre.