Pratiques de sécurité

Les champs sensibles stockés dans la base de données de la plateforme sont chiffrés avec AES-256-GCM avant d'être écrits sur le disque.

Quoi	Comment
Clés API du compte (Anthropic, OpenAI-compat., SMTP)	AES-256-GCM, MASTER_ENCRYPTION_KEY
Hachages de mots de passe utilisateur	bcrypt (cost 12)
Identifiants de canal IMAP / e-mail	AES-256-GCM, MASTER_ENCRYPTION_KEY
Fichiers de base de données sur disque	Les champs sensibles sont chiffrés au niveau applicatif avant stockage (AES-256-GCM, AAD par client, clés dans HashiCorp Vault).

• Tous les endpoints publics servis exclusivement via HTTPS ; HTTP est redirigé vers HTTPS (en-tête Apache HSTS).
• Versions TLS prises en charge : TLS 1.2 et 1.3 (TLS 1.0 / 1.1 désactivés).
• Le widget widget.js est servi avec Access-Control-Allow-Origin: * mais les endpoints de l'API de chat valident widget_key + liste d'origines autorisées.
• Les appels de service interne (Redis, MySQL sur localhost) communiquent via l'interface de boucle locale. Aucune donnée ne quitte l'hôte sans chiffrement.

Le calendrier de sauvegarde suivant s'applique à la base de données de plateforme et aux bases de données des clients :

Élément	Fréquence	Rétention	Localisation
Platform DB (einstein_saas_platform)	Quotidiennement, la nuit (UTC, automatisé)	7 jours en local ; copie chiffrée en France jusqu'à 3 semaines	Volume local + réplique hors site chiffrée
Client DBs (einstein_saas_tenant_*)	Quotidiennement, la nuit (UTC, automatisé)	7 jours en local ; copie chiffrée en France jusqu'à 3 semaines	Volume local + réplique hors site chiffrée
Fichiers téléchargés / stockage de documents	Quotidiennement, la nuit (UTC, automatisé)	Copie chiffrée en France, environ un mois	Volume local + réplique hors site chiffrée

Les sauvegardes s'exécutent par base de données via mysqldump --single-transaction, sont stockées compressées et chiffrées avec age, copiées chaque jour, à nouveau chiffrées, vers un centre de données en France, ailleurs que nos serveurs, et chaque exécution est vérifiée pour un dump non vide et journalisée avec un statut de réussite/échec.

Les archives de sauvegarde sont chiffrées au repos avec age (X25519 / ChaCha20-Poly1305) ; la clé de déchiffrement est conservée séparément des archives. Les champs protégés par un chiffrement au niveau des colonnes (AES-256-GCM) restent chiffrés dans chaque archive. La récupérabilité est vérifiée par un test de restauration mensuel automatisé.

4.1 Contrôle d'accès basé sur les rôles (RBAC)

Chaque utilisateur du portail se voit attribuer un rôle. Les rôles comportent des permissions distinctes par domaine. La plateforme vérifie les permissions côté serveur.

4.2 Authentification à deux facteurs

• 2FA via une application d'authentification (TOTP, RFC 6238 — par exemple Google Authenticator ou Authy) ou via un code par e-mail. Chaque utilisateur l'active lui-même dans les paramètres de son compte.
• Lorsque la 2FA est activée, la plateforme demande la deuxième étape à chaque connexion.
• Il n'y a pas de codes de récupération. Les utilisateurs qui choisissent le code par e-mail n'ont pas besoin d'une application distincte.

4.3 Isolation des comptes

L'authentification nécessite un contexte de compte (connexion basée sur slug). Les jetons de session sont limités à un seul compte. L'accès aux ressources entre comptes est empêché au niveau de la couche application par des filtres tenant_id obligatoires dans les requêtes de base de données.

Les actions importantes effectuées sur les ressources de la plateforme sont enregistrées dans le tableau audit_log (base de données de plateforme). Chaque entrée capture :

• Acteur : ID utilisateur, rôle et ID du compte.
• Action : verbe (créer, mettre à jour, supprimer, se connecter, exporter, ...).
• Ressource : type d'entité et ID.
• Métadonnées : noms de champs modifiés et valeurs anciennes/nouvelles (champs sensibles masqués).
• Horodatage : stocké en UTC (ISO 8601).
• Adresse IP : IP source de la requête.

Les entrées du journal d'audit sont conservées deux ans, puis supprimées automatiquement, même si le compte a pris fin plus tôt. La preuve qu'une demande d'effacement a été exécutée est supprimée automatiquement après 12 mois. Le journal est en ajout seul (append-only) au niveau de l'application.

Les entrées d'audit sont écrites par l'utilisateur de base de données habituel de l'application. Un utilisateur de base de données insert-only distinct n'est prévu que pour le journal d'audit de l'API revendeur.

6.1 Surveillance des CVE

Nous vérifions les dépendances Composer avec composer audit. Les vulnérabilités critiques des dépendances d'exécution sont traitées en priorité.

6.2 Cycle de correctifs

• Mises à jour de sécurité du système d'exploitation : installées automatiquement chaque jour (unattended-upgrades).
• Runtime PHP : PHP 8.5, maintenu à jour avec les mises à jour de sécurité.
• Serveur web : Apache 2.4.x — maintenu à jour avec les mises à jour de sécurité de la distribution.

6.3 Divulgation responsable

Les chercheurs en sécurité externes sont invités à signaler les vulnérabilités en vertu de notre politique de divulgation coordonnée. Lire la politique de divulgation responsable →

Composant	Détail
Région d'hébergement	UE — Pays-Bas (base de données), France (fichiers et sauvegardes)
Serveur web	Apache 2.4 (mod_rewrite, mod_ssl)
Runtime	PHP 8.5
Base de données	MySQL / MariaDB (platform + per-tenant)
Cache / sessions	Redis (loopback, password-protected)
Transferts de données transfrontaliers	Le traitement IA peut avoir lieu hors de l'UE, par exemple aux États-Unis, sauf si EU-only est activé (à partir de Plus). Nous vous indiquons sur demande quels fournisseurs d'IA nous utilisons.