La sécurité du système
  1. Vos données, derrière combien de portes ? Comptons.Une application métier garde vos clients, vos devis, vos factures, vos échanges. Voici ce qui se tient entre eux et le reste du monde, enceinte par enceinte. Tout est lu dans le code au moment où cette page est construite.
  2. L’enceinte : 2 ports, un seul chemin.nginx est seul à répondre. Le 80 renvoie vers le 443 ; tout passe ensuite en TLS, et le navigateur retient pendant 1 an de ne plus jamais tenter autrement.
    Ports publics
    80 · 443
    TLS
    1.2 · 1.3
    HSTS
    1 an
  3. Le filtre, sur chaque réponse.4 en-têtes de sécurité posés partout, et aucun script possible sur les maquettes partagées. Une taille maximale, 3 zones de débit et 8 limiteurs applicatifs. La documentation de l’API n’est pas publiée, et rien de sensible ne reste dans le cache du navigateur.
    En-têtes
    X-Frame-Options · nosniff · HSTS · CSP
    Zones de débit
    api 30/min · site 300/min · admin 600/min
    Corps max
    100 Mo
  4. La console : une clé ne suffit pas.La clé est comparée à temps constant, puis il faut un code à 6 chiffres qui change toutes les 30 s et ne sert qu’une fois. La session est gardée par son empreinte, dans un cookie hors de portée des scripts. 10 refus en 300 s déclenchent une alerte. Et sans clé, le serveur refuse de démarrer.
    Code
    6 chiffres · 30 s · ±1 pas · anti-rejeu
    Session
    8 h · HttpOnly · SameSite Strict · Secure
    Alerte
    10 refus en 300 s
  5. Les comptes : rien n’est gardé en clair.Mots de passe hachés. Sessions de 7 jours, stockées hachées. Liens de connexion valables 15 minutes, liens de mot de passe 24 h, à usage unique. Dans les applications sur mesure, un refus dit toujours la même chose : « Adresse ou mot de passe incorrect. »
    Hachage
    bcrypt · PBKDF2-SHA256 200 000 tours (sur mesure)
    Débit
    10 essais/min par IP · 3 e-mails/h par destinataire
    Conditions
    acceptées avant tout envoi, sinon refus
  6. Le coffre : l’empreinte, pas le secret.Les identifiants de messagerie des clients sont chiffrés avec une clé tenue hors du dépôt, sans laquelle rien ne s’ouvre. Des jetons et des liens, le serveur ne garde que l’empreinte. Aucune clé n’apparaît dans un journal, les adresses e-mail y sont masquées, et le service tourne sans droits d’administrateur.
    Chiffrement
    Fernet (AES-128 + HMAC-SHA256)
    Jetons
    256 bits · liens de documents 128 bits
    Journaux
    aucune clé · e-mails masqués
  7. Chaque client dans sa cellule.Les données d’envoi portent l’identifiant de leur client. Un gardien examine chaque envoi : un passage d’un client vers un autre est une violation critique, et tout se verrouille. 2 contrôles d’intégrité tournent chaque heure.
    Inter-clients
    violation critique · verrouillage total
    Contrôles horaires
    2
    Au déploiement
    deux clients, une base : rien ne traverse
  8. Un juge, et il échoue fermé.4 gardiens signalent. Le Guardian part d’un score de 100 et le fait baisser à chaque risque : sous 90, une action sensible attend un humain ; sous 70, tout attend ; sous 50, c’est bloqué ; sous 20, verrouillage. Puis un portier n’exécute que ce qui a été autorisé. Si le Guardian tombe lui-même, l’action sensible est bloquée, jamais laissée passer.
    Gardiens
    Bus de messages · Isolation des clients · Envois groupés · Cohérence des e-mails
    Décisions
    5
    Actions sensibles
    13
    Seuils
    20 · 50 · 70 · 90
  9. L’écluse : 13 portes avant d’écrire à quelqu’un.Un envoi groupé attend d’abord une validation humaine. Puis chaque message franchit les portes une à une : la provenance de l’adresse, la fenêtre horaire, la boîte du client, l’abonnement, le plan de contrôle, les destinataires sensibles, la liste de suppression, les quotas du compte et de la boîte, l’adresse d’envoi vérifiée, les rebonds, l’identité du site prouvée.
    Portes
    13
    Relances
    un contrôle en panne bloque l’envoi
    Envoi
    verrou unique : jamais deux fois
  10. Un paiement ne se rejoue pas.Chaque événement Stripe est vérifié par sa signature avant d’être lu, et un événement déjà traité ne l’est jamais deux fois. Un paiement qui ne se rattache à aucun client est refusé, et le refus reste visible dans la console.
    Signature
    vérifiée avant lecture
    Rejeu
    écarté par identifiant
  11. Tout laisse une trace.Ouvrons le registre. Chaque accès à la console, accordé ou refusé, avec l’empreinte de la clé. Chaque décision du plan de contrôle. Chaque acceptation des conditions, l’adresse IP hachée. Chaque effacement RGPD, d’abord simulé.
    Journaux
    5 : console · événements · décisions · conditions · RGPD
    Hachés
    l’IP des acceptations · l’e-mail des effacements
    RGPD
    simulation par défaut · journal
  12. Les contrôles, et la veille.46 contrôles sont appelés sur les chemins d’exécution : 22 relisent chaque e-mail rédigé pour un envoi groupé, 5 encadrent l’orchestrateur, 6 forment le plan de contrôle, 11 gardent l’envoi, 2 gardent le métier. Et 14 mécanismes veillent : 8 sur le passage d’une action, 6 en rondes, de 30 s à une heure.
    Contrôles appelés
    22 · 5 · 6 · 11 · 2 = 46
    Veille
    8 en ligne · 6 en rondes
    Rondes
    30 s · 5 min · 15 min · 1 h
  13. Aucune mise en ligne sans preuve.Avant de basculer, l’image neuve est interrogée ; après, c’est le service en production. Parmi les tests exécutés dans le conteneur : l’isolation des clients.
    Témoins
    445 dans l’image · 468 en service
    Suites de tests
    10
    nginx
    configuration testée avant rechargement
  14. La sécurité ne s’ajoute pas à la fin.Elle est écrite dans chaque couche, dès la première ligne, et on peut la montrer.
  • Enceintenginx : 80 · 443.
  • Éclusevalidation humaine, provenance de l’adresse, fenêtre horaire, boîte de réception pleine, abonnement à jour, plan de contrôle, destinataire sensible, liste de suppression, quota d’envoi, quota de la boîte, adresse d’envoi vérifiée, rebonds surveillés, identité du site prouvée.
  • Guardianseuils 20, 50, 70, 90.

Des portes, des gardiens, des preuves.

Chaque mécanisme de cette page est lu dans le code, là où il agit. C’est avec cette exigence que je construis les applications de mes clients.

Recompté dans le code à chaque construction

  • 46contrôles appelés sur les chemins d’exécution
  • 14mécanismes de veille
  • 13portes avant un envoi groupé
  • 4gardiens dans le plan de contrôle
  • 5décisions possibles
  • 13actions sensibles
  • 4en-têtes de sécurité
  • 3zones de débit
  • 8limiteurs applicatifs
  • 2contrôles d’intégrité par heure
  • 913témoins à chaque mise en ligne
  • 10suites de tests

Demandez à voir : je montre.

Et vos données, qui les garde ?

Une heure d’entretien pour parler de votre application, de ce qu’elle doit protéger, et de la façon dont elle le fera.

Réserver l’entretien d’une heure