Claude
ef2868b980
Trois problèmes, dont un grave, trouvés en corrigeant un échec de déploiement. **Le compose connectait l'application en superutilisateur PostgreSQL.** Un superutilisateur contourne toute politique de sécurité au niveau ligne, y compris déclarée en FORCE : la seconde couche d'isolation était présente en base et absente des faits. Le README l'interdisait déjà noir sur blanc ; le chemin de déploiement que nous livrons faisait exactement l'inverse. Un script d'initialisation crée désormais un rôle `planflow_app` NOSUPERUSER NOBYPASSRLS, propriétaire de la base — il lui faut ce droit pour migrer, et les politiques sont en FORCE précisément pour s'appliquer aussi au propriétaire. Mesuré : en superutilisateur, deux lignes visibles sans compte courant ; avec le rôle dédié, zéro. Basculer la base de développement sur ce même rôle a révélé le défaut que le superutilisateur masquait : `resolveSession` lisait `Membership`, table filtrée par compte, sans périmètre. Avec la RLS active, plus personne ne pouvait se connecter. La résolution passe maintenant par une porte étroite — une politique qui n'ouvre que les lignes dont l'utilisateur est titulaire, sous `app.user_id` — le temps de trouver le compte, puis repasse par le périmètre ordinaire. La suite de tests traverse enfin la RLS au lieu de la contourner. **Les pièces du dossier salarié n'avaient aucun volume.** Elles étaient écrites dans la couche du conteneur et disparaissaient au premier redéploiement. Une pièce d'identité perdue ne se reconstitue pas. Le reste répond à la demande : Postgres préconfiguré — la base n'étant ni publiée ni attachée au réseau du proxy, ce mot de passe protège d'un conteneur voisin, pas d'Internet — réseau `nginx_default` déclaré externe avec l'application seule dessus, et port publié peu courant. ENCRYPTION_KEY reste la seule variable sans valeur par défaut, et n'en aura pas : elle chiffre le NIR, l'IBAN et les arrêts de travail. Une clé livrée avec l'image serait connue de quiconque lit ce dépôt. Au démarrage, l'application contrôle ses propres privilèges : elle refuse de se lancer si la base porte plus d'un compte, et se contente d'un avertissement s'il n'y en a qu'un — bloquer une installation mono-compte fermerait l'accès de l'entreprise à ses données pour une fuite entre clients qui ne peut pas se produire. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Cr9dkEHwbDgkWPnyGj1Rjv
48 lines
2.2 KiB
Bash
48 lines
2.2 KiB
Bash
# Copier vers .env et renseigner. Ne jamais committer .env.
|
|
|
|
# --- Base de données --------------------------------------------------------
|
|
POSTGRES_USER=planflow
|
|
# Une valeur par défaut existe dans docker-compose.yml : la base n'étant jamais
|
|
# publiée ni attachée au réseau du reverse-proxy, ce mot de passe protège d'un
|
|
# conteneur voisin, pas d'Internet. Le changer reste recommandé.
|
|
POSTGRES_PASSWORD=change-me
|
|
POSTGRES_DB=planflow
|
|
|
|
# Compte de connexion de l'application. Distinct du superutilisateur
|
|
# d'amorçage : un superutilisateur contourne la row-level security, y compris
|
|
# déclarée en FORCE, et l'isolation ne reposerait plus que sur la couche
|
|
# applicative. Créé au premier démarrage par docker/init-app-role.sh.
|
|
APP_DB_USER=planflow_app
|
|
APP_DB_PASSWORD=change-me-aussi
|
|
|
|
# Connexion administrative, utilisée uniquement par le harnais de tests de bout
|
|
# en bout. Inutile en production.
|
|
# ADMIN_DATABASE_URL=postgresql://planflow@localhost:5432/planflow
|
|
|
|
# Utilisée par l'application et par Prisma.
|
|
# En docker-compose l'hôte est `db` ; en développement local, `localhost`.
|
|
DATABASE_URL=postgresql://planflow:change-me@localhost:5432/planflow
|
|
|
|
# --- Chiffrement ------------------------------------------------------------
|
|
# Chiffre au repos les colonnes sensibles exigées par PLAN.md §3.6 :
|
|
# NIR, IBAN, BIC. 32 octets en base64.
|
|
#
|
|
# openssl rand -base64 32
|
|
#
|
|
# Cette clé vit hors de la base : une sauvegarde volée ne doit pas suffire à
|
|
# lire ces colonnes. La perdre rend les données chiffrées irrécupérables —
|
|
# la sauvegarder séparément et documenter sa rotation.
|
|
ENCRYPTION_KEY=
|
|
|
|
# --- Application ------------------------------------------------------------
|
|
APP_URL=http://localhost:9317
|
|
# Port publié sur l'hôte. Peu courant à dessein : le service passe normalement
|
|
# par le reverse-proxy, qui joint le conteneur sur son port 3000.
|
|
APP_PORT=9317
|
|
|
|
# --- Pièces du dossier salarié ----------------------------------------------
|
|
# Répertoire de stockage, chiffré au repos avec ENCRYPTION_KEY.
|
|
# En docker-compose il vaut /data/documents, sur un volume nommé — ne pas le
|
|
# changer sans déplacer le volume, les pièces déjà déposées y resteraient.
|
|
DOCUMENT_STORE=./storage/documents
|