generated from gilles/template-webapp
227 lines
8.7 KiB
Markdown
227 lines
8.7 KiB
Markdown
# ADR-0004 — Pas d'authentification (réseau local uniquement)
|
|
|
|
- Statut : accepted
|
|
- Date : 2026-01-27
|
|
|
|
---
|
|
|
|
## Contexte
|
|
|
|
HomeStock est une application web self-hosted destinée à un usage mono-utilisateur sur un réseau local domestique. La question de la sécurité d'accès se pose :
|
|
|
|
**Contraintes du projet** :
|
|
- **Déploiement** : Réseau local 10.0.0.0/22, pas d'exposition Internet prévue
|
|
- **Utilisateurs** : Mono-utilisateur (propriétaire du domicile)
|
|
- **Données** : Inventaire personnel, factures (non sensibles au sens RGPD)
|
|
- **Accès physique** : Réseau domestique, appareils de confiance uniquement
|
|
|
|
**Questions à résoudre** :
|
|
1. Faut-il implémenter un système d'authentification (login/password) ?
|
|
2. Si oui, quel niveau de sécurité est nécessaire ?
|
|
3. Quels sont les risques réels d'un accès non authentifié sur réseau local ?
|
|
|
|
L'authentification ajoute de la complexité (gestion sessions, hash passwords, UI login) et peut dégrader l'expérience utilisateur (saisie répétée de credentials) pour un bénéfice de sécurité potentiellement faible dans ce contexte.
|
|
|
|
---
|
|
|
|
## Décision
|
|
|
|
**Nous ne déployons PAS de système d'authentification pour le MVP.** L'application est accessible librement sur le réseau local sans login ni password.
|
|
|
|
### Justification
|
|
1. **Périmètre réseau contrôlé** : Réseau domestique 10.0.0.0/22, tous les appareils sont de confiance
|
|
2. **Pas d'exposition Internet** : Application non accessible depuis l'extérieur, pas de port forwarding
|
|
3. **Mono-utilisateur** : Pas de besoin de gestion de sessions ou de rôles
|
|
4. **Simplicité UX** : Accès immédiat à l'application, pas de friction login
|
|
5. **Données non critiques** : Inventaire domestique et factures, pas de données bancaires ou médicales
|
|
|
|
### Périmètre de sécurité
|
|
- ✅ **Réseau local uniquement** : Application bind sur IP privée, pas 0.0.0.0
|
|
- ✅ **HTTPS optionnel** : TLS pour chiffrement en transit si certificat local disponible
|
|
- ✅ **Firewall** : Ports fermés en dehors du réseau local (configuration routeur)
|
|
- ❌ **Pas de login/password** : Accès direct à l'application
|
|
- ❌ **Pas de sessions** : Pas de gestion de tokens ou cookies d'authentification
|
|
- ❌ **Pas de RBAC** : Pas de rôles ou permissions (mono-utilisateur)
|
|
|
|
### Configuration réseau recommandée
|
|
```yaml
|
|
# docker-compose.yml
|
|
services:
|
|
backend:
|
|
ports:
|
|
- "10.0.0.X:8000:8000" # Bind IP privée uniquement, pas 0.0.0.0:8000
|
|
environment:
|
|
- ALLOWED_HOSTS=10.0.0.0/22 # Whitelist réseau local
|
|
```
|
|
|
|
---
|
|
|
|
## Alternatives considérées
|
|
|
|
### 1. Authentification basique (login/password)
|
|
**Description** : Page de connexion avec username/password, session cookie
|
|
|
|
**Avantages** :
|
|
- ✅ Protection contre accès non autorisé sur réseau local
|
|
- ✅ Traçabilité des accès (logs)
|
|
- ✅ Possibilité multi-utilisateurs future facilitée
|
|
|
|
**Inconvénients** :
|
|
- ❌ Complexité additionnelle (hash passwords, sessions, CSRF, refresh tokens)
|
|
- ❌ UX dégradée (saisie credentials à chaque accès)
|
|
- ❌ Gestion mot de passe oublié nécessaire
|
|
- ❌ Sécurité illusoire si appareil compromis (cookies volés)
|
|
|
|
**Verdict** : ❌ **Rejeté pour MVP** - Bénéfice limité sur réseau local de confiance, complexité injustifiée
|
|
|
|
### 2. Authentification par IP (whitelist)
|
|
**Description** : Autoriser uniquement certaines IPs du réseau local
|
|
|
|
**Avantages** :
|
|
- ✅ Simple à implémenter (middleware FastAPI)
|
|
- ✅ Pas d'UI login
|
|
|
|
**Inconvénients** :
|
|
- ❌ Gestion fastidieuse des IPs autorisées
|
|
- ❌ DHCP complique le suivi (IPs dynamiques)
|
|
- ❌ Pas de granularité utilisateur
|
|
|
|
**Verdict** : ❌ **Rejeté** - Complexité sans bénéfice majeur, réseau déjà isolé
|
|
|
|
### 3. Authentification par certificat client (mTLS)
|
|
**Description** : Certificats X.509 pour authentifier les appareils
|
|
|
|
**Avantages** :
|
|
- ✅ Sécurité forte
|
|
- ✅ Pas de password à mémoriser
|
|
|
|
**Inconvénients** :
|
|
- ❌ Complexité extrême (PKI, distribution certificats)
|
|
- ❌ Configuration browser complexe
|
|
- ❌ Totalement surdimensionné pour le cas d'usage
|
|
|
|
**Verdict** : ❌ **Rejeté** - Overkill absolu
|
|
|
|
### 4. Pas d'authentification (notre choix)
|
|
**Description** : Accès libre sur réseau local
|
|
|
|
**Avantages** :
|
|
- ✅ Simplicité maximale (pas de code auth)
|
|
- ✅ UX optimale (accès instantané)
|
|
- ✅ Maintenance réduite
|
|
- ✅ Adapté au contexte mono-utilisateur réseau local
|
|
|
|
**Inconvénients** :
|
|
- ⚠️ Accès libre pour tout appareil sur réseau local
|
|
- ⚠️ Pas de traçabilité utilisateur
|
|
- ⚠️ Si exposition Internet accidentelle = vulnérabilité
|
|
|
|
**Verdict** : ✅ **Choisi** - Solution adaptée au contexte avec mitigations appropriées
|
|
|
|
---
|
|
|
|
## Conséquences
|
|
|
|
### Positives
|
|
1. **Simplicité code** : Pas de code d'authentification, sessions, CSRF protection
|
|
2. **UX fluide** : Accès immédiat, pas de friction login
|
|
3. **Pas de gestion passwords** : Pas de hash, reset password, rotation
|
|
4. **Maintenance réduite** : Pas de vulnérabilités auth à monitorer (OWASP Top 10)
|
|
5. **Performance** : Pas de vérification session sur chaque requête
|
|
|
|
### Négatives et risques
|
|
1. **Exposition accidentelle Internet** : Si port forwarding activé par erreur → accès public
|
|
2. **Appareil compromis sur réseau** : Malware sur laptop/smartphone pourrait accéder à l'app
|
|
3. **Visiteurs réseau** : Invités connectés au WiFi domestique peuvent accéder à l'app
|
|
4. **Pas de traçabilité** : Impossible de savoir qui a modifié/supprimé des données
|
|
|
|
### Mitigations implémentées
|
|
1. **Bind IP privée uniquement** : Backend écoute sur 10.0.0.X:8000, pas 0.0.0.0
|
|
2. **Firewall routeur** : Ports 8000/5173 fermés en WAN, ouverts LAN uniquement
|
|
3. **HTTPS optionnel** : Certificat auto-signé pour chiffrement en transit
|
|
4. **Logging applicatif** : Logs des actions (créer/modifier/supprimer items) avec IP source
|
|
5. **Backup régulier** : Scripts de backup pour récupération en cas d'actions malveillantes
|
|
6. **Documentation claire** : Avertissement dans README sur importance isolation réseau
|
|
|
|
### Mitigations à envisager (post-MVP)
|
|
1. **Mode "invité" simple** : Code PIN basique si besoin de partager l'accès temporairement
|
|
2. **Alerte exposition** : Check au startup si l'app est accessible depuis Internet (API externe)
|
|
3. **Read-only mode** : Mode lecture seule pour appareils moins fiables
|
|
|
|
---
|
|
|
|
## Impacts techniques
|
|
|
|
### Code simplifié
|
|
Pas de code d'authentification signifie :
|
|
- Pas de modèle `User` en base
|
|
- Pas de hash passwords (bcrypt, argon2)
|
|
- Pas de gestion sessions/tokens
|
|
- Pas de middleware CSRF protection
|
|
- Pas d'endpoints `/login`, `/logout`, `/register`
|
|
- Pas d'UI login/signup
|
|
|
|
### Configuration Docker
|
|
```yaml
|
|
# docker-compose.yml
|
|
services:
|
|
backend:
|
|
ports:
|
|
- "10.0.0.50:8000:8000" # IP privée fixe uniquement
|
|
environment:
|
|
- ALLOWED_ORIGINS=http://10.0.0.50:5173,http://localhost:5173
|
|
- CORS_ALLOW_CREDENTIALS=false # Pas de cookies
|
|
```
|
|
|
|
### Logging renforcé
|
|
Même sans auth, logger les actions pour traçabilité :
|
|
```python
|
|
# Exemple log
|
|
logger.info(
|
|
"Item created",
|
|
extra={
|
|
"item_id": item.id,
|
|
"item_name": item.name,
|
|
"source_ip": request.client.host,
|
|
"user_agent": request.headers.get("user-agent")
|
|
}
|
|
)
|
|
```
|
|
|
|
### Évolution future
|
|
Si exposition Internet devient nécessaire (accès depuis extérieur) :
|
|
1. **Ajouter authentification** : Login simple (username/password) + session cookie
|
|
2. **Reverse proxy avec auth** : Traefik BasicAuth ou OAuth2 Proxy
|
|
3. **VPN** : Accès via WireGuard/Tailscale (recommandé)
|
|
4. **Cloudflare Access** : Zero-trust avec auth externe
|
|
|
|
---
|
|
|
|
## Notes
|
|
|
|
Cette décision est **contextuelle** et adaptée à HomeStock :
|
|
- ✅ Réseau local domestique contrôlé
|
|
- ✅ Mono-utilisateur
|
|
- ✅ Données non critiques
|
|
|
|
Elle serait **inappropriée** pour :
|
|
- ❌ Application exposée sur Internet
|
|
- ❌ Multi-utilisateurs
|
|
- ❌ Données sensibles (bancaires, médicales, secrets)
|
|
- ❌ Environnement professionnel
|
|
|
|
**Analogie** : C'est comme ne pas mettre de serrure sur la porte de sa chambre dans sa propre maison (réseau local) vs mettre une serrure sur la porte d'entrée (exposition Internet).
|
|
|
|
Si le contexte change (exposition Internet, ajout utilisateurs), cette décision devra être revisitée et l'authentification ajoutée. L'architecture modulaire (ADR-0002) facilite cet ajout futur sans refonte majeure.
|
|
|
|
**Principe appliqué** : "Security proportionate to risk" - Ne pas sur-sécuriser quand le risque est faible et contrôlé.
|
|
|
|
---
|
|
|
|
**Contributeurs** : Gilles (décideur) + Claude Code (architecte)
|
|
|
|
**Avertissement important** : Cette configuration est sécurisée UNIQUEMENT si le réseau local est isolé d'Internet. Vérifier régulièrement que :
|
|
1. Aucun port forwarding n'est configuré sur le routeur
|
|
2. Aucun service de tunnel (ngrok, etc.) n'est actif
|
|
3. Le firewall du routeur est correctement configuré
|