Securite et Conformite

Ce document decrit le modele de securite de ConformVault, les controles en place, les mecanismes de conformite reglementaire et les donnees personnelles traitees. Il est destine aux audits externes et aux evaluations de securite.

Modele de chiffrement

ConformVault utilise une architecture de chiffrement hybride a 4 couches. Le principe fondamental est le Zero-Knowledge : lorsque le chiffrement de bout en bout est active, le serveur n'a jamais acces aux donnees en clair ni aux cles de chiffrement.

Couche 1 : Chiffrement en transit (TLS 1.3)

Toutes les communications entre les clients et les serveurs utilisent TLS 1.3. Les certificats sont geres automatiquement par le Nginx Ingress Controller du cluster Kubernetes OVH.

Couche 2 : Chiffrement au repos (S3 OVH)

Les fichiers stockes dans les buckets S3 OVH sont chiffres au repos par le fournisseur. ConformVault ajoute une couche supplementaire de chiffrement applicatif.

Couche 3 : Chiffrement applicatif (AES-256-GCM)

Chaque fichier est chiffre avec une cle DEK (Data Encryption Key) unique et aleatoire :

• Algorithme : AES-256-GCM (chiffrement authentifie)
• Nonce : 12 octets, genere aleatoirement par fichier
• Tag d'authentification : 16 octets, assure l'integrite du fichier
• Mode chunked : Les fichiers sont decoupes en blocs (1 MB < 10 MB, 5 MB pour 10-100 MB, 10 MB > 100 MB). Chaque bloc a un nonce derive du nonce de base par XOR avec l'index du bloc (big-endian, 4 derniers octets)

Ce chiffrement est effectue cote client (dans le navigateur via Web Crypto API ou dans l'application desktop via le module Rust aes-gcm) dans le mode E2E. Le serveur ne voit jamais les donnees en clair.

Couche 4 : Protection des cles (RSA-4096 + KMS OVH)

Les cles DEK sont protegees par un systeme asymetrique :

• RSA-4096 : Chaque organisation possede une paire de cles RSA-4096
• RSA-OAEP : Enveloppement de la cle DEK avec SHA-256 pour le hachage OAEP et MGF1. Le label OAEP est vide (critique pour l'interoperabilite entre les clients)
• KMS OVH : La cle privee RSA est chiffree par le service KMS d'OVH avant stockage dans PostgreSQL
• Le client web, le client desktop et les SDKs produisent des sorties chiffrees byte-compatibles

Schema de chiffrement

Fichier original
    |
    v
[AES-256-GCM chunked] <-- DEK (cle aleatoire 256 bits)
    |                           |
    v                           v
Fichier chiffre           [RSA-4096 OAEP] <-- Cle publique de l'organisation
(stocke dans S3)                |
                                v
                          DEK chiffree
                          (stockee dans PostgreSQL)

                          Cle privee RSA
                                |
                                v
                          [KMS OVH WrapKey]
                                |
                                v
                          Cle privee chiffree + Base64
                          (stockee dans PostgreSQL)

Derivation de cle (mode E2E cote client)

Lorsque l'utilisateur active le mode Zero-Knowledge :

1. Le mot de passe est derive via PBKDF2 (600 000 iterations) pour obtenir une cle maitre
2. La cle maitre est derivee via HKDF pour obtenir la cle de chiffrement de fichier
3. Le chiffrement est effectue dans des Web Workers (pool de 4) pour ne pas bloquer l'interface

Authentification

JWT (JSON Web Tokens)

• Access token : Duree de vie de 15 minutes
• Refresh token : Utilise pour obtenir un nouveau access token
• Claims : sub (ID utilisateur), email, role, client_id, exp, iss
• Signature : HMAC-SHA256 avec cle secrete configuree par variable d'environnement

Authentification multi-facteurs (MFA)

• TOTP : Algorithme RFC 6238, codes a 6 chiffres
• Activation : Volontaire par l'utilisateur via son profil
• Verification : Requise a chaque connexion si activee

SSO (Single Sign-On)

• Fournisseur : Zitadel (OIDC/OpenID Connect)
• Flux : Authorization Code avec PKCE
• Integration : Le backend Python gere le flux complet et echange les tokens avec l'API Go

Verrouillage de compte

• Seuil : 5 tentatives de connexion echouees consecutives
• Duree : Verrouillage de 15 minutes
• Tracabilite : Chaque tentative est enregistree dans l'audit trail

Controles d'acces

Modele RBAC

Isolation multi-tenant

• Chaque organisation possede son propre bucket S3 dedie
• Les donnees sont isolees au niveau de la base de donnees par client_id / org_id
• Les cles de chiffrement RSA-4096 sont uniques par organisation
• Les requetes API verifient systematiquement l'appartenance de la ressource a l'organisation de l'utilisateur

Permissions sur les dossiers

Des permissions granulaires par dossier peuvent etre definies (lecture, ecriture) avec support des permissions temporaires (expiration automatique).

Protection contre les menaces

Rate limiting

• Endpoints d'authentification : 20 requetes/minute
• Mutations de facturation : 10 requetes/minute par organisation
• Implementation : Redis distribue avec script Lua atomique, fallback in-memory

Protection CSRF

• ContentTypeMiddleware : Rejet des Content-Type "simples" (text/plain, x-www-form-urlencoded)
• CORS strict : Origines autorisees explicitement listees, pas de wildcard en production
• En-tetes de securite : HSTS, X-Frame-Options DENY, Content-Security-Policy, Permissions-Policy, X-Permitted-Cross-Domain-Policies

Protection contre l'injection SQL

• Toutes les requetes SQL utilisent des parametres ($1, $2...) via asyncpg et le driver Go
• Les champs dynamiques dans les requetes UPDATE sont valides contre des listes blanches (whitelist)
• Validation des entrees via Gin binding (Go) et Pydantic (Python)

Taille des requetes

• Limite globale : 500 MB (MaxBodySizeMiddleware)
• Limite par defaut : 1 MB
• Uploads : 25 MB (configurable)

Antivirus

• ClamAV : Scan optionnel des fichiers uploades avant stockage
• Activation : Via la variable d'environnement CLAMAV_ENABLED
• Deploiement : Pod dedie dans le cluster Kubernetes

Sanitisation des erreurs

Les reponses d'erreur en production sont sanitisees : les erreurs 5xx retournent un message generique sans details d'implementation interne.

Audit trail

Chaque action significative est enregistree dans la table audit_logs :

Actions tracees

L'API d'audit supporte la recherche, l'export et la detection d'anomalies.

Conformite reglementaire

Loi 25 (Quebec)

La Loi 25 sur la protection des renseignements personnels dans le secteur prive impose des obligations auxquelles ConformVault repond :

PIPEDA (Canada)

• Responsabilite : Chaque organisation a un administrateur responsable
• Consentement : Mecanisme de consentement pour les liens de partage
• Limitation de l'utilisation : Isolation des donnees par organisation
• Mesures de securite : Chiffrement E2E, MFA, rate limiting

RGPD (Union Europeenne)

• Base legale : Consentement explicite pour les liens de partage
• Droit a l'effacement : Suppression des fichiers et comptes, corbeille avec soft-delete
• Portabilite : Export des fichiers
• Residence : Option de stockage en France (OVH GRA, Gravelines)

SOC 2

ConformVault est concu pour respecter les principes SOC 2 Trust Services Criteria :

• Securite : Chiffrement multicouche, RBAC, audit trail, rate limiting
• Disponibilite : Deploiement Kubernetes avec replicas, health checks, monitoring Prometheus
• Integrite du traitement : Tag GCM d'authentification, SHA-256 checksum, ClamAV
• Confidentialite : Zero-Knowledge E2E, isolation multi-tenant, KMS
• Vie privee : Consentement Loi 25, export/suppression des donnees

Donnees personnelles traitees

Audit de securite

Un audit de securite complet a ete realise en fevrier 2026 (v0.4.30 / v0.4.31). Resultats :

• 29 constatations corrigees : 2 critiques + 8 elevees + 8 moyennes + 11 basses
• Corrections critiques : Suppression des credentials hardcodes, migration vers variables d'environnement
• Corrections elevees : Verification SSL centralisee, suppression des logs de donnees sensibles, injection SQL corrigee (parametrisation + listes blanches)
• Corrections moyennes : En-tetes de securite (HSTS, CSP, X-Frame-Options), CORS durci, limite de taille des requetes
• Risques acceptes documentes : JWT en localStorage (refactoring majeur differe), timeouts HTTP client (amelioration incrementale)

La baseline de securite est documentee dans SECURITY_REMEDIATION.md avec la classification (REMEDIATED, FALSE POSITIVE, ACCEPTED RISK) de chaque constatation.