Journal des connexions : traçabilité des accès et alerte sur contexte inconnu

[THIOYE97]

Pourquoi

Le TDR exige des traces historisées systématiquement. Aujourd'hui, une tentative d'accès n'est écrite que dans le journal applicatif (stdout de l'hébergeur) : ni requêtable, ni conservée. On ne peut donc répondre ni à « qui s'est connecté, depuis où, et quand », ni voir une série d'échecs se former.

Ce que fait cette PR

Table login_events, alimentée aux quatre points de /auth : connexion réussie, échec avec son motif (unknown_user / bad_password / disabled), déconnexion, prolongation de session. Plus users.last_login_at / last_login_ip.

Deux choix de conception explicités dans le code : pas de clé étrangère vers users — la trace doit survivre à la suppression du compte suspect, et un échec sur une adresse inconnue n'a par définition aucun utilisateur à référencer. Et toute écriture passe par record_safe : un journal en panne dégrade la traçabilité, il ne doit pas fermer l'accès à la plateforme.

Détection de contexte inconnu — une connexion est signalée quand son adresse IP ou son appareil n'a jamais été observé pour ce compte. La première connexion d'un compte l'est donc toujours : c'est précisément l'événement qu'on attend après avoir remis des accès à un tiers.

Alerte par courriel via le relais Brevo déjà en place, envoyée en tâche de fond pour ne pas peser sur le temps de connexion. Les identifiants SMTP n'existaient que sur les services cron : ils sont ajoutés au service web dans render.yaml, faute de quoi l'alerte serait restée inerte en production.

Console de sécurité /security/*, réservée au super-administrateur, en trois lectures complémentaires : qui a tenté d'accéder, qui est connecté maintenant (sessions ouvertes), et qui ne s'est jamais connecté (comptes dormants). Ces endpoints passent délibérément par le rôle d'authentification et non par la session RLS : la politique `tenant_isolation_users` filtre par tenant sans échappatoire super-admin, une session RLS ne verrait qu'un seul tenant.

Correction d'un défaut découvert au passage

`is_super_admin` n'était calculé nulle part : la revendication émise dans l'access token valait toujours `false`. Toutes les portes qui en dépendent étaient donc closes pour tout le monde — bascule de tenant `X-Tenant-Id`, contexte RLS élargi, écrans d'administration.

Elle est désormais lue depuis le rôle `SUPER_ADMIN` de `user_roles`, au login comme au renouvellement (sans quoi un refresh dégradait silencieusement le jeton). Aucun compte ne porte ce rôle par défaut : rien ne change pour les comptes existants. L'attribution se fait par script :

```bash
python -m app.scripts.grant_super_admin conformite@bcrg-guinee.org
python -m app.scripts.grant_super_admin --list
```

Vérifications

• 19 tests ajoutés : 9 unitaires (courriel d'alerte, garde-fous) et 10 d'intégration sur Postgres réel (écriture, contexte inconnu non signalé deux fois, échecs journalisés, fermeture de la console aux non super-admins) ;
• suite complète : 152 tests verts ;
• migration s4_login_events appliquée et annulée sur une base jetable — colonnes, index et GRANT conformes ;
• ruff check propre.

Après fusion

Le preDeployCommand de Render applique alembic upgrade head avant que le nouveau code ne prenne le trafic : la migration se pose seule. Restent à saisir dans le dashboard Render, sur le service web, les variables sync: false : BREVO_SMTP_LOGIN, BREVO_SMTP_KEY, BREVO_FROM_EMAIL, LOGIN_ALERT_TO_EMAIL. Sans elles, le journal enregistre tout normalement — seul l'envoi du courriel est ignoré.

Le front correspondant (page « Journal de connexions ») fait l'objet d'une PR séparée sur le dépôt frontend. L'ordre de déploiement est indifférent.