Annexe Sécurité — EduRegie
Annexe à l'accord de sous-traitance : mesures techniques et organisationnelles concrètes (art. 32 RGPD).
Mesures techniques
| Mesure | Statut | Explication |
|---|---|---|
| Séparation des locataires par école | Mise en œuvre | Sécurité au niveau des lignes (RLS) dans PostgreSQL/Supabase ; chaque requête est automatiquement limitée au school_id = current_school_id() de l'utilisateur connecté (voir supabase/migrations/0002_auth_and_rls.sql) |
| Chiffrement en transit | Mise en œuvre | HTTPS/TLS pour tout le trafic vers le tableau de bord, les webhooks n8n et Supabase |
| Chiffrement au repos | Mise en œuvre | Chiffrement au repos standard du fournisseur d'hébergement Supabase/PostgreSQL |
| Authentification | Mise en œuvre | Supabase Auth (e-mail/mot de passe) ; pas d'auto-inscription publique — les comptes ne sont créés que sur invitation d'un administrateur d'école |
| MFA pour les rôles sensibles | Mise en œuvre et appliquée | Authentification TOTP obligatoire (application d'authentification) pour les rôles RH et administrateur d'école ; toute personne non encore inscrite est directement redirigée vers la page d'inscription lors de la connexion (voir middleware.ts et /dashboard/beveiliging) |
| Rôles à moindre privilège | Mise en œuvre | Navigation basée sur les rôles et contrôle des rôles côté serveur dans le tableau de bord (employé/opérateur/planificateur/chef d'équipe/RH/remplaçant/admin) ; voir components/DashboardNav.tsx et les contrôles de rôle par page |
| Journalisation des audits | Mise en œuvre | Table audit_log, alimentée par SF 21 - EduRegie Audit & Compliance |
| Séparation des rôles de service | Mise en œuvre | Les workflows n8n utilisent une clé de rôle de service qui écrit en dehors de la RLS ; chaque requête y filtre elle-même sur school_id (voir l'explication en bas de 0002_auth_and_rls.sql) |
| Environnements séparés | Recommandée | Utiliser un projet Supabase distinct (ou au minimum une école de démonstration distincte avec demo_mode = true) pour les démonstrations, séparé d'un futur environnement de production éventuel |
| SSO (Microsoft Entra ID / Google Workspace / SURFconext) | Pas encore mise en œuvre | Prévue en phase 3 de la feuille de route (docs/mvp-roadmap.md) |
Mesures organisationnelles
- Aucune possibilité de saisie de données médicales dans le portail utilisateur habituel ; les textes de l'interface avertissent explicitement les utilisateurs à ce sujet (voir
/dashboard/ziek-melden). - L'accès à la clé de rôle de service Supabase et à l'environnement n8n est limité au fournisseur (Elhoucine Automation) et, après livraison, au(x) administrateur(s) d'école désigné(s) par l'école.
- Les nouveaux utilisateurs ne sont ajoutés que via une invitation explicite d'un administrateur d'école (pas d'auto-inscription) — voir
app/api/internal/gebruikers/uitnodigen/route.ts. - Le mode démo (
demo_mode = truedans les paramètres de l'école) empêche l'envoi de notifications à de vrais membres du personnel ou élèves tant que l'école n'a pas donné son accord par écrit — voirdocs/productie-runbook.md. - Voir
docs/incidentprocedure.mdpour les étapes à suivre en cas de (suspicion de) violation de données.
Ce qui manque encore pour un niveau de sécurité de production complet
- Revue de sécurité/test d'intrusion indépendant avant la première livraison de production payante à une école.
- Exercice formel de réponse aux incidents avec l'équipe.
- Extension de la MFA au rôle de planificateur si l'école le souhaite — actuellement délibérément limitée aux RH/admin, les rôles ayant la vue la plus large sur les données du personnel.