Mesures techniques et organisationnelles

Mise à jour : avril 2026. Ces MTO sont régulièrement adaptées à l'état de la technique. Les modifications importantes sont communiquées au client.

1. Confidentialité

Le sous-traitant exploite une entreprise individuelle sans collaborateurs supplémentaires ayant accès aux données. Tous les sous-traitants ultérieurs employés (voir DPA § 7) sont soumis à une obligation de confidentialité. Les propres terminaux (postes de travail des développeurs) sont chiffrés avec FileVault, protégés par Touch ID et des mots de passe forts, et dotés d'un verrouillage d'écran automatique.

2. Pseudonymisation (art. 32 al. 1 lit. a RGPD)

• Dans les journaux, les adresses e-mail ne sont pas référencées en clair, mais exclusivement sous forme de tenant_id ou d'ID utilisateur anonymisé (pino-Log-Redaction).
• Les adresses IP sont hachées pour la limitation de débit au moyen d'un IP_HASH_SALT secret (HMAC-SHA-256) ; les IP d'origine ne sont pas stockées de manière persistante.
• L'IPv4 est normalisée en /32, l'IPv6 en /64, afin de restreindre davantage la traçabilité.

3. Chiffrement (art. 32 al. 1 lit. a RGPD)

3.1 Chiffrement en transit

• Toutes les connexions : HTTPS / TLS 1.2+ (HSTS activé).
• Connexions SMTP vers IONOS via STARTTLS, TLS 1.2+ imposé.
• Connexions à la base de données en interne via socket UNIX ou TLS.

3.2 Chiffrement au repos

• Jetons OAuth (réseaux sociaux) : chiffrement « Envelope Encryption » AES-256-GCM avec des clés versionnées (ENCRYPTION_KEY, ENCRYPTION_KEY_V2…V16). Format : v{N}:iv:tag:ct. Le contexte AAD est lié à tenantId:socialAccountId:platform — toute altération du contexte de la ligne fait échouer le déchiffrement.
• Mots de passe : Argon2id avec les paramètres OWASP 2024 (m=19456 KiB, t=2, p=1). Les hachages bcrypt hérités sont détectés à la connexion et re-hachés de manière transparente en Argon2id.
• Chiffrement des disques VM : l'infrastructure cloud IONOS offre un chiffrement des disques au niveau du fournisseur.
• Secrets : fichiers .env uniquement avec des permissions de fichier 0600, jamais dans le dépôt Git.

4. Contrôle des accès (physique / infrastructure)

• Le système de production fonctionne dans les centres de données IONOS en Allemagne (certifiés ISO 27001, ISO 22301). L'accès physique est sécurisé côté fournisseur (service de sécurité 24/7, biométrie, vidéosurveillance).
• Accès SSH aux serveurs : exclusivement par clé publique (pas de connexion par mot de passe), via un port SSH non standard (2222), avec Fail2ban contre la force brute, et avec application de IdentitiesOnly=yes.
• Le pare-feu (firewalld) limite les connexions entrantes aux ports 2222 (SSH), 80 (redirection HTTP vers HTTPS) et 443 (HTTPS).
• SELinux en mode Enforcing.

5. Contrôle des accès (niveau applicatif)

• Authentification : e-mail + mot de passe (Argon2id) ou SSO (Google / Microsoft / Apple). Jetons de session basés sur JWT avec signatures ES256 et rotation par kid (slot de clé CURRENT + PREVIOUS optionnel pour une rotation sans interruption).
• Rotation des jetons de rafraîchissement : rotation par famille avec une fenêtre de grâce de 10 secondes dans Redis ; ≥ 3 occurrences de grâce du même ancien ID de jeton déclenchent theft_detected et la révocation de la famille.
• Isolation multi-tenant via Postgres Row-Level-Security (RLS) : les connexions applicatives s'exécutent sous le rôle de base de données castloop_app (sans BYPASSRLS). Chaque transaction définit app.tenant_id via SET LOCAL. Les migrations s'exécutent sous castloop_migrator (avec BYPASSRLS). Même une injection SQL ne peut pas sortir de son propre périmètre de tenant (défense en profondeur).
• Limitation de débit : script Lua Redis (vérification+incrément atomique) contre la force brute et les abus.
• CSRF : cookies SameSite=Strict + jetons CSRF.
• CSP : Content-Security-Policy avec nonce par requête et strict-dynamic, empêche le XSS.
• Accès SSH au serveur : uniquement un seul administrateur (le titulaire).

6. Contrôle de la séparation

• Bases de données séparées par projet sur le serveur partagé (propre base de données Postgres castloop avec son propre utilisateur castloop_user, aucun accès aux autres bases de données).
• Les environnements de production, de préproduction et de développement sont séparés les uns des autres ; les secrets de production ne parviennent jamais en préproduction/développement.
• Mollie Key-Strict-Mode : en production exclusivement des clés live_*, en préproduction/développement exclusivement des clés test_* — imposé via le zod superRefine.

7. Intégrité (art. 32 al. 1 lit. b RGPD)

• La RLS empêche la manipulation de données entre tenants (voir 5).
• Les verrous consultatifs Postgres (clé 821912301) encadrent les migrations Drizzle — deux déploiements parallèles ne peuvent pas migrer simultanément.
• Chiffrement des jetons OAuth lié à l'AAD : toute altération du contexte de la ligne fait échouer le déchiffrement (protection de l'intégrité via le tag AES-GCM).
• Idempotence des webhooks Mollie : table dédiée mollie_webhook_events avec une clé d'idempotence (resource_id, payload_hash) (sha256 sur le JSON canonique).
• Validation des entrées côté client et côté serveur (schémas zod).

8. Disponibilité

• Redémarrage automatique pm2 : castloop-api, castloop-worker et castloop-app s'exécutent sous la supervision de pm2 et redémarrent automatiquement en cas de plantage.
• Arrêt en douceur : SIGTERM/SIGINT vident les requêtes HTTP et les jobs BullMQ ; strictement plafonné par SHUTDOWN_TIMEOUT_MS.
• Point de terminaison de contrôle de santé pour la surveillance.
• Sauvegardes par instantanés de VM : gérées par le fournisseur IONOS, rotation quotidienne. Pas de sauvegardes pg_dump autonomes — la couche d'instantanés du fournisseur est jugée suffisante.

9. Résilience

• La limitation de débit protège contre la surcharge.
• BullMQ avec mécanismes de réessai (backoff exponentiel) pour le rendu des clips et la publication sur les plateformes.
• Le balayeur d'orphelins d'ingestion Mollie (intervalle de 60 s, grâce de 120 s, déduplication BullMQ-jobId=eventId) empêche la dérive des paiements en cas de webhooks défaillants.
• Des connexions ioredis indépendantes pour BullMQ vs. le code applicatif empêchent les collisions de préfixes de clés.

10. Restaurabilité (art. 32 al. 1 lit. c RGPD)

• Instantanés de VM à rotation quotidienne (gérés par IONOS).
• Le déploiement via Git + rsync permet un retour arrière vers un commit antérieur en quelques minutes.
• Des migrations idempotentes, encadrées par un verrou consultatif, permettent une ré-exécution sûre en cas de défaillances partielles.

11. Procédure de vérification régulière

• Mises à jour des dépendances (npm audit, Dependabot) au moins une fois par mois.
• Correctifs du système d'exploitation (AlmaLinux) au moins une fois par mois.
• Surveillance des journaux : journaux pino avec masquage des champs sensibles (mots de passe, jetons, JWT, en-têtes authorization/cookie, clés d'API, DATABASE_URL, REDIS_URL, SMTP_PASS).
• Revue interne annuelle des MTO, le cas échéant adaptation à l'état de la technique.
• En cas de besoin / sur demande du client, tests d'intrusion externes.

12. Contrôle de la sous-traitance

• Contrats DPA écrits avec tous les sous-traitants ultérieurs employés (voir DPA § 7), dans la mesure où ceux-ci doivent être qualifiés, au regard du droit de la protection des données, de sous-traitants.
• Voies d'instruction documentées : tableau de bord client, corpus contractuel CGU/DPA, e-mail informel à info@castloop.de.
• Aucun recours à d'autres sous-traitants ultérieurs sans préavis de 30 jours au client (voir DPA § 7).

Mise à jour : avril 2026 · Version 1.0 · Annexe 1 au DPA