EZOUEU
RGPD · Article 32

Mesures techniques et organisationnelles

Cette annexe distingue les contrôles démontrables par le produit des pratiques d’exploitation qui nécessitent une preuve humaine séparée.

Version 2026-08-25Portée : service EZOU.EU

1. Accès des utilisateurs

  • Authentification du compte par magic link signé, à usage unique et expirant après 15 minutes.
  • Sessions signées, HttpOnly, SameSite=Lax, durée maximale de 30 jours.
  • Jetons API aléatoires dont seule l’empreinte SHA-256 est stockée.
  • Mots de passe d’artefact hachés avec Argon2id ; liens d’accès par domaine valables 15 minutes.
  • Policies de workspace évaluées côté serveur lors de la création d’une publication.

Limite actuelle : les routes workspace vérifient l’appartenance et l’offre, mais n’appliquent pas encore une séparation fine des rôles administrateur/membre pour chaque opération. Cette lacune doit être corrigée avant de présenter un RBAC complet.

2. Cloisonnement

  • Chaque artefact est servi sous son propre sous-domaine.
  • Le routage de l’origine d’un artefact précède celui du dashboard et de l’API.
  • Les pages système d’accès vivent sous un chemin réservé qu’un fichier utilisateur ne peut pas occuper.
  • Les fichiers exécutables identifiés par extension et les traversées de chemin sont refusés.
  • Les artefacts reçoivent nosniff, same-origin et, par défaut, une directive noindex que seule une bascule explicite par site peut lever. same-origin signifie que l'adresse d'une page n'est transmise qu'à l'intérieur du site lui-même : aucun site tiers vers lequel une publication renvoie n'en reçoit quoi que ce soit.

3. Confidentialité en transit et secrets

  • TLS automatisé pour le domaine principal et le wildcard des artefacts.
  • Configuration de production conservée hors des binaires, dans un fichier lisible par root:ezou avec le mode 640.
  • Clé Ed25519 persistante obligatoire en production ; une clé éphémère est limitée au développement.
  • Les secrets d’accès et jetons ne sont pas renvoyés après leur création, sauf dans le flux qui doit les remettre à leur titulaire.

Le chiffrement au repos du stockage et de la base relève de la configuration du fournisseur. Aucun justificatif de cette configuration n’est publié dans le dépôt ; il n’est donc pas attesté par cette page.

4. Réduction des données et journalisation

  • Le contenu des fichiers reste dans l’Object Storage et n’est pas copié dans la base de métadonnées.
  • Le scan ne conserve pas les valeurs détectées, seulement catégories, comptes et positions.
  • Les logs HTTP ne conservent pas l’IP complète ni le user-agent brut ; les chemins d’artefact sont généralisés.
  • L’IP de publication est tronquée à l’ingestion puis purgée à J+7 ; les événements de sécurité sont journalisés par réseau tronqué, 30 jours en clair puis en empreinte, 12 mois.
  • Les compteurs de consultation sont bornés à 13 mois, le détail d’une publication (chemins, provenances) étant effacé avec elle. Aucun visiteur unique n’est mesuré, la provenance est réduite au domaine et au chemin avant enregistrement, et l’adresse IP — tronquée d’un octet pour déterminer un pays — n’est conservée à aucun moment.

5. Détection et prévention

  • Scan DLP avant exposition avec modes avertissement et blocage.
  • Signalement d’abus limité en débit et journalisé : il enregistre l’artefact pour revue sans le couper, la quarantaine restant une décision d’exploitation.
  • Limitation de débit sur les authentifications, les déverrouillages par domaine email, les signalements d’abus, les vérifications de domaine et les créations de brouillon par site.
  • Registre fermé d’événements d’audit ; écriture stricte pour l’attestation d’effacement.

Limites actuelles : la création d’une publication n’est pas elle-même bornée par un compteur de débit ; elle l’est par l’obligation de compte et par les plafonds de l’offre — volume total, nombre de sites en ligne et nombre de sites gardés. Les empreintes des fichiers signalés sont consignées au journal d’audit, mais aucun contrôle ne s’y oppose encore à la republication du même contenu.

6. Disponibilité et reprise

L’API et le worker sont deux services systemd ; le worker reprend immédiatement les expirations échues au redémarrage. Le renouvellement TLS est surveillé et peut déclencher une alerte avant expiration.

Limite actuelle : l’architecture comporte une instance de calcul unique et aucun SLA contractuel. Aucun RPO, RTO, test de restauration ou politique de sauvegarde validée n’est publié. Ces éléments doivent être confirmés par l’exploitation avant toute annexe contractuelle chiffrée.

7. Développement, changements et dépendances

  • Compilation reproductible de binaires Go statiques avec chemins retirés.
  • go vet, tests Go, contrôle des claims et vérification du build Astro avant déploiement.
  • Migrations appliquées avant le redémarrage ; contrôles externes des trois surfaces après bascule.
  • Registre des sous-traitants chargé au démarrage et refusé s’il contient une entrée directe hors liste UE/EEE autorisée.

Limites actuelles : le dépôt ne démontre pas une fréquence de mise à jour système, une analyse SAST dédiée, une revue à deux personnes, un inventaire CVE continu ni une procédure formelle de gestion des changements.

8. Accès d’exploitation et personnel

Les binaires s’exécutent sous un utilisateur système ezou sans shell. Le script de déploiement se connecte par défaut en SSH avec un compte root, installe les fichiers puis attribue l’exécution au compte de service.

Limite actuelle : les règles d’habilitation humaine, MFA SSH, revue périodique des accès, départ d’un collaborateur, confidentialité du personnel et journalisation des commandes administrateur ne sont pas démontrées par le dépôt. Elles ne doivent pas être déclarées comme acquises sans preuve d’exploitation.

9. Sous-traitants et incidents

Les prestataires directs, leur rôle et les données concernées sont publiés dans le registre. Le DPA encadre l’assistance et la notification des violations. Le signalement d’un contenu illicite ou d’un abus utilise abuse@ezou.eu.

Limite actuelle : la due diligence des sous-traitants ultérieurs, le registre d’incidents, les exercices et les délais internes d’escalade nécessitent encore une procédure opérée et datée.

10. Révision

Cette annexe est relue lors d’un changement significatif d’architecture, de prestataire ou de contrôle, et au minimum avant toute nouvelle signature de DPA qui s’y réfère. Une nouvelle version doit remplacer la date ci-dessus ; l’ancienne version doit rester archivée avec les contrats auxquels elle s’applique.