Mesures de sécurité

Cette page décrit les mesures techniques et organisationnelles mises en œuvre pour protéger les données traitées par Cub., au sens de l'article 32 du RGPD. Elle décrit l'état réel du service, non un objectif : elle est mise à jour lorsque les mesures changent.

1. Hébergement

• Serveurs situés dans l'Union européenne, chez IONOS SE.
• Base de données accessible uniquement depuis la machine applicative ; elle

n'est pas exposée sur Internet.

• Séparation des environnements : la production et la préproduction ont des

bases, des jeux de données et des accès distincts.

2. Chiffrement

• En transit : l'intégralité du service est servie en HTTPS, certificats

renouvelés automatiquement. Les connexions aux serveurs de messagerie utilisent TLS.

• Secrets du coffre-fort : chiffrés en base en AES-256-GCM, avec une clé

détenue par l'application et absente du dépôt de code.

• Mots de passe des comptes : jamais stockés en clair ni réversibles, mais

sous forme d'empreinte calculée avec bcrypt.

• Jetons d'accès aux services tiers : chiffrés en base, révocables depuis les

paramètres.

3. Contrôle d'accès

• Accès nominatif ; aucun compte partagé prévu par le service.
• Cloisonnement par organisation : une requête ne peut atteindre que les données

de l'organisation active de l'utilisateur.

• Rôles et permissions par fonctionnalité, définis par l'administrateur de

l'organisation.

• Portail client et formulaires publics : jetons non devinables, à durée limitée,

révocables ; l'absence de jeton valide donne « introuvable » plutôt qu'« accès refusé », pour ne rien révéler de l'existence d'une ressource.

• Sessions signées, cookies `HttpOnly` et `SameSite`, expiration automatique.

4. Journalisation et traçabilité

• Consultation d'un secret du coffre-fort : journalisée, avec l'auteur et

l'horodatage.

• Signature électronique : conservation de l'horodatage, de l'adresse IP et de

l'empreinte du document, comme éléments de preuve.

• Journaux d'accès du serveur web conservés douze mois.
• Les adresses IP des répondants aux formulaires ne sont jamais stockées en

clair, seulement sous forme d'empreinte.

5. Limitation des abus

• Limitation de débit sur les points d'entrée publics : envoi de formulaire,

authentification, portail client.

• Validation systématique des données côté serveur : la validation du navigateur

n'est jamais tenue pour acquise.

• En-têtes de sécurité : `X-Content-Type-Options`, `X-Frame-Options`,

`Referrer-Policy`.

• Dépendances suivies et mises à jour ; les correctifs de sécurité sont appliqués

sans attendre le cycle de publication.

6. Sauvegardes

• Sauvegarde complète et automatique de la base, quotidienne, compressée et

stockée sur le serveur avec un accès restreint à l'administrateur système.

• Sauvegarde supplémentaire systématique avant chaque mise en production,

avant toute migration de schéma.

• Les sauvegardes sont conservées par rotation ; les plus anciennes sont purgées

automatiquement.

• Un déploiement conserve le build précédent le temps de vérifier le nouveau, ce

qui permet un retour arrière en quelques secondes.

7. Développement

• Code versionné, revue avant mise en production.
• Suite de tests automatisés exécutée avant chaque publication.
• Aucun secret dans le dépôt : la configuration sensible vit dans des fichiers

d'environnement à accès restreint sur le serveur.

• Les migrations de schéma sont vérifiées puis appliquées de façon contrôlée,

après sauvegarde.

8. Organisation

• Accès à la production limité aux personnes qui en ont besoin, nominatif.
• Obligation de confidentialité contractuelle pour toute personne y accédant.
• Revue des accès lors de tout changement de fonction ou départ.

9. Gestion des incidents

Une violation de données est traitée selon la procédure interne prévue à cet effet : qualification, confinement, notification au client dans les 48 heures, assistance à la notification à la CNIL dans les 72 heures et, si le risque est élevé, information des personnes concernées.

Pour signaler une vulnérabilité, écrivez à info@mycub.fr avec les éléments permettant de la reproduire. Aucune poursuite ne sera engagée contre une personne qui signale de bonne foi une faille sans exploiter, exfiltrer ni détruire de données, et qui laisse un délai raisonnable pour la corriger avant toute divulgation.

10. Limites assumées

• Le service ne fait pas l'objet d'une certification ISO 27001 ni d'un

hébergement de données de santé (HDS) : il n'est pas destiné à recevoir des données de santé.

• Aucun engagement de disponibilité supérieur à celui des

conditions générales de vente n'est pris ici.

• La sécurité des postes des utilisateurs et la qualité de leurs mots de passe

relèvent du client.