Sécurité Multi-Tenant : Comment Protéger les Données dans un SaaS Moderne

La sécurité des données est le fondement de toute plateforme SaaS multi-tenant. Un seul incident de fuite de données entre clients peut détruire la confiance et l'entreprise tout entière. Chez OZIOW, nous avons adopté une approche de défense en profondeur qui garantit l'isolation des données à chaque niveau de l'architecture.

Qu'est-ce que le Multi-Tenancy ?

Dans une architecture multi-tenant, une seule instance de l'application sert plusieurs clients (tenants). Chaque tenant possède ses propres données, ses propres utilisateurs et sa propre configuration, mais partage la même infrastructure technique. C'est le modèle utilisé par Salesforce, HubSpot et la plupart des SaaS modernes.

Le défi critique est de garantir qu'aucun tenant ne peut accéder aux données d'un autre, même en cas de bug applicatif.

Niveau 1 : Row-Level Security (RLS) de PostgreSQL

OZIOW utilise le Row-Level Security de PostgreSQL comme première ligne de défense. Chaque table contenant des données de tenant possède une colonnetenant_id et une politique RLS qui filtre automatiquement les lignes :

-- Politique RLS sur la table saas_organizations
CREATE POLICY "tenant_isolation" ON saas_organizations
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

-- Chaque requête est automatiquement filtrée
-- Un tenant A ne peut JAMAIS voir les données du tenant B

Cette protection opère au niveau du moteur de base de données lui-même. Même si un développeur oublie un filtre WHERE tenant_id = ?dans une requête, PostgreSQL bloque automatiquement l'accès aux données des autres tenants.

Niveau 2 : Authentification JWT Multi-Couche

OZIOW utilise un système JWT (JSON Web Token) à double jeton :

• Access Token (15 min) : Contient l'identité de l'utilisateur, son tenant_id et ses rôles. Utilisé pour chaque requête API.
• Refresh Token (7 jours) : Permet de renouveler l'Access Token sans re-saisir le mot de passe. Stocké de manière sécurisée côté client.

Le tenant_idest encodé dans le JWT et vérifié à chaque requête par un Guard NestJS. Il est impossible de modifier le tenant_id d'un token sans invalider sa signature cryptographique.

Niveau 3 : RBAC Granulaire

Le contrôle d'accès basé sur les rôles (Role-Based Access Control) d'OZIOW permet de définir des permissions fines pour chaque utilisateur au sein de son tenant :

• PLATFORM_OWNER : Accès total à la plateforme et tous les tenants
• TENANT_ADMIN : Administrateur d'un tenant spécifique
• ORG_ADMIN : Administrateur d'une organisation au sein d'un tenant
• MEMBER : Utilisateur standard avec accès limité

Niveau 4 : Journaux d'Audit

Chaque action critique est enregistrée dans la tablesaas_audit_logsavec un horodatage, l'identité de l'utilisateur, l'adresse IP, le type d'action et les données avant/après modification. Ces journaux sont immuables et exportables pour les audits de conformité RGPD.

Niveau 5 : Chiffrement et Infrastructure

• HTTPS/TLS : Toutes les communications sont chiffrées via des certificats Let's Encrypt.
• Chiffrement au repos : Les bases de données Supabase sont chiffrées avec AES-256.
• Rate Limiting : Protection contre les attaques par force brute (100 requêtes/minute par IP).
• CORS strict : Seuls les domaines autorisés peuvent communiquer avec l'API.
• Hébergement EU : Les serveurs sont hébergés à Francfort (Allemagne) pour la conformité RGPD.

Conclusion

La sécurité d'une plateforme SaaS multi-tenant ne peut pas être un ajout tardif. Chez OZIOW, elle est intégrée dans l'architecture dès la première ligne de code, de la base de données au réseau, en passant par l'application. C'est cette approche qui permet à nos clients de confier leurs données les plus sensibles à la plateforme en toute sérénité.