Skip to content

Sécurité et modèle de menace

# Statique.Auto-hébergé.Vérifiable.

Comment ce site est hébergé, ce qu’il protège, ce qu’il ne protège pas - et comment chacun peut le vérifier indépendamment.

## 1. Architecture

Architecture

Navigateur
  HTTPS · ni cookies ni analyses
Hébergement statique
  Apache · Gandi · Paris · déploiement SFTP
Fichiers du site
  HTML · CSS · JavaScript natif · polices auto-hébergées
Cache hors-ligne
  Service worker · cache local dès la première visite
Confiance
  Intégrité · Vérification · Source · Éditions
Archive
  Instantanés signés et figés

Les routes d'inspection publiques exposent le manifeste signé, les enregistrements de page, les miroirs source lisibles et les éditions archivées sans exposer l'infrastructure privée.

## 2. Actifs protégés

Les contrôles décrits ici protègent :

- La propriété du domaine
- L’intégrité DNS
- L’intégrité du compte d’hébergement
- L’intégrité du contenu public
- La clé de signature utilisée pour l’authenticité des versions

## 3. Modèle de menace

### Compromission de l’infrastructure

- Prise de contrôle du compte registrar
- Détournement DNS
- Compromission des identifiants d’hébergement

### Altération du contenu

- Modification de fichiers après déploiement
- Injection de JavaScript malveillant
- Altération silencieuse des ressources statiques

### Abus administratif

- Credential stuffing
- Analyse automatisée des vulnérabilités

### Bruit internet courant

Sondage automatisé continu pour les chemins CMS courants, les fichiers de configuration ou les points d’entrée connus. Ces éléments sont traités comme des conditions de fond persistantes plutôt que comme des événements exceptionnels.

### Livraison et fraîcheur

- Une version ancienne mais valablement signée servie à la place d’une plus récente
- Un cache navigateur / service worker corrompu ou périmé côté client

## 4. Contrôles

### Registrar & DNS

- MFA activée
- Verrouillage du registrar actif
- DNSSEC activé et validé
- Enregistrements CAA restreignant l’émission de certificats

### Hébergement

- Authentification multi-facteurs activée
- Déploiement SFTP uniquement
- Aucune exposition SSH shell
- Aucune exécution en arrière-plan planifiée

### Contenu public

- Architecture statique réduisant la surface d’attaque côté serveur
- CSP stricte démarrant par `default-src 'none'`
- Aucun chargement de ressource externe
- Aucune exécution de script dynamique
- Stockage navigateur local limité aux préférences du lecteur (langue, apparence), au marqueur de première visite qui retire la mention de traduction automatique, et aux horodatages d’installation du service worker indiquant uniquement quand le cache hors-ligne a été rafraîchi ; consultable sur la console de l’appareil local ; aucun cookie, aucun identifiant d’analyse ou de publicité, aucun suivi de session ni profilage comportemental

### Surveillance

- Analyse structurée des journaux
- Détection de patterns et scoring des anomalies
- Détection de dérive d’intégrité des fichiers par rapport à la base de référence signée

### Contrôle de source & chaîne d’approvisionnement

- Branches `main` et `preprod` protégées : historique linéaire, commits signés obligatoires, aucun forçage, aucune suppression
- Chaque modification passe par une pull request soumise à des contrôles obligatoires — barrière de publication, analyse de secrets, reconstruction reproductible et vérification de signature
- Le déploiement en production attend une approbation manuelle d’environnement avant que la poussée n’atteigne l’hôte en ligne
- Les archives de version portent une provenance SLSA de niveau 3 : construites sur un exécuteur hébergé, attestées sans clé via Sigstore (GitHub OIDC) et inscrites dans le journal de transparence public Rekor
- Chaque version est accompagnée d’un SBOM CycloneDX de la chaîne d’outils de construction
- La clé de signature n’entre jamais dans la CI ; le manifeste canonique reste construit localement et signé en PGP

## 5. Surface de vérification publique

### Routes d’inspection

Le site expose des routes d'inspection publique pour que le contenu publié puisse être contrôlé sans accès à l'infrastructure privée.

- `/integrity/` recense les éditions signées, la clé publique et le manifeste
- `/verify/` recense l'URL canonique d'une page, son miroir source et son empreinte
- `/source/` publie les miroirs lisibles d'une sélection de fichiers publics
- `/integrity/releases/` conserve les instantanés signés et figés

### Ce qu’elles ne couvrent pas

Ces routes facilitent l'inspection et la provenance. Elles ne suppriment pas la nécessité de protéger le DNS, les identifiants d'hébergement et la clé privée de signature.

## 6. Risque résiduel

Ce modèle protège le site statique public. Il ne protège pas contre la compromission du bureau d’enregistrement, de l’hébergement, des appareils clients ou de la clé privée.

### Hors du périmètre

Ce modèle ne tente pas de traiter :

- Compromission physique de l’infrastructure d’hébergement
- Compromission de la racine DNS mondiale
- Compromission d’une autorité de certification (CA)
- Adversaires étatiques
- Exploits navigateur zero-day sur les appareils clients

### Où le risque se concentre

Les risques principaux restent la compromission du domaine, du DNS, de l'hébergement et de la clé de signature privée.

### Hypothèses opérationnelles

- Un auteur unique de confiance contrôle la source et chaque publication
- La seule clé privée de signature réside sur la machine locale de l'auteur, jamais dans la CI
- L'intégrité de cette machine est supposée ; sa compromission est hors périmètre
- Les lecteurs vérifient l'empreinte de la clé hors bande avant de se fier à une signature

## 7. Divulgation

La divulgation responsable est la bienvenue. Les coordonnées de sécurité et les instructions de communication chiffrée sont publiées sur `/.well-known/security.txt`.

Lire la politique de divulgation security.txt de ce site

## 8. Principes de conception

- Simplicité plutôt que complexité
- Comportement déterministe plutôt que systèmes dynamiques
- Transparence plutôt qu’obscurité
- Intégrité vérifiable plutôt qu’hypothèses de confiance

## 9. Vérification & tests

### Contrôles par édition

Chaque édition publiée est contrôlée par rapport à un ensemble fixe de cibles publiques. Les contrôles couvrent la disponibilité, la confidentialité, les en-têtes de sécurité, l’accessibilité, le référencement et le balisage, et le résultat est consigné sous forme d’instantané signé avec l’édition.

Voir les derniers résultats de tests sur `/tests/`.

## 10. Accessibilité

Le site vise le niveau WCAG 2.2 AA. L'instantané de test signé de chaque édition publiée enregistre une vérification d'accessibilité automatisée, et la navigation au clavier, la structure des repères et l'ordre de focus sont vérifiés manuellement. Les exceptions connues sont indiquées ici plutôt que sous-entendues ; aucune n'est actuellement déclarée.

01 Architecture

HTML, CSS, JavaScript natif. Déploiement auto-géré sur Apache (Gandi, Paris). Aucune base de données publique.

02 En-têtes de sécurité

CSP par défaut deny. HSTS. COOP / COEP / CORP. Referrer-Policy no-referrer. Permissions-Policy verrouillée.

03 Actifs protégés

Identité. Contenu publié. Fichiers de vérification publics. Intégrité du code source.

04 Modèle de menaces

Injection de contenu. Compromission des identifiants d’hébergement. Usurpation d’identité. Fichiers obsolètes ou altérés.

05 Contrôles

Aucun script tiers. Aucun formulaire public. Manifeste d’intégrité signé. Exposition de fichiers restreinte. Cache piloté par service worker.

06 Risque résiduel

Le risque hébergeur et registrar demeure. L’exposition d’un site statique est réduite, pas éliminée. Voie de divulgation responsable publiée.

En Construction