Sécurisation des Accès — NF525
Exigence NF525 : L'accès au logiciel et aux données doit être sécurisé et les actions des utilisateurs tracées.
1. Gestion des utilisateurs
1.1 Modèle utilisateur
Chaque utilisateur du système est enregistré avec :
| Champ | Description |
|---|---|
name |
Nom complet |
email |
Adresse email (optionnelle) |
pin |
Code PIN pour accès POS (non exposé via l'API) |
role |
Rôle déterminant les permissions |
active |
Compte actif/désactivé |
1.2 Rôles et permissions
| Rôle | POS | Admin - Lecture | Admin - Écriture | Audit |
|---|---|---|---|---|
admin |
✅ | ✅ | ✅ | ✅ |
manager |
✅ | ✅ | ✅ | ❌ |
serveur |
✅ | ❌ | ❌ | ❌ |
cuisinier |
⚠️ (KDS) | ❌ | ❌ | ❌ |
barman |
⚠️ (Bar) | ❌ | ❌ | ❌ |
1.3 Authentification
| Contexte | Méthode |
|---|---|
| POS (iPad) | Code PIN 4 chiffres |
| Administration | Email + mot de passe (JWT) |
| API | Bearer token JWT avec expiration |
2. Traçabilité des actions
2.1 Journal d'événements
Chaque action sensible est enregistrée dans audit_logs avec :
- Qui : user_id + user_name
- Quoi : event_type + payload (détail JSON)
- Quand : timestamp UTC
- Intégrité : signature ECDSA chaînée
2.2 Événements tracés
| Événement | Déclencheur |
|---|---|
USER_LOGIN |
Connexion via PIN ou identifiants |
USER_LOGOUT |
Déconnexion |
ORDER_CREATED |
Validation d'une commande |
ORDER_CANCELLED |
Annulation |
ORDER_MODIFIED |
Modification post-validation |
PRODUCT_CREATED |
Ajout d'un produit |
PRODUCT_MODIFIED |
Modification d'un produit |
PRODUCT_DELETED |
Suppression d'un produit |
SETTINGS_CHANGED |
Modification de paramètres |
DAILY_CLOSE |
Clôture journalière |
MONTHLY_CLOSE |
Clôture mensuelle |
EXPORT_GENERATED |
Export fiscal |
3. Sécurité des données
3.1 Code PIN
- Le PIN n'est jamais retourné par l'API (
UserResponseexclut le champpin) - Stocké de manière sécurisée côté serveur
- Utilisé uniquement pour l'authentification POS
3.2 Clés cryptographiques
- Clé privée ECDSA stockée sur le serveur uniquement
- En production : fichier PEM chiffré ou HSM
- Jamais exposée via l'API
3.3 Base de données
- Accès via ORM SQLAlchemy uniquement (pas de SQL brut)
- Paramétrage strict des permissions OS sur le fichier SQLite
- En production : PostgreSQL avec authentification par certificat
4. Sécurité par la conception (Security by Design)
4.1 Intégrité des types et schémas
Le logiciel utilise une architecture "Schema-First" pour prévenir les failles de sécurité liées à la désécurisation des données (type-safety) :
- Validation unifiée : Les entrées API (Backend) et les interfaces (Frontend) sont générées depuis le même fichier JSON Schema.
- Élimination de l'erreur humaine : Aucune transcription manuelle des modèles de données n'est autorisée. Cela garantit que les contrôles de validité (min/max, regex, types) sont rigoureusement identiques sur tous les terminaux.
- Audit simplifiable : L'auditeur peut vérifier la conformité du contrat de données en consultant un répertoire unique (shared/schemas/).