Politique de Sécurité des Données
security@zenoiaiq.ch
1. Objet
La présente Politique de Sécurité décrit les mesures techniques et organisationnelles mises en œuvre par Zenoia Sàrl pour protéger les données des utilisateurs de la plateforme ZenoiaIQ, conformément à l'article 8 de la nDSG (RS 235.1) et à l'article 1-4 de l'OPDo (RS 235.11).
2. Architecture de sécurité
2.1 Modèle de défense en profondeur (5 couches)
| Couche | Mesure | Détail |
|---|---|---|
| 1 | Isolation multi-tenant | Row Level Security (RLS) sur chaque table, filtrage par company_id |
| 2 | Proxy API serveur | Clés API sensibles (Claude, Stripe) jamais exposées côté client |
| 3 | Authentification forte | 2FA obligatoire par code email (OTP), JWT avec double algorithme (ES256/HS256) |
| 4 | Gestion de session | Jetons JWT, session isolée par navigateur, vérification à chaque requête, trusted devices |
| 5 | Porte d'entrée (auth gate) | Aucun élément d'interface affiché avant authentification complète |
2.2 Chiffrement
| Périmètre | Méthode | Standard |
|---|---|---|
| En transit | TLS 1.2+ | HTTPS obligatoire (HSTS preload) |
| Au repos (DB) | AES-256 | Supabase/AWS encryption at rest |
| Au repos (fichiers) | AES-256 | Supabase Storage encryption |
| Mots de passe | bcrypt | Hachage irréversible (Supabase Auth) |
| Jetons JWT | ES256 / HS256 | Signature ECDSA avec clés JWKS |
2.3 Contrôle d'accès
| Mécanisme | Implémentation |
|---|---|
| RBAC | 3 rôles : admin > manager > member |
| Hiérarchie | Centralisation dans roles.js, vérification côté client ET serveur |
| Auditeur | Accès orthogonal (auditor_access boolean) |
| Super admin | Accès plateforme distinct du rôle entreprise |
2.4 Protection applicative
| Attaque | Protection |
|---|---|
| XSS (Cross-Site Scripting) | escHtml() global sur tous les innerHTML, CSP stricte |
| Injection SQL | Requêtes paramétrées via Supabase SDK, RLS |
| CSRF | Jetons JWT dans les headers (pas de cookies de session classiques) |
| IDOR | Vérification user_company_access avant chaque opération sensible |
| Brute force | Rate limiting (20 req/15min sur 2FA, 10/5min sur sourcing) |
| DDoS | Protection Vercel Edge Network + Supabase rate limiting |
| Clickjacking | X-Frame-Options: DENY |
| MIME sniffing | X-Content-Type-Options: nosniff |
2.5 Veille réglementaire automatisée
ZenoiaIQ intègre un assistant de veille réglementaire automatisé (Regulatory IQ) qui surveille mensuellement les sources officielles suisses (ESTV, BSV, SECO) pour détecter les modifications de taux TVA, AVS/AI/APG, allocations familiales, barèmes d'impôt à la source, seuils LPP et conventions collectives. Les modifications détectées sont analysées par IA et soumises à validation manuelle par un administrateur avant toute application. Aucune modification automatique n'est effectuée dans la base de données sans intervention humaine.
3. Procédure de gestion des incidents
3.1 Classification des incidents
| Niveau | Description | Exemples | Délai de réponse |
|---|---|---|---|
| Critique | Fuite de données personnelles, accès non autorisé | Compromission DB, vol de JWT, exfiltration | < 1 heure |
| Élevé | Tentative d'intrusion détectée, faille exploitable | Injection SQL tentée, brute force 2FA, zero-day | < 4 heures |
| Moyen | Anomalie sans impact avéré | Pic anormal de requêtes, tentatives de scraping | < 24 heures |
| Faible | Bug mineur, amélioration préventive | Header manquant, CSP ajustement | < 7 jours |
3.2 Procédure en cas d'incident critique
Phase 1 — Confinement (< 1h)
- Isoler le périmètre affecté (suspension de l'API, rotation des clés, blocage IP)
- Évaluer l'étendue de la compromission
- Activer les sauvegardes si corruption de données
Phase 2 — Notification (< 24h si risque élevé)
- Notifier le PFPDT (art. 24 nDSG) si risque élevé pour les personnes concernées
- Notifier les Utilisateurs affectés avec description de l'incident et mesures prises
- Notifier les Sous-traitants concernés (Supabase, Vercel)
Phase 3 — Remédiation (< 72h)
- Corriger la faille ou vulnérabilité
- Vérifier l'intégrité des données
- Restaurer le service normal
Phase 4 — Post-mortem (< 7 jours)
- Rédiger un rapport d'incident détaillé
- Identifier les améliorations à apporter
- Mettre à jour les mesures de sécurité
- Date et heure de détection
- Nature et périmètre de l'incident
- Données potentiellement affectées
- Mesures de confinement prises
- Notifications effectuées (PFPDT, Utilisateurs)
- Cause racine identifiée
- Mesures correctives et préventives
- La sélection de prestataires disposant de certifications reconnues (SOC 2, PCI DSS)
- La vérification régulière de la conformité des sous-traitants
- L'inclusion de clauses de sécurité et de notification dans les contrats
- Supabase est SOC 2 Type II certifié et opère sur AWS avec encryption at rest
- Données hébergées en région eu-central-2 (Zurich, Suisse)
- En cas de fuite chez Supabase, Zenoia notifiera les Utilisateurs et le PFPDT
- La responsabilité de Zenoia est limitée aux dommages directs proportionnels à sa part de responsabilité
- Vercel est SOC 2 Type II certifié
- Les fonctions serveur sont exécutées en région fra1 (Frankfurt, Allemagne)
- Les fonctions serveur ne stockent aucune donnée persistante (stateless)
- Les variables d'environnement (clés API) sont chiffrées par Vercel
- Impact limité : indisponibilité temporaire, pas de fuite de données stockées
- Stripe est PCI DSS Level 1 (plus haut niveau)
- Zenoia ne stocke jamais de données de carte bancaire
- En cas d'incident Stripe, seules les données de facturation (nom, adresse) pourraient être affectées
- Seules les données explicitement soumises à l'IA sont transmises
- Aucune donnée n'est conservée par Anthropic après traitement
- Les données sensibles ne sont jamais transmises à l'IA
- Seules les adresses email et les codes 2FA transitent par Resend
- Les codes 2FA ont une durée de validité limitée (10 minutes)
- Envoyez un rapport détaillé à security@zenoiaiq.ch
- N'exploitez pas la vulnérabilité au-delà du strict nécessaire pour la démontrer
- Ne divulguez pas publiquement la vulnérabilité avant sa correction
- Accordez un délai raisonnable (90 jours) pour la correction
- Accuser réception dans les 48 heures
- Évaluer la vulnérabilité dans les 7 jours
- Corriger les failles critiques dans les 72 heures
- Communiquer sur l'avancement de la correction
- Ne pas engager de poursuites contre les chercheurs agissant de bonne foi
- Au minimum une fois par an
- Après chaque incident de sécurité significatif
- Lors de changements majeurs d'architecture ou de sous-traitants
3.3 Registre des incidents
Chaque incident est documenté dans un registre interne comprenant :
4. Responsabilité en cas d'incident chez un sous-traitant
4.1 Principe de diligence (art. 9 al. 2 nDSG)
Zenoia est tenue de s'assurer que ses sous-traitants sont en mesure de garantir la sécurité des données. Cette diligence se manifeste par :
4.2 Scénarios spécifiques
Incident chez Supabase (base de données) :
Incident chez Vercel (hébergement) :
Incident chez Stripe (paiements) :
Incident chez Anthropic (IA) :
Incident chez Resend (emails) :
5. Signalement de vulnérabilités
5.1 Responsible Disclosure
Zenoia encourage le signalement responsable des vulnérabilités de sécurité. Si vous découvrez une faille :
5.2 Engagement de Zenoia
Zenoia s'engage à :
6. Continuité de service
6.1 Sauvegardes
| Type | Fréquence | Rétention | Outil |
|---|---|---|---|
| Point-in-Time Recovery | Continue | 7 jours | Supabase Pro |
| Snapshot quotidien | Quotidien | 30 jours | Automatique AWS |
6.2 Plan de reprise
| Scénario | RTO (objectif) | RPO (perte max) | Procédure |
|---|---|---|---|
| Panne Vercel | 30 min | 0 (stateless) | Basculement automatique Vercel |
| Panne Supabase | 2h | < 1h | Restauration depuis PITR |
| Corruption de données | 4h | < 24h | Restauration depuis snapshot |
| Compromission complète | 12h | < 24h | Rotation clés + restauration clean |
7. Révision et mise à jour
La présente Politique de Sécurité est révisée :
Zenoia Sàrl — security@zenoiaiq.ch Dernière révision : 23 mars 2026