Rendre le déploiement Docker correct, et la RLS réellement active
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
This commit is contained in:
17 files changed
+441
-87
No files matched your search
@@ -1,5 +1,7 @@
|
||||
import { afterAll, beforeAll, describe, expect, it } from 'vitest';
|
||||
|
||||
import { adminPrisma } from './admin-db';
|
||||
|
||||
import { IDCC_1517_PARAMETERS } from '@/domain/compliance/idcc1517';
|
||||
import { zonedInstant } from '@/domain/planning/week';
|
||||
|
||||
@@ -13,7 +15,7 @@ import { zonedInstant } from '@/domain/planning/week';
|
||||
* démontre qu'avec deux versions coexistantes en base.
|
||||
*/
|
||||
|
||||
const enabled = (process.env.DATABASE_URL ?? '').length > 0;
|
||||
const enabled = (process.env.ADMIN_DATABASE_URL ?? process.env.DATABASE_URL ?? '').length > 0;
|
||||
const describeIfDb = enabled ? describe : describe.skip;
|
||||
|
||||
const TZ = 'Europe/Paris';
|
||||
@@ -26,7 +28,6 @@ const membershipId = `${suffix}-member`;
|
||||
let agreementFor: typeof import('@/server/compliance/evaluate').agreementFor;
|
||||
let evaluateSchedule: typeof import('@/server/compliance/evaluate').evaluateSchedule;
|
||||
let withTenant: typeof import('@/server/tenant').withTenant;
|
||||
let unscoped: typeof import('@/server/tenant').unscoped;
|
||||
|
||||
/** 10 h de travail : conforme à 10 h, non conforme à 8 h. */
|
||||
function tenHourShift(scheduleId: string, date: string) {
|
||||
@@ -50,9 +51,9 @@ describeIfDb('moteur de conformité en base', () => {
|
||||
({ agreementFor, evaluateSchedule } = await import(
|
||||
'@/server/compliance/evaluate'
|
||||
));
|
||||
({ withTenant, unscoped } = await import('@/server/tenant'));
|
||||
({ withTenant } = await import('@/server/tenant'));
|
||||
|
||||
const db = unscoped();
|
||||
const db = adminPrisma();
|
||||
|
||||
await db.account.create({
|
||||
data: { id: accountId, name: `Compte ${suffix}` },
|
||||
@@ -137,7 +138,7 @@ describeIfDb('moteur de conformité en base', () => {
|
||||
|
||||
afterAll(async () => {
|
||||
if (!enabled) return;
|
||||
await unscoped().account.delete({ where: { id: accountId } });
|
||||
await adminPrisma().account.delete({ where: { id: accountId } });
|
||||
});
|
||||
|
||||
it('choisit la version en vigueur à la date, pas la plus récente', async () => {
|
||||
@@ -208,7 +209,7 @@ describeIfDb('moteur de conformité en base', () => {
|
||||
// Le figeage est en base, pas seulement dans l'application : une paie
|
||||
// antérieure doit rester reproductible même si quelqu'un écrit
|
||||
// directement en SQL.
|
||||
const db = unscoped();
|
||||
const db = adminPrisma();
|
||||
const agreement = await db.collectiveAgreement.findFirst({
|
||||
where: { accountId, version: 1 },
|
||||
});
|
||||
|
||||
Reference in new issue
Block a user