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 disponible sur toutes les offres — les clients peuvent acheminer le trafic vers le modèle via leur propre clé de fournisseur, qui n’apparaît jamais 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.

Sécurité de l’IA agentique et défense contre l’injection de prompt

Le widget de chat et le serveur MCP par locataire sont mis en correspondance avec l’OWASP Top 10 pour les applications agentiques 2026 (ASI01–ASI10). L’adversaire principal que nous visons est le contenu non fiable qui atteint le modèle — une charge d’injection de prompt dissimulée dans un document récupéré, le résultat d’un outil ou le contexte de la page — qui tente de détourner l’agent, d’exfiltrer des données ou de tromper l’utilisateur.

Pour les risques de la classe injection, notre posture publiée est honnête : atténué et mesuré, jamais « éliminé ». Les contrôles déterministes ci-dessous sont vérifiés dans le code et conditionnent chaque déploiement ; les résidus liés au comportement du modèle, comme une nouvelle formulation de jailbreak, sont suivis et soumis en continu à des exercices de red-team.

Les contrôles qui soutiennent cette posture :

• Un pare-feu d’entrée à sécurité intégrée inspecte chaque canal non fiable avant l’exécution du modèle et refuse les tentatives de jailbreak et de contournement du prompt système — dans les six langues prises en charge, de sorte que changer de langue ne le contourne pas.
• Le contenu que le modèle n’a pas produit (documents récupérés, résultats d’outils, contexte de la page) est traité comme non fiable : une action qui en découle ne peut jamais écrire, supprimer ni rediriger sans une confirmation nouvelle et explicite.
• Un filtre de prévention des pertes de données masque les secrets et les données personnelles dans la sortie du modèle avant qu’elle ne quitte la plateforme.
• Une suite adversariale de red-team sélectionnée s’exécute à chaque changement et bloque le déploiement si une attaque connue passe — ou si un message légitime commence à être bloqué à tort.

Le modèle de menaces assaini complet et les résultats de l’évaluation adversariale — la cartographie de l’OWASP Agentic Top 10 et notre méthodologie de red-team — sont disponibles pour les équipes de sécurité sur demande à admin@syncanix.com sous accord de confidentialité mutuel.

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 3 jours ouvrés et triage sous 7 jours. 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.