# Sécurité & RGPD — Inscriptions en ligne VBPV Ce document fait suite à l'audit avec l'expert cybersécurité. Il décrit ce qui est **déjà en place** dans la maquette, ce qui est **obligatoire avant mise en production**, et l'analyse de la piste « stockage tiers Google Drive/Sheets chiffré ». --- ## 1. Mesures déjà en place dans la maquette | Mesure | Détail | |---|---| | **Anti-robots** | Captcha arithmétique servi par le serveur (jeton à usage unique, 30 min) + champ-piège invisible (honeypot) sur l'envoi du formulaire. | | **Limitation de débit** | 12 requêtes/minute/IP maximum sur l'envoi de fiches et le dépôt de documents (anti-spam, anti-flood). | | **Chiffrement au repos des pièces** | Les documents déposés (certificats médicaux, pièces d'identité — données sensibles) sont chiffrés en **AES-256-GCM** avant écriture disque. Clé générée au premier lancement dans `data/.cle-chiffrement` (mode 600), surchargée par la variable d'environnement `CLE_CHIFFREMENT`. Déchiffrement uniquement à la volée pour l'admin. | | **Consentement RGPD** | Case obligatoire dans le formulaire (finalité, durée de conservation, droits d'accès/rectification/suppression, contact). Refus côté serveur si absent. Date du consentement stockée avec la fiche. | | **Limitation des fichiers** | 1 champ par type de pièce, 2,5 Mo max/fichier, formats restreints (PDF/images), noms de fichiers assainis, statut de validation par pièce côté admin. | | **En-têtes HTTP de sécurité** | `Content-Security-Policy`, `X-Content-Type-Options: nosniff`, `X-Frame-Options: SAMEORIGIN`, `Referrer-Policy`. | | **Droit à l'effacement** | Suppression d'une inscription = suppression des règlements, des mails journalisés et des fichiers déposés (route `DELETE`). | | **Minimisation** | Seules les données nécessaires à la licence sont collectées ; le questionnaire de santé est marqué confidentiel et réservé au secrétariat. | ## 2. Obligatoire AVANT toute mise en production 1. **HTTPS partout** (certificat Let's Encrypt) — jamais de formulaire de données personnelles en HTTP clair. 2. **Protéger l'espace admin par une authentification** (mot de passe fort + session, ou à minima Basic Auth derrière HTTPS). Aujourd'hui `/admin.html` et les API d'administration sont ouvertes : c'est acceptable pour une maquette locale, pas pour un serveur exposé. 3. **Captcha industriel** : le support **Google reCAPTCHA v2** est intégré et s'active simplement en définissant deux variables d'environnement : ```bash # 1. Créer les clés sur https://www.google.com/recaptcha/admin/create # (type « reCAPTCHA v2 — case à cocher », domaines : volley-vienne38.fr + localhost pour tester) # 2. Lancer le serveur avec : RECAPTCHA_SITE=votre_cle_site RECAPTCHA_SECRET=votre_cle_secrete node server.js ``` Sans ces variables, le captcha arithmétique maison reste actif (pratique en local). ⚠️ RGPD : reCAPTCHA transmet des données (IP, cookies) à Google — il faut le mentionner dans la politique de confidentialité ; la CNIL considère qu'il requiert le consentement cookies. **Cloudflare Turnstile** (gratuit, sans cookie) est l'alternative la plus propre juridiquement — l'intégration serait identique (mêmes deux variables, même appel de vérification). 4. **Sauvegardes chiffrées** de `data/` + de la clé (stockées séparément !). 5. **Registre des traitements** (obligation RGPD de l'association) : finalité « gestion des licences », base légale « exécution du contrat / intérêt légitime », durée « saison + 1 an », destinataires « secrétariat, FFVolley ». 6. **Mentions d'information** sur la page d'accueil (politique de confidentialité). 7. Purge automatique des dossiers en fin de saison (à planifier — cron annuel). ## 3. Piste « stockage tiers » : Google Sheets + Google Drive chiffrés ### Architecture proposée ``` Formulaire → Serveur club (Node) ├─ chiffre les données (AES-256-GCM, clé locale au club) ├─ API Google Sheets : 1 ligne par inscription (champs chiffrés, │ sauf un identifiant de dossier opaque type VBPV-2627-XXXX) └─ API Google Drive : pièces jointes chiffrées (le .bin chiffré, jamais le PDF/JPG en clair) Admin ← Serveur club : lit Sheets/Drive via API, déchiffre en mémoire, affiche. ``` - **Compte de service Google** (Workspace ou compte association) + partage d'un dossier Drive dédié ; quotas gratuits largement suffisants pour ~250 licenciés. - **Chiffrement « fait maison » côté serveur** : la fonction existe déjà dans la maquette (`chiffrerDocument` / `dechiffrerDocument`, AES-256-GCM). Le même module s'applique aux valeurs poussées dans Sheets (chiffrer chaque champ sensible, encoder en base64). - La clé de déchiffrement **ne quitte jamais le serveur du club** : Google ne voit passer que des blobs illisibles. - Un adaptateur `stockage-drive.js` peut remplacer le stockage local actuel sans toucher au reste du code (mêmes fonctions lire/écrire/supprimer). ### Bénéfices réels - Plus de fichiers sensibles sur le serveur web (surface d'attaque réduite) ; - sauvegarde/redondance gérées par Google ; - si le Drive fuite, les données sont inexploitables sans la clé du club. ### ⚠️ Limites juridiques à connaître (important) Externaliser **ne transfère pas la responsabilité** : au sens du RGPD, le club reste **responsable de traitement** ; Google n'est qu'un **sous-traitant** (art. 28 — le Data Processing Addendum de Google doit être accepté). Le chiffrement côté club est précisément ce qui rend ce montage sain : Google ne peut pas lire les données. À prévoir : - activer la **localisation UE** des données quand c'est possible ; - documenter le montage dans le registre des traitements ; - la clé devient le point critique : la perdre = perdre les dossiers ; la faire fuiter = perdre la protection. Sauvegarde de la clé hors ligne (coffre / gestionnaire de mots de passe du bureau). ### Alternative plus simple à considérer Un VPS français/UE (OVH, Scaleway…) avec la base SQLite actuelle + disque chiffré + sauvegardes chiffrées offre le même niveau de protection avec moins de pièces mobiles, et sans dépendance à un compte Google personnel. La piste Drive est pertinente surtout si le club veut éviter d'administrer un serveur de stockage. ## 4. Qui est responsable de quoi (en clair) - **Le club (association)** : responsable de traitement RGPD dans tous les cas — c'est lui qui décide de la collecte. Les mesures ci-dessus (minimisation, consentement, chiffrement, durée de conservation, registre) sont sa protection. - **Le développeur bénévole** : n'est pas responsable de traitement ; bonne pratique = tout documenter (ce fichier), ne jamais conserver de copie des données, remettre la clé au bureau du club. - En cas de doute : la CNIL publie un guide dédié aux associations (cnil.fr → « associations »).