1. Objet et champ d’application
Ce plan décrit comment Bungaflow (exploité par Redor AS) détecte, répond et se remet des incidents de sécurité et des violations de données personnelles.
Il s’applique à tous les systèmes, données et personnels impliqués dans l’exploitation de la plateforme Bungaflow.
2. Définitions
- Incident de sécurité :Tout événement compromettant la confidentialité, l’intégrité ou la disponibilité de la plateforme Bungaflow ou de ses données.
- Violation de données personnelles :Une violation de la sécurité entraînant la destruction, la perte, l’altération, la divulgation ou l’accès non autorisé à des données personnelles (RGPD Art. 4(12)).
- Niveaux de gravité : S1 Critique, S2 Majeur, S3 Mineur (tels que définis dans notre SLA).
3. Détection et signalement
- Surveillance automatisée :Suivi des erreurs (Sentry), surveillance de la disponibilité, analyse de sécurité CI/CD (Gitleaks, Dependabot).
- Journalisation :Journaux d’activité pour toutes les modifications de données dans l’application.
- Signalement interne :Les membres de l’équipe signalent immédiatement les incidents suspects au responsable des incidents.
- Signalement externe : Les utilisateurs peuvent signaler des problèmes de sécurité à security@bungaflow.com.
- Divulgation responsable :Nous encourageons les chercheurs en sécurité à signaler les vulnérabilités de manière responsable.
4. Classification des incidents
| Niveau | Impact | Exemples |
|---|
| S1 Critique | Violation de données avec exposition de données personnelles, panne totale du service, exploitation active | Fuite de base de données, compromission d’identifiants, rançongiciel |
| S2 Majeur | Dégradation partielle du service, exposition potentielle de données, vulnérabilité à haut risque | Contournement d’authentification, vulnérabilité d’injection, panne partielle |
| S3 Mineur | Impact limité, aucune exposition de données, vulnérabilité à faible risque | Divulgation d’informations (non personnelles), erreur de configuration mineure |
5. Procédures de réponse
Phase 1 : Identification (0–1 heure)
- Confirmer que l’incident est réel (pas un faux positif)
- Classifier le niveau de gravité
- Désigner un responsable d’incident
- Commencer la documentation dans le journal d’incidents
Phase 2 : Confinement (1–4 heures pour S1/S2)
- Court terme : isoler les systèmes affectés (révoquer les accès, bloquer les IP, désactiver les fonctionnalités)
- Préserver les preuves (journaux, captures)
- Évaluer le rayon d’impact (quelles données/utilisateurs affectés)
Phase 3 : Éradication (4–24 heures pour S1/S2)
- Supprimer la cause (corriger la vulnérabilité, changer les identifiants, mettre à jour les dépendances)
- Vérifier le correctif par une revue de sécurité
- Déployer via le pipeline CI/CD avec vérifications automatisées
Phase 4 : Rétablissement (24–48 heures pour S1/S2)
- Rétablir le fonctionnement normal
- Surveiller toute récurrence
- Vérifier l’intégrité des données
Phase 5 : Revue post-incident (dans les 5 jours ouvrables)
- Analyse des causes profondes
- Chronologie des événements
- Ce qui a bien fonctionné, ce qui peut être amélioré
- Actions correctives et mesures préventives
- Mise à jour de ce plan si nécessaire
6. Notification de violation RGPD
Conformément aux articles 33 et 34 du RGPD :
À l’autorité de contrôle (CNIL)
Dans les 72 heures suivant la prise de connaissance, sauf si la violation n’est pas susceptible d’entraîner un risque pour les personnes. La notification comprend : la nature de la violation, les catégories et le nombre approximatif de personnes concernées, les coordonnées de contact, les conséquences probables, les mesures prises.
Aux personnes concernées
Dans les meilleurs délais lorsque la violation est susceptible d’entraîner un risque élevé pour les droits et libertés des personnes. En langage clair décrivant : la nature de la violation, les coordonnées de contact, les conséquences probables, les mesures prises et recommandations.
Aux responsables du traitement
Si Bungaflow traite des données pour le compte d’un responsable du traitement (voir notre Accord de sous-traitance), le responsable est notifié dans les 48 heures.
7. Communication
- Interne :Le responsable d’incident coordonne toute la communication interne.
- Clients concernés :Notification par e-mail directe pour les incidents S1/S2 affectant leurs données.
- Public :Mise à jour de la page de statut pour les incidents affectant le service.
- Médias : Toutes les demandes médias sont dirigées vers contact@bungaflow.com.
- Aucune divulgation de détails techniques susceptibles de faciliter une exploitation ultérieure.
8. Mesures de sécurité en place (préventives)
- Chiffrement : TLS en transit, AES-256-GCM pour les champs sensibles au repos.
- Authentification :Supabase Auth avec OAuth et magic links (aucun mot de passe stocké).
- Autorisation :Contrôle d’accès basé sur les rôles (Admin/Lite) avec vérification côté serveur.
- En-têtes : HSTS, X-Frame-Options, Content-Security-Policy.
- CI/CD :Linting automatisé, vérification de types, vérification de build et analyse de secrets (Gitleaks) à chaque modification de code.
- Dépendances :Analyse automatique des vulnérabilités via Dependabot.
- Minimisation des données :Seules les données nécessaires sont collectées, suppression en cascade lors de la suppression du compte.
- Vérification des sous-traitants :Tous les sous-traitants disposent d’un DPA et de certifications de sécurité (SOC 2 Type II, ISO 27001).
Pour plus de détails, consultez notre Politique de confidentialité.
9. Rôles et responsabilités
- Responsable d’incident :Coordonne la réponse, prend les décisions de confinement, communique avec les parties prenantes.
- Équipe de développement :Met en œuvre les correctifs techniques, déploie les patchs.
- Protection des données :Évalue les implications RGPD, gère les notifications aux autorités.
Contact : security@bungaflow.com
10. Révision et mises à jour
- Ce plan est révisé au moins une fois par an.
- Mis à jour après chaque incident S1/S2 sur la base des leçons apprises.
- Tous les membres de l’équipe connaissent ce plan.