164 lines
4 KiB
Markdown
164 lines
4 KiB
Markdown
|
# 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](93_MULTI_GROUPE.md).
|
||
|
|
|
||
|
|
## 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é.
|
||
|
|
|