Politique de sécurité de l’information

Traduction fournie à titre indicatif. La version anglaise fait foi.

Cette politique indique comment LFW protège les systèmes qu’elle exploite et les systèmes des clients dans lesquels elle travaille. Elle est rédigée pour un évaluateur de sécurité et décrit la pratique, pas l’intention.

Version 1.0, 6 octobre 2026. Fait partie des pratiques publiées sur la page Confiance, avec la politique de contrôle d’accès, le plan de réponse aux incidents et la politique d’utilisation acceptable.

1. Périmètre et responsable

La politique couvre LFW.com, le Portail client sur my.lfw.com, le site d’administration du personnel, le serveur sur lequel ils tournent, le matériel de travail de LFW et l’accès de LFW aux systèmes des clients.

Leland Fiegel, fondateur de LFW, est responsable de cette politique et en est le seul membre du personnel au 27 septembre 2026. Lorsqu’un contrôle dépend d’une deuxième personne, cette politique le dit au lieu de laisser entendre qu’elle existe.

2. Où tournent les systèmes de LFW

Les applications propres de LFW tournent sur un serveur chez Hetzner à Ashburn, en Virginie, derrière Cloudflare. Le pare-feu de l’hôte n’accepte le trafic web que depuis les plages d’adresses de Cloudflare, de sorte que le serveur n’est pas joignable directement depuis Internet sur les ports web.

SSH se fait uniquement par clé ; la connexion par mot de passe et les mots de passe vides sont refusés. L’application, sa base de données et son index de recherche écoutent sur l’adresse de bouclage. fail2ban bannit les adresses après des échecs de connexion répétés.

Les visiteurs accèdent au site en TLS 1.3 avec une politique HSTS d’un an ; TLS 1.0 et 1.1 sont refusés. Le trafic entre Cloudflare et le serveur est également chiffré.

Le site d’administration du personnel et le Portail client sont des origines distinctes (admin.lfw.com et my.lfw.com). Un script injecté dans une page publique ne peut pas agir comme un membre du personnel ou un client connecté, car aucun des deux cookies de session n’atteint le site public.

3. L’application

Chaque page envoie une politique de sécurité du contenu qui autorise les scripts et les styles par empreinte, sans autoriser de script en ligne, avec les en-têtes standard : pas de détection du type MIME, une politique de référent stricte et une politique d’autorisations qui refuse la caméra, le microphone et la localisation.

Chaque écriture dans l’application est vérifiée selon l’origine dont elle provient, et les points d’accès publics sont limités en débit par adresse. Le type des fichiers envoyés est déterminé en inspectant leurs octets, jamais d’après ce que déclare l’expéditeur ; le SVG est refusé ; une requête peut transporter trois fichiers de huit mégaoctets au plus chacun.

Les liens privés (rapports, devis, invitations) utilisent des jetons aléatoires d’au moins 72 bits. Les secrets se trouvent dans un seul fichier sur le serveur, limité à l’administrateur du serveur et au compte de service. Le dépôt ne contient aucun secret.

4. Construction et mise en production

Chaque version est construite dans un conteneur jetable qui ne contient ni clés, ni fichiers privés, ni accès au serveur. Les scripts d’installation des dépendances sont désactivés ; seuls deux paquets natifs sont recompilés, nommément.

La construction échoue en cas d’erreur de lint, d’erreur de mur de texte ou de casse, de règle de composant en double, de vulnérabilité connue de gravité élevée dans l’un ou l’autre arbre de dépendances de production, ou de test en échec.

Une version de dépendance publiée depuis moins de sept jours est refusée. Les versions piégées sont normalement retirées dans ce délai : l’attente est le contrôle.

Une version est activée d’un seul bloc, après que la nouvelle version a répondu à ses vérifications de routes publiques et protégées, et la version précédente est conservée pour un retour arrière.

5. Sauvegardes

Le répertoire de données du serveur, les bases de données, les secrets et la configuration sont sauvegardés avec restic : chiffrés et dédupliqués, une fois par jour et à chaque mise en production. Seul l’administrateur du serveur peut lire les sauvegardes.

Chaque base de données est copiée avec la sauvegarde à chaud propre à SQLite avant d’être stockée, de sorte que chaque instantané est cohérent. Le dépôt est vérifié chaque semaine.

Conservation : les dix instantanés les plus récents, 30 quotidiens, 26 hebdomadaires, 24 mensuels et 10 annuels. Une copie chiffrée du dépôt est aussi conservée hors du compte d’hébergement, dans un bucket privé Cloudflare R2.

Les sauvegardes du site d’un client sont celles de l’hébergeur. LFW vérifie périodiquement qu’elles s’exécutent et restaure à partir d’elles si besoin, comme le prévoit l’annexe de gestion.

6. Journalisation et surveillance

Le serveur web enregistre chaque requête avec son adresse source. Le Portail client conserve un historique en ajout seul des modifications des demandes et des documents, enregistre chaque consultation d’un compte client par le personnel, et enregistre chaque jeton de connexion lors de son utilisation pour qu’aucun ne puisse être rejoué.

LFW Monitor vérifie LFW.com chaque jour comme il vérifie les sites des clients : accessibilité, liens cassés, vitesse, TLS, enregistrements d’authentification des courriels, politique de sécurité du contenu et autres en-têtes de sécurité. La disponibilité est vérifiée chaque minute, et le pied de chaque page l’affiche.

Sur le site d’un client, LFW Activity Logs enregistre qui a modifié quoi dans WordPress et quand, pour qu’un incident puisse être reconstitué avec les journaux d’accès de l’hébergeur.

7. Sites des clients

LFW ne prend en charge un site que si trois éléments sont en place : un hébergement géré au nom du client, un pare-feu dans WordPress (Wordfence Premium) sous licence pour le site, et Cloudflare devant l’hébergeur avec son pare-feu applicatif et sa protection contre les attaques DDoS activés.

Le cœur de WordPress, les thèmes et les extensions sont mis à jour chaque mois depuis le contrôle de version, avec des vérifications automatiques après chaque publication. Une version de sécurité est appliquée avant le cycle mensuel. Entre deux mises à jour, les pare-feu bloquent les attaques connues, y compris contre une faille publiée avant l’existence de son correctif.

8. Revue des systèmes propres de LFW

LFW a examiné LFW.com, ses points d’accès, le serveur, le DNS et l’authentification des courriels, ainsi que le dépôt, le 16 septembre 2026, par inspection et par des sondages non authentifiés de ses propres ressources. Aucune vulnérabilité exploitable par un visiteur non authentifié n’a été trouvée.

Le seul constat modéré, des permissions de fichiers qui permettaient à un second compte de service de l’hôte de lire les bases de données de LFW, a été corrigé le jour même et est désormais vérifié par un test. Les autres constats étaient des points de durcissement, acceptés en l’état, et sont consignés en privé.

Aucun test d’intrusion indépendant des systèmes de LFW n’a encore été commandé. Lorsque le contrat d’un client en prévoit un pour le site du client, LFW l’organise et en rapporte le résultat.

9. Signaler un problème

Les signalements de sécurité vont à security@lfw.com, indiqué dans security.txt (en anglais). La politique de divulgation des vulnérabilités, avec son périmètre, ses règles et son engagement de non-poursuite, est publiée sur lfw.com/security.

Une personne répond sous deux jours ouvrés. Heures ouvrées : Du lundi au vendredi, de 9 h à 17 h, heure de l’Est (de 6 h à 14 h, heure du Pacifique), hors jours fériés fédéraux. Nous n’assurons ni permanence en dehors de ces heures ni astreinte.

10. Ce que cette politique ne revendique pas

LFW ne détient aucun rapport SOC 2 ou ISO 27001 et ne se conforme à aucun référentiel nommé. Elle ne revendique ni chiffrement de disque pour la base de données en production de son serveur, ni cryptographie validée FIPS, ni système de détection d’intrusion réseau.

Cette politique évolue au grand jour : la version et la date ci-dessus changent quand elle change, et le texte précédent reste dans l’historique du dépôt.