Sécurité et divulgation responsable
Ce que nous faisons réellement pour protéger vos données, ce qui n’est pas encore en place, et comment nous signaler une vulnérabilité. Pas de badge : BoardAct ne détient aucune certification de sécurité et n’est pas certifié ISO/IEC 27001. La correspondance de nos mesures avec certains contrôles de cette norme, publiée dans le DPA, est indicative : elle ne constitue ni une déclaration de conformité ni un rapport d’audit.
1. Architecture
- Un Espace par client. Chaque client a sa propre instance de l’application et sa propre base de données SQLite, dans un espace de noms Kubernetes dédié. Aucune base n’est partagée entre clients.
- Cloisonnement réseau. Des règles réseau (NetworkPolicies) refusent le trafic d’un client vers un autre ; une sonde d’isolation les vérifie. Un pare-feu sur l’hôte empêche les conteneurs d’atteindre les services du nœud et le réseau d’administration.
- Hébergement en France. Google Cloud, région europe-west9 (Paris). Sauvegardes dans l’Union européenne. Cloudflare en frontal (DNS, proxy, TLS).
- Garde-fous à l’admission. Des politiques d’admission Kubernetes (ValidatingAdmissionPolicy) bornent ce que l’automate de provisionnement des Espaces peut créer. Certaines sont encore en mode observation ; celle qui protège la configuration des Espaces est bloquante.
2. Données
- Chiffrement en transit par TLS sur tout le trafic public ; au repos par le chiffrement par défaut de Google Cloud.
- Sauvegardes continues de chaque base (Litestream) vers un stockage Google Cloud dans l’Union européenne : restauration à un instant donné sur les dernières 24 heures ; les anciennes versions des fichiers de sauvegarde sont effacées après 30 jours. Elles sont écrites avec le compte de service du nœud, aujourd’hui commun aux Espaces hébergés sur ce nœud ; une identité et un dossier de sauvegarde propres à chaque Espace sont en cours de mise en place.
- Fichiers déposés assainis : images ré-encodées, métadonnées (dont position GPS) effacées, SVG contenant du code refusés.
- Réversibilité : export du registre (CSV, JSON) depuis l’application, et copie complète de la base de votre Espace, de ses fichiers et de sa configuration sur simple demande au support, sans frais (données exportables).
- Pas d’IA sur vos données : aucun entraînement, aucun envoi à un fournisseur d’IA (charte IA).
3. Accès et exploitation
- Aucun port d’administration public. SSH, API Kubernetes et outils internes ne sont joignables que par un VPN privé (Tailscale) authentifié.
- Moindre privilège pour les comptes de service (e-mails, provisionnement) ; les sauvegardes passent encore par le compte de service du nœud (voir ci-dessus) ; secrets hors du code.
- GitOps. La plateforme est décrite dans git ; chaque changement du code de l’application ou de l’infrastructure passe par une demande de fusion relue par le fondateur, avec contrôles automatisés (tests, analyse de secrets), avant fusion ; l’intégration continue valide aussi les manifestes et recherche les secrets avec gitleaks. Les demandes de création d’un Espace, générées par notre outil interne, sont fusionnées automatiquement après l’intégration continue, sans relecture humaine. Les images de conteneurs sont référencées par empreinte (digest).
- Journal d’activité dans chaque Espace : qui a fait quoi, quand.
4. Ce qui n’est pas encore en place
- Haute disponibilité : les Espaces tournent sur un nœud unique, dans une seule zone. Une panne interrompt le service jusqu’à sa reprise ; les données sont protégées par les sauvegardes continues.
- Supervision centralisée avec alertes et astreinte : pas encore en place.
- Certification (ISO/IEC 27001, SOC 2) : aucune à ce jour.
- Tests d’intrusion externes : aucun à ce jour.
- Sauvegardes cloisonnées par Espace : identité et dossier de sauvegarde propres à chaque Espace, en cours.
Le détail des mesures, avec leur correspondance indicative aux contrôles de l’annexe A d’ISO/IEC 27001:2022, figure dans l’annexe 2 du DPA. Les sous-traitants sont listés dans l’annexe 3.
5. Politique de divulgation responsable
Vous pensez avoir trouvé une vulnérabilité dans boardact.com, un Espace hébergé ou le code de BoardAct ? Écrivez à [email protected]. Les coordonnées sont aussi publiées dans /.well-known/security.txt (RFC 9116).
Ce que nous vous demandons
- Décrivez la faille et la façon de la reproduire, avec son impact estimé.
- Testez uniquement sur votre propre compte ou un Espace d’essai que vous avez créé. N’accédez pas aux données d’autrui, ne les modifiez pas et ne les conservez pas au-delà du nécessaire pour démontrer la faille ; si vous y accédez par accident, arrêtez-vous et signalez-le.
- Pas de déni de service, de test de charge, d’ingénierie sociale, d’hameçonnage ni d’attaque physique.
- Laissez-nous un délai raisonnable pour corriger avant toute publication : 90 jours par défaut, à ajuster ensemble.
Ce que nous nous engageons à faire
- Accuser réception sous 3 jours ouvrés et vous tenir informé de l’avancement.
- Corriger en priorité selon la gravité, et prévenir les clients concernés si leurs données ont pu être exposées.
- Vous créditer publiquement si vous le souhaitez. Nous n’offrons pas de prime pour le moment.
Cadre de protection
Si vous agissez de bonne foi et dans le respect de cette politique, nous considérons votre recherche comme autorisée, nous n’engagerons pas de poursuites et nous ne déposerons pas plainte contre vous à son sujet. Si un tiers engageait une action contre vous pour une recherche conforme à cette politique, nous ferions savoir qu’elle était autorisée. Cette politique ne peut pas vous autoriser à agir sur les systèmes de nos prestataires (Google Cloud, Cloudflare) ou d’autres tiers, qui ont leurs propres règles.
En France, l’article L2321-4 du Code de la défense permet aussi de signaler une vulnérabilité à l’ANSSI, en toute bonne foi, sans révéler son identité à l’éditeur concerné.
6. Contacts
- Sécurité : [email protected]
- Support : [email protected]
- Questionnaire de sécurité, demande d’audit : [email protected]