Sécurité & confiance

01 Notre approche de la sécurité

Auditor PRO applique trois principes fondateurs à toutes les couches techniques de la plateforme. Ils ne sont pas négociables et guident chaque décision de conception.

02 Isolation multi-tenant : trois couches indépendantes

Auditor PRO repose sur une architecture à deux moteurs de stockage complémentaires : PostgreSQL central pour la gouvernance, et un fichier SQLite chiffré par client pour les données métier. Cette séparation garantit qu'aucun bug applicatif ne peut faire fuiter des données entre clients.

Pourquoi deux bases ?

Trois bénéfices différenciants

• Isolation cryptographique par client : un compromis serveur n'expose qu'un seul tenant à la fois. Là où un SaaS mono-base doit défendre une seule grosse base contenant 100 % des clients, nous opposons N petites forteresses indépendantes.
• Crypto-shredding RGPD prouvable : la suppression de la clé d'un client rend son fichier mathématiquement illisible, même depuis un backup ancien. Conformité article 17 cryptographiquement vérifiable, pas déclarative.
• Pas de fuite cross-tenant par bug applicatif : un bug qui omet le filtre WHERE tenant_id = X reste contenu : les fichiers SQLite des autres clients sont physiquement distincts, chiffrés avec des clés différentes.

Trois couches d'isolation indépendantes

Couche applicative (PHP) : toute requête est explicitement filtrée par tenant_id extrait de la session serveur (getSessionTenantId()). Aucun identifiant tenant n'est jamais accepté depuis le client.

Couche base de données (PostgreSQL Row-Level Security) : depuis mai 2026, RLS est activé sur l'ensemble des tables tenant-scopées avec FORCE ROW LEVEL SECURITY. Même si le code applicatif omet une clause WHERE tenant_id, la base refuse les lignes hors tenant. Si la variable de session n'est pas positionnée, zéro ligne n'est visible. Fail closed

Couche stockage (SQLite chiffré par tenant) : chaque tenant est chiffré avec une DEK individuelle (Data Encryption Key, 256 bits aléatoires) elle-même chiffrée par une KEK maître conservée hors-base. Un attaquant qui obtiendrait un accès filesystem ne peut pas lire ces données sans aussi obtenir la KEK ET la DEK chiffrée du tenant cible. AES-256 DEK/KEK

03 Chiffrement de bout en bout

Les données sont chiffrées en transit (TLS 1.2+ uniquement) et au repos (AES-256 par tenant). Les mots de passe et secrets utilisateur reposent sur des algorithmes modernes et lents par conception.

En transit

• TLS 1.2 et 1.3 uniquement, SSLv3/TLS 1.0/1.1 désactivés
• Renforcement des suites cryptographiques (Forward Secrecy)
• HSTS activé avec preload : redirection forcée HTTPS, 1 an

Au repos

04 Identité & contrôle d'accès

Trois méthodes d'authentification (SSO Azure, locale, OTP email), une politique de mot de passe stricte, et un modèle RBAC à cinq rôles attribués par tenant.

Méthodes d'authentification

Politique mot de passe (auth locale)

• 13 caractères minimum (dépasse la recommandation ANSSI de 12)
• Majuscule + minuscule + chiffre + caractère spécial obligatoires
• Historique : les 5 derniers mots de passe ne peuvent être réutilisés
• Expiration : 90 jours
• Verrouillage compte : 5 échecs en 15 min → lockout
• Rate limit IP : 10 requêtes/min → HTTP 429

Sessions

RBAC : 5 rôles par tenant

Un utilisateur peut avoir des rôles différents selon le tenant qu'il consulte. Chaque endpoint API vérifie le rôle avant tout traitement via requireRoleOrDie([...]).

• tenant_admin : administration complète du tenant
• manager : tableau de bord, plans d'action, reporting équipe
• auditeur : conduite d'audit, délégation, export
• audité : réponse aux contrôles délégués uniquement
• testeur : essai gratuit limité dans le temps

Certains modules appliquent en plus un scoping intra-tenant par utilisateur : un auditeur ne voit et ne manipule que ses propres données, même si d'autres auditeurs du tenant existent.

05 IA confidentielle

Quatre couches de protection face au traitement par IA : anonymisation avant envoi, BYOK Azure OpenAI (instance Azure propre au tenant) ou alternatives Anthropic / LLM local, kill-switch global, quotas par tenant. Le mappping de ré-identification reste exclusivement côté serveur Auditor PRO.

• Anonymisation des données avant envoi au LLM : emails, noms de personnes, numéros de téléphone, identifiants techniques sont remplacés par des jetons opaques avant tout appel IA.
• BYOK (Bring Your Own Key) Azure OpenAI : chaque tenant peut configurer sa propre instance Azure OpenAI (endpoint, deployment, API key). Les paramètres sont stockés dans le SQLite chiffré du tenant (table tenant_ai_config), jamais en base centrale, et Effitek n'y a aucun accès. Les requêtes IA partent vers l'instance Azure du client : aucune instance LLM partagée entre clients.
• Options alternatives sans BYOK : pour les tenants qui ne souhaitent pas configurer leur propre infrastructure Azure : Claude (Anthropic) hébergé chez Anthropic via API, ou LLM local (Ollama) hébergé chez le Client ou dans une infrastructure souveraine désignée : aucune donnée ne quitte le périmètre du Client (cf. CGVU §13).
• Kill-switch global : un flag plateforme permet de désactiver instantanément tout appel IA pour tous les tenants (incident de sécurité, anomalie fournisseur).
• Quotas par tenant : limites de tokens et d'appels par plan et par période, pour éviter dérapage de coûts et exfiltration de masse.

06 Protection OWASP Top 10

Couverture systématique des dix risques applicatifs OWASP les plus courants.

• Injections (SQL, OS, NoSQL) : toutes les requêtes utilisent des requêtes paramétrées PDO. Aucune concaténation SQL. Validation stricte des inputs en amont.
• XSS & CSP : Content Security Policy stricte (script-src, style-src, frame-ancestors), htmlspecialchars() systématique sur les sorties HTML, X-XSS-Protection + X-Content-Type-Options: nosniff.
• CSRF : token CSRF (256 bits) requis sur toutes les actions POST/DELETE, validé par hash_equals().
• En-têtes HTTP : HSTS preload 1 an, X-Frame-Options DENY, Referrer-Policy strict-origin-when-cross-origin, Permissions-Policy restrictive.
• Rate limiting : limites par IP et par compte sur login, OTP, contact, register. HTTP 429 + log applicatif.
• Méthodes HTTP : TRACE désactivé, méthodes autorisées explicitement par endpoint.

07 Traçabilité & journalisation

Toute action sensible laisse une trace horodatée, attribuée, exportable en cas d'audit.

• connexion_log : chaque tentative d'authentification (succès, échec, méthode, IP, user agent)
• activity_log : création, modification, suppression d'entités métier (audit, preuve, plan d'action, délégation)
• error_log PHP : toutes les exceptions et anomalies applicatives, sans données sensibles
• Rétention des journaux applicatifs : selon les délais définis dans le DPA (Annexe 1). La rétention des données client est traitée séparément dans les CGVU §résiliation.
• Export : CSV + JSON sur demande, pour intégration SIEM client (plan Enterprise)

08 Démarche d'amélioration continue

Trois mécanismes complémentaires pour valider la sécurité réelle, pas seulement la sécurité documentée.

• Audit black-box (externe) : pentest annuel par un prestataire indépendant, rapport disponible sous NDA
• Audit white-box (code source) : revue de code statique (SAST), scan de dépendances (Composer audit), audit régulier par un expert externe
• Revue manuelle ciblée : chaque mise en production d'une feature sensible (auth, paiement, IA, BYOK) déclenche une revue dédiée
• Mises à jour système : patch security OS sous 30 jours, dépendances applicatives sous 14 jours (CVE critique : 48 h)

09 Conformité & engagements

Auditor PRO est conçu pour les entreprises soumises à NIS2, DORA, RGPD, et hébergé exclusivement dans l'Union européenne.

Standards et référentiels couverts par l'outil

La plateforme intègre les catalogues officiels de 50+ référentiels : NIS2, DORA, ISO/IEC 27001, ISO/IEC 27002, ISO/IEC 27005, NIST CSF 2.0, NIST 800-53, CIS Controls v8, PCI DSS v4, SOC 2, RGPD, TISAX, EBA ICT, et bien d'autres.

Engagements opérationnels Effitek