Sécurité et exploitation #

Cette page décrit les contrôles réellement présents et les responsabilités d’exploitation. Elle ne constitue ni une certification ni une garantie de conformité automatique.

Modèle de confiance #

L’organisation est la frontière multi-tenant. Les repositories filtrent les listes, les contrôleurs recherchent chaque relation dans le tenant courant et une ressource étrangère est généralement masquée par une réponse 404.

Le frontend adapte l’affichage aux rôles, mais l’API Symfony prend toutes les décisions de sécurité.

Authentification #

• mots de passe Argon2id via Sodium ;
• JWT signé d’une durée de 15 minutes ;
• refresh token rotatif en cookie HttpOnly ;
• sessions serveur consultables et révocables ;
• MFA TOTP facultatif avec codes de secours à usage unique ;
• verrouillage progressif après échecs ;
• récupération de compte par jeton à usage unique valable 30 minutes.

Après une réinitialisation de mot de passe, les sessions existantes sont invalidées.

Autorisations #

La hiérarchie générale est SUPER_ADMIN → ADMIN → RISK_MANAGER → VIEWER. Les rôles Auditeur et Responsable d’action héritent de la lecture et ajoutent leurs responsabilités. Les documents appliquent en plus READ, EDIT et MANAGE.

Secrets #

Secrets TOTP, SMTP et OAuth sont chiffrés avec libsodium à partir de APP_SECRET. Une clé API ou un secret webhook n’est affiché en clair qu’à sa création. Les logs et réponses API ne doivent jamais contenir ces valeurs.

En production :

1. générez des secrets uniques ;
2. conservez-les dans un gestionnaire de secrets ;
3. stabilisez et sauvegardez APP_SECRET ;
4. protégez les clés JWT ;
5. organisez la rotation et la révocation.

Journal et détection #

Le journal technique est append-only, tenant-aware et chaîné par empreintes. Il conserve auteur, ressource, date, IP et identifiant de corrélation ; les champs sensibles sont remplacés par [REDACTED].

Surveillez au minimum :

• échecs et verrouillages de connexion ;
• changements de rôles et désactivations ;
• créations/révocations de clés et partages ;
• erreurs du worker et du scheduler ;
• échecs d’intégrité du journal ;
• état /api/health et saturation du stockage.

Documents et partages #

Les fichiers restent dans un volume privé ou un stockage objet configuré. Les liens externes utilisent un jeton aléatoire dont seule l’empreinte est stockée. Les documents sensibles exigent un mot de passe et une expiration ; toute modification révoque les liens existants.

Réponse à incident #

Préservez d’abord les journaux, les horodatages et les sauvegardes. Révoquez sessions, clés ou partages compromis, puis identifiez les organisations et objets affectés. Documentez chronologie, décisions, notification réglementaire et retour d’expérience dans le module Résilience.

Contrôle périodique #

Ces fréquences sont des recommandations à adapter au contexte, pas des exigences officielles du dépôt.

Intégrité du journal d’audit #

La chaîne d’audit append-only reste vérifiable en production : chaque événement porte les éléments d’intégrité nécessaires et les rapports annuels indiquent si une entrée est scellée. Les exports PDF n’exposent ni valeurs métier avant/après ni données techniques du client. Surveillez toute rupture de chaîne, conservez la clé HMAC hors du dépôt et vérifiez l’intégrité après restauration.