Périmètre
EZOU.EU publie des artefacts statiques servis sous une origine dédiée. Le service n’exécute pas de backend utilisateur, ne fournit pas de base de données applicative et ne conserve pas de secret serveur pour le compte du code publié.
Architecture directe
- Instance Scaleway en région parisienne : API, dashboard, serving, scan et worker.
- Scaleway Object Storage : fichiers publiés.
- Scaleway PostgreSQL managé : comptes, métadonnées, policies et audit.
- OVH : registrar et zone DNS ; CertMagic utilise DNS-01 pour le certificat wildcard.
- Brevo : emails transactionnels. Mollie : paiement des abonnements.
- Aucun CDN actif dans l’architecture déclarée.
Isolation et contrôle d’accès
Le routeur reconnaît une origine d’artefact avant le dashboard et l’API, afin qu’un contenu utilisateur ne puisse pas atteindre le control plane depuis son propre sous-domaine. Les artefacts restent non indexables par défaut.
Les accès proposés sont l’URL non listée, le mot de passe haché avec Argon2id et le domaine email vérifié par lien temporaire. Les cookies de session et de déverrouillage sont HttpOnly, SameSite=Lax et limités à leur origine.
Transport et clés
Le TLS est terminé par le binaire avec renouvellement automatisé du certificat. Le site marketing ajoute HSTS lorsqu’une connexion TLS fiable est détectée. Les jetons et cookies applicatifs sont signés ; les jetons API et mots de passe ne sont conservés que sous forme d’empreinte ou de hash.
La clé Ed25519 d’attestation est fournie par la configuration de production ; une clé absente est refusée en production. Son identifiant est dérivé de la clé publique.
Scan et prévention
La finalisation exécute l’analyse DLP lorsqu’elle a été demandée — elle ne l’est pas par défaut — ou lorsque la règle du compte l’impose. NIR valides et secrets pris en charge bloquent alors toujours ; la policy du workspace peut bloquer aussi les avertissements. Les exécutables identifiés par extension et les chemins réservés sont refusés.
Journalisation et minimisation
Les logs HTTP applicatifs conservent méthode, chemin du control plane, statut et durée, sans IP complète ni user-agent brut. Pour une origine d’artefact, le chemin et le slug sont remplacés par une valeur générique. L’IP utilisée pour l’anti-abus des publications est tronquée puis purgée à J+7. Les événements de sécurité (refus de limitation, tentatives d’accès échouées) sont journalisés par réseau tronqué, 30 jours en clair puis en empreinte, 12 mois.
Le journal métier est append-only pendant trois ans. Une attestation d’effacement n’est annoncée qu’après écriture stricte de son événement.
Rétention et suppression
Les publications finalisées avec une durée de 24 h, 7 jours ou 30 jours sont purgées par le worker ; les publications permanentes exigent un compte. Une publication bloquée avant finalisation doit encore être supprimée explicitement. Une suppression retire les objets du stockage principal, traite le CDN configuré, signe l’attestation et neutralise les secrets d’accès. Voir l’architecture d’effacement.
Développement et déploiement
Le déploiement exécute go vet, les tests Go, le contrôle des claims et la vérification SEO du build Astro avant l’envoi. Les migrations précèdent le redémarrage et les trois surfaces sont testées depuis l’extérieur. Les binaires s’exécutent sous un utilisateur système sans shell.
Limites et contrôles non attestés
- Pas de certification HDS, SecNumCloud, ISO 27001 ou SOC 2 revendiquée.
- Pas de résultat de pentest public ni de programme de divulgation coordonnée documenté à cette date.
- Pas de SLA contractuel, RPO ou RTO public validé.
- La politique de sauvegarde et le chiffrement au repos géré par le fournisseur ne sont pas attestés par le dépôt.
- Les habilitations administrateur, revues d’accès, patchs système et procédures d’incident nécessitent des preuves d’exploitation externes au code.
- Le code d’un artefact peut charger les services externes choisis par son auteur.