Mesures techniques et organisationnelles de sécurité — plateforme MUNUS+
Traduction de courtoisie du document mis à jour le 30 août 2026. L'original italien est la seule version faisant foi ; en cas de divergence, le texte italien prévaut. Ce document n'est pas versionné par numéro : il porte la date du dernier contrôle sur les systèmes en exploitation, la même que celle de l'italien.
W.F.B. Srl — Via Romolo Gessi 13, 20146 Milan (MI), Italie — N° de TVA IT04724770237 Contact : privacy@wfbservice.it
Ceci est l'annexe technique citée par la politique de confidentialité (§ « Comment nous protégeons vos données »). Elle décrit les mesures adoptées au sens de l'art. 32 du RGPD et constitue, au sens des art. 5.2 et 24 du RGPD, la documentation par laquelle le responsable de traitement démontre avoir adopté des mesures adaptées au risque. Elle est fournie sur demande aux personnes concernées, aux clients et aux autorités, en écrivant à privacy@wfbservice.it. Elle est mise à jour lorsque les mesures changent : la date en bas de page est celle du dernier contrôle sur les systèmes en exploitation.
1. Comment le système est construit
MUNUS+ est une application web et mobile avec une base de données PostgreSQL, hébergée sur des serveurs dédiés de Hetzner Online GmbH (Allemagne et Finlande, Union européenne). Les environnements sont au nombre de deux et séparés sur des machines distinctes : production (données réelles) et recette (données anonymisées). Les documents téléversés résident dans un stockage d'objets privé, dans la même région de l'UE.
Les données de chaque entreprise cliente sont isolées au niveau de chaque ligne de la base. L'isolement n'est pas confié à une liste tenue à la main : il est dérivé automatiquement de la structure des données et vérifié par un contrôle au démarrage, qui empêche le lancement de l'application si la structure change de forme. Un système à l'arrêt est préférable à un système qui sert les mauvaises données.
2. Accès et identité
| Mesure | Comment elle est mise en œuvre |
|---|---|
| Mots de passe | exigences minimales imposées par le système (longueur ≥ 10, majuscules, minuscules, chiffres, caractères spéciaux, aucune répétition consécutive) ; conservés uniquement sous forme d'empreinte cryptographique non réversible (bcrypt) — même les administrateurs ne peuvent pas les lire |
| Second facteur | obligatoire pour tout le personnel interne (administrateurs et opérateurs) : code temporaire sur application d'authentification, standard TOTP RFC 6238 ; disponible et recommandé pour les autres utilisateurs, avec des codes de récupération à usage unique conservés sous forme chiffrée |
| Profilage des accès | quatre rôles distincts, plus des permissions nommées et un périmètre par site : chaque utilisateur ne voit que ce que son rôle et son périmètre autorisent |
| Défense contre les tentatives de connexion | double limite automatique : par origine de la requête et par compte individuel (blocage temporaire après quelques tentatives échouées), efficace aussi contre des tentatives réparties sur de nombreuses adresses |
| Révocation | la désactivation d'un compte prend effet immédiatement : la validité est revérifiée à chaque requête, et pas seulement à la connexion |
| Invitations et récupérations de mot de passe | liens à usage unique et à expiration, invalidés à la première utilisation par une opération atomique (un lien ne peut pas être consommé deux fois) |
3. Protection des communications
Tout le trafic circule sur une connexion chiffrée (HTTPS/TLS) avec des certificats renouvelés automatiquement. Le navigateur reçoit des instructions de sécurité qui imposent l'usage du canal chiffré (HSTS), limitent les origines des contenus exécutables (Content Security Policy) et empêchent l'inclusion de l'application dans des pages tierces.
Les notifications push circulent avec un contenu chiffré selon le standard Web Push : le service de l'appareil qui les délivre n'est pas en mesure de les lire.
4. Traçabilité
Le système tient un journal des opérations qui note qui a créé ou modifié une donnée, quand, et — pour les opérations significatives — le motif déclaré. Les entités significatives ne sont jamais supprimées physiquement : elles sont désactivées et restent reconstituables. Le journal sert à la sécurité et à l'exactitude des données et n'est pas utilisé pour le contrôle de la prestation de travail.
5. Continuité et sauvegardes
| Mesure | Fréquence / durée |
|---|---|
| Copie de la base de données | quotidienne, avec vérification automatique d'intégrité (une copie tronquée n'est pas acceptée) |
| Copie des documents | quotidienne, avec conservation temporaire des fichiers supprimés pour permettre leur récupération |
| Copie externe (fournisseur et pays différents) | quotidienne, chiffrée avant l'envoi en AES-256 : le fournisseur qui la conserve ne peut pas en lire le contenu |
| Rotation | les copies expirent automatiquement ; la suppression d'une donnée se propage avec la rotation naturelle |
| Test de restauration | la restauration a été réellement effectuée et comparée à l'original, et pas seulement planifiée |
6. Surveillance
- Contrôle de santé quotidien sur les deux environnements : espace disque, état des services, expiration des certificats, âge de la dernière sauvegarde, résultat des automatisations.
- Contrôle automatique toutes les 10 minutes : si un service est à l'arrêt, il est redémarré une seule fois et une alerte est envoyée.
- Surveillance externe indépendante, hors de notre infrastructure, qui vérifie l'accessibilité des sites et alerte s'ils ne répondent pas.
- Sentinelles sur les sauvegardes : si une sauvegarde n'est pas effectuée, le silence lui-même déclenche l'alerte. Un outil qui se tait ne dit pas que tout va bien.
7. Sécurité des serveurs
Accès administratif exclusivement par clé cryptographique (authentification par mot de passe désactivée), accès direct de l'utilisateur système privilégié désactivé, clés conservées dans un gestionnaire de secrets et jamais sous forme de fichiers en clair. Double pare-feu (réseau, hors de la machine, et système) avec seulement trois ports publics. Protection automatique contre les tentatives répétées de connexion à distance (fail2ban), active et vérifiée sur les deux environnements. Mises à jour de sécurité du système d'exploitation appliquées périodiquement.
8. Fournisseurs
Les fournisseurs qui traitent des données pour le compte du responsable sont liés par des contrats conformes à l'art. 28 du RGPD et traitent toutes les données dans l'Union européenne : Hetzner Online GmbH (Allemagne), Backblaze Inc. (Pays-Bas, avec des données chiffrées avant l'envoi), Brevo/Sendinblue SAS (France). Aucune donnée n'est cédée à des fins de marketing, de profilage ou d'entraînement de systèmes d'intelligence artificielle.
9. Mesures organisationnelles
Accès aux données limité au personnel autorisé et aux seules finalités du rôle ; environnement de recette alimenté exclusivement avec des données anonymisées (noms remplacés, coordonnées rendues non délivrables) ; documents légaux versionnés, avec enregistrement de qui a pris connaissance de quel texte et quand ; séparation des identifiants entre environnements, de sorte que les comptes de recette ne puissent en aucun cas atteindre les données réelles.
10. Limites déclarées, et que se passe-t-il en cas de violation
Aucun système informatique ne peut être considéré comme sûr à 100 %. La réglementation n'impose pas un résultat absolu : elle impose des mesures adaptées au risque et la capacité de les démontrer — et c'est la raison d'être de ce document.
Les mesures font l'objet d'une révision périodique. Avant l'ouverture du portail à des utilisateurs externes, une vérification de sécurité applicative structurée (test d'intrusion) est programmée, sur les seuls environnements de recette.
En cas de violation de données à caractère personnel, le responsable de traitement :
1. contient l'incident et en reconstitue la portée à l'aide du journal des opérations et des journaux des systèmes ; 2. notifie à l'autorité italienne de protection des données dans les 72 heures à compter du moment où il en a connaissance, lorsque la violation présente un risque pour les droits des personnes concernées (art. 33 du RGPD) ; 3. communique sans délai aux personnes concernées ce qui s'est produit, lorsque la violation entraîne un risque élevé pour leurs droits et libertés (art. 34 du RGPD), en indiquant la nature de la violation, les données concernées, les conséquences probables et les mesures adoptées ; 4. documente chaque violation — y compris celles qui ne sont pas notifiables — dans son propre registre des incidents.
Document mis à jour le 30 août 2026. Les mesures décrites ont été vérifiées sur les systèmes en exploitation à la date indiquée.