4 KiB
Sécurité et confidentialité
Statut: référence opérationnelle
Public: exploitants, sysadmin, mainteneurs, exécutifs
Dernière révision: 2026-06-01
Principes
L'application doit minimiser les données personnelles, isoler les groupes et permettre au groupe de comprendre qui a changé quoi. Le journal ne sert pas à surveiller les membres; il sert à protéger l'historique et corriger les erreurs.
Authentification
- Connexion par groupe, identifiant/courriel et PIN à 4 chiffres.
- PIN haché côté serveur.
- Session JWT.
- Durée normale: 30 jours.
- Durée avec
Se souvenir de moi: 90 jours. - Un membre inactif ne peut pas se connecter.
Sysadmin
Le compte Sysadmin:
- existe au déploiement initial;
- a tous les accès;
- ne doit pas être supprimé;
- peut impersonifier un membre;
- peut gérer les groupes;
- doit être utilisé avec retenue.
Le PIN initial 0000 doit être changé ou encadré selon la politique du groupe après installation réelle.
Impersonification
Quand Sysadmin agit comme un autre membre, le jeton conserve l'identité sysadmin dans adm. La journalisation peut donc distinguer:
- le membre au nom duquel l'action est faite;
- le sysadmin qui a causé l'action.
Autorisations
Les accès ordinaires viennent:
- des postes actifs;
- des permissions de modules associées aux postes;
- de la catégorie
executif.
Le frontend masque les modules non visibles, mais le backend doit toujours vérifier l'autorisation.
Isolation multi-groupe
Chaque lecture ou modification doit être bornée au groupe_id du membre courant. Une route qui reçoit un identifiant doit vérifier l'appartenance de l'objet au groupe courant.
Voir Multi-groupe.
Journalisation
Sont journalisées automatiquement:
- méthodes
POST,PUT,PATCH,DELETE; - routes sous
/api/; - actions réussies;
- membre;
- sysadmin d'origine si impersonification;
- chemin;
- statut HTTP;
- IP;
- user-agent;
- paramètres sûrs.
L'historique métier peut conserver:
- domaine;
- objet;
- ancienne valeur;
- nouvelle valeur;
- raison automatique;
- membre responsable.
Données personnelles
Données membres typiques:
- prénom;
- nom optionnel;
- téléphone;
- identifiant/courriel;
- date d'abstinence optionnelle;
- PIN haché;
- préférences de notifications.
Le prénom est conservé lors du droit à l'oubli afin que l'historique reste lisible.
Droit à l'oubli
Le droit à l'oubli ne supprime pas l'enregistrement du membre. Il anonymise:
- nom;
- téléphone;
- courriel ou identifiant de connexion;
- date d'abstinence;
- PIN;
- préférences;
- abonnements push.
Sont conservés:
- ID technique;
- prénom;
- relations historiques.
Notifications push
Les notifications sont opt-in. Le membre choisit les catégories. Le navigateur peut refuser ou bloquer les notifications.
Les catégories applicatives sont:
- gouvernance;
- trésorerie;
- membres;
- postes;
- rencontres;
- littérature;
- événements;
- système.
Secrets
Les secrets ne doivent pas être committés en clair.
Secrets principaux:
- mot de passe PostgreSQL applicatif;
- secret JWT;
- variables de notification push si utilisées;
- accès SSH Ansible.
Le fichier ansible/group_vars/vault.yml doit être chiffré avec Ansible Vault lorsqu'il contient des valeurs réelles.
Sauvegardes
Les sauvegardes PostgreSQL doivent être protégées comme des données personnelles. Elles contiennent l'historique complet du groupe.
Points de fracture
Risques principaux:
- mauvais groupe sélectionné à la connexion;
- utilisation prolongée de
Sysadmin; - permissions trop larges accordées à un poste;
- sauvegardes non testées;
- perte d'accès au serveur;
- conflit social autour du journal;
- absence de reprise papier.
Mesures:
- vérifier régulièrement les permissions;
- imprimer ou savoir produire les rapports clés;
- tester les sauvegardes;
- expliquer le rôle du journal;
- garder l'application comme outil, pas comme autorité.