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.
Défense en profondeur
Chaque couche (réseau, application, base, données) possède ses propres contrôles indépendants. Un attaquant doit franchir plusieurs barrières successives, jamais une seule.
Never trust the client
Aucune décision de sécurité n'est basée sur des données fournies par le navigateur. Le tenant_id, l'oid utilisateur et les rôles sont toujours dérivés de la session serveur.
Least privilege
Chaque rôle ne dispose que des permissions strictement nécessaires à son métier. Les comptes techniques (cron, API) ont des permissions distinctes des comptes humains.
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 ?
| Type de donnée | Stockage | Pourquoi |
|---|---|---|
| Annuaire utilisateurs, RBAC, plans, catalogues partagés (NIS2, DORA, ISO 27001, RGPD…), journal de connexion | PostgreSQL central | Données cross-tenant : gouvernance plateforme, requêtes admin, reporting consolidé |
| Audits, réponses aux questionnaires, références de preuves (chemins indexés vers SharePoint), analyses de risques, clés IA (BYOK), métadonnées SharePoint | SQLite chiffré par tenant AES-256 | Données propriétés du client. Un fichier {uuid}.sqlite par client, sa propre clé. |
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 = Xreste 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) : RLS est actif en production depuis le 15 mai 2026 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
| Bases SQLite tenants | SQLCipher AES-256 avec DEK individuelle par tenant + KEK maître hors-base |
|---|---|
| PostgreSQL central | Chiffrement disque + sauvegardes chiffrées GPG, RLS activé |
| Mots de passe utilisateur | bcrypt cost 12 (auth locale) + bcrypt sur OTP, anti-timing par hash burn |
| Tokens CSRF | random_bytes(32) : 256 bits d'entropie, validation hash_equals() |
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
| Méthode | Implémentation |
|---|---|
| SSO Azure Entra ID | OAuth2 Authorization Code, JWT RS256, validation signature via JWKS Microsoft, state + nonce anti-CSRF/replay |
| Auth locale | bcrypt cost 12, anti-timing burn hash, anti-enumeration message générique |
| OTP par email | Code 6 chiffres généré par CSPRNG, stocké en bcrypt, expiration 15 min, 3 tentatives max, rate limit 5 envois/heure |
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
| Cookie | Secure, HttpOnly, SameSite=Lax |
|---|---|
| Durée | 15 minutes (sliding window) |
| Régénération ID | session_regenerate_id(true) après auth |
| Session unique | Last-login-wins : les sessions précédentes sont détruites à chaque login |
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 à deux volets (23 catégories : identifiants et PII + secrets techniques) avant envoi, BYOK Azure OpenAI (instance Azure propre au tenant) ou alternatives Anthropic / LLM local Ollama, kill-switch global, quotas par tenant. Le mapping de ré-identification reste exclusivement côté serveur Auditor PRO.
- Anonymisation à deux volets avant envoi au LLM (23 catégories détectées par regex déterministe, remplacées par des jetons opaques numérotés). Volet 1, identifiants et PII : emails, IP, téléphones, IBAN, chemins UNC et hostnames internes, URLs internes, civilités et noms de personnes (M. Dupont, Mme Martin, Dr Durand), raisons sociales avec forme juridique (Acme SAS / SARL / EURL / SCI / etc.), SIRET, SIREN, TVA intracommunautaire FR, adresses postales (code postal + ville). Volet 2, secrets techniques : clés privées RSA / SSH / PGP / EC / DSA / ENCRYPTED, clés publiques SSH (ssh-rsa, ssh-ed25519, ecdsa-sha2-*), tokens AWS Access Key (AKIA / ASIA), tokens GitHub (ghp_ / ghs_ / gho_ / ghu_ / ghr_ / github_pat_), tokens Slack (xoxb / xoxp / xoxa / xoxr / xoxs), JWT (eyJ...), Bearer tokens, connection strings (postgres, mysql, mongodb, redis, amqp, SQL Server / .NET), clés API génériques (api_key, client_secret, access_token, auth_token), mots de passe en clair (password=, mdp:, pwd:, passwd:). Le mapping de ré-identification reste exclusivement côté serveur Auditor PRO, jamais transmis au LLM.
- 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). Mode recommandé pour les tenants dont la posture de risque exclut tout appel LLM externe, même après anonymisation.
- 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
| Hébergement | Union européenne ou région souveraine désignée selon le déploiement régional (cf. CGVU §12.3). Sous-traitant infrastructure : OVH SAS (UE). |
|---|---|
| Sauvegardes | Schéma 3-2-1 : full quotidien BDD + différentiel quotidien fichiers + delta hebdomadaire + full mensuel ; site distant + copie offline air-gap (protection ransomware) |
| SLA disponibilité | Engagements précis (taux de disponibilité, GTI, GTR, fenêtres de maintenance) définis dans le Contrat de Service annexé aux CGVU (Annexe 2) |
| PRA / PCA | Modalités (RTO, RPO, fréquence de bascule) définies dans le Contrat de Service annexé aux CGVU (Annexe 2) |
| Notification incident | Notification au tenant selon les modalités définies au DPA (Annexe 1), dans le respect des obligations RGPD article 33 |
10 Vos questions, nos réponses directes
Les 6 questions que se posent les RSSI et DPO avant de tester. Réponses précises et sans détour.