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 tenant (Anthropic, OpenAI-compat., SMTP)	AES-256-GCM, MASTER_ENCRYPTION_KEY
Hachages de mots de passe utilisateur	bcrypt (cost 12)
Chaînes de connexion BYOD	AES-256-GCM, MASTER_ENCRYPTION_KEY
Identifiants de canal IMAP / e-mail	AES-256-GCM, MASTER_ENCRYPTION_KEY
Fichiers de base de données sur disque	Tablespace MySQL InnoDB sur volume chiffré TODO: confirm full-disk encryption status with ops

• Tous les endpoints publics servis exclusivement via HTTPS ; HTTP est redirigé vers HTTPS (en-tête Apache HSTS).
• Version TLS minimale : TLS 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 tenants :

Élément	Fréquence	Rétention	Localisation
Platform DB (einstein_saas_platform)	Quotidiennement, la nuit (UTC, automatisé)	7 sauvegardes quotidiennes (glissantes)	Volume local + réplique hors site chiffrée
Tenant DBs (einstein_saas_tenant_*)	Quotidiennement, la nuit (UTC, automatisé)	7 sauvegardes quotidiennes (glissantes)	Volume local + réplique hors site chiffrée
Fichiers téléchargés / stockage de documents	Quotidiennement, la nuit (UTC, automatisé)	7 sauvegardes quotidiennes (glissantes)	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, répliquées vers un volume hors site distinct, 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 portal se voit attribuer un rôle. Les rôles comportent des permissions granulaires (51+ drapeaux individuels). La plateforme applique les contrôles de permission côté serveur sur chaque endpoint API.

4.2 Authentification à deux facteurs

• L'authentification à deux facteurs via TOTP (RFC 6238 — Google Authenticator, Authy, etc.) est obligatoire pour le rôle propriétaire et est appliquée à la connexion.
• Les propriétaires de compte peuvent rendre obligatoire l'authentification à deux facteurs pour tous les membres de l'équipe via le panneau de paramètres.
• Les codes de récupération de secours sont générés lors de l'inscription et doivent être stockés de manière sécurisée par l'utilisateur.

4.3 Isolation des tenants

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

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 tenant.
• 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 pendant 2 ans. Le journal est append-only au niveau de l'application.

Un utilisateur de base de données dédié insert-only (einstein_audit_writer) est utilisé pour les écritures d'audit, empêchant la modification ou la suppression des entrées de journal par l'utilisateur de base de données d'application.

6.1 Surveillance des CVE

Les dépendances Composer sont surveillées via composer audit à chaque exécution du pipeline de déploiement. Les CVE critiques dans les dépendances d'exécution déclenchent un correctif hors bande dans les 72 heures suivant la publication. TODO: confirm SLA with ops

6.2 Cycle de correctifs

• Correctifs de sécurité du système d'exploitation : appliqués lors de la fenêtre de maintenance hebdomadaire. TODO: confirm window day/time with ops
• Runtime PHP : maintenu à la dernière version stable mineure de la branche active (actuellement PHP 8.2.x).
• 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
Serveur de production	dev01-aionized (Ubuntu)
Serveur web	Apache 2.4 (mod_rewrite, mod_ssl)
Runtime	PHP 8.2+
Base de données	MySQL / MariaDB (platform + per-tenant)
Cache / sessions	Redis (loopback, password-protected)
Transferts de données transfrontaliers	Aucun par défaut. Les appels cloud-AI optionnels (Anthropic/OpenAI-compat.) sont soumis au consentement de l'utilisateur et couverts par les Clauses contractuelles types.